wp_mail() sets Content-Type header twice for multipart emails

[rmccue]

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=""

This appears to cause errors in Outlook, as there is no boundary on the latter.

The cause of this is PHPMailer::GetMailMIME(), as it does not know that the email is a multipart email. The easiest way to achieve this appears to be to simply allow the user to set the AltBody via wp_mail(). In order to achieve backwards compatibility, wp_mail() should work out which part is the text/plain one and which is the text/html one based on the boundary.

I'll be working on a patch for this.

One thought on how to achieve this was passing the body as an array instead of a string to wp_mail(), with keys being the Content-Type for each. Then, if only text/html and text/plain are set, use AltBody for the text and Body for the HTML. If anything else is set, we'll use PHPMailer's attachment system fully instead.

Thoughts?

It sounds good to accept an array of alternative versions.

Treat the non-array case either as we do now or as text/plain

If the body is a string, we'll use the current parsing (i.e. get Content-Type from the $headers parameter), otherwise, we'll ignore the Content-Type header from there and use the key for each item.

My only concern is adding custom headers to each type. We could accept something like this, I guess:

$body = array(
	'text/plain' => array(
		'headers' => array(
			'X-Type' => 'text'
		),
		'body' => 'xyz'
	)
);

Do people need type specific custom headers that often would be my question?

Does supporting multiple content types not remove the need for some of the custom headers?

I agree. Perhaps more elegant would be to simply have a wp_mail_headers_$type filter. Then, the $message parameter we accept could be:

$message = array(
	'text/plain' => 'xyz',
	'text/html' => '<b>xyz</b>'
);

I much prefer this, but it does involve adding an extra filter if people need custom headers.

Initial patch. Add support for text/html and text/plain

Turns out you *can't* have custom headers with PHPMailer anyway.

The patch I've included allows you to use an array such as the one I mentioned above. What I'd like to do is have the ability to add inline attachments (e.g. images), but I'm not sure how one would achieve that. With images, you're likely to have more than one, and if they're the same type, you're slightly screwed.

Perhaps allowing the following would be better:

$message = array(
	'text/plain' => 'xyz',
	'text/html' => '<b>xyz</b>',
	'image/png' => array(
		'file1.png',
		'file2.png'
	)
);

But we still then have the issue of working of if it's inline or an attachment. We might be able to do this based on the type, but I'm thinking a filter would work well for it. I'll submit a patch to that effect later.

Replying to rmccue:

Turns out you *can't* have custom headers with PHPMailer anyway.

The patch I've included allows you to use an array such as the one I mentioned above. What I'd like to do is have the ability to add inline attachments (e.g. images), but I'm not sure how one would achieve that. With images, you're likely to have more than one, and if they're the same type, you're slightly screwed.

Perhaps allowing the following would be better:

$message = array(
	'text/plain' => 'xyz',
	'text/html' => '<b>xyz</b>',
	'image/png' => array(
		'file1.png',
		'file2.png'
	)
);

But we still then have the issue of working of if it's inline or an attachment. We might be able to do this based on the type, but I'm thinking a filter would work well for it. I'll submit a patch to that effect later.

This is looking good.

I just checked the "Unit" Tests we have and found that we do have some for the wp_mail function :-)

Would be good to add some more test cases for your new functionality if you get time but you should at least check that the current ones pass :-D

Add support for multiple attachments of the same type

Looks good.

I've added a basic test for this new functionality in ​[UT322]

Replying to westi:

I've added a basic test for this new functionality in ​[UT322]

FYI, it's boundary ;)

Also, it doesn't appear as though the charset matches the blog's character set, but I'm not sure on that. Probably worth a unit test for that too.

Replying to rmccue:

Replying to westi:

I've added a basic test for this new functionality in ​[UT322]

FYI, it's boundary ;)

Also, it doesn't appear as though the charset matches the blog's character set, but I'm not sure on that. Probably worth a unit test for that too.

:-) Spilling fail

Unit Tests++

I would like to roll this small enhancement from GCI into 3.2

I think the main check for the $message should be is_array() and else, rather than is_string() elseif is_array(). Patch looks good.

Per "This appears to cause errors in Outlook," this sounds like an enhancement that fixes a bug? westi, your call on this one. Looked good a few weeks ago for me.

Another bug with the wp_mail function in WordPress 3.2. It doesn't work if we write this:

wp_mail('Example <me@example.net>', 'The subject', 'The message');

We must write this instead:

wp_mail('me@example.net', 'The subject', 'The message');

Replying to Kleor:

Another bug with the wp_mail function in WordPress 3.2. It doesn't work if we write this:

wp_mail('Example <me@example.net>', 'The subject', 'The message');

We must write this instead:

wp_mail('me@example.net', 'The subject', 'The message');

That has already been fixed what build are you testing with?

3.2-beta1

Replying to Kleor:

3.2-beta1

Which was [17903] the $to issues was fixed in [18006] for #17305 please upgrade to a newer nightly build

I think this still counts as an enhancement rather than a bug.

At the moment we don't really support multipart emails.

Marking for 3.3

The two patches so far both have a major error. If wp_mail() is called twice, AltBody is not cleared. Suggest you add these two lines:

	$phpmailer->ClearCCs();
	$phpmailer->ClearCustomHeaders();
	$phpmailer->ClearReplyTos();

+	$phpmailer->Body= '';
+	$phpmailer->AltBody= '';

	// From email and name
	// If we don't have a name from the input headers
	if ( !isset( $from_name ) )

A test for the error in the patch is as follows: call wp_mail() with an array message to send an HTML email. Then call wp_mail() with a string message to send a different plain email. The second message will be send multi-part, with the previous message in one part and the current message in the other part. Security problem in some uses.

The patch needs to be updated anyway, in light of Bug #17305, so I would also suggest incorporating the improvement I suggested there to allow '<foo@…>' in $to and to clean up the regex:

			// Break $recipient into name and address parts if in the format "Foo <bar@baz.com>"
			$recipient_name = '';
-			if( preg_match( '/(.+)\s?<(.+)>/', $recipient, $matches ) ) {
+			if( preg_match( '/(.*)<(.+)>/', $recipient, $matches ) ) {
				if ( count( $matches ) == 3 ) {
					$recipient_name = $matches[1];
					$recipient = $matches[2];
				}
			}
-			$phpmailer->AddAddress( trim( $recipient ), $recipient_name);
+			$phpmailer->AddAddress( trim( $recipient ), trim( $recipient_name) );
		} catch ( phpmailerException $e ) {
			continue;
..................
				// Break $recipient into name and address parts if in the format "Foo <bar@baz.com>"
				$recipient_name = '';
-				if( preg_match( '/(.+)\s?<(.+)>/', $recipient, $matches ) ) {
+				if( preg_match( '/(.*)<(.+)>/', $recipient, $matches ) ) {
					if ( count( $matches ) == 3 ) {
						$recipient_name = $matches[1];
						$recipient = $matches[2];
					}
				}
-				$phpmailer->AddCc( trim($recipient), $recipient_name );
+				$phpmailer->AddCc( trim($recipient), trim($recipient_name) );
			} catch ( phpmailerException $e ) {
				continue;
..................
				// Break $recipient into name and address parts if in the format "Foo <bar@baz.com>"
				$recipient_name = '';
-				if( preg_match( '/(.+)\s?<(.+)>/', $recipient, $matches ) ) {
+				if( preg_match( '/(.*)<(.+)>/', $recipient, $matches ) ) {
					if ( count( $matches ) == 3 ) {
						$recipient_name = $matches[1];
						$recipient = $matches[2];
					}
				}
-				$phpmailer->AddBcc( trim($recipient), $recipient_name );
+				$phpmailer->AddBcc( trim($recipient), trim($recipient_name) );
			} catch ( phpmailerException $e ) {
				continue;

Security-wise, it would be best to also clear phpmailer at the end of wp_mail(), actually.

This patch has been merged with the "enhanced emails" project code. See #18493 .

This is still a problem. Constructing one's own multipart/mixed email and sending it through wp_mail() results in attachments not being read properly by Hotmail's e-mail program (Gmail and RoundCube work fine). This is due to wp_mail() adding headers so that e.g. in totality, the following headers and body are produced:

MIME-Version: 1.0
Content-Type: multipart/mixed;
	 boundary="==Multipart_Boundary_x{82b884f3b88a46c15d210eda4b90a8f7}x"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: multipart/mixed; charset=""

--==Multipart_Boundary_x{82b884f3b88a46c15d210eda4b90a8f7}x
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit

Dear Recipient,
...

In this case, the lines

MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: multipart/mixed; charset=""

are the ones added by wp_mail(), thus causing Hotmail to ignore any multiparts due to the second Content-Type definition overriding the first.

Could we not just add a flag to wp_mail() that desists from adding any headers other than the ones supplied to it by the function call?

Marking as needs-refresh for now, as it may need parts backported from #18493. I should get to this within a day, if not, yell in my direction. :)

Attaching updated diff from core code revision 686217.

Having looked at #18493, I feel some of those changes (i.e. default to require a template file) may break plugins currently using the wp_mail() function so I haven't back ported anything from that ticket.