]> ICANN

6 Rond Point Schumann, Bd. 1 Brussels 1040 Belgium arnt@gulbrandsen.priv.no https://icann.org/ua

Fastmail

Level 2, 114 William St. Melbourne VIC 3000 Australia brong@fastmailteam.com https://fastmail.com

Applications EXTRA IMAP JMAP 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.

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).

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 when, and only when, they appear in all capitals, as shown here.

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 , and ), 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 . 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. 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 ) and Oauth (see ) 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 section 2. Note that all JMAP servers support internationalized email addresses (see ). If this IMAP server does not, or the IMAP client does not issue ENABLE UTF8=ACCEPT (see ), then there is a possibility that the client receives accurate address fields via JMAP and downgraded fields via IMAP (see (see and for examples).

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 is extended thus: resp-code-jmap = "JMAPACCESS" SP string / "DEBUGGING" resp-text-code =/ resp-code-jmap Note that the link cannot contain a "]" character. The syntax in is extended similarly (this extension may be used with IMAP4rev1 as well as IMAP4rev2).

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

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.

References Normative References The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev1 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev1 also provides the capability for an offline client to resynchronize with the server. IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev1 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev1 supports a single server. A mechanism for accessing configuration information to support multiple IMAP4rev1 servers is discussed in RFC 2244. IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as RFC 2821. [STANDARDS-TRACK] This document updates RFC 3501 (IMAP4rev1) with persistent identifiers on mailboxes and messages to allow clients to more efficiently reuse cached data when resources have changed location on the server. The Internet Message Access Protocol Version 4rev2 (IMAP4rev2) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev2 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev2 also provides the capability for an offline client to resynchronize with the server. IMAP4rev2 includes operations for creating, deleting, and renaming mailboxes; checking for new messages; removing messages permanently; setting and clearing flags; parsing per RFCs 5322, 2045, and 2231; searching; and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev2 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev2 does not specify a means of posting mail; this function is handled by a mail submission protocol such as the one specified in RFC 6409. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References OTP provides a useful authentication mechanism for situations where there is limited client or server trust. Currently, OTP is added to protocols in an ad-hoc fashion with heuristic parsing. This specification defines an OTP SASL mechanism so it can be easily and formally integrated into many application protocols. [STANDARDS-TRACK] Full use of electronic mail throughout the world requires that (subject to other constraints) people be able to use close variations on their own names (written correctly in their own languages and scripts) as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. This document is a replacement for RFC 4952; it reflects additional issues identified since that document was published. [STANDARDS-TRACK] This specification extends the Internet Message Access Protocol (IMAP) to support UTF-8 encoded international characters in user names, mail addresses, and message headers. This specification replaces RFC 5738. The Email Address Internationalization (SMTPUTF8) extension to SMTP allows Unicode characters encoded in UTF-8 and outside the ASCII repertoire in mail header fields. Upgraded POP and IMAP servers support internationalized messages. If a POP or IMAP client does not support Email Address Internationalization, a POP or IMAP server cannot deliver internationalized messages to the client and cannot remove the message. To avoid that situation, this document describes a mechanism for converting internationalized messages into the traditional message format. As part of the conversion process, message elements that require internationalized treatment are recoded or removed, and receivers are able to recognize that they received messages containing such elements, even if they cannot process the internationalized elements. This document specifies a method for IMAP and POP servers to serve internationalized messages to conventional clients. The specification is simple, easy to implement, and provides only rudimentary results. OAuth enables a third-party application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction or by allowing the third-party application to obtain access on its own behalf. This document defines how an application client uses credentials obtained via OAuth over the Simple Authentication and Security Layer (SASL) to access a protected resource at a resource server. Thereby, it enables schemes defined within the OAuth framework for non-HTTP-based application protocols. Clients typically store the user's long-term credential. This does, however, lead to significant security vulnerabilities, for example, when such a credential leaks. A significant benefit of OAuth for usage in those clients is that the password is replaced by a shared secret with higher entropy, i.e., the token. Tokens typically provide limited access rights and can be managed and revoked separately from the user's long-term password. This document specifies a protocol for clients to efficiently query, fetch, and modify JSON-based data objects, with support for push notification of changes and fast resynchronisation and for out-of- band binary data upload/download.