And the alternative were few open source xmpp erlang engines. One thing they had in common was they all relied on XMPP. During this time I would have worked close to 40 different and unique communications platforms. Storing multipart/alternative may be a very good idea, for clients that may support XMPP stanzas directly.I have been working with social media/communications platform for around 8 years now. with collections as mailfolders and IMAP access looks very promising indeed.Īrchiving according to XEP0136 and also storing the data in a mailspool, with folders matching collections might work very well indeed.
kaelĮrratum : But it’d be difficult to receive mail notifications only when the Inbox is not opened. But I’d prefer if it used a Pubsub/PEP format as I’ve suggested on the SIP-XMPP list. 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.Īlso, you might be interested by the draft-ietf-sieve-notify-xmpp draft which defines a format for mail notifications. I don’t remember the type of message used for notification but I guess it can be easily changed.īut it’d be difficult to receive mail notifications only when the Inbox is opened. Regarding notifications of new mails, there exists the JMC component. 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).īTW, 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.
#Offline delivery of messages ejabberd Offline
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). 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 ? Stephen Paul Weber Someone wrote a “component in Python to log Jabber messages to a IMAP mail folder” but there’s no source available. You can leave a response, or trackback from your own site. You can follow any responses to this entry through the feed. This entry is filed under Communication, Email, Jabber, Tech, XMPP. I’ll try again sometime if no one else does – maybe with ejabberd, maybe with someone else. I want to do it as an ejabberd module, but ejabberd is barely documented. 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). That’s it! Sure, more can be done, but if you get the first one done I will be your biggest fan. Might be good to offer real-time deliver of those messages to the user of XMPP as well though. If you store offline messages in a mailspool and run an SMTP server on that spool, you’re mostly done.
Heck, store them in a Unix mailspool (have to store them somewhere anyway) and existing IMAP servers will just work for you!
I want IMAP access to these in the inbox and their archive. Gmail sort-of does this by presenting unseen offline messages in the web interface inbox.
0 kommentar(er)
