address headers shouldn't wrap on space

Bug #266409 reported by Jikamens
2
Affects Status Importance Assigned to Milestone
GNU Mailman
New
Medium
Unassigned

Bug Description

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
        <email address hidden>

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.

[http://sourceforge.net/tracker/index.php?func=detail&aid=1810844&group_id=103&atid=100103]

Revision history for this message
Jikamens (jikamens) wrote :

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.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.