[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

 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

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