RFC1342-encoding References seems unnecessary and creates issues with mail clients

[mhchem]

Looking at the mails I receive, I noticed some bugs with different mail clients. They all choke on the fact that PHPMailer RFC1342-encodes References. It creates headers like this (with personal data x'ed):

References: =?us-ascii?Q?<001001d58d84$e6201780$b2604680$=3D=3Dxxxxxxxxxxx.com@xxxx.d?=
 =?us-ascii?Q?e>_<xxxxxxx-3126fd9b-6e51-41d8-a1e1-4ff12fb9d018-15722663862?=
 =?us-ascii?Q?71=3D=3D3c-xxx-xxxxx-xx02@xxxx.de>_<E9A9DAD9-16AE-4C38-ADCB-?=
 =?us-ascii?Q?8435CB2CBFBA=3D=3Dxxxxxxxxxxxx.de@xxxx.de>?=

I don't see why References need to be RFC1342-encoded at all.

K-9 chokes on it and does not recognize mails belonging together. Apple Mail chokes on it and does create a completely wrong References header when replying. Other mail clients

[Synchro]

The reason it needs encoding is that it contains lines that are longer than 76 chars and so needs to be folded, however, regular folding requires spaces to be present in the original value, and if the value itself is longer than that, it's not possible to fold it without corrupting the value. RFC2047 encoding provides a way of folding lines without introducing potentially corrupting spaces. See #1525 and #1840 for a much more in-depth discussion of this problem. In there you'll note that Apple Mail does the same thing at 998 chars; the limit is lower in PHP because the standard mail() function can corrupt lines longer than about 65 chars.

[mhchem]

I see your point. I didn't know your goal was to limit to 76 chars.
I will close this and file bugs for mail clients that choke on this Q-encoding.
I also open another issue, because the current behavior can be improved. #1878