There is and probably always will be discrepancies in the way MUAs handle header folding/unfolding and RFC2047 decoding. There is a possible ambiguity in the part of RFC2047 you quote. 'linear-white- space' is any number of white space characters, so if part of the header is an encoded word followed by some white space followed by ordinary ASCII text, how much of the white space is the separating linear-white- space and how much is leading white space in the text field? Thus the only unambiguous way to represent this is to never begin a text field with white space.
This is further complicated by header folding and unfolding. RFC5322 sec 2.2.3 is clear on how headers should be folded and unfolded. Folding is done per "The general rule is that wherever this specification allows for folding white space (not simply WSP characters), a CRLF may be inserted before any WSP." and unfolding per "Unfolding is accomplished by simply removing any CRLF that is immediately followed by WSP." This is clear, but contradicts the original RFC822 sec 3.1 which says "The general rule is that wherever there may be linear-white-space (NOT simply LWSP-chars), a CRLF immediately followed by AT LEAST one LWSP- char may instead be inserted." and "Unfolding is accomplished by regarding CRLF immediately followed by a LWSP-char as equivalent to the LWSP-char." This effectively says that when folding you can insert multiple whitespace characters, but when unfolding, you don't remove any. Thus the standards have been buggy and even the best intentioned MUAs have to guess about what to do. -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1582819 Title: subject encoding bug To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1582819/+subscriptions _______________________________________________ Mailman-coders mailing list [email protected] https://mail.python.org/mailman/listinfo/mailman-coders
