885105 - [email/IMAP] switch from forked imap.js implementation to 'inbox' or similar

Status: RESOLVED DUPLICATE of bug 885110

(Firefox OS Graveyard :: Gaia::E-Mail, defect)

Description

[Andrew Sutherland [:asuth] (he/him)]

We are using a forked version of https://github.com/mscdex/node-imap.  It has served us well, but we'd like an IMAP protocol implementation that more aggressively factors parsing logic out in a modular fashion.  https://github.com/andris9/inbox looks exactly like what we want in terms of parser and lower level protocol implementation.  Higher level operations like message moves (that aren't using RFC 6851's MOVE command) are something we want to use our offline operation mechanism support for, however.

Andris (the author of 'inbox', copied here) has started to port some of his other libraries (that we use) across to (moz)TCPSocket and TextEncoder/TextDecoder (from buffer) in https://github.com/andris9/firemail so we want to make sure that if 'inbox' ends up in that lib, we just start using that rather than starting from the node wrapper.  We have shims so that we can do it either way, but the use of Buffer can introduce a lot of transformations that aren't really required, so it's nice to avoid.

Comment 1

[andris.reinman]

With "inbox" module there are several problems. At first, there are almost no tests - only the parser that handles data coming from the server has some tests but there are none for the functional side of the module. 

Additionally, the module in its current implementation is meant for downloading entire messages at once (with all the attachments etc.) which is not something anyone would probably want to do in a mobile. While this can be easily overcome by changing FETCH BODY[] to something saner, there is also an issue regarding licensing. 

Namely, "inbox" has been quite lax at "borrowing" some translations for folder names from the QT project (https://github.com/andris9/inbox/blob/master/lib/names.json) which is not MIT/BSD compatible. These translations are used to detect IMAP folder types - instead of creating yet another Trash and Sent Mail folder, existing ones can be used. RFC6154 is going to handle folder type detection in the future with SPECIAL-USE parameter but while most of the servers do not support this, folder name/translation mapping needs to be used.

While probably not an issue for a small independent module considering that the data is not copied directly but used "as an inspiration" it might be somewhat controversial to be used by a major project like FirefoxOS. I guess that safer way would be to drop the current translation list and regather it - maybe the translations can be found from the Thunderbird code?

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

Lacking tests can be thought of as a temporary problem :)  Specifically, the gaia e-mail client can either write new things from scratch or use and contribute to existing open source libraries.  I definitely favor using and contributing to existing solutions to the maximum extent possible, and that would include helping to author unit tests.

Folder detection is on the line between protocol level and higher layers.  Currently, our folder type detection lives above the protocol, here:
https://github.com/mozilla-b2g/gaia-email-libs-and-more/blob/master/data/lib/mailapi/imap/account.js#L789

The logic is adapted from the Thunderbird logic which just assumes that servers will use english strings for their special folder names.  The Thunderbird UI then uses localized strings to expose those english-named folders in the user's locale.  However it's also possible that there is a second layer that I missed that does use localized strings to reverse the folder names.  Thunderbird also does have UI affordances to specify what folders to use for all of the special-purpose folders: sent, drafts, archives, etc., so maybe users with servers that use localized special folder names just end up manually configuring that.

Comment 3

[andris.reinman]

"inbox" is going to be part of firemail at some point (maybe under another name though but this is irrelevant at this point). I'm not sure the exact timeframe for this as I'm not so much directly porting but rewriting the libraries and this takes time. Currently I'm working with the RFC2822 parser and when this is more or less completed, I'm going to write a POP3 client and only after that move on to the IMAP part. I'd like to do POP3 first (even though best before for POP3 is long past its due) because of its simplicity.