unsubscribe removal confirmation should be optional

[Doolyo]

We should be able to choose if we want the members
that unsubscribe by e-mail to receive a 'removal
confirmation' e-mail. I need the user to not receive this
notice and just remove him without him knowing it.
However, we should still be able to sent him the
good_bye message when he left if we want it, like it's
the case currently.

The removal notice is not really necessary if people
receive an e-mail telling that they have been removed.
They can submit again if they want and report the abuse.

This option should just be an added tag that would be
valid for the whole list.

[http://sourceforge.net/tracker/index.php?func=detail&aid=1269025&group_id=103&atid=350103]

[Mark Sapiro (msapiro)]

I'm moving this to "Feature Requests" as it is not a bug.

[Doolyo (doolyo)]

Ok, thanks.

[uggtodoor (zhuangmali)]

Ugg boots are good. They have many advantages. One of the most important features is that they are very comfortable and warm. Sheepskin ugg boots are made. Because of the sheepskin, ugg boots are so soft and comfortable. For this reason, they are very fashion. There are most flat ugg boots, and we also have other styles of high heels.Wellcome to:
http://www.uggtodoor.com

[Cedders (cedric-gn)]

I think Sourceforge bug 1951777 <http://sourceforge.net/tracker/?func=detail&aid=1951777&group_id=103&atid=350103> 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.)

[Mark Sapiro (msapiro)]

Cedders wrote: #4

>I think Sourceforge bug 1951777 <http://sourceforge.net/tracker/?func=detail&aid=1951777&group_id=103&atid=350103> 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.

[Mark Sapiro (msapiro)]

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 <email address hidden> 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.