< draft-ietf-extra-imap4rev2-04.txt   draft-ietf-extra-imap4rev2-05.txt >
Network Working Group A. Melnikov, Ed. Network Working Group A. Melnikov, Ed.
Internet-Draft Isode Ltd Internet-Draft Isode Ltd
Obsoletes: 3501 (if approved) B. Leiba, Ed. Obsoletes: 3501 (if approved) B. Leiba, Ed.
Intended status: Standards Track Huawei Technologies Intended status: Standards Track Huawei Technologies
Expires: September 10, 2019 March 9, 2019 Expires: January 10, 2020 July 9, 2019
INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev2 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev2
draft-ietf-extra-imap4rev2-04 draft-ietf-extra-imap4rev2-05
Abstract Abstract
The Internet Message Access Protocol, Version 4rev2 (IMAP4rev2) The Internet Message Access Protocol, Version 4rev2 (IMAP4rev2)
allows a client to access and manipulate electronic mail messages on allows a client to access and manipulate electronic mail messages on
a server. IMAP4rev2 permits manipulation of mailboxes (remote a server. IMAP4rev2 permits manipulation of mailboxes (remote
message folders) in a way that is functionally equivalent to local message folders) in a way that is functionally equivalent to local
folders. IMAP4rev2 also provides the capability for an offline folders. IMAP4rev2 also provides the capability for an offline
client to resynchronize with the server. client to resynchronize with the server.
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2019. This Internet-Draft will expire on January 10, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 42 skipping to change at page 3, line 42
6.3. Client Commands - Authenticated State . . . . . . . . . . 31 6.3. Client Commands - Authenticated State . . . . . . . . . . 31
6.3.1. ENABLE Command . . . . . . . . . . . . . . . . . . . 31 6.3.1. ENABLE Command . . . . . . . . . . . . . . . . . . . 31
6.3.2. SELECT Command . . . . . . . . . . . . . . . . . . . 33 6.3.2. SELECT Command . . . . . . . . . . . . . . . . . . . 33
6.3.3. EXAMINE Command . . . . . . . . . . . . . . . . . . . 35 6.3.3. EXAMINE Command . . . . . . . . . . . . . . . . . . . 35
6.3.4. CREATE Command . . . . . . . . . . . . . . . . . . . 35 6.3.4. CREATE Command . . . . . . . . . . . . . . . . . . . 35
6.3.5. DELETE Command . . . . . . . . . . . . . . . . . . . 36 6.3.5. DELETE Command . . . . . . . . . . . . . . . . . . . 36
6.3.6. RENAME Command . . . . . . . . . . . . . . . . . . . 38 6.3.6. RENAME Command . . . . . . . . . . . . . . . . . . . 38
6.3.7. SUBSCRIBE Command . . . . . . . . . . . . . . . . . . 40 6.3.7. SUBSCRIBE Command . . . . . . . . . . . . . . . . . . 40
6.3.8. UNSUBSCRIBE Command . . . . . . . . . . . . . . . . . 41 6.3.8. UNSUBSCRIBE Command . . . . . . . . . . . . . . . . . 41
6.3.9. LIST Command . . . . . . . . . . . . . . . . . . . . 41 6.3.9. LIST Command . . . . . . . . . . . . . . . . . . . . 41
6.3.10. LSUB Command . . . . . . . . . . . . . . . . . . . . 44 6.3.10. LSUB Command . . . . . . . . . . . . . . . . . . . . 58
6.3.11. NAMESPACE Command . . . . . . . . . . . . . . . . . . 45 6.3.11. NAMESPACE Command . . . . . . . . . . . . . . . . . . 59
6.3.12. STATUS Command . . . . . . . . . . . . . . . . . . . 49 6.3.12. STATUS Command . . . . . . . . . . . . . . . . . . . 63
6.3.13. APPEND Command . . . . . . . . . . . . . . . . . . . 51 6.3.13. APPEND Command . . . . . . . . . . . . . . . . . . . 65
6.3.14. IDLE Command . . . . . . . . . . . . . . . . . . . . 53 6.3.14. IDLE Command . . . . . . . . . . . . . . . . . . . . 67
6.4. Client Commands - Selected State . . . . . . . . . . . . 55 6.4. Client Commands - Selected State . . . . . . . . . . . . 69
6.4.1. CHECK Command . . . . . . . . . . . . . . . . . . . . 56 6.4.1. CHECK Command . . . . . . . . . . . . . . . . . . . . 70
6.4.2. CLOSE Command . . . . . . . . . . . . . . . . . . . . 56 6.4.2. CLOSE Command . . . . . . . . . . . . . . . . . . . . 70
6.4.3. UNSELECT Command . . . . . . . . . . . . . . . . . . 57 6.4.3. UNSELECT Command . . . . . . . . . . . . . . . . . . 71
6.4.4. EXPUNGE Command . . . . . . . . . . . . . . . . . . . 57 6.4.4. EXPUNGE Command . . . . . . . . . . . . . . . . . . . 71
6.4.5. SEARCH Command . . . . . . . . . . . . . . . . . . . 58 6.4.5. SEARCH Command . . . . . . . . . . . . . . . . . . . 72
6.4.6. FETCH Command . . . . . . . . . . . . . . . . . . . . 63 6.4.6. FETCH Command . . . . . . . . . . . . . . . . . . . . 77
6.4.7. STORE Command . . . . . . . . . . . . . . . . . . . . 67 6.4.7. STORE Command . . . . . . . . . . . . . . . . . . . . 81
6.4.8. COPY Command . . . . . . . . . . . . . . . . . . . . 68 6.4.8. COPY Command . . . . . . . . . . . . . . . . . . . . 82
6.4.9. MOVE Command . . . . . . . . . . . . . . . . . . . . 69 6.4.9. MOVE Command . . . . . . . . . . . . . . . . . . . . 83
6.4.10. UID Command . . . . . . . . . . . . . . . . . . . . . 71 6.4.10. UID Command . . . . . . . . . . . . . . . . . . . . . 85
6.5. Client Commands - Experimental/Expansion . . . . . . . . 73 6.5. Client Commands - Experimental/Expansion . . . . . . . . 87
6.5.1. X<atom> Command . . . . . . . . . . . . . . . . . . . 73 6.5.1. X<atom> Command . . . . . . . . . . . . . . . . . . . 87
7. Server Responses . . . . . . . . . . . . . . . . . . . . . . 74 7. Server Responses . . . . . . . . . . . . . . . . . . . . . . 88
7.1. Server Responses - Status Responses . . . . . . . . . . . 75 7.1. Server Responses - Status Responses . . . . . . . . . . . 89
7.1.1. OK Response . . . . . . . . . . . . . . . . . . . . . 82 7.1.1. OK Response . . . . . . . . . . . . . . . . . . . . . 96
7.1.2. NO Response . . . . . . . . . . . . . . . . . . . . . 82 7.1.2. NO Response . . . . . . . . . . . . . . . . . . . . . 96
7.1.3. BAD Response . . . . . . . . . . . . . . . . . . . . 83 7.1.3. BAD Response . . . . . . . . . . . . . . . . . . . . 97
7.1.4. PREAUTH Response . . . . . . . . . . . . . . . . . . 83 7.1.4. PREAUTH Response . . . . . . . . . . . . . . . . . . 97
7.1.5. BYE Response . . . . . . . . . . . . . . . . . . . . 83 7.1.5. BYE Response . . . . . . . . . . . . . . . . . . . . 97
7.2. Server Responses - Server and Mailbox Status . . . . . . 84 7.2. Server Responses - Server and Mailbox Status . . . . . . 98
7.2.1. The ENABLED Response . . . . . . . . . . . . . . . . 84 7.2.1. The ENABLED Response . . . . . . . . . . . . . . . . 98
7.2.2. CAPABILITY Response . . . . . . . . . . . . . . . . . 84 7.2.2. CAPABILITY Response . . . . . . . . . . . . . . . . . 98
7.2.3. LIST Response . . . . . . . . . . . . . . . . . . . . 85 7.2.3. LIST Response . . . . . . . . . . . . . . . . . . . . 99
7.2.4. LSUB Response . . . . . . . . . . . . . . . . . . . . 88 7.2.4. LSUB Response . . . . . . . . . . . . . . . . . . . . 102
7.2.5. NAMESPACE Response . . . . . . . . . . . . . . . . . 89 7.2.5. NAMESPACE Response . . . . . . . . . . . . . . . . . 103
7.2.6. STATUS Response . . . . . . . . . . . . . . . . . . . 89 7.2.6. STATUS Response . . . . . . . . . . . . . . . . . . . 103
7.2.7. ESEARCH Response . . . . . . . . . . . . . . . . . . 89 7.2.7. ESEARCH Response . . . . . . . . . . . . . . . . . . 103
7.2.8. FLAGS Response . . . . . . . . . . . . . . . . . . . 90 7.2.8. FLAGS Response . . . . . . . . . . . . . . . . . . . 104
7.3. Server Responses - Mailbox Size . . . . . . . . . . . . . 90 7.3. Server Responses - Mailbox Size . . . . . . . . . . . . . 104
7.3.1. EXISTS Response . . . . . . . . . . . . . . . . . . . 90 7.3.1. EXISTS Response . . . . . . . . . . . . . . . . . . . 104
7.4. Server Responses - Message Status . . . . . . . . . . . . 90 7.4. Server Responses - Message Status . . . . . . . . . . . . 104
7.4.1. EXPUNGE Response . . . . . . . . . . . . . . . . . . 91 7.4.1. EXPUNGE Response . . . . . . . . . . . . . . . . . . 105
7.4.2. FETCH Response . . . . . . . . . . . . . . . . . . . 91 7.4.2. FETCH Response . . . . . . . . . . . . . . . . . . . 105
7.5. Server Responses - Command Continuation Request . . . . . 97 7.5. Server Responses - Command Continuation Request . . . . . 111
8. Sample IMAP4rev2 connection . . . . . . . . . . . . . . . . . 98 8. Sample IMAP4rev2 connection . . . . . . . . . . . . . . . . . 112
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 99 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 113
10. Author's Note . . . . . . . . . . . . . . . . . . . . . . . . 114 10. Author's Note . . . . . . . . . . . . . . . . . . . . . . . . 128
11. Security Considerations . . . . . . . . . . . . . . . . . . . 114 11. Security Considerations . . . . . . . . . . . . . . . . . . . 128
11.1. STARTTLS Security Considerations . . . . . . . . . . . . 114 11.1. STARTTLS Security Considerations . . . . . . . . . . . . 128
11.2. COPYUID and APPENDUID response codes . . . . . . . . . . 115 11.2. COPYUID and APPENDUID response codes . . . . . . . . . . 129
11.3. Other Security Considerations . . . . . . . . . . . . . 115 11.3. Other Security Considerations . . . . . . . . . . . . . 129
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 116 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 130
12.1. Updates to IMAP4 Capabilities registry . . . . . . . . . 116 12.1. Updates to IMAP4 Capabilities registry . . . . . . . . . 130
12.2. GSSAPI/SASL service name . . . . . . . . . . . . . . . . 116 12.2. GSSAPI/SASL service name . . . . . . . . . . . . . . . . 130
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 116 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 130
13.1. Normative References . . . . . . . . . . . . . . . . . . 116 13.1. Normative References . . . . . . . . . . . . . . . . . . 130
13.2. Informative References (related protocols) . . . . . . . 119 13.2. Informative References (related protocols) . . . . . . . 133
13.3. Informative References (historical aspects of IMAP and 13.3. Informative References (historical aspects of IMAP and
related protocols) . . . . . . . . . . . . . . . . . . . 120 related protocols) . . . . . . . . . . . . . . . . . . . 135
Appendix A. Backward compatibility with IMAP4rev1 . . . . . . . 121 Appendix A. Backward compatibility with IMAP4rev1 . . . . . . . 135
A.1. Mailbox International Naming Convention . . . . . . . . . 121 A.1. Mailbox International Naming Convention . . . . . . . . . 136
Appendix B. Backward compatibility with BINARY extension . . . . 123 Appendix B. Backward compatibility with BINARY extension . . . . 137
Appendix C. Changes from RFC 3501 / IMAP4rev1 . . . . . . . . . 123 Appendix C. Changes from RFC 3501 / IMAP4rev1 . . . . . . . . . 138
Appendix D. Acknowledgement . . . . . . . . . . . . . . . . . . 125 Appendix D. Acknowledgement . . . . . . . . . . . . . . . . . . 139
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 130 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 145
1. How to Read This Document 1. How to Read This Document
1.1. Organization of This Document 1.1. Organization of This Document
This document is written from the point of view of the implementor of This document is written from the point of view of the implementor of
an IMAP4rev2 client or server. Beyond the protocol overview in an IMAP4rev2 client or server. Beyond the protocol overview in
section 2, it is not optimized for someone trying to understand the section 2, it is not optimized for someone trying to understand the
operation of the protocol. The material in sections 3 through 5 operation of the protocol. The material in sections 3 through 5
provides the general context and definitions with which IMAP4rev2 provides the general context and definitions with which IMAP4rev2
skipping to change at page 5, line 35 skipping to change at page 5, line 35
1.2. Conventions Used in This Document 1.2. Conventions Used in This Document
"Conventions" are basic principles or procedures. Document "Conventions" are basic principles or procedures. Document
conventions are noted in this section. conventions are noted in this section.
In examples, "C:" and "S:" indicate lines sent by the client and In examples, "C:" and "S:" indicate lines sent by the client and
server respectively. server respectively.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [KEYWORDS]. "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.
The word "can" (not "may") is used to refer to a possible The word "can" (not "may") is used to refer to a possible
circumstance or situation, as opposed to an optional facility of the circumstance or situation, as opposed to an optional facility of the
protocol. protocol.
"User" is used to refer to a human user, whereas "client" refers to "User" is used to refer to a human user, whereas "client" refers to
the software being run by the user. the software being run by the user.
"Connection" refers to the entire sequence of client/server "Connection" refers to the entire sequence of client/server
interaction from the initial establishment of the network connection interaction from the initial establishment of the network connection
skipping to change at page 41, line 33 skipping to change at page 41, line 33
The UNSUBSCRIBE command removes the specified mailbox name from the The UNSUBSCRIBE command removes the specified mailbox name from the
server's set of "active" or "subscribed" mailboxes as returned by the server's set of "active" or "subscribed" mailboxes as returned by the
LSUB command. This command returns a tagged OK response only if the LSUB command. This command returns a tagged OK response only if the
unsubscription is successful. unsubscription is successful.
Example: C: A002 UNSUBSCRIBE #news.comp.mail.mime Example: C: A002 UNSUBSCRIBE #news.comp.mail.mime
S: A002 OK UNSUBSCRIBE completed S: A002 OK UNSUBSCRIBE completed
6.3.9. LIST Command 6.3.9. LIST Command
Arguments: reference name Arguments (basic): reference name
mailbox name with possible wildcards mailbox name with possible wildcards
Arguments (extended): selection options (OPTIONAL)
reference name
mailbox patterns
return options (OPTIONAL)
Responses: untagged responses: LIST Responses: untagged responses: LIST
Result: OK - list completed Result: OK - list completed
NO - list failure: can't list that reference or name NO - list failure: can't list that reference or name
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
THIS VERSION HAS ONLY AN INITIAL PASS AT ADDING THE EXTENDED LIST
SYNTAX AND OPTIONS. THERE'S STILL A GOOD DEAL OR WORK TO DO ON IT,
AND THE ABNF IS NOT THERE YET.
The LIST command returns a subset of names from the complete set of The LIST command returns a subset of names from the complete set of
all names available to the client. Zero or more untagged LIST all names available to the client. Zero or more untagged LIST
replies are returned, containing the name attributes, hierarchy replies are returned, containing the name attributes, hierarchy
delimiter, and name; see the description of the LIST reply for more delimiter, and name; see the description of the LIST reply for more
detail. detail.
The LIST command SHOULD return its data quickly, without undue delay. The LIST command SHOULD return its data quickly, without undue delay.
For example, it SHOULD NOT go to excess trouble to calculate the For example, it SHOULD NOT go to excess trouble to calculate the
\Marked or \Unmarked status or perform other processing; if each name \Marked or \Unmarked status or perform other processing; if each name
requires 1 second of processing, then a list of 1200 names would take requires 1 second of processing, then a list of 1200 names would take
20 minutes! 20 minutes!
The extended LIST command, introduced in [RFC5258] provides
capabilities beyond that of the original IMAP LIST command. The
extended syntax is being used if one of the following conditions is
true:
1. if the first word after the command name begins with a
parenthesis ("LIST selection options")
2. if the second word after the command name begins with a
parenthesis ("multiple mailbox patterns")
3. if the LIST command has more than 2 parameters ("LIST return
options")
An empty ("" string) reference name argument indicates that the An empty ("" string) reference name argument indicates that the
mailbox name is interpreted as by SELECT. The returned mailbox names mailbox name is interpreted as by SELECT. The returned mailbox names
MUST match the supplied mailbox name pattern. A non-empty reference MUST match the supplied mailbox name pattern(s). A non-empty
name argument is the name of a mailbox or a level of mailbox reference name argument is the name of a mailbox or a level of
hierarchy, and indicates the context in which the mailbox name is mailbox hierarchy, and indicates the context in which the mailbox
interpreted. name is interpreted.
An empty ("" string) mailbox name argument is a special request to In the basic syntax only, an empty ("" string) mailbox name argument
return the hierarchy delimiter and the root name of the name given in is a special request to return the hierarchy delimiter and the root
the reference. The value returned as the root MAY be the empty name of the name given in the reference. The value returned as the
string if the reference is non-rooted or is an empty string. In all root MAY be the empty string if the reference is non-rooted or is an
cases, a hierarchy delimiter (or NIL if there is no hierarchy) is empty string. In all cases, a hierarchy delimiter (or NIL if there
returned. This permits a client to get the hierarchy delimiter (or is no hierarchy) is returned. This permits a client to get the
find out that the mailbox names are flat) even when no mailboxes by hierarchy delimiter (or find out that the mailbox names are flat)
that name currently exist. even when no mailboxes by that name currently exist.
In the extended syntax, any mailbox name arguments that are empty
strings are ignored. There is no special meaning for empty mailbox
names when the extended syntax is used.
The reference and mailbox name arguments are interpreted into a The reference and mailbox name arguments are interpreted into a
canonical form that represents an unambiguous left-to-right canonical form that represents an unambiguous left-to-right
hierarchy. The returned mailbox names will be in the interpreted hierarchy. The returned mailbox names will be in the interpreted
form. form.
Note: The interpretation of the reference argument is Note: The interpretation of the reference argument is
implementation-defined. It depends upon whether the server implementation-defined. It depends upon whether the server
implementation has a concept of the "current working directory" implementation has a concept of the "current working directory"
and leading "break out characters", which override the current and leading "break out characters", which override the current
skipping to change at page 43, line 45 skipping to change at page 44, line 33
The character "*" is a wildcard, and matches zero or more characters The character "*" is a wildcard, and matches zero or more characters
at this position. The character "%" is similar to "*", but it does at this position. The character "%" is similar to "*", but it does
not match a hierarchy delimiter. If the "%" wildcard is the last not match a hierarchy delimiter. If the "%" wildcard is the last
character of a mailbox name argument, matching levels of hierarchy character of a mailbox name argument, matching levels of hierarchy
are also returned. If these levels of hierarchy are not also are also returned. If these levels of hierarchy are not also
selectable mailboxes, they are returned with the \Noselect mailbox selectable mailboxes, they are returned with the \Noselect mailbox
name attribute (see the description of the LIST response for more name attribute (see the description of the LIST response for more
details). details).
If multiple mailbox patterns are used (in the extended syntax), a
mailbox matches if it matches at least one mailbox pattern. If a
mailbox matches more than one pattern, it is still only returned
once. Any syntactically valid pattern that is not accepted by a
server for any reason MUST be silently ignored.
Selection options tell the server to limit the mailbox names that are
selected by the LIST operation. If selection options are used, the
mailboxes returned are those that match both the list of mailbox
patterns and the selection options. Unless a particular selection
option provides special rules, the selection options are cumulative:
a mailbox that matches the mailbox patterns is selected only if it
also matches all of the selection options. (An example of a
selection option with special rules is the RECURSIVEMATCH option.)
Return options control what information is returned for each matched
mailbox. Return options MUST NOT cause the server to report
information about additional mailbox names other than those that
match the patterns and selection options. If no return options are
specified, the client is only expecting information about mailbox
attributes. The server MAY return other information about the
matched mailboxes, and clients MUST be able to handle that situation.
Initial selection options and return options are defined in the
following subsections, and new ones will also be defined in
extensions. Initial options MUST be supported. Each non-initial
option will be enabled by a capability string (one capability may
enable multiple options), and a client MUST NOT send an option for
which the server has not advertised support. A server MUST respond
to options it does not recognize with a BAD response. The client
SHOULD NOT specify any option more than once; however, if the client
does this, the server MUST act as if it received the option only
once. The order in which options are specified by the client is not
significant.
In general, each selection option except RECURSIVEMATCH will have a
corresponding return option. The REMOTE selection option is an
anomaly in this regard, and does not have a corresponding return
option. That is because it expands, rather than restricts, the set
of mailboxes that are returned. Future extensions to this
specification should keep parallelism in mind and define a pair of
corresponding options.
Server implementations are permitted to "hide" otherwise accessible Server implementations are permitted to "hide" otherwise accessible
mailboxes from the wildcard characters, by preventing certain mailboxes from the wildcard characters, by preventing certain
characters or names from matching a wildcard in certain situations. characters or names from matching a wildcard in certain situations.
For example, a UNIX-based server might restrict the interpretation of For example, a UNIX-based server might restrict the interpretation of
"*" so that an initial "/" character does not match. "*" so that an initial "/" character does not match.
The special name INBOX is included in the output from LIST, if INBOX The special name INBOX is included in the output from LIST, if INBOX
is supported by this server for this user and if the uppercase string is supported by this server for this user and if the uppercase string
"INBOX" matches the interpreted reference and mailbox name arguments "INBOX" matches the interpreted reference and mailbox name arguments
with wildcards as described above. The criteria for omitting INBOX with wildcards as described above. The criteria for omitting INBOX
is whether SELECT INBOX will return failure; it is not relevant is whether SELECT INBOX will return failure; it is not relevant
whether the user's real INBOX resides on this or some other server. whether the user's real INBOX resides on this or some other server.
6.3.9.1. LIST 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. Of particular note are
the mailbox attributes as returned by this option, compared with
what is returned by LSUB. With the latter, 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 that 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 [RFC2193]. 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 that 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 other selection options,
but have some submailboxes that do. Information about children is
returned in the CHILDINFO extended data item, as described in
Section 6.3.9.5.
Note 1: In order 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 6.3.9.6.
The RECURSIVEMATCH option MUST NOT occur as the only selection
option (or only with REMOTE), as it only makes sense when other
selection options are also used. The server MUST return BAD
tagged response in such case.
Note that even if the RECURSIVEMATCH option is specified, the
client MUST still be able to handle a case when a CHILDINFO
extended data item is returned and there are no submailboxes that
meet the selection criteria of the subsequent LIST command, as
they can be deleted/renamed after the LIST response was sent, but
before the client had a chance to access them.
6.3.9.2. LIST 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 the behavior of the LSUB
command).
CHILDREN - requests mailbox child information as originally proposed
in [RFC3348]. See Section 6.3.9.4, below, for details. This
option MUST be supported by all servers.
6.3.9.3. General Principles for Returning LIST Responses
This section outlines several principles that can be used by server
implementations of this document to decide whether a LIST response
should be returned, as well as how many responses and what kind of
information they may contain.
1. 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.
2. 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 such
responses 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 this case, see the CHILDINFO extended
data item described in Section 6.3.9.5. Note that the
CHILDINFO extended data item can only be returned when the
RECURSIVEMATCH selection option is specified.
3. Attributes returned in the same LIST response must be treated
additively. For example, the following response
S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
means that the "Fruit/Peach" mailbox doesn't exist, but it is
subscribed.
6.3.9.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 [RFC3348]. The CHILDREN
return option is simply an indication that the client wants this
information; a server MAY provide it even if the option is not
specified.
Many IMAP4 clients present to the user a hierarchical view of the
mailboxes that a user has access to. Rather than initially
presenting to the user the entire mailbox hierarchy, it is often
preferable to show to the user a collapsed outline list of the
mailbox hierarchy (particularly if there is a large number of
mailboxes). The user can then expand the collapsed outline hierarchy
as needed. It is common to include within the collapsed hierarchy a
visual clue (such as a ''+'') to indicate that there are child
mailboxes under a particular mailbox. When the visual clue is
clicked, the hierarchy list is expanded to show the child mailboxes.
The CHILDREN return option provides a mechanism for a client to
efficiently determine whether a particular mailbox has children,
without issuing a LIST "" * or a LIST "" % for each mailbox name.
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 is provided to indicate that the
client particularly wants this information. If the CHILDREN return
option is present, the server MUST return these attributes even if
their computation 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 and the user does not have permission
to access any of them. In this case, \HasNoChildren SHOULD be
used. In many cases, however, a server may not be able to
efficiently compute whether a user has access to any child
mailbox. Note that even though the \HasChildren attribute for a
mailbox must be correct at the time of processing of the
mailbox, a client must be prepared to deal with a situation when
a mailbox is marked with the \HasChildren attribute, but no
child mailbox appears in the response to the LIST command. This
might happen, for example, due to children mailboxes being
deleted or made inaccessible to the user (using access control)
by another client before the server is able to list them.
\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
IMAP4 defined attribute \NoInferiors, which indicates that no child
mailboxes exist now and none can be created in the future.
6.3.9.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 has caused it to be returned and indicates
that the mailbox has at least one descendant mailbox that matches the
selection criteria.
The LSUB command indicates this condition by using the "\NoSelect"
attribute, but the LIST (SUBSCRIBED) command MUST NOT do that, since
"\NoSelect" retains its original meaning here. Further, the
CHILDINFO extended data item is more general, in that it can be used
with any extended set of selection criteria.
Note: Some servers allow for mailboxes to exist without requiring
their parent to exist. For example, a mailbox "Customers/ABC" can
exist while the mailbox "Customers" does not. As CHILDINFO extended
data item is not allowed if the RECURSIVEMATCH selection option is
not specified, such servers SHOULD use the "\NonExistent
\HasChildren" attribute pair to signal to the client that there is a
descendant mailbox that matches the selection criteria. See example
11 in Section 6.3.9.6.
The returned selection criteria allow the client to distinguish a
solicited response from an unsolicited one, as well as to distinguish
among 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.
Examples 8 and 10 in Section 6.3.9.6 demonstrate the difference
between present CHILDINFO extended data item and the "\HasChildren"
attribute.
The following table summarizes interaction between the "\NonExistent"
attribute and CHILDINFO (the first column indicates whether the
parent mailbox exists):
+--------+--------------+--------------------+----------------------+
| exists | meets the | has a child that | returned LIST- |
| | selection | meets the | EXTENDED attributes |
| | criteria | selection criteria | 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.
6.3.9.6. LIST Command Examples
This example shows some uses of the basic LIST command:
Example: C: A101 LIST "" "" Example: C: A101 LIST "" ""
S: * LIST (\Noselect) "/" "" S: * LIST (\Noselect) "/" ""
S: A101 OK LIST Completed S: A101 OK LIST Completed
C: A102 LIST #news.comp.mail.misc "" C: A102 LIST #news.comp.mail.misc ""
S: * LIST (\Noselect) "." #news. S: * LIST (\Noselect) "." #news.
S: A102 OK LIST Completed S: A102 OK LIST Completed
C: A103 LIST /usr/staff/jones "" C: A103 LIST /usr/staff/jones ""
S: * LIST (\Noselect) "/" / S: * LIST (\Noselect) "/" /
S: A103 OK LIST Completed S: A103 OK LIST Completed
C: A202 LIST ~/Mail/ % C: A202 LIST ~/Mail/ %
S: * LIST (\Noselect) "/" ~/Mail/foo S: * LIST (\Noselect) "/" ~/Mail/foo
S: * LIST () "/" ~/Mail/meetings S: * LIST () "/" ~/Mail/meetings
S: A202 OK LIST completed S: A202 OK LIST completed
Extended examples:
1: The first example shows the complete local hierarchy that will
be used for the other examples.
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
2: In the next example, we will see the subscribed mailboxes. This
is similar to, but not equivalent with, <LSUB "" "*">. Note
that the mailbox called "Fruit/Peach" is subscribed to, but does
not actually exist (perhaps it was deleted while still
subscribed). The "Fruit" mailbox is not subscribed to, but it
has two subscribed children. The "Vegetable" mailbox is
subscribed and has two children; one of them is subscribed as
well.
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
3: The next example shows the use of the CHILDREN option. The
client, without having to list the second level of hierarchy,
now knows which of the top-level mailboxes have submailboxes
(children) and which do not. Note that it's not necessary for
the server to return the \HasNoChildren attribute for the inbox,
because the \NoInferiors attribute already implies that, and has
a stronger meaning.
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
4: In this example, we see more mailboxes that reside on another
server. This is similar to the command <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
5: The following example also requests the server to include
mailboxes that reside on another server. The server returns
information about all mailboxes that are subscribed. This is
similar to the command <RLSUB "" "*">. We also see the use of
two selection options.
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
6: The following example requests the server to include mailboxes
that reside on another server. The server is asked to return
subscription information for all returned mailboxes. This is
different from the example above.
Note that the output of this command is not a superset of the
output in the previous example, as it doesn't include LIST
response for the non-existent "Fruit/Peach".
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
7: In the following example, the client has specified multiple
mailbox patterns. Note that this example does not use the
mailbox hierarchy used in the previous examples.
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
8: The following example demonstrates the difference between the
\HasChildren attribute and the CHILDINFO extended data item.
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 RETURN (CHILDREN), it will get 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 the mailbox "Foo/Baz" is the only
subscribed mailbox. Then we get this result:
C: C02 LIST (SUBSCRIBED) "" "*"
S: * LIST (\Subscribed) "/" "Foo/Baz"
S: C02 OK done
Now, if the client issues <LIST (SUBSCRIBED) "" "%">, the server
will return no mailboxes (as the mailboxes "Moo", "Foo", and
"Inbox" are NOT subscribed). However, if the client issues
this:
C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
S: * LIST () "/" "Foo" ("CHILDINFO" ("SUBSCRIBED"))
S: C04 OK done
(i.e., the mailbox "Foo" is not subscribed, but it has a child
that is.)
A1) If the mailbox "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) If we assume instead that the mailbox "Foo" is not part of
the original hierarchy and is not subscribed, the last command
will give this result:
C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
S: * LIST (\NonExistent) "/" "Foo" ("CHILDINFO" ("SUBSCRIBED"))
S: C04 OK done
B) Now, let's assume that no mailbox is subscribed. In this
case, the command <LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"> will
return no responses, as there are no subscribed children (even
though "Foo" has children).
C) And finally, suppose that only the mailboxes "Foo" and "Moo"
are subscribed. In that case, we see this result:
C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" RETURN (CHILDREN)
S: * LIST (\HasChildren \Subscribed) "/" "Foo"
S: * LIST (\HasNoChildren \Subscribed) "/" "Moo"
S: C04 OK done
(which means that the mailbox "Foo" has children, but none of
them is subscribed).
9: The following example demonstrates that the CHILDINFO extended
data item is returned whether or not children mailboxes match
the canonical LIST pattern.
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 that 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 the following 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 (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 is returned for mailboxes
"foo2", "baz2", and "eps2", because all of them have subscribed
children, even though for the mailbox "foo2" only one of the two
subscribed children matches the pattern, for the mailbox "baz2"
all the subscribed children match the pattern, and for the
mailbox "eps2" none of the subscribed children matches the
pattern.
Note that if the client issues
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 mailboxes "foo2", "baz2", and "eps2"
still have the CHILDINFO extended data item, even though this
information is redundant and the client can determine it by
itself.
10: The following example shows usage of multiple mailbox patterns.
It also demonstrates that the presence of the CHILDINFO extended
data item doesn't necessarily imply \HasChildren.
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
11: The following example shows how a server that supports missing
mailbox hierarchy elements can signal to a client that didn't
specify the RECURSIVEMATCH selection option that there is a
child mailbox that matches the selection criteria.
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.
6.3.10. LSUB Command 6.3.10. LSUB Command
Arguments: reference name Arguments: reference name
mailbox name with possible wildcards mailbox name with possible wildcards
Responses: untagged responses: LSUB Responses: untagged responses: LSUB
Result: OK - lsub completed Result: OK - lsub completed
NO - lsub failure: can't list that reference or name NO - lsub failure: can't list that reference or name
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
skipping to change at page 117, line 29 skipping to change at page 131, line 29
[DISPOSITION] [DISPOSITION]
Troost, R., Dorner, S., and K. Moore, Ed., "Communicating Troost, R., Dorner, S., and K. Moore, Ed., "Communicating
Presentation Information in Internet Messages: The Presentation Information in Internet Messages: The
Content-Disposition Header Field", RFC 2183, August 1997, Content-Disposition Header Field", RFC 2183, August 1997,
<http://www.rfc-editor.org/info/rfc2183>. <http://www.rfc-editor.org/info/rfc2183>.
[PLAIN] Zeilenga, K., Ed., "The PLAIN Simple Authentication and [PLAIN] Zeilenga, K., Ed., "The PLAIN Simple Authentication and
Security Layer (SASL) Mechanism", RFC 4616, August 2006, Security Layer (SASL) Mechanism", RFC 4616, August 2006,
<http://www.rfc-editor.org/info/rfc4616>. <http://www.rfc-editor.org/info/rfc4616>.
[KEYWORDS] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119,
Requirement Levels", BCP 14, RFC 2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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>.
[LANGUAGE-TAGS] [LANGUAGE-TAGS]
Alvestrand, H., "Content Language Headers", RFC 3282, May Alvestrand, H., "Content Language Headers", RFC 3282, May
2002, <http://www.rfc-editor.org/info/rfc3282>. 2002, <http://www.rfc-editor.org/info/rfc3282>.
[LOCATION] [LOCATION]
Palme, J., Hopmann, A., and N. Shelness, "MIME Palme, J., Hopmann, A., and N. Shelness, "MIME
Encapsulation of Aggregate Documents, such as HTML Encapsulation of Aggregate Documents, such as HTML
(MHTML)", RFC 2557, March 1999, (MHTML)", RFC 2557, March 1999,
<http://www.rfc-editor.org/info/rfc2557>. <http://www.rfc-editor.org/info/rfc2557>.
skipping to change at page 119, line 40 skipping to change at page 133, line 45
RFC 7888, DOI 10.17487/RFC7888, May 2016, RFC 7888, DOI 10.17487/RFC7888, May 2016,
<https://www.rfc-editor.org/info/rfc7888>. <https://www.rfc-editor.org/info/rfc7888>.
[RFC8314] Moore, K. and C. Newman, "Cleartext Considered Obsolete: [RFC8314] Moore, K. and C. Newman, "Cleartext Considered Obsolete:
Use of Transport Layer Security (TLS) for Email Submission Use of Transport Layer Security (TLS) for Email Submission
and Access", RFC 8314, DOI 10.17487/RFC8314, January 2018, and Access", RFC 8314, DOI 10.17487/RFC8314, January 2018,
<https://www.rfc-editor.org/info/rfc8314>. <https://www.rfc-editor.org/info/rfc8314>.
13.2. Informative References (related protocols) 13.2. Informative References (related protocols)
[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>.
[RFC2193] Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193,
DOI 10.17487/RFC2193, September 1997,
<https://www.rfc-editor.org/info/rfc2193>.
[RFC3348] Gahrns, M. and R. Cheng, "The Internet Message Action
Protocol (IMAP4) Child Mailbox Extension", RFC 3348,
DOI 10.17487/RFC3348, July 2002,
<https://www.rfc-editor.org/info/rfc3348>.
[IMAP-DISC] [IMAP-DISC]
Melnikov, A., Ed., "Synchronization Operations for Melnikov, A., Ed., "Synchronization Operations for
Disconnected IMAP4 Clients", RFC 4549, June 2006, Disconnected IMAP4 Clients", RFC 4549, June 2006,
<http://www.rfc-editor.org/info/rfc4549>. <http://www.rfc-editor.org/info/rfc4549>.
[IMAP-I18N] [IMAP-I18N]
Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet
Message Access Protocol Internationalization", RFC 5255, Message Access Protocol Internationalization", RFC 5255,
DOI 10.17487/RFC5255, June 2008, DOI 10.17487/RFC5255, June 2008,
<http://www.rfc-editor.org/info/rfc5255>. <http://www.rfc-editor.org/info/rfc5255>.
skipping to change at page 125, line 38 skipping to change at page 140, line 12
5161, RFC 6154 so work done by authors/editors of these documents is 5161, RFC 6154 so work done by authors/editors of these documents is
appreciated. appreciated.
Index Index
$ $
$Forwarded (predefined flag) 12 $Forwarded (predefined flag) 12
$MDNSent (predefined flag) 12 $MDNSent (predefined flag) 12
+ +
+FLAGS <flag list> 68 +FLAGS <flag list> 82
+FLAGS.SILENT <flag list> 68 +FLAGS.SILENT <flag list> 82
- -
-FLAGS <flag list> 68 -FLAGS <flag list> 82
-FLAGS.SILENT <flag list> 68 -FLAGS.SILENT <flag list> 82
A A
ALERT (response code) 75 ALERT (response code) 89
ALL (fetch item) 63 ALL (fetch item) 77
ALL (search key) 60 ALL (search key) 74
ALL (search result option) 59 ALL (search result option) 73
ALREADYEXISTS (response code) 75 ALREADYEXISTS (response code) 89
ANSWERED (search key) 60 ANSWERED (search key) 74
APPEND (command) 51 APPEND (command) 65
APPENDUID (response code) 75 APPENDUID (response code) 89
AUTHENTICATE (command) 27 AUTHENTICATE (command) 27
AUTHENTICATIONFAILED (response code) 76 AUTHENTICATIONFAILED (response code) 90
AUTHORIZATIONFAILED (response code) 76 AUTHORIZATIONFAILED (response code) 90
B B
BAD (response) 83 BAD (response) 97
BADCHARSET (response code) 76 BADCHARSET (response code) 90
BCC <string> (search key) 60 BCC <string> (search key) 74
BEFORE <date> (search key) 60 BEFORE <date> (search key) 74
BINARY.PEEK[<section-binary>]<<partial>> (fetch item) 64 BINARY.PEEK[<section-binary>]<<partial>> (fetch item) 78
BINARY.SIZE[<section-binary>] (fetch item) 64 BINARY.SIZE[<section-binary>] (fetch item) 78
BINARY.SIZE[<section-binary>] (fetch result) 92 BINARY.SIZE[<section-binary>] (fetch result) 106
BINARY[<section-binary>]<<number>> (fetch result) 92 BINARY[<section-binary>]<<number>> (fetch result) 106
BINARY[<section-binary>]<<partial>> (fetch item) 64 BINARY[<section-binary>]<<partial>> (fetch item) 78
BODY (fetch item) 64 BODY (fetch item) 78
BODY (fetch result) 92 BODY (fetch result) 106
BODY <string> (search key) 60 BODY <string> (search key) 74
BODY.PEEK[<section>]<<partial>> (fetch item) 66 BODY.PEEK[<section>]<<partial>> (fetch item) 80
BODYSTRUCTURE (fetch item) 67 BODYSTRUCTURE (fetch item) 81
BODYSTRUCTURE (fetch result) 93 BODYSTRUCTURE (fetch result) 107
BODY[<section>]<<origin octet>> (fetch result) 92 BODY[<section>]<<origin octet>> (fetch result) 106
BODY[<section>]<<partial>> (fetch item) 64 BODY[<section>]<<partial>> (fetch item) 78
BYE (response) 83 BYE (response) 97
Body Structure (message attribute) 13 Body Structure (message attribute) 13
C C
CANNOT (response code) 77 CANNOT (response code) 91
CAPABILITY (command) 24 CAPABILITY (command) 24
CAPABILITY (response code) 77 CAPABILITY (response code) 91
CAPABILITY (response) 84 CAPABILITY (response) 98
CC <string> (search key) 60 CC <string> (search key) 74
CHECK (command) 56 CHECK (command) 70
CLIENTBUG (response code) 77 CLIENTBUG (response code) 91
CLOSE (command) 56 CLOSE (command) 70
CLOSED (response code) 77 CLOSED (response code) 91
CONTACTADMIN (response code) 78 CONTACTADMIN (response code) 92
COPY (command) 68 COPY (command) 82
COPYUID (response code) 78 COPYUID (response code) 92
CORRUPTION (response code) 78 CORRUPTION (response code) 92
COUNT (search result option) 59 COUNT (search result option) 73
CREATE (command) 35 CREATE (command) 35
D D
DELETE (command) 36 DELETE (command) 36
DELETED (search key) 60 DELETED (search key) 74
DRAFT (search key) 60 DRAFT (search key) 74
E E
ENABLE (command) 31 ENABLE (command) 31
ENVELOPE (fetch item) 67 ENVELOPE (fetch item) 81
ENVELOPE (fetch result) 96 ENVELOPE (fetch result) 110
ESEARCH (response) 89 ESEARCH (response) 103
EXAMINE (command) 35 EXAMINE (command) 35
EXPIRED (response code) 78 EXPIRED (response code) 92
EXPUNGE (command) 57 EXPUNGE (command) 71
EXPUNGE (response) 91 EXPUNGE (response) 105
EXPUNGEISSUED (response code) 79 EXPUNGEISSUED (response code) 93
Envelope Structure (message attribute) 13 Envelope Structure (message attribute) 13
F F
FAST (fetch item) 63 FAST (fetch item) 77
FETCH (command) 63 FETCH (command) 77
FETCH (response) 91 FETCH (response) 105
FLAGGED (search key) 60 FLAGGED (search key) 74
FLAGS (fetch item) 67 FLAGS (fetch item) 81
FLAGS (fetch result) 97 FLAGS (fetch result) 111
FLAGS (response) 90 FLAGS (response) 104
FLAGS <flag list> (store command data item) 68 FLAGS <flag list> (store command data item) 82
FLAGS.SILENT <flag list> (store command data item) 68 FLAGS.SILENT <flag list> (store command data item) 82
FROM <string> (search key) 60 FROM <string> (search key) 74
FULL (fetch item) 64 FULL (fetch item) 78
Flags (message attribute) 11 Flags (message attribute) 11
H H
HEADER (part specifier) 65 HEADER (part specifier) 79
HEADER <field-name> <string> (search key) 60 HEADER <field-name> <string> (search key) 74
HEADER.FIELDS (part specifier) 65 HEADER.FIELDS (part specifier) 79
HEADER.FIELDS.NOT (part specifier) 65 HEADER.FIELDS.NOT (part specifier) 79
I I
IDLE (command) 53 IDLE (command) 67
INTERNALDATE (fetch item) 67 INTERNALDATE (fetch item) 81
INTERNALDATE (fetch result) 97 INTERNALDATE (fetch result) 111
INUSE (response code) 79 INUSE (response code) 93
Internal Date (message attribute) 12 Internal Date (message attribute) 12
K K
KEYWORD <flag> (search key) 61 KEYWORD <flag> (search key) 75
Keyword (type of flag) 12 Keyword (type of flag) 12
L L
LARGER <n> (search key) 61 LARGER <n> (search key) 75
LIMIT (response code) 79 LIMIT (response code) 93
LIST (command) 41 LIST (command) 41
LIST (response) 85 LIST (response) 99
LOGOUT (command) 25 LOGOUT (command) 25
LSUB (command) 44 LSUB (command) 58
LSUB (response) 88 LSUB (response) 102
M M
MAX (search result option) 58 MAX (search result option) 72
MAY (specification requirement term) 5 MAY (specification requirement term) 5
MESSAGES (status item) 50 MESSAGES (status item) 64
MIME (part specifier) 65 MIME (part specifier) 79
MIN (search result option) 58 MIN (search result option) 72
MOVE (command) 69 MOVE (command) 83
MUST (specification requirement term) 5 MUST (specification requirement term) 5
MUST NOT (specification requirement term) 5 MUST NOT (specification requirement term) 5
Message Sequence Number (message attribute) 11 Message Sequence Number (message attribute) 11
N N
NAMESPACE (command) 45 NAMESPACE (command) 59
NAMESPACE (response) 89 NAMESPACE (response) 103
NEW (search key) 61 NEW (search key) 75
NO (response) 82 NO (response) 96
NONEXISTENT (response code) 79 NONEXISTENT (response code) 93
NOOP (command) 25 NOOP (command) 25
NOPERM (response code) 79 NOPERM (response code) 93
NOT <search-key> (search key) 61 NOT <search-key> (search key) 75
NOT RECOMMENDED (specification requirement term) 5
O O
OK (response) 82 OK (response) 96
ON <date> (search key) 61 ON <date> (search key) 75
OPTIONAL (specification requirement term) 5 OPTIONAL (specification requirement term) 5
OR <search-key1> <search-key2> (search key) 61 OR <search-key1> <search-key2> (search key) 75
OVERQUOTA (response code) 80 OVERQUOTA (response code) 94
P P
PARSE (response code) 80 PARSE (response code) 94
PERMANENTFLAGS (response code) 80 PERMANENTFLAGS (response code) 94
PREAUTH (response) 83 PREAUTH (response) 97
PRIVACYREQUIRED (response code) 80 PRIVACYREQUIRED (response code) 94
Permanent Flag (class of flag) 12 Permanent Flag (class of flag) 12
Predefined keywords 12 Predefined keywords 12
R R
READ-ONLY (response code) 81 READ-ONLY (response code) 95
READ-WRITE (response code) 81 READ-WRITE (response code) 95
RECOMMENDED (specification requirement term) 5 RECOMMENDED (specification requirement term) 5
RENAME (command) 38 RENAME (command) 38
REQUIRED (specification requirement term) 5 REQUIRED (specification requirement term) 5
RFC822 (fetch item) 67 RFC822 (fetch item) 81
RFC822 (fetch result) 97 RFC822 (fetch result) 111
RFC822.HEADER (fetch item) 67 RFC822.HEADER (fetch item) 81
RFC822.HEADER (fetch result) 97 RFC822.HEADER (fetch result) 111
RFC822.SIZE (fetch item) 67 RFC822.SIZE (fetch item) 81
RFC822.SIZE (fetch result) 97 RFC822.SIZE (fetch result) 111
RFC822.TEXT (fetch item) 67 RFC822.TEXT (fetch item) 81
RFC822.TEXT (fetch result) 97 RFC822.TEXT (fetch result) 111
S S
SEARCH (command) 58 SEARCH (command) 72
SEEN (search key) 61 SEEN (search key) 75
SELECT (command) 33 SELECT (command) 33
SENTBEFORE <date> (search key) 61 SENTBEFORE <date> (search key) 75
SENTON <date> (search key) 61 SENTON <date> (search key) 75
SENTSINCE <date> (search key) 61 SENTSINCE <date> (search key) 75
SERVERBUG (response code) 81 SERVERBUG (response code) 95
SHOULD (specification requirement term) 5 SHOULD (specification requirement term) 5
SHOULD NOT (specification requirement term) 5 SHOULD NOT (specification requirement term) 5
SINCE <date> (search key) 61 SINCE <date> (search key) 75
SIZE (status item) 51 SIZE (status item) 65
SMALLER <n> (search key) 61 SMALLER <n> (search key) 75
STARTTLS (command) 26 STARTTLS (command) 26
STATUS (command) 49 STATUS (command) 63
STATUS (response) 89 STATUS (response) 103
STORE (command) 67 STORE (command) 81
SUBJECT <string> (search key) 61 SUBJECT <string> (search key) 75
SUBSCRIBE (command) 40 SUBSCRIBE (command) 40
Session Flag (class of flag) 12 Session Flag (class of flag) 12
System Flag (type of flag) 11 System Flag (type of flag) 11
T T
TEXT (part specifier) 65 TEXT (part specifier) 79
TEXT <string> (search key) 61 TEXT <string> (search key) 75
TO <string> (search key) 61 TO <string> (search key) 75
TRYCREATE (response code) 81 TRYCREATE (response code) 95
U U
UID (command) 71 UID (command) 85
UID (fetch item) 67 UID (fetch item) 81
UID (fetch result) 97 UID (fetch result) 111
UID <sequence set> (search key) 62 UID <sequence set> (search key) 76
UIDNEXT (response code) 81 UIDNEXT (response code) 95
UIDNEXT (status item) 50 UIDNEXT (status item) 64
UIDNOTSTICKY (response code) 81 UIDNOTSTICKY (response code) 95
UIDVALIDITY (response code) 81 UIDVALIDITY (response code) 95
UIDVALIDITY (status item) 50 UIDVALIDITY (status item) 64
UNANSWERED (search key) 62 UNANSWERED (search key) 76
UNAVAILABLE (response code) 81 UNAVAILABLE (response code) 95
UNDELETED (search key) 62 UNDELETED (search key) 76
UNDRAFT (search key) 62 UNDRAFT (search key) 76
UNFLAGGED (search key) 62 UNFLAGGED (search key) 76
UNKEYWORD <flag> (search key) 62 UNKEYWORD <flag> (search key) 76
UNKNOWN-CTE (response code) 82 UNKNOWN-CTE (response code) 96
UNSEEN (search key) 62 UNSEEN (search key) 76
UNSEEN (status item) 50 UNSEEN (status item) 64
UNSELECT (command) 57 UNSELECT (command) 71
UNSUBSCRIBE (command) 41 UNSUBSCRIBE (command) 41
Unique Identifier (UID) (message attribute) 9 Unique Identifier (UID) (message attribute) 9
X X
X<atom> (command) 73 X<atom> (command) 87
[ [
[RFC-5322] Size (message attribute) 13 [RFC-5322] Size (message attribute) 13
\ \
\All (mailbox name attribute) 87 \All (mailbox name attribute) 101
\Answered (system flag) 11 \Answered (system flag) 11
\Archive (mailbox name attribute) 87 \Archive (mailbox name attribute) 101
\Deleted (system flag) 11 \Deleted (system flag) 11
\Draft (system flag) 12 \Draft (system flag) 12
\Drafts (mailbox name attribute) 87 \Drafts (mailbox name attribute) 101
\Flagged (mailbox name attribute) 87 \Flagged (mailbox name attribute) 101
\Flagged (system flag) 11 \Flagged (system flag) 11
\HasChildren (mailbox name attribute) 86 \HasChildren (mailbox name attribute) 100
\HasNoChildren (mailbox name attribute) 86 \HasNoChildren (mailbox name attribute) 100
\Junk (mailbox name attribute) 87 \Junk (mailbox name attribute) 101
\Marked (mailbox name attribute) 86 \Marked (mailbox name attribute) 100
\Noinferiors (mailbox name attribute) 86 \Noinferiors (mailbox name attribute) 100
\Noselect (mailbox name attribute) 86 \Noselect (mailbox name attribute) 100
\Recent (system flag) 12 \Recent (system flag) 12
\Seen (system flag) 11 \Seen (system flag) 11
\Sent (mailbox name attribute) 87 \Sent (mailbox name attribute) 101
\Trash (mailbox name attribute) 87 \Trash (mailbox name attribute) 101
\Unmarked (mailbox name attribute) 86 \Unmarked (mailbox name attribute) 100
Authors' Addresses Authors' Addresses
Alexey Melnikov (editor) Alexey Melnikov (editor)
Isode Ltd Isode Ltd
14 Castle Mews 14 Castle Mews
Hampton, Middlesex TW12 2NP Hampton, Middlesex TW12 2NP
UK UK
Email: Alexey.Melnikov@isode.com Email: Alexey.Melnikov@isode.com
 End of changes. 55 change blocks. 
242 lines changed or deleted 904 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/