Summary

  • RFC 9698 lets an authenticated IMAP server advertise a JMAP route to the same complete mail set, with matching object identifiers and credentials it can infer are sufficient for JMAP.
  • That assertion does not freeze a message's lifetime, complete a later login or guarantee identical fields. A migration decision needs evidence from each of those boundaries.
  • Verified erratum 8635 fixes a command in an example: clients request the address with GETJMAPACCESS; JMAPACCESS names the capability and response.

The least disruptive migration may begin inside the connection already serving the customer. A mail client has authenticated to IMAP, built a cache and learned the identity of its messages. Asking that customer to configure another service, prove the account again and wait for a second download makes a better protocol feel like a worse product.

RFC 9698 offers a modest bridge. It lets the IMAP server disclose a JMAP Session address and make a correspondence claim about the mail on the other side. Published in January 2025 and listed as a Proposed Standard, it supports gradual migration and the use of JMAP extensions inside an IMAP client. It does not announce that migration has happened.

A promise with three parts

The first part concerns coverage. The extension supports complete equivalence: both protocols provide the same set of messages. A service exposing only a convenient subset through JMAP has not met that description merely because the two interfaces belong to one vendor.

The second concerns credentials. After successful LOGIN or AUTHENTICATE, the server considers how the client authenticated. If it can infer that those credentials suffice for JMAP, subsequent capability lists must include JMAPACCESS. The inference is therefore attached to the authentication path, not simply to a hostname with two protocol listeners.

The RFC's examples make the distinction tangible. Shared OAuth infrastructure or a shared password database can support the inference. An operator can instead retain passwords temporarily for older IMAP clients while disabling them for JMAP. The IMAP login then succeeds without the capability appearing. Its absence is not, by itself, evidence that no JMAP service exists.

The third part is matching object identifiers. A mailbox or message identified through one protocol must be accessible as that same object with the same identifier through the other. The server must also advertise OBJECTID. These are the object identifiers defined for IMAP by RFC 8474, not ordinary mailbox-scoped UIDs promoted to universal names.

That distinction can save real work in a design without establishing a measured saving. A client need not rediscover identity solely by comparing downloaded bodies or mutable folder names. But a valid correspondence remains meaningful only in context. JMAP's core specification scopes record-ID uniqueness to a data type within an account. A reconciliation record should therefore retain the account and object type, not just an attractive string that happens to match.

The address is the beginning of another exchange

The client asks for the route with GETJMAPACCESS. If the IMAP server knows the corresponding JMAP service, it returns an untagged JMAPACCESS response containing one Session URL and then a tagged OK. If it does not know one, the result is tagged BAD, and the capability must not be advertised.

There is a small documentary trap here. Example 2 originally used JMAPACCESS as the command. Technical erratum 8635, verified on 21 November 2025, changes it to GETJMAPACCESS. That is a correction to an example, not evidence of a deployed vulnerability or a revised authentication scheme.

The returned URL names the JMAP Session resource. A successful authenticated GET there yields the Session object describing available accounts and capabilities for the supplied credentials. Discovering the address and completing that request are different observations. The extension does not mint a credential or carry a later authentication response backward in time.

Its security argument is bounded too. RFC 9698 reasons that a client has already authenticated and that JMAP's existing discovery procedure can reveal the address independently; the added disclosure is consequently thought to offer little extra help to an attacker. That reasoning does not certify an operator's endpoint, credential policy or transport configuration. The ordinary JMAP security obligations remain.

The same object can have changed before the second look

A message found through IMAP may be deleted before JMAP is asked for it. RFC 9698 expressly leaves message lifetime alone. Two reads separated by half a second are not an atomic snapshot. A missing second result therefore calls for timing and deletion evidence before anyone labels it a broken identity mapping.

Fields require similar care. The extension encourages servers to align flags and other data as far as possible; it does not itself require identical mailbox names. Other applicable rules still matter. JMAP Mail defines mailbox names, roles, memberships and keywords. Its model can keep an Email ID stable across mailbox moves and can place one email in multiple mailboxes. The useful comparison follows the field's semantics, not the visual layout of two clients.

RFC 8474 makes another limit explicit: EMAILID identifies immutable content, while instances sharing it may have different keywords. Identity evidence cannot silently become proof that every mutable state or pending action is equivalent.

Internationalized addresses expose the cost of that mistake. In the legacy IMAP circumstances described by RFC 9698, a client that has not enabled UTF8=ACCEPT may receive downgraded address fields while JMAP supplies the accurate fields. RFC 6855 explains why such surrogates are not interchangeable with their originals, including possible effects on replying and signature verification. Matching IDs cannot repair a comparison made between different representations.

A bridge that remains small

Lu Heng's Minimum Initial Specification supplies a useful editorial lens: define the common invariant, while leaving operational decisions with participants. Running-Code Primacy asks whether that agreement has become behavior in running systems. Reality Layers cautions against allowing a declaration to stand in for its execution.

Applied here, the result is a practical sequence: capability observed, Session address obtained, JMAP authentication completed, account and object matched, current representation reconciled, intended action verified. These are proposed operating records, not additional RFC requirements. No provider implementation, migration measurement or incident was tested for this report. The standard makes the handoff easier to attempt; only the participating systems can show what survived it.