On 12/2/05 6:13:20 PM, "Mark Sapiro" <msapiro@value.net> wrote:
Clearly what I said above is not the whole story as Nathan's message that I received from the list had the Subject: folded with a <space>, yet other Mailman related headers in the message, namely List-Unsubscribe: and List-Subscribe: are folded with <tab>.
The other interesting one from an Outlook or Entourage perspective is the Thread-Topic, which ends up having a tab inserted into it.
Upon closer examination, I see that the email.Header.Header class supports a continuation_ws argument which as Brad notes is used in CookHeaders. The prefix_subject function in CookHeaders attempts to determine the continuation-ws character from the existing header by looking at the first character of the first continuation line of the original subject header. If the header isn't continued or if the first character of the first continuation is not a <space> or <tab>, it defaults to a <tab>.
Scripts are another matter than source code, so I took a look.
Thus it will try to preserve the continuation-ws of an already folded incoming subject, but will default to <tab>. Thus if the incoming subject is not folded, but addition of the prefix lengthens it sufficiently so it folds, it will be continued with a <tab>.
It seems that for other headers, like Thread-Topic, even regularly folded items get its folding space turned into a folding tab.
BTW, this code has been in CookHeaders since 2.1.1, so I don't think anything will change in this respect between 2.1.2 and 2.1.6.
It does seem however, that given RFC 2822, the default continuation-ws character in CookHeaders should be <space> and not <tab>.
From my reading, it seems that email.Header doesn't preserve the FWS in the original header as it should. It would seem that the only time the continuation-ws parameter should be used is if there are sets of characters that need to be turned into multiple adjacent RFC 2047 encoded-words, as that FWS is not considered to be logically part of the header value, but merely an artifact of encoding. If email.Header did the correct preservation, then it would not matter whether you passed in <space> or <tab>.
However, it is significantly more likely that you'd find a space in a header (like the Subject) than a tab, so I'd concur with the suggestion about using space as a continuation-ws character. Or, get a fix from Python.
And now, off to the Python lists...
-nh