Internet-Draft IMAP LIST-METADATA September 2022
Murchison & Gondwana Expires 23 March 2023 [Page]
Intended Status:
Standards Track
K. Murchison
B. Gondwana

IMAP4 Extension for Returning Mailbox METADATA in Extended LIST


This document defines an extension to the to 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 Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 23 March 2023.

1. Introduction

IMAP clients sometimes fetch mailbox metadata (e.g. color) to augment the display of mailboxes to 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 to 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 [RFC2119].

3. METADATA Return Option to LIST Command

[RFC5464] defines the GETMETADATA command which 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. As per [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 it desires.

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

Note that the line wrapping of the extended LIST commands below is for editorial purposes only.

In this example:

  • The "color" annotation for the "foo" mailbox has not been set, so the METADATA response has a value of "NIL" (has no value).
  • The "bar" mailbox doesn't exist, so it has no METADATA response.
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.

         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 (BNF) as described in [RFC5234]. Note that "return-option" is defined in [RFC5258] and "entry" is defined in [RFC5464].

return-option =/ "METADATA" "(" entry *(SP entry) ")"

6. Security Considerations

This specification does not introduce any additional security concerns beyond those described in [RFC5258].

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

This document defines the "LIST-METADATA" IMAP capability to be added to the registry defined in Section 12 of [RFC3501].

8.2. Registration of LIST-EXTENDED option METADATA

This section registers the "METADATA" option to be added to the registry defined in Section 9 of [RFC5258].

LIST-EXTENDED option name:
LIST-EXTENDED option type:
LIST-EXTENDED option description:
Causes the LIST command to return METADATA responses in addition to LIST responses.
Published specification:
RFC XXXX, Section 3
Security considerations:
RFC XXXX, Section 6
Intended usage:
Person and email address to contact for further information:
Kenneth Murchison <>, Bron Gondwana <>
Owner/Change controller:

9. References

9.1. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, , <>.
Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, , <>.
Leiba, B. and A. Melnikov, "Internet Message Access Protocol version 4 - LIST Command Extensions", RFC 5258, DOI 10.17487/RFC5258, , <>.
Daboo, C., "The IMAP METADATA Extension", RFC 5464, DOI 10.17487/RFC5464, , <>.

Authors' Addresses

Kenneth Murchison
Fastmail US LLC
1429 Walnut Street - Suite 1201
Philadelphia, PA 19102
United States of America
Bron Gondwana
Fastmail Pty Ltd
Level 2, 114 William Street
Melbourne VIC 3000