Improve folding of too long headers

[mhchem]

When a header gets too long and has no white space for folding, it gets RFC1342-Q-encoded. #1840

However, this leads to lines that are too long (similar to #36 issue 2).

In-Reply-To: =?us-ascii?Q?<33E3D825-9C3C-4F74-867D-3D4520379AD4=3D=3Dxxxxxxxxxxxx.de@x?=
 =?us-ascii?Q?xxx.de>?=

This could be prevented by a folding directly after the colon.

In-Reply-To:
 =?us-ascii?Q?<33E3D825-9C3C-4F74-867D-3D4520379AD4=3D=3Dxxxxxxxxxxxx.de@x?=
 =?us-ascii?Q?xxx.de>?=

This is allowed because RFC 5322 states:

references      =   "References:" 1*msg-id CRLF
msg-id          =   [CFWS] "<" id-left "@" id-right ">" [CFWS]

Furthermore, this initial white space should be considered when determining if Q-encoding is necessary. Because the best solution would be the following output, IMHO.

In-Reply-To:
 <33E3D825-9C3C-4F74-867D-3D4520379AD4=3D=3Dxxxxxxxxxxxx.de@xxxx.de>

Thirdly, you might want to apply Q-encoding only to words that are too long. If there is just one word longer than 76 characters, there is no need to Q-encode the whole header in pieces of 59 characters.

[Synchro]

There are quite a few special cases for folding headers, and they are all there to try to work around line length limits - for example DKIM signatures are allowed to have spaces inserted anywhere, and all spaces are stripped when unfolding - this is an exception to standard RFC822 folding. Unfortunately, all these headers seem to do it in slightly different ways, as your example shows, and the only proper way to deal with it is to have separate folding code for every possible header type that does this.

RFC2047 folding is at least generic, and should apply to any header, however, that's not always the case.

[madgreen1]

Hi! I ran into a similar issue for the List-Unsubscribe header when using the unsubscribe link.
Q-encoding completely breaks the link.