[Mailman-Users] Re: Passwords

[Ken Manheimer]

On Wed, 20 Jan 1999, Clark Evans wrote:

> WOW!  Very cool.   I'm off to play and try it out!

Great!

> [...]
> I'm sure you here this often, but I was just playing
> with the program on python.org, and you need 
> PASSWORDS?  
> 
> Can this be disabled?  I mean, the world has enough 
> passwords.  If some sick puppy wants to "unsubscribe" 
> me or change me to digest form, as a cruel trick, 
> then that's fine.  I'd rather take the chance, rather 
> than have to maintain _yet another_ password. 

What if you didn't actually have to remember the password?

In fact, you can use mailman to remember your password for you.  Any
time that you need it to, eg, make options changes or unsubscribe, you
hit the button on your options page that sends it to you.  It's an extra
step - but you always have the option of remembering the password, and
avoiding the step. 

One way or the other, though, some additional time/attention has to be
paid. I see this as being inevitable.  Why?  You might consider that the
cost to individual subscribers for mischief that can happen in the
absence of passwords to be low, but the real problem is one of scaling. 

Maillist administrators will tend to hear of each such incident, and
site administrators will hear about some of them.  Not much of a problem
when there are few members, but what about when maillists have hundreds
and thousands of members, and sites have many many maillists?  Small
nuisances become major, even crippling problems - the unregulated
scenario does not scale up.

Scalability is usually the underlying theme in the network
communications world. 

There are other benefits.  Things like confidence - you might not care
about missing a few messages on the classic cars mailing list, but you
want to be sure someone hasn't messed with your subscription to your
bosses' employee/projects updates list, etc. 

The upshot is that some energy investment is necessary to regulate
access.  The question is how best to balance the investment so it is not
too heavy, not too light.  (I've gotten complaints that the security is
too _lax_ - eg, passwords sent in the clear, via email.)  I happen to
think that the balance we've reached - mostly just what john viega
originally implemented, at least for the subscriber passwords - is
pretty well tailored to the needs. 

> 	Could the system allow signup with
>         an OPTIONAL password?

This is worth considering.  For the reasons i mention above, it's not
clear to me that it's a win.  I'm inclined to prefer to prevent
subscribers from taking the lazy way out, if it means avoiding serious
potential scaling nuisances for the administrators.

> 	By default, at the bottom of every message
> 	put a link the user's subscription page, 
> 	the current list archive, how to unsubscribe
> 	via e-mail, and, finally, how they can
> 	disable the trailer (/w option on 
> 	subscription page)

Another cool idea.  This is something that we probably would do but,
once again, scaling comes into play, big time.  The message transmission
mechanism batches together recipients for the sake of efficiency.  This
means that multiple recipient receive identical messages.  This can be a
big win for large lists, both in terms of system load and posting
turnaround time.  The redeeming thing is that subscribers can relatively
easily get to their subscription address from the listinfo URL, which is
included at the bottom of each message...

Ken Manheimer		  klm at python.org	    703 620-8990 x268
	    (orporation for National Research |nitiatives

	# If you appreciate Python, consider joining the PSA! #
		  # <http://www.python.org/psa/>. #