1
2
3
4
5Internet Engineering Task Force (IETF) A. Melnikov
6Request for Comments: 9208 Isode
7Obsoletes: 2087 March 2022
8Category: Standards Track
9ISSN: 2070-1721
10
11
12 IMAP QUOTA Extension
13
14Abstract
15
16 This document defines a QUOTA extension of the Internet Message
17 Access Protocol (IMAP) (see RFCs 3501 and 9051) that permits
18 administrative limits on resource usage (quotas) to be manipulated
19 through the IMAP protocol.
20
21 This document obsoletes RFC 2087 but attempts to remain backwards
22 compatible whenever possible.
23
24Status of This Memo
25
26 This is an Internet Standards Track document.
27
28 This document is a product of the Internet Engineering Task Force
29 (IETF). It represents the consensus of the IETF community. It has
30 received public review and has been approved for publication by the
31 Internet Engineering Steering Group (IESG). Further information on
32 Internet Standards is available in Section 2 of RFC 7841.
33
34 Information about the current status of this document, any errata,
35 and how to provide feedback on it may be obtained at
36 https://www.rfc-editor.org/info/rfc9208.
37
38Copyright Notice
39
40 Copyright (c) 2022 IETF Trust and the persons identified as the
41 document authors. All rights reserved.
42
43 This document is subject to BCP 78 and the IETF Trust's Legal
44 Provisions Relating to IETF Documents
45 (https://trustee.ietf.org/license-info) in effect on the date of
46 publication of this document. Please review these documents
47 carefully, as they describe your rights and restrictions with respect
48 to this document. Code Components extracted from this document must
49 include Revised BSD License text as described in Section 4.e of the
50 Trust Legal Provisions and are provided without warranty as described
51 in the Revised BSD License.
52
53 This document may contain material from IETF Documents or IETF
54 Contributions published or made publicly available before November
55 10, 2008. The person(s) controlling the copyright in some of this
56 material may not have granted the IETF Trust the right to allow
57 modifications of such material outside the IETF Standards Process.
58 Without obtaining an adequate license from the person(s) controlling
59 the copyright in such materials, this document may not be modified
60 outside the IETF Standards Process, and derivative works of it may
61 not be created outside the IETF Standards Process, except to format
62 it for publication as an RFC or to translate it into languages other
63 than English.
64
65Table of Contents
66
67 1. Introduction and Overview
68 2. Document Conventions
69 3. Terms
70 3.1. Resource
71 3.1.1. Name
72 3.1.2. Definition
73 3.2. Quota Root
74 4. Definitions
75 4.1. Commands
76 4.1.1. GETQUOTA
77 4.1.2. GETQUOTAROOT
78 4.1.3. SETQUOTA
79 4.1.4. New STATUS attributes
80 4.2. Responses
81 4.2.1. QUOTA
82 4.2.2. QUOTAROOT
83 4.3. Response Codes
84 4.3.1. OVERQUOTA
85 5. Resource Type Definitions
86 5.1. STORAGE
87 5.2. MESSAGE
88 5.3. MAILBOX
89 5.4. ANNOTATION-STORAGE
90 6. Interaction with IMAP ACL Extension (RFC 4314)
91 7. Formal Syntax
92 8. Security Considerations
93 9. IANA Considerations
94 9.1. Changes/Additions to the IMAP Capabilities Registry
95 9.2. IMAP Quota Resource Type Registry
96 10. Changes Since RFC 2087
97 11. References
98 11.1. Normative References
99 11.2. Informative References
100 Acknowledgments
101 Contributors
102 Author's Address
103
1041. Introduction and Overview
105
106 This document defines a couple of extensions to the Internet Message
107 Access Protocol [RFC3501] [RFC9051] for querying and manipulating
108 administrative limits on resource usage (quotas). This extension is
109 compatible with both IMAP4rev1 [RFC3501] and IMAP4rev2 [RFC9051].
110
111 The "QUOTA" capability denotes a server compliant with [RFC2087]. ../imapserver/server.go:157
112 Some responses and response codes defined in this document are not
113 present in such servers (see Section 10 for more details), and
114 clients MUST NOT rely on their presence in the absence of any
115 capability beginning with "QUOTA=".
116
117 Any server compliant with this document MUST also return at least one
118 capability starting with the "QUOTA=RES-" prefix, as described in
119 Section 3.1.
120
121 Any server compliant with this document that implements the SETQUOTA
122 command (see Section 4.1.3) MUST also return the "QUOTASET"
123 capability.
124
125 This document also reserves all other capabilities starting with the
126 "QUOTA=" prefix for future IETF Stream Standard Track, Informational,
127 or Experimental extensions to this document.
128
129 Quotas can be used to restrict clients for administrative reasons,
130 but the QUOTA extension can also be used to indicate system limits
131 and current usage levels to clients.
132
133 Although the IMAP4 QUOTA extension specified in [RFC2087] has seen
134 deployment in servers, it has seen little deployment in clients.
135 Since the meaning of the resources was implementation dependent, it
136 was impossible for a client implementation to determine which
137 resources were supported, and it was impossible to determine which
138 mailboxes were in a given quota root (see Section 3.2) without a
139 priori knowledge of the implementation.
140
1412. Document Conventions
142
143 In protocol examples, this document uses a prefix of "C: " to denote
144 lines sent by the client to the server and "S: " for lines sent by
145 the server to the client. Lines prefixed with "//" are comments
146 explaining the previous protocol line. These prefixes and comments
147 are not part of the protocol. Lines without any of these prefixes
148 are continuations of the previous line, and no line break is present
149 in the protocol before such lines unless specifically mentioned.
150
151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
153 "OPTIONAL" in this document are to be interpreted as described in
154 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
155 capitals, as shown here.
156
157 Other capitalized words are IMAP keywords [RFC3501] [RFC9051] or
158 keywords from this document.
159
1603. Terms
161
1623.1. Resource
163
164 A resource has a name, a formal definition.
165
1663.1.1. Name
167
168 The resource name is an atom, as defined in IMAP4rev1 [RFC3501].
169 These MUST be registered with IANA.
170
171 Supported resource names MUST be advertised as a capability by
172 prepending the resource name with "QUOTA=RES-". A server compliant
173 with this specification is not required to support all reported
174 resource types on all quota roots.
175
1763.1.2. Definition
177
178 The resource definition or document containing it, while not visible
179 through the protocol, SHOULD be registered with IANA.
180
181 The usage of a resource MUST be represented as a 63-bit unsigned
182 integer. 0 indicates that the resource is exhausted. Usage integers
183 don't necessarily represent proportional use, so clients MUST NOT
184 compare an available resource between two separate quota roots on the
185 same or different servers.
186
187 Limits will be specified as, and MUST be represented as, an integer.
188 0 indicates that any usage is prohibited.
189
190 Limits may be hard or soft; that is, an implementation MAY choose, or
191 be configured, to disallow any command if the limit on a resource is
192 or would be exceeded.
193
194 All resources that the server handles MUST be advertised in a
195 CAPABILITY response/response code consisting of the resource name
196 prefixed by "QUOTA=RES-".
197
198 The resources STORAGE (Section 5.1), MESSAGE (Section 5.2), MAILBOX
199 (Section 5.3), and ANNOTATION-STORAGE (Section 5.4) are defined in
200 this document.
201
2023.2. Quota Root
203
204 This document introduces the concept of a "quota root", as resource
205 limits can apply across multiple IMAP mailboxes.
206
207 Each mailbox has zero or more implementation-defined named "quota
208 roots". Each quota root has zero or more resource limits (quotas).
209 All mailboxes that share the same named quota root share the resource
210 limits of the quota root.
211
212 Quota root names need not be mailbox names, nor is there any
213 relationship defined by this document between a quota root name and a
214 mailbox name. A quota root name is an astring, as defined in IMAP4
215 [RFC3501] [RFC9051]. It SHOULD be treated as an opaque string by any
216 clients.
217
218 Quota roots are used since not all implementations may be able to
219 calculate usage, or apply quotas, on arbitrary mailboxes or mailbox
220 hierarchies.
221
222 Not all resources may be limitable or calculable for all quota roots.
223 Furthermore, not all resources may support all limits; some limits
224 may be present in the underlying system. A server implementation of
225 this memo SHOULD advise the client of such inherent limits, by
226 generating QUOTA (Section 4.2.1) responses, and SHOULD advise the
227 client of which resources are limitable for a particular quota root.
228 A SETQUOTA (Section 4.1.3) command MAY also round a quota limit in an
229 implementation-dependent way, if the granularity of the underlying
230 system demands it. A client MUST be prepared for a SETQUOTA
231 (Section 4.1.3) command to fail if a limit cannot be set.
232
233 Implementation Notes: This means that, for example, under UNIX, a
234 quota root may have a MESSAGE (Section 5.2) quota always set due to
235 the number of inodes available on the filesystem; similarly, STORAGE
236 (Section 5.1) may be rounded to the nearest block and limited by free
237 filesystem space.
238
2394. Definitions
240
2414.1. Commands
242
243 The following commands exist for manipulation and querying quotas.
244
2454.1.1. GETQUOTA 2087:123 ../imapserver/server.go:2934
246
247 Arguments: quota root
248
249 Responses: REQUIRED untagged responses: QUOTA
250
251 Result: OK - getquota completed
252
253 NO - getquota error: no such quota root, permission
254 denied
255
256 BAD - command unknown or arguments invalid
257
258 The GETQUOTA command takes the name of a quota root and returns the
259 quota root's resource usage and limits in an untagged QUOTA response.
260 (Names of quota roots applicable to a particular mailbox can be
261 discovered by issuing the GETQUOTAROOT command; see Section 4.1.2.)
262 Note that the server is not required to support any specific resource
263 type (as advertised in the CAPABILITY response, i.e., all capability
264 items with the "QUOTA=RES-" prefix) for any particular quota root.
265
266 Example:
267
268 S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE [...]
269
270 [...]
271
272 C: G0001 GETQUOTA "!partition/sda4"
273
274 S: * QUOTA "!partition/sda4" (STORAGE 104 10923847)
275
276 S: G0001 OK Getquota complete
277
2784.1.2. GETQUOTAROOT 2087:141 ../imapserver/server.go:2891
279
280 Arguments: mailbox name
281
282 Responses: REQUIRED untagged responses: QUOTAROOT, QUOTA
283
284 Result: OK - getquotaroot completed
285
286 NO - getquotaroot error: permission denied
287
288 BAD - command unknown or arguments invalid
289
290 The GETQUOTAROOT command takes a mailbox name and returns the list of
291 quota roots for the mailbox in an untagged QUOTAROOT response. For
292 each listed quota root, it also returns the quota root's resource
293 usage and limits in an untagged QUOTA response.
294
295 Note that the mailbox name parameter doesn't have to reference an ../imapserver/server.go:2900
296 existing mailbox. This can be handy in order to determine which
297 quota root would apply to a mailbox when it gets created.
298
299 Example:
300
301 S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-MESSAGE
302 [...]
303
304 [...]
305
306 C: G0002 GETQUOTAROOT INBOX
307
308 S: * QUOTAROOT INBOX "#user/alice" "!partition/sda4"
309
310 S: * QUOTA "#user/alice" (MESSAGE 42 1000)
311
312 S: * QUOTA "!partition/sda4" (STORAGE 104 10923847)
313
314 S: G0002 OK Getquotaroot complete
315
3164.1.3. SETQUOTA
317
318 Arguments: quota root list of resource limits
319
320 Responses: untagged responses: QUOTA
321
322 Result: OK - setquota completed
323
324 NO - setquota error: can't set that data
325
326 BAD - command unknown or arguments invalid
327
328 Note that unlike other command/responses/response codes defined in
329 this document, support for the SETQUOTA command requires the server
330 to advertise the "QUOTASET" capability.
331
332 The SETQUOTA command takes the name of a mailbox quota root and a
333 list of resource limits. The resource limits for the named quota
334 root are changed to the specified limits. Any previous resource
335 limits for the named quota root are discarded, even resource limits
336 not explicitly listed in the SETQUOTA command. (For example, if the
337 quota root had both STORAGE and MESSAGE limits assigned to the quota
338 root before the SETQUOTA is called and the SETQUOTA only includes the
339 STORAGE limit, then the MESSAGE limit is removed from the quota
340 root.)
341
342 If the named quota root did not previously exist, an implementation
343 may optionally create it and change the quota roots for any number of
344 existing mailboxes in an implementation-defined manner.
345
346 If the implementation chooses to change the quota roots for some
347 existing mailboxes, such changes SHOULD be announced with untagged
348 QUOTA responses.
349
350 Example:
351
352 S: * CAPABILITY [...] QUOTA QUOTASET QUOTA=RES-STORAGE QUOTA=RES-
353 MESSAGE [...]
354
355 [...]
356
357 C: S0000 GETQUOTA "#user/alice"
358
359 S: * QUOTA "#user/alice" (STORAGE 54 111 MESSAGE 42 1000)
360
361 S: S0000 OK Getquota completed
362
363 C: S0001 SETQUOTA "#user/alice" (STORAGE 510)
364
365 S: * QUOTA "#user/alice" (STORAGE 58 512)
366
367 // The server has rounded the STORAGE quota limit requested to
368 the nearest 512 blocks of 1024 octets; otherwise, another client
369 has performed a near-simultaneous SETQUOTA using a limit of 512.
370
371 S: S0001 OK Rounded quota
372
373 C: S0002 SETQUOTA "!partition/sda4" (STORAGE 99999999)
374
375 S: * QUOTA "!partition/sda4" (STORAGE 104 10923847)
376
377 // The server has not changed the quota, since this is a
378 filesystem limit, and it cannot be changed. The QUOTA
379 response here is entirely optional.
380
381 S: S0002 NO Cannot change system limit
382
3834.1.4. New STATUS attributes
384
385 The DELETED and DELETED-STORAGE status data items allow for
386 estimation of the amount of resources that could be freed by an
387 EXPUNGE on a mailbox.
388
389 The DELETED status data item requests the server to return the number
390 of messages with the \Deleted flag set. The DELETED status data item
391 is only required to be implemented when the server advertises the
392 "QUOTA=RES-MESSAGE" capability.
393
394 The DELETED-STORAGE status data item requests the server to return ../imapserver/server.go:2661
395 the amount of storage space that can be reclaimed by performing
396 EXPUNGE on the mailbox. The server SHOULD return the exact value;
397 however, it is recognized that the server may have to do a non-
398 trivial amount of work to calculate it. If the calculation of the
399 exact value would take a long time, the server MAY instead return the
400 sum of the RFC822.SIZE of the messages with the \Deleted flag set.
401 The DELETED-STORAGE status data item is only required to be
402 implemented when the server advertises the "QUOTA=RES-STORAGE"
403 capability.
404
405 Example:
406
407 S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-
408 MESSAGE [...]
409
410 [...]
411
412 C: S0003 STATUS INBOX (MESSAGES DELETED DELETED-STORAGE)
413
414 S: * STATUS INBOX (MESSAGES 12 DELETED 4 DELETED-STORAGE 8)
415
416 // 12 messages, 4 of which would be deleted when an EXPUNGE
417 happens.
418
419 S: S0003 OK Status complete.
420
4214.2. Responses
422
423 The following responses may be sent by the server.
424
4254.2.1. QUOTA
426
427 Data: quota root name
428
429 list of resource names, usages, and limits
430
431 This response occurs as a result of a GETQUOTA, GETQUOTAROOT, or
432 SETQUOTA command. The first string is the name of the quota root for
433 which this quota applies.
434
435 The name is followed by an S-expression format list of the resource
436 usage and limits of the quota root. The list contains zero or more
437 triplets. Each triplet contains a resource name, the current usage
438 of the resource, and the resource limit.
439
440 Resources not named in the list are not limited in the quota root.
441 Thus, an empty list means there are no administrative resource limits
442 in the quota root.
443
444 Example:
445
446 S: * QUOTA "" (STORAGE 10 512)
447
4484.2.2. QUOTAROOT
449
450 Data: mailbox name
451
452 zero or more quota root names
453
454 This response occurs as a result of a GETQUOTAROOT command. The
455 first string is the mailbox and the remaining strings are the names
456 of the quota roots for the mailbox.
457
458 Examples:
459
460 S: * QUOTAROOT INBOX ""
461
462 // The INBOX mailbox is covered by a single quota root with
463 name "".
464
465 S: * QUOTAROOT comp.mail.mime
466
467 // The comp.mail.mime mailbox has no quota root associated
468 with it, but one can be created.
469
4704.3. Response Codes
471
4724.3.1. OVERQUOTA 9051:5155 ../imapclient/parse.go:120 ../imapserver/server.go:2807 ../imapserver/server.go:3363
473
474 The OVERQUOTA response code SHOULD be returned in the tagged NO
475 response to an APPEND/COPY/MOVE when the addition of the message(s)
476 puts the target mailbox over any one of its quota limits.
477
478 Example 1:
479
480 C: A003 APPEND saved-messages (\Seen) {326}
481 S: + Ready for literal data
482 C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
483 C: From: Fred Foobar <foobar@Blurdybloop.example>
484 C: Subject: afternoon meeting
485 C: To: mooch@owatagu.siam.edu.example
486 C: Message-Id: <B27397-0100000@Blurdybloop.example>
487 C: MIME-Version: 1.0
488 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
489 C:
490 C: Hello Joe, do you think we can meet at 3:30 tomorrow?
491 C:
492 S: A003 NO [OVERQUOTA] APPEND Failed
493
494 The OVERQUOTA response code MAY also be returned in an untagged NO
495 response in the authenticated or the selected state when a mailbox
496 exceeds soft quota. For example, such OVERQUOTA response codes might
497 be sent as a result of an external event (e.g., Local Mail Transfer
498 Protocol (LMTP) [RFC2033] delivery or COPY/MOVE/APPEND in another
499 IMAP connection) that causes the currently selected mailbox to exceed
500 soft quota. Note that such an OVERQUOTA response code might be
501 ambiguous because it might relate to the target mailbox (as specified
502 in COPY/MOVE/APPEND) or to the currently selected mailbox. (The
503 EXTRA WG chose not to address this deficiency due to syntactic
504 limitations of IMAP response codes and because such events are likely
505 to be rare.) This form of the OVERQUOTA response codes MUST NOT be
506 returned if there is no mailbox selected and no command in progress
507 that adds a message to a mailbox (e.g., APPEND).
508
509 Example 2:
510
511 C: A003 APPEND saved-messages (\Seen) {326}
512 S: + Ready for literal data
513 C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
514 C: From: Fred Foobar <foobar@Blurdybloop.example>
515 C: Subject: afternoon meeting
516 C: To: mooch@owatagu.siam.edu.example
517 C: Message-Id: <B27397-0100000@Blurdybloop.example>
518 C: MIME-Version: 1.0
519 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
520 C:
521 C: Hello Joe, do you think we can meet at 3:30 tomorrow?
522 C:
523 S: * NO [OVERQUOTA] Soft quota has been exceeded
524 S: A003 OK [APPENDUID 38505 3955] APPEND completed
525
526 Example 3:
527
528 C: A004 COPY 2:4 MEETING
529 S: * NO [OVERQUOTA] Soft quota has been exceeded
530 S: A004 OK [COPYUID 38505 304,319:320 3956:3958] COPY
531 command completed
532
5335. Resource Type Definitions ../imapclient/protocol.go:287
534
535 The following resource types are defined in this memo. A server
536 supporting a resource type MUST advertise this as a CAPABILITY with a
537 name consisting of the resource name prefixed by "QUOTA=RES-". A
538 server MAY support multiple resource types and MUST advertise all
539 resource types it supports.
540
5415.1. STORAGE
542
543 "STORAGE" is the physical space estimate, in units of 1024 octets, of
544 the mailboxes governed by the quota root. This MAY not be the same
545 as the sum of the RFC822.SIZE of the messages. Some implementations
546 MAY include metadata sizes for the messages and mailboxes, and other
547 implementations MAY store messages in such a way that the physical
548 space used is smaller, for example, due to use of compression.
549 Additional messages might not increase the usage. Clients MUST NOT
550 use the usage figure for anything other than informational purposes;
551 for example, they MUST NOT refuse to APPEND a message if the limit
552 less the usage is smaller than the RFC822.SIZE divided by 1024 octets
553 of the message, but it MAY warn about such condition.
554
555 The usage figure may change as a result of performing actions not
556 associated with adding new messages to the mailbox, such as SEARCH,
557 since this may increase the amount of metadata included in the
558 calculations.
559
560 When the server supports this resource type, it MUST also support the
561 DELETED-STORAGE status data item.
562
563 Support for this resource MUST be indicated by the server by
564 advertising the "QUOTA=RES-STORAGE" capability.
565
566 A resource named the same was also given as an example in [RFC2087].
567 This document provides a more precise definition.
568
5695.2. MESSAGE
570
571 "MESSAGE" is the number of messages stored within the mailboxes
572 governed by the quota root. This MUST be an exact number; however,
573 clients MUST NOT assume that a change in the usage indicates a change
574 in the number of messages available, since the quota root may include
575 mailboxes the client has no access to.
576
577 When the server supports this resource type, it MUST also support the
578 DELETED status data item.
579
580 Support for this resource MUST be indicated by the server by
581 advertising the "QUOTA=RES-MESSAGE" capability.
582
583 A resource named the same was also given as an example in [RFC2087].
584 This document provides a more precise definition.
585
5865.3. MAILBOX
587
588 "MAILBOX" is the number of mailboxes governed by the quota root.
589 This MUST be an exact number; however, clients MUST NOT assume that a
590 change in the usage indicates a change in the number of mailboxes,
591 since the quota root may include mailboxes the client has no access
592 to.
593
594 Support for this resource MUST be indicated by the server by
595 advertising the "QUOTA=RES-MAILBOX" capability.
596
5975.4. ANNOTATION-STORAGE
598
599 "ANNOTATION-STORAGE" is the maximum size of all annotations
600 [RFC5257], in units of 1024 octets, associated with all messages in
601 the mailboxes governed by the quota root.
602
603 Support for this resource MUST be indicated by the server by
604 advertising the "QUOTA=RES-ANNOTATION-STORAGE" capability.
605
6066. Interaction with IMAP ACL Extension (RFC 4314)
607
608 This section lists [RFC4314] rights required to execute quota-related
609 commands when both RFC 4314 and this document are implemented.
610
611 +===================+=+=+===+===+===+===+===+===+===+===+=====+=====+
612 | Operations\Rights |l|r| s | w | i | c | x | t | e | a | Any | Non |
613 +===================+=+=+===+===+===+===+===+===+===+===+=====+=====+
614 | GETQUOTA | | | | | | | | | | | | + |
615 +-------------------+-+-+---+---+---+---+---+---+---+---+-----+-----+
616 | GETQUOTAROOT | |*| | | | | | | | | | * |
617 +-------------------+-+-+---+---+---+---+---+---+---+---+-----+-----+
618 | SETQUOTA | | | | | | | | | | + | | |
619 +-------------------+-+-+---+---+---+---+---+---+---+---+-----+-----+
620
621 Table 1
622
623 See Section 4 of [RFC4314] for conventions used in this table.
624
625 Legend:
626
627 "+": The right is required
628
629 "*": Only one of the rights marked with * is required
630
631 "Any": At least one of the "l", "r", "i", "k", "x", or "a" rights is
632 required
633
634 "Non": No rights required to perform the command
635
636 Note that which permissions are needed in order to perform a
637 GETQUOTAROOT command depends on the quota resource type being
638 requested. For example, a quota on the number of messages (MESSAGE
639 resource type) or total size of messages (STORAGE resource type)
640 requires "r" right on the mailbox in question, since the quota
641 involved would reveal information about the number (or total size) of
642 messages in the mailbox. By comparison, the MAILBOX resource type
643 doesn't require any right.
644
6457. Formal Syntax
646
647 The following syntax specification uses the Augmented Backus-Naur
648 Form (ABNF) notation as specified in [ABNF].
649
650 Non-terminals referenced but not defined below are as defined by
651 IMAP4 [RFC3501] [RFC9051].
652
653 Except as noted otherwise, all alphabetic characters are case
654 insensitive. The use of uppercase or lowercase characters to define
655 token strings is for editorial clarity only. Implementations MUST
656 accept these strings in a case-insensitive fashion.
657
658 getquota = "GETQUOTA" SP quota-root-name 2087:231 ../imapserver/server.go:2936
659
660 getquotaroot = "GETQUOTAROOT" SP mailbox 2087:233 ../imapserver/server.go:2893
661
662 quota-list = "(" quota-resource *(SP quota-resource) ")"
663
664 quota-resource = resource-name SP resource-usage SP resource-limit
665
666 quota-response = "QUOTA" SP quota-root-name SP quota-list 2087:239 ../imapclient/parse.go:507 ../imapserver/server.go:2924 ../imapserver/server.go:2962
667
668 quotaroot-response = "QUOTAROOT" SP mailbox *(SP quota-root-name) 2087:242 ../imapclient/parse.go:495 ../imapserver/server.go:2918
669
670 setquota = "SETQUOTA" SP quota-root-name SP setquota-list
671
672 setquota-list = "(" [setquota-resource *(SP setquota-resource)]
673 ")"
674
675 setquota-resource = resource-name SP resource-limit
676
677 quota-root-name = astring
678
679 resource-limit = number64
680
681 resource-name = "STORAGE" / "MESSAGE" / "MAILBOX" /
682 "ANNOTATION-STORAGE" / resource-name-ext
683
684 resource-name-ext = atom
685 ;; Future resource registrations
686
687 resource-usage = number64
688 ;; must be less than corresponding resource-limit
689
690 capability-quota = capa-quota-res / "QUOTASET"
691 ;; One or more capa-quota-res must be returned.
692 ;; Also "QUOTASET" can optionally be returned.
693
694 capa-quota-res = "QUOTA=RES-" resource-name
695
696 status-att =/ "DELETED" / "DELETED-STORAGE" 9051:7056 3501:5047 7889:252 7162:2452 ../imapserver/parse.go:439
697 ;; DELETED status data item MUST be supported
698 ;; when the "QUOTA=RES-MESSAGE" capability is
699 ;; advertised.
700 ;; DELETED-STORAGE status data item MUST be
701 ;; supported when the "QUOTA=RES-STORAGE"
702 ;; capability is advertised.
703
704 status-att-val =/ status-att-deleted /
705 status-att-deleted-storage
706
707 status-att-deleted = "DELETED" SP number
708 ;; DELETED status data item MUST be supported
709 ;; when the "QUOTA=RES-MESSAGE" capability is
710 ;; advertised.
711
712 status-att-deleted-storage = "DELETED-STORAGE" SP number64 9051:6681 9051:7070 9051:7059 3501:4834 ../imapserver/server.go:2634
713 ;; DELETED-STORAGE status data item MUST be
714 ;; supported when the "QUOTA=RES-STORAGE"
715 ;; capability is advertised.
716
717 resp-text-code =/ "OVERQUOTA"
718
719 number64 = <Defined in RFC 9051>
720
7218. Security Considerations
722
723 Implementors should be careful to make sure the implementation of
724 these commands does not violate the site's security policy. The
725 resource usage of other users is likely to be considered confidential
726 information and should not be divulged to unauthorized persons. In
727 particular, no quota information should be disclosed to anonymous
728 users.
729
730 As for any resource shared across users (for example, a quota root
731 attached to a set of shared mailboxes), a user that can consume or
732 render unusable the resource can affect the resources available to
733 the other users; this might occur, for example, by a user with
734 permission to execute the SETQUOTA setting, which sets an
735 artificially small value.
736
737 Note that computing resource usage might incur a heavy load on the
738 server. Server implementers should consider implementation
739 techniques that lower the load on servers such as caching of resource
740 usage information or usage of less precise computations when under
741 heavy load.
742
7439. IANA Considerations
744
7459.1. Changes/Additions to the IMAP Capabilities Registry
746
747 IMAP4 capabilities are registered by publishing a Standards Track or
748 an IESG-approved Informational or Experimental RFC. The "IMAP
749 Capabilities" registry is currently located at
750 <https://www.iana.org/assignments/imap4-capabilities>.
751
752 IANA has updated the reference for the QUOTA extension to point to
753 this document. IANA has also added the "QUOTA=" prefix and the
754 "QUOTASET" capability to the "IMAP Capabilities" registry with this
755 document as the reference.
756
757 IANA has added the following notes to the "IMAP Capabilities"
758 registry:
759
760 The prefix "QUOTA=RES-" is reserved per RFC 9208, Section 9.1. See
761 Section 9.2 of that document for values that follow this prefix.
762
763 All other capabilities starting with the "QUOTA=" prefix are reserved
764 for future IETF Stream extensions to RFC 9208.
765
7669.2. IMAP Quota Resource Type Registry
767
768 IANA has created a new registry for IMAP quota resource types. The
769 registration policy for the "IMAP Quota Resource Types" registry is
770 "Specification Required" [RFC8126].
771
772 When registering a new quota resource type, the registrant needs to
773 provide the following:
774
775 * the name of the quota resource type
776
777 * a short description
778
779 * extra required IMAP commands/responses (if any)
780
781 * extra optional IMAP commands/responses (if any)
782
783 * name and email address of author
784
785 * name and email address of change controller
786
787 * a reference to a specification that describes the quota resource
788 type in more detail
789
790 Designated experts should check that the provided references are
791 correct, the references describe the quota resource type being
792 registered in sufficient detail to be implementable, the syntax of
793 any optional commands/responses is correct (e.g., ABNF validates),
794 and the syntax/description complies with rules and limitations
795 imposed by IMAP [RFC3501] [RFC9051]. Designated experts should avoid
796 registering multiple identical quota resource types under different
797 names and should provide advice to requestors about other possible
798 quota resource types to use.
799
800 The initial contents of the "IMAP Quota Resource Types" registry are
801 as follows:
802
803 +===================+=======================================+
804 | field name | field value |
805 +===================+=======================================+
806 | Name of the quota | STORAGE |
807 | resource type: | |
808 +-------------------+---------------------------------------+
809 | Description: | The physical space estimate, in units |
810 | | of 1024 octets, of the mailboxes |
811 | | governed by the quota root. |
812 +-------------------+---------------------------------------+
813 | Extra required | DELETED-STORAGE STATUS request data |
814 | IMAP commands/ | item and response data item |
815 | responses: | |
816 +-------------------+---------------------------------------+
817 | Extra optional | N/A |
818 | IMAP commands/ | |
819 | responses: | |
820 +-------------------+---------------------------------------+
821 | Author: | Alexey Melnikov |
822 | | <alexey.melnikov@isode.com> |
823 +-------------------+---------------------------------------+
824 | Change | IESG <iesg@ietf.org> |
825 | Controller: | |
826 +-------------------+---------------------------------------+
827 | Reference: | Section 5.1 of RFC 9208 |
828 +-------------------+---------------------------------------+
829
830 Table 2: STORAGE
831
832 +=====================+==========================================+
833 | field name | field value |
834 +=====================+==========================================+
835 | Name of the quota | MESSAGE |
836 | resource type: | |
837 +---------------------+------------------------------------------+
838 | Description: | The number of messages stored within the |
839 | | mailboxes governed by the quota root. |
840 +---------------------+------------------------------------------+
841 | Extra required IMAP | DELETED STATUS request data item and |
842 | commands/responses: | response data item |
843 +---------------------+------------------------------------------+
844 | Extra optional IMAP | N/A |
845 | commands/responses: | |
846 +---------------------+------------------------------------------+
847 | Author: | Alexey Melnikov |
848 | | <alexey.melnikov@isode.com> |
849 +---------------------+------------------------------------------+
850 | Change Controller: | IESG <iesg@ietf.org> |
851 +---------------------+------------------------------------------+
852 | Reference: | Section 5.2 of RFC 9208 |
853 +---------------------+------------------------------------------+
854
855 Table 3: MESSAGE
856
857 +==================================+=============================+
858 | field name | field value |
859 +==================================+=============================+
860 | Name of the quota resource type: | MAILBOX |
861 +----------------------------------+-----------------------------+
862 | Description: | The number of mailboxes |
863 | | governed by the quota root. |
864 +----------------------------------+-----------------------------+
865 | Extra required IMAP commands/ | N/A |
866 | responses: | |
867 +----------------------------------+-----------------------------+
868 | Extra optional IMAP commands/ | N/A |
869 | responses: | |
870 +----------------------------------+-----------------------------+
871 | Author: | Alexey Melnikov |
872 | | <alexey.melnikov@isode.com> |
873 +----------------------------------+-----------------------------+
874 | Change Controller: | IESG <iesg@ietf.org> |
875 +----------------------------------+-----------------------------+
876 | Reference: | Section 5.3 of RFC 9208 |
877 +----------------------------------+-----------------------------+
878
879 Table 4: MAILBOX
880
881 +================+=======================================+
882 | field name | field value |
883 +================+=======================================+
884 | Name of the | ANNOTATION-STORAGE |
885 | quota resource | |
886 | type: | |
887 +----------------+---------------------------------------+
888 | Description: | The maximum size of all annotations |
889 | | [RFC5257], in units of 1024 octets, |
890 | | associated with all messages in the |
891 | | mailboxes governed by the quota root. |
892 +----------------+---------------------------------------+
893 | Extra required | N/A |
894 | IMAP commands/ | |
895 | responses: | |
896 +----------------+---------------------------------------+
897 | Extra optional | N/A |
898 | IMAP commands/ | |
899 | responses: | |
900 +----------------+---------------------------------------+
901 | Author: | Alexey Melnikov |
902 | | <alexey.melnikov@isode.com> |
903 +----------------+---------------------------------------+
904 | Change | IESG <iesg@ietf.org> |
905 | Controller: | |
906 +----------------+---------------------------------------+
907 | Reference: | Section 5.4 of RFC 9208 |
908 +----------------+---------------------------------------+
909
910 Table 5: ANNOTATION-STORAGE
911
91210. Changes Since RFC 2087
913
914 This document is a revision of [RFC2087], and it aims to clarify the
915 meaning of different terms that were used in that RFC. It also
916 provides more examples, gives guidance on allowed server behavior,
917 defines an IANA registry for quota resource types, and provides
918 initial registrations for 4 of them.
919
920 When compared with [RFC2087], this document defines two more commonly
921 used resource types, adds an optional OVERQUOTA response code, and
922 defines two extra STATUS data items ("DELETED" and "DELETED-
923 STORAGE"). The DELETED STATUS data item must be implemented if the
924 "QUOTA=RES-MESSAGE" capability is advertised. The DELETED-STORAGE
925 STATUS data item must be implemented if the "QUOTA=RES-STORAGE"
926 capability is advertised. For extensibility, quota usage and quota
927 limits are now 63-bit unsigned integers.
928
92911. References
930
93111.1. Normative References
932
933 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
934 Specifications: ABNF", STD 68, RFC 5234,
935 DOI 10.17487/RFC5234, January 2008,
936 <https://www.rfc-editor.org/info/rfc5234>.
937
938 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
939 Requirement Levels", BCP 14, RFC 2119,
940 DOI 10.17487/RFC2119, March 1997,
941 <https://www.rfc-editor.org/info/rfc2119>.
942
943 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
944 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
945 <https://www.rfc-editor.org/info/rfc3501>.
946
947 [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
948 RFC 4314, DOI 10.17487/RFC4314, December 2005,
949 <https://www.rfc-editor.org/info/rfc4314>.
950
951 [RFC5257] Daboo, C. and R. Gellens, "Internet Message Access
952 Protocol - ANNOTATE Extension", RFC 5257,
953 DOI 10.17487/RFC5257, June 2008,
954 <https://www.rfc-editor.org/info/rfc5257>.
955
956 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
957 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
958 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
959
960 [RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message
961 Access Protocol (IMAP) - Version 4rev2", RFC 9051,
962 DOI 10.17487/RFC9051, August 2021,
963 <https://www.rfc-editor.org/info/rfc9051>.
964
96511.2. Informative References
966
967 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033,
968 DOI 10.17487/RFC2033, October 1996,
969 <https://www.rfc-editor.org/info/rfc2033>.
970
971 [RFC2087] Myers, J., "IMAP4 QUOTA extension", RFC 2087,
972 DOI 10.17487/RFC2087, January 1997,
973 <https://www.rfc-editor.org/info/rfc2087>.
974
975 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
976 Writing an IANA Considerations Section in RFCs", BCP 26,
977 RFC 8126, DOI 10.17487/RFC8126, June 2017,
978 <https://www.rfc-editor.org/info/rfc8126>.
979
980Acknowledgments
981
982 The editor of this document would like to thank the following people
983 who provided useful comments or participated in discussions that lead
984 to this update of [RFC2087]: John Myers, Cyrus Daboo, Lyndon
985 Nerenberg, Benjamin Kaduk, Roman Danyliw, and Éric Vyncke.
986
987 This document is a revision of [RFC2087], and it borrows a lot of
988 text from that RFC. Thus, the work of John Myers, the author of
989 [RFC2087], is appreciated.
990
991Contributors
992
993 Dave Cridland wrote a lot of text in an earlier draft version that
994 became the basis for this document.
995
996Author's Address
997
998 Alexey Melnikov
999 Isode Limited
1000 Email: alexey.melnikov@isode.com
1001 URI: https://www.isode.com
1002