3 ms·
Email delivery over SMTP works on a store-and-forward model: when you send an email, it first goes to your outgoing mail server, which then connects to a mail s
by sveiss 14y ago
Email delivery over SMTP works on a store-and-forward model: when you send an email, it first goes to your outgoing mail server, which then connects to a mail server at the destination domain and sends the message to it. The mail server at the destination then has the responsibility of sending the mail on to the receiving user (perhaps it gets routed through a spam filter, then to a storage server to wait until the receiving user opens their mail client).
Because the source mail server forwards the message on, it loses control of it -- the most it could do is send a "please delete this message I sent you and forget I sent it" message to the mail server at the destination domain. The destination mail server wouldn't be obliged to act on it -- it could have forgotten where it forwarded the original mail on to, or it could instead decide to send a 'Hey! Look what somebody doesn't what you to read!' message in big flashing letters to the original recipient.
AOL and corporate mail systems can implement this because they control the destination mail servers, as well as the sending mail server. On the wider Internet, you'd need to replace SMTP with a protocol whereby the message is stored near to the sender, rather than near the recipient, until the destination user reads it. There are some good arguments in favor of a system like this (it could make spammers bear more of the cost of sending their spam, for instance), but uprooting a fundamental protocol and replacing it with something else isn't an easy task to do on a network as big as the Internet.
- csense 14y ago> uprooting a fundamental protocol and replacing it with something else isn't an easy task to do on a network as big as the Internet It's a bit of work, but relatively straightforward if anyone really cares about it enough to spend effort on it. Add a new message to the SMTP protocol that says "I have mail for you, but I'll only give you the headers right now. When the user opens it, you can call me back and ask for the content." If the target server doesn't understand the message, fall back to allowing the email to be recalled by implementing a delay. Publish an informal protocol spec before you publicly release any code; try to get it accepted as an RFC. Create an open-source reference implementation for the most popular open-source email programs -- mail servers, mail clients, webmail platforms. Get it accepted in the upstream of those projects. As people start using it, they realize it's really good and start to demand it of commercial implementations. As there's a published spec, the commercial implementations end up being mostly compatible with each other and the open-source work.
- nanijoe 14y agoSo what happens when I try to read the email and your server is offline? I'm now stuck with the header that says "Important - Respond Immediately" without any way of getting the content
- andrewhillman 14y agoThanks for the explanation. Why wouldn't GMAIL, YMAIL, LIVE etc... not want this "pull back" function within their own systems - start small. Then overtime, maybe the protocol could be revised making this function interoperable. Sometimes you just want to pull back an email and Gmails 30 second lab function is useless.