IMAP was designed by Mark Crispin at a time when a mail client was a program on a university workstation with a persistent network connection. The protocol assumes exactly that: a long-lived TCP session, one folder selected at a time, a chatty text dialogue of commands and untagged responses. IMAP4rev1 was standardized in RFC 3501 in 2003, and a cleanup (IMAP4rev2, RFC 9051) arrived in 2021, but the model underneath never changed.
A smartphone is the opposite of that model. Connections drop constantly. The radio is the biggest battery cost, so you want few, short, batched requests. You care about five folders at once. You want the server to tell you the moment something changes, not to hold a socket open per folder hoping IDLE survives the next NAT timeout. Forty years of extensions (CONDSTORE, QRESYNC, NOTIFY, BINARY) each fix a piece of this, and each is supported by a different subset of servers, so real clients ship a matrix of fallbacks and quirks workarounds.
What JMAP actually is
JMAP, the JSON Meta Application Protocol, was standardized in RFC 8620 (the core sync mechanism) and RFC 8621 (its application to mail) in 2019. Much of the design came out of Fastmail, which had been running an internal JSON protocol between its own web client and servers for years and brought that experience to an IETF working group.
The protocol drops the persistent-session model entirely. A client makes an HTTPS request to a single API endpoint containing a batch of method calls, and gets a batch of responses back. Three design choices do most of the work:
- Batched, chainable method calls. One request can say "run this query for the newest 50 message ids, then fetch the headers of whatever that query returned" using back-references between calls. What takes IMAP a conversation takes JMAP one round trip.
- State strings instead of guesswork. Every object type (Mailbox, Email, Thread) has an opaque state token. A client that was offline for a week presents its old token and asks for changes; the server returns exactly the created, updated, and destroyed ids since then. This is the sync model CONDSTORE and QRESYNC retrofitted onto IMAP, but it is mandatory and uniform, so clients can rely on it.
- Blobs out of band. Message bodies and attachments are not base64-smuggled through the protocol. They are uploaded and downloaded as binary blobs over plain HTTPS, referenced by id. Sending a large attachment does not mean re-encoding it into a protocol stream.
Push notifications are part of the core spec rather than an extension: a server offers an event-stream endpoint for connected clients, and a webhook-style push subscription for platforms where the app cannot stay awake. The mobile-battery problem that IMAP IDLE never solved is a first-class design requirement.
What this changes for privacy, and what it doesn't
JMAP runs exclusively over HTTPS. There is no plaintext port, no STARTTLS negotiation to strip, and no separate submission protocol to configure badly: mail retrieval and sending ride the same authenticated channel. A whole class of downgrade and misconfiguration problems that follow IMAP and SMTP submission around simply has no place to occur. If you have read our piece on MTA-STS and mail transport hardening, JMAP moves the client-to-server leg onto the same footing as ordinary web traffic, JA3 fingerprinting and all.
What JMAP does not change is the content trust model. It is a sync protocol. The server still stores your mail and still reads it, unless the content is encrypted end-to-end at a layer above, with PGP or S/MIME. A JMAP server operated by an advertising company can profile you exactly as well as an IMAP server can. Anyone evaluating a provider should keep those two questions separate: how the mail moves, and who can read it at rest.
JMAP's efficiency has a quiet privacy benefit on mobile: fewer, shorter connections mean a smaller traffic-timing footprint for anyone watching the network. But this is a marginal gain, not a defense. Traffic analysis of encrypted connections still reveals when you are active and roughly how much mail you move.
IMAP and JMAP side by side
| Property | IMAP | JMAP |
|---|---|---|
| Transport | Long-lived TCP session, optional TLS | Stateless HTTPS requests only |
| Sync model | Per-folder, extension-dependent (CONDSTORE/QRESYNC) | Uniform state tokens, delta sync built in |
| Push | IDLE, one folder per connection | Event stream + push subscriptions, all types |
| Round trips for "show new mail" | Many (select, search, fetch per folder) | One batched request |
| Sending | Separate protocol (SMTP submission) | Same protocol and session (EmailSubmission) |
| Ecosystem support | Universal | A handful of servers and clients |
So why hasn't it won?
The last row of that table is the whole story. Fastmail runs JMAP in production for its own apps. The Cyrus and Stalwart mail servers implement it, and Apache James has support. On the client side the picture is thin: most of the mail apps people actually use, on every platform, speak IMAP and nothing else, and the large mailbox providers have little incentive to add a second protocol to infrastructure that already works. Gmail and Outlook expose their own proprietary HTTP APIs to their own apps, which solve the same problems JMAP solves, just privately.
That is the uncomfortable pattern: the mail giants each built a private JMAP-equivalent and kept it, while the open standard waits for a critical mass of servers and clients to adopt it at the same time. Protocol replacement in a federated system is slow even when the replacement is better on every axis. IMAP works, in the way that a forty-year-old bridge with weight restrictions works, and "works" has beaten "better" in email for decades.
It still matters that JMAP exists. It is the standards-track answer to a real question: what should client-to-server mail look like if you design it for the devices people actually own? Anyone building new mail infrastructure today can start from RFC 8620 instead of from 1986, and some do. The same pattern is playing out in messaging, where MLS is the modern, IETF-standardized answer slowly displacing a thicket of older ad-hoc designs.
What to take from this if you just use email
You cannot switch your mail apps to JMAP today, and there is no security emergency requiring you to. The practical takeaways are smaller. If your provider's app feels dramatically faster and more battery-friendly than a generic IMAP client pointed at the same account, this is why: the native app is almost certainly not speaking IMAP. And when you evaluate a mail provider's claims, remember that transport modernity and content privacy are orthogonal. A provider can run the most modern sync protocol in the world and still read every word you write. The questions that actually protect you are the ones about end-to-end encryption and what the server stores in the clear.