The test case should be updated for the new format, however I'd say that it's not quite correct anyway - that example should be using us-ascii for that header value; While it's workable, UTF-8 is excessive for something that doesn't contain 8-bit chars, and email should try and use minimal encodings (e.g. see the 7bit fallback used for message bodies).

As for the test case, this is fixed in 8701f3b 6ee4d8a f547145.

Regarding the charset selection, isn't this a separate issue of PHPMailer::encodeHeader? Currently it always Q-encodes any value using the PHPMailer::$CharSet, whereas it could be more clever and prefer less expensive charsets such as us-ascii or 7bit if applicable.

Yes, exactly that (though 7bit is a CTE, not a charset). A call to has8bitChars() will tell you whether it can be downgraded safely.

I wonder if this will fix #1525 as well?!

UTF-8 is excessive for something that doesn't contain 8-bit chars

Can you illustrate why UTF-8 is more excessive in this case:

=?UTF-8?Q?eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee?=
  =?UTF-8?Q?eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee?=

vs.

=?us-ascii?Q?eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee?=
  =?us-ascii?Q?eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee?=

Isn't us-ascii a subset of UTF-8?

While the content is indeed identical and compatible, marking it as UTF-8 requires firing up a complete unicode engine to decode it on the receiver, which is unnecessary overhead if we know in advance it's plain ASCII. In PHP for example, we would not be able to decode it easily if we didn't have the mbstring extension enabled, whereas it would present no problems in us-ascii.

It's like putting literal IPs first in SPF records; it's not a requirement, but it makes life easier for receivers.

I wonder if this will fix #1525 as well?!

I think so.

@Synchro Maybe you could have a second third look? I have now refactored my PR as follows:

• Aligned commit messages with the usual style in this repository (consistency).
• Separated encoding selection from encoding (readability, separation of concerns).
• Applied charset selection to B-encoding as well (consistency).

This was a great bit of work, solving several long-standing bugs that I'd been procrastinating about! Thank you very much for all your effort. This set of changes and other things that have happened lately mean that I will release this as PHPMailer 6.1 soon. Would you be interested in joining the PHPMailer org?

@Synchro Thank you for your reviews and the merge. And sure, feel free to add me to the org. I might like to tackle the header name vs. header value line length limitation at some point.