How to "un-send" email.

It is a fact of modern life that you can't unsend email. The problem is that to really unsend email you need a time travel device.

It's a shame, really.

MS-Exchange has the ability to send a request that will hide the email, but most non-Exchange providers don't support the protocol. Besides, the horse has left the barn. You can't put the toothpaste back in the tube.

Gmail has the ability to unsend an email if you sent it in the last 10 seconds. Useful and cute, but not awesome. (Awesomer is their "prove you are sober before sending a message" feature.)

One way to mitigate this risk of wishing you had an "undo" is to send out a first paragraph plus a URL to the entire message. This way you can rewrite, refine, and update the body of the email as much as you want.

We use this technique at work. Suppose we want to tell people that the printing system will be down on Thursday evening so that we can upgrade the print server software. We put the basic message in a 1-paragraph email, and list a link to a document with more info. The link might be to a ticket # that tracks the issue, or a blog post (yes, we have internal blogs), a web page, or a document. We can constantly update the document over time.

Maybe we should extend this. All email should be a subject line plus a URL to the actual message. Made a typo? Correct it. Regretted what you said? Delete it. Called your boss an asshole? Change it to be a loverletter.

You still need to get the subject right, but the message can change. Maybe we could invent a way for the email to be "frozen" once the person reads it (one way would be for the email client to cache the message once it is downloaded). Spammers would have a harder time spamming us, since we'd be able to track their message back to their web site and therefore identifying them would be, well, if not easier, differently harder.

Or maybe we shouldn't even send email. The user interface would still look the same. Behind the scenes it would just be sending URLs.

Usenet made this transition. Usenet was replaced by RSS feeds, which are just lists of URLs. Maybe email should make the same change.

Posted by Tom Limoncelli in Ideas

Comments (5)
Tweet

5 Comments

Paul Coen | March 14, 2010 1:23 PM

At least as of Exchange 2007, the user had to be on the same Exchange server for this to really work well, and the recipient knows you tried to retract something, including the subject line of the message.

GroupWise actually has a full retraction feature - it just removes the message silently, and it at least works across post offices.

If you look at the way that any SIS email system operates, it's not vastly different than using URLs against some central repository. I'd be concerned, though, with security, and the possibility of misdirecting a "client". Can't say I've been overly impressed with the "state of the industry" on that front in the past few years, and I'm not sure things are improving.

Also, the notion of keeping the message on the sender's site means that messages just vanish after a provider or company disappears or changes its infrastructure. Document retention rules might dictate keeping a local (recipient's) copy anyway, so it would have to be pulled down, and again that could be used to leverage a security vulnerability.

The only way to avoid that issue would be to have a giant virtual SIS mail system that everyone was using. That would be a really terrible idea on a number of levels.

Daniel Howard | March 14, 2010 2:28 PM

I like the idea of doing maintenance and outage announcements via "call by reference" . . . we have a similar practice in my office.

Cisco (my employer) has a "secure sender" service which provides central management for identity and cryptography: you send a message through the web site and the recipient receives a link to an HTTPS URL. No idea if you can revise a message, but such a practice could allow you to know if and when your message was read easily.

Instead of making users click on links though, since most e-mail clients these days have some degree of support for web technology, you could make your HTML multipart do a JavaScript call to retrieve the most recent message version. You would have to make provisions for graceful degradation, and you would want minimal latency on that JavaScript refresh.

Sounds most doable to implement for web-based senders. Probably already patented by some jackass.

-danny

Juergen | March 14, 2010 2:58 PM

There's a major flaw in your idea... it would make email useless for any kind of legal transaction.

A fax cannot be unsent unless you send a burglar or arsonist to the recipient. Therefore, judges consider a fax to be legally the same as a letter.

An email can be considered as binding in some countries if it has been cryptographically signed - but by giving the user the ability to change the email afterwards ("turn it into a loveletter") you'd remove that chance. You'd be able to send an email ordering something - only to change it into something else once the item is shipping... NOT GOOD.

Phil P | March 14, 2010 5:16 PM

The new email protocol sounds a lot like one of DJB's proposals from years ago.

This looks like the beastie: http://cr.yp.to/im2000.html

AR Keen | March 14, 2010 5:24 PM

I've seen email/web hybrid systems like Daniel's employer's "secure sender." One use case is enforcing document retention policies in industries with regulatory compliance concerns.

I think it works well when doing newsletters, bulletins, service alerts, and other one-to-many, one-way communication channels.

I think there are some major technical problems with implementing a web-pushed email.
1) It requires constant, always-on Internet access to read messages. Allowing a client to fetch the content of URLs for offline reading removes your ability to transparently re-edit.
2) Unless you disable Copy+paste/Save Document/Print you can't ensure that the most recent copy is the only copy.
3) Your revise/reedit/revoke window is only open from when you send it to when the first client reads the URL sent.
3) Browsers are not good email clients.
4) How do you file/sort/tag/label email?
5) It makes spam harder to deal with. Instead of passing a message to the server that can be processed, you have to check a blacklist or fetch the URL to process. There's no guarantee that a fetched URL is going to stay in the same state once scanned.
6) Botnets, rogue ISPs, unmaintained web forums, unpatched and exploited web apps could all be targets for web links for spammers, making maintaining a feasible blacklist untenable. SURBL provides the same anti-spam functionality that a web-transport mail program would. It's a great tool, but I wouldn't want to rely on it exclusively for spam control.
7) Access control: How do you ensure that your recipient is the only one who reads the web link?

Personally, I feel that a immutability of email is a feature, not a bug. Given some of the problems that I've seen arise on web communities that allow transparent reedits, allowing the content of messages to change could significantly damage the ability of email to serve as an effective communication mechanism.

Awesome Conferences

5 Comments

Best of Blog

Navigation

Recent Entries

Search

Archives

RSS Feed

Credits