Wandering Thoughts archives

On (not) putting IP addresses in registration email

If you are creating some sort of system that sends email to people in response to web-based requests, it is tempting to think that you should put in the IP address (and the timestamp) that the request came from, in case your services are abused. In practice this is useless, for a number of reasons.

The first one is that almost no one sends abuse complaints about spam any more, because people have long since worked out that doing so is almost always a waste of (their) time. If your system is used to spam people, they're just going to arrange to block you (in one of many different ways, often by clicking some 'report as spam' button).

Related to this is that what you are actually giving people is second hand evidence, and that is plain not very useful for abuse complaints. Imagine that you are an abuse department and you get a report that says, more or less, 'someone else sent me spam, but claims that it came from one of your IP addresses at this time'. Are you going to do very much with that complaint? Well, no, for all sorts of reasons.

(Also, let me gently point out that these days anyone who is going to use your system to harass someone with subscription requests is going to do it through open proxies.)

As mentioned before, one of the reasons that such second hand evidence is not very useful is that it has been faked over and over again by spammers themselves, because spammers just love to claim that they're not responsible for the spam, no, really. At this point such claims are probably more likely to appear in spam than they are to appear in real email, and certainly they give your email messages a certain smell.

So in short, including IP addresses is useless in practice and makes your email look kind of spammy.

Finally, there is an issue of responsibility. To wit: if your system can be used to spam someone, it is your responsibility to fix it and to deal with it, not the recipient's. It is your job to take precautions, to be unattractive to spammers and harassers, to track and block IPs, and if necessary to send abuse complaints to ISPs. If you're doing all of this right, putting the request's IP address in the email is unnecessary.

Putting the IP address in your email messages anyways sends any number of signals to people. None of them are very good signals.

(See this and especially this.)

Some suggestions for registration confirmation emails

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.

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

Marketing people absolutely love having an 'invite your friends' feature on your website, where your existing users can stick in the email addresses of their friends to have you send invitations to your service to them. Unfortunately, there are a number of problems with it that mean you can't have one any more.

First, if you provide any way to have user-entered text (even in the form of the sending user's nominal real name), spammers will exploit it. Second, even with no user entered text at all it is still going to annoy at least some of the recipients; in fact, you will be sending spam by the UBE definition, since it is email, it is unwanted by at least some recipients, and you will be sending it in bulk.

For the sake of both your reputation and your marketing, it is much better to persuade your users to send personal email messages from their own accounts. If you want to help them out (and increase the chance that they'll actually send the message), you can supply cut and paste ready messages that they can just dump in their mail client, with personalized links and everything.

Sidebar: the distrust problem

Merely having an invite-your-friends feature will cause some people to distrust you for reasons that boil down to 'the well has been poisoned by spammers'; too many untrustworthy websites have kept such email addresses and later used them for additional purposes (marketing, selling them as valuable assets, or whatever).

It follows that if Marketing absolutely forces you to have an invite your friends feature, you should under no circumstances actually keep a copy of these email addresses (or at least not a usable copy; use a hashed version for anti-abuse purposes). And you should have a clear and prominently mentioned policy about it.

(Do not say that it falls under your general privacy policy, unless your privacy policy is 'we never keep email addresses, we get rid of them right away'.)

Forwarding emails without false positives

Here is a modest suggestion for email clients: when you forward a message, you should put some marker of this at the front of the Subject: header. Similarly, if you are configuring your email client and you have a choice, you should set it up this way.

(Some but not all clients do this today.)

Many anti-spam systems that I've seen put a spam status marker at the start of the Subject: line; it's a relatively obvious place, and putting it at the start increases the chances that the users will see it (instead of missing it at the end of the line, or having their client not even show a specialized header).

(Also, there is the whole tradition of putting 'Re:' at the start of the subject line for replies.)

Now suppose one of your users forwards a spam-tagged message. This forwarded message is not itself spam (the obvious example is 'dear system staff, why did this get classified as spam?'), but if your client leaves the start of the Subject: header alone, the status marker is completely intact. Filtering badness is quite likely to occur. Putting the forwarding marker at the start of the Subject: line avoids this (and plays along with the existing 'Re:' tradition).

(Having written this I have to admit that my mail client currently isn't set up this way. I should fix that, but there always seem to be more important things to do than fiddle with the guts of my MUA environment, which is somewhat baroque.)