Annon Inglorion/Documents/Designs/emsg/

emsg

Robbert Haarman

2006-05-07

Notice of Deprecation

Important note: It turns out that the idea behind emsg has already been standardized in the message/external-body MIME type, described in RFC 1341, with the URL access method being added in RFC 2017. As these documents precede emsg, the mechanisms they describe are more general, and implementations of these RFCs are more widespread than implementations of emsg, I will do no further work on emsg, and refere interested parties to the message/external-body MIME type instead.

Introduction

emsg, short for electronic message, is a modification to email that reduces the damage done by spam, as well as making sending spam less attractive. The basic idea is that the messages are kept by the sender, and only a link to the message is actually transfered to the recipients. This reduces the network traffic and storage space that is wasted when messages go unread, and facilitates sender identification.

Justification

Bulk email uses a lot of bandwidth and takes up a lot of storage space on recipients' servers. All these resources are essentially wasted in case the recepient decides not to open the message, which is what happens to many unsollicited messages. Also, the original sender of an email is sometimes hard to trace.

emsg solves all these issues by keeping the message at the sender's side. Recipients are only sent a reference to the message, which saves space and bandwidth. Moreover, the server the message was sent through can easily be identified.

Specification

A new MIME type is defined (text/x-emsg for now). This type specifies a reference to a stored message. References consist of a line of the form

uri URI

specifying the location the message can be fetched from, for example, an HTTP URL. Later versions of this specification may specify additional fields.

It is recommended that emsg references in emails be accompanied by a textual, human readable explanation telling users of non-emsg-aware mail user agents where to fetch the message. An example emsg in email could be:


To: fred@foobar.com                                                             
From: j.r.hacker@2600.com                                                       
Subject: Example                                                                
Content-Type: multipart/alternative; boundary="bbboundarybbb"                   
                                                                                
This is a multi-part message in MIME format.                                    
--bbboundarybb                                                                  
Content-Type: text/plain                                                        
                                                                                
This is an emsg. You can fetch the original message by going to                 
http://2600.com/~j.r.hacker/emsg/132890574023859                               
For an explanation of what emsgs are, go to
http://inglorion.net/documents/designs/emsg/

--bbboundarybbb                                                                 
Content-Type: text/x-emsg                                                       
                                                                                
uri http://2600.com/~j.r.hacker/emsg/132890574023859                            
--bbboundarybbb--

Comments

...

Posted by Guest

at 2006-04-20 11:35:18

Hmm. I can see the 'point' about the bulk thing... generally, bandwidth and space would be saved. However, I feel there would be a general security risk overall. It also causes problems with IPs/domains as everyone would have to go static.

Let's assume we've built a prototype. We've got 2 boxes running this 'emsg' program (client/server). Box #1 sends a message to box #2 (assuming it knows the right IP) with some data say... "box.1?box.2?emsg/msg1" ... then box #2 receives it and the message would be in a format like:

"To: box.2 (192.168.1.5)

From: box.1 (192.168.1.8)

URI: http://192.168.1.8/emsg/msg1"

... then they just visit the message via HTTP. 1) There's nothing to stop the box #1 'HTTP server' being malicious. 2) There's nothing to stop a possible box #3 visiting the same URL. Even if checks were put in place, it could all be spoofed.

So, looking at your idea raw, as it is now, it's a bit... unwise. One improvement would be a switch from HTTP to a new type of protocol... it may be possible for some check to be implemented, where the box.1 server knows that /emsg/msg1 is for box.2 only, then when the request comes in to view the message, it can somehow ensure that the viewer is box.2... maybe if there was a central database kept somewhere? Again, you can't just place programs on peoples computers e.g. a program to listen on port 54 like a DNS server that says "yup, I'm box.2" because they can be faked.

If you go and have a think on your ideas, it might be interesting to see you release a 'revised' idea?

Reply to this message

Re: ...

Posted by inglorion

at 2006-04-27 08:09:04

Thanks for your comment, and apologies for taking so long to reply. The motherboard in my desktop machine broke down, which disrupted my workflow a bit.

I think you should know that I see emsg more as an interesting idea to explore than as the Final Ultimate Solution to Spam. However, your comment shows that at least some people see something in it, so perhaps it's worth the effort of identifying and solving the issues that come with it.

Addressing the points you made:

> It also causes problems with IPs/domains as everyone would have to go static.

Why would that be the case?

> 1) There's nothing to stop the box #1 'HTTP server' being malicious.

Indeed. No more as there is anything to stop a mail server from being malicious. Keep in mind that the idea behind emsg is to make messages more traceable. By storing them on a server associated with the sender instead of one associated with the receiver, we gain insight in who is approving the sending of these messages. If that server is malicious, we know that _that_ server is malicious, whereas with SMTP, the issue is less clear.

> 2) There's nothing to stop a possible box #3 visiting the same URL.

True. And it should generally be that way; at least I would want to be able to check my mail from any machine I happened to be using. Of course, what you are concerned about is privacy, and there you have a good point. However, there are a couple of things to observe here.

First of all, in some cases you might actually want a message to be publicly accessible. Secondly, there is no prescribed mechanism for generating these URLs. It's probably a good idea to make them hard to guess, and perhaps some information about the intended recipients should be encoded in them.

Thirdly, not a lot of privacy is offered by existing mail protocols; typically, a message travels through multiple hops to get to the recipients mailbox, where it is then accessed through username/password authentication. All of these steps are performed without any encryption, which means any of the intermediate nodes could inspect the message, and it's even possible (and actually pretty easy) to steal passwords and get full access to someone's mailbox.

Fourth, if a message is meant to be private, the sender probably knows the recipient to the extent that public key cryptography (e.g. PGP) can be used.

All in all, I think privacy is an issue which needs to be addressed, but good solutions are easy to obtain.

As for implementing a new prococol for message retrieval, I don't think that would be necessary. Once again, you raise the issue of identification of machines, and I will once again point out that: 1) you don't want to authenticate machines, you want to authenticate users 2) adequate mechanisms for user authentication already exist. In this specific case, HTTPS (HTTP over SSL) can be used to encrypt the transmission and authenticate the server, the client, or both; or plain HTTP could be used, with PGP on the message to authenticate the sender, the recipient, or both. There are plenty of other possibilities, as well.

Anyway, it's fun to think about this stuff once in a while. Thanks for your comments, and if you would like to continue the discussion, I would be glad to.

Reply to this message