IMAP Extension for Object Identifiers
updates
- rfc-3501 — INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1
Extracted elements (25)
ObjectIDs are restricted to 1–255 characters from a 64-codepoint safe subset (a-z, A-Z, 0-9, _, -) to reduce encoding mistakes and allow clients to allocate bounded storage; these are the same characters as base64url.
Servers should avoid ObjectIDs starting with a dash or digits, containing only digits, differing only by ASCII case, or equaling the sequence "NIL" in any case, to prevent confusion with IMAP nil values and avoid glob/spreadsheet autodetection. Prefixing every ID with an alphabetical character is recommended.
This extension is intentionally designed to be compatible with the JMAP Mail data model (draft-ietf-jmap-mail), enabling future interoperability between IMAP ObjectID and JMAP message/mailbox identifiers.
A proxy that aggregates multiple independent servers MUST NOT advertise the OBJECTID capability unless it can guarantee that different objects will never use the same identifiers, even if backend object identifiers collide.
MAILBOXID is required to be unique only within messages offered to a single client login to a single server hostname; global uniqueness is advisable but not required.
A server advertising the OBJECTID capability MUST include the MAILBOXID response code in the tagged OK response to all successful CREATE commands.
A server advertising the OBJECTID capability MUST return an untagged OK response with the MAILBOXID response code on all successful SELECT and EXAMINE commands.
A server that advertises the OBJECTID capability MUST support the MAILBOXID status attribute in the STATUS command.
IMAP servers that support this extension MUST include "OBJECTID" in the response list to the CAPABILITY command.
In cases where a client detects inconsistent ObjectID responses from a server, it SHOULD fall back to relying on the guarantees of RFC 3501. Client authors MUST ensure their design cannot enter an infinite loop of discarding cache and refetching data without user interaction.
The server MAY assign the same EMAILID as an existing message upon APPEND if it detects that the new message has exactly identical content. EMAILID only identifies immutable content; messages with the same EMAILID may have different keywords.
The server MUST keep the same MAILBOXID for the source and destination when renaming a mailbox in a way that keeps the same messages (with the exception of RENAME INBOX, which is treated as creating a new mailbox and moving messages).
The server MUST NOT use the same ObjectID value for both EMAILIDs and THREADIDs; servers storing them with the same internal value can generate prefixed values (e.g., M and T prefixes) to avoid clashes.
The server MUST return the same EMAILID for the same {name, uidvalidity, uid} triple; EMAILID is immutable. The server MUST return the same EMAILID as the source message for the matching destination message after a COPY or MOVE command.
The server MUST return the same MAILBOXID for a mailbox with the same name and UIDVALIDITY, MUST NOT report the same MAILBOXID for two mailboxes at the same time, and MUST NOT reuse the same MAILBOXID for a mailbox that does not obey all RFC 3501 invariants.
The server MUST return the same THREADID for all messages with the same EMAILID, SHOULD return the same THREADID for related messages across different mailboxes, and MUST NOT change the THREADID of a message once reported.
THREADID is OPTIONAL; if the server doesn't support it or cannot calculate relationships, it MUST return NIL to all FETCH responses for THREADID and a SEARCH for THREADID MUST NOT match any messages.
The CREATE command is extended to return a MAILBOXID response code on success. Syntax: "MAILBOXID" SP "(" objectid ")" in the tagged OK response.
Two new FETCH data items are defined: EMAILID (returns the server-assigned ObjectID for a message's content) and THREADID (returns the ObjectID for the set of related messages, or NIL if unsupported).
Two new SEARCH filters are defined: EMAILID SP objectid (matches messages whose EMAILID exactly equals the specified ObjectID) and THREADID SP objectid (matches messages whose THREADID exactly equals the specified ObjectID).
IANA has added "OBJECTID" to the "IMAP Capabilities" registry and "MAILBOXID" to the "IMAP Response Codes" registry, both with references to this document.
If a digest is used for ObjectID generation, it must have a collision-resistant property; server implementors should monitor current security research and choose secure digests. Digest-based IDs may serve as proof that a particular byte sequence was seen by the server, which is a risk if IDs are leaked to clients without permission to fetch the data directly.
An objectid is a string of 1 to 255 characters from the 64-character set: a-z, A-Z, 0-9, underscore, and dash (the base64url alphabet per RFC 4648). ObjectID values are case sensitive.
FETCH response syntax: "EMAILID" SP "(" objectid ")" and "THREADID" SP ( "(" objectid ")" / nil ), following the tagged-ext production from RFC 4466.
MAILBOXID response code syntax: "MAILBOXID" SP "(" objectid ")". Used in CREATE tagged OK response, SELECT/EXAMINE untagged OK response, and STATUS response items.