Chris's Wiki :: blog/spam/RegistrationEmail

Some suggestions for registration confirmation emails

September 27, 2009

As a practical matter, I think that registration confirmation email should have at least three characteristics:

it should always be initiated by that user; there should be none of the invite-your-friends features that are beloved by marketers.
(Yes, I'm completely serious about this.)
it should not have any user-entered text whatsoever. Any user entered text will be exploited by spammers, and you don't have any need for it anyways.
it should be devoid of marketing material in general. No 'thank you and welcome to <X>, the best place in the world for <Y>' or the like. Imagine that you are the most paranoid anti-spam person in the world getting this email, and try to make it so that it is not even possibly marketing anything. You can put all of that stuff in the email that they get after they confirm their address.

Hopefully it goes without saying that you should rate-limit the amount of registration confirmations that you'll send to any one email address. Since people's anti-spam systems do eat email, I think that you should allow a couple of repeats more or less immediately but then start backing off. Do tell the user about it, because if you've done your job well most of the people running into the rate limit should be real users having email problems.

(More sophisticated systems are possible and probably friendlier. For example, you might notice when messages bounce and allow faster retries for that.)

Per AutosendExcludeAddresses, putting the IP address that submitted the request into the confirmation email does nothing to make people feel better about you, and may even make you look more spammy. The real cure is to take steps to block abuse to start with.

Comments on this page:

From 206.168.172.26 at 2009-09-28 11:19:27:

I agree entirely with your three characteristics. The avoidance of anything that even has the whiff of marketing in registration confirmation requests is especially crucial.

I think you're not quite right about not including the IP address from which the request was submitted. Saving the victims of forged requests the hassle of asking you from where the attack was launched will put them in a better mood when they're being subscription-bombed, which means they're less likely to summarily blacklist your IP range.

Finally, one thing you're missing is providing advanced notice of the sender address from which the confirmation will arrive. The registrant can then use that to put in whitelist entries when they're on a mail system that uses such protection. As a corollary to that, the sender address needs to be consistent and simple. You need to use it for both envelope and From: line, as most users will never understand the difference. A simple "we will send you a confirmation email message from ..." is sufficient, and highly appreciated.

By cks at 2009-09-30 02:22:58:

I strongly disagree about including the request IP address, for reasons I just wrote down in WhySourceIPsAreUseless.

Written on 27 September 2009.

«	Why you can no longer have an 'invite-your-friends' feature

What I think about why graphics cards keep being successful