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

 thanks also @amanandhishoe.

 for everyone in this discussion, let’s get one thing out the door though
 to keep the communication simple:

  - //nobody// is discussing Reply-To addresses. ONLY the Return-
 Path/Envelope From/MAIL FROM/Sender address is in scope.
  - the matter of having duplicate `-f` parameters is out-of-scope and
 slated for resolution in 6.9.1.
  - 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. (unfortunately we have a large shared
 legacy of documentation in PHP misleading people on how to reliably
 interoperate).

 if anyone else wants to write something about `Reply-To` or `From`, please
 don’t 😅 — it’ll just muddy this conversation.

 ----

 > Because the envelope is created and finalized by the underlying mail
 transfer agent (MTA) or transactional email service, WordPress itself is
 not in a position to reliably define or manage the envelope sender.

 How would you propose that a WordPress site establish the Return-Path when
 the mail is not handled by the service hosting the site? To borrow some
 other discussions, for example when mail is handled via Office 365, Gmail,
 or Proton?

 > Attempting to do so at the application level risks misalignment with
 host- or provider-level mail configuration and can lead to delivery and
 authentication failures.

 We can remember too that this entire struggle //starts// with misalignment
 and delivery failures that are due to the existing default-generated
 Return-Path. As far as I can tell, //everyone// agrees that we want
 deliverable mail. We have risk with or without it.

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

 > 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?

 ----

 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?

  - Is it non-trivial to know the `site.com` part for a given node/site?
  - Is it non-trivial to rewrite the Return-Path?

 ----

 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.

 ----

 I’m going to take a short pause from this to let other people speak and
 digest what y’all are saying. I am certainly open to a revert of [61010]
 if there’s agreement for it, but it seems from what everyone is saying
 that the primary issue is that a non-plugin-modified Return-Path should
 take a secondary role to a `-f` argument in `sendmail_path`.

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