Wandering Thoughts archives

What modern email is good for

Suppose that you are creating a service today. What can you reasonably and sensibly use email for, given modern email principles?

My answer is that the only real use of email today is as a notification system: you send your users email to tell them that there is something waiting for them on your site (whether that is a message, a state change, or whatever). This is a bit extreme, but I think it's the necessary end result of the limits.

Since modern email is not reliable, you can't make email the only that you tell users about something; the chance that it will get rejected, dropped, or filtered is just too great. (And when this happens, it will not be the fault of your users for not carefully making sure that your email bypasses all filtering.)

So you need to give users a way to get at this information, such as through your website. Since you don't want to train your users to trust email, you don't want to send full copies of information by email; instead you want users to read it off your site using some captive communication system (one that is not susceptible to various sorts of spoofing attacks).

This winds up with the conclusion of 'email as notification system'. You keep the real information inside your system, and only use email to let users know about the existence of new messages et al. If a user's email system drops some messages, there's no big loss; the user will find out about these new things the next time they wind up on your website itself.

(It may be useful to aggregate these notification emails, so that the user is not barraged with a storm of them.)

Autoresponders in the modern email world

Given modern email, one may sensibly ask what the role of various sorts of autoresponders and other 'do things by email' things are. The simple answer is that they have no role; they cannot send email to people who have not asked for it, plus pragmatically, most of the email that they get will have forged sender information and be invalid.

Well, sort of, because the statement of the limitations also shows how you can get around them. There are two general approaches.

First, you can simply make your system never send email. Everything that it would previously have sent email for must be checked and handled at SMTP time and produce SMTP rejections, so instead of an email to tell you that your bug report wasn't formatted right, you get a SMTP rejection to that effect. This obviously only works for 'do things by email' systems that don't need to email people as a routine matter.

The second is that if you can only send email to people who have specifically asked for it, you simply need to have your system only accept email from people who have registered their email addresses with you. Since you can't send bounces, you have to do this check at SMTP time and refuse messages that don't pass it.

(This may still give the malicious a way to harass your users, but at a minimum it insures that you are not sending backscatter to random forged addresses. It follows that you should allow your users to opt out of this, so that if the malicious do start trying to harass them through this they can easily cut the email off.)

These two approaches can of course be combined; you might send friendly error messages by email only to registered users and do SMTP-time rejection for everyone else, for example.

(It is worth mentioning one bad combination explicitly: no matter how tempting it seems, you cannot send email to an email address just because it has submitted a validly formatted request.)

These are pretty strong rules, but I feel that they're what's necessary in a modern email environment.