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.
6 Responses
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.
[…] ejabberd doesn’t run after apt-get install ejabberd Saved by mjen1952 on Wed 22-10-2008 Messaging: What I Want Saved by Lecquio on Wed 22-10-2008 Differences OpenFire/ejabberd (Part I) Saved by chericem on […]