[Mailman-developers] administrative unsubscribing

[Ken Manheimer]

On Sat, 11 Apr 1998, Scott wrote:

> it seems to me like list admins need a more efficient way to
> (mass-)unsubscribe members than going through them one at a time the
> same way that a list member would unsubscribe them.

This is something i've also had in mind.

> some ideas for the interface are:
> 
> have the mass subscibe box simply full of a list of all subscribers
> and be able to edit it directly.

And do some kind of differencing approach, where members that you
deleted from the list are deleted, and members that you added are added?
My thoughts have been tending to the next option...

(I should note that there's another mechanism for doing mass
subscriptions which i came to rely on for transferring over my existing
lists - mailman/bin/populate_new_list turns out to work better for me. 
In either case, you have to be careful to clean out extra stuff from the
entries - you can't add "klm@python.org (ken manheimer)", for instance.) 

> under member management administrative interface, list all the members
> with a checkbox allowing the adminstrator to unsubcribe people one
> click at a time.  

I would have a table with an entry for each member, including their
address and some check buttons, one to disable delivery, one to
hide/unhide them, and one to unsubscribe them completely.

There's one nuance that i think should be accounted for as well, which
makes the setup slightly more elaborate than just that.  I think this
interface *should* include the members that have set the concealment
option for their subscription.  However, that means that this interface,
itself, should be accessed indirectly from the membership management
page, via something that requires the administrator password.
Otherwise, non-administrators could visit the admin pages and get to see
the concealed folks...

This reminds me of a somewhat related area that really needs work - the
subscription mechanisms are too basic, at the moment.  There are two
missing features - actual confirmation of subscription requests
(currently that's finagled around), and subscription of forwarding
addresses.  Let me explain...

I've had several requests from subscribers to be able to change their
subscription address.  Makes sense to me, but it so happens that the
current mechanisms for preventing mischievous third-party subscriptions
are not up to this.

New web-based subscriptions addresses are "confirmed" by prompting an
email subscription sent from the subscription address.  Well, that's not
really confirmation - the web-based subscription attempt isn't recorded
or anything, it just prompts the helpful message desribing how to
subscribe, basically.  Well, i don't think we can use the same trick for
subscription address changes, because the old address needs to be
removed, as well as adding the new one.  And we can't rely on the
password for the old address because that doesn't vouch for the
authority over creation of the new address - ie, someone could subscribe
at their real address in order to get a password that would allow them
to subscribe an arbitrary address of their choice.  No good.

In particular, there is no confirmation tracking done - no database of
requests to be resolved against confirmations.  We would need something
like that to do the subscription transfers, i think.  Or at least, i
think that would be the right way to do it, particularly since such a
mechanism would enable the other big, lacking subscription feature - the
ability to subscribe a forwarding address.  Ie, some people have a
forwarding address at acm.org, but no actual logins there.  They would
like to be able to subscribe that address, but the current mechanism
doesn't allow it - it is constrained to the sender/from fields, because
there is no actual confirmation going on, just identification.

Anyway, these are some issues i'm hoping to tackle and or yield to
others...

> are there any other ideas for how to do this?  if there is a consensus
> on whether this feature should be added and what the interface should
> look like, i'll add it to my list of things to implement and get
> startted next week.

Cool - the membership management stuff is one of the things i had on my
list!

Ken