Hacker News new | ask | show | jobs
by cliveowen 4375 days ago
Frankly I've never understood why email doesn't work this way, it looks backwards to me. As long as the recipient hasn't read the email the sender should have the right to delete it. Even if the client has already delivered the email in the recipient's inbox there should be a way for the SMTP/IMAP server to notify the client and remove it.

Even Whatsapp works this way: once you've sent a message, you can't unsend it. The message is first relayed to their servers and then relayed to the client, but even if the recipient isn't online and the message is only on the server, deleting it only removes it from your conversation. You'd think that in 2014 we would have addressed these kinds of flaws.

5 comments

But see, that all falls apart when you say:

> "there should be a way for the SMTP/IMAP server to notify the client and remove it."

As long as the protocol requires the client to obey a command to delete, it's not going to work.

With such a protocol, nothing is stopping me from choosing to disregard any messages to delete already received (and downloaded) messages. In fact, I'd probably have the client highlight them for me if they got a "delete this" request. There's probably something good someone is trying to hide in that message.

If I recall correctly, Twitter had a similar issue with their API. They have a method to delete a Tweet, but the Twitter client has to honor the delete client-side since it has a cache of tweets it has seen.

Of course, in a closed environment like Twitter, Twitter can choose to revoke a non-compliant client's API keys if they don't follow the rules. Not so much with email.

> Frankly I've never understood why email doesn't work this way

Because internet email is mostly designed as a highly fault-tolerant low-trust network, so the basic design is unauthenticated forwarding, so once its sent, there's no generally-applicable way to prove that you are the sender to ask for it to be deleted. Inside something like a particular Exchange server, email can be implemented that way (and basically is), and that works because its a single centralized database with client authentication.

Outlook/Exchange does allow emails to be recalled - but I think this only works within the same Exchange organisation.

It is weird to see an email sitting in your Inbox disappear as you watch!

It seems to vary though; you can configure Outlook to not obey message recalls, although that might be at the discretion of an admin group policy. Either way, my last DoD network allowed you to avoid deleting emails based on recall requests, which was a very nice feature (or policy omission, not sure).
> Frankly I've never understood why email doesn't work this way, it looks backwards to me.

It's (also) a privacy issue as it discloses when one of the recipient has read the email.

Dodgy to be reaching into my machine to suit you, the sender. Possession is 9/10 of the law or something.
1) Possession is 9 points of the law was the original quote - it's just been bastardized over the years.

2) If it's "okay" for your machine to receive and keep the misdirected email message, how is it "not okay" for someone sending a correctly directed message asking your MUA to remove the message? Your MUA allows the behavior; you allow it by use of that MUA; no access control mechanisms were broached. To look at it literally, all email is "reaching into your machine to suit the sender".

> Possession is 9 points of the law was the original quote - it's just been bastardized over the years.

Its not that much of a bastardization, as a modernization -- the original seems to have been "possession is 11 points in the law (and they say there are but 12)", which was decimalized from 11 and 12 to 9 and 10, sometimes used with the "9" alone and the last part omitted, and later simplified to 9/10. The original sense of the statement is preserved, which is why I wouldn't call it a "bastardization".

Same way its ok to give me something, but not to take something from me without permission.