RFC 9586

IMAP Extension for Using and Returning Unique Identifiers (UIDs) Only

📅 published May 2024, from ietf

IMAP Extension for Using and Returning Unique Identifiers (UIDs) Only ✨

RFC 9586 · IETF · Request for Comments: 9586 🎀

  • Category: Experimental 🧪
  • ISSN: 2070-1721
  • Date: May 2024 📅
  • Authors: A. Melnikov (Isode), A. P. Achuthan, V. Nagulakonda, A. Singh (Yahoo!), L. Alves 💜
  • Obsoletes / Updates: The title block doesn't list any documents that this one obsoletes or updates. 🦋

Abstract 🦋

okay so the UIDONLY extension to IMAP (the Internet Message Access Protocol, defined in RFCs 3501 and 9051) lets clients turn on a mode where mailbox change info only comes back using UIDs. 💅 Message numbers don't show up in responses, and once this is on you can't use them in requests either. This is lowkey a big win because both clients and servers stop needing to keep a map between message numbers and UIDs, which saves a ton of resources. ✨

This document defines an experimental IMAP extension. 🧪

Status of This Memo 🌸

Quick reality check, bestie: this document is not an Internet Standards Track specification. It's published so people can examine it, try it out in experimental implementations, and evaluate it. 🔍

It does define an Experimental Protocol for the Internet community, and it's a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community and went through public review before the Internet Engineering Steering Group (IESG) approved it for publication. 🫶 Not everything the IESG approves is a candidate for any level of Internet Standard, though. See Section 2 of RFC 7841 for that. 💀

For the current status, any errata, and how to send feedback, check https://www.rfc-editor.org/info/rfc9586. 🔗

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. ✨

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please read these carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Revised BSD License. 📜

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of that material may not have granted the IETF Trust the right to allow modifications outside the IETF Standards Process. Without an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The one exception is formatting it for publication as an RFC or translating it into languages other than English. 🌍

Table of Contents 🧚

1.  Introduction and Overview
2.  Document Conventions
3.  The UIDONLY Extension
  3.1.  Enabling the UIDONLY Extension
  3.2.  Changes to FETCH/STORE/SEARCH/COPY/MOVE
  3.3.  Changes to UID FETCH / UID STORE
  3.4.  Changes to EXPUNGE / UID EXPUNGE
  3.5.  Changes to UID SEARCH
  3.6.  Changes to How Other Mailbox Changes Are Announced
  3.7.  Interaction with the CONDSTORE and QRESYNC Extensions
  3.8.  Interaction with Other Extensions
4.  Formal Syntax
5.  Security Considerations
6.  IANA Considerations
7.  Alternative Solutions Not Taken
8.  Normative References
9.  Informative References
Acknowledgments
Authors' Addresses

1. Introduction and Overview 💖

This document defines an extension to the Internet Message Access Protocol [RFC3501] [RFC9051] that gets rid of message numbers entirely. ✨ It's compatible with both IMAP4rev1 [RFC3501] and IMAP4rev2 [RFC9051], so no one's left out. 🫶

The UIDONLY extension lets clients ask servers to only use and return UIDs. 🦋 That's the whole point: it helps clients and servers cut down on the resources they'd otherwise spend keeping a map between message numbers and UIDs. It's giving efficiency, no cap. 💅

2. Document Conventions 🌸

In protocol examples, this document uses "C:" for lines the client sends to the server and "S:" for lines the server sends to the client. 💬 Lines starting with "//" are comments explaining the previous protocol line. Those prefixes and comments aren't part of the protocol itself. Lines with none of those prefixes are continuations of the line before them, and there's no line break in the protocol unless the document specifically says so. 🔍

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. 🔥 Capitals only, babe, lowercase versions are just regular words. 🙈

Other capitalized words are names of IMAP commands or responses [RFC3501] [RFC9051], or keywords from this document. 🍓

3. The UIDONLY Extension 🎀

An IMAP server advertises support for the UIDONLY extension by including the "UIDONLY" capability in the CAPABILITY response/response code. 📣

Once the UIDONLY extension is enabled (see Section 3.1), the client MUST NOT use message sequence numbers (including the special marker "*") in any arguments to IMAP commands. If the client does use message sequence numbers, the server MUST return a tagged BAD response. 🚫 The server MUST include the UIDREQUIRED response code in such BAD responses (see below). Also, once the UIDONLY extension is enabled, the server MUST NOT return message sequence numbers in any response. 🙅‍♀️

The UIDREQUIRED response code works like this:

  • UIDREQUIRED: Once the UIDONLY extension is enabled, the server returns the UIDREQUIRED response code when the client issues a command that includes message numbers instead of UIDs. 💌

Here's what that looks like in action:

C: 07 FETCH 10000:14589 (UID FLAGS)
S: 07 BAD [UIDREQUIRED] Message numbers are not allowed
    once UIDONLY is enabled

The UIDONLY extension changes how information about new, expunged, or changed messages gets returned in unsolicited responses. ✨ Specifically, it affects responses to UID FETCH, UID STORE, EXPUNGE, and UID EXPUNGE, plus how unsolicited mailbox changes get announced. 📢

The following subsections go into the changes this extension introduces in more detail. 🧚

3.1. Enabling the UIDONLY Extension 🔑

So, the UIDONLY extension affects how info about new, expunged, or changed messages comes back in unsolicited responses. That means the client has to turn it on first, using the ENABLE command. 💅

S: * OK [CAPABILITY IMAP4rev1 ENABLE CONDSTORE QRESYNC UIDONLY
    AUTH=SCRAM-SHA-256]
C: 01 ENABLE UIDONLY
S: * ENABLED UIDONLY
S: 01 OK ENABLE completed

3.2. Changes to FETCH/STORE/SEARCH/COPY/MOVE 🚫

Once UIDONLY is enabled, the FETCH, STORE, SEARCH, COPY, and MOVE commands are prohibited. If a client sends any of them, they MUST result in a tagged BAD response. 🙅‍♀️ Clients should use UID FETCH, UID STORE, UID SEARCH, UID COPY, or UID MOVE instead, respectively. 💖

3.3. Changes to UID FETCH / UID STORE 🦋

Once UIDONLY is enabled, every FETCH response that UID FETCH or UID STORE would've returned gets replaced by a UIDFETCH response. 🔄

The UIDFETCH response carries the same response data items as the FETCH response does. The UID is always returned at the beginning of a UIDFETCH response, and it can also show up in the UID response data item if the client asks for it. ✨ Asking for the UID item is redundant, sure, but it can make it easier to update existing (non-UIDONLY) implementations so they support UIDONLY. 🫶

C: 10 UID FETCH 25900:26600 (FLAGS)
[...]
S: * 25996 UIDFETCH (FLAGS (\Seen))
S: * 25997 UIDFETCH (FLAGS (\Flagged \Answered))
S: * 26600 UIDFETCH (FLAGS ())
S: 10 OK FETCH completed

C: 11 UID FETCH 25900:26600 (UID FLAGS)
S: * 25900 UIDFETCH (FLAGS (\Seen) UID 25900)
S: * 25902 UIDFETCH (FLAGS (\Flagged) UID 25902)
S: * 26310 UIDFETCH (FLAGS (\Answered) UID 26310)
S: * 26311 UIDFETCH (FLAGS () UID 26311)
S: * 26498 UIDFETCH (FLAGS (\Answered) UID 26498)
[...]
S: 11 OK FETCH completed

3.4. Changes to EXPUNGE / UID EXPUNGE 🧹

Once UIDONLY is enabled, every EXPUNGED response that EXPUNGE or UID EXPUNGE would've returned gets replaced by a VANISHED response, as defined in [RFC7162]. 🗑️ A server that implements UIDONLY isn't required (but is allowed) to also implement the CONDSTORE and/or QRESYNC extensions. 🌈

C: 12 EXPUNGE
S: * VANISHED 405,407,410,425
S: 12 OK expunged

Once UIDONLY is enabled, the "<sequence set>" UID SEARCH criterion is prohibited. Using it results in a tagged BAD response. 🙅‍♀️ Clients should use ALL or the "UID <sequence set>" UID SEARCH criterion instead. 💜

3.6. Changes to How Other Mailbox Changes Are Announced 📣

Once UIDONLY is enabled, every change to flags (and other dynamic message attributes) comes back in UIDFETCH responses instead of FETCH responses. 🚩

Expunged messages get announced with VANISHED responses instead of EXPUNGE responses, too. 👋

This extension doesn't affect EXISTS or RECENT responses. 🙌

The UID MOVE and UID COPY commands SHOULD return the COPYUID response code, as specified in [RFC4315]. 💅

Using the UIDNOTSTICKY response code (see [RFC4315]) isn't compatible with the UIDONLY extension. In other words, a server that advertises the UIDONLY extension MUST NOT return a UIDNOTSTICKY response code. 🚫

Heads up: UIDNOTSTICKY and UIDONLY don't mix. A server that advertises UIDONLY must never send UIDNOTSTICKY. 🙅‍♀️
C: 15 UID move 597 "Archives/2023/2023-05"
S: * OK [COPYUID 1685977201 597 2] UID MOVE
S: * VANISHED 597
S: 15 OK UID MOVE Completed

3.7. Interaction with the CONDSTORE and QRESYNC Extensions 🧚

CONDSTORE is compatible with UIDONLY. ✨ The MODSEQ message data item comes back in UIDFETCH responses instead of FETCH responses. 💖

QRESYNC is compatible with UIDONLY too, but once UIDONLY is enabled, the fourth SELECT QRESYNC parameter (see Section 3.2.5.2 ("Message Sequence Match Data") of [RFC7162]) MUST NOT be used. 🙅‍♀️ If the server observes that parameter once UIDONLY is enabled, it MUST return a tagged BAD response. 🥲

3.8. Interaction with Other Extensions 🦋

Other IMAP extensions might define commands that accept message sequence numbers (the "sequence-set" ABNF non-terminal; see Section 9 of [RFC9051]). Once UIDONLY is enabled, the server MUST reject those commands with a tagged BAD response. 🚫 For example, the SORT and THREAD [RFC5256] commands are prohibited, just like SEARCH. The good news is that UID SORT and UID THREAD can be used instead. 💅✨

4. Formal Syntax ✨

okay so bestie, this is where the grammar lives 🎀 The syntax is written in ABNF, the Augmented Backus-Naur Form from [ABNF], and yes it looks scary but it's really just a recipe for what messages are allowed to look like 💅

Anything used here but not defined in this section is defined in Section 9 of IMAP4 [RFC9051], so go check there if something looks unfamiliar 🧚

Quick heads up: all the alphabetic characters are case insensitive 🌸 Uppercase and lowercase are only used to make the token strings easier to read for us humans. Implementations MUST accept these strings in a case-insensitive fashion 💖 So "uidonly", "UIDONLY" and "UidOnly" are all the same vibe, periodt 💅

SP                  = <Defined in RFC 5234>

capability          =/ "UIDONLY"
                       ;; <capability>; see RFC 9051

message-data        =/ uidfetch-resp

uidfetch-resp       = uniqueid SP "UIDFETCH" SP msg-att
                      ;; The uniqueid is the UID of
                      ;; the corresponding message

message-data        =/ expunged-resp

expunged-resp       = <defines VANISHED response; see RFC 7162>

resp-text-code      =/ "UIDREQUIRED"

So the big picture: UIDONLY gets added as a capability, there's a new UIDFETCH response that rides along as message data 🦋 and UIDREQUIRED shows up as a response text code 🍓 The expunged-resp one is borrowed from the VANISHED response in [RFC7162], so we don't have to reinvent it 🙈

5. Security Considerations 🔥

okay bestie, the vibe here is pretty chill 😌 This IMAP extension is not believed to add any additional Security Considerations beyond the ones that are generally applicable to IMAP4rev1 [RFC3501] and IMAP4rev2 [RFC9051] 💜 So if you already locked down your IMAP setup, you're mostly already covered 🫶

6. IANA Considerations 🌈

Quick rundown of the paperwork 📝 IMAP4 capabilities get registered by publishing a Standards Track or IESG-approved Informational or Experimental RFC 💅

IANA has added the UIDONLY extension to the "IMAP Capabilities" registry, and RFC 9586 is listed as the reference 🎀 You can find that registry at <https://www.iana.org/assignments/imap4-capabilities/> ✨

IANA also added the UIDREQUIRED response code to the "IMAP Response Codes" registry, with RFC 9586 as the reference too 🦋 That registry lives at <https://www.iana.org/assignments/imap-response-codes/> 🧚

7. Alternative Solutions Not Taken 🙈

ngl this section is a little bit of tea ☕ An earlier draft version of this document proposed using FETCH responses with the message number parameter always set to 0 💀 The working group decided that was too risky, because it could cause unexpected side effects and cache corruptions in client code that wasn't properly updated to handle a lack of message numbers 😭 So that idea got yeeted 🔥

8. Normative References 📚

These are the must-read references the spec depends on, bestie 🌸

9. Informative References 💭

And these are the extra reads that aren't required, but are super helpful for context 🧚

Acknowledgments 🫶

The editors want to give a huge shoutout to the people who gave useful comments and joined the discussions that led to this document 👑 That's Arnt Gulbrandsen, Ken Murchison, Bron Gondwana, Barry Leiba, and Elwyn Davis 💖

This document is similar to [IMAP-UIDONLY-ORIG], but some different syntactic choices were made in the end 🦋

Authors' Addresses 💌

  • Alexey Melnikov Isode Limited Email: alexey.melnikov@isode.com URI: https://www.isode.com
  • Arun Prakash Achuthan Yahoo Inc. Email: arunprakash@myyahoo.com
  • Vikram Nagulakonda Yahoo Inc. Email: nvikram_imap@yahoo.com
  • Ashutosh Singh Yahoo Inc. Email: ashutoshvsingh@yahoo.com
  • Luis Alves Email: luis.alves@lafaspot.com

That's the whole spec, bestie! 🌈✨

📦 where this page comes from