Mailman 3 June 2008 - Mailman-coders

[ mailman-Bugs-1993432 ] Feature Request: List Confg Export/Import via Web/Email
by SourceForge.net June 13, 2008

June 13, 2008

Bugs item #1993432, was opened at 2008-06-13 22:35 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=1993432&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: Vanessa Layne (vlayne) Assigned to: Nobody/Anonymous (nobody) Summary: Feature Request: List Confg Export/Import via Web/Email Initial Comment: Feature request summary: That the web admin interface provide the admin (list owner) with a way to download a configuration file for his list which contains absolutely the entire specifics of his list, and a way to upload such a configuration list, so that lists can be backed up or moved from server to server by list owners who do not have system-level access to the Mailman servers, a situation typical of Mailman installs in commercial hosting companies. Explaination of the Problem and its Context: There is presently no way for a list owner to extract from Mailman the configurations of his list unless he has command-line access. It is essentially impossible to move a list from one Mailman server to another without data loss unless one has access to the command-line tools and/or the system level files. Note that manually reconfiguring the list on another server loses all of the bounce-suspensions and user-suspensions (that is, accounts the owners of which have suspended while on vacation). The admin can only suspend subscriptions as "admin", so that, for instance, users on vacation then must ask the admin to unsuspend them. That in addition to the fact that manually configuring all the other user-selectable subscription options for a large list, manually, is an egregiously large task. In hosted environments in which Mailman is run by the hosting company as a service for their customers -- a substantial share of Mailman list owners are under these circumstances -- it is precisely the situation that the user does not have permissions necessary to run those commands against the server himself. Indeed, he may not be able to log in to the shell on the server at all. This means he must rely upon the hosting company to run backups of his Mailman configurations; he cannot run them himself to protect against disk failure. Perhaps more critically, if the list owner wishes to change hosting companies and port his list from one server to another, he has to request a dump of his config at precisely that moment when his hosting company is least motivated to answer his support requests -- after all, he's a lame-duck customer. Proposed Solution: Ideally, the administrator's web interface to Mailmail would have at least one, if not two, important new options: 1) A link to a page with downloadable links for each of the config files. 2) A link to a page to submit config files. I understand #2 is vastly more problematic. Even just having #1, however, would be enormously beneficial, if it just outputs the various files as they appear on the server. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1993432&group_…

1 0

[ mailman-Bugs-1991348 ] Decorate can create a multipart message with no part headers
by SourceForge.net June 11, 2008

June 11, 2008

Bugs item #1991348, was opened at 2008-06-11 15:15 Message generated for change (Settings changed) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1991348&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Mark Sapiro (msapiro) Assigned to: Mark Sapiro (msapiro) Summary: Decorate can create a multipart message with no part headers Initial Comment: If the message to be decorated is a single part message with no Content-* headers and the message body contains non-us-ascii characters (note that this is not a valid message), Decorate.process() will convert the message to multipart/mixed with a text/plain part for the original body and additional text/plain part(s) for msg_header and/or msg_footer. The problem is the part that corresponds to the original message body has no part headers which confuses some mail readers. This is fixed in bzr for 2.1.11. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1991348&group_…

1 0

[ mailman-Bugs-1991348 ] Decorate can create a multipart message with no part headers
by SourceForge.net June 11, 2008

June 11, 2008

Bugs item #1991348, was opened at 2008-06-11 15:15 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=1991348&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: Mark Sapiro (msapiro) Assigned to: Mark Sapiro (msapiro) Summary: Decorate can create a multipart message with no part headers Initial Comment: If the message to be decorated is a single part message with no Content-* headers and the message body contains non-us-ascii characters (note that this is not a valid message), Decorate.process() will convert the message to multipart/mixed with a text/plain part for the original body and additional text/plain part(s) for msg_header and/or msg_footer. The problem is the part that corresponds to the original message body has no part headers which confuses some mail readers. This is fixed in bzr for 2.1.11. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1991348&group_…

1 0

[ mailman-Feature Requests-1989865 ] Web UI should give metrics to new subscribers
by SourceForge.net June 10, 2008

June 10, 2008

Feature Requests item #1989865, was opened at 2008-06-10 07:38 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1989865&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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: mattl (gnuboy) Assigned to: Nobody/Anonymous (nobody) Summary: Web UI should give metrics to new subscribers Initial Comment: When joining a new list, Mailman should present the user with some metrics on average amounts of list traffic so they can easily gauge their options. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2008-06-10 10:38 Message: Logged In: YES user_id=1123998 Originator: NO Moved to Feature Requests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1989865&group_…

1 0

[ mailman-Bugs-1989865 ] Web UI should give metrics to new subscribers
by SourceForge.net June 10, 2008

June 10, 2008

Bugs item #1989865, was opened at 2008-06-10 14:38 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=1989865&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: mattl (gnuboy) Assigned to: Nobody/Anonymous (nobody) Summary: Web UI should give metrics to new subscribers Initial Comment: When joining a new list, Mailman should present the user with some metrics on average amounts of list traffic so they can easily gauge their options. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1989865&group_…

1 0

[ mailman-Bugs-1989694 ] mailman-created archives are a PITA by default
by SourceForge.net June 10, 2008

June 10, 2008

Bugs item #1989694, was opened at 2008-06-10 13:44 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=1989694&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: Pipermail Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Toni Mueller (tonimueller) Assigned to: Nobody/Anonymous (nobody) Summary: mailman-created archives are a PITA by default Initial Comment: Hello, after finally getting _thoroughly_fed_up_ with the broken archiving options of Mailman, which do nothing to thwart spammers, but makes re-integrating the mail into a live mailbox for local reading a PITA, I came across this thread: http://www.mail-archive.com/mailman-users@python.org/msg49367.html I can "fix" all the mail addresses in an archive I've downloaded using only two vi commands, and I could fix the stupid date format using one more command (presumably), but the fact that any spam bot worth their salt could do it automatically, or that a script doing it could be written in five minutes, doesn't imho warrant to create that extra pain for all regular users. Mailman should provide non-obfuscated archives by default or fully obfuscated archives, at the administrator's discretion, and with a good explanation up front that all the listmasters can read before toggling the switch. Btw, I do have a "legitimate" use for un-obfuscated email addresses (ie, being able to reply to posts after joining a list), but the current state of affairs _only_ serves to aggravate legitimate users, and should be considered snake oil at best, and also "advertised" as such. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1989694&group_…

1 0

[ mailman-Patches-1193846 ] pass emailhost to mlist.Create
by SourceForge.net June 9, 2008

June 9, 2008

Patches item #1193846, was opened at 2005-05-02 10:57 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1193846&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: Mailman 2.1 Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Jorge Jimenez (tribus) Assigned to: Nobody/Anonymous (nobody) Summary: pass emailhost to mlist.Create Initial Comment: As bin/newlist has emailhost option, then make mlist.Create call with lang and host_name parameters to take care of it. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2008-06-09 14:10 Message: Logged In: YES user_id=12800 Originator: NO I don't think this should be done in newlist. I've always regretted putting too much logic into the bin scripts because very often the code wants to be used elsewhere too. But anything in a script is basically unavailable to other parts of Mailman. +1 for working up a new bug/patch for validating urlhost and emailhost. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2008-06-09 13:59 Message: Logged In: YES user_id=1123998 Originator: NO I see what you're saying, but if this is to be addressed, I think it should be done in newlist itself, possibly as you suggest via a modified MailList.CheckValues(). I don't think it should be done by passing host_name to MailList.Create() because if that is done, the exception thrown by Create() is Errors.BadListNameError and it is reported by newlist as 'Illegal list name'. The problem here is if I specify say a listname of 'list' and an unqualified email host name of 'host' to newlist, newlist reports 'Illegal list name: list@host' which is confusing to the user who doesn't realize that the problem is 'host' needs to be qualified. In summary, I think this patch should remain closed and perhaps a new bug should be opened for 'newlist doesn't validate urlhost and emailhost arguments'. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2008-06-09 13:16 Message: Logged In: YES user_id=11375 Originator: NO Here's why I think the emailhost portion is still relevant, though not very important. MailList.Create does: postingaddr = '%s@%s' % (name, emailhost) try: Utils.ValidateEmail(postingaddr) except Errors.MMBadEmailError: raise Errors.BadListNameError, postingaddr Setting the emailhost after calling .Create() side-steps this check, and it doesn't look like bin/newlist does anything like this check, nor does it call MailList.CheckValues(). Perhaps the above check should be put into .CheckValues(), and newlist changed to do mlist.CheckValues(). ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2008-06-09 11:52 Message: Logged In: YES user_id=1123998 Originator: NO Nothing in this patch is currently relevant. The 'lang' part of it was fixed in Mailman 2.1.10, and host_name and web_page_url have been set appropriately by newlist since 2.1.6 although they are not passed to mlist.Create but set after. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2008-06-09 09:26 Message: Logged In: YES user_id=11375 Originator: NO This patch is slightly out-of-date -- mlist.Create now takes a langs parameter instead of just 'lang' -- but adding the host_name is still relevant. mlist.Create checks the validity of postingaddr based upon the emailhost, so setting it after-the-fact is sidestepping that check. I'll try to apply and test this patch, but won't do it not in time for 2.1.11. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1193846&group_…

1 0

[ mailman-Patches-1193846 ] pass emailhost to mlist.Create
by SourceForge.net June 9, 2008

June 9, 2008

Patches item #1193846, was opened at 2005-05-02 07:57 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1193846&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: Mailman 2.1 Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Jorge Jimenez (tribus) Assigned to: Nobody/Anonymous (nobody) Summary: pass emailhost to mlist.Create Initial Comment: As bin/newlist has emailhost option, then make mlist.Create call with lang and host_name parameters to take care of it. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2008-06-09 10:59 Message: Logged In: YES user_id=1123998 Originator: NO I see what you're saying, but if this is to be addressed, I think it should be done in newlist itself, possibly as you suggest via a modified MailList.CheckValues(). I don't think it should be done by passing host_name to MailList.Create() because if that is done, the exception thrown by Create() is Errors.BadListNameError and it is reported by newlist as 'Illegal list name'. The problem here is if I specify say a listname of 'list' and an unqualified email host name of 'host' to newlist, newlist reports 'Illegal list name: list@host' which is confusing to the user who doesn't realize that the problem is 'host' needs to be qualified. In summary, I think this patch should remain closed and perhaps a new bug should be opened for 'newlist doesn't validate urlhost and emailhost arguments'. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2008-06-09 10:16 Message: Logged In: YES user_id=11375 Originator: NO Here's why I think the emailhost portion is still relevant, though not very important. MailList.Create does: postingaddr = '%s@%s' % (name, emailhost) try: Utils.ValidateEmail(postingaddr) except Errors.MMBadEmailError: raise Errors.BadListNameError, postingaddr Setting the emailhost after calling .Create() side-steps this check, and it doesn't look like bin/newlist does anything like this check, nor does it call MailList.CheckValues(). Perhaps the above check should be put into .CheckValues(), and newlist changed to do mlist.CheckValues(). ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2008-06-09 08:52 Message: Logged In: YES user_id=1123998 Originator: NO Nothing in this patch is currently relevant. The 'lang' part of it was fixed in Mailman 2.1.10, and host_name and web_page_url have been set appropriately by newlist since 2.1.6 although they are not passed to mlist.Create but set after. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2008-06-09 06:26 Message: Logged In: YES user_id=11375 Originator: NO This patch is slightly out-of-date -- mlist.Create now takes a langs parameter instead of just 'lang' -- but adding the host_name is still relevant. mlist.Create checks the validity of postingaddr based upon the emailhost, so setting it after-the-fact is sidestepping that check. I'll try to apply and test this patch, but won't do it not in time for 2.1.11. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1193846&group_…

1 0

[ mailman-Patches-1193846 ] pass emailhost to mlist.Create
by SourceForge.net June 9, 2008

June 9, 2008

Patches item #1193846, was opened at 2005-05-02 10:57 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1193846&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: Mailman 2.1 Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Jorge Jimenez (tribus) Assigned to: Nobody/Anonymous (nobody) Summary: pass emailhost to mlist.Create Initial Comment: As bin/newlist has emailhost option, then make mlist.Create call with lang and host_name parameters to take care of it. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2008-06-09 13:16 Message: Logged In: YES user_id=11375 Originator: NO Here's why I think the emailhost portion is still relevant, though not very important. MailList.Create does: postingaddr = '%s@%s' % (name, emailhost) try: Utils.ValidateEmail(postingaddr) except Errors.MMBadEmailError: raise Errors.BadListNameError, postingaddr Setting the emailhost after calling .Create() side-steps this check, and it doesn't look like bin/newlist does anything like this check, nor does it call MailList.CheckValues(). Perhaps the above check should be put into .CheckValues(), and newlist changed to do mlist.CheckValues(). ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2008-06-09 11:52 Message: Logged In: YES user_id=1123998 Originator: NO Nothing in this patch is currently relevant. The 'lang' part of it was fixed in Mailman 2.1.10, and host_name and web_page_url have been set appropriately by newlist since 2.1.6 although they are not passed to mlist.Create but set after. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2008-06-09 09:26 Message: Logged In: YES user_id=11375 Originator: NO This patch is slightly out-of-date -- mlist.Create now takes a langs parameter instead of just 'lang' -- but adding the host_name is still relevant. mlist.Create checks the validity of postingaddr based upon the emailhost, so setting it after-the-fact is sidestepping that check. I'll try to apply and test this patch, but won't do it not in time for 2.1.11. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1193846&group_…

1 0

[ mailman-Patches-1193846 ] pass emailhost to mlist.Create
by SourceForge.net June 9, 2008

June 9, 2008

Patches item #1193846, was opened at 2005-05-02 07:57 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1193846&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: Mailman 2.1 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Jorge Jimenez (tribus) Assigned to: Nobody/Anonymous (nobody) Summary: pass emailhost to mlist.Create Initial Comment: As bin/newlist has emailhost option, then make mlist.Create call with lang and host_name parameters to take care of it. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2008-06-09 08:52 Message: Logged In: YES user_id=1123998 Originator: NO Nothing in this patch is currently relevant. The 'lang' part of it was fixed in Mailman 2.1.10, and host_name and web_page_url have been set appropriately by newlist since 2.1.6 although they are not passed to mlist.Create but set after. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2008-06-09 06:26 Message: Logged In: YES user_id=11375 Originator: NO This patch is slightly out-of-date -- mlist.Create now takes a langs parameter instead of just 'lang' -- but adding the host_name is still relevant. mlist.Create checks the validity of postingaddr based upon the emailhost, so setting it after-the-fact is sidestepping that check. I'll try to apply and test this patch, but won't do it not in time for 2.1.11. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1193846&group_…

1 0