Best Practices

Closed-Loop Confirmed Opt-In is the only method of email subscription management that provides actual proof of permission.

Why use a closed-loop confirmed opt-in system?

+ Because submission does not equal subscription. The single submission of an email address carries with it absolutely no proof of permission. Anyone can enter an email address through a web page or via email. Anyone can buy a "Millions" CD and flood your system with addresses. Anyone can sell you a list of unethically harvested addresses and say, "Sure, they're opt-in." Only closed-loop confirmed opt-in can prove that the address owner is the one who asked to be added to the list. If you're not using closed-loop confirmed opt-in, you're not a "permission-based marketer" -- you're a "submission-based marketer".

+ The unique, unguessable token stops forged "confirmation replies." If you're paying web publishers for co-registrations, any publisher could submit forged registration requests, then follow up by sending in forged confirmation replies. Since there is no unique token involved, all the scammer has to do is forge the "from" address of the email, the co-registration is completed... and you've just paid this sleazy scammer for an address that they unethically harvested off the Web, or which they bought for far less than the bounty they've collected from you. But if you use a unique, unguessable token, that token is sent to the submitted address, not to the scammer. If the scammer tries to forge a confirmation, it's rejected, since there's no matching token.

+ No one can be signed up for your list against their will. Unless the address owner gives others access to their email password, unauthorized addition of an address is virtually impossible with properly-managed closed-loop confirmed opt-in. If the address was submitted by an unauthorized party, the address owner just ignores the confirmation request. Instead of a series of spams arriving in their inbox, followed angry emails being sent to you, and/or abuse reports being sent to your upstream, your subscription server quietly and efficiently takes care of everything.

+ It'll elevate your status in the Internet community. And the community is well known for its vocal criticism of companies that have a reputation for spamming. The community is also known for boycotting spammer companies, and patronizing companies known to be "white hats." Never underestimate the power of good will.

+ It'll save you time, and time is, of course, money. No more arguing with addressees over whether they subscribed. No more bowing and scraping to your service provider when a spam complaint comes in. With closed-loop confirmed opt-in, you've got proof of permission.

+ It'll save you money, and money is... uh... money. Scammers can't rip off your co-registration network by entering unauthorized addresses. And you won't be unceremoniously disconnected by your service provider for spamming.

+ It'll keep you out of jail. Some states now have, or will soon have laws against unsolicited commercial email. If you have proof of permission, you won't have to have your head shaved, and become a gang member's... uh... girlfriend.


In a closed-loop confirmed opt-in subscription system:

1) The address owner — or someone else — submits a request, via email or a Web form, that the email address be added to a particular mailing list

2) In response, your subscription server generates a unique, unguessable token that is associated with the submission of that email address. This token might consist of a hash combining the date and time of the subscription request, along with the address itself... in addition to a secret key that will make the token truly unguessable.

3) Your subscription server records the submission info, including the date and time stamps, the email address, the name of the mailing list, the IP number of the submitting computer, and the URL of the Web form if one is used. If the request was received via email, the full, unedited email headers are stored in place of the URL.

4) Your subscription server sends a confirmation request email to the submitted email address. The request message contains the same info stored by your server: date and time stamps for the submission, the IP address of the requesting computer, the name of the mailing list, the unique token, and the submitted address.

5) The submitted address receives the confirmation request, and the owner responds to the confirmation request, returning the unique token to the subscription server — if the subscription request was valid. The address owner can easily complete the subscription by replying to an encoded Reply-To address, or by clicking an encoded link. Note that an automated reply — like a "vacation reply" or "out-of-office reply" or an autoresponder message is not a valid confirmation messages... even if the reply quotes the unique token. Methods employing a returned unique token also help avoid all issues of inaccuracy in the user's confirmation reply. If the address was submitted by an unauthorized party, the address owner just ignores the confirmation request, and the subscription server erases the original request data after an arbitrary confirmation period ends.

6) Your subscription server receives the confirmation reply, and completes the subscription process, first by comparing the returned token with the stored token associated with the originally-submitted address. If they match, the server then stores the complete headers of the confirmation email, along with all the usual info: date and time, unique token, and IP number. If the confirmation reply was submitted via an encoded URL, the URL is stored instead of the headers. Lastly, the submitted address is added to the appropriate mailing list. Optionally, a welcome message can be sent to the new subscriber. — If the confirmation is not returned to you from the submitted address, or the unique token is not present or does not match, then the subscription process is aborted, and no further email is sent to the submitted address. All record of the original submission is erased from the subscription server after some arbitrary period.


What else do you need to remember?

+ Mailing can begin only after a positive confirmation response. This is closed-loop confirmed opt-in... NOT "single opt-in" — which is actually "opt-out." If the confirmation is not returned to you from the submitted address, or the unique token is not present or does not match, then the subscription process should be aborted, and no further email should be sent to the submitted address. All record of the original submission should be erased from the subscription server after some arbitrary period. NOTE: Some administrators and users are concerned that even the temporary storage of the originally-submitted address could lead to privacy problems. It's been suggested that in addition to the IP number, plus the date and time stamps, only the unique token should be stored. If the token is a one-way hash the address will be protected from prying eyes. When the token-matching confirmation reply is received, the sender's address can be recorded from the email's From address, or can be retrieved from a value in the encoded URL.

+ The burden of proof of permission rests solely on the shoulders of the sender... not the recipient. If you can't positively prove that an address owner asked to be on your list, you don't have a right to send them email. Because of this, you must keep records of the original subscription request, as well as the confirmation reply, for the duration of the subscription.

+ Closed-loop confirmed opt-in practices eliminate "Spam Extortion Syndrome": "Either you reveal your email address to us, or we'll keep spamming you." Again: The burden of proof of permission rests solely on the shoulders of the sender... not the recipient. Remember, the recipient has absolutely no obligation — and probably no will — to surrender their identity or address to an entity that has already begun to abuse their trust through the sending of unsolicited email. With complete subscription records, you have actual proof of subscription. No more going round and round with users who don't want to — and shouldn't have to — surrender their email address.

+ Closed-loop confirmed opt-in is easy to implement. Even a hack (not hacker) scripter like the CM webmaster is able to cobble together a working system in Perl, in less than 2 days... including subscription and unsubscription via both web and email. Fulfilled subscription and confirmation data doesn't need to be accessed frequently, so your backend only has to deal with it two to four times (including unsubscription) over the life of the subscription. If you want to use a full eCRM solution, you'll probably be able to find a module that can easily handle subscription management, fully integrated with your existing database.

+ Closed-loop confirmed opt-in is easy for your subscribers to use. For a basic subscription, it's as easy as 1-2-3...  1) Your subscriber types in their address. 2) Your subscriber clicks "Submit" (or sends their email to your subscription server), and 3) Your subscriber clicks the response link in the confirmation email, or replies to your encoded response address. With those three steps, your closed-loop confirmed opt-in system has saved you and your subscriber lots of grief, saved you some coin, and possibly kept a state's Attorney General from sending you to The Big House.


How do you convert your mailing lists to closed-loop confirmed opt-in?

Just remove all addresses for which you have no closed-loop opt-in confirmation, as described above... Or, you can send a single confirmation request — with a unique token — to each address on the list. If the address owner ignores the message, just remove them from your list. If they reply with a confirmation, you'll have proof that the addressee really wants your mail, and you won't be forced to spend all that extra time dealing with spam complaints and avoidable privacy problems.

For more information on how to manage a mailing list responsibly, see:

http://mail-abuse.org/manage.html

Best of luck!