|
|
|
|
|
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. |
|
> "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.