]> Fastmail

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

Stalwart Labs LLC

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

mailmaint Internet-Draft This document defines the OBJECTID+ extension for IMAP, which obsoletes . OBJECTID+ introduces a compound OBJECTID response format that bundles object identifiers into key-value pairs, an ACCOUNTID identifier for account-level context, OBJECTID response codes for the RENAME command, and identifier-based mailbox selection via SELECT and EXAMINE. The OBJECTID+ extension is activated implicitly when a client uses any OBJECTID+-specific feature, ensuring backward compatibility with clients that only support .

Introduction This document obsoletes and defines persistent identifiers on mailboxes and messages to allow clients to more efficiently reuse cached data when resources have changed location on the server. The OBJECTID+ extension builds upon the identifier framework established by and introduces several new capabilities. It defines a compound OBJECTID response format that bundles multiple identifiers into a parenthesized list of key-value pairs; identifiers that the server does not support are simply omitted from the response. This compound format is used uniformly across SELECT, EXAMINE, CREATE, RENAME, STATUS, and FETCH responses once the extension has been activated. Four types of object identifiers may appear within the compound OBJECTID response. MAILBOXID is a server-allocated identifier for each mailbox that persists across renames, allowing clients to detect that a mailbox has been renamed rather than deleted and recreated. EMAILID is an identifier for message content that persists across COPY and MOVE operations, allowing clients to avoid redownloading messages that have changed location. THREADID is an optional identifier grouping related messages, allowing clients to display conversations. ACCOUNTID is a new identifier for account-level context, enabling disambiguation of mailboxes in environments where multiple accounts are accessible through a single IMAP session. The extension also introduces identifier-based mailbox selection via the OBJECTID parameter on SELECT and EXAMINE, allowing clients to reliably reselect mailboxes after renames. Additionally, the RENAME command now returns an OBJECTID response code, providing the server-allocated identifiers for the renamed mailbox. All identifier types are optional within the compound OBJECTID response; a server that does not support a particular identifier simply omits it. The empty compound response "OBJECTID ()" is valid and indicates that the server supports the OBJECTID+ extension but does not have any identifiers to return in a given context.

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.

CAPABILITY Identification

OBJECTID and OBJECTID+ Capabilities This document obsoletes and defines the OBJECTID+ capability. The OBJECTID+ capability is independent of the OBJECTID capability defined in : a server MAY advertise OBJECTID+ alone, or it MAY advertise both OBJECTID and OBJECTID+ to provide backward compatibility with clients that only support . A server that advertises both capabilities MUST behave as defined in until the client activates OBJECTID+ (). A server that advertises only OBJECTID+ is not required to support the individual MAILBOXID, EMAILID, or THREADID attributes defined in . The OBJECTID+ extension adds the ACCOUNTID identifier (), the compound OBJECTID response format (), the OBJECTID SELECT/EXAMINE parameter (), the OBJECTID FETCH data item (), the OBJECTID STATUS attribute (), and the OBJECTID response code on CREATE () and RENAME ().

Activation of OBJECTID+ A client activates the OBJECTID+ extension by using any OBJECTID+-specific feature. The server MUST NOT send OBJECTID+-specific responses until the extension has been activated. The extension is activated by any of the following: The client issues ENABLE OBJECTID+ () The client uses the OBJECTID parameter on SELECT or EXAMINE () The client requests the OBJECTID status attribute () The client requests the OBJECTID FETCH data item () When the extension is activated by any mechanism other than ENABLE, the server MUST send an untagged ENABLED response listing OBJECTID+ before any response that is affected by the activation:

Once activated, the OBJECTID+ extension remains active for the duration of the IMAP session. Activation MUST NOT be reversed. Once OBJECTID+ is activated, the server MUST use the compound OBJECTID response code () in place of the MAILBOXID response code in all subsequent SELECT, EXAMINE, CREATE, and RENAME responses.

OBJECTID Compound Format The OBJECTID+ extension introduces the compound OBJECTID format, which bundles multiple identifiers into a parenthesized list of key-value pairs. Each key identifies the type of object identifier (e.g., MAILBOXID, ACCOUNTID, EMAILID, THREADID), and each value is the corresponding ObjectID. Keys that the server does not support or that are not applicable in a given context are simply omitted from the response. An empty compound response "OBJECTID ()" is valid and indicates that the server supports the OBJECTID+ extension but does not have any identifiers to return in this context. Once OBJECTID+ has been activated, the compound OBJECTID format is used as a response code in SELECT and EXAMINE untagged OK responses, as a response code in tagged OK responses to CREATE and RENAME, as a STATUS attribute, and as a FETCH data item. The contents of the compound OBJECTID vary by context: For mailbox context (SELECT, EXAMINE, CREATE, RENAME, STATUS): the server SHOULD include MAILBOXID and ACCOUNTID. For message context (FETCH): the server SHOULD include EMAILID and THREADID. ACCOUNTID is not included in FETCH OBJECTID responses because the account context is already established by the SELECT or EXAMINE response for the current mailbox. Identifiers that the server does not support are omitted rather than returned as NIL. This allows the compound format to self-describe the server's capabilities without requiring clients to handle placeholder values. Clients MUST ignore any unrecognised key-value pairs in a compound OBJECTID response. This allows future extensions to add new identifier types without breaking existing clients.

Relationship to Individual Attributes The OBJECTID compound is functionally equivalent to requesting each of its constituent identifiers individually. A server MUST return the same values for identifiers whether they are requested individually or as part of an OBJECTID compound. For example, the MAILBOXID returned within an OBJECTID STATUS response MUST be identical to the MAILBOXID returned when requested as a standalone STATUS attribute. The OBJECTID compound is provided as a convenience for clients that wish to retrieve all available identifiers in a single request without enumerating each attribute separately.

ACCOUNTID Object Identifier The ACCOUNTID is a server-allocated identifier that specifies the account to which a mailbox belongs. When used in conjunction with MAILBOXID, the ACCOUNTID provides complete disambiguation of mailboxes in environments where multiple 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 other object identifiers defined in this specification (see ). The server MUST return the same ACCOUNTID for all mailboxes that belong to the same account. Conversely, the server MUST NOT return the same ACCOUNTID for mailboxes that belong to different accounts, even if accessed within the same IMAP session. When a server advertises the "JMAPACCESS" capability as defined in , it MUST ensure that the ACCOUNTID returned via IMAP matches the accountId property of the corresponding account in JMAP, as defined in . This correspondence is essential for clients to correlate mailboxes across the two protocols. When a mailbox is accessed exclusively through IMAP and does not have a corresponding representation in JMAP, 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. The ACCOUNTID is conceptually immutable for a given account within an IMAP session. However, if the underlying 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.

MAILBOXID Object Identifier The MAILBOXID is a server-allocated unique identifier for each mailbox. The server MUST return the same MAILBOXID for a mailbox with the same name and UIDVALIDITY. The server MUST NOT report the same (ACCOUNTID, MAILBOXID) pair for two different mailboxes at the same time. The server MUST NOT reuse the same MAILBOXID for a mailbox that does not obey all the invariants that defines for a mailbox that does not change name or UIDVALIDITY. The server SHOULD keep the same MAILBOXID for the source and destination when renaming a mailbox in a way that keeps the same messages (but see for the special case regarding the renaming of INBOX, which is treated as creating a new mailbox and moving the messages). When OBJECTID+ has been activated (), the server returns MAILBOXID within the compound OBJECTID response code for SELECT, EXAMINE, CREATE, and RENAME commands, and within the compound OBJECTID STATUS attribute. Servers that also advertise the OBJECTID capability continue to support the standalone MAILBOXID attribute as defined in .

EMAILID Object Identifier and THREADID Correlator

EMAILID Identifier for Identical Messages The EMAILID data item is an ObjectID that uniquely identifies the content of a single message. Anything that must remain immutable on a {name, uidvalidity, uid} triple must also be the same between messages with the same EMAILID. The server MUST return the same EMAILID for the same {name, uidvalidity, uid} triple; hence, EMAILID is immutable. Messages with the same EMAILID MUST have identical immutable content. Messages with identical content SHOULD have the same EMAILID, but the server is not required to detect content duplication. A COPY or MOVE command is allowed to create a new EMAILID for the destination message. The server SHOULD preserve the EMAILID when the source and destination mailboxes have the same ACCOUNTID, but is not required to do so. The server MAY assign the same EMAILID as an existing message upon APPEND (e.g., if it detects that the new message has exactly identical content to that of an existing message). NOTE: EMAILID only identifies the immutable content of the message. In particular, it is possible for different messages with the same EMAILID to have different keywords. This document does not specify a way to STORE by EMAILID.

THREADID Identifier for Related Messages The THREADID data item is an ObjectID that uniquely identifies a set of messages that the server believes should be grouped together when presented. THREADID calculation is generally based on some combination of References, In-Reply-To, and Subject, but the exact logic is left up to the server implementation. describes some algorithms that could be used; however, this specification does not mandate any particular strategy. The server MUST return the same THREADID for all messages with the same EMAILID. The server SHOULD return the same THREADID for related messages, even if they are in different mailboxes; for example, messages that would appear in the same thread if they were in the same mailbox SHOULD have the same THREADID, even if they are in different mailboxes. The server MUST NOT change the THREADID of a message once reported. THREADID is OPTIONAL; if the server does not support THREADID, it omits THREADID from the compound OBJECTID response in FETCH. A SEARCH for THREADID MUST NOT match any messages when the server does not support THREADID. Within a compound OBJECTID FETCH response, the server MUST NOT return the same ObjectID value as both the EMAILID and the THREADID for different messages. If they are stored with the same value internally, the server can generate prefixed values (as shown in the examples below with M and T prefixes) to avoid collisions. Servers that also advertise the OBJECTID capability continue to support the standalone EMAILID and THREADID FETCH data items as defined in .

OBJECTID+ Extensions to Existing Commands

OBJECTID Parameter on SELECT and EXAMINE This document extends SELECT and EXAMINE to accept an OBJECTID parameter in the optional parameters list, as defined in . The OBJECTID parameter has two forms: Without arguments: SELECT "mailbox" (OBJECTID) activates the OBJECTID+ extension () and requests the compound OBJECTID response code in place of the MAILBOXID response code. With arguments: SELECT "mailbox" (OBJECTID (MAILBOXID id ACCOUNTID id)) additionally requests that the server select the mailbox identified by the given MAILBOXID and ACCOUNTID rather than by name. The mailbox name serves as a fallback if no mailbox matches the given identifiers. In the second form, the parenthesized list after OBJECTID contains the same key-value pairs that the server returns in its compound OBJECTID response (). The client SHOULD include all identifiers that the server provided in the most recent compound OBJECTID response for the mailbox. When the server receives the second form, it MUST attempt to locate a mailbox matching the provided identifiers. If a match is found, the server selects that mailbox regardless of whether the mailbox name in the command still refers to it. If no match is found, the server falls back to selecting the mailbox by name, following the normal SELECT semantics. This mechanism allows clients to reliably reselect a mailbox after it has been renamed by another client, following the same pattern as the Sieve :mailboxid extension in . Example (activation only, no ID-based selection):

Example (ID-based selection after a rename):

Here the mailbox was previously named "foo" but may have been renamed. The server locates it by MAILBOXID and ACCOUNTID regardless of its current name. Example (ID-based selection, fallback to name):

The MAILBOXID did not match any mailbox, so the server fell back to selecting "foo" by name. The response contains the actual OBJECTID of the selected mailbox. Example (shared mailbox with different ACCOUNTID):

Note that in this example, the server does not send ENABLED again because the extension was already activated. The shared mailbox has a different ACCOUNTID, indicating it belongs to a different account.

OBJECTID Response Code for CREATE When OBJECTID+ has been activated (), the server MUST use the compound OBJECTID response code instead of MAILBOXID in the tagged OK response to successful CREATE commands. Example:

OBJECTID Response Code for RENAME When OBJECTID+ has been activated (), the server MUST include the compound OBJECTID response code in the tagged OK response to successful RENAME commands. The MAILBOXID in the response SHOULD be the same as the source mailbox when the rename preserves all mailbox invariants. The ACCOUNTID reflects the account to which the mailbox belongs after the rename. When a mailbox is renamed within the same account, the server SHOULD return the same MAILBOXID and ACCOUNTID as the source mailbox. When a mailbox is renamed across account boundaries (for example, from a personal namespace to a shared namespace belonging to a different account), the server MAY return a different ACCOUNTID, a different MAILBOXID, or both, reflecting the new account context and any server-specific identifier allocation policy. Example (local rename, identifiers preserved):

Example (cross-account rename, new identifiers issued):

OBJECTID Attribute for STATUS The OBJECTID STATUS attribute requests the compound OBJECTID response, which includes the MAILBOXID and ACCOUNTID for the queried mailbox (when supported by the server). Syntax: "OBJECTID" Requesting the OBJECTID STATUS attribute activates the OBJECTID+ extension (). Example:

Servers that also advertise the OBJECTID capability continue to support the standalone MAILBOXID STATUS attribute as defined in . When the LIST-STATUS IMAP capability defined in is also available, the STATUS command can be combined with the LIST command. Example:

This example demonstrates how clients can efficiently retrieve object identifiers for multiple mailboxes, including mailboxes belonging to different accounts, using the extended LIST command with STATUS return option. Example:

This example demonstrates how clients can efficiently retrieve object identifiers for multiple mailboxes, including mailboxes belonging to different accounts, using the extended LIST command with STATUS return option.

OBJECTID Data Item for FETCH The OBJECTID FETCH data item causes the server to return a compound OBJECTID response containing the EMAILID and, if supported, the THREADID for each message. Syntax: "OBJECTID" Requesting the OBJECTID FETCH data item activates the OBJECTID+ extension (). ACCOUNTID is not included in the FETCH OBJECTID response because the account context is already established by the SELECT or EXAMINE response for the current mailbox. Example:

Example (no THREADID support):

Example (server supports no message identifiers):

Servers that also advertise the OBJECTID capability continue to support the individual EMAILID and THREADID FETCH data items as defined in .

New Filters on SEARCH Command This document defines the filters EMAILID and THREADID on the SEARCH command. Syntax: "EMAILID" SP objectid Messages whose EMAILID is exactly the specified ObjectID. Syntax: "THREADID" SP objectid Messages whose THREADID is exactly the specified ObjectID. When using the MULTISEARCH extension defined in to search across multiple mailboxes, clients SHOULD only search for EMAILID or THREADID across mailboxes that share the same ACCOUNTID. Since object identifiers are only guaranteed to be unique within the scope of a single ACCOUNTID, searching across mailboxes with different ACCOUNTIDs may produce incorrect results if identifiers from different accounts happen to collide. Example:

Formal Syntax The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation. Elements not defined here can be found in the formal syntax of the ABNF , IMAP , IMAP ABNF extensions , and IMAP ENABLE specifications. Except as noted otherwise, all alphabetic characters are case insensitive. The use of uppercase or lowercase characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion. Please note specifically that ObjectID values are case sensitive.

Implementation Considerations

Assigning Object Identifiers All ObjectID values are allocated by the server. In the interest of reducing the possibilities of encoding mistakes, ObjectIDs are restricted to a safe subset of possible byte values; in order to allow clients to allocate storage, they are restricted in length. An ObjectID is a string of 1 to 255 characters from the following set of 64 codepoints: a-z, A-Z, 0-9, _, -. These characters are safe to use in almost any context (e.g., filesystems, URIs, IMAP atoms). These are the same characters defined as base64url in . For maximum safety, servers should also follow defensive allocation strategies to avoid creating risks where glob completion or data type detection may be present (e.g., on filesystems or in spreadsheets). In particular, it is wise to avoid: IDs starting with a dash IDs starting with digits IDs that contain only digits IDs that differ only by ASCII case (for example, A vs. a) the specific sequence of three characters NIL in any case (because this sequence can be confused with the IMAP protocol expression of the null value) A good solution to these issues is to prefix every ID with a single alphabetical character.

Interaction with Special Cases The case of RENAME INBOX may need special handling because it has special behavior, as defined in . It is advisable (though not required) to have MAILBOXID values be globally unique, but it is only required to be unique within the scope of a single ACCOUNTID as seen by a single client login to a single server hostname. Object identifiers such as MAILBOXID, EMAILID, and THREADID need only be unique within the scope of a single ACCOUNTID. A proxy that aggregates multiple independent backend servers MUST return a different ACCOUNTID for each set of mailboxes served by different backends, unless it can guarantee that all object identifiers are unique across those backends. This ensures that clients can rely on the combination of ACCOUNTID and any other object identifier being unique within the IMAP session, even when the backend servers independently assign identifiers that might otherwise collide.

Client Usage Servers that implement both and this specification should optimize their execution of commands like UID SEARCH OR EMAILID 1234 EMAILID 4321. Clients can assume that searching the all-mail mailbox using OR/ EMAILID or OR/THREADID is a fast way to find messages again if some other client has moved them out of the mailbox where they were previously seen. Clients that cache data offline should fetch the EMAILID of all new messages to avoid redownloading already-cached message details. Clients should fetch the MAILBOXID for any new mailboxes before discarding cache data for any mailbox that is no longer present on the server so that they can detect renames and avoid redownloading data. 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, clients can efficiently determine which IMAP mailbox corresponds to a newly delivered message without requiring additional synchronization operations.

Interaction with the OBJECTID Capability A server MAY advertise both OBJECTID and OBJECTID+ to provide backward compatibility with clients that only support . When both capabilities are advertised, the server MUST behave as defined in until the client activates OBJECTID+ (). Once OBJECTID+ has been activated, the server MUST use compound OBJECTID response codes in place of MAILBOXID response codes for CREATE, RENAME, SELECT, and EXAMINE commands, and MUST support the OBJECTID STATUS attribute and FETCH data item. A server that advertises only OBJECTID+ is not required to support the individual MAILBOXID, EMAILID, or THREADID attributes defined in . Such a server uses exclusively the compound OBJECTID format defined in this specification.

Interaction with IMAP4rev2 This specification is written in terms of (IMAP4rev1) but applies equally to (IMAP4rev2). IMAP4rev2 incorporates the ENABLE command and the MOVE extension natively, so no separate capability negotiation is needed for those features. The formal syntax in this document extends the ABNF productions defined in . Servers implementing IMAP4rev2 SHOULD apply the same extensions to the corresponding productions in .

Interaction with MOVE The MOVE command atomically moves messages between mailboxes. As specified in , MOVE is allowed to create new EMAILIDs and THREADIDs for the destination messages. The server SHOULD preserve the EMAILID when the source and destination mailboxes share the same ACCOUNTID, but is not required to do so. The MOVE command does not receive an OBJECTID response code. The COPYUID response code already provides the UID mapping between source and destination.

Interaction with NAMESPACE The NAMESPACE extension exposes that a single IMAP connection may provide access to mailboxes from different namespaces, including personal, other users', and shared namespaces. The ACCOUNTID returned for a mailbox SHOULD reflect the account that owns the mailbox data, not the account of the authenticated user accessing it. For example: Mailboxes in the personal namespace have the authenticated user's ACCOUNTID. Mailboxes in the "Other Users" namespace that belong to a different user SHOULD have that other user's ACCOUNTID. Mailboxes in a shared namespace SHOULD have the ACCOUNTID of the account that owns the shared data. This ensures that ACCOUNTID provides meaningful account-level disambiguation and, when JMAPACCESS is advertised, correctly correlates with the JMAP accountId that owns the corresponding Mailbox objects.

Interaction with UIDONLY When the UIDONLY extension is active, FETCH responses are replaced with UIDFETCH responses. The OBJECTID FETCH data item works identically in UIDFETCH responses. A server that supports both OBJECTID+ and UIDONLY MUST include the OBJECTID data item in UIDFETCH responses when requested.

Interaction with SORT and THREAD The THREAD command defined in computes thread relationships algorithmically based on message headers and returns a thread structure for display purposes. The THREADID defined in this document is a persistent identifier assigned by the server to group related messages. THREADID and the THREAD command are independent. A server MAY use different algorithms for THREAD responses and THREADID assignment, and the thread groupings need not correlate. Clients MUST NOT assume that messages sharing a THREADID will appear in the same thread structure returned by the THREAD command, or vice versa.

Advice to Client Implementers In cases of server failure and disaster recovery, or misbehaving servers, it is possible that a client will be sent invalid information, e.g., identical ObjectIDs or ObjectIDs that have changed where they MUST NOT change according to this document. In a case where a client detects inconsistent ObjectID responses from a server, it SHOULD fall back to relying on the guarantees of . For simplicity, a client MAY instead choose to discard its entire cache and resync all state from the server. Client authors protecting against server misbehavior MUST ensure that their design cannot get into an infinite loop of discarding cache and fetching the same data repeatedly without user interaction.

Future Considerations This extension is intentionally defined to be compatible with the data model in JMAP for Mail. A future extension to the Sieve :mailboxid extension could add ACCOUNTID support for multi-account environments. An extension to allow fetching message content directly via EMAILID and message listings by THREADID could be proposed.

IANA Considerations

IMAP Capabilities Registry IANA is requested to add the following entry to the "IMAP Capabilities" registry located at https://www.iana.org/assignments/imap-capabilities: Capability Reference OBJECTID+ This document The existing "OBJECTID" entry in the "IMAP Capabilities" registry, registered by , remains unchanged. Servers MAY advertise both OBJECTID and OBJECTID+ as described in this document.

IMAP Response Codes Registry IANA is requested to add the following entry to the "IMAP Response Codes" registry located at https://www.iana.org/assignments/imap-response-codes: Response Code Reference OBJECTID This document The existing "MAILBOXID" entry in the "IMAP Response Codes" registry, registered by , remains unchanged.

Security Considerations

Object Identifier Generation It is strongly advised that servers generate ObjectIDs that are safe to use as filesystem names and unlikely to be autodetected as numbers. See implementation considerations. If a digest is used for ID generation, it must have a collision- resistant property, so server implementations are advised to monitor current security research and choose secure digests. As the IDs are generated by the server, it will be possible to migrate to a new hash by just using the new algorithm when creating new IDs. This is particularly true if a prefix is used on each ID, which can be changed when the algorithm changes. The use of a digest for ID generation may be used as proof that a particular sequence of bytes was seen by the server. However, this is only a risk if IDs are leaked to clients who don't have permission to fetch the data directly. Servers that are expected to handle highly sensitive data should consider this when choosing how to create IDs. See also the security considerations in .

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 account identifiers 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 account identifiers 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+" 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 account identifiers that it cannot subsequently use to access the corresponding JMAP resources, potentially revealing the existence of accounts the user cannot access.

Privacy in Multi-Tenant Environments In multi-tenant or hosted environments, servers SHOULD generate account identifiers 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 account identifier generation mechanism should not use patterns that would allow users to infer these relationships unless such information is explicitly intended to be visible.

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] 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] Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] This document describes the base-level server-based sorting and threading extensions to the IMAP protocol. These extensions provide substantial performance improvements for IMAP clients that offer sorted and threaded views. [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] This document defines an IMAP extension consisting of two new commands, MOVE and UID MOVE, that are used to move messages from one mailbox to another. [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. 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. Most IMAP extensions are used by the client when it wants to and the server supports it. However, a few extensions require the server to know whether a client supports that extension. The ENABLE extension allows an IMAP client to say which extensions it supports. [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. This document defines a NAMESPACE command that allows a client to discover the prefixes of namespaces used by a server for personal mailboxes, other users' mailboxes, and shared mailboxes. [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] The UIDPLUS extension of the Internet Message Access Protocol (IMAP) provides a set of features intended to reduce the amount of time and resources used by some client operations. The features in UIDPLUS are primarily intended for disconnected-use clients. [STANDARDS-TRACK] 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] Some IMAP message stores include special-use mailboxes, such as those used to hold draft messages or sent messages. Many mail clients allow users to specify where draft or sent messages should be put, but configuring them requires that the user know which mailboxes the server has set aside for these purposes. This extension adds new optional mailbox attributes that a server may include in IMAP LIST command responses to identify special-use mailboxes to the client, easing configuration. [STANDARDS-TRACK] The IMAP4 specification allows the searching of only the selected mailbox. A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT and SEARCH commands, waiting for each to complete before moving on to the next. This extension allows a client to search multiple mailboxes with one command, limiting the delays caused by many round trips and not requiring disruption of the currently selected mailbox. This extension also uses MAILBOX, UIDVALIDITY, and TAG fields in ESEARCH responses, allowing a client to pipeline the searches if it chooses. This document updates RFC 4466 and obsoletes RFC 6237. 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. The OBJECTID capability of IMAP (RFC 8474) allows clients to identify mailboxes by a unique identifier that survives renaming. This document extends the Sieve email filtering language (RFC 5228) to allow using that same unique identifier as a target for fileinto rules and for testing the existence of mailboxes. The UIDONLY extension to the Internet Message Access Protocol (RFCs 3501 and 9051) allows clients to enable a mode in which information about mailbox changes is returned using only Unique Identifiers (UIDs). Message numbers are not returned in responses and cannot be used in requests once this extension is enabled. This helps both clients and servers to reduce resource usage required to maintain a map between message numbers and UIDs. This document defines an experimental IMAP extension.

Ideas for Implementing Object Identifiers Ideas for calculating account identifiers: Universally Unique Identifier (UUID) Server-assigned sequence number (guaranteed not to be reused) Hash of the JMAP accountId (if JMAP integration is provided) Ideas for calculating mailbox identifiers: Universally Unique Identifier (UUID) Server-assigned sequence number (guaranteed not to be reused) Ideas for implementing EMAILID: Digest of message content (RFC822 bytes) -- expensive unless cached UUID Server-assigned sequence number (guaranteed not to be reused) Ideas for implementing THREADID: Derive from EMAILID of first seen message in the thread. UUID Server-assigned sequence number (guaranteed not to be reused) There is a need to index and look up reference/in-reply-to data at message creation to efficiently find matching messages for threading. Threading may be either across mailboxes or within each mailbox only. The server has significant leeway here.

Changes from RFC 8474 This document obsoletes and introduces the following changes: The OBJECTID+ capability and extension is defined as an independent extension that may be advertised alongside or in place of the OBJECTID capability from . Servers that advertise only OBJECTID+ are not required to support the individual MAILBOXID, EMAILID, or THREADID attributes defined in . The compound OBJECTID response format is introduced, using key-value pairs where unsupported identifiers are omitted rather than returned as NIL. This compound format is used uniformly for SELECT, EXAMINE, CREATE, RENAME, STATUS, and FETCH responses. The ACCOUNTID identifier is defined for account-level context, enabling disambiguation of mailboxes in environments where multiple accounts are accessible through a single IMAP session. The RENAME command now returns an OBJECTID response code containing the identifiers of the renamed mailbox, which is new behavior not present in . The OBJECTID SELECT/EXAMINE parameter is introduced, supporting both activation of the OBJECTID+ extension and identifier-based mailbox selection with fallback to the mailbox name. An implicit activation model replaces mandatory ENABLE: OBJECTID+ is activated when the client uses any OBJECTID+-specific feature (OBJECTID in SELECT, EXAMINE, FETCH, or STATUS, or ENABLE OBJECTID+), with an untagged ENABLED response to signal activation. The OBJECTID FETCH data item provides EMAILID and THREADID in compound form. The OBJECTID STATUS attribute provides MAILBOXID and ACCOUNTID in compound form. Security considerations are added for account identifier exposure, cross-account information leakage, JMAP authentication consistency, and privacy in multi-tenant environments. IANA registrations are updated to include the OBJECTID+ capability and OBJECTID response code.

Acknowledgements The authors would like to thank the members of the IETF mailmaint working group for their contributions to this specification.

Changes [[This section to be removed by RFC Editor]] draft-ietf-mailmaint-imap-objectid-bis-02 Extended SELECT/EXAMINE OBJECTID parameter to support ID-based mailbox selection with fallback to mailbox name, following the pattern established by Removed restatement of behavior for MAILBOXID, EMAILID, and THREADID; this document now references for base OBJECTID behavior and focuses on OBJECTID+ extensions Reduced introduction length Clients MUST ignore unrecognised key-value pairs in compound OBJECTID responses (extensibility) ABNF objectid-key extended to allow future keys via atom Clarified COPY/MOVE EMAILID semantics: COPY/MOVE MAY create new EMAILIDs; same EMAILID MUST have same content; same content SHOULD have same EMAILID draft-ietf-mailmaint-imap-objectid-bis-01 Replaced mandatory ENABLE with implicit activation model: OBJECTID+ is activated when the client uses any OBJECTID+-specific feature (OBJECTID in SELECT/FETCH/STATUS, or ENABLE OBJECTID+) Changed compound OBJECTID format from positional with NIL to key-value pairs where unsupported identifiers are omitted Removed ACCOUNTID from FETCH OBJECTID (redundant with SELECT) Removed standalone ACCOUNTID STATUS attribute, FETCH data item, and SEARCH filter; ACCOUNTID is only available through compound OBJECTID responses Added OBJECTID parameter for SELECT/EXAMINE as an activation trigger MAILBOXID reverted to single objectid format in individual items (compatible with RFC 8474) Renamed capability from OBJECTIDBIS to OBJECTID+ Clarified that object identifiers only need to be unique within the scope of a single ACCOUNTID; proxies MUST assign different ACCOUNTIDs for different backends draft-ietf-mailmaint-imap-objectid-bis-00 Initial version