IMAP QUOTA Extension
obsoletes
- rfc-2087 — IMAP4 QUOTA extension
Extracted elements (29)
Quota roots are used rather than per-mailbox quotas because not all implementations can calculate usage or apply quotas on arbitrary mailboxes or hierarchies; a quota root may span multiple mailboxes and need not be named after any mailbox.
Quota usage and limits are now 63-bit unsigned integers (number64 from RFC 9051), an extension from RFC 2087, to provide sufficient headroom for large storage and message counts in modern deployments.
RFC 2087 saw little client deployment because resource meanings were implementation-dependent, making it impossible for clients to determine which resources were supported or which mailboxes belonged to a quota root without prior knowledge; this document standardizes resource types and capability advertisement to fix this.
When RFC 4314 ACL is also implemented: GETQUOTA requires no ACL right; GETQUOTAROOT requires 'r' right for MESSAGE or STORAGE resources (as they reveal message counts/sizes), but no right for MAILBOX; SETQUOTA requires the 'a' (administer) right.
Any server compliant with this document MUST return at least one capability starting with the 'QUOTA=RES-' prefix, advertising which resource types it supports.
Any server compliant with this document that implements the SETQUOTA command MUST also return the 'QUOTASET' capability.
Clients MUST NOT rely on responses and response codes defined in this document (beyond those in RFC 2087) in the absence of any capability beginning with 'QUOTA='.
Clients MUST NOT use the STORAGE usage figure to decide whether to refuse an APPEND; for example, they MUST NOT refuse APPEND solely because the limit minus usage is smaller than RFC822.SIZE/1024 of the message.
If the implementation chooses to change quota roots for existing mailboxes as a side-effect of SETQUOTA creating a new quota root, such changes SHOULD be announced with untagged QUOTA responses.
Resource names MUST be registered with IANA and MUST be advertised as a capability by prepending the resource name with 'QUOTA=RES-'.
The OVERQUOTA response code in an untagged NO (for soft quota exceeded) MUST NOT be returned if there is no mailbox selected and no command in progress that adds a message to a mailbox.
The usage of a resource MUST be represented as a 63-bit unsigned integer; clients MUST NOT compare an available resource between two separate quota roots on the same or different servers.
ANNOTATION-STORAGE is the maximum size of all annotations (RFC 5257), in units of 1024 octets, associated with all messages in the mailboxes governed by the quota root.
MAILBOX is the exact number of mailboxes governed by the quota root; clients MUST NOT assume a change in usage indicates a change in the number of accessible mailboxes.
MESSAGE is the exact number of messages stored within the mailboxes under the quota root; clients MUST NOT assume a change in usage indicates a change in number of accessible messages, since inaccessible mailboxes are included.
STORAGE is the physical space estimate in units of 1024 octets of mailboxes under the quota root; it MAY differ from the sum of RFC822.SIZE values due to metadata, compression, or other implementation factors.
The DELETED STATUS data item returns the number of messages with the \Deleted flag set in a mailbox; it is only required to be implemented when the server advertises 'QUOTA=RES-MESSAGE'.
The DELETED-STORAGE STATUS data item returns the amount of storage reclaimable by EXPUNGE; the server SHOULD return the exact value but MAY return the sum of RFC822.SIZE of \Deleted messages if exact calculation is too expensive.
The GETQUOTA command takes the name of a quota root and returns the quota root's resource usage and limits in an untagged QUOTA response. The server returns NO if the quota root does not exist or permission is denied.
The GETQUOTAROOT command takes a mailbox name and returns the list of quota roots for the mailbox in an untagged QUOTAROOT response, plus a QUOTA response for each listed quota root. The mailbox name need not reference an existing mailbox.
The OVERQUOTA response code SHOULD be returned in the tagged NO response to APPEND/COPY/MOVE when adding message(s) would exceed any quota limit on the target mailbox.
The SETQUOTA command takes the name of a mailbox quota root and a list of resource limits; any previous resource limits for the named quota root are discarded, including those not explicitly listed in the command.
IANA created the 'IMAP Quota Resource Types' registry with 'Specification Required' policy, with initial entries for STORAGE, MESSAGE, MAILBOX, and ANNOTATION-STORAGE resource types.
IANA updated the IMAP Capabilities registry to reference RFC 9208, added the 'QUOTA=' prefix reservation and the 'QUOTASET' capability; the 'QUOTA=RES-' prefix is reserved for quota resource types defined in Section 9.2.
Computing resource usage may impose heavy server load; implementers should consider caching usage information or using less precise computations under high load.
For quota roots shared across users (e.g., shared mailboxes), a user who can consume or set the resource can affect availability for other users; for example, by setting an artificially small SETQUOTA value.
Resource usage of other users is confidential information and must not be divulged to unauthorized persons; no quota information should be disclosed to anonymous users.
The QUOTA untagged response carries the quota root name followed by a parenthesized list of zero or more resource triplets: resource-name SP resource-usage SP resource-limit. Resources not listed are not limited.
The QUOTAROOT untagged response carries the mailbox name followed by zero or more quota root names (astrings); zero names indicates the mailbox has no quota root but one may be created.