eMail via XMPP
Thursday, March 30, 2006 by darcoPosted in Jabber
The idea of using XMPP as a transport for email (possibly a replacement to SMTP) is not new, but so far I haven't really seen anything come from the idle speculation. And, more importantly, that's not what this post is about anyway. At least not yet.
I'm considering writing an eMail jabber component that would allow you to check, view, read, reply, and write email. The first step to doing that is to write an XMPP protocol for email. Think about all of the features of IMAP, with the ability to receive real-time updates and send mail. There are many benefits to doing this:
- SMTP ports are often blocked, keeping people from sending mail
- Sometimes XMPP and HTTP are the only protocols allowed past a firewall
- Fairly easy to write perl scripts which could manipulate your mailboxes for you and have it work for everything.
- etc.
The first step in making this happen is to come up with a mapping from MIME to XML and vice-versa. So I submit exactly that to you now for public review.
Normal MIME Message:
From: Robert Quattlebaum <rquattle@notarealemail.com> To: Robert Quattlebaum <rquattle@omgbogus.net> MIME-Version: 1.0 Content-Type: multipart/mixed boundary="----_=_NextPart_001_01C647B7.0781DFD5"; Subject: Example SMTP Message in XML format ------_=_NextPart_001_01C647B7.0781DFD5 Content-Type: multipart/alternative; boundary="----=_Part_470_24618162.1141711732808" ------=_Part_470_24618162.1141711732808 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline testing ------=_Part_470_24618162.1141711732808 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline <html><body><h1>testing</h1></body></html> ------=_Part_470_24618162.1141711732808– ------_=_NextPart_001_01C647B7.0781DFD5 Content-Transfer-Encoding: base64 Content-Type: image/jpeg; name=test.jpg Content-Disposition: attachment; filename=test.jpg insertbase64codehere ------_=_NextPart_001_01C647B7.0781DFD5–
The same MIME message in XML:
<mime xmlns="http://www.deepdarc.com/XMIME"> <h name="From">Robert Quattlebaum <rquattle@notarealemail.com></h> <h name="To">Robert Quattlebaum <rquattle@omgbogus.net></h> <h name="Subject">Example SMTP Message in XML format</h> <h name="Content-Type">multipart/mixed</h> <mime> <h name="Content-Type">multipart/alternative</h> <mime> <h name="Content-Transfer-Encoding">quoted-printable</h> <h name="Content-Type">text/plain</h> <h name="Content-Disposition">inline</h> <b>testing</b> </mime> <mime> <h name="Content-Transfer-Encoding">quoted-printable</h> <h name="Content-Type">text/hml</h> <h name="Content-Disposition">inline</h> <b><html><body><h1>testing</h1></body></html></b> </mime> </mime> <mime> <h name="Content-Type">image/jpeg; name=test.jpg</h> <h name="Content-Disposition">attachment; filename=test.jpg</h> <b enc="base64">insertbase64codehere</b> </mime> </mime>
It should be pretty easy for you to get the idea of what's going on. The idea here is to be able to convert from standard email to XML (and vice-versa) "losslessly". Note that I don't really care about preserving the "boundary" parts. All we care about is preserving the structural integrity of the email. If we can do that, then we won't break things like X.509 and PGP signatures.
Here is the DTD:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE mime [ <!ENTITY % BODY "(b | mime)"> <!ELEMENT mime (h+, %BODY;*)> <!ELEMENT h (#PCDATA)> <!ATTLIST h name CDATA #REQUIRED> <!ELEMENT b (#PCDATA)> <!ATTLIST b enc (text | base64 | xml) "text"> ]>
I am not the first person to think about creating a XML representation of MIME. XMTP is such an implementation. There are several things that I don't like about it, but the largest is that all headers are themselves elements. This means that any new or unexpected headers would violate the schema.
Others have also come up with draft standards of such that seems to a better job, but I'm not particularly satisfied with them either–I think they are unnecessarily complex.
The method I describe above should more simple to understand, parse, and live with long-term.
Any thoughts? Suggestions?