Bugs item #1810844, was opened at 2007-10-10 10:05
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1810844&group_id=103
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
<[EMAIL PROTECTED]>
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.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1810844&group_id=103
_______________________________________________
Mailman-coders mailing list
[email protected]
http://mail.python.org/mailman/listinfo/mailman-coders
