]> Stalwart Labs LLC

1309 Coffeen Avenue, Suite 1200 Sheridan WY 82801 USA mauro@stalw.art https://stalw.art

mailmaint Internet-Draft This document extends the IMAP OBJECTID extension (RFC 8474) to support account identifiers, enabling IMAP servers to provide account-level context for mailboxes when multiple accounts are accessible through a single IMAP connection. This extension is particularly relevant for environments where IMAP mailboxes include shared mailboxes from multiple JMAP accounts, as defined in the JSON Meta Application Protocol (JMAP). By introducing the ACCOUNTID object identifier, this specification ensures that mailboxes can be uniquely identified across different accounts in both IMAP and JMAP contexts, thereby facilitating seamless interoperability between the two protocols in multi-account scenarios.

Introduction The IMAP OBJECTID extension, defined in , provides persistent identifiers for mailboxes (MAILBOXID) and messages (EMAILID and THREADID) within an IMAP server. These identifiers enable clients to efficiently track and reference resources even when they are moved or renamed, thereby reducing the need for redundant data synchronization operations. The JMAPACCESS extension for IMAP, specified in , establishes a mechanism by which IMAP clients can discover that the messages and mailboxes accessible via IMAP are also available through JMAP (the JSON Meta Application Protocol, as defined in ). When an IMAP server advertises the JMAPACCESS capability, it asserts that mailboxes and messages share the same object identifiers across both protocols. This allows clients to migrate gradually to JMAP or to leverage JMAP-specific features while continuing to use IMAP as their primary access method. The JMAP Email Delivery Push extension extends JMAP's push notification capabilities to deliver EmailPush objects containing specific email properties directly to clients when new messages arrive. These push notifications include the accountId property, which identifies the JMAP account to which the delivered email belongs. This account-level identification is essential for clients managing multiple accounts, as it allows them to properly route notifications and display relevant information to users without requiring additional synchronization requests. In JMAP, an authenticated user may have access to multiple accounts, each containing distinct sets of mailboxes and messages. Each account is identified by a unique accountId, which serves as a namespace for all objects within that account. The accountId is a fundamental concept in JMAP architecture, as it allows servers to represent different data stores, organizational units, or delegation scenarios within a single authenticated session. For instance, a user might have access to their personal account, one or more shared team accounts, and delegated accounts from other users. The JMAPACCESS extension, as currently specified in , implicitly assumes that all IMAP mailboxes accessible to an authenticated user correspond to a single JMAP account. Consequently, when object identifiers are exchanged between IMAP and JMAP, the accountId is omitted from the IMAP representation, as it is presumed to be constant. This assumption holds true in the majority of deployment scenarios, where a user's IMAP connection maps directly to their primary JMAP account. However, this assumption breaks down in environments where an IMAP session provides access to mailboxes from multiple JMAP accounts. Such scenarios commonly arise when users access shared mailboxes, delegated folders, or organizational resources that exist within separate JMAP accounts but are presented as part of a unified IMAP mailbox hierarchy. In these cases, the MAILBOXID alone is insufficient to uniquely identify a mailbox across the IMAP-JMAP boundary, because different JMAP accounts may theoretically use the same MAILBOXID for different mailboxes. This ambiguity becomes particularly problematic when considering the JMAP Email Delivery Push extension. When a client receives an EmailPush notification containing an accountId and a mailbox identifier, it needs to correlate this information with its IMAP representation of the mailbox. Without an accountId in the IMAP context, the client cannot definitively determine which JMAP account a given IMAP mailbox belongs to, potentially leading to incorrect mailbox associations, failed synchronization attempts, or inability to properly handle push notifications for shared mailboxes. The motivation for this specification is to extend the OBJECTID framework to include account-level identification in IMAP, thereby enabling precise correlation of mailboxes across IMAP and JMAP protocols in multi-account environments. By introducing the ACCOUNTID object identifier, this extension ensures that clients can unambiguously identify the JMAP account associated with each IMAP mailbox, facilitating interoperability and enabling advanced features such as account-aware push notifications.

Notational Conventions 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.

ACCOUNTID Object Identifier The ACCOUNTID is a server-allocated identifier that specifies the JMAP account to which a mailbox belongs. When used in conjunction with the MAILBOXID, the ACCOUNTID provides complete disambiguation of mailboxes in environments where multiple JMAP accounts are accessible through a single IMAP session. The ACCOUNTID is represented as an opaque string using the same character set and syntactic constraints as the MAILBOXID, as defined in . That is, an ACCOUNTID MUST consist of between 1 and 255 characters from the base64url alphabet defined in , excluding the padding character. The server MUST ensure that for any mailbox accessible via both IMAP and JMAP, the ACCOUNTID returned via IMAP matches the accountId property of the corresponding Mailbox object in JMAP, as defined in . This correspondence is essential for clients to correlate mailboxes across the two protocols. The server MUST return the same ACCOUNTID for all mailboxes that belong to the same JMAP account. Conversely, the server MUST NOT return the same ACCOUNTID for mailboxes that belong to different JMAP accounts, even if accessed within the same IMAP session. When a mailbox is accessed exclusively through IMAP and does not have a corresponding representation in JMAP (for instance, if the server does not support the JMAPACCESS extension), the server MAY still assign an ACCOUNTID to maintain consistency in the IMAP representation. However, such ACCOUNTIDs need not correspond to any JMAP account identifier. If a server advertises both "OBJECTID=ACCOUNTID" and "JMAPACCESS" capabilities, clients can rely on the ACCOUNTID to determine the appropriate JMAP account context for operations involving the mailbox. This is particularly important when handling JMAP Email Delivery Push notifications, as described in the introduction, where the accountId field in an EmailPush object can be correlated with the ACCOUNTID of the corresponding IMAP mailbox. The ACCOUNTID is conceptually immutable for a given JMAP account within an IMAP session. However, if the underlying JMAP account is deleted or the user's access to that account is revoked, the associated mailboxes will no longer be accessible via IMAP, and their ACCOUNTIDs become irrelevant. If a new account is subsequently created with the same accountId, and mailboxes from that account become accessible via IMAP, the server MAY reuse the same ACCOUNTID value.

New Response Code for CREATE This document extends the CREATE command to include the ACCOUNTID in the response code on successful mailbox creation, in addition to the MAILBOXID response code defined in . A server advertising the "OBJECTID=ACCOUNTID" capability MUST include both the MAILBOXID and ACCOUNTID response codes in the tagged OK response to all successful CREATE commands. Syntax: "ACCOUNTID" SP "(" objectid ")" This is a response code in the tagged OK response for a successful CREATE command. The objectid uses the same syntax as defined for MAILBOXID in . Example:

In this example, the mailbox "foo" is created in account "u1a48e8e3", while the shared mailbox "shared/team" is created in a different account "u2b59f9f4". This demonstrates how mailboxes within the same IMAP session can belong to different JMAP accounts.

New OK Untagged Response for SELECT and EXAMINE This document adds the ACCOUNTID response code to the untagged OK responses returned by the SELECT and EXAMINE commands, complementing the MAILBOXID response code defined in . A server advertising the "OBJECTID=ACCOUNTID" capability MUST return an untagged OK response with both the MAILBOXID and ACCOUNTID response codes on all successful SELECT and EXAMINE commands. Syntax: "OK" SP "[" "ACCOUNTID" SP "(" objectid ")" "]" SP text This is an untagged OK response to SELECT or EXAMINE commands. Example:

This example shows how clients can determine the account context when selecting different mailboxes, even within the same IMAP session.

New Attribute for STATUS This document adds the ACCOUNTID attribute to the STATUS command using the extended syntax defined in , in parallel with the MAILBOXID attribute defined in . A server that advertises the "OBJECTID=ACCOUNTID" capability MUST support the ACCOUNTID status attribute. Syntax: "ACCOUNTID" This is the attribute name used in the STATUS command. Syntax: "ACCOUNTID" SP "(" objectid ")" This is the response item in the STATUS response, containing the account identifier assigned by the server for the mailbox. Example:

This example demonstrates how clients can efficiently retrieve both mailbox and account identifiers for multiple mailboxes using the extended LIST command with STATUS return option, as defined in .

Implementation Considerations The implementation considerations specified in apply equally to the ACCOUNTID object identifier defined in this specification. In particular, the ACCOUNTID is generated and managed entirely by the server. Clients MUST NOT attempt to construct, modify, or interpret the internal structure of an ACCOUNTID value. The ACCOUNTID MUST be treated as an opaque identifier whose only meaningful operation is equality comparison. Servers SHOULD generate ACCOUNTIDs using mechanisms that ensure global uniqueness across all accounts within the server's administrative domain, similar to the recommendations for MAILBOXID generation. Suitable approaches include Universally Unique Identifiers (UUIDs) as defined in , or server-assigned sequence numbers that are guaranteed never to be reused. When both "OBJECTID=ACCOUNTID" and "JMAPACCESS" capabilities are advertised, servers MUST ensure that the ACCOUNTID values correspond exactly to the accountId values used in the JMAP protocol. This correspondence is essential for clients that need to correlate IMAP mailboxes with their JMAP representations, particularly when handling JMAP Email Delivery Push notifications. Servers that provide access to mailboxes from multiple JMAP accounts through a single IMAP session SHOULD advertise the "OBJECTID=ACCOUNTID" capability to enable clients to distinguish between accounts. However, servers that provide access only to mailboxes from a single JMAP account MAY choose not to advertise this capability, as the account context is unambiguous in such cases. Clients that support both IMAP and JMAP SHOULD use the ACCOUNTID when available to maintain accurate mappings between IMAP mailboxes and JMAP Mailbox objects. This is particularly important for clients that use JMAP Email Delivery Push notifications, as these notifications include the accountId property. By correlating the accountId from a push notification with the ACCOUNTID of IMAP mailboxes, clients can efficiently determine which IMAP mailbox corresponds to a newly delivered message without requiring additional synchronization operations. Clients SHOULD be prepared to handle IMAP servers that do not advertise "OBJECTID=ACCOUNTID", even when the server advertises "JMAPACCESS". In such cases, clients MAY assume that all accessible mailboxes belong to a single JMAP account, though this assumption may lead to incorrect behavior if the server subsequently exposes mailboxes from additional accounts.

Security Considerations The security considerations specified in and apply to this specification. The introduction of the ACCOUNTID object identifier does not fundamentally alter the security properties of the IMAP protocol or the OBJECTID extension. However, implementers should consider the following additional points.

Account Identifier Exposure The ACCOUNTID reveals information about the account structure of the server and which mailboxes belong to which accounts. While this information is generally not considered sensitive in the context of an authenticated IMAP session, servers that wish to minimize information disclosure MAY choose to generate ACCOUNTIDs using unpredictable values (such as UUIDs) rather than sequential numbers or other patterns that might reveal information about account creation order or the total number of accounts on the server.

Cross-Account Information Leakage Servers MUST ensure that the ACCOUNTID mechanism does not inadvertently grant users access to information about accounts they are not authorized to access. In particular, servers MUST NOT return ACCOUNTID values for accounts that the authenticated user does not have permission to access, even if such accounts exist on the server.

Consistency with JMAP Authentication When a server advertises both "OBJECTID=ACCOUNTID" and "JMAPACCESS" capabilities, the server MUST ensure that the same authentication credentials used for the IMAP session would grant access to the corresponding JMAP accounts. Inconsistencies in authentication or authorization between IMAP and JMAP could lead to situations where a client receives ACCOUNTIDs that it cannot subsequently use to access the corresponding JMAP resources, potentially revealing the existence of accounts the user cannot access.

Digest-Based Identifier Generation If servers use cryptographic digests to generate ACCOUNTIDs, the security considerations regarding collision resistance and algorithm selection discussed in apply. Servers SHOULD monitor current security research and use digest algorithms that provide adequate collision resistance.

Privacy in Multi-Tenant Environments In multi-tenant or hosted environments, servers SHOULD generate ACCOUNTIDs in a manner that does not reveal relationships between accounts or organizational structures that users should not be aware of. For example, if multiple accounts belong to the same organization, the ACCOUNTID generation mechanism should not use patterns that would allow users to infer these relationships unless such information is explicitly intended to be visible.

Other Considerations See also the security considerations in , , and .

IANA Considerations

IMAP Capabilities Registry IANA is requested to add the following capability to the "Internet Message Access Protocol (IMAP) Capabilities Registry" located at https://www.iana.org/assignments/imap-capabilities: Capability name: OBJECTID=ACCOUNTID
Reference: this document

IMAP Response Codes Registry IANA is requested to add the following response code to the "IMAP Response Codes" registry located at https://www.iana.org/assignments/imap-response-codes: Response code: ACCOUNTID
Reference: this document

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. 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. This document defines an IMAP extension to let clients know that the messages in this IMAP server are also available via the JSON Meta Application Protocol (JMAP), and how. It is intended for clients that want to migrate gradually to JMAP or use JMAP extensions within an IMAP client. Over the years, many documents from IMAPEXT and LEMONADE working groups, as well as many individual documents, have added syntactic extensions to many base IMAP commands described in RFC 3501. For ease of reference, this document collects most of such ABNF changes in one place. This document also suggests a set of standard patterns for adding options and extensions to several existing IMAP commands defined in RFC 3501. The patterns provide for compatibility between existing and future extensions. This document updates ABNF in RFCs 2088, 2342, 3501, 3502, and 3516. It also includes part of the errata to RFC 3501. This document doesn't specify any semantic changes to the listed RFCs. [STANDARDS-TRACK] 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. 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] Many IMAP clients display information about total number of messages / total number of unseen messages in IMAP mailboxes. In order to do that, they are forced to issue a LIST or LSUB command and to list all available mailboxes, followed by a STATUS command for each mailbox found. This document provides an extension to LIST command that allows the client to request STATUS information for mailboxes together with other information typically returned by the LIST command. [STANDARDS-TRACK] 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. This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] This specification defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and can guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation\'s (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group). Information from earlier versions of the DCE specification have been incorporated into this document. [STANDARDS-TRACK] Fastmail This document specifies an extension to the JSON Meta Application Protocol (JMAP) that allows clients to receive an object via the JMAP push channel whenever a new email is delivered that matches a client- defined filter. The object can also include properties from the email, to allow a user notification to be displayed without having to make a further network request.

Changes [[This section to be removed by RFC Editor]] draft-degennaro-imap-objectid-accountid-00 Initial version