[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 dmsnell):

 @michaelorlitzky in WordPress 6.9, mail started being sent with
 `wordpress at site.com` as the envelope sender/return path/mail from address.
 This is still configurable via the `wp_mail_from` filter so it’s well
 within reach to change it, but there is no UI setting in `wp-admin` for it
 — it requires a few lines of code in a plugin.

 In the process, #64368 appeared for when people were passing the `-f` CLI
 arg as part of the `sendmail_path` and that created unexpected crashes.
 That specific interaction bug between the reportedly invalid use of `-f`
 inside the `sendmail_path` and the change in WordPress will be resolved in
 the 6.9.1 release (whereas if that arg is present then WordPress will try
 and avoid setting the return-path again).

 > ultimately we have to choose…it's "impossible" to tell whether or not an
 external address is deliverable…It's absolutely trivial

 Since so many people are extremely confident in contradictory extremes it
 leads me to believe that the extremes are not where we’ll resolve this
 issue; if that were truly the case I would think we all would have either
 solved this or given up entirely. So while there’s debate, we can keep
 trying to find creative solutions.

 In the preparation for #49687 I sent test emails to
 [https://aboutmy.email/a9f9d1e/session aboutmy.email] and that provided
 helpful knowledge about what //actually// left WordPress and the shared
 host it was on. Perhaps there is opportunity for a WordPress.org service
 where we could report back on test email. I know that opens a can of worms
 for security and spam and abuse, but perhaps we can find a way to create a
 temporary service which can assert various information about the mail,
 including SPF, DMARC, and DKIM verification, and even attempt delivery to
 the sender address.

 I’m also wondering if there are not solutions out there for hosts to
 provide information to a service on when the last messages appeared in
 their controlled return-path mailbox. If WordPress could know it sent out
 emails, but has never received any messages in the return, it could raise
 a notice “Without having received messages, we cannot be sure that the
 email is configured properly. Check XYZ.”

 ----

 Based on my extremely limited exposure, it seems like something could be
 better with the integration of these email settings and WordPress. It also
 seems a bit suspect to be handing out private information in the mail
 headers, such as the local Linux username and local hostname.

 I would have rather expected a host to override mail settings and send
 something with a return path like `mail-info at cheap-vps.net` rather than
 `cd16557 at n05-cluster2.local`.

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