[wp-trac] [WordPress Trac] #15448: wp_mail() sets Content-Type header twice for multipart emails

Tue Feb 21 06:31:50 UTC 2017

#15448: wp_mail() sets Content-Type header twice for multipart emails
---------------------------------------+------------------------
 Reporter:  rmccue                     |       Owner:  nacin
     Type:  enhancement                |      Status:  reviewing
 Priority:  normal                     |   Milestone:  4.8
Component:  Mail                       |     Version:
 Severity:  normal                     |  Resolution:
 Keywords:  gci has-patch westi-likes  |     Focuses:
---------------------------------------+------------------------

Comment (by dd32):

 > When trying to send emails via `wp_mail()` with a Content-Type of
 multipart/alternative, the Content-Type header will be set with
 `$phpmailer->ContentType`, and again with `$phpmailer->AddCustomHeader()`,
 which causes two Content-Type headers in the email:
 > {{{
 > Content-Type: multipart/alternative;
 >        boundary="example_boundary"
 > Content-Type: multipart/alternative; charset=""
 > }}}

 As far as I can tell, the original issue for this ticket, being that two
 `Content-Type` headers would be added, was fixed in a PHPMailer update
 some time ago - I can't find when, although I'll note PHPMailer 5.2.10
 added the `This is a multi-part message in MIME format.` filler line which
 would've fixed the final Outlook-related parse failures.

 I'll note that there's zero code examples posted on the ticket other than
 a unit test using MockMailer - without example code it's incredibly hard
 to actually verify if an issue still exists, and if so, if the proposed
 patches actually fix it.

 Using the following code:
 {{{
 $html_message = '<html><head><meta http-equiv="Content-Type"
 content="text/html; charset=utf-8" /></head><body><p>Hello
 World!</p></body></html>';
 add_action( 'phpmailer_init', $alt_function = function( $mailer ) {
 $mailer->AltBody = strip_tags( $mailer->Body ); } );
 wp_mail( $to, $subject, $html_message );
 remove_action( 'phpmailer_init', $alt_function );
 }}}

 will result in the following email:
 {{{
 From: WordPress <wordpress at localhost.localdomain>
 Message-ID: <8bd7f4a25da2084a2a803d40a4c823e2 at centos>
 X-Mailer: PHPMailer 5.2.22 (https://github.com/PHPMailer/PHPMailer)
 MIME-Version: 1.0
 Content-Type: multipart/alternative;
         boundary="b1_8bd7f4a25da2084a2a803d40a4c823e2"
 Content-Transfer-Encoding: 8bit

 This is a multi-part message in MIME format.

 --b1_8bd7f4a25da2084a2a803d40a4c823e2
 Content-Type: text/plain; charset=UTF-8
 Content-Transfer-Encoding: 8bit

 Hello World!

 --b1_8bd7f4a25da2084a2a803d40a4c823e2
 Content-Type: text/html; charset=UTF-8
 Content-Transfer-Encoding: 8bit

 <html><head><meta http-equiv="Content-Type" content="text/html;
 charset=utf-8" /></head><body><p>Hello World!</p></body></html>

 --b1_8bd7f4a25da2084a2a803d40a4c823e2--
 }}}

 ----

 That being said, I don't mind the approaches taken here - extending the
 `$message` parameter of `wp_mail()` to accept an array of mime typed
 contents. However, with the above in light that I can't duplicate the
 original issue, I'm curious if the additional code in
 [attachment:15448_Sep2016.diff] is actually needed anymore.

 The interactions between this and #18493 could end up weird - however, I
 expect that this use-case would just override any future HTML email
 template functionality core added.

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