Hmm...

First, I take "opt-in" to mean simply that someone must ask to be added to a list (as opposed to simply adding them to the list despite their desires). What you are talking about, sending a message which must be answered is what most folks call "confirmation." That is, someone

Before everyone was on the net and we actually needed to be concerned about such things, the morphemes "OPT" "IN" never referenced e-mail. OPT-IN as a concept didn't arrive until we needed confirmation, ergo ...

purporting to be Joe sends a s ubscribe request, the list sends back an email to Joe saying please confirm, and if (and only if) Joe sends back the confirmation then he's added to the list.

OK, I've changed the subject to list confirmations.

I'm explaining this word usage in the hopes that it will help you search more effectively. That said, have you read the FAQ on this question:

http://www.hartzler.net/smartlist/SmartList-FAQ.html#Section_4.6

I have. I've looked at it. For my purposes, managing 40+ related mailing lists, the cure may be worse than the disease.

And how does this solution fall short?

I have a web page which allows people to go and subscribe to any or all of the lists. One submit button click and it's off to the races. If someone wants to be malevolent, they put in the address of someone they don't like and subscribe them to all of the lists. So, 44 "you have been subscribed" messages pop into the person's mailbox. These messages modulo the list name are pretty much identical, but that's OK, I might want to change them to be different some day. Since this person didn't want to be subscribed, they're eventually going to receive 44 "you have been unsubscribed" messages. There also going to receive the list traffic, which on the main list, averages 100 messages per weekday, much less for the rest of the lists. Still, if they're reasonably active in checking their e-mail it is possible for them to get subscribed and get unsubscribed before too much mail has been received. All of this happens because once you've been subscribed, all subsequent subscription attempts are ignored. Furthermore, the person to whom this happens to is likely to complain, at which time we add their address to the reject list and all subsequent subscription attempts, malevolent or not, get dropped on the mail room floor.

With confirm, however, every subscription attempt generates a new "do you want to be subscribed" message. This message will be sent everytime there is a press of a submit button. Hence, a malevolent force, with a few hundred clicks of the submit button will be able to send thousands of "do you want to be subscribed" messages to an unsuspecting mailbox.

Now, if the unsuspecting mailbox is one with a mail quota, somewhere about message 1000 or so, the receiving site starts bouncing the messages back to me, clogging my bounce queue. (We don't use SmartList's bounce processing either, only I can unsubscribe someone because their mail bounces.)

Let's assume the person recieving the messages complains to their service provider, or to mine. Prior to installing confirm, the'd be complaining about maybe less than 100 messages (before the unsubscribes hit), but after, with several thousand messages being delivered, it's going to sound to the ISPs like we're mail bombing, and they yank us off the net, thereby precipitating a unintended DOS attack to the rest of our community.

Since confirm operates before the reject list is checked, we're sending out the messages regardless of whether or not we know these people aren't initiating the request.

The cookie mechanism is primitive and susceptable to an unintended DOS simply be having the queue overflow from too many requests. (Since we're a technical support group, we frequently get mentioned in classes and on such days could receive dozens of subscription requests.) Hence, we'd have to up the cookie mechanism to levels which also make it impractical to deny a request due to the inavailablility of cookies.

Ideally I'm looking for something which would accept as arguments an e-mail address, an action and a list of list names and which would then generate a non-predictable looking key to store the request, send off a single message to the request address with sufficient information to re-generate the key buried in the message. A single response address would process the return request, verify the key data has not been changed, and then process the lists returned in the message.

...

You may edit the lists to which you wish to be subscribed. ...

------ LISTS TO BE SUBSCRIBED ----- ###ADD: peg ###ADD: dba ------ END OF LISTS ------

You must include this block in your reply. You may not edit it in any way or your request will be denied. ------ ADDRESS BLOCK ------ DO NOT EDIT OR DELETE ------ ###ADDRESS: someaddress@x.y.z.tld ###REQUESTED: Mon Sep 3 10:04:21 CDT 2001 ###REQUESTID: 22336 ------ END OF ADDRESS BLOCK ------

Now, if someone submits address x@y.tld and we're already waiting for a response from that address, return an error code.

If they request a subsribe and they're already subscribed, ignore that list. If they request an unsubscribe and they're not subscribed, ignore that request. (Hence, it would be good to be SmartList aware.)

Automatically delete any request which is more than x hours?minutes?days old.

When a response come in, process and then delete the request.

Now I'm unlikely to find the time to write this myself, besides we never write what we can beg, borrow or well, you know.

pegmgr@peg.com writes: ...

Still, if they're reasonably active in checking their e-mail it is possible for them to get subscribed and get unsubscribed before too much mail has been received. All of this happens because once you've been subscribed, all subsequent subscription attempts are ignored. Furthermore, the person to whom this happens to is likely to complain, at which time we add their address to the reject list and all subsequent subscription attempts, malevolent or not, get dropped on the mail room floor.

With confirm, however, every subscription attempt generates a new "do you want to be subscribed" message. This message will be sent everytime there is a press of a submit button. Hence, a malevolent force, with a few hundred clicks of the submit button will be able to send thousands of "do you want to be subscribed" messages to an unsuspecting mailbox.

If the problem is that the webpage acts as a 'magnifier' for malevolent forces (one HTTP request becomes 40+ mail messages) then I would say that the webpage would be 'at fault' and therefore that's where the DOS prevention should take place. That's not too hard: just keep a list of address, list, and subscribe attempt timestamp tuples, refusing attempts that would result in a duplicate address and list pair 'too soon' after the already entered one (also, update the timestamp when that happens). You also have the webpage keep an audit trail and include the trace information (originating IP, etc) in the subscribe request fed into smartlist, so that the 'target' gets a copy.

Note that it's the magnification of effect that makes something a DOS danger, the ability of the attacker to make the target perform N*M effort at only N cost to himself, be that in packet counts, CPU cycles burned, or email messages sent. An 'open' SmartList mailing list _without_ the confirm package is arguably just such a magnifier: one subscribe request generates a number of messages proportional to the 'busyness' of the list. With the confirm package, SmartList generates at most one message per message sent by an attacker. They can use SmartList as a 'reflector', but it neither magnifies the effect, nor does it hide their identity.

So, I think the confirm package makes SmartList _less_ of a DOS danger, not more.

Now, if the unsuspecting mailbox is one with a mail quota, somewhere about message 1000 or so, the receiving site starts bouncing the messages back to me, clogging my bounce queue. (We don't use SmartList's bounce processing either, only I can unsubscribe someone because their mail bounces.)

(Uh, "Doctor, it hurts when I do _this_")

Let's assume the person recieving the messages complains to their service provider, or to mine. Prior to installing confirm, the'd be complaining about maybe less than 100 messages (before the unsubscribes hit), but after, with several thousand messages being delivered, it's going to sound to the ISPs like we're mail bombing, and they yank us off the net, thereby precipitating a unintended DOS attack to the rest of our community.

Your contract with your ISP allows them to drop your connection without 24 hours notice, or at least contacting you first? Negotiate a better contract or talk to them about your concerns. There are real people behind the abuse@ address at your ISP and they're generally not sadists. I'm friends with one of the people that handles abuse@qwest.net and from the stories that she's told me they encounter enough "user error" to be properly cautious about making accusations. Turning off your connection costs them your business in the short-term, something no ISP wants to do (or right now, can _afford_ to do...).

Since confirm operates before the reject list is checked, we're sending out the messages regardless of whether or not we know these people aren't initiating the request.

Didn't someone recently assert that this isn't true? I haven't looked myself, so I don't personally know whether it does or not.

The cookie mechanism is primitive and susceptable to an unintended DOS simply be having the queue overflow from too many requests. (Since we're a technical support group, we frequently get mentioned in classes and on such days could receive dozens of subscription requests.) Hence, we'd have to up the cookie mechanism to levels which also make it impractical to deny a request due to the inavailablility of cookies.

Sounds like a simple matter of programming.

Ideally I'm looking for something which would accept as arguments an e-mail address, an action and a list of list names and which would then generate a non-predictable looking key to store the request, send off a single message to the request address with sufficient information to re-generate the key buried in the message. A single response address would process the return request, verify the key data has not been changed, and then process the lists returned in the message.

...

Now I'm unlikely to find the time to write this myself, besides we never write what we can beg, borrow or well, you know.

It appears that nothing exists that meets your criteria. You therefore have the choice of either

a) writing it yourself b) modifying an existing package c) praying for someone to do it for you d) doing without

I haven't seen anyone leaping forward, so (c) seems unlikely to work.

Philip Guenther