RFC 9698

RFC 9698: The JMAPACCESS Extension for IMAP ✨

okay bestie, this one is RFC 9698 and it's giving bridge between two worlds 🌈. It's an IMAP extension, and it's a Standards Track document, so it's an official Internet spec 💅. It was written by A. Gulbrandsen (ICANN) and B. Gondwana (Fastmail), and it's dated January 2025 🎀. Its ISSN is 2070-1721. The title block doesn't list anything it obsoletes or updates, so it's not replacing or changing any other RFCs 🌸.

Abstract 🫶

okay so this doc defines an IMAP extension that lets clients know the messages on an IMAP server are also reachable through the JSON Meta Application Protocol (JMAP), and it explains how 🦋. It's aimed at clients that want to migrate to JMAP slowly, or that want to use JMAP extensions from inside an IMAP client. main character energy for migration 😭.

Status of This Memo 🌟

this is an Internet Standards Track document 🔥. It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 7841 💜. For the current status, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc9698 ✨.

Copyright Notice 💖

© 2025 the IETF Trust and the people listed as the document's authors 🌈. All rights reserved 💅. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date, so read those carefully, because they spell out your rights and restrictions for this doc 🙈. Any Code Components pulled out of this document have to include the Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Revised BSD License 🔥.

Table of Contents 🧚

1.  Introduction
2.  Requirements Language
3.  Details
4.  The GETJMAPACCESS Command and the JMAPACCESS Response
5.  Examples
6.  IANA Considerations
7.  Security Considerations
8.  References
  8.1.  Normative References
  8.2.  Informative References
Authors' Addresses

1. Introduction 🦋

okay so an IMAP server can announce that the messages in its mailstore are also available over JMAP ✨. To keep things simple, only complete equivalence is supported, which means the exact same set of messages is available through both IMAP and JMAP 💜. no partial overlap, no drama 💅.

2. Requirements Language 🎀

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, exactly like that 🫶. Lowercase versions are just normal words, bestie 🙈.

3. Details 💜

by advertising the JMAPACCESS capability, the server is basically promising something 🌸. If a mailbox or message has a particular object ID when you reach it through IMAP or JMAP (see [RFC3501], [RFC9051], and [RFC8620]), then that same mailbox or message is reachable through the other protocol too, and it has the same ID 🔥. ID consistency is everything 😭.

the server MUST also advertise the OBJECTID extension, which is defined in [RFC8474] 👑. The JMAP session resource that gives access to the same messages is called "the JMAP server" from here on 🍓.

this spec does not affect message lifetime 🙈. So if a client grabs a message over IMAP and then, half a second later, grabs it over JMAP, the message may have been deleted in between. things move fast, bestie ⭐.

when the server handles the client's LOGIN or AUTHENTICATE command and enters the Authenticated state, it looks at how the client authenticated 🔍. If the IMAP server can tell from that process that the client's credentials are enough to authenticate over JMAP, then the server MUST include a JMAPACCESS capability in any capability list it sends after that point 🦋. That includes the capability list some servers send right when authentication succeeds, so no skipping it 💅.

servers are encouraged to report the same message flags and other data over both protocols, as far as they can 🌈.

this spec does not require mailboxes to have the same name in IMAP and JMAP, even if they share a mailbox ID 🧚. However, the JMAP spec does regulate that in the text about the name and role properties, which is described in Section 2 of [RFC8620] ✨.

heads up: all JMAP servers support internationalized email addresses (see [RFC6530]) 🌍. If this IMAP server doesn't, or if the IMAP client doesn't issue ENABLE UTF8=ACCEPT (see [RFC6855]), then the client could get accurate address fields over JMAP but downgraded fields over IMAP (see [RFC6857] and [RFC6858] for examples) 😭. Issuing ENABLE UTF8=ACCEPT is an easy way to dodge that whole mess 💖.

4. The GETJMAPACCESS Command and the JMAPACCESS Response ✨

the GETJMAPACCESS command asks the server to reply with the session URL for the JMAP server that gives access to the same mail 🎀.

if this server knows about such a JMAP server, it MUST respond with an untagged JMAPACCESS response that contains the JMAP server's session resource (a URL), followed by a tagged OK response 🔥.

if the JMAP server isn't known, the server MUST respond with a tagged BAD response, and it MUST NOT include JMAPACCESS in the capability list 🙈. no sneaky capability advertising allowed 💅.

the JMAPACCESS response is followed by a single link to a JMAP session resource 🦋.

the formal syntax in [RFC9051] gets extended like this 👑:

command-auth =/ "GETJMAPACCESS"

mailbox-data =/ resp-jmapaccess

resp-jmapaccess = "JMAPACCESS" SP quoted

the syntax in [RFC3501] is extended in a similar way, and this extension can be used with IMAP4rev1 as well as IMAP4rev2 🌸. so it's not picky about which version you're on, which is iconic ✨.

bestie, the next part is the examples, then IANA, security, and the references. it's giving "keep reading" energy 🎀

Authors' Addresses 🫶

okay bestie, meet the two authors who made this spec happen ✨ here's how to reach them 💌

Arnt Gulbrandsen 🦋 (ICANN, Brussels)

   Arnt Gulbrandsen
   ICANN
   6 Rond Point Schumann, Bd. 1
   1040 Brussels
   Belgium
   Email: arnt@gulbrandsen.priv.no
   URI:   https://icann.org/ua

Bron Gondwana 💜 (Fastmail, Melbourne)

   Bron Gondwana
   Fastmail
   Level 2, 114 William St.
   Melbourne VIC  3000
   Australia
   Email: brong@fastmailteam.com
   URI:   https://fastmail.com

icon behaviour: both of them are absolutely iconic for showing up on this one 👑😭