On Wednesday, November 28 at 11:04 AM, quoth Mutt:
In other words, by merely removing the CRLF, we should have the original, pre-folding version of the header. Thus, when folding, we may only ADD CRLFs (in specific places), rather than give ourselves the freedom to delete and replace some of the characters of the original header.I read the standard the same way, too (except RfC2047 where space or even white space between encoded words is to be removed).
Ahh, an interesting point. Hmm... Though, if I'm understanding that RFC correctly (and I may not be), the space is only to be removed between *encoded* words, and should be left in place between encoded words and non-encoded words or between multiple non-encoded words.
On the other hand, there's a compatibility issue. Some quick tests show that some clients properly implement it the standard way, others don't.
Eh? I lost track of your pronoun there. By "it" you mean folding? or unfolding?
I did notice that Apple's Mail.app implements unfolding improperly (it swaps out tabs for spaces).
So maybe mutt should just keep continuing interpreting it in the broken way but send in the correct. We could then leave it that way until somebody else complains.
If you mean that mutt should behave like Mail.app for rendering, then I think you're right, that probably makes sense.
I'm still wondering though why this hasn't come up earlier...
My best guess would be that most folks don't write long subject lines, and that's probably the only place where it is really visible.
~Kyle --No man has a natural right to commit aggression on the equal rights of another, and this is all from which the laws ought to restrain him.
-- Thomas Jefferson, July 7, 1786
Attachment:
pgpl4OS79RCHo.pgp
Description: PGP signature