[wp-trac] [WordPress Trac] #64368: `Could not instantiate mail function` errors sending mail in 6.9

[WordPress Trac]

#64368: `Could not instantiate mail function` errors sending mail in 6.9
--------------------------+-----------------------
 Reporter:  desrosj       |       Owner:  SirLouen
     Type:  defect (bug)  |      Status:  accepted
 Priority:  normal        |   Milestone:  6.9.1
Component:  Mail          |     Version:  6.9
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:
--------------------------+-----------------------

Comment (by SirLouen):

 I'm going to answer @Monarobase and @amanandhishoe

 The first trouble has been discussed extensively here #60420

 > a configurable setting for the Envelope-From address, and/or

 I cannot fully disagree, but there is a controversial topic, behind the WP
 motto "decisions not options", that historically hinders a lot this type
 of things (specially because the plebs like us cannot take decisions this
 is reserved for the royalty)

 So basically thinking on the idea of bringing the selection of a From or
 even a Sender email, to the frontend it's unlikely to happen in the short
 run without a massive workaround something like a Canonical plugin that
 hardly justifies it.

 For now, what we have is two things: A hook injection via `phpmailer_init`
 and a from setter hook with `wp_mail_from`, that also sets the Sender to
 the same address as the From. So there are plenty of alternatives for
 server operators to fix this trouble. Furthermore, think that Mail was
 originally meant to be a pluggable (this is why most of the code related
 to `wp_mail` is in the file `pluggable.php`). This has many implications,
 and I can't speak on the future, but for now, the intention is not to put
 it anywhere in the frontend.

 If you want to discuss more about this "frontending" topic to avoid going
 too away from the purpose of this topic, I suggest you to move the never-
 ending discussion into #60420. I'm not going to add anything else on this
 topic here.

 The second trouble, about defaulting or not, has been discussed in #49687

 Overall, default is the way to go. The problem here, is that we did not
 consider, that PHPMailer (the library behind WordPress to handle email)
 was not overriding the defaults if there was a value already set. This is
 fixed for now [https://core.trac.wordpress.org/ticket/64368#comment:36
 with the workaround provided here]. By 6.9.1 no workaround will be needed,
 and any overrides like setting your own `-f` will do the cut.

 But be aware, that if you configure your Exim/Postfix or whatever MTA
 Sender directly in the config, it will completely override whatever you
 set in WordPress/PHPMailer/or PHP level. In WordPress we are simply
 defaulting.

 Mail component has not been historically the rockstar of WP, hence, some
 updates like the removal of the Sender, 7 years ago, has impacted poorly
 in how hostings designed their mailing systems (forcing them to set the
 Sender, instead of relying on defaults, which happens to be, not only
 simpler to deploy for automatic installations, but also more comfortable
 to maintain). The problem was that the ticket that triggered that removal
 was unrelated to DNS checks or the liking but more probably an MTA
 specific bug. The truth is that no debugging was done back in the day, and
 we could not trace with precision what happened, but Sender address
 defaulting should have never been removed, and we needed to fix this.

 Having something default can never be intrinsically bad. It means that you
 can (and should) override it if it's not convenient for your setup. But
 having no Sender, by default means, killing the deliverability of anyone
 who has a basic setup by forcing 100% of the people to set up something or
 be unable to send at all.

 Note that all testing was done with defaults in pretty much all MTA, and
 deliverability was 100%. The fact that the Sender envelope address must
 exist is not correct. The only validity check done here is on the domain
 of the Sender Address and this leads us to the first point, which I won't
 be discussing more in this ticket but in #49687

 Conclusion

 Everything goes down to a single point:

 > It reduces deliverability for WordPress sites on hosts that already
 configure return paths correctly and prevents from receiving delivery
 errors

 > it does not know host-level flags (-f, rewriting rules)

 This is a mistake that will be solved in 6.9.1, don't worry. WordPress
 will keep defaulting the Sender address, but prioritizing what has already
 been set server/parser level.

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