[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:24 SirLouen]:
 > Some key elements I want to highlight:
 >
 > 1. The `From:` part is kind of tricky regarding the hosting part. If you
 have a fully configured MTA in your server/webhost/whatever you are using,
 as long as you have the local part (the `wordpress`) mapped, it won't
 bring any troubles. The problem is that most hostings limit the mappings
 to X units, and aliases don't count.

 Apologies, but this is very misleading. If your organization's mail is
 hosted at O365 and if your website is hosted at Bluehost, creating a
 mailbox for `wordpress@$SERVER_NAME` is not going to do anything. You will
 still fail SPF/DKIM in every scenario where you would have failed it
 before. The only situation where this could possibly help is when the
 recipient uses[https://en.wikipedia.org/wiki/Callback_verification sender
 address verification]. But sender address verification is considered
 abusive, never worked reliably, and is mostly gone.

 > I have not used regular web hosting for ages, but the last time I dealt
 with one I remember that just creating the mailbox for `wordpress` with my
 associated domain DNS pointing fully to the hosting was more than enough
 to make the WP mailing system work flawlessly. So from a very basic user
 standpoint, just explaining in the Health Check that they need to create
 said mailbox will be more than enough (or edit this with the corresponding
 hook). For the “advanced administrator” that needs to configure his MTA
 accordingly, here is where the Administration Handbook entry comes into
 play.

 This will almost never help, because sender address verification is almost
 never the problem. Moreover, "nobody" hosts their email on their web
 server (check the market share of Gmail + O365), so this advice is
 impossible for most people to follow.

 > 2. I still need to review the book entry more deeply. Despite it was
 merged some months ago the link was not even added, so it is not published
 yet. I think that the major problem that administrators are having is with
 the `Sender` address itself (not the `wordpress at host` address in
 particular). In fact, in some of my servers I use a
 `wordpress at mail.host.org` format because I host the core domain for
 corporate emails in a different mail server. So the reality is that if the
 administrators can't deal with the filter hook… they have a serious
 problem.

 There is no "Sender" address. It's important to be clear about what we're
 trying to fix. There are a few potential issues:

 1. Sender address verification: can be ignored in 2025, but regardless,
 only cares about the SMTP envelope sender that is sent during off-site
 mail transmission.
 2. DKIM: only cares about the `From: ` header.
 3. SPF: only cares about the SMTP envelope sender.

 All three are related in that, when sending mail locally via `mail()`,
 there is no SMTP transaction, and your MTA has to guess an envelope sender
 to be used when it eventually relays the mail off-site. The common linux
 MTAs will use the `From: ` header by default, unless you override it via
 PHP's `sendmail_path` (not a great workaround because it affects every
 message sent from PHP). So in all likelihood we are talking about the
 `From: ` header in all cases.

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