Skip to main content

The JMAPACCESS Extension for IMAP

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Active".
Authors Arnt Gulbrandsen , Bron Gondwana
Last updated 2023-09-03 (Latest revision 2023-07-26)
RFC stream Internet Engineering Task Force (IETF)
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Document shepherd Jiankang Yao
Shepherd write-up Show Last changed 2023-08-11
IESG IESG state Waiting for AD Go-Ahead::Revised I-D Needed
Consensus boilerplate Yes
Telechat date (None)
Responsible AD Murray Kucherawy
Send notices to,
IANA IANA review state IANA OK - Actions Needed
IANA expert review state Expert Reviews OK
EXTRA                                                     A. Gulbrandsen
Internet-Draft                                                     ICANN
Intended status: Standards Track                             B. Gondwana
Expires: 27 January 2024                                        Fastmail
                                                            26 July 2023

                   The JMAPACCESS Extension for IMAP


   This document defines an IMAP extension to let clients know that the
   messages in this IMAP server are also available via JMAP, and how.
   It is intended for clients that want to migrate gradually to JMAP.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 27 January 2024.

Copyright Notice

   Copyright (c) 2023 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 (
   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.

Gulbrandsen & Gondwana   Expires 27 January 2024                [Page 1]
Internet-Draft               IMAP JMAPACCESS                   July 2023

Table of Contents

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

1.  Introduction

   A few IMAP client maintainers have asked for ways to use features
   that are available in JMAP without having to drop their expensively
   tested IMAP code.

   This document provides a server with a way to declare that the
   messages in its mailstore are also available via JMAP.  For
   simplicity, only a complete equivalence is supported (the same set of
   messages are available via both IMAP and JMAP).

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "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
   a mailbox or message has a particular object ID when accessed via
   either IMAP or JMAP (see [RFC3501], [RFC9051] and [RFC8620]), then
   the same mailbox or message is accessible via the other protocol, and
   it has the same ID.

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

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

Gulbrandsen & Gondwana   Expires 27 January 2024                [Page 2]
Internet-Draft               IMAP JMAPACCESS                   July 2023

   When the server processes the client's LOGIN/AUTHENTICATE command and
   enters Authenticated state, the server considers the way the client
   authenticated.  If the IMAP server can infer from the client's
   authentication process that its credentials suffice to authenticate
   via JMAP, then the server MUST also send a JMAPACCESS response code
   containing a link to the JMAP server.

   If the credentials might not succeed with the JMAP server, then the
   server SHOULD send an untagged OK response with a DEBUGGING response
   code with a message to help client developers understand why this
   authentication would not work with the JMAP server.

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

   This specification does not require mailboxes to have the same name
   in IMAP and JMAP, even if they share mailbox ID.  However, the JMAP
   specification regulates that, in the text about the name and role
   properties in [RFC8620] section 2.

   Note that all JMAP servers support internationalized email addresses
   (see [RFC6530]).  If this IMAP server does not, or the IMAP client
   does not issue ENABLE UTF8=ACCEPT (see [RFC6855]), then there is a
   possibility that the client receives accurate address fields via JMAP
   and downgraded fields via IMAP (see (see [RFC6857] and [RFC6858] for

4.  The JMAPACCESS and DEBUGGING Response Codes

   The JMAPACCESS response code is followed by a single link to a JMAP
   session resource.  The server/mailstore at that location is
   referenced as "the JMAP server" in this document.

   The DEBUGGING response code asserts that when used with a status
   response, the client may safely forward the string argument to the
   client maintainers.  The argument MUST NOT contain any message
   contents or other personal information.

   The formal syntax in [RFC9051] is extended thus:

   resp-code-jmapaccess = "JMAPACCESS" SP (atom / quoted)

   resp-code-debugging = "DEBUGGING" SP (atom / quoted)

   resp-text-code =/ resp-code-jmapaccess / resp-code-debugging

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

Gulbrandsen & Gondwana   Expires 27 January 2024                [Page 3]
Internet-Draft               IMAP JMAPACCESS                   July 2023

5.  Examples

   Lines sent by the client are preceded by C:, lines sent by the server
   by S:. Each example starts with the IMAP banner issued when the
   client connects, and generally contains only those capabilities
   required by the example itself, omitting even required capabilities

   Example 1.  A client connects, sees that SASL OAUTH is available, and
   authenticates in that way.


   The server processes the command successfully.  Since it knows that
   the client used Oauth, and that it and its JMAP alter ego use the
   same Oauth backend subsystem, the server infers that the (next)
   access token is just a usable via JMAP as via IMAP.  It issues a
   JMAPACCESS response code in its reply:

   S: 1 OK [JMAPACCESS] done

   SASL OAUTH is specified by [RFC7628], and the argument in this
   example is abbreviated from the more realistic length used in

   Example 2.  A client connects, sees no SASL method it recognises, and
   issues a LOGIN command.

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

   The server sees that the password is accepted, knows that it and its
   JMAP alter ego the same password database, and issues a JMAPACCESS
   response code:

   S: * OK [JMAPACCESS "[jmap]"] For JMAP access
   S: 2 OK done

   The URL is quoted since the ] character must be quoted.  The URL uses
   the same quoting rules as most other IMAP strings.

   Example 3.  A client connects, sees no SASL method it recognises, and
   issues a LOGIN command with a correct password.

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

Gulbrandsen & Gondwana   Expires 27 January 2024                [Page 4]
Internet-Draft               IMAP JMAPACCESS                   July 2023

   The server operator has decided to disable password use with JMAP,
   but allow it for a while with IMAP to cater to older clients.  The
   server issues a DEBUGGING response code in its reply:

   S: 3 OK [DEBUGGING "Cleartext passwords are being disabled"] done

   The message is quoted since it contains spaces.  The message uses the
   same quoting rules as most other IMAP strings.

   Example 4.  A client connects, sees no SASL method it recognises, and
   issues a LOGIN command.  Its password is incorrect.

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

   The server does not enter Authenticated state, so nothing requires it
   to issue either JMAPACCESS or DEBUGGING.  It replies curtly:

   S: 4 NO done

6.  IANA Considerations

   The IANA is requested to add the JMAPACCESS and DEBUGGING response
   codes to the IMAP Response Codes registry.

7.  Security Considerations

   DEBUGGING reveals to clients why they cannot auhenticate to the JMAP
   server.  One normally does not want to reveal anything about why a
   client cannot authenticate, for fear of giving useful information to
   an intruder.

   However, in this case the client has already authenticated via IMAP.
   By doing so the client already gained access to all of the same mail.
   The authors believe that the debugging value of the response code far
   outweighs its security concerns.

8.  References

8.1.  Normative References

              4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,

   [RFC8474]  Gondwana, B., Ed., "IMAP Extension for Object
              Identifiers", RFC 8474, DOI 10.17487/RFC8474, September
              2018, <>.

Gulbrandsen & Gondwana   Expires 27 January 2024                [Page 5]
Internet-Draft               IMAP JMAPACCESS                   July 2023

   [RFC9051]  Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message
              Access Protocol (IMAP) - Version 4rev2", RFC 9051,
              DOI 10.17487/RFC9051, August 2021,

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <>.

8.2.  Informative References

   [RFC6530]  Klensin, J. and Y. Ko, "Overview and Framework for
              Internationalized Email", RFC 6530, DOI 10.17487/RFC6530,
              February 2012, <>.

   [RFC6855]  Resnick, P., Ed., Newman, C., Ed., and S. Shen, Ed., "IMAP
              Support for UTF-8", RFC 6855, DOI 10.17487/RFC6855, March
              2013, <>.

   [RFC6857]  Fujiwara, K., "Post-Delivery Message Downgrading for
              Internationalized Email Messages", RFC 6857,
              DOI 10.17487/RFC6857, March 2013,

   [RFC6858]  Gulbrandsen, A., "Simplified POP and IMAP Downgrading for
              Internationalized Email", RFC 6858, DOI 10.17487/RFC6858,
              March 2013, <>.

   [RFC7628]  Mills, W., Showalter, T., and H. Tschofenig, "A Set of
              Simple Authentication and Security Layer (SASL) Mechanisms
              for OAuth", RFC 7628, DOI 10.17487/RFC7628, August 2015,

   [RFC8620]  Jenkins, N. and C. Newman, "The JSON Meta Application
              Protocol (JMAP)", RFC 8620, DOI 10.17487/RFC8620, July
              2019, <>.

Authors' Addresses

Gulbrandsen & Gondwana   Expires 27 January 2024                [Page 6]
Internet-Draft               IMAP JMAPACCESS                   July 2023

   Arnt Gulbrandsen
   6 Rond Point Schumann, Bd. 1
   1040 Brussels

   Bron Gondwana
   Level 2, 114 William St.
   Melbourne VIC  3000

Gulbrandsen & Gondwana   Expires 27 January 2024                [Page 7]