5Internet Engineering Task Force (IETF) A. Gulbrandsen
6Request for Comments: 9698 ICANN
7Category: Standards Track B. Gondwana
8ISSN: 2070-1721 Fastmail
12 The JMAPACCESS Extension for IMAP
16 This document defines an IMAP extension to let clients know that the
17 messages in this IMAP server are also available via the JSON Meta
18 Application Protocol (JMAP), and how. It is intended for clients
19 that want to migrate gradually to JMAP or use JMAP extensions within
24 This is an Internet Standards Track document.
26 This document is a product of the Internet Engineering Task Force
27 (IETF). It represents the consensus of the IETF community. It has
28 received public review and has been approved for publication by the
29 Internet Engineering Steering Group (IESG). Further information on
30 Internet Standards is available in Section 2 of RFC 7841.
32 Information about the current status of this document, any errata,
33 and how to provide feedback on it may be obtained at
34 https://www.rfc-editor.org/info/rfc9698.
38 Copyright (c) 2025 IETF Trust and the persons identified as the
39 document authors. All rights reserved.
41 This document is subject to BCP 78 and the IETF Trust's Legal
42 Provisions Relating to IETF Documents
43 (https://trustee.ietf.org/license-info) in effect on the date of
44 publication of this document. Please review these documents
45 carefully, as they describe your rights and restrictions with respect
46 to this document. Code Components extracted from this document must
47 include Revised BSD License text as described in Section 4.e of the
48 Trust Legal Provisions and are provided without warranty as described
49 in the Revised BSD License.
54 2. Requirements Language
56 4. The GETJMAPACCESS Command and the JMAPACCESS Response
58 6. IANA Considerations
59 7. Security Considerations
61 8.1. Normative References
62 8.2. Informative References
67 An IMAP server can declare that the messages in its mailstore are
68 also available via JMAP. For simplicity, only a complete equivalence
69 is supported (the same set of messages are available via both IMAP
722. Requirements Language
74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
76 "OPTIONAL" in this document are to be interpreted as described in
77 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
78 capitals, as shown here.
82 By advertising the JMAPACCESS capability, the server asserts that if
83 a mailbox or message has a particular object ID when accessed via
84 either IMAP or JMAP (see [RFC3501], [RFC9051], and [RFC8620]), then
85 the same mailbox or message is accessible via the other protocol, and
88 The server MUST also advertise the OBJECTID extension, defined by
89 [RFC8474]. The JMAP session resource that allows access to the same
90 messages is called "the JMAP server" below.
92 This specification does not affect message lifetime: If a client
93 accesses a message via IMAP and half a second later via JMAP, then
94 the message may have been deleted between the two accesses.
96 When the server processes the client's LOGIN/AUTHENTICATE command and
97 enters Authenticated state, the server considers the way the client
98 authenticated. If the IMAP server can infer from the client's
99 authentication process that its credentials suffice to authenticate
100 via JMAP, then the server MUST include a JMAPACCESS capability in any
101 capability list sent after that point. This includes the capability
102 list that some servers send immediately when authentication succeeds.
104 Servers are encouraged to report the same message flags and other
105 data via both protocols, as far as possible.
107 This specification does not require mailboxes to have the same name
108 in IMAP and JMAP, even if they share a mailbox ID. However, the JMAP
109 specification regulates that in the text about the name and role
110 properties described in Section 2 of [RFC8620].
112 Note that all JMAP servers support internationalized email addresses
113 (see [RFC6530]). If this IMAP server does not or if the IMAP client
114 does not issue ENABLE UTF8=ACCEPT (see [RFC6855]), then it is
115 possible that the client will receive accurate address fields via
116 JMAP and downgraded fields via IMAP (see [RFC6857] and [RFC6858] for
117 examples). Issuing ENABLE UTF8=ACCEPT is a simple way to sidestep
1204. The GETJMAPACCESS Command and the JMAPACCESS Response
122 The GETJMAPACCESS command requests that the server respond with the
123 session URL for the JMAP server that provides access to the same
126 If such a JMAP server is known to this server, the server MUST
127 respond with an untagged JMAPACCESS response containing the JMAP
128 server's session resource (a URL) followed by a tagged OK response.
130 If such a JMAP server is not known, the server MUST respond with a
131 tagged BAD response (and MUST NOT include JMAPACCESS in the
134 The JMAPACCESS response is followed by a single link to a JMAP
137 The formal syntax in [RFC9051] is extended as follows:
139 command-auth =/ "GETJMAPACCESS"
141 mailbox-data =/ resp-jmapaccess
143 resp-jmapaccess = "JMAPACCESS" SP quoted
145 The syntax in [RFC3501] is extended similarly (this extension may be
146 used with IMAP4rev1 as well as IMAP4rev2).
150 Lines sent by the client are preceded by C: and lines sent by the
151 server are preceded by S:. Each example starts with the IMAP banner
152 issued by the server on connection, and generally abbreviates the
153 capability lists to what's required by the example itself.
155 Real connections use longer capability lists, much longer
156 AUTHENTICATE arguments and of course use TLS. However, these
157 examples focus on JMAPACCESS.
161 A client connects, sees that SASL OAuth [RFC7628] is available, and
162 authenticates in that way.
164 S: * OK [CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR] example1
165 C: 1 AUTHENTICATE OAUTHBEARER bixhPXVzZ...QEB
167 The server processes the command successfully. It knows that the
168 client used OAuth, and that it and its JMAP alter ego use the same
169 OAuth backend subsystem. Because of that it infers that the (next)
170 access token is just as usable via JMAP as via IMAP. It includes a
171 JMAPACCESS capability in its reply (again, real capability lists are
174 S: 1 OK [CAPABILITY IMAP4rev1 JMAPACCESS] done
176 S: * JMAPACCESS "https://example.com/.well-known/jmap"
179 SASL OAuth is specified by [RFC7628], and the argument in this
180 example is abbreviated from the more realistic length used in RFC
185 A client connects, sees no SASL method it recognizes, and issues a
188 S: * OK [CAPABILITY IMAP4rev2] example2
189 C: 2 LOGIN "arnt" "trondheim"
191 The server sees that the password is accepted, knows that it and its
192 JMAP alter ego use the same password database, and issues a
193 JMAPACCESS capability:
195 S: * OK [CAPABILITY IMAP4rev2 JMAPACCESS] done
198 S: * JMAPACCESS "https://example.com/.well-known/jmap"
201 The URL uses the same quoting rules as most other IMAP strings.
205 A client connects, sees no SASL method it recognizes, and issues a
206 LOGIN command with a correct password.
208 S: * OK [CAPABILITY IMAP4rev1 IMAP4rev2] example3
209 C: 3 LOGIN "arnt" "trondheim"
211 The server operator has decided to disable password use with JMAP,
212 but allow it for a while with IMAP to cater to older clients.
213 Therefore, the login succeeds, but there is no JMAPACCESS capability.
219 A client connects, sees no SASL method it recognizes, and issues a
220 LOGIN command. Its password is incorrect.
222 S: * OK [CAPABILITY IMAP4rev2 AUTH=GSS] example4
223 C: 4 LOGIN "arnt" "oslo"
225 The server does not enter Authenticated state, so nothing requires it
226 to mention JMAPACCESS. It replies curtly:
2306. IANA Considerations
232 The IANA has added the JMAPACCESS capability to the "Internet Message
233 Access Protocol (IMAP) Capabilities Registry" and listed this
234 document as the reference.
2367. Security Considerations
238 JMAPACCESS reveals to authenticated IMAP clients that they would be
239 able to authenticate via JMAP using the same credentials and that the
242 One does not normally reveal anything at all about authentication.
243 However, if the client is an attacker, then the attacker is known to
244 have valid credentials, and Section 2.2 of [RFC8620] tells the
245 attacker how to find the revealed URL without the help of this
246 extension. Therefore, it is believed that this document does not
247 benefit an attacker noticeably, and its value for migration far
2528.1. Normative References
254 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
255 Requirement Levels", BCP 14, RFC 2119,
256 DOI 10.17487/RFC2119, March 1997,
257 <https://www.rfc-editor.org/info/rfc2119>.
259 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
260 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
261 <https://www.rfc-editor.org/info/rfc3501>.
263 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
264 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
265 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
267 [RFC8474] Gondwana, B., Ed., "IMAP Extension for Object
268 Identifiers", RFC 8474, DOI 10.17487/RFC8474, September
269 2018, <https://www.rfc-editor.org/info/rfc8474>.
271 [RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message
272 Access Protocol (IMAP) - Version 4rev2", RFC 9051,
273 DOI 10.17487/RFC9051, August 2021,
274 <https://www.rfc-editor.org/info/rfc9051>.
2768.2. Informative References
278 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for
279 Internationalized Email", RFC 6530, DOI 10.17487/RFC6530,
280 February 2012, <https://www.rfc-editor.org/info/rfc6530>.
282 [RFC6855] Resnick, P., Ed., Newman, C., Ed., and S. Shen, Ed., "IMAP
283 Support for UTF-8", RFC 6855, DOI 10.17487/RFC6855, March
284 2013, <https://www.rfc-editor.org/info/rfc6855>.
286 [RFC6857] Fujiwara, K., "Post-Delivery Message Downgrading for
287 Internationalized Email Messages", RFC 6857,
288 DOI 10.17487/RFC6857, March 2013,
289 <https://www.rfc-editor.org/info/rfc6857>.
291 [RFC6858] Gulbrandsen, A., "Simplified POP and IMAP Downgrading for
292 Internationalized Email", RFC 6858, DOI 10.17487/RFC6858,
293 March 2013, <https://www.rfc-editor.org/info/rfc6858>.
295 [RFC7628] Mills, W., Showalter, T., and H. Tschofenig, "A Set of
296 Simple Authentication and Security Layer (SASL) Mechanisms
297 for OAuth", RFC 7628, DOI 10.17487/RFC7628, August 2015,
298 <https://www.rfc-editor.org/info/rfc7628>.
300 [RFC8620] Jenkins, N. and C. Newman, "The JSON Meta Application
301 Protocol (JMAP)", RFC 8620, DOI 10.17487/RFC8620, July
302 2019, <https://www.rfc-editor.org/info/rfc8620>.
308 6 Rond Point Schumann, Bd. 1
311 Email: arnt@gulbrandsen.priv.no
312 URI: https://icann.org/ua
317 Level 2, 114 William St.
320 Email: brong@fastmailteam.com
321 URI: https://fastmail.com