what to do with confirmation of web based subscriptions
proposal concerning web based subscriptions:
*allways* use confirmation, even if the list doesn't require them via email.
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.
it seems that as mailman becomes more widely used, more and more lists will have a problem with this.
comments?
Scott Cotton IC Group Inc
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
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
On Thu, 23 Apr 1998, Scott wrote:
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?
Just some small things - a fix to the admin option help mechanism (and displaying the current option setting like on the regular options page - instead of 0/1/2 values for enumerations, you see the setting names on radio button with the right one checked - trivial, i know, but much more civilized...) I've forgotten what else - nothing big, but i'm starting to get a feel for some of the big pending things.
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.
Yikes. I'm convinced.
| 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.
More later.
Ken
"S" == Scott scott@chronis.pobox.com writes:
S> i'd like to make it impossible for a
S> person to subscribe some other unconsenting person to a
S> mailling list....while still allowing someone to subscribe to a list using a perfectly valid alternative address. Scott, I haven't seen your patches, but I know that other ML managers handle this in a useful way. They will send a confirmation email to the alternative address that contains a partially random string. The user need only reply to the message and include verbatim this string.
This seems like a small hurdle to impose given the important nature of this defense. A small explanation included with the email (along with a link to a detailed Web page) would go a long way to easing any inconvenience.
S> the only reason i can think of is that people don't want
S> subscribing to involve two steps. i don't personally find this
S> valid given the nature of folks to abuse such services.I highly agree!
-Barry
On Mon, Apr 27, 1998 at 11:07:15AM -0400, Barry A. Warsaw wrote: | | >>>>> "S" == Scott scott@chronis.pobox.com writes: | | S> i'd like to make it impossible for a | S> person to subscribe some other unconsenting person to a | S> mailling list. | | ...while still allowing someone to subscribe to a list using a | perfectly valid alternative address. Scott, I haven't seen your | patches, but I know that other ML managers handle this in a useful | way. They will send a confirmation email to the alternative address | that contains a partially random string. The user need only reply to | the message and include verbatim this string.
that is exactly what the patches do. there's still some problems synching the patches with the distribution, but this functionality is what my copy of mailman is doing right now.
| This seems like a small hurdle to impose given the important nature of | this defense. A small explanation included with the email (along with | a link to a detailed Web page) would go a long way to easing any | inconvenience.
it's all there, except the link to a web page, which sounds like a good idea.
thanks for the feedback.
scott
participants (4)
-
Barry A. Warsaw -
Ken Manheimer -
Scott -
Scott