[Mailman-developers] what to do with confirmation of web based subscriptions

Ken Manheimer klm@python.org
Thu, 23 Apr 1998 19:10:05 -0400 (EDT)


Hi, all.  I'm finally getting my head back to the surface after
returning, and starting to catch up on some of the mailman comments and
developments.  I also have some new items of my own to throw in the mix. 

On Wed, 15 Apr 1998, Scott wrote:

> proposal concerning web based subscriptions:
> 
> *allways* use confirmation, even if the list doesn't require them via
> email. 

I'm a little confused about what you're saying.  By "even if the list
doesn't require them via email", are you referring to the admin approval
option?  Are you basically saying, don't allow the option of unconfirmed
subscriptions?  

If so, i'm not sure what i think of this.  I can see how it would
usually be the right thing (tm) to require some kind of confirmation -
currently either email from the user or administrator approval. To some
degree, allowing unconfirmed subscriptions can amount to being a bad
neighbor.  It reminds me of the gun debate - how much should we protect
people from each other.  ("Guns don't kiss people, people kiss people."
Or something:-)  I guess the question is, are there valid reasons to
have lists that take wholly unconfirmed subscriptions?  If we're
confident there aren't any lurking around the corner, then fine, lets
close that door.

> If you don't, it's a security hole for any mailing list that doesn't
> implement it, and for out of service-attacks against the system
> mailman on which mailman is running.  Even if a list is not advertised,
> it is still vulnerable to this, as an "attacker" could well find out
> the name of list by other means.

Well, it does occur to me that a list that allows unconfirmed
subscriptions but also requires membership for posting privilege would
not be susceptable in the simple way to denial-of-service attacks.  

Along related lines, it does occur to me that we should prevent mail
loops, where either the list is subscribed to itself, or where some
reflector loops back to the list.  (The former situation was hinted at
this afternoon, when someone accidentally specified the matrix-sig as
their address for subscription *to* matrix-sig list; all it did was post
the subscription instructions to the list, but it would have subscribed
the list to itself if there was no confirmation...)  What i'm doing is
adding a header, "X-BeenThere: <listaddr>", which will be detected and
cause a hold of the message for approval, if encountered.

Ken