[wp-trac] [WordPress Trac] #60420: Default wordpress at site.com sender address can be problematic

[WordPress Trac]

#60420: Default wordpress at site.com sender address can be problematic
-----------------------------+------------------------------
 Reporter:  thinlinecz       |       Owner:  (none)
     Type:  feature request  |      Status:  reopened
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Mail             |     Version:  1.5.1.2
 Severity:  normal           |  Resolution:
 Keywords:  close            |     Focuses:
-----------------------------+------------------------------

Comment (by michael.orlitzky):

 Replying to [comment:51 dmsnell]:
 >  - it is widely-understood that the `-f` parameter in the
 `sendmail_path` has been documented; it has also been established that the
 documentation should not have provided that.

 I don't believe this. I see that the author of
 https://core.trac.wordpress.org/ticket/64368 is fond of stating it without
 justification, but the only discussion upstream is this Github issue with
 no comments: https://github.com/php/php-src/issues/20648

 It is unfortunate that duplicate values of `-f` can cause some sendmail
 implementations to crash, but Wordpress has no business guessing the wrong
 address and trying to pass it to sendmail in the first place. Personally,
 I would have preferred it to crash than lose mail for two weeks.


 > What makes application-level configuration riskier than host-level
 configuration?

 I don't think this is the argument that anyone is making. Neither is
 inherently more risky than the other. What is risky is using an invalid
 address that was pulled out of Wordpress's butt to override an address
 that the host has explicitly specified.


 > > WP is losing even more mail than it was
 >
 > @michaelorlitzky I appreciate you sharing this, but everyone is kind of
 tossing around these claims and I would really love to see numbers. that
 is, I don’t want any of us to have to guess or pick whose opinion is more
 trustworthy given that we have these contradictory claims.
 >
 > are you able to report or estimate delivery issues against total number
 of sites/email attempts on your host?

 When you pointed me towards the new behavior in 6.9, I checked our logs.
 Whereas previously we had no mail going out from wordpress@$sitename, we
 now have lots of it going out from wordpress@$sitename, and many of those
 are rejected because our web server is not in the associated SPF record.
 We were failing 0% due to SPF in 6.8.x, and now we are failing more than
 0%. The numbers are pretty unambiguous.

 I monitor these things, but the emails informing me of the problem were
 being sent to nonexistent wordpress@ addresses.

 Anyone who had a working system using `sendmail -f` to set the envelope
 sender will be in the same boat. And while it's possible that some people
 got lucky and are seeing better results with the new wrong addresses than
 they did with the old wrong addresses, they're still wrong addresses. It
 isn't an empirical matter.


 > With this next question, please understand that I’m trying to learn and
 understand everyone’s needs and that I’m not proposing a solution.
 >
 > From a host’s perspective, if we are already overriding or setting the
 Return-Path for emails, would it not be possible to also override the
 `wordpress at site.com` address?

 How? The "From:" header is in the body of the message. The best solution I
 have found so far is to patch Wordpress. This is easier and more correct
 than putting hooks in every theme, since I don't have to create a hundred
 child themes, and the changes do not propagate to other servers when a
 site is migrated. (When a site moves, SPF/DKIM alignment needs to be re-
 evaluated.)


 > One more burning question I have is this: if the `-f` parameter is set
 in `sendmail_path` and that’s respected by WordPress, is there still an
 issue from the host side? It seems like this is the fix that everyone
 wants: a host can override what’s set by WordPress, but a WordPress plugin
 can also intervene and definitively set a proper Return-Path when a valid
 mailbox exists.

 This fixes the problem for the Return-Path, but then you still have all of
 the same issues with the "From:" address, and there is no way to override
 it.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/60420#comment:55>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform