Status of This Memo

This is an Internet Standards Track document.¶

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc9698.¶

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document 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) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1.Introduction

An IMAP server can declare that the messages in its mailstore are alsoavailable via JMAP. For simplicity, only a complete equivalence issupported (the same set of messages are available via both IMAP andJMAP).¶

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 interpreted as described in BCP 14[RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3.Details

By advertising the JMAPACCESS capability, the server asserts that if amailbox or message has a particular object ID when accessed via eitherIMAP or JMAP (see[RFC3501],[RFC9051], and[RFC8620]), then thesame mailbox or message is accessible via the other protocol, and ithas the same ID.¶

The serverMUST also advertise the OBJECTID extension, defined by[RFC8474]. The JMAP session resource that allows access to the samemessages is called "the JMAP server" below.¶

This specification does not affect message lifetime: If a clientaccesses a message via IMAP and half a second later via JMAP, then themessage may have been deleted between the two accesses.¶

When the server processes the client's LOGIN/AUTHENTICATE command andenters Authenticated state, the server considers the way the clientauthenticated. If the IMAP server can infer from the client'sauthentication process that its credentials suffice to authenticatevia JMAP, then the serverMUST include a JMAPACCESS capability in anycapability list sent after that point. This includes the capabilitylist that some servers send immediately when authentication succeeds.¶

Servers are encouraged to report the same message flags and other datavia both protocols, as far as possible.¶

This specification does not require mailboxes to have the same name inIMAP and JMAP, even if they share a mailbox ID. However, the JMAPspecification regulates that in the text about the name and roleproperties described inSection 2 of [RFC8620].¶

Note that all JMAP servers support internationalized email addresses(see[RFC6530]). If this IMAP server does not or if the IMAP clientdoes not issue ENABLE UTF8=ACCEPT (see[RFC6855]), then it is possiblethat the client will receive accurate address fields via JMAPand downgraded fields via IMAP (see[RFC6857] and[RFC6858]for examples). Issuing ENABLE UTF8=ACCEPT is a simple way to sidestepthe issue.¶

4.The GETJMAPACCESS Command and the JMAPACCESS Response

The GETJMAPACCESS command requests that the server respond with the session URL for the JMAP server that provides access to the same mail.¶

If such a JMAP server is known to this server, the serverMUST respond with an untagged JMAPACCESS response containing the JMAP server's session resource (a URL) followed by a tagged OK response.¶

If such a JMAP server is not known, the serverMUST respond with a tagged BAD response (andMUST NOT include JMAPACCESS in the capability list).¶

The JMAPACCESS response is followed by a single link to a JMAP session resource.¶

The formal syntax in[RFC9051] is extended as follows:¶

command-auth =/ "GETJMAPACCESS"mailbox-data =/ resp-jmapaccessresp-jmapaccess = "JMAPACCESS" SP quoted

The syntax in[RFC3501] is extended similarly (this extension may beused with IMAP4rev1 as well as IMAP4rev2).¶

5.Examples

Lines sent by the client are preceded by C: and lines sent by the server are preceded by S:. Each example starts with the IMAP banner issued by the serveron connection, and generally abbreviates the capability lists towhat's required by the example itself.¶

Real connections use longer capability lists, much longer AUTHENTICATEarguments and of course use TLS. However, these examples focus on JMAPACCESS.¶

Example 1:¶

A client connects, sees that SASL OAuth[RFC7628] is available, andauthenticates in that way.¶

S: * OK [CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR] example1C: 1 AUTHENTICATE OAUTHBEARER bixhPXVzZ...QEB

The server processes the command successfully. It knows that theclient used OAuth, and that it and its JMAP alter ego use the sameOAuth backend subsystem. Because of that it infers that the (next)access token is just as usable via JMAP as via IMAP. It includes aJMAPACCESS capability in its reply (again, real capability lists are much longer):¶

S: 1 OK [CAPABILITY IMAP4rev1 JMAPACCESS] doneC: 1b GETJMAPACCESSS: * JMAPACCESS "https://example.com/.well-known/jmap"S: 1b OK done

SASL OAuth is specified by[RFC7628], and the argument in thisexample is abbreviated from the more realistic length used in RFC 7628.¶

Example 2:¶

A client connects, sees no SASL method it recognizes, andissues a LOGIN command.¶

S: * OK [CAPABILITY IMAP4rev2] example2C: 2 LOGIN "arnt" "trondheim"

The server sees that the password is accepted, knows that it and itsJMAP alter ego use the same password database, and issues a JMAPACCESScapability:¶

   S: * OK [CAPABILITY IMAP4rev2 JMAPACCESS] done   S: 2 OK done   C: 2b JMAPACCESS   S: * JMAPACCESS "https://example.com/.well-known/jmap"   S: 2b OK done

The URL uses the same quoting rules as most other IMAP strings.¶

Example 3:¶

A client connects, sees no SASL method it recognizes, andissues a LOGIN command with a correct password.¶

S: * OK [CAPABILITY IMAP4rev1 IMAP4rev2] example3C: 3 LOGIN "arnt" "trondheim"

The server operator has decided to disable password use with JMAP, butallow it for a while with IMAP to cater to older clients. Therefore, the loginsucceeds, but there is no JMAPACCESS capability.¶

S: 3 OK done

Example 4:¶

A client connects, sees no SASL method it recognizes, andissues a LOGIN command. Its password is incorrect.¶

S: * OK [CAPABILITY IMAP4rev2 AUTH=GSS] example4C: 4 LOGIN "arnt" "oslo"

The server does not enter Authenticated state, so nothing requires itto mention JMAPACCESS. It replies curtly:¶

S: 4 NO done

6.IANA Considerations

The IANA has added the JMAPACCESS capability to the "Internet Message Access Protocol (IMAP) Capabilities Registry" and listed this document as the reference.¶

7.Security Considerations

JMAPACCESS reveals to authenticated IMAP clients thatthey would be able to authenticate via JMAP using the same credentialsand that the object IDs match.¶

One does not normally reveal anything at all about authentication.However, if the client is an attacker, then the attacker is known tohave valid credentials, andSection 2.2 of [RFC8620] tells the attackerhow to find the revealed URL without the help of this extension.Therefore, it is believed that this document does notbenefit an attacker noticeably, and its value for migration far outweighsits risk.¶

Authors' Addresses