IMAP Extension for Object Identifiers

Internet-Draft	IMAP OBJECTID+	March 2026
Gondwana & De Gennaro	Expires 16 September 2026	[Page]

Abstract

This document updates [RFC3501] (IMAP4rev1) and [RFC9051] (IMAP4rev2) 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 obsoletes [RFC8474] by adding the OBJECTID+ extension, which introduces compound OBJECTID responses containing key-value pairs of identifiers and an ACCOUNTID identifier for account-level context. The OBJECTID+ extension is implicitly activated when a client uses any OBJECTID+-specific feature, ensuring backward compatibility with clients that do not understand the extension.¶

1. Introduction

IMAP stores are often used by many clients. Each client may cache data from the server so that it does not need to redownload information. [RFC3501] states that a mailbox can be uniquely referenced by its name and UIDVALIDITY, and a message within that mailbox can be uniquely referenced by its mailbox (name + UIDVALIDITY) and unique identifier (UID). The triple of mailbox name, UIDVALIDITY, and UID is guaranteed to be immutable.¶

[RFC4315] defines a COPYUID response that allows a client that copies messages to know the mapping between the UIDs in the source and destination mailboxes and, hence, update its local cache.¶

If a mailbox is successfully renamed by a client, that client will know that the same messages exist in the destination mailbox name as previously existed in the source mailbox name.¶

The result is that the client that copies (or moves [RFC6851]) messages or renames a mailbox can update its local cache, but any other client connected to the same store cannot know with certainty that the messages are identical, so it will redownload everything.¶

This extension adds new properties to a message (EMAILID) and mailbox (MAILBOXID). These properties allow a client to quickly identify messages or mailboxes that have been renamed by another client.¶

This extension also adds an optional thread identifier (THREADID) to messages, which can be used by the server to indicate messages that it has identified to be related. A server that does not implement threading will return NIL to all requests for THREADID.¶

Additionally, this document introduces the OBJECTID+ extension, which adds an ACCOUNTID identifier for account-level context and a compound OBJECTID response format that bundles multiple identifiers into key-value pairs. This is particularly relevant for environments where IMAP mailboxes include shared mailboxes from multiple JMAP accounts, as defined in [RFC8620]. The compound format allows servers to include only the identifiers they support, with unsupported identifiers simply omitted from the response.¶

1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

2. CAPABILITY Identification

2.1. OBJECTID Capability

A server that supports the basic object identifier functionality as defined in [RFC8474] MUST include "OBJECTID" in the response list to the CAPABILITY command.¶

A server advertising "OBJECTID" MUST support MAILBOXID, EMAILID, and THREADID as described in this document. The behavior of OBJECTID without OBJECTID+ is identical to [RFC8474].¶

2.2. OBJECTID+ Capability

A server that supports the extended object identifier functionality defined in this document MUST include "OBJECTID+" in the response list to the CAPABILITY command.¶

A server advertising "OBJECTID+" MUST also advertise "OBJECTID".¶

The OBJECTID+ extension adds:¶

The ACCOUNTID identifier (Section 4)¶
The compound OBJECTID response format (Section 3)¶
The OBJECTID SELECT/EXAMINE parameter (Section 7.1)¶
The OBJECTID FETCH data item (Section 6.4)¶
The OBJECTID STATUS attribute (Section 7.4)¶
The OBJECTID response code on CREATE and RENAME (Section 7.2, Section 7.3)¶

2.3. 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+ ([RFC5161])¶
The client uses the OBJECTID parameter on SELECT or EXAMINE (Section 7.1)¶
The client requests the OBJECTID status attribute (Section 7.4)¶
The client requests the OBJECTID FETCH data item (Section 6.4)¶

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:¶

* ENABLED OBJECTID+

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 (Section 3) in place of the MAILBOXID response code in all subsequent SELECT, EXAMINE, CREATE, and RENAME responses.¶

3. 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.¶

The compound OBJECTID format is used in the following contexts once OBJECTID+ has been activated:¶

As a response code in SELECT/EXAMINE untagged OK responses¶
As a response code in tagged OK responses to CREATE and RENAME¶
As a STATUS attribute¶
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.¶

3.1. 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.¶

5. 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 MAILBOXID for two mailboxes at the same time.¶

The server MUST NOT reuse the same MAILBOXID for a mailbox that does not obey all the invariants that [RFC3501] defines for a mailbox that does not change name or UIDVALIDITY.¶

The server MUST keep the same MAILBOXID for the source and destination when renaming a mailbox in a way that keeps the same messages (but see [RFC3501] for the special case regarding the renaming of INBOX, which is treated as creating a new mailbox and moving the messages).¶

5.1. MAILBOXID Response Code for CREATE

This document extends the CREATE command to have the response code MAILBOXID on successful mailbox creation.¶

A server advertising the OBJECTID capability MUST include the MAILBOXID response code in the tagged OK response to all successful CREATE commands unless OBJECTID+ has been activated, in which case the OBJECTID response code (Section 7.2) is used instead.¶

Syntax: "MAILBOXID" SP "(" objectid ")"¶

Example:¶

C: 3 create foo
S: 3 OK [MAILBOXID (F2212ea87-6097-4256-9d51-71338625)] \
        Completed

5.2. MAILBOXID Untagged Response for SELECT and EXAMINE

A server advertising the OBJECTID capability MUST return an untagged OK response with the MAILBOXID response code on all successful SELECT and EXAMINE commands, unless OBJECTID+ has been activated, in which case the OBJECTID response code (Section 7.1) is used instead.¶

Syntax: "OK" SP "[" "MAILBOXID" SP "(" objectid ")" "]" SP text¶

Example:¶

C: 27 select "foo"
[...]
S: * OK [MAILBOXID (F2212ea87-6097-4256-9d51-71338625)] Ok
[...]
S: 27 OK [READ-WRITE] Completed

5.3. MAILBOXID Attribute for STATUS

This document adds the MAILBOXID attribute to the STATUS command using the extended syntax defined in [RFC4466].¶

A server that advertises the OBJECTID capability MUST support the MAILBOXID status attribute.¶

Syntax: "MAILBOXID"¶

The attribute in the STATUS command.¶

Syntax: "MAILBOXID" SP "(" objectid ")"¶

The response item in the STATUS response contains the server-assigned identifier for this mailbox.¶

Example:¶

C: 6 status foo (mailboxid)
S: * STATUS foo (MAILBOXID (F2212ea87-6097-4256-9d51-71338625))
S: 6 OK Completed
C: 7 status bar (mailboxid)
S: * STATUS bar (MAILBOXID (F6352ae03-b7f5-463c-896f-d8b48ee3))
S: 7 OK Completed
C: 8 rename foo renamed
S: 8 OK Completed
C: 9 status renamed (mailboxid)
S: * STATUS renamed (MAILBOXID \
        (F2212ea87-6097-4256-9d51-71338625))
S: 9 OK Completed

When the LIST-STATUS IMAP capability defined in [RFC5819] is also available, the STATUS command can be combined with the LIST command.¶

Example:¶

C: 11 list "" "*" return (status (mailboxid))
S: * LIST (\HasNoChildren) "." INBOX
S: * STATUS INBOX (MAILBOXID \
        (Ff8e3ead4-9389-4aff-adb1-d8d89efd8cbf))
S: * LIST (\HasNoChildren) "." bar
S: * STATUS bar (MAILBOXID \
        (F6352ae03-b7f5-463c-896f-d8b48ee3))
S: * LIST (\HasNoChildren) "." renamed
S: * STATUS renamed (MAILBOXID \
        (F2212ea87-6097-4256-9d51-71338625))
S: 11 OK Completed (0.001 secs 3 calls)

6. EMAILID Object Identifier and THREADID Correlator

6.1. 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 triple; hence, EMAILID is immutable.¶

The server SHOULD return the same EMAILID as the source message for the matching destination message in the COPYUID pairing after a COPY or MOVE command [RFC6851]. When the source and destination mailboxes have the same ACCOUNTID, the server SHOULD preserve the EMAILID. When a COPY or MOVE crosses ACCOUNTID boundaries, the server MAY assign a different EMAILID in the destination, as the identifier namespaces are scoped per ACCOUNTID.¶

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

6.2. 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. [RFC5256] 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 or is unable to calculate relationships between messages, it MUST return NIL to all FETCH responses for the THREADID data item, and a SEARCH for THREADID MUST NOT match any messages.¶

The server MUST NOT use the same ObjectID value for both EMAILIDs and THREADIDs. 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 clashes.¶

6.3. EMAILID and THREADID in FETCH and UID FETCH Commands

This document defines two FETCH items:¶

Syntax: "EMAILID"¶

The EMAILID message data item causes the server to return EMAILID FETCH response data items.¶

Syntax: "THREADID"¶

The THREADID message data item causes the server to return THREADID FETCH response data items.¶

This document defines the following responses:¶

Syntax: "EMAILID" SP "(" objectid ")"¶

The EMAILID response data item contains the server-assigned ObjectID for each message.¶

Syntax: "THREADID" SP "(" objectid ")"¶

The THREADID response data item contains the server-assigned ObjectID for the set of related messages to which this message belongs.¶

Syntax: "THREADID" SP nil¶

The NIL value is returned for the THREADID response data item when the server mailbox does not support THREADID calculation.¶

Example:¶

C: 5 append inbox "20-Mar-2018 03:07:37 +1100" {733}
[...]
Subject: Message A
Message-ID: <fake.1521475657.54797@example.com>
[...]
S: 5 OK [APPENDUID 1521475658 1] Completed

C: 11 append inbox "20-Mar-2018 03:07:37 +1100" {793}
[...]
Subject: Re: Message A
Message-ID: <fake.1521475657.21213@example.org>
References: <fake.1521475657.54797@example.com>
[...]
S: 11 OK [APPENDUID 1521475658 2] Completed

C: 17 append inbox "20-Mar-2018 03:07:37 +1100" {736}
[...]
Subject: Message C
Message-ID: <fake.1521475657.60280@example.com>
[...]
S: 17 OK [APPENDUID 1521475658 3] Completed

C: 22 fetch 1:* (emailid threadid)
S: * 1 FETCH (EMAILID (M6d99ac3275bb4e) \
        THREADID (T64b478a75b7ea9))
S: * 2 FETCH (EMAILID (M288836c4c7a762) \
        THREADID (T64b478a75b7ea9))
S: * 3 FETCH (EMAILID (M5fdc09b49ea703) \
        THREADID (T11863d02dd95b5))
S: 22 OK Completed (0.000 sec)

C: 23 move 2 foo
S: * OK [COPYUID 1521475659 2 1] Completed
S: * 2 EXPUNGE
S: 23 OK Completed

C: 24 fetch 1:* (emailid threadid)
S: * 1 FETCH (EMAILID (M6d99ac3275bb4e) \
        THREADID (T64b478a75b7ea9))
S: * 2 FETCH (EMAILID (M5fdc09b49ea703) \
        THREADID (T11863d02dd95b5))
S: 24 OK Completed (0.000 sec)

C: 25 select "foo"
[...]
S: 25 OK [READ-WRITE] Completed
C: 26 fetch 1:* (emailid threadid)
S: * 1 FETCH (EMAILID (M288836c4c7a762) \
        THREADID (T64b478a75b7ea9))
S: 26 OK Completed (0.000 sec)

Example: (no THREADID support)¶

C: 26 fetch 1:* (emailid threadid)
S: * 1 FETCH (EMAILID (M00000001) THREADID NIL)
S: * 2 FETCH (EMAILID (M00000002) THREADID NIL)
S: 26 OK Completed (0.000 sec)

6.4. Compound OBJECTID in FETCH

When the OBJECTID+ extension has been activated (Section 2.3), the client can request the compound OBJECTID FETCH data item.¶

Syntax: "OBJECTID"¶

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

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:¶

C: 30 fetch 1:* (objectid)
S: * ENABLED OBJECTID+
S: * 1 FETCH (OBJECTID (EMAILID M6d99ac3275bb4e \
        THREADID T64b478a75b7ea9))
S: * 2 FETCH (OBJECTID (EMAILID M5fdc09b49ea703 \
        THREADID T11863d02dd95b5))
S: 30 OK Completed (0.000 sec)

Example: (no THREADID support)¶

C: 31 fetch 1:* (objectid)
S: * 1 FETCH (OBJECTID (EMAILID M00000001))
S: * 2 FETCH (OBJECTID (EMAILID M00000002))
S: 31 OK Completed (0.000 sec)

Example: (server supports no message identifiers)¶

C: 32 fetch 1:* (objectid)
S: * 1 FETCH (OBJECTID ())
S: * 2 FETCH (OBJECTID ())
S: 32 OK Completed (0.000 sec)

The individual EMAILID and THREADID FETCH items continue to work as described above, regardless of whether OBJECTID+ has been activated. A client may use either the individual items or the compound OBJECTID item, or both.¶

7. OBJECTID+ Extensions to Existing Commands

7.1. OBJECTID Parameter on SELECT and EXAMINE

This document extends SELECT and EXAMINE to accept an OBJECTID parameter in the optional parameters list.¶

Including OBJECTID in the SELECT or EXAMINE parameters activates the OBJECTID+ extension (Section 2.3) and requests that the server return the compound OBJECTID response code instead of the MAILBOXID response code.¶

Example:¶

C: 27 select "foo" (OBJECTID)
S: * ENABLED OBJECTID+
[...]
S: * OK [OBJECTID (MAILBOXID F2212ea87-6097-4256-9d51-71338625 \
        ACCOUNTID u1a48e8e3)] Ok
[...]
S: 27 OK [READ-WRITE] Completed

C: 28 select "shared/team"
[...]
S: * OK [OBJECTID (MAILBOXID F8839dca12-3ef8-4a72-b63d-54f9e8a1 \
        ACCOUNTID u2b59f9f4)] Ok
[...]
S: 28 OK [READ-WRITE] Completed

Note that in the second SELECT, the server does not send ENABLED again because the extension was already activated by the first SELECT. Also note that the second mailbox has a different ACCOUNTID, indicating it belongs to a different account (e.g., a shared mailbox).¶

7.2. OBJECTID Response Code for CREATE

When OBJECTID+ has been activated, the server MUST use the OBJECTID response code instead of MAILBOXID in the tagged OK response to successful CREATE commands.¶

Example:¶

C: 3 create foo
S: 3 OK [OBJECTID (MAILBOXID \
        F2212ea87-6097-4256-9d51-71338625 \
        ACCOUNTID u1a48e8e3)] Completed
C: 4 create bar
S: 4 OK [OBJECTID (MAILBOXID \
        F6352ae03-b7f5-463c-896f-d8b48ee3 \
        ACCOUNTID u1a48e8e3)] Completed
C: 5 create shared/team
S: 5 OK [OBJECTID (MAILBOXID \
        F8839dca12-3ef8-4a72-b63d-54f9e8a1 \
        ACCOUNTID u2b59f9f4)] Completed

7.3. OBJECTID Response Code for RENAME

When OBJECTID+ has been activated, the server MUST include the OBJECTID response code in the tagged OK response to successful RENAME commands.¶

The MAILBOXID in the response reflects the (unchanged) identifier of the renamed mailbox. The ACCOUNTID reflects the account to which the mailbox belongs after the rename.¶

When a mailbox is renamed within the same account, the server MUST 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):¶

C: 8 rename foo renamed
S: 8 OK [OBJECTID (MAILBOXID \
        F2212ea87-6097-4256-9d51-71338625 \
        ACCOUNTID u1a48e8e3)] Completed

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

C: 13 rename bar "Other Users.shared.bar"
S: 13 OK [OBJECTID (MAILBOXID \
        Fa77c2e19-84d3-4b0f-9e12-67df5c8a \
        ACCOUNTID u2b59f9f4)] Completed

7.4. OBJECTID Attribute for STATUS

When OBJECTID+ has been activated, the OBJECTID STATUS attribute is available. It requests the compound OBJECTID response, which includes both the MAILBOXID and ACCOUNTID for the queried mailbox.¶

Syntax: "OBJECTID"¶

Requesting the OBJECTID status attribute activates the OBJECTID+ extension (Section 2.3).¶

Example:¶

C: 6 status foo (objectid)
S: * ENABLED OBJECTID+
S: * STATUS foo (OBJECTID (MAILBOXID \
        F2212ea87-6097-4256-9d51-71338625 \
        ACCOUNTID u1a48e8e3))
S: 6 OK Completed

C: 7 status bar (objectid)
S: * STATUS bar (OBJECTID (MAILBOXID \
        F6352ae03-b7f5-463c-896f-d8b48ee3 \
        ACCOUNTID u1a48e8e3))
S: 7 OK Completed

C: 8 status shared/team (objectid)
S: * STATUS shared/team (OBJECTID (MAILBOXID \
        F8839dca12-3ef8-4a72-b63d-54f9e8a1 \
        ACCOUNTID u2b59f9f4))
S: 8 OK Completed

The MAILBOXID status attribute from [RFC8474] continues to work as an individual attribute regardless of whether OBJECTID+ has been activated.¶

When the LIST-STATUS IMAP capability defined in [RFC5819] is also available, the STATUS command can be combined with the LIST command.¶

Example:¶

C: 11 list "" "*" return (status (objectid))
S: * ENABLED OBJECTID+
S: * LIST (\HasNoChildren) "." INBOX
S: * STATUS INBOX (OBJECTID (MAILBOXID \
        Ff8e3ead4-9389-4aff-adb1-d8d89efd8cbf \
        ACCOUNTID u1a48e8e3))
S: * LIST (\HasNoChildren) "." bar
S: * STATUS bar (OBJECTID (MAILBOXID \
        F6352ae03-b7f5-463c-896f-d8b48ee3 \
        ACCOUNTID u1a48e8e3))
S: * LIST (\HasNoChildren) "." "Other Users.other.sub.folder"
S: * STATUS "Other Users.other.sub.folder" (OBJECTID ( \
        MAILBOXID F8839dca12-3ef8-4a72-b63d-54f9e8a1 \
        ACCOUNTID u2b59f9f4))
S: 11 OK Completed (0.001 secs 3 calls)

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

9. Formal Syntax

The following syntax specification uses the Augmented Backus-Naur Form (ABNF) [RFC5234] notation. Elements not defined here can be found in the formal syntax of the ABNF [RFC5234], IMAP [RFC3501], IMAP ABNF extensions [RFC4466], and IMAP ENABLE [RFC5161] 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.¶

capability =/ "OBJECTID" / "OBJECTID+"

enable-data =/ "OBJECTID+"
        ; extends the enable-data production from [RFC5161]

objectid = 1*255(ALPHA / DIGIT / "_" / "-")
        ; characters in object identifiers are case
        ; significant

objectid-key = "MAILBOXID" / "ACCOUNTID" / "EMAILID" / "THREADID"

objectid-kvpair = objectid-key SP objectid

objectid-compound = "OBJECTID" SP "(" *(objectid-kvpair) ")"
        ; key-value pairs of identifiers
        ; keys not supported by the server are omitted
        ; an empty list "OBJECTID ()" is valid

; --- OBJECTID capability (RFC 8474 compatible) ---

fetch-att =/ "EMAILID" / "THREADID"

fetch-emailid-resp = "EMAILID" SP "(" objectid ")"
        ; follows tagged-ext production from [RFC4466]

fetch-threadid-resp = "THREADID" SP ( "(" objectid ")" / nil )
        ; follows tagged-ext production from [RFC4466]

msg-att-static =/ fetch-emailid-resp / fetch-threadid-resp

resp-text-code =/ "MAILBOXID" SP "(" objectid ")"
        ; incorporated before the expansion rule of
        ;  atom [SP 1*<any TEXT-CHAR except "]">]
        ; that appears in [RFC3501]

search-key =/ "EMAILID" SP objectid / "THREADID" SP objectid

status-att =/ "MAILBOXID"

status-att-val =/ "MAILBOXID" SP "(" objectid ")"
        ; follows tagged-ext production from [RFC4466]

; --- OBJECTID+ extensions ---

select-param =/ "OBJECTID"

fetch-att =/ "OBJECTID"

msg-att-static =/ objectid-compound

resp-text-code =/ objectid-compound

status-att =/ "OBJECTID"

status-att-val =/ objectid-compound
        ; follows tagged-ext production from [RFC4466]

10. Implementation Considerations

10.1. 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 [RFC4648].¶

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

10.2. Interaction with Special Cases

The case of RENAME INBOX may need special handling because it has special behavior, as defined in Section 6.3.5 of [RFC3501].¶

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

10.3. Client Usage

Servers that implement both [RFC6154] 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.¶

10.4. Interaction with the OBJECTID Capability

A server that advertises both the OBJECTID capability defined in [RFC8474] and the OBJECTID+ capability defined in this document MUST behave as follows:¶

When OBJECTID+ has not been activated, the server MUST conform to the behaviour specified in [RFC8474] for all OBJECTID-related responses. The server MUST NOT return OBJECTID response codes, OBJECTID status attributes, or ACCOUNTID attributes.¶
When OBJECTID+ has been activated, the server MUST conform to the behaviour specified in this document. The server MUST use OBJECTID response codes in place of MAILBOXID response codes for CREATE, RENAME, SELECT, and EXAMINE commands. The server MUST support OBJECTID as a STATUS attribute and as a FETCH data item.¶

This design allows servers to support both the original and extended specifications without breaking the IMAP grammar for clients that understand only one of the two extensions.¶

10.5. Interaction with IMAP4rev2

This specification is written in terms of [RFC3501] (IMAP4rev1) but applies equally to [RFC9051] (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 [RFC3501]. Servers implementing IMAP4rev2 SHOULD apply the same extensions to the corresponding productions in [RFC9051].¶

10.6. Interaction with MOVE

The MOVE command [RFC6851] atomically moves messages between mailboxes. As specified in Section 6, the server SHOULD preserve the EMAILID of moved messages when the source and destination mailboxes share the same ACCOUNTID. When a MOVE crosses ACCOUNTID boundaries, the server MAY assign new EMAILIDs and THREADIDs in the destination, as identifier namespaces are scoped per ACCOUNTID.¶

The MOVE command does not receive an OBJECTID response code. The COPYUID response code already provides the UID mapping between source and destination.¶

10.7. Interaction with NAMESPACE

The NAMESPACE extension [RFC2342] 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.¶

10.8. Interaction with UIDONLY

When the UIDONLY extension [RFC9586] 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.¶

10.9. Interaction with SORT and THREAD

The THREAD command defined in [RFC5256] 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.¶

10.10. 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 [RFC3501]. 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.¶

Table 1
Capability	Reference
OBJECTID+	This document

Table 2
Response Code	Reference
OBJECTID	This document

13. Security Considerations

13.1. 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 Section 11 of [RFC3501].¶

13.2. 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.¶

13.3. 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.¶

13.4. 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.¶

13.5. 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.¶

14. References

14.1. Normative References

[RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3501]: Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, <https://www.rfc-editor.org/rfc/rfc3501>.
[RFC4315]: Crispin, M., "Internet Message Access Protocol (IMAP) - UIDPLUS extension", RFC 4315, DOI 10.17487/RFC4315, December 2005, <https://www.rfc-editor.org/rfc/rfc4315>.
[RFC4466]: Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, DOI 10.17487/RFC4466, April 2006, <https://www.rfc-editor.org/rfc/rfc4466>.
[RFC5161]: Gulbrandsen, A., Ed. and A. Melnikov, Ed., "The IMAP ENABLE Extension", RFC 5161, DOI 10.17487/RFC5161, March 2008, <https://www.rfc-editor.org/rfc/rfc5161>.
[RFC5228]: Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email Filtering Language", RFC 5228, DOI 10.17487/RFC5228, January 2008, <https://www.rfc-editor.org/rfc/rfc5228>.
[RFC5234]: Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/rfc/rfc5234>.
[RFC5256]: Crispin, M. and K. Murchison, "Internet Message Access Protocol - SORT and THREAD Extensions", RFC 5256, DOI 10.17487/RFC5256, June 2008, <https://www.rfc-editor.org/rfc/rfc5256>.
[RFC5819]: Melnikov, A. and T. Sirainen, "IMAP4 Extension for Returning STATUS Information in Extended LIST", RFC 5819, DOI 10.17487/RFC5819, March 2010, <https://www.rfc-editor.org/rfc/rfc5819>.
[RFC6851]: Gulbrandsen, A. and N. Freed, Ed., "Internet Message Access Protocol (IMAP) - MOVE Extension", RFC 6851, DOI 10.17487/RFC6851, January 2013, <https://www.rfc-editor.org/rfc/rfc6851>.
[RFC8174]: Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8474]: Gondwana, B., Ed., "IMAP Extension for Object Identifiers", RFC 8474, DOI 10.17487/RFC8474, September 2018, <https://www.rfc-editor.org/rfc/rfc8474>.
[RFC9698]: Gulbrandsen, A. and B. Gondwana, "The JMAPACCESS Extension for IMAP", RFC 9698, DOI 10.17487/RFC9698, January 2025, <https://www.rfc-editor.org/rfc/rfc9698>.

14.2. Informative References

[RFC2342]: Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, DOI 10.17487/RFC2342, May 1998, <https://www.rfc-editor.org/rfc/rfc2342>.
[RFC4122]: Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, <https://www.rfc-editor.org/rfc/rfc4122>.
[RFC4648]: Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/rfc/rfc4648>.
[RFC6154]: Leiba, B. and J. Nicolson, "IMAP LIST Extension for Special-Use Mailboxes", RFC 6154, DOI 10.17487/RFC6154, March 2011, <https://www.rfc-editor.org/rfc/rfc6154>.
[RFC7377]: Leiba, B. and A. Melnikov, "IMAP4 Multimailbox SEARCH Extension", RFC 7377, DOI 10.17487/RFC7377, October 2014, <https://www.rfc-editor.org/rfc/rfc7377>.
[RFC8620]: Jenkins, N. and C. Newman, "The JSON Meta Application Protocol (JMAP)", RFC 8620, DOI 10.17487/RFC8620, July 2019, <https://www.rfc-editor.org/rfc/rfc8620>.
[RFC9051]: Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message Access Protocol (IMAP) - Version 4rev2", RFC 9051, DOI 10.17487/RFC9051, August 2021, <https://www.rfc-editor.org/rfc/rfc9051>.
[RFC9586]: Melnikov, A., Achuthan, A. P., Nagulakonda, V., Singh, A., and L. Alves, "IMAP Extension for Using and Returning Unique Identifiers (UIDs) Only", RFC 9586, DOI 10.17487/RFC9586, May 2024, <https://www.rfc-editor.org/rfc/rfc9586>.