5Internet Engineering Task Force (IETF) K. Murchison
6Request for Comments: 9590 B. Gondwana
7Category: Standards Track Fastmail
8ISSN: 2070-1721 May 2024
11 IMAP Extension for Returning Mailbox METADATA in Extended LIST
15 This document defines an extension to the Internet Message Access
16 Protocol (IMAP) LIST command that allows the client to request
17 mailbox annotations (metadata), along with other information
18 typically returned by the LIST command.
22 This is an Internet Standards Track document.
24 This document is a product of the Internet Engineering Task Force
25 (IETF). It represents the consensus of the IETF community. It has
26 received public review and has been approved for publication by the
27 Internet Engineering Steering Group (IESG). Further information on
28 Internet Standards is available in Section 2 of RFC 7841.
30 Information about the current status of this document, any errata,
31 and how to provide feedback on it may be obtained at
32 https://www.rfc-editor.org/info/rfc9590.
36 Copyright (c) 2024 IETF Trust and the persons identified as the
37 document authors. All rights reserved.
39 This document is subject to BCP 78 and the IETF Trust's Legal
40 Provisions Relating to IETF Documents
41 (https://trustee.ietf.org/license-info) in effect on the date of
42 publication of this document. Please review these documents
43 carefully, as they describe your rights and restrictions with respect
44 to this document. Code Components extracted from this document must
45 include Revised BSD License text as described in Section 4.e of the
46 Trust Legal Provisions and are provided without warranty as described
47 in the Revised BSD License.
52 2. Conventions Used in This Document
53 3. METADATA Return Option to LIST Command
56 6. Security Considerations
57 7. Privacy Considerations
58 8. IANA Considerations
59 8.1. Registration of IMAP Capability LIST-METADATA
60 8.2. Registration of LIST-EXTENDED Option METADATA
62 9.1. Normative References
63 9.2. Informative References
68 IMAP clients sometimes fetch mailbox metadata (e.g., color) to
69 augment the display of mailboxes for the logged-in user. In order to
70 do that, the client is forced to issue a LIST or LSUB command to list
71 all available mailboxes, followed by a GETMETADATA command for each
72 mailbox found. This document defines an extension to the IMAP LIST
74 The LIST-METADATA extension allows the client to request annotations
75 on available mailboxes, along with other information typically
76 returned by the LIST command.
782. Conventions Used in This Document
80 In examples, "C:" indicates lines sent by a client that is connected
81 to a server. "S:" indicates lines sent by the server to the client.
83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
85 "OPTIONAL" in this document are to be interpreted as described in
86 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
87 capitals, as shown here.
89 Long lines in examples are wrapped using "The Single Backslash
90 Strategy" described in [RFC8792].
923. METADATA Return Option to LIST Command
94 [RFC5464] defines the GETMETADATA command that is used by an IMAP
95 client to retrieve mailbox annotations. Sometimes, a client will
96 have to look up the metadata for some or all of the mailboxes
97 returned by the LIST command. Doing so in multiple GETMETADATA
98 commands wastes bandwidth and can degrade performance if the client
99 does not pipeline the requests.
102 "METADATA", which allows the client to request all of the desired
103 information in a single command. For each listable mailbox matching
104 the list pattern and selection options, the server MUST return an
105 untagged LIST response, followed by one or more untagged METADATA
106 responses containing the mailbox annotations requested by the client.
107 The untagged METADATA responses to an extended LIST command have the
108 same syntax and semantics as those that would be returned by
109 GETMETADATA commands on the same set of listable mailboxes (see
110 Section 4.4.1 of [RFC5464]). As per Section 4.4 of [RFC5464], the
111 server may return all requested annotations in a single METADATA
112 response for each mailbox, or it may split the requested annotations
113 into multiple METADATA responses for each mailbox.
115 If the server is unable to look up the annotations for given mailbox,
116 it MAY drop the corresponding METADATA response. In such a
117 situation, the LIST command would still return a tagged OK reply.
121 The following are examples of fetching metadata from only the top-
122 level hierarchies of the mailbox using different sets of selection
123 criteria (see Section 6.3.9 of [RFC9051]).
127 * The "color" annotation for the "foo" mailbox has not been set, so
128 the METADATA response has a value of "NIL" (i.e., has no value).
130 * "bar" has children, but isn't an actual mailbox itself, so it has
131 no METADATA response.
133 ========== NOTE: '\' line wrapping per RFC 8792 ===========
136 S: * CAPABILITY IMAP4rev1 IMAP4rev2 \
137 LIST-EXTENDED LIST-METADATA METADATA
140 RETURN (METADATA ("/shared/vendor/cmu/cyrus-imapd/color"))
141 S: * LIST () "." "INBOX"
142 S: * METADATA INBOX ("/shared/vendor/cmu/cyrus-imapd/color" "#b71c1c")
143 S: * LIST () "." "foo"
144 S: * METADATA "foo" ("/shared/vendor/cmu/cyrus-imapd/color" NIL)
145 S: * LIST (\NonExistent) "." "bar"
146 S: A01 OK List completed.
148 In this example, the LIST response for the "foo" mailbox is returned
149 because it has matching children, but no METADATA response is
150 returned because "foo" itself doesn't match the selection criteria.
152 ========== NOTE: '\' line wrapping per RFC 8792 ===========
154 C: A02 LIST (SUBSCRIBED RECURSIVEMATCH) "" % \
155 RETURN (METADATA ("/shared/vendor/cmu/cyrus-imapd/color"))
156 S: * LIST (\Subscribed) "." "INBOX"
157 S: * METADATA INBOX ("/shared/vendor/cmu/cyrus-imapd/color" "#b71c1c")
158 S: * LIST () "." "foo" (CHILDINFO ("SUBSCRIBED"))
159 S: A02 OK List completed.
163 The following syntax specification uses the Augmented Backus-Naur
164 Form (ABNF) as described in [RFC5234]. Note that "return-option" is
165 defined in [RFC5258] and "entry" is defined in [RFC5464].
1696. Security Considerations
171 This specification does not introduce any additional security
172 concerns beyond those described in [RFC5258] and [RFC5464].
1747. Privacy Considerations
176 This specification does not introduce any additional privacy concerns
177 beyond those described in [RFC5464].
1798. IANA Considerations
1818.1. Registration of IMAP Capability LIST-METADATA
183 Per this document, IANA has added the "LIST-METADATA" IMAP capability
184 to the "IMAP Capabilities" registry located at
185 <https://www.iana.org/assignments/imap4-capabilities/>.
1878.2. Registration of LIST-EXTENDED Option METADATA
189 Per this document, IANA has registered the "METADATA" LIST-EXTENDED
190 option in the "LIST-EXTENDED options" registry located at
191 <https://www.iana.org/assignments/imap-list-extended/>.
193 LIST-EXTENDED option name:
196 LIST-EXTENDED option type:
199 LIST-EXTENDED option description:
200 Causes the LIST command to return METADATA responses in addition
203 Published specification:
206 Security considerations:
212 Person and email address to contact for further information:
213 Kenneth Murchison <murch@fastmailteam.com> and
214 Bron Gondwana <brong@fastmailteam.com>
216 Owner/Change controller:
2219.1. Normative References
223 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
224 Requirement Levels", BCP 14, RFC 2119,
225 DOI 10.17487/RFC2119, March 1997,
226 <https://www.rfc-editor.org/info/rfc2119>.
228 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
229 Specifications: ABNF", STD 68, RFC 5234,
230 DOI 10.17487/RFC5234, January 2008,
231 <https://www.rfc-editor.org/info/rfc5234>.
233 [RFC5258] Leiba, B. and A. Melnikov, "Internet Message Access
234 Protocol version 4 - LIST Command Extensions", RFC 5258,
235 DOI 10.17487/RFC5258, June 2008,
236 <https://www.rfc-editor.org/info/rfc5258>.
238 [RFC5464] Daboo, C., "The IMAP METADATA Extension", RFC 5464,
239 DOI 10.17487/RFC5464, February 2009,
240 <https://www.rfc-editor.org/info/rfc5464>.
242 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
243 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
244 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
246 [RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message
247 Access Protocol (IMAP) - Version 4rev2", RFC 9051,
248 DOI 10.17487/RFC9051, August 2021,
249 <https://www.rfc-editor.org/info/rfc9051>.
2519.2. Informative References
253 [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
254 "Handling Long Lines in Content of Internet-Drafts and
255 RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
256 <https://www.rfc-editor.org/info/rfc8792>.
264 Philadelphia, PA 19102
265 United States of America
266 Email: murch@fastmailteam.com
271 Level 2, 114 William Street
274 Email: brong@fastmailteam.com