Happy New Year (almost)!
Archives show me that this topic went around a while back but I did not find a complete answer. It's not really a Mailman bug, but a Mailman choice between correct options.
When the Subject is folded into more than 1 line, Mailman inserts whitespace in the form of a TAB character, at the start of the continuation lines. Outlook, when unfolding, removes the CR LF but leaves whatever whitespace is there, in this case a TAB, so people tell me it looks ugly.
Microsoft, Microsoft...
I noticed that in Mailman/Handlers/CookHeaders.py, we go out of our way to change email.header's continuation_ws from the default of one space to be one tab. Both are correct, since the standard just says whitespace, but if we used one space it would trick Outlook into doing the right thing.
Why the tab? CookHeaders.py gets pretty hairy so I feel like I'm missing something.
Joseph Brennan Columbia University Information Technology
Joseph Brennan writes:
Why the tab?
I would suppose because it looks better in character-oriented display. On most terminals, a tab will expand to 8 spaces, making the fact that the header is folded very obvious. It won't hurt anything if you change it to space. This isn't going to be a true fix, though, because IIRC Mailman *does* insert that space, and it will remain as a doubled space in the recipient's MUA display.
Note that in recent versions of the standard, the handling of FWS has been clarified: the proper way to unfold is to remove the CRLF, and change nothing else. This implies that the proper way to fold is to find some whitespace and insert a CRLF (and nothing else) before that whitespace.
Not that it matters, but I think that graphical MUAs are (as usual) broken here. They are going to reformat unstructured fields anyway (treating the single logical line as a paragraph, and wrapping long ones), so they might as well do the sane thing and interpret all whitespace as merely a single word separator, then wrap that. This is almost never a mistake in my experience. Not even Pythonistas expect whitespace to be significant *within* a line! :-)
Joseph Brennan writes:
Why the tab?
I would suppose because it looks better in character-oriented display. On most terminals, a tab will expand to 8 spaces, making the fact that the header is folded very obvious. It won't hurt anything if you change it to space. This isn't going to be a true fix, though, because IIRC Mailman *does* insert that space, and it will remain as a doubled space in the recipient's MUA display.
Note that in recent versions of the standard, the handling of FWS has been clarified: the proper way to unfold is to remove the CRLF, and change nothing else. This implies that the proper way to fold is to find some whitespace and insert a CRLF (and nothing else) before that whitespace.
Not that it matters, but I think that graphical MUAs are (as usual) broken here. They are going to reformat unstructured fields anyway (treating the single logical line as a paragraph, and wrapping long ones), so they might as well do the sane thing and interpret all whitespace as merely a single word separator, then wrap that. This is almost never a mistake in my experience. Not even Pythonistas expect whitespace to be significant *within* a line! :-)
participants (2)
-
Joseph Brennan -
Stephen J. Turnbull