IMAP LIST-METADATA: IMAP Extension for Returning Mailbox METADATA in Extended LIS
Lets an email client ask for folder list and per-folder annotations in one IMAP command.
Murchison, K. and B. Gondwana, "IMAP Extension for Returning Mailbox METADATA in Extended LIS", RFC 9590, DOI 10.17487/RFC9590, May 2024, <https://www.rfc-editor.org/info/rfc9590>.
@misc{rfc9590,
series = {Request for Comments},
number = 9590,
howpublished = {RFC 9590},
publisher = {RFC Editor},
doi = {10.17487/RFC9590},
url = {https://www.rfc-editor.org/info/rfc9590},
author = {K. Murchison and B. Gondwana},
title = {{IMAP Extension for Returning Mailbox METADATA in Extended LIS}},
pagetotal = 6,
year = 2024,
month = may,
} RFC text
Contents
Internet Engineering Task Force (IETF) K. Murchison
Request for Comments: 9590 B. Gondwana
Category: Standards Track Fastmail
ISSN: 2070-1721 May 2024
IMAP Extension for Returning Mailbox METADATA in Extended LIST
Abstract
This document defines an extension to the Internet Message Access
Protocol (IMAP) LIST command that allows the client to request
mailbox annotations (metadata), along with other information
typically returned by the LIST command.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9590.
Copyright Notice
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 review these documents
carefully, as 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 are provided without warranty as described
in the Revised BSD License.
Table of Contents
1. Introduction
2. Conventions Used in This Document
3. METADATA Return Option to LIST Command
4. Examples
5. Formal Syntax
6. Security Considerations
7. Privacy Considerations
8. IANA Considerations
8.1. Registration of IMAP Capability LIST-METADATA
8.2. Registration of LIST-EXTENDED Option METADATA
9. References
9.1. Normative References
9.2. Informative References
Authors' Addresses
1. Introduction
IMAP clients sometimes fetch mailbox metadata (e.g., color) to
augment the display of mailboxes for the logged-in user. In order to
do that, the client is forced to issue a LIST or LSUB command to list
all available mailboxes, followed by a GETMETADATA command for each
mailbox found. This document defines an extension to the IMAP LIST
command that is identified by the capability string "LIST-METADATA".
The LIST-METADATA extension allows the client to request annotations
on available mailboxes, along with other information typically
returned by the LIST command.
2. Conventions Used in This Document
In examples, "C:" indicates lines sent by a client that is connected
to a server. "S:" indicates lines sent by the server to the client.
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.
Long lines in examples are wrapped using "The Single Backslash
Strategy" described in [RFC8792].
3. METADATA Return Option to LIST Command
[RFC5464] defines the GETMETADATA command that is used by an IMAP
client to retrieve mailbox annotations. Sometimes, a client will
have to look up the metadata for some or all of the mailboxes
returned by the LIST command. Doing so in multiple GETMETADATA
commands wastes bandwidth and can degrade performance if the client
does not pipeline the requests.
This document extends the LIST command with a new return option,
"METADATA", which allows the client to request all of the desired
information in a single command. For each listable mailbox matching
the list pattern and selection options, the server MUST return an
untagged LIST response, followed by one or more untagged METADATA
responses containing the mailbox annotations requested by the client.
The untagged METADATA responses to an extended LIST command have the
same syntax and semantics as those that would be returned by
GETMETADATA commands on the same set of listable mailboxes (see
Section 4.4.1 of [RFC5464]). As per Section 4.4 of [RFC5464], the
server may return all requested annotations in a single METADATA
response for each mailbox, or it may split the requested annotations
into multiple METADATA responses for each mailbox.
If the server is unable to look up the annotations for given mailbox,
it MAY drop the corresponding METADATA response. In such a
situation, the LIST command would still return a tagged OK reply.
4. Examples
The following are examples of fetching metadata from only the top-
level hierarchies of the mailbox using different sets of selection
criteria (see Section 6.3.9 of [RFC9051]).
In this example:
* The "color" annotation for the "foo" mailbox has not been set, so
the METADATA response has a value of "NIL" (i.e., has no value).
* "bar" has children, but isn't an actual mailbox itself, so it has
no METADATA response.
========== NOTE: '\' line wrapping per RFC 8792 ===========
C: A00 CAPABILITY
S: * CAPABILITY IMAP4rev1 IMAP4rev2 \
LIST-EXTENDED LIST-METADATA METADATA
S: A00 OK Completed.
C: A01 LIST "" % \
RETURN (METADATA ("/shared/vendor/cmu/cyrus-imapd/color"))
S: * LIST () "." "INBOX"
S: * METADATA INBOX ("/shared/vendor/cmu/cyrus-imapd/color" "#b71c1c")
S: * LIST () "." "foo"
S: * METADATA "foo" ("/shared/vendor/cmu/cyrus-imapd/color" NIL)
S: * LIST (\NonExistent) "." "bar"
S: A01 OK List completed.
In this example, the LIST response for the "foo" mailbox is returned
because it has matching children, but no METADATA response is
returned because "foo" itself doesn't match the selection criteria.
========== NOTE: '\' line wrapping per RFC 8792 ===========
C: A02 LIST (SUBSCRIBED RECURSIVEMATCH) "" % \
RETURN (METADATA ("/shared/vendor/cmu/cyrus-imapd/color"))
S: * LIST (\Subscribed) "." "INBOX"
S: * METADATA INBOX ("/shared/vendor/cmu/cyrus-imapd/color" "#b71c1c")
S: * LIST () "." "foo" (CHILDINFO ("SUBSCRIBED"))
S: A02 OK List completed.
5. Formal Syntax
The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) as described in [RFC5234]. Note that "return-option" is
defined in [RFC5258] and "entry" is defined in [RFC5464].
return-option =/ "METADATA" SP "(" entry *(SP entry) ")"
6. Security Considerations
This specification does not introduce any additional security
concerns beyond those described in [RFC5258] and [RFC5464].
7. Privacy Considerations
This specification does not introduce any additional privacy concerns
beyond those described in [RFC5464].
8. IANA Considerations
8.1. Registration of IMAP Capability LIST-METADATA
Per this document, IANA has added the "LIST-METADATA" IMAP capability
to the "IMAP Capabilities" registry located at
<https://www.iana.org/assignments/imap4-capabilities/>.
8.2. Registration of LIST-EXTENDED Option METADATA
Per this document, IANA has registered the "METADATA" LIST-EXTENDED
option in the "LIST-EXTENDED options" registry located at
<https://www.iana.org/assignments/imap-list-extended/>.
LIST-EXTENDED option name:
METADATA
LIST-EXTENDED option type:
RETURN
LIST-EXTENDED option description:
Causes the LIST command to return METADATA responses in addition
to LIST responses.
Published specification:
RFC 9590, Section 3
Security considerations:
RFC 9590, Section 6
Intended usage:
COMMON
Person and email address to contact for further information:
Kenneth Murchison <murch@fastmailteam.com> and
Bron Gondwana <brong@fastmailteam.com>
Owner/Change controller:
IESG <iesg@ietf.org>
9. References
9.1. Normative References
[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>.
[RFC5234] 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>.
[RFC5258] Leiba, B. and A. Melnikov, "Internet Message Access
Protocol version 4 - LIST Command Extensions", RFC 5258,
DOI 10.17487/RFC5258, June 2008,
<https://www.rfc-editor.org/info/rfc5258>.
[RFC5464] Daboo, C., "The IMAP METADATA Extension", RFC 5464,
DOI 10.17487/RFC5464, February 2009,
<https://www.rfc-editor.org/info/rfc5464>.
[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>.
9.2. Informative References
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
"Handling Long Lines in Content of Internet-Drafts and
RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
<https://www.rfc-editor.org/info/rfc8792>.
Authors' Addresses
Kenneth Murchison
Fastmail US LLC
1429 Walnut Street
Suite 1201
Philadelphia, PA 19102
United States of America
Email: murch@fastmailteam.com
Bron Gondwana
Fastmail Pty Ltd
Level 2, 114 William Street
Melbourne VIC 3000
Australia
Email: brong@fastmailteam.com
AI ELI5
On this page
§1The Problem and the Extension
IMAP clients sometimes fetch mailbox metadata, for example a color, to improve how mailboxes are displayed. Without this extension, the client must issue a LIST or LSUB command and then a GETMETADATA command for each mailbox found.
This document defines an extension to the IMAP LIST command identified by the capability string LIST-METADATA. It lets the client request mailbox annotations along with the information that LIST normally returns.
Instead of asking one question to get the folder names and then many more to get notes on each folder, you ask once.
§2The METADATA Return Option
RFC 5464 defines GETMETADATA. Doing many of those calls wastes bandwidth and can hurt performance when the client does not pipeline the requests. This document therefore adds a new return option, METADATA, to the extended LIST command.
For each listable mailbox that matches the list pattern and selection options, the server MUST return an untagged LIST response followed by one or more untagged METADATA responses with the requested annotations. These have the same syntax and meaning as responses to GETMETADATA on the same mailboxes. The server may put all annotations in one METADATA response or split them across several.
If the server cannot look up the annotations for a mailbox, it MAY drop that mailbox's METADATA response, and the LIST command still ends with a tagged OK.
For every folder that fits your search, the server tells you its name and then the notes you asked for. If it cannot find the notes for one folder, it skips them and carries on.
§3Examples and Syntax
The RFC's examples fetch a color annotation for top-level mailboxes. A mailbox whose annotation is unset gets a METADATA response with the value NIL. A mailbox such as bar that has children but is not itself a real mailbox gets no METADATA response.
A second example uses SUBSCRIBED RECURSIVEMATCH. The LIST response for foo is returned because it has matching children, but no METADATA response follows because foo itself does not match the selection criteria.
The formal syntax adds a single ABNF rule: return-option =/ "METADATA" SP "(" entry *(SP entry) ")", where the entry names come from RFC 5464.
If a folder has no note yet, the answer is "nothing here". If a name is only a container for other folders, there are no notes to report.
C: A01 LIST "" % RETURN (METADATA ("/shared/vendor/cmu/cyrus-imapd/color"))
S: * LIST () "." "INBOX"
S: * METADATA INBOX ("/shared/vendor/cmu/cyrus-imapd/color" "#b71c1c")
S: * LIST () "." "foo"
S: * METADATA "foo" ("/shared/vendor/cmu/cyrus-imapd/color" NIL)
S: * LIST (\NonExistent) "." "bar"
S: A01 OK List completed.§4Security and Privacy Considerations
The specification introduces no security concerns beyond those in RFC 5258 and RFC 5464, and no privacy concerns beyond those in RFC 5464. The RFC adds no new threats of its own.
Asking for notes in the list does not let anyone see anything they could not already ask for.
§5IANA Registrations
IANA added the LIST-METADATA capability to the IMAP Capabilities registry. It also registered the METADATA option, of type RETURN, in the LIST-EXTENDED options registry. Its description is that it causes the LIST command to return METADATA responses in addition to LIST responses.
The new feature got its official name written in the public list of IMAP features.