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

[Scott]

On Thu, Apr 23, 1998 at 07:10:05PM -0400, Ken Manheimer wrote:
| 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. 

great! what have you been working on?

| 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?  

no, i'm referring to the confirmation step with subscriptions that
i've implemented and posted a patch for as well as an ftp location of
the changed files.  did you see those yet?

|Are you basically saying, don't allow the option of unconfirmed
| subscriptions?  

i'm saying don't allow the option of unconfirmed subscriptions via the
web. and, if a subscription occurs with the address=<some address
other than the sender address> option that is implemented in the
patches referred to above, then require confirmation.  i'd like to
make it impossible for a person to subscribe some other unconsenting
person to a mailling list.  

this practice, believe it or not, is quite common at our site. every
day somone picks a victim's address and subscribes them to each of the
80-100 lists at our site with open subscription policies. that victim
then essentially gets mailbombed in a real bad sortof way.  i'd like
it if mailman made this impossible. i think listserv makes this
impossible by requiring all subscription requests to undergo a
confirmation request. 

| 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?  

the only reason i can think of is that people don't want subscribing
to involve two steps.  i don't personally find this valid given the
nature of folks to abuse such services.

| 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.  

when mailman hosts hundreds of lists on one machine, the accumulated
effect of the scenario described above can constitute an out of
service attack as well.

| 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.

that sounds like a good idea.  

scott