RFC 9208
IMAP QUOTA Extension
RFC 9208: IMAP QUOTA Extension 🎀
Okay bestie, the title block first! 💖 This is RFC 9208, the IMAP QUOTA Extension, written by A. Melnikov from Isode. It's dated March 2022, it's a Standards Track doc, and its ISSN is 2070-1721. It also obsoletes RFC 2087, so it's the new, glow-up version of that one. 🦋
Abstract ✨
So this doc adds a QUOTA extension to IMAP (see RFCs 3501 and 9051) that lets you check and change administrative limits on resource usage, aka quotas, straight through the IMAP protocol. 💅
It obsoletes RFC 2087 but tries really hard to stay backwards compatible wherever it can. 🫶
Status of This Memo 🌸
This is an Internet Standards Track document. 🔥
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841. 📚
Info about the current status of this doc, any errata, and how to send feedback lives at https://www.rfc-editor.org/info/rfc9208. ✨
Copyright Notice 🌈
Copyright (c) 2022 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), as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this doc. Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Revised BSD License. 🙈
This document may include material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. Unless you get 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 exceptions are 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. Terms
3.1. Resource
3.1.1. Name
3.1.2. Definition
3.2. Quota Root
4. Definitions
4.1. Commands
4.1.1. GETQUOTA
4.1.2. GETQUOTAROOT
4.1.3. SETQUOTA
4.1.4. New STATUS attributes
4.2. Responses
4.2.1. QUOTA
4.2.2. QUOTAROOT
4.3. Response Codes
4.3.1. OVERQUOTA
5. Resource Type Definitions
5.1. STORAGE
5.2. MESSAGE
5.3. MAILBOX
5.4. ANNOTATION-STORAGE
6. Interaction with IMAP ACL Extension (RFC 4314)
7. Formal Syntax
8. Security Considerations
9. IANA Considerations
9.1. Changes/Additions to the IMAP Capabilities Registry
9.2. IMAP Quota Resource Type Registry
10. Changes Since RFC 2087
11. References
11.1. Normative References
11.2. Informative References
Acknowledgments
Contributors
Author's Address1. Introduction and Overview 💖
This doc defines a couple of extensions to the Internet Message Access Protocol [RFC3501] [RFC9051] for querying and changing administrative limits on resource usage (quotas). This extension works with both IMAP4rev1 [RFC3501] and IMAP4rev2 [RFC9051]. 🦋
The "QUOTA" capability means a server that follows [RFC2087]. Some responses and response codes defined here aren't in those servers (see Section 10 for more details), so clients MUST NOT rely on them unless they see a capability beginning with "QUOTA=". 🙈
Any server that follows this document MUST also return at least one capability starting with the "QUOTA=RES-" prefix, as described in Section 3.1. ✨
Any server that follows this document AND implements the SETQUOTA command (see Section 4.1.3) MUST also return the "QUOTASET" capability. 💅
This doc also reserves every other capability starting with the "QUOTA=" prefix for future IETF Stream Standard Track, Informational, or Experimental extensions to this document. 🌸
Quotas can restrict clients for administrative reasons, but the QUOTA extension can also show system limits and current usage levels to clients. 🔥
The IMAP4 QUOTA extension in [RFC2087] has been deployed in servers, but it hasn't been deployed much in clients. The meaning of the resources was implementation dependent, so a client couldn't work out which resources were supported. It also couldn't tell which mailboxes were in a given quota root (see Section 3.2) without knowing the implementation beforehand. Mood. 😭
2. Document Conventions 💅
In protocol examples, this doc uses a prefix of "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. These prefixes and comments aren't part of the protocol. Lines without any of these prefixes continue the previous line, and there's no line break in the protocol before those lines unless it's specifically mentioned. 🎀
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document get interpreted as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, just like here. 🧚
Other capitalized words are IMAP keywords [RFC3501] [RFC9051] or keywords from this document. 💜
3. Terms 🎀
3.1. Resource
A resource has a name and a formal definition. ✨
3.1.1. Name
The resource name is an atom, as defined in IMAP4rev1 [RFC3501]. These MUST be registered with IANA. 🦋
Supported resource names MUST be advertised as a capability by putting the "QUOTA=RES-" prefix in front of the resource name. A server that follows this spec doesn't have to support every reported resource type on every quota root. 🌈
3.1.2. Definition
The resource definition, or the document that contains it, isn't visible through the protocol, but it SHOULD be registered with IANA. 🫶
The usage of a resource MUST be represented as a 63-bit unsigned integer. 0 means the resource is exhausted. Usage integers don't necessarily represent proportional use, so clients MUST NOT compare an available resource between two separate quota roots, whether they're on the same server or different ones. 🙈
Limits will be specified as, and MUST be represented as, an integer. 0 means any usage is prohibited. 💅
Limits can be hard or soft. In other words, an implementation MAY choose, or be configured, to disallow any command if the limit on a resource is or would be exceeded. 🔥
Every resource the server handles MUST be advertised in a CAPABILITY response or response code, consisting of the resource name with the "QUOTA=RES-" prefix. 🌸
The resources STORAGE (Section 5.1), MESSAGE (Section 5.2), MAILBOX (Section 5.3), and ANNOTATION-STORAGE (Section 5.4) are defined in this document. ⭐
3.2. Quota Root
This doc brings in the idea of a "quota root," since resource limits can apply across multiple IMAP mailboxes. 🎀
Each mailbox has zero or more implementation-defined named "quota roots". Each quota root has zero or more resource limits (quotas). All mailboxes that share the same named quota root share that quota root's resource limits. 🧚
Quota root names don't need to be mailbox names, and this document doesn't define any relationship between a quota root name and a mailbox name. A quota root name is an astring, as defined in IMAP4 [RFC3501] [RFC9051]. Clients SHOULD treat it as an opaque string. 💖
Quota roots exist because not every implementation can calculate usage or apply quotas on arbitrary mailboxes or mailbox hierarchies. 🦋
Not every resource can be limited or calculated for every quota root. Also, not every resource supports every limit, and some limits might already be in the underlying system. A server implementation of this memo SHOULD tell the client about such inherent limits by generating QUOTA (Section 4.2.1) responses. It SHOULD also tell the client which resources are limitable for a particular quota root. A SETQUOTA (Section 4.1.3) command MAY also round a quota limit in an implementation-dependent way, if the granularity of the underlying system demands it. A client MUST be prepared for a SETQUOTA (Section 4.1.3) command to fail if a limit can't be set. 🌈
Implementation Notes: For example, under UNIX, a quota root may always have a MESSAGE (Section 5.2) quota set because of the number of inodes available on the filesystem. Similarly, STORAGE (Section 5.1) may be rounded to the nearest block and limited by free filesystem space. 🍓
4. Definitions 🧚
4.1. Commands
These are the commands that exist for manipulating and querying quotas. 👑
4.1.1. GETQUOTA
Arguments: quota root
Responses: REQUIRED untagged responses: QUOTA
Result: OK - getquota completed. NO - getquota error: no such quota root, permission denied. BAD - command unknown or arguments invalid. 💅
The GETQUOTA command takes the name of a quota root and returns that quota root's resource usage and limits in an untagged QUOTA response. (You can find the names of quota roots that apply to a particular mailbox by issuing the GETQUOTAROOT command; see Section 4.1.2.) The server isn't required to support any specific resource type (as advertised in the CAPABILITY response, meaning all capability items with the "QUOTA=RES-" prefix) for any particular quota root. 🫶
Example:
S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE [...]
[...]
C: G0001 GETQUOTA "!partition/sda4"
S: * QUOTA "!partition/sda4" (STORAGE 104 10923847)
S: G0001 OK Getquota complete4.1.2. GETQUOTAROOT
Arguments: mailbox name
Responses: REQUIRED untagged responses: QUOTAROOT, QUOTA
Result: OK - getquotaroot completed. NO - getquotaroot error: permission denied. BAD - command unknown or arguments invalid. 🌸
The GETQUOTAROOT command takes a mailbox name and returns the list of quota roots for that mailbox in an untagged QUOTAROOT response. For each listed quota root, it also returns that quota root's resource usage and limits in an untagged QUOTA response. ✨
The mailbox name parameter doesn't have to point at an existing mailbox. This comes in handy for figuring out which quota root would apply to a mailbox before it gets created. 🦋
Example:
S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-MESSAGE
[...]
[...]
C: G0002 GETQUOTAROOT INBOX
S: * QUOTAROOT INBOX "#user/alice" "!partition/sda4"
S: * QUOTA "#user/alice" (MESSAGE 42 1000)
S: * QUOTA "!partition/sda4" (STORAGE 104 10923847)
S: G0002 OK Getquotaroot complete4.1.3. SETQUOTA 💅
Arguments: quota root list of resource limits
Responses: untagged responses: QUOTA
Result:
- OK - setquota completed
- NO - setquota error: can't set that data
- BAD - command unknown or arguments invalid
okay so heads up, SETQUOTA is the one where you actually change the limits 🔥 Unlike the other commands and response codes in this doc, it only works if the server advertises the QUOTASET capability, so check that first 🫶
You give it the name of a quota root and a list of resource limits, and the limits for that root get swapped out for the ones you sent. Anything that was there before gets tossed, even limits you didn't mention 💀 For example, if the root had both STORAGE and MESSAGE limits and your SETQUOTA only includes STORAGE, then MESSAGE is gone. no cap, it's wild 😭
If the quota root didn't exist yet, an implementation may optionally create it and change the quota roots for any number of existing mailboxes, in whatever implementation-defined way it likes 🧚
If the server does decide to change quota roots for some existing mailboxes, those changes SHOULD be announced with untagged QUOTA responses 🌸
Example:
S: * CAPABILITY [...] QUOTA QUOTASET QUOTA=RES-STORAGE QUOTA=RES-
MESSAGE [...]
[...]
C: S0000 GETQUOTA "#user/alice"
S: * QUOTA "#user/alice" (STORAGE 54 111 MESSAGE 42 1000)
S: S0000 OK Getquota completed
C: S0001 SETQUOTA "#user/alice" (STORAGE 510)
S: * QUOTA "#user/alice" (STORAGE 58 512)
// The server has rounded the STORAGE quota limit requested to
the nearest 512 blocks of 1024 octets; otherwise, another client
has performed a near-simultaneous SETQUOTA using a limit of 512.
S: S0001 OK Rounded quota
C: S0002 SETQUOTA "!partition/sda4" (STORAGE 99999999)
S: * QUOTA "!partition/sda4" (STORAGE 104 10923847)
// The server has not changed the quota, since this is a
filesystem limit, and it cannot be changed. The QUOTA
response here is entirely optional.
S: S0002 NO Cannot change system limit4.1.4. New STATUS attributes ✨
The DELETED and DELETED-STORAGE status data items help you estimate how much stuff an EXPUNGE on a mailbox could free up 🧹
The DELETED status data item asks the server for the number of messages with the \Deleted flag set. It's only required to be implemented when the server advertises the "QUOTA=RES-MESSAGE" capability 🎀
The DELETED-STORAGE status data item asks the server for how much storage space could be reclaimed by running EXPUNGE on the mailbox. The server SHOULD return the exact value, but the server may have to do a non-trivial amount of work to figure it out, and that's totally recognized 🥹 If working out the exact value would take a long time, the server MAY instead return the sum of the RFC822.SIZE of the messages with the \Deleted flag set. DELETED-STORAGE is only required to be implemented when the server advertises the "QUOTA=RES-STORAGE" capability 💜
Example:
S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-
MESSAGE [...]
[...]
C: S0003 STATUS INBOX (MESSAGES DELETED DELETED-STORAGE)
S: * STATUS INBOX (MESSAGES 12 DELETED 4 DELETED-STORAGE 8)
// 12 messages, 4 of which would be deleted when an EXPUNGE
happens.
S: S0003 OK Status complete.4.2. Responses 🦋
The following responses may be sent by the server.
4.2.1. QUOTA 🌈
Data: quota root name
list of resource names, usages, and limits
This response shows up as a result of a GETQUOTA, GETQUOTAROOT, or SETQUOTA command. The first string is the name of the quota root this quota applies to 💖
After the name comes an S-expression format list of the resource usage and limits for that quota root. The list has zero or more triplets, and each triplet holds a resource name, the current usage of that resource, and the resource limit 🍓
Any resource not named in the list isn't limited in that quota root. So an empty list just means there are no administrative resource limits in the quota root 🌸
Example:
S: * QUOTA "" (STORAGE 10 512)4.2.2. QUOTAROOT 🌷
Data: mailbox name
zero or more quota root names
This response shows up as a result of a GETQUOTAROOT command. The first string is the mailbox, and the rest are the names of the quota roots for that mailbox 📬
Examples:
S: * QUOTAROOT INBOX ""
// The INBOX mailbox is covered by a single quota root with
name "".
S: * QUOTAROOT comp.mail.mime
// The comp.mail.mime mailbox has no quota root associated
with it, but one can be created.4.3. Response Codes 👑
4.3.1. OVERQUOTA 🚨
The OVERQUOTA response code SHOULD be returned in the tagged NO response to an APPEND/COPY/MOVE when adding the message(s) pushes the target mailbox over any one of its quota limits 💅
Example 1:
C: A003 APPEND saved-messages (\Seen) {326}
S: + Ready for literal data
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar <foobar@Blurdybloop.example>
C: Subject: afternoon meeting
C: To: mooch@owatagu.siam.edu.example
C: Message-Id: <B27397-0100000@Blurdybloop.example>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: Hello Joe, do you think we can meet at 3:30 tomorrow?
C:
S: A003 NO [OVERQUOTA] APPEND FailedThe OVERQUOTA response code MAY also be returned in an untagged NO response while the connection is in the authenticated or selected state, when a mailbox goes over a soft quota 🫧 For example, the server might send this because of an outside event, like Local Mail Transfer Protocol (LMTP) [RFC2033] delivery, or a COPY/MOVE/APPEND happening in another IMAP connection, that pushes the currently selected mailbox over its soft quota. Heads up though, this kind of OVERQUOTA response code can be ambiguous, since it might be about the target mailbox (from COPY/MOVE/APPEND) or about the currently selected mailbox 🤔 (The EXTRA WG chose not to fix this gap because of syntactic limitations of IMAP response codes, and because these events are likely to be rare.) This form of the OVERQUOTA response code MUST NOT be returned if no mailbox is selected and there's no command in progress that adds a message to a mailbox (like APPEND) 🙅♀️
Example 2:
C: A003 APPEND saved-messages (\Seen) {326}
S: + Ready for literal data
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar <foobar@Blurdybloop.example>
C: Subject: afternoon meeting
C: To: mooch@owatagu.siam.edu.example
C: Message-Id: <B27397-0100000@Blurdybloop.example>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: Hello Joe, do you think we can meet at 3:30 tomorrow?
C:
S: * NO [OVERQUOTA] Soft quota has been exceeded
S: A003 OK [APPENDUID 38505 3955] APPEND completedExample 3:
C: A004 COPY 2:4 MEETING
S: * NO [OVERQUOTA] Soft quota has been exceeded
S: A004 OK [COPYUID 38505 304,319:320 3956:3958] COPY
command completed5. Resource Type Definitions 🎀
The following resource types are defined in this memo. A server supporting a resource type MUST advertise this as a CAPABILITY, with a name made of the resource name prefixed by "QUOTA=RES-". A server MAY support multiple resource types, but it MUST advertise every resource type it supports 🫶
5.1. STORAGE 💾
"STORAGE" is the physical space estimate, in units of 1024 octets, of the mailboxes governed by the quota root. This MAY not be the same as the sum of the RFC822.SIZE of the messages. Some implementations MAY include metadata sizes for the messages and mailboxes, and other implementations MAY store messages in a way that uses less physical space, for example by using compression. Adding more messages might not increase the usage at all 🤏 Clients MUST NOT use the usage figure for anything other than informational purposes. For example, they MUST NOT refuse to APPEND a message if the limit minus the usage is smaller than the RFC822.SIZE of the message divided by 1024 octets, but a client MAY warn about that situation ⚠️
The usage figure may change because of actions that don't add new messages to the mailbox, such as SEARCH, since that can increase the amount of metadata included in the calculations 🔍
When the server supports this resource type, it MUST also support the DELETED-STORAGE status data item 💅
Support for this resource MUST be indicated by the server by advertising the "QUOTA=RES-STORAGE" capability 🌸
A resource with this same name was also given as an example in [RFC2087]. This document provides a more precise definition ✨
5.2. MESSAGE 💌
"MESSAGE" is the number of messages stored within the mailboxes governed by the quota root. This MUST be an exact number. Clients MUST NOT assume that a change in the usage means a change in the number of messages available, since the quota root may include mailboxes the client has no access to 🙈
When the server supports this resource type, it MUST also support the DELETED status data item 🍓
Support for this resource MUST be indicated by the server by advertising the "QUOTA=RES-MESSAGE" capability 🦋
A resource with this same name was also given as an example in [RFC2087]. This document provides a more precise definition 💜
5.3. MAILBOX 📭
"MAILBOX" is the number of mailboxes governed by the quota root. This MUST be an exact number. Clients MUST NOT assume that a change in the usage means a change in the number of mailboxes, since the quota root may include mailboxes the client has no access to 👀
Support for this resource MUST be indicated by the server by advertising the "QUOTA=RES-MAILBOX" capability 🌈
5.4. ANNOTATION-STORAGE 🗂️
"ANNOTATION-STORAGE" is the maximum size of all annotations [RFC5257], in units of 1024 octets, associated with all messages in the mailboxes governed by the quota root 📝
Support for this resource MUST be indicated by the server by advertising the "QUOTA=RES-ANNOTATION-STORAGE" capability 💖
6. Interaction with IMAP ACL Extension (RFC 4314) 🦋
Okay so this section is about who gets to do what when [RFC4314] (the ACL extension) is running alongside this document. Here's the rights chart, bestie 💅
+===================+=+=+===+===+===+===+===+===+===+===+=====+=====+
| Operations\Rights |l|r| s | w | i | c | x | t | e | a | Any | Non |
+===================+=+=+===+===+===+===+===+===+===+===+=====+=====+
| GETQUOTA | | | | | | | | | | | | + |
+-------------------+-+-+---+---+---+---+---+---+---+---+-----+-----+
| GETQUOTAROOT | |*| | | | | | | | | | * |
+-------------------+-+-+---+---+---+---+---+---+---+---+-----+-----+
| SETQUOTA | | | | | | | | | | + | | |
+-------------------+-+-+---+---+---+---+---+---+---+---+-----+-----+
Table 1See Section 4 of [RFC4314] for conventions used in this table. 🎀
Legend time 🧚
"+": The right is required"*": Only one of the rights marked with * is required"Any": At least one of the"l","r","i","k","x", or"a"rights is required"Non": No rights required to perform the command
Now, the GETQUOTAROOT row is the one to watch 👀 Which permissions you need depends on the quota resource type you're asking about. Like, a quota on the number of messages (MESSAGE resource type) or the total size of messages (STORAGE resource type) needs the "r" right on the mailbox in question, because the quota would otherwise reveal how many messages (or how much total size) is sitting in that mailbox. 🙈 Meanwhile the MAILBOX resource type doesn't need any right at all. Lowkey iconic design.
7. Formal Syntax 📜
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF]. 🧚
Non-terminals referenced but not defined below are as defined by IMAP4 [RFC3501] [RFC9051]. 💖
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. 🫶 That MUST is doing a lot of work here, so don't skip it.
getquota = "GETQUOTA" SP quota-root-name
getquotaroot = "GETQUOTAROOT" SP mailbox
quota-list = "(" quota-resource *(SP quota-resource) ")"
quota-resource = resource-name SP resource-usage SP resource-limit
quota-response = "QUOTA" SP quota-root-name SP quota-list
quotaroot-response = "QUOTAROOT" SP mailbox *(SP quota-root-name)
setquota = "SETQUOTA" SP quota-root-name SP setquota-list
setquota-list = "(" [setquota-resource *(SP setquota-resource)]
")"
setquota-resource = resource-name SP resource-limit
quota-root-name = astring
resource-limit = number64
resource-name = "STORAGE" / "MESSAGE" / "MAILBOX" /
"ANNOTATION-STORAGE" / resource-name-ext
resource-name-ext = atom
;; Future resource registrations
resource-usage = number64
;; must be less than corresponding resource-limit
capability-quota = capa-quota-res / "QUOTASET"
;; One or more capa-quota-res must be returned.
;; Also "QUOTASET" can optionally be returned.
capa-quota-res = "QUOTA=RES-" resource-name
status-att =/ "DELETED" / "DELETED-STORAGE"
;; DELETED status data item MUST be supported
;; when the "QUOTA=RES-MESSAGE" capability is
;; advertised.
;; DELETED-STORAGE status data item MUST be
;; supported when the "QUOTA=RES-STORAGE"
;; capability is advertised.
status-att-val =/ status-att-deleted /
status-att-deleted-storage
status-att-deleted = "DELETED" SP number
;; DELETED status data item MUST be supported
;; when the "QUOTA=RES-MESSAGE" capability is
;; advertised.
status-att-deleted-storage = "DELETED-STORAGE" SP number64
;; DELETED-STORAGE status data item MUST be
;; supported when the "QUOTA=RES-STORAGE"
;; capability is advertised.
resp-text-code =/ "OVERQUOTA"
number64 = <Defined in RFC 9051>8. Security Considerations 🔐
Implementors should be careful to make sure the implementation of these commands does not violate the site's security policy. 🚨 The resource usage of other users is likely to be considered confidential information and should not be divulged to unauthorized persons. Like, the tea is private, bestie. In particular, no quota information should be disclosed to anonymous users. 🙅♀️
As for any resource shared across users (for example, a quota root attached to a set of shared mailboxes), a user that can consume or render unusable the resource can affect the resources available to the other users. 😭 This might happen, for example, when a user with permission to execute the SETQUOTA setting sets an artificially small value. Main character villain arc, honestly 💀
Note that computing resource usage might incur a heavy load on the server. Server implementers should consider implementation techniques that lower the load on servers, such as caching of resource usage information or usage of less precise computations when under heavy load. 🫠 Be kind to your servers, they're doing their best 🥹
9. IANA Considerations 🌸
9.1. Changes/Additions to the IMAP Capabilities Registry 🎀
IMAP4 capabilities are registered by publishing a Standards Track or an IESG-approved Informational or Experimental RFC. The "IMAP Capabilities" registry is currently located at https://www.iana.org/assignments/imap4-capabilities. 🗂️
IANA has updated the reference for the QUOTA extension to point to this document. IANA has also added the "QUOTA=" prefix and the "QUOTASET" capability to the "IMAP Capabilities" registry with this document as the reference. ✨
IANA has added the following notes to the "IMAP Capabilities" registry:
The prefix "QUOTA=RES-" is reserved per RFC 9208, Section 9.1. See Section 9.2 of that document for values that follow this prefix. All other capabilities starting with the "QUOTA=" prefix are reserved for future IETF Stream extensions to RFC 9208.
9.2. IMAP Quota Resource Type Registry ✨
okay so IANA made a brand new registry just for IMAP quota resource types 🎀 The registration policy is "Specification Required" [RFC8126], so you need an actual spec to back your new type up. no vibes-only submissions, bestie 💅
When you register a new quota resource type, you need to bring these things:
- the name of the quota resource type
- a short description
- extra required IMAP commands/responses (if any)
- extra optional IMAP commands/responses (if any)
- name and email address of author
- name and email address of change controller
- a reference to a specification that describes the quota resource type in more detail
The designated experts are the ones checking your homework 🧐 They should make sure the references are correct, that the references describe the quota resource type in enough detail that someone could actually implement it, that the syntax of any optional commands/responses is correct (e.g., ABNF validates), and that the syntax and description follow the rules and limitations imposed by IMAP [RFC3501] [RFC9051]. They should also avoid registering multiple identical quota resource types under different names, and they should give requestors advice about other possible quota resource types they could use instead. no duplicate drama, periodt 🙅♀️
Here's the starter pack that's already in the "IMAP Quota Resource Types" registry 🌸
+===================+=======================================+
| field name | field value |
+===================+=======================================+
| Name of the quota | STORAGE |
| resource type: | |
+-------------------+---------------------------------------+
| Description: | The physical space estimate, in units |
| | of 1024 octets, of the mailboxes |
| | governed by the quota root. |
+-------------------+---------------------------------------+
| Extra required | DELETED-STORAGE STATUS request data |
| IMAP commands/ | item and response data item |
| responses: | |
+-------------------+---------------------------------------+
| Extra optional | N/A |
| IMAP commands/ | |
| responses: | |
+-------------------+---------------------------------------+
| Author: | Alexey Melnikov |
| | <alexey.melnikov@isode.com> |
+-------------------+---------------------------------------+
| Change | IESG <iesg@ietf.org> |
| Controller: | |
+-------------------+---------------------------------------+
| Reference: | Section 5.1 of RFC 9208 |
+-------------------+---------------------------------------+
Table 2: STORAGE+=====================+==========================================+
| field name | field value |
+=====================+==========================================+
| Name of the quota | MESSAGE |
| resource type: | |
+---------------------+------------------------------------------+
| Description: | The number of messages stored within the |
| | mailboxes governed by the quota root. |
+---------------------+------------------------------------------+
| Extra required IMAP | DELETED STATUS request data item and |
| commands/responses: | response data item |
+---------------------+------------------------------------------+
| Extra optional IMAP | N/A |
| commands/responses: | |
+---------------------+------------------------------------------+
| Author: | Alexey Melnikov |
| | <alexey.melnikov@isode.com> |
+---------------------+------------------------------------------+
| Change Controller: | IESG <iesg@ietf.org> |
+---------------------+------------------------------------------+
| Reference: | Section 5.2 of RFC 9208 |
+---------------------+------------------------------------------+
Table 3: MESSAGE+==================================+=============================+
| field name | field value |
+==================================+=============================+
| Name of the quota resource type: | MAILBOX |
+----------------------------------+-----------------------------+
| Description: | The number of mailboxes |
| | governed by the quota root. |
+----------------------------------+-----------------------------+
| Extra required IMAP commands/ | N/A |
| responses: | |
+----------------------------------+-----------------------------+
| Extra optional IMAP commands/ | N/A |
| responses: | |
+----------------------------------+-----------------------------+
| Author: | Alexey Melnikov |
| | <alexey.melnikov@isode.com> |
+----------------------------------+-----------------------------+
| Change Controller: | IESG <iesg@ietf.org> |
+----------------------------------+-----------------------------+
| Reference: | Section 5.3 of RFC 9208 |
+----------------------------------+-----------------------------+
Table 4: MAILBOX+================+=======================================+
| field name | field value |
+================+=======================================+
| Name of the | ANNOTATION-STORAGE |
| quota resource | |
| type: | |
+----------------+---------------------------------------+
| Description: | The maximum size of all annotations |
| | [RFC5257], in units of 1024 octets, |
| | associated with all messages in the |
| | mailboxes governed by the quota root. |
+----------------+---------------------------------------+
| Extra required | N/A |
| IMAP commands/ | |
| responses: | |
+----------------+---------------------------------------+
| Extra optional | N/A |
| IMAP commands/ | |
| responses: | |
+----------------+---------------------------------------+
| Author: | Alexey Melnikov |
| | <alexey.melnikov@isode.com> |
+----------------+---------------------------------------+
| Change | IESG <iesg@ietf.org> |
| Controller: | |
+----------------+---------------------------------------+
| Reference: | Section 5.4 of RFC 9208 |
+----------------+---------------------------------------+
Table 5: ANNOTATION-STORAGE10. Changes Since RFC 2087 💜
this doc is a glow-up of [RFC2087] 🦋 It's clarifying what a bunch of the terms mean (the old RFC was a little vague), adding more examples, giving guidance on what servers are allowed to do, creating an IANA registry for quota resource types, and registering 4 of them to start.
Compared to [RFC2087], this document adds two more commonly used resource types, adds an optional OVERQUOTA response code, and defines two extra STATUS data items ("DELETED" and "DELETED-STORAGE"). The DELETED STATUS data item must be implemented if the QUOTA=RES-MESSAGE capability is advertised. The DELETED-STORAGE STATUS data item must be implemented if the QUOTA=RES-STORAGE capability is advertised. And for extensibility, quota usage and quota limits are now 63-bit unsigned integers 🔢✨
the "must" lines above are real requirements, so don't skip them!
11. References 📚
11.1. Normative References
[ABNF] 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/info/rfc5234>.
[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/info/rfc2119>.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
<https://www.rfc-editor.org/info/rfc3501>.
[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
RFC 4314, DOI 10.17487/RFC4314, December 2005,
<https://www.rfc-editor.org/info/rfc4314>.
[RFC5257] Daboo, C. and R. Gellens, "Internet Message Access
Protocol - ANNOTATE Extension", RFC 5257,
DOI 10.17487/RFC5257, June 2008,
<https://www.rfc-editor.org/info/rfc5257>.
[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/info/rfc8174>.
[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/info/rfc9051>.11.2. Informative References
[RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033,
DOI 10.17487/RFC2033, October 1996,
<https://www.rfc-editor.org/info/rfc2033>.
[RFC2087] Myers, J., "IMAP4 QUOTA extension", RFC 2087,
DOI 10.17487/RFC2087, January 1997,
<https://www.rfc-editor.org/info/rfc2087>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.Acknowledgments 🫶
the editor wants to give a huge shoutout to the people who gave useful comments or joined the discussions that led to this update of [RFC2087]: John Myers, Cyrus Daboo, Lyndon Nerenberg, Benjamin Kaduk, Roman Danyliw, and Éric Vyncke. ily all 🩷
This document is a revision of [RFC2087] and borrows a lot of its text, so John Myers, the author of [RFC2087], gets a big thank-you too 🌈
Contributors 🌸
Dave Cridland wrote a lot of text in an earlier draft version, and that text became the basis for this document 👑
Author's Address 🧚
Alexey Melnikov Isode Limited Email: alexey.melnikov@isode.com URI: https://www.isode.com
📦 where this page comes from
- ietf: rfc9208 2022-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms