RFC 5258

Internet Message Access Protocol version 4 - LIST Command Extensions

📅 published June 2008, from ietf

Internet Message Access Protocol version 4 - LIST Command Extensions 💌

Okay bestie, the title block is giving a LOT, so here's the tea ✨ This is RFC 5258, published in June 2008 by the Network Working Group. It's a Standards Track doc, so it's an actual Internet protocol standard 🔥 The authors are B. Leiba from the IBM T.J. Watson Research Center and A. Melnikov from Isode Limited 🫶 It obsoletes RFC 3348, so that one is officially retired 💀, and it updates RFC 2193, so that one gets a glow-up 🎀

Status of This Memo 📜

This document is an Internet standards track protocol for the Internet community, and it's open for discussion and suggestions for improvements 💬 For the current standardization state and status of this protocol, check the "Internet Official Protocol Standards" (STD 1) doc 🔍 Distribution of this memo is unlimited, so share it with everyone 🌈

Abstract 🦋

Okay so IMAP4 has two commands for listing mailboxes, LIST and LSUB. Every time an extension came along, like Mailbox Referrals, it needed its own specialized list, so we kept adding list commands. Each extension had to add its function to BOTH LIST and LSUB, and these commands aren't extensible as they're defined 😭 If the extensions needed to work together, we had to add yet another set of commands to mix the different options, and that set got bigger with every new extension. Literally exponential chaos 💀

This document fixes that by adding an extension to the base LIST command. Instead of a pile of new commands, you get mutually compatible options on LIST, which means no exponential explosion of specialized list commands ✨

Table of Contents

   1.  Introduction and Overview  . . . . . . . . . . . . . . . . . .  3
   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
   3.  Extended LIST Command  . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Initial List of Selection Options  . . . . . . . . . . . .  7
     3.2.  Initial List of Return Options . . . . . . . . . . . . . .  8
     3.3.  General Principles for Returning LIST Responses  . . . . .  9
     3.4.  Additional Requirements on LIST-EXTENDED Clients . . . . .  9
     3.5.  CHILDINFO Extended Data Item . . . . . . . . . . . . . . . 10
   4.  The CHILDREN Return Option . . . . . . . . . . . . . . . . . . 11
   5.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   6.  Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . . 19
   7.  Internationalization Considerations  . . . . . . . . . . . . . 22
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 23
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
     9.1.  Guidelines for IANA  . . . . . . . . . . . . . . . . . . . 23
     9.2.  Registration Procedure and Change Control  . . . . . . . . 23
     9.3.  Registration Template for LIST-EXTENDED Options  . . . . . 25
     9.4.  Initial LIST-EXTENDED Option Registrations . . . . . . . . 25
     9.5.  Registration Template for LIST-EXTENDED Extended Data
           Item . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
     9.6.  Initial LIST-EXTENDED Extended Data Item Registrations . . 28
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 29
     11.2. Informative References . . . . . . . . . . . . . . . . . . 30

1. Introduction and Overview ✨

Okay so the LIST command gets extended by changing its syntax so it can take options and multiple patterns 🧚 The list of options replaces all those commands people were using to mix and match the info they wanted. The new syntax is backward compatible with no ambiguity. The new syntax gets used if ANY of these is true:

if the first word after the command name begins with a parenthesis ("LIST selection options")
if the second word after the command name begins with a parenthesis ("multiple mailbox patterns")
if the LIST command has more than 2 parameters ("LIST return options")

Otherwise the original syntax is used 🍓

Now the spicy part 🌶️ By adding options to LIST, we're announcing that we intend to phase out and eventually deprecate the RLIST and RLSUB commands described in [MBRef] 👋 We're also defining how to request extended mailbox info, like what's described in the Child Mailbox Extension [CMbox]. The base LSUB command is NOT deprecated by this extension, lowkey. Instead, this extension adds a way to get subscription info with more options, on servers that support it. Clients that just need a list of subscribed mailboxes, the way LSUB gives them, SHOULD continue to use that command 💅

This document defines an IMAP4 extension identified by the capability string "LIST-EXTENDED" 🦋 The extension changes the IMAP4 protocol in these ways, with more detail in Section 3 and Section 4:

a. defines new syntax for LIST command options.
b. extends LIST to allow for multiple mailbox patterns.
c. adds LIST command selection options: SUBSCRIBED, REMOTE, and RECURSIVEMATCH.
d. adds LIST command return options: SUBSCRIBED and CHILDREN.
e. adds new mailbox attributes: \NonExistent, \Subscribed, \Remote, \HasChildren, and \HasNoChildren.
f. adds CHILDINFO extended data item.

2. Conventions Used in This Document 🎀

In examples, C: marks lines sent by a client connected to a server, and S: marks lines the server sends back to the client 💬

The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are used in this document as specified in RFC 2119 [Kwds]. Those are the official vibes for requirement levels, so read them carefully bestie 🫶

The term "canonical LIST pattern" refers to the canonical pattern the server builds internally from the reference and mailbox name arguments (Section 6.3.8 of [IMAP4]). The [IMAP4] LIST command only returns mailboxes that match the canonical LIST pattern 🔍

Other terms get introduced right where they're first referenced, so keep reading and you'll catch them 🌸

3. Extended LIST Command ✨

Okay bestie, the LIST command is getting a full glow-up 💅 This extension lets you send multiple mailbox patterns at once, as long as you wrap them in parentheses 🎀 A mailbox name matches a list of patterns if it matches at least one of them. And if a mailbox name matches more than one pattern in the list, the server SHOULD return only a single LIST response. No duplicates, no drama 🫶

Ngl there's a catch. The plain, non-extended LIST command has to treat an empty ("" string) mailbox name as a special request for the hierarchy delimiter and the root name of whatever is in the reference parameter (as per [IMAP4]). But ANY extended LIST command (extended in any of 3 ways from Section 1, or any combo of them) MUST NOT treat the empty mailbox name as that special request 🙈 Regular processing applies instead. And if an extended LIST command has multiple mailbox names and one or more of them is the empty string, that empty string MUST be ignored for the purpose of matching. Periodt, it just gets ignored 💀

Some servers might restrict which patterns they allow in a LIST command. If a server doesn't accept a particular pattern, it MUST silently ignore it 🍓

The LIST command syntax gets two more upgrades 🦋 First, a parenthesized list of command options goes between the command name and the reference name (these are the LIST selection options). Second, there's an optional list of options at the end that controls what kind of information comes back (these are the LIST return options). Check Section 6 for the formal syntax, it has all the nitty-gritty details 📚

A LIST selection option tells the server which mailbox names to select for the LIST operation. The server should return information about all mailbox names that match any of the "canonical LIST pattern" (described above) and satisfy any extra selection criteria (if there are any) specified by the LIST selection options. Let's call any such mailbox name a "matched mailbox name" 💜 When multiple selection options are specified, the server MUST return information about mailbox names that satisfy every selection option, unless the description of a particular option sets special rules. RECURSIVEMATCH is one of those rule-breakers, and we'll get to it later in this section. We'll use the term "selection criteria" to talk about all the selection options in a LIST command together.

A LIST return option controls which information comes back for each matched mailbox name. Return options MUST NOT cause the server to report information about additional mailbox names. If the client doesn't specify any return option, the server should only return information about attributes. (The server is totally allowed to include other info too if it wants, no judgement 🌈)

Both selection and return options are defined in this document and in approved extension documents. Each option is enabled by a capability string (one capability can enable multiple options), and a client MUST NOT send an option that the server hasn't advertised support for 🙅‍♀️ A server MUST respond to options it doesn't recognize with a BAD response. The client SHOULD NOT specify any option more than once, but if it does, the server MUST act as if it received that option only once. The order the client lists options in doesn't matter ✨

In general, every selection option except RECURSIVEMATCH has a matching return option. REMOTE is the anomaly here 🧚 It doesn't have a corresponding return option, because it expands the set of mailboxes returned instead of restricting it. Future extensions should keep parallelism in mind and define a pair of corresponding options 🎀

This extension is identified by the capability string "LIST-EXTENDED", and support for it is a prerequisite for any future extensions that need specialized forms of the LIST command. Those extensions MUST refer to this document and MUST add their function through command options, as described here 💅 Extensions that don't need an extended LIST command, but do use extended LIST responses (see below), don't need to advertise the "LIST-EXTENDED" capability string. Main character behavior, honestly 👑

This extension also adds extended fields to the LIST response. They go at the end as a parenthesized list of tagged data (also called an "extended data item"). The first element of an extended field is a tag, which identifies the type of data. Tags MUST be registered with IANA, as described in Section 9.5 of this document 🌸 Here's an example of what an extended set might look like:

tablecloth (("edge" "lacy") ("color" "red"))) (X-Sample "text"))

tablecloth ("edge" "lacy")) (X-Sample "text" "more text"))

See the formal syntax in Section 6 for the full details. The server MUST NOT return any extended data item unless the client has shown it can support extended LIST responses, for example by using an extended LIST command 🔒 The server MAY return data in the extended fields that the client didn't directly ask for in the corresponding LIST command. For example, the client can turn on extra extended fields by using another IMAP extension that makes use of extended LIST responses 🦋 And the client MUST ignore all extended fields it doesn't recognize. Not your business, bestie 💅

The LIST-EXTENDED capability also defines several new mailbox attributes 🌈

The "\NonExistent" attribute indicates that a mailbox name does not refer to an existing mailbox. Note that this attribute isn't very meaningful by itself 🙈 Mailbox names that match the canonical LIST pattern but don't exist must not be returned, unless one of the two conditions below is also satisfied:

a. The mailbox name also satisfies the selection criteria (for example, it's subscribed and the "SUBSCRIBED" selection option has been specified).

b. "RECURSIVEMATCH" has been specified, and the mailbox name has at least one descendant mailbox name that does not match the LIST pattern but does match the selection criteria.

In practice, this means the "\NonExistent" attribute usually comes back with one or more of "\Subscribed", "\Remote", "\HasChildren", or the CHILDINFO extended data item (see their descriptions below) 🍓

The "\NonExistent" attribute implies "\NoSelect". The "\NonExistent" attribute MUST be supported and MUST be accurately computed 💖

3.1. Initial List of Selection Options

The selection options defined in this specification are as follows:

SUBSCRIBED 🎀 causes the LIST command to list subscribed names, rather than the existing mailboxes. This will often be a subset of the actual mailboxes. It's also possible for this list to contain the names of mailboxes that don't exist. In any case, the list MUST include exactly those mailbox names that match the canonical list pattern and are subscribed to. This option is intended to supplement the LSUB command. The mailbox attributes returned by this option are the real tea compared to what LSUB gives you. With LSUB, the attributes returned may not reflect the actual attribute status on the mailbox name, and the \NoSelect attribute has a second special meaning (it indicates that this mailbox is not, itself, subscribed, but that it has descendant mailboxes that are). With the SUBSCRIBED selection option described here, the attributes are accurate and complete, and have no special meanings. "LSUB" and "LIST (SUBSCRIBED)" are, thus, not the same thing, and some servers must do significant extra work to respond to "LIST (SUBSCRIBED)". Because of this, clients SHOULD continue to use "LSUB" unless they specifically want the additional information offered by "LIST (SUBSCRIBED)" 🧁

This option defines a new mailbox attribute, "\Subscribed", that indicates a mailbox name is subscribed to. The "\Subscribed" attribute MUST be supported and MUST be accurately computed when the SUBSCRIBED selection option is specified 💜

Note that the SUBSCRIBED selection option implies the SUBSCRIBED return option (see below) ✨

REMOTE 🌍 causes the LIST command to show remote mailboxes as well as local ones, as described in [MBRef]. This option is intended to replace the RLIST command and, in conjunction with the SUBSCRIBED selection option, the RLSUB command 🦋

This option defines a new mailbox attribute, "\Remote", that indicates a mailbox is a remote mailbox. The "\Remote" attribute MUST be accurately computed when the REMOTE option is specified 🌸

The REMOTE selection option has no interaction with other options. Its effect is to tell the server to apply the other options, if any, to remote mailboxes in addition to local ones. In particular, it has no interaction with RECURSIVEMATCH (see below). A request for (REMOTE RECURSIVEMATCH) is invalid, because a request for (RECURSIVEMATCH) is. A request for (REMOTE RECURSIVEMATCH SUBSCRIBED) is asking for all subscribed mailboxes, both local and remote 🔥

RECURSIVEMATCH 🧚 this option forces the server to return information about parent mailboxes that don't match the other selection options, but do have some submailboxes that do. Information about children is returned in the CHILDINFO extended data item, as described in Section 3.5 👑

Note 1: For a parent mailbox to be returned, it still has to match the canonical LIST pattern.

Note 2: When returning the CHILDINFO extended data item, it doesn't matter whether or not the submailbox matches the canonical LIST pattern. See also example 9 in Section 5 🙈

The RECURSIVEMATCH option MUST NOT occur as the only selection option (or only with REMOTE), because it only makes sense when other selection options are also used. The server MUST return a BAD tagged response in that case 💀

Even if the RECURSIVEMATCH option is specified, the client MUST still be able to handle the case where a CHILDINFO extended data item is returned and there are no submailboxes that meet the selection criteria of the subsequent LIST command. That's because they can be deleted or renamed after the LIST response was sent, but before the client had a chance to access them 🫶

3.2. Initial List of Return Options

The return options defined in this specification are as follows:

SUBSCRIBED 🎀 causes the LIST command to return subscription state for all matching mailbox names. The "\Subscribed" attribute MUST be supported and MUST be accurately computed when the SUBSCRIBED return option is specified. Further, all mailbox flags MUST be accurately computed (this differs from how the LSUB command behaves) 💖

CHILDREN 🌈 requests mailbox child information, as originally proposed in [CMbox]. See Section 4, below, for the details. This option MUST be supported by all servers 🧁

3.3. General Principles for Returning LIST Responses 🎀

okay so this section is basically the server's cheat sheet for deciding whether to send a LIST response back, how many to send, and what info goes inside them 📝 the vibe is giving organized ✨

At most one LIST response should be returned for each mailbox name that matches the canonical LIST pattern. Server implementors must not assume that clients will be able to assemble mailbox attributes and other information returned in multiple LIST responses. 💅
There are only two reasons for including a matching mailbox name in the responses to the LIST command. (Note that the server is allowed to return unsolicited responses at any time, and those are not governed by this rule 🦋)
- A. The mailbox name also satisfies the selection criteria.
- B. The mailbox name doesn't satisfy the selection criteria, but it has at least one descendant mailbox name that satisfies the selection criteria and that doesn't match the canonical LIST pattern.

For more information on case B, see the CHILDINFO extended data item described in Section 3.5. Note that the CHILDINFO extended data item can only be returned when the RECURSIVEMATCH selection option is specified. 🌸

Attributes returned in the same LIST response must be treated additively. For example, this response:

S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"

means that the "Fruit/Peach" mailbox doesn't exist, but it is subscribed. 🍓 so the attributes stack, they don't cancel each other out 🙈

3.4. Additional Requirements on LIST-EXTENDED Clients 💖

All clients that support this extension MUST treat an attribute with a stronger meaning as implying any attribute that can be inferred from it. For example, the client must treat the presence of the \NoInferiors attribute as if the \HasNoChildren attribute was also sent by the server. 🫶 the strong attribute carries the weaker one with it, iykyk

The table below summarizes the inference rules described in Section 3. 🧚

            +--------------------+-------------------+
            | returned attribute | implied attribute |
            +--------------------+-------------------+
            |    \NoInferiors    |   \HasNoChildren  |
            |    \NonExistent    |     \NoSelect     |
            +--------------------+-------------------+

3.5. CHILDINFO Extended Data Item 👑

The CHILDINFO extended data item MUST NOT be returned unless the client has specified the RECURSIVEMATCH selection option. 🙅‍♀️

The CHILDINFO extended data item in a LIST response describes the selection criteria that caused it to be returned, and it indicates that the mailbox has at least one descendant mailbox that matches those selection criteria. ✨

The LSUB command signals this condition by using the "\NoSelect" attribute, but the LIST (SUBSCRIBED) command MUST NOT do that, since "\NoSelect" keeps its original meaning here. Also, the CHILDINFO extended data item is more general, because it can be used with any extended set of selection criteria. 💅 it's the upgrade that works with everything 🌈

Note: Some servers allow mailboxes to exist without requiring their parent to exist. For example, a mailbox "Customers/ABC" can exist while the mailbox "Customers" does not. Because the CHILDINFO extended data item isn't allowed if the RECURSIVEMATCH selection option isn't specified, such servers SHOULD use the "\NonExistent \HasChildren" attribute pair to tell the client that there is a descendant mailbox that matches the selection criteria. See example 11 in Section 5. 🙈

The returned selection criteria let the client tell a solicited response apart from an unsolicited one, and they also let it tell apart solicited responses caused by multiple pipelined LIST commands that specify different criteria. 🔥

Servers SHOULD ONLY return a non-matching mailbox name along with CHILDINFO if at least one matching child is not also being returned. That is, servers SHOULD suppress redundant CHILDINFO responses. 🧹 no doubled-up info, bestie 💖

Examples 8 and 10 in Section 5 show the difference between a present CHILDINFO extended data item and the "\HasChildren" attribute. 🦋

The table below summarizes how the "\NonExistent" attribute and CHILDINFO interact. (The first column shows whether the parent mailbox exists.) 💀

+--------+--------------+--------------------+----------------------+
| exists |   meets the  |  has a child that  |       returned       |
|        |   selection  |      meets the     |     LIST-EXTENDED    |
|        |   criteria   | selection criteria |    attributes and    |
|        |              |                    |       CHILDINFO      |
+--------+--------------+--------------------+----------------------+
|   no   |      no      |         no         |   no LIST response   |
|        |              |                    |       returned       |
|   yes  |      no      |         no         |   no LIST response   |
|        |              |                    |       returned       |
|   no   |      yes     |         no         |     (\NonExistent    |
|        |              |                    |        <attr>)       |
|   yes  |      yes     |         no         |       (<attr>)       |
|   no   |      no      |         yes        |   (\NonExistent) +   |
|        |              |                    |       CHILDINFO      |
|   yes  |      no      |         yes        |    () + CHILDINFO    |
|   no   |      yes     |         yes        |     (\NonExistent    |
|        |              |                    |  <attr>) + CHILDINFO |
|   yes  |      yes     |         yes        | (<attr>) + CHILDINFO |
+--------+--------------+--------------------+----------------------+

where <attr> is one or more attributes that correspond to the selection criteria. For example, for the SUBSCRIBED option, the <attr> is \Subscribed. 🌸

4. The CHILDREN Return Option 🌷

The CHILDREN return option implements the Child Mailbox Extension, originally proposed by Mike Gahrns and Raymond Cheng, of Microsoft Corporation. Most of the information in this section is taken directly from their original specification [CMbox]. The CHILDREN return option is simply a way for the client to say it wants this information. A server MAY provide it even if the option is not specified. 🎀

Lots of IMAP4 [IMAP4] clients show the user a hierarchical view of the mailboxes they can access. Rather than showing the whole mailbox hierarchy right away, it's often nicer to show a collapsed outline list (especially when there are a ton of mailboxes 😭). The user can then expand the outline as needed. It's super common to put a visual clue in the collapsed list, like ''+'', to show that a mailbox has child mailboxes under it. When that clue gets clicked, the list expands to show the children. The CHILDREN return option gives the client a way to efficiently figure out whether a mailbox has children, without issuing LIST "" * or LIST "" % for each mailbox name. 🧚 no more spamming LIST for every single folder 🫶

The CHILDREN return option defines two new attributes that MUST be returned within a LIST response: \HasChildren and \HasNoChildren. Although these attributes MAY be returned in response to any LIST command, the CHILDREN return option exists to show that the client especially wants this information. If the CHILDREN return option is present, the server MUST return these attributes even if computing them is expensive. 💜

\HasChildren

The presence of this attribute indicates that the mailbox has child mailboxes. A server SHOULD NOT set this attribute if there are child mailboxes but the user does not have permission to access any of them. In that case, \HasNoChildren SHOULD be used. In many cases, though, a server may not be able to efficiently compute whether a user has access to any child mailbox. 🙈

Also, even though the \HasChildren attribute for a mailbox must be correct at the time the mailbox is processed, a client must be ready for a situation where a mailbox is marked with \HasChildren but no child mailbox shows up in the response to the LIST command. This might happen, for example, if another client deleted the children or made them inaccessible to the user (using access control) before the server got around to listing them. 💀 plot twist, the children vanished 😭

\HasNoChildren

The presence of this attribute indicates that the mailbox has NO child mailboxes that are accessible to the currently authenticated user. 🦋

It is an error for the server to return both a \HasChildren and a \HasNoChildren attribute in the same LIST response. ⚠️

Note: the \HasNoChildren attribute should not be confused with the \NoInferiors attribute defined in IMAP4 [IMAP4]. \NoInferiors means that no child mailboxes exist now and none can be created in the future. Different vibes entirely 🙅‍♀️💅

5. Examples ✨

Example 1 🧚 okay so this first one shows the whole local hierarchy that every other example uses. Think of it as the cast list before the show starts 🎀

C: A01 LIST "" "*"
S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST () "/" "Fruit"
S: * LIST () "/" "Fruit/Apple"
S: * LIST () "/" "Fruit/Banana"
S: * LIST () "/" "Tofu"
S: * LIST () "/" "Vegetable"
S: * LIST () "/" "Vegetable/Broccoli"
S: * LIST () "/" "Vegetable/Corn"
S: A01 OK done

Example 2 🍓 now we get the subscribed mailboxes. It's similar to <LSUB "" "*">, but not the same thing, so don't mix them up bestie 🙈 Watch the "Fruit/Peach" mailbox: it's subscribed but doesn't actually exist anymore (maybe it got deleted while still subscribed, ouch). "Fruit" isn't subscribed, but it has two subscribed kids. "Vegetable" is subscribed and has two children, and one of those is subscribed too. Iconic family drama 💅

C: A02 LIST (SUBSCRIBED) "" "*"
S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
S: * LIST (\Subscribed) "/" "Fruit/Banana"
S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
S: * LIST (\Subscribed) "/" "Vegetable"
S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
S: A02 OK done

Example 3 🦋 this one shows the CHILDREN option in action. The client gets to find out which top-level mailboxes have submailboxes and which don't, without having to list the second level of hierarchy. Lowkey genius 🧠 Also, the server doesn't need to send \HasNoChildren for the inbox, because \NoInferiors already says that and says it harder ✨

C: A03 LIST () "" "%" RETURN (CHILDREN)
S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST (\HasChildren) "/" "Fruit"
S: * LIST (\HasNoChildren) "/" "Tofu"
S: * LIST (\HasChildren) "/" "Vegetable"
S: A03 OK done

Example 4 🌈 more mailboxes, this time living on another server. This is basically the same vibe as <RLIST "" "%">.

C: A04 LIST (REMOTE) "" "%" RETURN (CHILDREN)
S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST (\HasChildren) "/" "Fruit"
S: * LIST (\HasNoChildren) "/" "Tofu"
S: * LIST (\HasChildren) "/" "Vegetable"
S: * LIST (\Remote) "/" "Bread"
S: * LIST (\HasChildren \Remote) "/" "Meat"
S: A04 OK done

Example 5 💜 this one also asks for remote mailboxes, but now the server only returns the subscribed ones. It's like <RLSUB "" "*">. We also get to see two selection options working together, which is very main character energy 👑

C: A05 LIST (REMOTE SUBSCRIBED) "" "*"
S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
S: * LIST (\Subscribed) "/" "Fruit/Banana"
S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
S: * LIST (\Subscribed) "/" "Vegetable"
S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
S: * LIST (\Remote \Subscribed) "/" "Bread"
S: A05 OK done

Example 6 🎀 same remote energy, but now the server is asked for subscription info on every mailbox it returns. Different from the one above, so don't get it twisted 🙃

Note that the output here is not a superset of the previous example's output, because it doesn't include a LIST response for the non-existent "Fruit/Peach". Plot twist 😭

C: A06 LIST (REMOTE) "" "*" RETURN (SUBSCRIBED)
S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
S: * LIST () "/" "Fruit"
S: * LIST () "/" "Fruit/Apple"
S: * LIST (\Subscribed) "/" "Fruit/Banana"
S: * LIST () "/" "Tofu"
S: * LIST (\Subscribed) "/" "Vegetable"
S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
S: * LIST () "/" "Vegetable/Corn"
S: * LIST (\Remote \Subscribed) "/" "Bread"
S: * LIST (\Remote) "/" "Meat"
S: A06 OK done

Example 7 🧁 here the client sends multiple mailbox patterns at once. Also, this one doesn't use the hierarchy from the earlier examples, so it's a whole new storyline ✨

C: BBB LIST "" ("INBOX" "Drafts" "Sent/%")
S: * LIST () "/" "INBOX"
S: * LIST (\NoInferiors) "/" "Drafts"
S: * LIST () "/" "Sent/March2004"
S: * LIST (\Marked) "/" "Sent/December2003"
S: * LIST () "/" "Sent/August2004"
S: BBB OK done

Example 8 🔍 this is the one where we compare the \HasChildren attribute with the CHILDINFO extended data item. Pay attention, it's giving detective 🕵️‍♀️

Let's assume there is the following hierarchy:

C: C01 LIST "" "*"
S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST () "/" "Foo"
S: * LIST () "/" "Foo/Bar"
S: * LIST () "/" "Foo/Baz"
S: * LIST () "/" "Moo"
S: C01 OK done

If the client asks for RETURN (CHILDREN), it gets this:

C: CA3 LIST "" "%" RETURN (CHILDREN)
S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST (\HasChildren) "/" "Foo"
S: * LIST (\HasNoChildren) "/" "Moo"
S: CA3 OK done

A) 🌸 let's also assume that "Foo/Baz" is the only subscribed mailbox. Then we get this:

C: C02 LIST (SUBSCRIBED) "" "*"
S: * LIST (\Subscribed) "/" "Foo/Baz"
S: C02 OK done

Now, if the client issues <LIST (SUBSCRIBED) "" "%">, the server returns no mailboxes at all, because "Moo", "Foo", and "Inbox" are not subscribed. Dead silence 💀 But if the client does this:

C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
S: * LIST () "/" "Foo" ("CHILDINFO" ("SUBSCRIBED"))
S: C04 OK done

(i.e., "Foo" is not subscribed, but it has a child that is.) 🫶

A1) ✨ if "Foo" had also been subscribed, the last command would return this:

C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
S: * LIST (\Subscribed) "/" "Foo" ("CHILDINFO" ("SUBSCRIBED"))
S: C04 OK done

or even this:

C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
S: * LIST (\Subscribed \HasChildren) "/" "Foo" ("CHILDINFO"
   ("SUBSCRIBED"))
S: C04 OK done

A2) 🦄 now let's say "Foo" isn't part of the original hierarchy and isn't subscribed. The last command gives this result:

C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
S: * LIST (\NonExistent) "/" "Foo" ("CHILDINFO" ("SUBSCRIBED"))
S: C04 OK done

B) 🙅‍♀️ okay, next, suppose no mailbox is subscribed at all. Then <LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"> returns no responses, because there are no subscribed children (even though "Foo" still has children).

C) 💖 and finally, suppose only "Foo" and "Moo" are subscribed. Then we see this:

C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" RETURN (CHILDREN)
S: * LIST (\HasChildren \Subscribed) "/" "Foo"
S: * LIST (\HasNoChildren \Subscribed) "/" "Moo"
S: C04 OK done

(which means "Foo" has children, but none of them is subscribed) 🎀

Example 9 🌷 this one shows that the CHILDINFO extended data item comes back whether or not the children match the canonical LIST pattern. It's a whole mess of mailboxes, so buckle up 🎢

Let's assume there is the following hierarchy:

C: D01 LIST "" "*"
S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST () "/" "foo2"
S: * LIST () "/" "foo2/bar1"
S: * LIST () "/" "foo2/bar2"
S: * LIST () "/" "baz2"
S: * LIST () "/" "baz2/bar2"
S: * LIST () "/" "baz2/bar22"
S: * LIST () "/" "baz2/bar222"
S: * LIST () "/" "eps2"
S: * LIST () "/" "eps2/mamba"
S: * LIST () "/" "qux2/bar2"
S: D01 OK done

And the following mailboxes are subscribed:

C: D02 LIST (SUBSCRIBED) "" "*"
S: * LIST (\Subscribed) "/" "foo2/bar1"
S: * LIST (\Subscribed) "/" "foo2/bar2"
S: * LIST (\Subscribed) "/" "baz2/bar2"
S: * LIST (\Subscribed) "/" "baz2/bar22"
S: * LIST (\Subscribed) "/" "baz2/bar222"
S: * LIST (\Subscribed) "/" "eps2"
S: * LIST (\Subscribed) "/" "eps2/mamba"
S: * LIST (\Subscribed) "/" "qux2/bar2"
S: D02 OK done

The client issues this command first:

C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*2"
S: * LIST () "/" "foo2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\Subscribed) "/" "foo2/bar2"
S: * LIST (\Subscribed) "/" "baz2/bar2"
S: * LIST (\Subscribed) "/" "baz2/bar22"
S: * LIST (\Subscribed) "/" "baz2/bar222"
S: * LIST (\Subscribed) "/" "eps2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\Subscribed) "/" "qux2/bar2"
S: D03 OK done

and the server may also include these (but this would violate a SHOULD NOT in Section 3.5, because CHILDINFO is redundant):

S: * LIST () "/" "baz2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\NonExistent) "/" "qux2" ("CHILDINFO" ("SUBSCRIBED"))

The CHILDINFO extended data item shows up for "foo2", "baz2", and "eps2", because all of them have subscribed children. For "foo2", only one of the two subscribed children matches the pattern. For "baz2", all the subscribed children match. For "eps2", none of the subscribed children matches. Chaotic but valid 💅

Note that if the client issues this instead:

C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*"
S: * LIST () "/" "foo2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\Subscribed) "/" "foo2/bar1"
S: * LIST (\Subscribed) "/" "foo2/bar2"
S: * LIST () "/" "baz2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\Subscribed) "/" "baz2/bar2"
S: * LIST (\Subscribed) "/" "baz2/bar22"
S: * LIST (\Subscribed) "/" "baz2/bar222"
S: * LIST (\Subscribed) "/" "eps2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\Subscribed) "/" "eps2/mamba"
S: * LIST (\Subscribed) "/" "qux2/bar2"
S: D03 OK done

the LIST responses for "foo2", "baz2", and "eps2" still carry the CHILDINFO extended data item, even though that info is redundant and the client could figure it out on its own 🙃

Example 10 🍭 this one shows multiple mailbox patterns again, and it also proves that having CHILDINFO doesn't always mean \HasChildren. Ngl this is a little tricky, so read slowly 🤓

C: a1 LIST "" ("foo" "foo/*")
S: * LIST () "/" foo
S: a1 OK done

C: a2 LIST (SUBSCRIBED) "" "foo/*"
S: * LIST (\Subscribed \NonExistent) "/" foo/bar
S: a2 OK done

C: a3 LIST (SUBSCRIBED RECURSIVEMATCH) "" foo RETURN (CHILDREN)
S: * LIST (\HasNoChildren) "/" foo ("CHILDINFO" ("SUBSCRIBED"))
S: a3 OK done

Example 11 🧚‍♀️ last one! This shows how a server that supports missing mailbox hierarchy elements can tell a client that didn't ask for RECURSIVEMATCH that there's a child mailbox matching the selection criteria. Sneaky, but helpful 🌈

C: a1 LIST (REMOTE) "" *
S: * LIST () "/" music/rock
S: * LIST (\Remote) "/" also/jazz
S: a1 OK done

C: a2 LIST () "" %
S: * LIST (\NonExistent \HasChildren) "/" music
S: a2 OK done

C: a3 LIST (REMOTE) "" %
S: * LIST (\NonExistent \HasChildren) "/" music
S: * LIST (\NonExistent \HasChildren) "/" also
S: a3 OK done

C: a3.1 LIST "" (% music/rock)
S: * LIST () "/" music/rock
S: a3.1 OK done

Because "music/rock" is the only mailbox under "music", there's no need for the server to also return "music". However, clients must handle both cases. Both ways are valid, so keep your code flexible 💜

6. Formal Syntax ✨

okay so the syntax is written in ABNF (Augmented Backus-Naur Form) as described in [ABNF] 🎀. anything that isn't defined in here gets borrowed from [IMAP4]. the big plot twist is that the new version of "mailbox-list", the bit that carries the LIST response payload, updates the version in the IMAP spec 😭. it's pointed to by "mailbox-data", which lives in [IMAP4] 💅

"vendor-token" comes from [ACAP] 🦋. ngl this normative reference to ACAP is gonna be an issue when we try to move this spec forward, because it makes us depend on ACAP 💀. the definitions of "vendor-token" and the IANA registry need to end up somewhere else, in a doc that can move along the standards track on its own without ACAP 🫶

childinfo-extended-item =  "CHILDINFO" SP "("
            list-select-base-opt-quoted
            *(SP list-select-base-opt-quoted) ")"
            ; Extended data item (mbox-list-extended-item)
            ; returned when the RECURSIVEMATCH
            ; selection option is specified.
            ; Note 1: the CHILDINFO tag can be returned
            ; with and without surrounding quotes, as per
            ; mbox-list-extended-item-tag production.
            ; Note 2: The selection options are always returned
            ; quoted, unlike their specification in
            ; the extended LIST command.

child-mbox-flag =  "\HasChildren" / "\HasNoChildren"
            ; attributes for CHILDREN return option, at most one
            ; possible per LIST response

eitem-standard-tag =  atom
            ; a tag for extended list data defined in a Standard
            ; Track or Experimental RFC.

eitem-vendor-tag =  vendor-token "-" atom
            ; a vendor-specific tag for extended list data

list =      "LIST" [SP list-select-opts] SP mailbox SP mbox-or-pat
            [SP list-return-opts]

list-return-opts =  "RETURN" SP
            "(" [return-option *(SP return-option)] ")"
            ; list return options, e.g., CHILDREN

list-select-base-opt =  "SUBSCRIBED" / option-extension
            ; options that can be used by themselves

list-select-base-opt-quoted =  DQUOTE list-select-base-opt DQUOTE

list-select-independent-opt =  "REMOTE" / option-extension
            ; options that do not syntactically interact with
            ; other options

list-select-mod-opt =  "RECURSIVEMATCH" / option-extension
            ; options that require a list-select-base-opt
            ; to also be present

list-select-opt =  list-select-base-opt / list-select-independent-opt
            / list-select-mod-opt
            ; An option registration template is described in
            ; Section 9.3 of this document.

list-select-opts =  "(" [
              (*(list-select-opt SP) list-select-base-opt
               *(SP list-select-opt))
            / (list-select-independent-opt
               *(SP list-select-independent-opt))
            ] ")"
            ; Any number of options may be in any order.
            ; If a list-select-mod-opt appears, then a
            ; list-select-base-opt must also appear.
            ; This allows these:
            ; ()
            ; (REMOTE)
            ; (SUBSCRIBED)
            ; (SUBSCRIBED REMOTE)
            ; (SUBSCRIBED RECURSIVEMATCH)
            ; (SUBSCRIBED REMOTE RECURSIVEMATCH)
            ; But does NOT allow these:
            ; (RECURSIVEMATCH)
            ; (REMOTE RECURSIVEMATCH)

mailbox-list =  "(" [mbx-list-flags] ")" SP
            (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox
            [SP mbox-list-extended]
            ; This is the list information pointed to by the ABNF
            ; item "mailbox-data", which is defined in [IMAP4]

mbox-list-extended =  "(" [mbox-list-extended-item
            *(SP mbox-list-extended-item)] ")"

mbox-list-extended-item =  mbox-list-extended-item-tag SP
            tagged-ext-val

mbox-list-extended-item-tag =  astring
            ; The content MUST conform to either "eitem-vendor-tag"
            ; or "eitem-standard-tag" ABNF productions.
            ; A tag registration template is described in this
            ; document in Section 9.5.

mbx-list-oflag =/  child-mbox-flag / "\Subscribed" / "\Remote"

mbx-list-sflag =/  "\NonExistent"

mbox-or-pat =  list-mailbox / patterns

option-extension =  (option-standard-tag / option-vendor-tag)
            [SP option-value]

option-standard-tag =  atom
            ; an option defined in a Standards Track or
            ; Experimental RFC

option-val-comp =  astring /
            option-val-comp *(SP option-val-comp) /
            "(" option-val-comp ")"

option-value =  "(" option-val-comp ")"

option-vendor-tag =  vendor-token "-" atom
            ; a vendor-specific option, non-standard

patterns =  "(" list-mailbox *(SP list-mailbox) ")"

return-option =  "SUBSCRIBED" / "CHILDREN" / option-extension

tagged-ext-comp =  astring /
            tagged-ext-comp *(SP tagged-ext-comp) /
            "(" tagged-ext-comp ")"
            ; Extensions that follow this general
            ; syntax should use nstring instead of
            ; astring when appropriate in the context
            ; of the extension.
            ; Note that a message set or a "number"
            ; can always be represented as an "atom".
            ; A URL should be represented as
            ; a "quoted" string.

tagged-ext-simple =  sequence-set / number

tagged-ext-val =  tagged-ext-simple /
            "(" [tagged-ext-comp] ")"

7. Internationalization Considerations 🌈

the LIST command selection option types in this spec are simple tests of mailbox properties 🍓. future LIST-EXTENDED extensions might define selection options that do more fancy, sophisticated tests, though. when a test needs matching text and the COMPARATOR [I18N] extension is in the picture, the active comparator must be used to do the comparisons. and any LIST-EXTENDED extension like that MUST indicate in its spec how it interacts with the COMPARATOR [I18N] extension 🫶

8. Security Considerations 🔥

this part is serious, bestie 😭. this document describes syntactic changes to the IMAP4 commands LIST, LSUB, RLIST, and RLSUB, and the modified LIST command has the same security considerations as those commands. they're described in [IMAP4] and [MBRef] 💜

the Child Mailbox Extension gives a client a more efficient way to figure out whether a particular mailbox has children 🧚. but if a mailbox has children and the currently authenticated user doesn't have access to any of them, the server SHOULD respond with a \HasNoChildren attribute 🙈. in lots of cases though, a server can't efficiently work out whether a user has access to any child mailbox. if that server responds with \HasChildren when the user actually can't access any child mailboxes, potentially more info about the mailbox gets conveyed than was intended 💀

In most situations this won't be a security concern, because if info about whether a mailbox has children is sensitive, a user wouldn't be granted access to that mailbox in the first place. 🦋

the CHILDINFO extended data item has the same security considerations as the \HasChildren attribute we just talked about 👑

9. IANA Considerations 🌸

9.1. Guidelines for IANA

IANA has created two new registries, one for LIST-EXTENDED options and one for LIST-EXTENDED response data 🎀. the templates and the initial registrations are detailed below ✨

9.2. Registration Procedure and Change Control

okay the rules for registering stuff 📋. registering a LIST-EXTENDED option means filling in the template in Section 9.3 and emailing it to iana@iana.org. registering a LIST-EXTENDED extended data item means filling in the template in Section 9.5 and emailing it to iana@iana.org too. IANA has the right to reject obviously bogus registrations, but it won't review any claims made in the registration form 💅

a LIST-EXTENDED option or extended data item name that starts with "V-" is reserved for vendor-specific ones 🌈. all options, whether vendor specific or global, should be registered with IANA. if a LIST-EXTENDED extended data item gets returned because someone asked for a particular LIST-EXTENDED option, the name of the option SHOULD be used as the name of that extended data item 🦋. each vendor-specific option or extended data item MUST start with its vendor-token ("vendor prefix") 🫶. the vendor-token MUST be registered with IANA, using the [ACAP] vendor subtree registry 💜

standard LIST-EXTENDED option and extended data item names are case insensitive 🍓. if the vendor prefix is left off a vendor-specific name, the rest is case insensitive too. the vendor prefix itself isn't case sensitive, since it might contain non-ASCII characters 🌸. even though the registration procedures don't require it, authors are encouraged to get community review and comment whenever that's doable ✨. authors can seek community review by posting a spec of their proposed mechanism as an Internet-Draft 🧚. LIST-EXTENDED options and extended data items meant for widespread use should be standardized through the normal IETF process, when that's appropriate 👑

comments on registered LIST-EXTENDED options or extended response data should first be sent to the "owner" of the mechanism and/or to the IMAPEXT WG mailing list 💌. commenters can, after a reasonable attempt to contact the owner, ask IANA to attach their comment to the registration itself. if IANA approves, the comment will be accessible alongside the registration itself 🌈

once a LIST-EXTENDED registration has been published by IANA, the author can request a change to its definition. the change request follows the same procedure as the registration request 🔁

the owner of a LIST-EXTENDED registration can pass responsibility for the registered option or extended data item to another person or agency by informing IANA. this can be done without discussion or review 🫶

the IESG may reassign responsibility for a LIST-EXTENDED option or extended data item. the most common case will be enabling changes to mechanisms where the registration's author has died, moved out of contact, or is otherwise unable to make changes that matter to the community 😭

LIST-EXTENDED registrations may not be deleted. mechanisms that are no longer believed appropriate for use can be declared OBSOLETE by a change to their "intended use" field 🪦. those LIST-EXTENDED options and extended data items will be clearly marked in the lists IANA publishes 📣

the IESG is considered to be the owner of all LIST-EXTENDED options and extended data items that are on the IETF standards track 👑

9.3. Registration Template for LIST-EXTENDED Options 💅

Okay so, if you ever want to add a brand new LIST-EXTENDED option, IANA wants this exact template filled out. No skipping fields, bestie 📝

To: iana@iana.org
Subject: Registration of LIST-EXTENDED option X

LIST-EXTENDED option name:

LIST-EXTENDED option type: (One of SELECTION or RETURN)

Implied return options(s), if the option type is SELECTION: (zero or
more)

LIST-EXTENDED option description:

Published specification (optional, recommended):

Security considerations:

Intended usage:
(One of COMMON, LIMITED USE, or OBSOLETE)

Person and email address to contact for further information:

Owner/Change controller:

(Any other information that the author deems interesting may be added
below this line.)

9.4. Initial LIST-EXTENDED Option Registrations 🌸

Okay, the LIST-EXTENDED option registry comes pre-loaded with these five entries, so you'll see them all right here ✨

1.  To: iana@iana.org
    Subject: Registration of LIST-EXTENDED option SUBSCRIBED

    LIST-EXTENDED option name: SUBSCRIBED

    LIST-EXTENDED option type: SELECTION

    Implied return options(s): SUBSCRIBED

    LIST-EXTENDED option description: Causes the LIST command to list
    subscribed mailboxes, rather than the actual mailboxes.

    Published specification: RFC 5258, Section 3.

    Security considerations: RFC 5258, Section 8.

    Intended usage: COMMON

    Person and email address to contact for further information:
    Alexey Melnikov <Alexey.Melnikov@isode.com>

    Owner/Change controller: iesg@ietf.org

2.  To: iana@iana.org
    Subject: Registration of LIST-EXTENDED option REMOTE

    LIST-EXTENDED option name: REMOTE

    LIST-EXTENDED option type: SELECTION

    Implied return options(s): (none)

    LIST-EXTENDED option description: Causes the LIST command to
    return remote mailboxes as well as local ones, as described in
    RFC 2193.

    Published specification: RFC 5258, Section 3.

    Security considerations: RFC 5258, Section 8.

    Intended usage: COMMON

    Person and email address to contact for further information:
    Alexey Melnikov <Alexey.Melnikov@isode.com>

    Owner/Change controller: iesg@ietf.org

3.  To: iana@iana.org
    Subject: Registration of LIST-EXTENDED option SUBSCRIBED

    LIST-EXTENDED option name: SUBSCRIBED

    LIST-EXTENDED option type: RETURN

    LIST-EXTENDED option description: Causes the LIST command to
    return subscription state.

    Published specification: RFC 5258, Section 3.

    Security considerations: RFC 5258, Section 8.

    Intended usage: COMMON

    Person and email address to contact for further information:
    Alexey Melnikov <Alexey.Melnikov@isode.com>

    Owner/Change controller: iesg@ietf.org

4.  To: iana@iana.org
    Subject: Registration of LIST-EXTENDED option RECURSIVEMATCH

    LIST-EXTENDED option name: RECURSIVEMATCH

    LIST-EXTENDED option type: SELECTION

    Implied return options(s): (none)

    LIST-EXTENDED option description: Requests that CHILDINFO
    extended data item (childinfo-extended-item) is to be returned.

    Published specification: RFC 5258, Section 3.

    Security considerations: RFC 5258, Section 8.

    Intended usage: COMMON

    Person and email address to contact for further information:
    Alexey Melnikov <Alexey.Melnikov@isode.com>

    Owner/Change controller: iesg@ietf.org

5.  To: iana@iana.org
    Subject: Registration of LIST-EXTENDED option CHILDREN

    LIST-EXTENDED option name: CHILDREN

    LIST-EXTENDED option type: RETURN

    LIST-EXTENDED option description: Requests mailbox child
    information.

    Published specification: RFC 5258, Section 3 and Section 4.

    Security considerations: RFC 5258, Section 8.

    Intended usage: COMMON

    Person and email address to contact for further information:
    Alexey Melnikov <Alexey.Melnikov@isode.com>
    Owner/Change controller: iesg@ietf.org

9.5. Registration Template for LIST-EXTENDED Extended Data Item ✨

Next up is the template for the extended data items. Same energy, different target 🦋

To: iana@iana.org
Subject: Registration of X LIST-EXTENDED extended data item

LIST-EXTENDED extended data item tag:

LIST-EXTENDED extended data item description:

Which LIST-EXTENDED option(s) (and their types) causes this extended
data item to be returned (if any):

Published specification (optional, recommended):

Security considerations:

Intended usage:
(One of COMMON, LIMITED USE, or OBSOLETE)

Person and email address to contact for further information:

Owner/Change controller:

(Any other information that the author deems interesting may be added
below this line.)

9.6. Initial LIST-EXTENDED Extended Data Item Registrations 🍓

The LIST-EXTENDED extended data item registry starts off with just one entry, and it's a main character: CHILDINFO 👑

1.  To: iana@iana.org
    Subject: Registration of CHILDINFO LIST-EXTENDED extended data
    item

    LIST-EXTENDED extended data item tag: CHILDINFO

    LIST-EXTENDED extended data item description: The CHILDINFO
    extended data item describes the selection criteria that has
    caused it to be returned and indicates that the mailbox has one
    or more child mailboxes that match the selection criteria.

    Which LIST-EXTENDED option(s) (and their types) causes this
    extended data item to be returned (if any): RECURSIVEMATCH
    selection option
    Published specification: RFC 5258, Section 3.5.

    Security considerations: RFC 5258, Section 8.

    Intended usage: COMMON

    Person and email address to contact for further information:
    Alexey Melnikov <Alexey.Melnikov@isode.com>

    Owner/Change controller: iesg@ietf.org

10. Acknowledgements 🫶

Okay, big thank-yous time 💖 Mike Gahrns and Raymond Cheng from Microsoft Corporation came up with the Child Mailbox Extension and pitched it back in 1997. The whole idea is theirs, and so is most of the text in Section 4 ✨

This document came out of discussions on the IMAP4 and IMAPEXT mailing lists, and it's meant to reflect what those groups agreed on 🌈 Mark Crispin, Philip Guenther, Cyrus Daboo, Timo Sirainen, Ken Murchison, Rob Siemborski, Steve Hole, Arnt Gulbrandsen, Larry Greenfield, Dave Cridland, and Pete Maclean were all active in those talks or gave suggestions for this document. Iconic squad 👑

11. References 📚

11.1. Normative References

[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[I18N] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet Message Access Protocol Internationalization", RFC 5255, June 2008.
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, March 2003.
[Kwds] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[MBRef] Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193, September 1997.

11.2. Informative References

[CMbox] Gahrns, M. and R. Cheng, "The Internet Message Action Protocol (IMAP4) Child Mailbox Extension", RFC 3348, July 2002.

Authors' Addresses 🎀

Here's where you can find the authors. Barry Leiba and Alexey Melnikov, both legends 🦋

Barry Leiba
IBM T.J. Watson Research Center
19 Skyline Drive
Hawthorne, NY  10532
US

Phone: +1 914 784 7941
EMail: leiba@watson.ibm.com


Alexey Melnikov
Isode Limited
5 Castle Business Village
36 Station Road
Hampton, Middlesex  TW12 2BX
UK

EMail: Alexey.Melnikov@isode.com
URI:   http://www.melnikov.ca/

Full Copyright Statement ⭐

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🌸

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

📦 where this page comes from

ietf: rfc5258 2008-06
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms