[wp-trac] [WordPress Trac] #52822: PHPMailer change in WordPress 5.7 breaks working sites
WordPress Trac
noreply at wordpress.org
Mon Mar 15 22:37:34 UTC 2021
#52822: PHPMailer change in WordPress 5.7 breaks working sites
--------------------------+-----------------------------
Reporter: tigertech | Owner: (none)
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Mail | Version: 5.7
Severity: normal | Keywords:
Focuses: |
--------------------------+-----------------------------
In [https://core.trac.wordpress.org/ticket/52577] , the "Upgrade PHPMailer
to version 6.3.0" change has this functionality:
//Make the mail() and sendmail transports set the envelope sender the same
way as SMTP does, i.e. use whatever From is set to, only falling back to
the sendmail_from php.ini setting if From is unset.//
This is a change in behavior that can break mail sending, because it
changes WordPress behavior if the site has been using a valid envelope
sender configured in the php.ini "sendmail_from" field. Some (many)
plugins send messages from the WordPress "admin_email" address, so let's
say that the site is properly configured like this:
php.ini "sendmail_from = user123@ hostingcompany.com"
WordPress admin_email address: example@ gmail.com
(Ignore the extra spaces I had to add after "@" to get trac to not hide
them.)
If a plugin uses wp_mail() to send mail "From" the admin_email address
(because it hasn't bothered to ask the user to specify a better one, which
is sadly common), WordPress would previously send that as:
Return-Path: user123@ hostingcompany.com
From: example@ gmail.com
This would work: the "sending with a From header you don't own" is not
recommended for DKIM/DMARC purposes, but at least the Return-Path is a
valid address for the sender, so the SPF would likely match and it would
be delivered.
Now, however, the same message would be sent as:
Return-Path: example@ gmail.com
From: example@ gmail.com
In other words, the valid PHP sendmail configuration is now ignored, and
WordPress tries sending from a domain name that it is not authorized to
send from. This looks like a forgery to receiving servers because neither
DKIM nor SPF match, and the message is likely to be rejected. (I'm filing
this bug report as a result of seeing an actual case of that happening in
the wild.)
The justification for this code change is "This avoids errors from the
mail() function if Sender is not set explicitly and php.ini is not
configured", which is a good goal, but it's affecting more than that: it
also changes how it works when that error is not happening.
The "Return-Path" envelope sender address that PHP is configured to use is
important. Competent server operators have it set up to work reliably, and
that shouldn't be throw away.
A better fix for this goal would be to check for errors from the mail()
function, and retry it with the new code only if there actually was an
error.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/52822>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list