Mark Sapiro writes:

case, it is done by the underlying Python email library, and all three of the above folded subjects should unfold to essentially the same thing (i.e., the MUA should remove the inserted <cr><lf><tab>)

AFAIK the standard implies but does not say that a single CRLF is to be inserted before "folding white space", and that the proper way to unfold is to simply remove the CRLF. It's not obvious to me that using a TAB here is a good idea; I would prefer a single space.

Again AFAIK, only in the case of abutting MIME encoded words does the standard explicitly say what to do with whitespace other than the CRLF. In that case, all intervening whitespace is to be removed (ie, any whitespace that should remain must be encoded in the encoded words). That's obviously not appropriate for receiving MUAs for non-RFC 2047 cases.

Unfortunately, there is no agreement whatsoever among MUAs on how to deal with the ambiguity in "the standard as MUA-writers understand it".

The bottom line is that I have a lot of sympathy with the OP; Eudora is not at all out of line with the degree of variation in the sample of MUAs I'm familiar with (many do not remove the CRLF, I suppose on the grounds that the sending MUA or user often intends a "sequence of lines" semantics). However, I don't see what Mailman can do except to pick a particular interpretation of the treatment of folding, and stick to it. The one used by Python's email library is certainly reasonable.

This is because the RFC recommends "folding SHOULD be limited to placing the CRLF at higher-level syntactic breaks" and the folding process is preferring to fold following a comma or semicolon if possible.

There's no support in the RFC for this. The "syntactic breaks" referred to are the RFC syntax, and the Subject field has none, not even comments. See RFC 2822 sections 2.2.1 and 3.6.5.

I would argue that Mailman's algorithm is bogus, as it violates POLA. At the very least the subject header should be presumed to be prose to be broken into approximately equal lines.

Barry Warsaw writes:

I agree that the current state isn't correct, but the right place to
fix this is in the email package, so the discussion really should be
moved to Python's email-sig.

I thought about that ... but I certainly hope that people who have opinions about this will join, because this is not a standards issue at root. It's about palliative care for those with sick MUAs.<wink> So what are the symptoms we need to palliate?

Brad Knowles writes:

The problem is that the people who can fix this problem are over on the list that Barry identified. Any discussion anywhere else is not likely to go anywhere, at least not as far as Python & Mailman are concerned.

So, get your experts to go have the appropriate discussion over there, or at least talk about the summary of the discussion.

This is not a problem that can be *defined* by experts, who are generally going to be using conformant, well-behaved software. Sometimes there will be issues, but they're less likely and Mailman Users are probably among the most likely to encounter large collections of users who all use software with the same issue.

Solutions should be proposed and discussed on email-sig, that's the appropriate place for that.

To all: Please, if you have an issue with Mailman's folding of headers, bring it up on the email-sig and/or the Python tracker. I don't know that something will be done soon, but those are the right places to collect reports. For tracker submissions, I suggest the phrase "email header folding" should be in the summary to make search easy (you won't find any yet, though).

You can see what's been happening with the email module recently here:

http://sourceforge.net/search/index.php?words=email&sort=artifact_id&sortdir=desc&offset=0&group_id=5470&type_of_search=artifact&pmode=0

To submit a bug report, I think you need to register with Sourceforge. It's not hard, and AFAICT (I've been registered since the prerelease trial) it's never been a source of spam or anything like that.