[Mailman-Developers] Use of tabs when folding header lines --increasing subject length as a test

[Nathan Herring]

On 12/2/05 6:13:20 PM, "Mark Sapiro" <msapiro at 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