-
Messaging: What I Want
- body
-
I've blogged numerous times about XMPP, SMTP, and communications evolution on the web. I've suggested what I want ultimately and snippets of how we might get there. Here, I am going to outline just briefly what I consider "next steps". The big ones. Get these done, and you will have made a *huge* stride in online messaging:
- Allow offline messages (type normal or chat) to be collected as "email". Gmail sort-of does this by presenting unseen offline messages in the web interface inbox. I want IMAP access to these in the inbox and their archive. Heck, store them in a Unix mailspool (have to store them somewhere anyway) and existing IMAP servers will just work for you!
- SMTP messages are type=normal. If you store offline messages in a mailspool and run an SMTP server on that spool, you're mostly done. Might be good to offer real-time deliver of those messages to the user of XMPP as well though.
That's it! Sure, more can be done, but if you get the first one done I will be your biggest fan. Do both and you're well on your way to an evolution in how we deal with email (both from a user and a protocol perspective). Yes, I've tried to build this. I want to do it as an ejabberd module, but ejabberd is barely documented. I'll try again sometime if no one else does - maybe with ejabberd, maybe with someone else.
-
Replacing SMTP with XMPP
- body
-
The idea is out: XMPP is a perfect replacement for SMTP. SMTP (the current standard e-mail program) is outdated for a variety of reasons, such as the fact that it's not SPAM resistant and that you can't know for sure (easily) who sent a message.
XMPP (a.k.a. Jabber) solves a lot of this and is a fully extensible protocol that has already been adopted as a standard for IM. The benefits are many, and there is only one major hurdle: every server on the Internet would have to change software!
Regular readers may be able to guess my (and others') solution to that problem: backwards compatibility! When using XMPP for primary email, one must provide a bridge back to the SMTP world. There's no real way around that for now. Fortunately, it's not too hard. There are a few options:
- Write a client that supports both XMPP and SMTP (through POP3 or IMAP) and have an identical address on both networks (think @gmail.com).
- Modify (/write) an SMTP-based mail server to support XMPP.
- Modify (/write) an XMPP server to support SMTP.
I really believe option #3 is the way to go.
What else may be required for this to become a reality? Well, some way of keeping the traditional email experience (at least somewhat) may be required for the masses. This means things like an inbox (for non-chat messages) and tags for message history. Gmail actually already has this for offline messages. There was also some work in 2004 on an XMPP client that supported something like this.
Some say that the encoding of emails must be retained. I think this is bunk because it defeats the purpose of changing protocols and killing the old standard. Some thought does need to go into the handling of offline payloads (especially file transfers / email attachments). I think data: URIs may work for this, but something better may be in the works.
All it takes is one person who decides to adopt this as their primary way of functioning. They develop some software, and it spreads from there. I'm sticking with GTalk servers for Jabber for now (although I have the power to run my own @singpolyma.net), just because it's easier for people who already have that address (I hate having multiple addresses). What I'm really waiting for / looking for is a decent client for this. Gmail has IM built in and handles this model for offline messages well, but it is not really even possible to reply to emails via Jabber, et cetera. GTalk interfaces (including Gmail) actually don't support any XMPP message type except chat well just yet. We're getting closer to something that could work though.








You can trackback from you own site.
5 Comments
Someone wrote a "component in Python to log Jabber messages to a IMAP mail folder" but there's no source available.
When you say "Might be good to offer real-time deliver of those messages to the user of XMPP as well though", are you referring to a sort of XMPP-to-SMTP gateway ?
@kael SMTP-to-XMPP. Messages received over *either* XMPP or SMTP go to the mailspool for IMAP delivery (first point) and it might be good to have SMTP messages delivered to you over XMPP if you are online while they are received (making them indistinguishable from type=normal XMPP message you receive) - behaviour would be unchanged (or would be the same as for offline XMPP messages) if received while you were not online (or maybe if you were away).
Regarding the IMAP storage of XMPP messages, perhaps that the Ejabberd mod_archive, Datasink or the mod_archive_odbc modules could be the base of such a component, maybe combined with the ErlMail package (I don't know much of it ; it seems the only Erlang IMAP module available).
BTW, have you thought to the format of XMPP messages stored into IMAP server ? Messages could be formatted into multipart/alternative with one part in XML, the other in plain text.
Regarding notifications of new mails, there exists the JMC component. I don't remember the type of message used for notification but I guess it can be easily changed.
But it'd be difficult to receive mail notifications only when the Inbox is opened. There's no way to know if a mailbox is opened, at least, I don't see any, but it'd definitely a good thing as with current Mail-to-XMPP notification services, it's annoying to receive messages twice, even worst when notifications sent after connecting with Jabber are from mails already read.
Also, you might be interested by the draft-ietf-sieve-notify-xmpp draft which defines a format for mail notifications. But I'd prefer if it used a Pubsub/PEP format as I've suggested on the SIP-XMPP list.
Erratum : But it'd be difficult to receive mail notifications only when the Inbox is not opened.
http://www.xmpp.org/extensions/xep-0136.html with collections as mailfolders and IMAP access looks very promising indeed.
Archiving according to XEP0136 and also storing the data in a mailspool, with folders matching collections might work very well indeed.
Storing multipart/alternative may be a very good idea, for clients that may support XMPP stanzas directly.
Reply / Comment