Phpmailer: Some HTML emails received in Outlook replace every 75th character with an equals (=) sign

[Blurn]

Basing this one off of closed issue #464. It seems that the behavior has regressed. The issue did not occur in v5.2.10, but I'm seeing it now after upgrading to v5.2.14 with WordPress 4.4.1 (https://core.trac.wordpress.org/ticket/35212).

There is a relevant StackOverflow thread here: http://stackoverflow.com/questions/33787777/phpmailer-inserts-equal-sign-every-75th-character/34589032#34589032

I have attached some examples:
Good_Email_Example_5.2.10.txt
Bad_Email_Example_5.2.14.txt

My current workaround is to replace WordPress' core file for PHPMailer with version 5.2.10. As you can imagine this is less than ideal because updates will bring be back up to 5.2.14 where the issue occurs.

Please let me know how I can help you reproduce this or if I should be submitting this issue somewhere else (like straight to WordPress instead). Thank you!

[Synchro]

What I'd like to see is an example of a complete delivered message generated using each version (preferably with identical content) so we can compare them and see the differences. The examples you posted are not encoded messages so they are no good for seeing what's wrong with the encoding.

[Blurn]

Thanks for the response! I'm new to troubleshooting mail issues like this. Pardon me sending the incorrect examples. I have grabbed the messages straight from the postfix queue (immediately after generation). They are identical messages. One generated with 5.2.10 and the other with 5.2.14.

See below:
Good-Example-5.2.10.txt
Bad-Example-5.2.14.txt

Let me know if that isn't what you need. I will try my best to provide whatever is needed. Thanks again!

[ttmjason]

How would I generate the copy of an encoded message? I'm running into the same issue but not on Wordpress using version 5.2.14

[Synchro]

@Blurn - Those examples are utterly corrupted, nothing like an email should like - they look like they are pulled from a log file or something, not an email program?

@ttmjason - in your email program you should be able to "show original" or "view source" on a message, then copy and paste the content. Your mail program may be able to save the message directly in its raw form (usually with a ".eml" extension).

[sarahkemp]

Same issue with Wordpress 4.4.1 and PHPMailer 5.2.14. Unfortunately these emails aren't _quite_ identical but they are very close (aside from the equals issue):

phpmailer-5.4.14.txt
phpmailer-5.4.10.txt

The mention in this answer: http://stackoverflow.com/a/34589032/1947155 pointed me to why this was only happening to some of my emails - the ones with a single line over 1,002 characters in length.

I rolled back to 5.4.10 and the problem appears resolved, but I would obviously like to be able to keep up with the release, so I hope these files will help with this issue.

Using Outlook 2010.

[Synchro]

@sarahkemp Those two files are absolutely identical - they look like the source of the original message body before sending, not of a delivered message. That SO answer says that the problem does not appear if you're sending using SMTP (i.e. you're calling isSMTP) - does that happen for you too?

[sarahkemp]

I would have sworn that I checked those files when I uploaded them and they were different, but I agree they are identical. Let me try again:

phpmailer-5.4.10.txt
phpmailer-5.4.14.txt

These are pulled from Outlook's Other Actions > View Source.

I added this code to my wordpress functions.php:

add_action( 'phpmailer_init', 'configure_smtp' );
function configure_smtp( PHPMailer $phpmailer ){
    $phpmailer->isSMTP(); //switch to smtp
    $phpmailer->Host = 'mail.mydomain.com';
    $phpmailer->SMTPAuth = true;
    $phpmailer->Port = 25;
    $phpmailer->Username = 'Username Here';
    $phpmailer->Password = 'myemailpassword';
    $phpmailer->SMTPSecure = false;
    $phpmailer->From = 'From Email Here;
    $phpmailer->FromName='Sender Name';
}

And the emails I received were plain text so I know the snippet was used (I later added a call to isHTML()). The emails sent with isSMTP() were not affected by this issue. I used smtp.gmail.com for testing this.

Sorry for the bad uploads last time, I really don't know how I managed that.

[Synchro]

@sarahkemp Those are still decoded bodies, not complete messages - they should start with email headers - both go straight into HTML. It's odd that one uses UNIX line breaks, the other Windows.

The HTML content is also missing <html>, <head> and <body> tags, which won't be helping, unless it's your client that has stripped them.

[Blurn]

@Synchro I have exported mime (.eml) examples. See attached files below (I am using .txt instead of .eml to get around the Github file extension filter):

• Good-Example-5.2.10.txt
• Bad-Example-5.2.14.txt

Let me know if I can provide anything else. Sorry about the original examples. I grabbed them right out of the email server mail queue...

[sarahkemp]

@Synchro I'm sorry these don't help. Outlook doesn't have an option to export the full message that I can find. That SO thread also mentioned that more well-formed HTML might not see this issue, but this HTML hasn't changed since version 5.4.10 was working with it. It also suggested this issue doesn't occur in all email clients, Outlook was one of the unlucky ones (surprise surprise).

The line breaks changed (disappeared in windows) when I saved the file. I couldn't say why one changed and the other didn't, I used the same method for both.

Hopefully @Blurn's files can help with this issue.

[Blurn]

@sarahkemp I hope so too. To get mime files (.eml) from Outlook I used: http://www.maildev.com/msgextract/ ... There's a free trial. Outlook is great in so many ways but you're right, no surprise we're running into issues rendering messages and that there is a limitation on what it can export messages as.

[Synchro]

@Blurn thanks, those look right!

I see several oddities in both messages:

• Two MIME-Version: 1.0 headers
• Missing pre-multipart text (before the first boundary)
• Boundary strings not in PHPMailer format
• The 5.2.14 version has additional quoted-printable-encoded = at random points

Most of these don't look like they are caused by PHPMailer since it doesn't do it in other circumstances. At a guess I'd say that your email extractor doesn't really extract, but reconstructs a message from the available data. Could you run the same code to create your message, but just before calling send() do this:

$mail->preSend();
echo $mail->getSentMIMEMessage();

This should dump you a copy of the message as it is sent. Alternatively, BCC the message to an account that you don't use Outlook to read. Either way that should provide more info about where this problem is happening.

[Blurn]

@Synchro I sent the same messages to my Gmail account and used the show original function to save the .eml files. See below:

• Good-Example-5.2.10-from-GMail.txt
• Bad-Example-5.2.14-from-GMail.txt

Let me know if those don't work and I'll run your other method. Thanks again!

[Synchro]

Thanks, that's more informative - and the structure is quite different to what's turning up in Outlook! The problems with headers have gone away, and there is no multipart structure and no plain text version, suggesting that Outlook is being quite creative with what it receives. What's left looks like a problem with line break formatting - the extra encoded = are occurring at line breaks in the bad gmail example.

I'll look into this, but while I'm doing that could you try using the code in the current master branch rather than the 5.2.14 release version - there were some changes relating to line breaks just recently.

It would be useful to compare what you sent with what shows up in your mailbox, so it would be useful to see the generated messages before they are sent - if you write them directly to a file rather than echoing it will eliminate copy/paste as a source of differences:

$mail->preSend();
file_put_contents('email1.eml', $mail->getSentMIMEMessage());

[kenschenke]

I'm seeing the same issue in my own PHP code. In my case, the recipients using Outlook report the extraneous equal signs when I send the messages using 5.2.15 but not with 5.2.10. I have sent the exact same message in PHPMailer 5.2.10 and 5.2.15 and the only difference I can find in the message content is an extra blank line between the X-Mailer the MIME-Version headers in 5.2.15. Could this be what is confusing Outlook? I have attached the message sources (as provided by GMail).

phpmailer_5.2.10.txt
phpmailer_5.2.15.txt

[Synchro]

In those examples I see no gap between X-Mailer and MIME-Version headers? The 5.2.10 version has an additional X-Priority header and a trailing slash in the X-Mailer URL. Neither of those should cause such problems, but it would be good if you could experiment further to see if they do!

[kenschenke]

You're right - I completely misunderstood what WinMerge was showing me in the side-by-side diff. I re-ran the test using preSend(). Here are the two outputs again. This time, the major difference is the end of line characters. I ran both of these tests on a Linux machine with PHP 5.3.3.

phpmailer_5.2.10.txt
phpmailer_5.2.15.txt

[Synchro]

The extra line breaks looks suspiciously like we've got mixed format line breaks - the headers using \n and the body using \r\n, and later on \r has been converted to \n, resulting in double breaks. Can you try setting $mail->LE = "\r\n";? This is something I've been contemplating setting as the default.

[kenschenke]

I added the$mail->LE = "\r\n"; using 5.2.10 and 5.2.15. In both versions, the recipient's email body was rendered blank (Microsoft Outlook). Overlooking the Message-ID and MIME boundary lines, the messages were identical between the versions. Not surprising, considering they both rendered blank.

So far, the only combination that seems to work with this recipient's Outlook client is 5.2.10 without the $mail->LE set. I saved outputs on both versions with and without the LE set.

5.2.10_noLE.txt
5.2.10_withLE.txt
5.2.15_noLE.txt
5.2.15_withLE.txt

[Synchro]

This is very weird. The only one of those that is technically correct is 5.2.15 with the changed LE, in which all line breaks are CRLF. 5.2.10 without the change has one notable feature: the line breaks immediately after the subject line (that separates headers from body) are an LF followd by a CRLF; all others are LF:

Subject: Test Email<LF><CR><LF>

The original examples in this issue show a kind of strange double-QP-encoding that's causing the extra = chars, which I can only attribute to something between the sender and receiver - in my experience Outlook might render things oddly, but it doesn't mess with the message source. Does your client have any kind of mail/spam filter? I've seen some do horrific things to messages...

@kenschenke Are these examples taken from the client's Outlook, or are they copies of what you sent?

[Synchro]

BTW the reason I'm thinking of forcing CRLF as the line ending is this; it's a direct contravention of the RFCs to do anything else. In light of that, it would seem reasonable to remove/ignore the LE property altogether - its existence orginates before my time with PHPMailer!

[Synchro]

To anyone seeing this happen, can you try BCCing yourself in a message that this happens in in an account not going though Outlook or that server? That way we would be able to tell if the corruption in the message is occurring before or after sending.

[kenschenke]

@Synchro The examples I have uploaded were gathered using $mail->preSend() and file_put_contents('filename.txt', $mail->getSentMIMEMessage()). My email client is Outlook 2013 using POP. My recipient is using an unknown version of Outlook on an Exchange server. The emails are being forwarded through a filtering service on outlook.com (formally known as Forefront).

When I Cc myself to either my POP mailbox or a GMail account, the emails always look fine no matter which version of PHPMailer or the LE settings. My educated guess is that the mail scanning service on the recipient's end is where the messages are getting messed up.

I also have a free account on outlook.com. It's set to auto-forward everything to my GMail. When I sent a message to my live.com email using 5.2.15, the forwarded message to GMail has the extra equal signs. When that same message (using 5.2.15) is sent directly to my GMail account, it looks fine. If I instead send the message my to live.com email using 5.2.10, the message arrives in my GMail looking fine.

[Synchro]

Thanks, so it sounds like I should be able to reproduce it with a live.com account.

[Synchro]

Well that wasn't very productive. I'm finding it works (with your exact content) perfectly on outlook.com with either \n or \r\n breaks!

Is there any difference between outlook.com, hotmail and live?

Have you tried setting $mail->Encoding = 'base64';? It's more likely to get trapped by spam filters, but it might be more robust to that forwarding system.

[kenschenke]

Some observations:

1) Explicitly setting $mail->Encoding = 'base64'; works.
2) Break each line of content at less that 76 characters also works.
3) Using a different version of PHP works.

I have two different Linux machines. One is running PHP 5.3.3 and other is running 5.4.16. The failure occurs when PHP 5.3.3 composes the message using quoted printable encoding. If I pre-format the content using line breaks or force base64 encoding, the message arrives readable.

The part that still continues to REALLY confuse me is, both versions of PHP construct the quoted-printable block in the exact same way.

[bbarnwell]

Any further development on this? We've started encountering the issue when Gravity Forms started sending notification emails to Exchange with lots of equal signs inserted. We rolled back to 5.2.10 and it seems ok.

[Synchro]

It's still not resolved. PHPMailer 5.2 can be inconsistent in its line break formats (as you can see from earlier in this thread). My best suggestion at the moment is to try PHPMailer 6.0 (not yet released) which is completely consistent in its line break format and a little more conservative about adding unneeded breaks.

[bbarnwell]

Thanks for the update. We realized we're running an old version of PHP, 5.3.3 as well. We'll try updating that first.

[Luisinho77]

Greetings!

I just wanted to share with you my excitement about some amazing stuff, just take a look at that http://rdatolyjy.poolsafetyfenceorlando.com/e4dmvx

Kind regards, ljlorente

[sarahkemp]

Per @kenschenke suggestion that another version of PHP would work, I moved from 5.3.3 to 5.4.45 with no improvement on this issue. I also fixed the structure of my emails to include HTML and BODY tags hoping that would help but no luck. When the emails go through Gmail they are fine, even when they auto forward to Outlook they look fine in Outlook. Only when they are sent directly to Outlook do I see this issue. We also use the spam filtering service mentioned above formerly known as Forefront, now "Exchange Online Protection", I believe.

I installed Easy WP SMTP and with that plugin enabled, the message looks fine.

[madurapa]

That's odd, specially since not all the ns are transliterated and not at a specific position.

Try calling set CRLF with "\r\n" as well. Look up the message details in Exchange and inspect the Content-Type and Charset / Encoding - post the raw thing here so we can inspect it.

Microsoft Knowledgebase

Microsoft Exchange uses an enhanced character set. The default MIME character set for Microsoft Exchange is ISO 8859-1. Some gateways do not support the way this character set issues a soft return for line feeds. When this occurs, each line is terminated with an equal sign showing the line break where the gateway's line-length support ends.

[fc-os]

Hi,
i had the same problem in 5.2.14, it seems to be the "setWordWrap" method.
If if have an alt body the wordwrap isnt executed on the html body and the method "hasLineLongerThanMax" returns true and enables the quoted-printable encoding.

I think the combination is having an alt body and an html body with lines that exceeds the maximum of 1000chars is the problem.

I moved the html body wrapping out of the switch, so that the alt and html body get an wrapping and cant reproduce it anymore, but im not sure if
thats the ideal fix or more like an workaround.

[Synchro]

Doing that will mean that lines may exceed the maximum length permitted by the RFC, and the approach PHPMailer takes is exactly the same as what Apple Mail does, so it's not exactly controversial. The quoted printable encoding the PHPMailer does is pretty strict and does not have problems in general. Some examples posted here show stray = chars occurring in places where PHPMailer did not insert them, so something else is messing up the encoding, possibly some spam filter. This problem appears to be specific to some particular configurations of outlook, so it's hard to reproduce - for example I have sent byte-for-byte exact copies of the problematic examples posted here into my own outlook account without any problems at all.

[Alexis2000]

We just had similar issues here. We fixed it by reformatting the html in the email to be properly indented with line breaks. I used my IDE for this (code formatting). I think if one line exceeds 1002 characters in the email then hotmail/outlook is inserting equal signs to escape things.

[Synchro]

It does seem to be a line length issue. PHPMailer spots long lines and automatically switches to using quoted-printable encoding to wrap long lines safely. However, from what we've seen above, sometimes hotmail re-encodes and rewraps at a shorter length, resulting in a double encoding without matching MIME changes (i.e. corruption). You can tell this is happening because the spurious = chars appear in places that there were none in the original message, and the identical message CC'd to a non-corrupting client does not exhibit the problem.

[Synchro]

There has been some work on a possibly related bug in #953, which includes various workarounds. Please can you have a go with the latest 6.0.0rc5 release to test.

[stephwestgarth]

So I am having this issue after upgrading a system I've inherited from 5.2.9 to 5.2.23 (yes, it was that neglected). Along with equals signs, it also sometimes inserts random whitespace characters wherever it feels like in the HTML (eg. styles now have spaces between characters, so it breaks formatting, end tags now have a space in them so it freaks out and tries to insert a valid end tag wherever it feels like)

It sounds like these are both the same issue, one is just using live, one is using a corporate outlook account and it's how it is dealing with the long lines.

The issue is fixed in 6.0.0rc5, but if PHPMailer 5.2.x is still being recommended for users that are using PHP 5.x, it should probably be fixed, or at least noted as a known issue so others don't have to do quite so much hunting to work out how to deal with the problem.

[Synchro]

The extra spaces and stray = are not being added by PHPMailer - the message is ok at the point it's sent, it's corrupted on receipt, and only by hotmail/outlook. 6.0 works from PHP 5.5 and deals with the problem in a different way, and there's a fair amount of code relating to it that I don't want to back port - I really just need to get 6.0 released, so I'm glad to hear that it's ok for you in the 6.0rc.

[stephwestgarth]

Sorry, I meant outlook/hotmail was inserting the characters due to the format of the code from PHPMailer. It's definitely just another typical Outlook/hotmail problem. I perfectly understand your hesitance to back port, just thought it was worth flagging even just for others that may come across this thread looking for answers and needing a solution. Good luck with getting 6.0 released

[Synchro]

6.0 has finally been released! Hopefully the changes in there will fix this problem, but if it has not, please open a new issue.