Fastmail US LLC

1429 Walnut Street Suite 1201 Philadelphia PA 19102 United States of America murch@fastmailteam.com

Fastmail Pty Ltd

Level 2, 114 William Street Melbourne VIC 3000 Australia brong@fastmailteam.com

ART extra IMAP4 LIST METADATA 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 .

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 () 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

• .  Introduction
• .  Conventions Used in This Document
• .  METADATA Return Option to LIST Command
• .  Examples
• .  Formal Syntax
• .  Security Considerations
• .  Privacy Considerations
• .  IANA Considerations
  • .  Registration of IMAP Capability LIST-METADATA
  • .  Registration of LIST-EXTENDED Option METADATA
• .  References
  • .  Normative References
  • .  Informative References
• Authors' Addresses

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.

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 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 .

METADATA Return Option to LIST Command 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 ). As per , 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.

Examples The following are examples of fetching metadata from only the top-level hierarchies of the mailbox using different sets of selection criteria (see ). 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.

Formal Syntax The following syntax specification uses the Augmented Backus-Naur Form (ABNF) as described in . Note that "return-option" is defined in and "entry" is defined in . return-option =/ "METADATA" SP "(" entry *(SP entry) ")"

Security Considerations This specification does not introduce any additional security concerns beyond those described in and .

Privacy Considerations This specification does not introduce any additional privacy concerns beyond those described in .

IANA Considerations

Registration of IMAP Capability LIST-METADATA Per this document, IANA has added the "LIST-METADATA" IMAP capability to the "IMAP Capabilities" registry located at .

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 .

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,

Security considerations:

RFC 9590,

Intended usage:

COMMON

Person and email address to contact for further information:

<murch@fastmailteam.com> and  <brong@fastmailteam.com>

Owner/Change controller:

IESG <iesg@ietf.org>

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we have added extensions, such as Mailbox Referrals, that have required specialized lists we have had to expand the number of list commands, since each extension must add its function to both LIST and LSUB, and these commands are not, as they are defined, extensible. If we've needed the extensions to work together, we've had to add a set of commands to mix the different options, the set increasing in size with each new extension. This document describes an extension to the base LIST command that will allow these additions to be done with mutually compatible options to the LIST command, avoiding the exponential increase in specialized list commands. [STANDARDS-TRACK] The METADATA extension to the Internet Message Access Protocol permits clients and servers to maintain "annotations" or "metadata" on IMAP servers. It is possible to have annotations on a per-mailbox basis or on the server as a whole. For example, this would allow comments about the purpose of a particular mailbox to be "attached" to that mailbox, or a "message of the day" containing server status information to be made available to anyone logging in to the server. [STANDARDS-TRACK] RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The Internet Message Access Protocol Version 4rev2 (IMAP4rev2) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev2 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev2 also provides the capability for an offline client to resynchronize with the server. IMAP4rev2 includes operations for creating, deleting, and renaming mailboxes; checking for new messages; removing messages permanently; setting and clearing flags; parsing per RFCs 5322, 2045, and 2231; searching; and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev2 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev2 does not specify a means of posting mail; this function is handled by a mail submission protocol such as the one specified in RFC 6409. Informative References This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content.

Authors' Addresses Fastmail US LLC

1429 Walnut Street Suite 1201 Philadelphia PA 19102 United States of America murch@fastmailteam.com

Fastmail Pty Ltd

Level 2, 114 William Street Melbourne VIC 3000 Australia brong@fastmailteam.com