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