1. Protocol Architecture: RFC 3501 Plaintext vs RFC 8620 JSON-over-HTTP

Understanding the performance gulf between IMAP and JMAP requires examining the wire protocols and communication paradigms:

IMAP (RFC 3501): A conversational, connection-oriented, stateful protocol operating over a dedicated TCP socket (port 993 with TLS). Commands are issued as plain-text strings prefixed with unique client tags (e.g., A001 SELECT INBOX). The client and server maintain strict session state. To fetch an email with attachments, the client must first select the mailbox, fetch message flags, fetch MIME body structures, parse the multipart boundaries, and issue subsequent commands to download individual parts. If a mobile device drops its connection when moving from cellular to Wi-Fi, the entire TCP socket dies, and the client must re-authenticate and re-synchronize from scratch.

JMAP (RFC 8620): A stateless, REST-inspired protocol transmitting structured JSON over standard HTTP/2 or HTTP/3 (port 443). Rather than issuing multiple conversational commands, a JMAP client sends a single HTTP POST request containing an array of method calls. In a single request, the client can ask the server to: (1) fetch the mailbox list, (2) return the unread count, and (3) download the first 25 message summaries complete with sender avatars and preview snippets. The server executes these operations concurrently and returns a unified JSON response.

# IMAP (RFC 3501): 4 sequential network roundtrips required
C: a01 SELECT INBOX
S: * 145 EXISTS 

 * OK [UIDVALIDITY 12345] 

 a01 OK [READ-WRITE] Completed
C: a02 FETCH 145 (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE BODYSTRUCTURE)
S: * 145 FETCH (...) 

 a02 OK Completed
C: a03 FETCH 145 BODY[1]
S: * 145 FETCH (BODY[1] 1024 [HTML content] ...) 

 a03 OK Completed

# JMAP (RFC 8620): 1 single HTTP/2 POST request fetches envelope + body snippet
POST /jmap/ HTTP/2
Host: mail.example.com
Content-Type: application/json
Authorization: Bearer secret_token_xyz

{
  "using": ["urn:ietf:params:jmap:core", "urn:ietf:params:jmap:mail"],
  "methodCalls": [
    ["Email/query", {"filter": {"inMailbox": "inbox_id"}, "sort": [{"property": "receivedAt", "isAscending": false}], "limit": 10}, "q1"],
    ["Email/get", {"#ids": {"resultOf": "q1", "name": "Email/query", "path": "/ids"}, "properties": ["id", "from", "subject", "receivedAt", "preview"]}, "g1"]
  ]
}

2. Mobile Battery Drain, Network Hopping & Cellular Radio State

The single greatest operational flaw of IMAP on mobile devices is its interaction with cellular power management:

• Cellular Radio Wake Locks: Modern 4G/5G mobile radios operate in discrete power tiers: Sleep (near-zero power), Low-Power Shared, and Full Power Active. To receive push email over IMAP, clients use IMAP IDLE (RFC 2177), keeping a persistent TCP socket open. Because NAT routers and mobile carrier firewalls drop idle sockets after 10 to 15 minutes, mobile clients must wake the radio every 9 to 14 minutes to send synthetic TCP keep-alive packets, preventing the device from entering deep sleep and draining battery.
• JMAP Push Mechanics: JMAP separates data transfer from push notifications. When the client is backgrounded, it shuts down its HTTP connection. Push notifications are delivered via native operating system push channels (Apple Push Notification service [APNs] or Google FCM) or lightweight Server-Sent Events (SSE). The device sleeps undisturbed until an actual email arrives.
• Network Hopping & Roaming: When a user walks out of their house and their phone transitions from home Wi-Fi to 5G cellular, their IP address changes. IMAP sockets instantly break with ECONNRESET, requiring full TLS renegotiation and folder re-synchronization. JMAP requests over HTTP/2 simply send the next request over the new connection; with HTTP/3 (QUIC), connection migration allows seamless roaming with zero connection interruption.

3. Query Batching & Latency over High-Loss Networks

On high-latency cellular connections (e.g., 200ms latency on an airplane Wi-Fi or rural 3G connection), network roundtrips dominate performance:

To open an email client and synchronize a folder with 20 new messages, IMAP requires between 12 and 25 sequential roundtrips (capability exchange, authentication, mailbox selection, UID search, envelope fetch, body structure fetch, flags update). At 200ms per roundtrip, the user waits 3 to 5 seconds staring at a spinning wheel.

JMAP executes the identical synchronization in exactly one HTTP/2 roundtrip via method chaining. The query results from Email/query are piped directly into Email/get on the server side without traveling back over the radio link. Total load time: 200ms.

4. Server Daemon Ecosystem: Cyrus, Dovecot Proxies & Stalwart

While JMAP represents a massive technological leap, server adoption has historically lagged behind IMAP’s three-decade head start:

• Cyrus IMAP: The pioneer of JMAP. Cyrus has supported native JMAP since version 3.0, co-authored by the Fastmail engineering team who wrote RFC 8620. Cyrus offers a battle-tested, high-concurrency JMAP implementation used in production across tens of millions of mailboxes.
• Stalwart Mail Server: The modern, open-source all-in-one mail server written in Rust. Stalwart features 100% native JMAP, IMAP4rev2, and SMTP support with built-in S3-compatible blob storage, RocksDB metadata caching, and native OAuth 2.0 authentication.
• Dovecot: The dominant open-source IMAP daemon currently supports JMAP through proxy middleware and plugins (such as Apache James JMAP proxies or community jmap-dovecot modules). Full native core JMAP integration is on the Dovecot roadmap.

5. IMAP vs JMAP Technical Matrix