[ mailman-Bugs-1810844 ] address headers shouldn't wrap on space

SourceForge.net noreply at sourceforge.net
Wed Oct 10 16:11:25 CEST 2007

Bugs item #1810844, was opened at 2007-10-10 10:05
Message generated for change (Comment added) made by jikamens
You can respond by visiting: 

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: mail delivery
Group: 2.1 (stable)
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jonathan Kamens (jikamens)
Assigned to: Nobody/Anonymous (nobody)
Summary: address headers shouldn't wrap on space

Initial Comment:
I have a mailman list whose description and address are both somewhat long.  The result is that mailman wraps the Reply-To header so that it looks like this:

Reply-To: Long List Description On First Line
        <long at list.address.on.second.line>

This is perfectly valid according to the RFCs, although given the RFC "SHOULD" noted in the code, it actually seems to be preferable for address headers *not* to be wrapped on space characters, which is what I'm writing about.

The problem is that Juno mishandles the above header field, such that when someone on Juno tries to reply to a message sent to the list, the address that Juno inserts into the reply is "Long List Description On First Line", which is obviously not valid.

Juno's absolutely broken, and I'll take that up with them.  However, in the spirit of "Be generous in what you accept and conservative in what you generate," I think it would be preferable for mailman to be kind and not wrap address headers (To, From, Reply-To, Cc) on whitespace, but rather only to wrap them on commas.  This seems to be keeping with the spirit of the SHOULD in the RFC as well.

I found a workaround, I believe -- adding an explicit reply_to_address setting to prevent the mailing list description from showing up in the Reply-To, which should prevent it from being wrapped -- but still, I think the root cause of the issue would be better addressed by not wrapping on whitespace.

Although I'm not enough of a Python programmer to whip up a patch quickly, I think the right way to fix this is probably to make splitchars an associative hash rather than a string, with the keys of the hash being header field names and the values being strings representing the split characters for those particular headers, along with a "default" key representing the default split characters (i.e., ';, ', what's used now).  Then you'd need to modify _split_ascii to figure out which header field it's wrapping and pick the appropriate split chars to use.  I imagine there are probably other ways to fix this, but this is the one that came to mind for me.


>Comment By: Jonathan Kamens (jikamens)
Date: 2007-10-10 10:11

Logged In: YES 
Originator: YES

Note that there should be whitespace at the beginning of the second line
in the example header shown above, but it's getting stripped out when
Tracker displays the text.


You can respond by visiting: 

More information about the Mailman-coders mailing list