JMAP, or JSON Meta Application Protocol, is emerging as a modern alternative to traditional protocols such as IMAP and SMTP.
But what exactly is JMAP, and why does it deserve our attention in the field of email ? This article guides you through JMAP’s main technical features and its usefulness.
What’s JMAP Protocol?
The JSON Meta Application Protocol (JMAP) is a set of standard, open Internet protocols designed to handle e-mail. JMAP is implemented using JSON APIs and was created as an alternative to IMAP/SMTP protocols and proprietary messaging APIs such as Gmail (Google) or MAPI (Microsoft Outlook).
In addition to email management, JMAP serves as the basis for other protocols and data models, notably for contact and calendar synchronization, with the aim of potentially replacing CardDAV and CalDAV. Other extensions are also under development.
Why JMAP?
The limitations of the IMAP protocol are well known: slow performance, complexity in managing multiple connections, and inefficiency in synchronizing emails across multiple devices. In response to these issues, JMAP was developed to offer several major advantages:
Unified API: JMAP unifies the management of various aspects of messaging services, including emails, contacts, and calendars, into a single API, making the management of complex applications easier.
Simplicity: JMAP is based on HTTP and uses the JSON format, which is well-known to developers, greatly simplifying the integration process. Unlike IMAP, it is not necessary to maintain a persistent connection to monitor new emails.
Performance: JMAP allows better connection management through the use of batch requests and optimized resource management. Email retrieval is faster and more efficient, especially in environments with limited bandwidth.
Faster synchronization: With JMAP, synchronization of emails, calendars, and contacts across multiple devices is instantaneous. New email notifications can be received in real-time without requiring multiple network requests.
How does JMAP work?
The operation of JMAP is based on simple yet powerful principles. Here is a technical overview of its mechanism:
Synchronization mechanism: JMAP includes intelligent synchronization mechanisms that allow only changes since the last sync to be retrieved. This eliminates the need to reload all the data, which is particularly advantageous for users with slow connections.
Use of HTTP/HTTPS: JMAP uses HTTP as the transport protocol, which is already ubiquitous in most network infrastructures. This allows seamless integration with web and mobile services.
Data representation in JSON: All data, whether it is emails, contacts, or synchronization information, is exchanged in JSON format. This format is both lightweight and easy to interpret, reducing the complexity and size of responses.
Batching requests: Unlike IMAP, where each action (checking for new emails, reading, marking as read, etc.) requires a separate request, JMAP allows multiple actions to be sent in a single HTTP request. This significantly reduces the number of network requests and improves overall performance.
JMAP Uses cases:
Web and Mobile Applications: Modern email clients, whether in the form of mobile apps or web clients, can greatly benefit from JMAP. The fast synchronization and batch request management make these applications more fluid and responsive.
Email Providers: Email service providers, by adopting JMAP, can reduce the load on their servers while offering a better user experience. Additionally, compatibility with HTTP/HTTPS allows for easier integration with existing systems.
Unified API: Developers looking to integrate email management into their applications can rely on these APIs. This simplifies the implementation of email-related services while ensuring optimized synchronization and management.
JMAP vs IMAP/SMTP comparison
| Feature | JMAP | IMAP/SMTP |
|---|---|---|
| Transport protocol | HTTP/HTTPS | IMAP and SMTP use dedicated protocols |
| Data format | JSON (lightweight and structured) | Plain text (more complex and verbose) |
| Connection management | Stateless HTTP requests | Persistent connections required |
| Batch requests | Supports batch requests | One request per action |
| Push notifications | Native support without persistent connection | Often based on long connections (idle) |
| Synchronization | Smart synchronization, only fetches changes | Full synchronization, often slow |
| Unified management | Unified API for emails, contacts, calendars | Email only, with separate protocols (CardDAV for contacts, CalDAV for calendars) |
| Implementation complexity | Simple, with JSON and HTTP/HTTPS | More complex, requires multiple protocols |
| Performance | Optimized for modern applications | Less efficient, especially in low-bandwidth environments |
| Usage | Suitable for modern web and mobile environments | Mainly used for traditional desktop email clients |
Opensource servers supporting JMAP
Cyrus-IMAP, a well-known mail server, was one of the first to support JMAP, starting as early as 2018 with version 3.0. While not everything is fully supported yet, not all aspects of JMAP have been standardized by the IETF either.
Apache James (Java Apache Mail Enterprise Server) is a complete mail server solution that supports JMAP.
Stalwart JMAP Server is a lightweight and fast solution that implements JMAP, along with other protocols like IMAP, SMTP, and Sieve. It is designed to be performant and easily integrated into modern environments. Stalwart stands out for its focus on JMAP, offering a simple and effective alternative to traditional mail servers.
Stalwart, written in Rust, seems like a very interesting project that I encourage you to follow if you’re passionate about the email world!
Our opinion on JMAP
By solving the performance, complexity and compatibility problems of older protocols such as IMAP and SMTP, JMAP makes a compelling case for the future of messaging services. JMAP is the protocol to watch closely.
In any case, at Sweego, JMAP seems very interesting for new services that we’d like to offer and that are requested by our customers. Wait and see…