EXTRA A. Gulbrandsen Internet-Draft ICANN Intended status: Standards Track B. Gondwana Expires: 20 July 2023 Fastmail 16 January 2023 The JMAPACCESS Extension for IMAP draft-ietf-extra-jmapaccess-02 Abstract 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 https://datatracker.ietf.org/drafts/current/. 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 20 July 2023. 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 (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. Gulbrandsen & Gondwana Expires 20 July 2023 [Page 1] Internet-Draft IMAP JMAPACCESS January 2023 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 3. Details . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 4. The JMAPACCESS and DEBUGGING Response Codes . . . . . . . . . 3 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 7.2. Informative References . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 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", "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 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 20 July 2023 [Page 2] Internet-Draft IMAP JMAPACCESS January 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 same authentication would work with the JMAP server, then the server MUST also send an untagged OK response with a JMAPACCESS response code containing a link to the JMAP server. If the authentication would not succeed with the JMAP server, then the server SHOULD send an untagged OK response with a DEBUGGING response code and some human-readable text to help client developers understand why this authentication would not work with the JMAP server. Some authentication methods use tokens that change depending on time or sequence. One-time passwords (see [RFC2444]) and Oauth (see [RFC7628]) are good examples. In these cases, JMAPACCESS requires that this server and the JMAP server use the same sequence. To take Oauth as an example, an access token is equally valid with both protocols, no matter which server issued it. 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 examples). 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 human-readable text to the client maintainers. The human-readable text MUST NOT contain any message contents or other personal information. The formal syntax in [RFC9051] is extended thus: resp-code-jmap = "JMAPACCESS" SP string / "DEBUGGING" Gulbrandsen & Gondwana Expires 20 July 2023 [Page 3] Internet-Draft IMAP JMAPACCESS January 2023 resp-text-code =/ resp-code-jmap Note that the link cannot contain a "]" character. The syntax in [RFC3501] is extended similarly (this extension may be used with IMAP4rev1 as well as IMAP4rev2). 5. IANA Considerations The IANA is requested to add the JMAPACCESS and DEBUGGING response codes to the IMAP Response Codes registry. 6. Security Considerations This extension 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 OK response far outweighs its security concerns. 7. References 7.1. Normative References [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 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, . [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, . Gulbrandsen & Gondwana Expires 20 July 2023 [Page 4] Internet-Draft IMAP JMAPACCESS January 2023 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 7.2. Informative References [RFC2444] Newman, C., "The One-Time-Password SASL Mechanism", RFC 2444, DOI 10.17487/RFC2444, October 1998, . [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 Arnt Gulbrandsen ICANN 6 Rond Point Schumann, Bd. 1 1040 Brussels Belgium Email: arnt@gulbrandsen.priv.no URI: https://icann.org/ua Gulbrandsen & Gondwana Expires 20 July 2023 [Page 5] Internet-Draft IMAP JMAPACCESS January 2023 Bron Gondwana Fastmail Level 2, 114 William St. Melbourne VIC 3000 Australia Email: brong@fastmailteam.com URI: https://fastmail.com Gulbrandsen & Gondwana Expires 20 July 2023 [Page 6]