Mailman 3 April 2011 - Mailman-coders

[Bug 266408] Re: genaliases on Postfix is inefficient and can cause bounces
by Cedders 17 Apr '11

17 Apr '11

Very good. I don't recall testing it, and wonder if it needs further testing with MTAs other than Postfix. BTW the reference to Bug [ 1809697 ] is now launchpad bug 266407. -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/266408 Title: genaliases on Postfix is inefficient and can cause bounces

1 0

[Bug 266806] Re: unsubscribe removal confirmation should be optional
by Mark Sapiro 17 Apr '11

17 Apr '11

Cedders wrote on 2011-04-15: #4 > I would prefer instead of ALLOW_OPEN_SUBSCRIBE an additional value for > mlist.unsubscribe_policy =2 meaning no approval and no confirmation necessary > - instant unsubscribe without any authorisation needed. Perhaps it could > generate a warning if send_goodbye_msg==0, but I don't see any reason site > managers would want to restrict it. I think you are misunderstanding the request for ALLOW_OPEN_UNSUBSCRIBE in the posts you reference. They ask for ALLOW_OPEN_UNSUBSCRIBE to work analogously to ALLOW_OPEN_SUBSCRIBE. I.e. if the site sets ALLOW_OPEN_UNSUBSCRIBE = Yes in mm_cfg.py, then Privacy options... -> Subscription rules -> unsubscribe_policy would offer a third option of "no authentication or confirmation" to the list admin, and if ALLOW_OPEN_UNSUBSCRIBE were defaulted or set to No, only the current two options would be available. Thus there would be a third option as you envision, but its availability would be controlled by the site admin. I certainly understand the desire to make it as easy as possible for people who want to leave a list to do so, but this has to be balanced against the possibility for abuse. Imagine how you would feel if some anonymous member of a list didn't like your opinions, and every time you posted you found yourself unsubscribed and had to go through the process of subscribing and setting your options all over again. In my case, I get an unsubscribe confirmation from the mailman- users(a)python.org list a couple of times a month. I suspect that these may at least in part be the result of spam spoofing my address sent to the -leave or -unsubscribe address, but whatever they are, I would be very annoyed if instead of the confirmation request that I could ignore, I received a notice of unsubscription and had to rejoin the list. -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/266806 Title: unsubscribe removal confirmation should be optional

1 0

[Bug 266408] Re: genaliases on Postfix is inefficient and can cause bounces
by Mark Sapiro 16 Apr '11

16 Apr '11

** Changed in: mailman Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/266408 Title: genaliases on Postfix is inefficient and can cause bounces

1 0

[Bug 266408] Re: genaliases on Postfix is inefficient and can cause bounces
by Mark Sapiro 16 Apr '11

16 Apr '11

> and call "MTA.create(None, quiet=quiet)" once more before > os.umask(omask) > in bin/genaliases Has this been tested? It looks like this will be a deadlock because genaliases has the lock at this point and MTA,create tries to obtain it. It seems that things need to be rearranged to finally: lock.unlock(unconditionally=True) MTA.create(None, quiet=quiet) os.umask(omask) ** Changed in: mailman Status: New => In Progress ** Changed in: mailman Milestone: 2.1-stable => 2.1.15 ** Changed in: mailman Assignee: (unassigned) => Mark Sapiro (msapiro) -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/266408 Title: genaliases on Postfix is inefficient and can cause bounces

1 0

[Bug 266732] Re: genaliases shouldn`t call postmap after every list
by Mark Sapiro 16 Apr '11

16 Apr '11

*** This bug is a duplicate of bug 266408 *** https://bugs.launchpad.net/bugs/266408 ** This bug has been marked a duplicate of bug 266408 genaliases on Postfix is inefficient and can cause bounces * You can subscribe to bug 266408 by following this link: https://bugs.launchpad.net/mailman/+bug/266408/+subscribe -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/266732 Title: genaliases shouldn`t call postmap after every list

1 0

[Bug 266806] Re: unsubscribe removal confirmation should be optional
by Mark Sapiro 16 Apr '11

16 Apr '11

Cedders wrote: #4 >I think Sourceforge bug 1951777 <http://sourceforge.net/tracker/?func=detail&aid=1951777&group_id=103&atid=3…> is a duplicate of this, and have commented there as follows. Please do not use the SourceForge Tracker. All mailman items therein were migrated to Launchpad as of 2008. SourceForge RFE 1951777 is LP Bug #266874 which is marked as a duplicate of this. No Mailman developers read the SourceForge tracker any more. As it says there, "Do not use this tracker! Submit your issues at Launchpad or they will be ignored." We tried to make the SF tracker read only, but we couldn't make it world readable without making it world writable. It is available only so existing old URLs still work. -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/266806 Title: unsubscribe removal confirmation should be optional

1 0

[Bug 266732] Re: genaliases shouldn`t call postmap after every list
by Cedders 16 Apr '11

16 Apr '11

This is a duplicate of bug 266408. <https://bugs.launchpad.net/mailman/+bug/266408> -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/266732 Title: genaliases shouldn`t call postmap after every list

1 0

[Bug 266806] Re: unsubscribe removal confirmation should be optional
by Cedders 16 Apr '11

16 Apr '11

I think Sourceforge bug 1951777 <http://sourceforge.net/tracker/?func=detail&aid=1951777&group_id=103&atid=3…> is a duplicate of this, and have commented there as follows. As I understand it, this bug suggests that a list could optionally be configured not to send confirm messages and allow an unsubscribe by email without the password, or via web; having send_goodbye_msg set to "yes" provides a certain level of security against abuse. This is also suggested in a message on mailman-users in 2001 <http://mail.python.org/pipermail/mailman-users/2001-June/011729.html> as an additional supervisor function ALLOW_OPEN_UNSUBSCRIBE, and again in 2005 <http://mail.python.org/pipermail/mailman- users/2005-May/044573.html>. I would prefer instead of ALLOW_OPEN_SUBSCRIBE an additional value for mlist.unsubscribe_policy =2 meaning no approval and no confirmation necessary - instant unsubscribe without any authorisation needed. Perhaps it could generate a warning if send_goodbye_msg==0, but I don't see any reason site managers would want to restrict it. Note that a one-click web unsubscribe is possible for non-digest users provided "personalize" is set to "yes" (or "full"). I find that on a one-to-many list of several thousand subscribers there can be a significant number of complaints from users who simply don't seem to be able to get their head around either requesting a password or responding to a confirmation token. This failure to follow the instructions produces spam reports and requires moderator intervention. So this can go the footer (this is the short form suggested by Jimm Tittsler in http://mail.python.org/pipermail/mailman-users/2005-May/044961.html): To unsubscribe click the link below: <%(user_optionsurl)s?password=%(user_password)s&unsub=1&unsubconfirm=1> However, this isn't the full solution that another choice of unsubscribe_policy would give. (I may have a go at implementing this.) ** Bug watch added: SourceForge.net Tracker #1951777 http://sourceforge.net/support/tracker.php?aid=1951777 -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/266806 Title: unsubscribe removal confirmation should be optional

1 0

[Bug 265908] Re: Unsub instructions difficult to find
by Cedders 16 Apr '11

16 Apr '11

Here's a patch just for the English template that does what the reporter suggests ** Patch added: "Reformat listinfo template" https://bugs.launchpad.net/mailman/+bug/265908/+attachment/2043861/+files/m… -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/265908 Title: Unsub instructions difficult to find

1 0

[Bug 265908] Re: Unsub instructions difficult to find
by Cedders 16 Apr '11

16 Apr '11

+1 for this Also, related, unsubscribe could be prioritised in the options page once an email address is supplied. ** Patch added: "Hack to make unsubscribe via options page a bit more user-friendly" https://bugs.launchpad.net/mailman/+bug/265908/+attachment/2043827/+files/m… -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/265908 Title: Unsub instructions difficult to find

1 0