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

 Replying to [comment:47 dmsnell]:
 > > decision to always define an Envelope-From address
 >
 > @Monarobase can you help me understand this, because it was my
 understanding that WordPress was already sending out an `Envelope-From`
 address before this change. Here are a couple of test emails sent while I
 was trying to confirm the patch.
 >
 >  - [https://aboutmy.email/200fda9e/session before the patch was applied]
 [[br]]`MAIL FROM:<exouser at image-build-instance-
 ubuntu-24-1761002402583201839.js2local>`
 >  - [https://aboutmy.email/a9f9d1e/session after the patch was applied]
 [[br]]`MAIL FROM:<wordpress at 149.165.153.253>`
 >
 > This was for a vanilla installation of WordPress on a fresh Ubuntu node.
 Maybe you are saying that WordPress did not send anything through
 `PHPMailer` in the //before// case, and PHP’s `mail()` auto-set it? and
 somehow that would be some default that hosts configure in a way that it
 would be valid? For reference, the auto-generated value here (before the
 patch was applied) was the Linux user on the server running `nginx` @ the
 local hostname and domain name, something as far as I can tell is
 unavailable for discovery publicly.
 >
 > Have to admit the details here confuse me, and I’m leaning on everyone
 else’s expertise. If you can help us understand how to see what you are
 seeing between the call to `mail()` and the MTAs I would personally value
 that.
 >
 > Specifically, before this patch, my emails were sending with an invalid
 mailbox; yet, you are pointing out that this patch //created// the problem
 of sending from an invalid mailbox. That’s what I’m currently struggling
 to understand.


 Hello,

 Previous versions of WordPress called PHP’s mail() without the 5th
 parameter ($additional_params). i.e. it did not pass an explicit -f value:

 {{{#!php
 mail($to, $subject, $message, $headers);
 }}}


 Starting with WordPress version 6.9 now explicitly sets the envelope
 sender by passing -f via the 5th parameter:

 {{{#!php
 mail($to, $subject, $message, $headers, '-f wordpress at domain.tld');
 }}}


 On cPanel/Exim specifically, when mail() is called without -f, Exim is
 typically configured to use:

 {{{
 <system_user at server.hostname>
 }}}


 That may look odd, but it is a host-controlled default that the host can
 ensure is a valid mailbox. Hosts rely on this because it provides a
 predictable, RFC-valid envelope sender even when applications don’t
 specify one.

 Once WordPress forces -f wordpress at domain.tld, that host-safe default is
 bypassed and replaced with a value that, in many real-world installs, is
 not a valid mailbox (and cannot be assumed to exist).

 ** Why RFC validity matters in practice **

 In your tests, email delivery succeeded because most receiving systems do
 not reject a single message solely because the envelope sender is invalid.
 Modern anti-spam systems typically assign a score or probability to each
 message based on many signals, one of which is RFC compliance.

 An invalid envelope sender usually does not cause an immediate rejection
 on its own; instead, it increases the message’s spam score. If the overall
 score remains below the rejection threshold, the message is still accepted
 — which explains why isolated test messages appear to work.

 The problem emerges at scale. When large volumes of mail are sent with an
 invalid envelope sender, the accumulated scoring impact causes more
 messages to cross rejection or spam thresholds. At that point, messages
 are increasingly blocked or filtered, and the sending IP’s reputation
 degrades.

 This is why many hosts enforce RFC compliance on outbound mail: allowing
 RFC-invalid messages to leave the platform reliably leads to worse
 deliverability over time.

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