IMAP Extension for unique identifiersFastMailLevel 2, 114 William StMelbourneVIC 3000Australiabrong@fastmailteam.comhttps://www.fastmail.com
Applications
EXTRAIMAPemailThis document adds new properties to IMAP mailboxes and messages to allow
clients to more efficiently re-use cached data for resources which have
changed location on the server.
IMAP stores are often used by many clients, which each cache information
locally about the server state so that they don't need to download anything
again. defines 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 UID.
Further, defines a COPYUID response which allows a client which
copies messages between folders to know the mapping between the UIDs in the
source and destination mailboxes, and hence update its local cache.
So a client which copies (or moves) messages or renames folders
can update its local cache, but any other client connected to the same store
can not know with certainty that the messages are identical, and so will
re-download everything.
This extension adds new properties to a message (EMAILID) and mailbox (MAILBOXID)
which allow a client to quickly identify messages or mailboxes which 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 which it has identified
to be related.
In examples, "C:" indicates lines sent by a client that is connected
to a server. "S:" indicates lines sent by the server to the client.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in when they appear in ALL CAPS. These words may
also appear in this document in lower case as plain English words,
absent their normative meanings.
IMAP servers that support this extension MUST include "UNIQUEID" in
the response list to the CAPABILITY command.
This extension defines one new status data item for the STATUS
command and response:
MAILBOXID
A unique identifier for the mailbox. This identifier SHOULD be
retained when the mailbox is renamed. This identifer MUST NOT
be identical if the mailbox does not meet the invarients for a
mailbox with the same name and uidvalidity as a mailbox
previously reported to have this UIDVALIDITY. A server MUST NOT
return two mailboxes with the same MAILBOXID.
The value of the MAILBOXID is an opaque string of 1..255 bytes in length.
The MAILBOXID is server assigned and read-only.
The server MAY choose to create a MAILBOXID value in a way that does not
survive RENAME, (e.g. a digest of mailboxname + uidvalidity could be used
as a "MAILBOXID" and it would be legal, though of course clients would
not get the full benefits of this extension from such a server).
Example:
When the LIST-STATUS IMAP capability is also available,
the STATUS command can be combined with the LIST command to further
improve efficiency. This way, the unique ids of many mailboxes can be
queried with just one LIST command.
Example:
This extension defines two additional FETCH items on messages:
EMAILID
A server allocated opaque string value (1..255 bytes) which
uniquely identifies the content of a single message. That is
the exact bytes of the RFC822 FETCH item. The server MUST NOT
return the same EMAILID for two different sets of bytes. The
server SHOULD return the same EMAILID for the same set of bytes.
THREADID
A server allocated opaque string value (1..255 bytes) which
is the same for messages which the server has, with its own
algorithm, decided are "related" in some way. This is generally
based on some combination of References, In-Reply-To and Subject
but the exact logic is left up to the server implementation.
If the mailbox does not support THREADID, it will return NIL for
fetch.
Example:
This extension defines two new search keys for the SEARCH command:
EMAILID blob
Messages with the exactly matching EMAILID (bytes, does not
depend on charset, case IS significant)
THREADID blob
Messages with the exactly matching THREADID (bytes, does not
depend on charset, case IS significant)
Example: (as if run before the MOVE above when the mailbox had 3 messages)
This specification defines a new response code "MAILBOXID" to the "CREATE"
command.
Example:
resp-text-code =/ "MAILBOXID"
uniqueid = 1*255(ALPHA / DIGIT / "_" / "-")
The case of RENAME INBOX may need special handling for unique ids.
It is OK to change the mailboxid on a folder RENAME, but you MUST NOT
ever re-use a MAILBOXID which has been shown to a client.
It is advisable (though not required) to have MAILBOXID be globally
unique, but they it is only required to be unique within a single
server.
If you have unique IDs larger than 255 bytes in a data store, it is
safe to use a cryptograhically strong hash to convert your IDs into
a MAILBOXID value to display for this extension. It may be worth
caching that value, as STATUS MAILBOXID is expected to be cheap for
the server to calculate.
Ideas for implementing EMAILID:
Digest of (MailboxName/UIDVALIDITY/UID) - is not kept when moving
messages, but is guarantee unique.Digest of message content (RFC822 bytes) - expensive unless cachedID allocated at creation time - very efficient but requires storage
of an additional value.Ideas for implementing THREADID:
Derive from EMAILID of first seen message in the thread.ID allocated at creation time.There is a need to index and look up reference/in-reply-to data
efficiently at message creation to efficiently find matching messages
for threading. Threading may be either across folders, or within
each folder only. The server has significant leeway here.
This extension is intentionally defined to be compatible with the data
model in .
A future extension could be proposed to give a way to SELECT a mailbox
by MAILBOXID rather than name.
An extension to allow fetching message content directly via EMAILID and
message listings by THREADID could be proposed.
The IANA is requested to add "UNIQUEID" to the "IMAP Capabilities"
registry located at .
If globally unique identifiers are used as MAILBOXIDs on IMAP folders,
then it may be possible to tell when an account or folder has been renamed,
even if all the mail has been deleted, if the folders themselves are
retained.
add ABNFconsider whether IDs should be constrained to a smaller set of allowed
characters (in conjunction with JMAP group)consider whether STATUS response should be MAILBOXID ("value") to allow
non-integer responses.renamed UNIQUEID (status item) to MAILBOXIDrenamed MSGID to EMAILIDrenamed THRID to THREADIDadded TODO sectionThe EXTRA working group at IETF.
The gmail team's X-GM-THRID and X-GM-MSGID implementation.