Mailman 3 October 2007 - Mailman-coders

[ mailman-Patches-1798683 ] SMTP authentication and TLS support
by SourceForge.net 21 Oct '07

21 Oct '07

Patches item #1798683, was opened at 2007-09-20 04:14 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1798683&group_… 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: Mailman 2.2 / 3.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tomas Smetana (tsmetana) Assigned to: Nobody/Anonymous (nobody) Summary: SMTP authentication and TLS support Initial Comment: Hi, here's a patch for Mailman 2.x that enables it using SMTP AUTH and TLS connection. This features might be useful on more paranoid SMTP servers. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2007-10-20 21:44 Message: Logged In: YES user_id=1123998 Originator: NO The patch seems good except if SMTP_USE_TLS is set True in mm_cfg.py, the patch references mm_cfg.SMTP_HELO_HOST which is neither defined nor documented in the patch. Perhaps the patch to Defaults.py.in should include something like SMTP_HELO_HOST = DEFAULT_EMAIL_HOST or even SMTP_HELO_HOST = '' and some comments describing what all the new variables are. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1798683&group_…

1 0

[ mailman-Bugs-1810844 ] address headers shouldn't wrap on space
by SourceForge.net 10 Oct '07

10 Oct '07

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_… 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(a)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_…

1 0

[ mailman-Bugs-1810844 ] address headers shouldn't wrap on space
by SourceForge.net 10 Oct '07

10 Oct '07

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_… 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(a)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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1810844&group_…

1 0

[ mailman-Bugs-1809706 ] genaliases on Postfix is inefficient and can cause bounces
by SourceForge.net 08 Oct '07

08 Oct '07

Bugs item #1809706, was opened at 2007-10-08 19:31 Message generated for change (Comment added) made by cedders You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1809706&group_… 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: command line scripts Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Cedric Knight (cedders) Assigned to: Nobody/Anonymous (nobody) Summary: genaliases on Postfix is inefficient and can cause bounces Initial Comment: We're running Mailman 2.1.5-8sarge5 and Postfix 2.1.5-9 on a mail server with a few hundred lists. For reasons described on Bug [ 1809697 ], we run genaliases as a cron job. While genaliases is running, incoming posts and admin mail to some lists can bounce, with "550 User unknown in virtual alias table". It appears that genaliases loops over all lists and calls MTA.create(mlist, nolock=True, quiet=quiet) for each list, which in turn calls _update_maps() which runs Postfix's postmap and postalias commands. Hence for a time while running genaliases the list of mappings loaded into Postfix is incomplete. The process can also take over a minute because of this repeated hashing. Suggested fix (would patch on Bazaar but repository is empty :) - add "if not nolock:" before _update_maps() in Mailman/MTA/Postfix.py and call "MTA.create(None, quiet=quiet)" once more before os.umask(omask) in bin/genaliases ---------------------------------------------------------------------- >Comment By: Cedric Knight (cedders) Date: 2007-10-08 19:42 Message: Logged In: YES user_id=940941 Originator: YES The issue also appears to be present in 2.1.9. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1809706&group_…

1 0

[ mailman-Bugs-1809706 ] genaliases on Postfix is inefficient and can cause bounces
by SourceForge.net 08 Oct '07

08 Oct '07

Bugs item #1809706, was opened at 2007-10-08 19:31 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=1809706&group_… 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: command line scripts Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Cedric Knight (cedders) Assigned to: Nobody/Anonymous (nobody) Summary: genaliases on Postfix is inefficient and can cause bounces Initial Comment: We're running Mailman 2.1.5-8sarge5 and Postfix 2.1.5-9 on a mail server with a few hundred lists. For reasons described on Bug [ 1809697 ], we run genaliases as a cron job. While genaliases is running, incoming posts and admin mail to some lists can bounce, with "550 User unknown in virtual alias table". It appears that genaliases loops over all lists and calls MTA.create(mlist, nolock=True, quiet=quiet) for each list, which in turn calls _update_maps() which runs Postfix's postmap and postalias commands. Hence for a time while running genaliases the list of mappings loaded into Postfix is incomplete. The process can also take over a minute because of this repeated hashing. Suggested fix (would patch on Bazaar but repository is empty :) - add "if not nolock:" before _update_maps() in Mailman/MTA/Postfix.py and call "MTA.create(None, quiet=quiet)" once more before os.umask(omask) in bin/genaliases ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1809706&group_…

1 0

[ mailman-Bugs-1809697 ] Changing host_name domain does not update virtual-mailman
by SourceForge.net 08 Oct '07

08 Oct '07

Bugs item #1809697, was opened at 2007-10-08 19:14 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=1809697&group_… 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: Web/CGI Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Cedric Knight (cedders) Assigned to: Nobody/Anonymous (nobody) Summary: Changing host_name domain does not update virtual-mailman Initial Comment: We're running Mailman 2.1.5-8sarge5 and Postfix 2.1.5-9. Making a change to the "Host name this list prefers for email" on the "General Options" web page does not create or update a virtual_host entry if needed in the data/virtual-mailman file. Hence this can cause unexpected bounces to addresses associated with that list. The workaround we use for this is to run genaliases regularly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1809697&group_…

1 0

Mailman-coders October 2007