For thirty years, if you wanted to build an email client, you had two miserable choices: IMAP, a stateful, line-oriented protocol from 1986 that mutates its own grammar based on server capabilities, or POP3, which barely counts as email at all. Every mobile mail app on Earth spent enormous engineering effort papering over IMAP's quirks: no batching, no push (without the IDLE hack), no efficient sync, ambiguous UTF-8 handling, and a wire format that requires a bespoke parser. RFC 8620 is Neil Jenkins and Chris Newman's answer: throw out the wire protocol entirely, keep the data model, and build something a JavaScript developer could implement in an afternoon.

JMAP is the generic half of the spec — it defines the transport and object-manipulation semantics that email (RFC 8621), contacts, and calendars all layer on top of. The core idea: everything is a JSON object with an id, and clients talk to the server by POSTing batches of "method calls" to a single HTTPS endpoint. A method call is a tuple: [name, arguments, client-tag]. The server executes them in order and returns a matching list of responses.

Several design decisions are worth studying:

• Result references. The killer feature. A later call in the batch can reference the output of an earlier one using a JSON Pointer (RFC 6901) into the previous response. So "get my inbox, then get the first 20 messages in it, then get the thread each belongs to" is one HTTP request, not three round trips. This alone makes JMAP dramatically faster than IMAP on high-latency mobile networks.
• State strings and /changes. Every object type has an opaque state token. To sync, you send your last-known state and get back exactly which IDs were created, updated, or destroyed since then. No more IMAP's "compare UIDVALIDITY, then fetch flags for every UID, then diff." Sync becomes O(changes), not O(mailbox).
• Push via EventSource or WebSockets. No more IMAP IDLE with its one-connection-per-folder tax. A single push channel notifies you of state changes across every account.
• Uploads are separate. Binary blobs go through a dedicated upload endpoint and are referenced by blob ID in subsequent method calls, keeping the JSON layer clean.
• Capabilities are namespaced URIs. Extensions live at URIs like urn:ietf:params:jmap:mail, so vendors can add features without colliding — a direct lesson learned from IMAP's flat capability soup.

The backstory is telling. Jenkins is CTO of Fastmail, which had been running a proprietary JSON-over-HTTP protocol internally since roughly 2014 because IMAP simply could not deliver the responsiveness their web and mobile clients needed. Standardization took years, in part because the IETF EXTRA working group had to fight the instinct to just "fix IMAP again" (they'd done it many times — IMAP4rev1, then LEMONADE, then IMAP4rev2). JMAP won by not pretending to be IMAP at all.

Adoption in 2026 is quietly growing: Fastmail, Topicbox, Stalwart, Cyrus, and Apache James all speak JMAP; the JMAP for Calendars spec (RFC 8984 data model, RFC 8620 transport) is starting to displace CalDAV in new deployments; and there's a Contacts spec too. Gmail and Outlook still don't support it, which is JMAP's biggest problem — but every indie mail provider you'd actually want to use does.