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: 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 <long@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

Message: Logged In: YES user_id=274776 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: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1810844&group_id=103