You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
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.
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).
This could be prevented by a folding directly after the colon.
This is allowed because RFC 5322 states:
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.
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.
The text was updated successfully, but these errors were encountered: