While reading yesterday’s link to the FastMail blog post, “Email is your electronic memory”, I followed the link in the post to the JMAP protocol (discussed three years ago here, on HN, and most recently LWN).
In a nutshell, JMAP is an IETF draft protocol for “synchronising JSON-based data objects efficiently”, implemented initially as more efficient protocol for synchronizing email between servers and MUAs in lieu of IMAP.
As a mail-client protocol, in addition to being an efficient RESTful-like RPC (JSON + HTTPS), it has other features to recommend it, including mail submission, support for GMail-like labels (i.e., membership in multiple folders), and extensions to support contact and calendar/todo management in lieu of CardDav and CalDav. (N.B. JMAP is not an MTA-to-MTA replacment. It’s a client protocol only.)
JMAP is not without controversy as a mail-client protocol:
It’s a structured protocol that almost requires libraries to and tools to interact with. (Yes, JSON is text based so you can handcraft the requests and parse the replies. See examples.) For developers, structure is very good. But for sysadmins wanting to test a server quickly, it’s hard to beat
It doesn’t handle binary objects (e.g., attachments in email). They’re referenced using blob ids that have to be pulled separately to avoid having to encode them in base64 (or similar).
The project has come along quite a bit since last discussed. There are server implementations, an IMAP proxy, client libraries, and a sample web front end available for testing. Perhaps it’s time for another review and discussion.