More Sender-Stored Email

I was thinking about sender-stored email again. It occured to me how you could throw away SMTP and implement a whole new protocol pretty easily. The idea is partly inspired by OpenID.

It's also inspired by the fact that, instead of an email address, I've been using a URL for a number of years. If you want to send me email (and I don't know you) you go to that URL and fill out a form.

User A at Site S wants to send email to user B at Site T.

Previously, A@S would send email to B@T. It would go to an outbound email server at Site S, then be relayed to the exchange server for site T, then perhaps relayed through multiple servers inside T's location, until finally it was delivered to an inbox on an email server. At some later point, Users B would read their email and retrieve the message from the inbox.

In the new scheme, user B doesn't have an email address per se. They simply have a URL. It can be some arbitrary URL or such as http://b.email.myplace.com, or some generic email site like http://b.email.com, or a corp address maybe like, http://x.corp.com/eng/b.

Now, when A sends email to B, A's client simply POSTs a message to the URL using HTTP. The message contains these fields:

• From - The sender's name and possibly return URL
  
• (optional) To Name - Who the message it to.
• Subject
• Message URL - The URL of the message we are sending

This brief information goes into T's ``inbox.'' This is the only information required to be stored on the recipient's site. This inbox can be a simple table of data.

To read the message from A, user B accesses the URL in the message. This allows retrieving the email message with all of its headers. I've listed them before but here are some of the immediate advantages.

• The recipient immediately knows who the message is coming from (because they get it from the source site). Based on the URL, if they decide it's spam, they can choose not to read it.
• The message doesn't travel over the network until the last minute, when it's read. It efficiently travels directly to the recipient and completely under the recipient's control.
  
• The message is stored once by the sender A.
  
• However, the recipient does have the option of keeping their own copy if they want to.
• Any attachments are naturally additional URLs to retrieve them. The recipient can verify if the attachments are from the same site or not.
• Encryption is easy: (HTTPS).
• Authentication of the recipient is easy (B has to sign into A's site).
• This uses existing protocols and infrastructure. Most work is done by web servers.

And there's this big advantage.

There's no message store-and-forward or routing. The recipient's address is a URL and the sender connects to it directly.

The only new software required here is two pieces. There is the software that is posted to and that displays a list of messages. There is also software on the sending end that allows the sender to compose an email message. Then when they send it, the message is put up on the web server (for retrieval by the recipient) and that address is then sent.

Of course, it's possible to write email clients that do all of this behind the scene and make the email-reading experience completely indistinguishable from what currently happens.

Now look at what Site T needs in order for it's occupants to recieve email. In the current implementation of email, the site needs massive amounts of storage to handle all of the messages that arrive on an hourly basis. Messages are stored seperately (sometimes) for each recipient.

With the new scheme, Site T could simply give each user a browser and would only need to store a table of received messages.

This idea could easily be phased in along side existing email and with a bit of coding, it could be done transparently to the user. The cost savings and efficiency gains would be huge.

References: My previous Email Ideas posting and