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.