JSON Meta Application Protocol
As an open standard, JMAP is the alternative to proprietary email APIs that only work with Gmail. It’s a much needed modern email standard that makes email more open to innovators like you.
Supported by Fastmail.
FAQ
Selected entries from the FAQ
Why use HTTPS/JSON?
The short answer is it's good enough, it's widely understood, and it's by far the easiest thing for developers to adopt. There's support in basically all OSes and programming languages. And it's easy to read and debug.
HTTP doesn't tend to run into firewall issues, and is so commonly used that it has integrations which can help with optimisation (for example, iOS has built-in support for optimising radio usage by batching HTTP calls from different apps where possible, which their mail team have told us they would like to be able to use). This isn't an innate advantage of HTTP, but rather an advantage of its ubiquity.
With GZIP, JSON data is reasonably compact and fast enough to serialise/parse. However, the encoding/transport part of JMAP is not core to its operation, so future specifications could easily add alternatives (e.g. WebSocket instead of HTTPS, CBOR instead of JSON). For the initial version though, HTTPS+JSON makes the most sense.
End-to-end encryption
A lot of the optimisations for efficient client-server sync require the server to be able to read the message. If everything were encrypted, the server would basically be a dumb blob store. This is particularly bad for mobile, where you only want to sync partial information. Users expect to be able to search their whole archive, so either you need all the data in the client, or the server needs to have access to the data.
JMAP is therefore not introducing any new measures to address end-to-end encryption. The best advice is probably to run your own "JMAP server" on trusted hardware; otherwise you need to sync the entire multi-gigabyte mail spool to all your devices. JMAP is also simple enough that you could run the server on multiple machines with an underlying replication protocol over encrypted links and have that do your smarts.
IETF
- IETF Working Group https://datatracker.ietf.org/group/jmap/about/ - now moving on to contacts and calendars
- A JMAP Subprotocol for WebSocket [RFC8887]
- JMAP Blob Management Extension [RFC9404]
- JMAP Quotas [RFC9425]
In development:
Data Formats
- JMAP was designed in conjunction with new JSON-based file formats for contacts and calendars, which can also be used standalone or in other protocols.
- JMAP Contacts uses JSContact (RFC9553) as the data format for contacts.
- JMAP Calendars uses JSCalendar (RFC 8984) as the data format for events.
JSON Meta Application Protocol
The base layer specification for all application types. RFC8620
This document specifies a protocol for clients to efficiently query, fetch, and modify JSON-based data objects, with support for push notification of changes and fast resynchronisation and for out-of-band binary data upload/download.
JSON Meta Application Protocol (JMAP) for Mail
This is the email specific RFC. RF8621
This document specifies a data model for synchronising email data with a server using the JSON Meta Application Protocol (JMAP). Clients can use this to efficiently search, access, organise, and send messages, and to get push notifications for fast resynchronisation when new messages are delivered or a change is made in another client.