Will Expiring Email Go Anywhere?
Josh Baer, who works for Datran Media and founded OtherInbox, has recently proposed creating an “X-Expires” header to allow the sender of a message to have the message deleted at a predefined date and time.
Others have already made most of the arguments against it. Scanning stored email is an expensive process, using up both disc and processor cycles. Spammers will use the mechanism to expire messages before enough users can complain to cause their mail to be blocked by complaint-based reputation systems. And one commenter on The Magill Report said he’d create a filter to expire messages with an X-Expires header immediately, rather than storing it at all.
But that’s not all. Many companies have strict email retention policies imposed by regulation or concern over legal liability. If they went into a courtroom and tried to explain that they deleted evidence because of an experimental email header, they’d be laughed out of the room.
And of course, there’s already an Expiry-Date: header for email, first described in RFC 1327 in 1992 and further in RFC 2076 five years later. Similarly, DKIM includes a way for signatures of messages to expire: when a signature expires, the message can no longer be authenticated, and thus it can no longer be trusted, and thus (in theory) it should be deleted. Either of these options could be available now, without creating and marketing something new — except that nobody’s implemented them.
Baer dismisses these concerns, and likens it to the “List-Unsubscribe” header he published in 1998, the use of which has since become a best practice for both discussion lists and marketing email. He claims that everyone thought List-Unsubscribe was a bad idea back then, and we’ve changed our minds, so we’ll change our minds on this one too. But there’s a bigger difference here.
Including a List-Unsubscribe header is an action of giving. It gives the user information they might not have been able to find easily otherwise. It gives the mail client software a standardized place to find that information, so it can be presented it to the user in an easy, comfortable, predictable way. It is an inherently friendly act.
An expiration header would be a request, even a demand. It tells the mailbox provider that they are expected to do something they were not expected to do before. It takes control away from the recipient: opt-out, rather than opt-in.
This directly contravenes one of the core philosophies and practices of Internet email: once a message has been delivered, it’s done. The recipient owns it, controls it. Nobody can do anything else to the message without the recipient’s participation. This isn’t just something people say — it’s actually designed into the POP and IMAP protocols used to transfer messages from the mail server’s storage to the client, and is thereby built into users’ expectations.
When your computer or mobile device beeps to say “you have new mail,” you can decide for yourself whether to check it right away — but you expect, and the sender expects, that when you check your email you’ll see that message. You know, without question, that if you don’t delete that message, you can come back later and it’ll still be there. Users never expect that a message they thought was safely stored could suddenly disappear — and they get very upset if it does, as we saw recently with Gmail.
This is the primary reason why so few mailbox providers have adopted Joe St. Sauver’s 2006 proposal (PDF) that malware and phishing messages should be removed after delivery, even though everyone agrees that’d make users slightly safer. It’s a better user experience to warn them not to open it rather than having it disappear without notice.
There are also users who think that email expiring on a set schedule is a great idea. They say that server notifications intended for system administrators should automatically disappear when they’re no longer current. Same with marketing messages, Facebook notifications, et cetera — all the things that may be relevant in the moment, yet become decreasingly so over time. Meanwhile, other users say they prefer to keep messages about sales and promotions around for a while, so they can call and complain if it turns out they didn’t get the promised sale price.
What these diametrically opposed requests have in common is that users are asking for more control over their inbox. They aren’t asking for someone else to take email away from them; they want it to go away when they want it to go away. (They may also want a pony.)
As Clay Shirky said recently at a conference, what our always-connected society is experiencing isn’t information overload; it’s filter failure, or perhaps more of a shifting of responsibility. Publishers of information used to have to filter out the uninteresting and irrelevant materials to keep costs down; on the internet, and particularly in email, cost no longer creates that pressure. Publishers aren’t filtering, so the recipient of all of that unfiltered information feels overwhelmed — unless they can filter it themselves.
The filters available to end users in either desktop or webmail clients haven’t evolved much since the earliest versions of Outlook and Eudora. They’re applied when a message is downloaded, or can sometimes be run manually later. Automatic, periodic cleanup is clunky at best. None of the innovations of modern spam filters have trickled down. Compared to iTunes Smart Playlists, email filters are still in the dark ages. Even when they’re available, most people don’t know how to use them.
Better filters would give users something new, something that delights and empowers them — and it would solve their need for irrelevant mail to go away, without taking away their ability to control their own inbox.