< draft-ietf-extra-imap4rev2-14.txt   draft-ietf-extra-imap4rev2-15.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 Futurewei Technologies Intended status: Standards Track Futurewei Technologies
Expires: November 9, 2020 May 8, 2020 Expires: December 19, 2020 June 17, 2020
Internet Message Access Protocol (IMAP) - Version 4rev2 Internet Message Access Protocol (IMAP) - Version 4rev2
draft-ietf-extra-imap4rev2-14 draft-ietf-extra-imap4rev2-15
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 November 9, 2020. This Internet-Draft will expire on December 19, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 43 skipping to change at page 3, line 43
6.3.1. ENABLE Command . . . . . . . . . . . . . . . . . . . 33 6.3.1. ENABLE Command . . . . . . . . . . . . . . . . . . . 33
6.3.2. SELECT Command . . . . . . . . . . . . . . . . . . . 35 6.3.2. SELECT Command . . . . . . . . . . . . . . . . . . . 35
6.3.3. EXAMINE Command . . . . . . . . . . . . . . . . . . . 37 6.3.3. EXAMINE Command . . . . . . . . . . . . . . . . . . . 37
6.3.4. CREATE Command . . . . . . . . . . . . . . . . . . . 38 6.3.4. CREATE Command . . . . . . . . . . . . . . . . . . . 38
6.3.5. DELETE Command . . . . . . . . . . . . . . . . . . . 39 6.3.5. DELETE Command . . . . . . . . . . . . . . . . . . . 39
6.3.6. RENAME Command . . . . . . . . . . . . . . . . . . . 40 6.3.6. RENAME Command . . . . . . . . . . . . . . . . . . . 40
6.3.7. SUBSCRIBE Command . . . . . . . . . . . . . . . . . . 42 6.3.7. SUBSCRIBE Command . . . . . . . . . . . . . . . . . . 42
6.3.8. UNSUBSCRIBE Command . . . . . . . . . . . . . . . . . 43 6.3.8. UNSUBSCRIBE Command . . . . . . . . . . . . . . . . . 43
6.3.9. LIST Command . . . . . . . . . . . . . . . . . . . . 43 6.3.9. LIST Command . . . . . . . . . . . . . . . . . . . . 43
6.3.10. NAMESPACE Command . . . . . . . . . . . . . . . . . . 61 6.3.10. NAMESPACE Command . . . . . . . . . . . . . . . . . . 61
6.3.11. STATUS Command . . . . . . . . . . . . . . . . . . . 66 6.3.11. STATUS Command . . . . . . . . . . . . . . . . . . . 65
6.3.12. APPEND Command . . . . . . . . . . . . . . . . . . . 67 6.3.12. APPEND Command . . . . . . . . . . . . . . . . . . . 66
6.3.13. IDLE Command . . . . . . . . . . . . . . . . . . . . 70 6.3.13. IDLE Command . . . . . . . . . . . . . . . . . . . . 69
6.4. Client Commands - Selected State . . . . . . . . . . . . 72 6.4. Client Commands - Selected State . . . . . . . . . . . . 71
6.4.1. CLOSE Command . . . . . . . . . . . . . . . . . . . . 72 6.4.1. CLOSE Command . . . . . . . . . . . . . . . . . . . . 71
6.4.2. UNSELECT Command . . . . . . . . . . . . . . . . . . 73 6.4.2. UNSELECT Command . . . . . . . . . . . . . . . . . . 72
6.4.3. EXPUNGE Command . . . . . . . . . . . . . . . . . . . 73 6.4.3. EXPUNGE Command . . . . . . . . . . . . . . . . . . . 72
6.4.4. SEARCH Command . . . . . . . . . . . . . . . . . . . 74 6.4.4. SEARCH Command . . . . . . . . . . . . . . . . . . . 73
6.4.5. FETCH Command . . . . . . . . . . . . . . . . . . . . 86 6.4.5. FETCH Command . . . . . . . . . . . . . . . . . . . . 85
6.4.6. STORE Command . . . . . . . . . . . . . . . . . . . . 90 6.4.6. STORE Command . . . . . . . . . . . . . . . . . . . . 89
6.4.7. COPY Command . . . . . . . . . . . . . . . . . . . . 91 6.4.7. COPY Command . . . . . . . . . . . . . . . . . . . . 90
6.4.8. MOVE Command . . . . . . . . . . . . . . . . . . . . 92 6.4.8. MOVE Command . . . . . . . . . . . . . . . . . . . . 91
6.4.9. UID Command . . . . . . . . . . . . . . . . . . . . . 94 6.4.9. UID Command . . . . . . . . . . . . . . . . . . . . . 93
6.5. Client Commands - Experimental/Expansion . . . . . . . . 96 6.5. Client Commands - Experimental/Expansion . . . . . . . . 95
6.5.1. X<atom> Command . . . . . . . . . . . . . . . . . . . 96 6.5.1. X<atom> Command . . . . . . . . . . . . . . . . . . . 95
7. Server Responses . . . . . . . . . . . . . . . . . . . . . . 97 7. Server Responses . . . . . . . . . . . . . . . . . . . . . . 96
7.1. Server Responses - Status Responses . . . . . . . . . . . 98 7.1. Server Responses - Status Responses . . . . . . . . . . . 97
7.1.1. OK Response . . . . . . . . . . . . . . . . . . . . . 106 7.1.1. OK Response . . . . . . . . . . . . . . . . . . . . . 105
7.1.2. NO Response . . . . . . . . . . . . . . . . . . . . . 106 7.1.2. NO Response . . . . . . . . . . . . . . . . . . . . . 105
7.1.3. BAD Response . . . . . . . . . . . . . . . . . . . . 107 7.1.3. BAD Response . . . . . . . . . . . . . . . . . . . . 106
7.1.4. PREAUTH Response . . . . . . . . . . . . . . . . . . 107 7.1.4. PREAUTH Response . . . . . . . . . . . . . . . . . . 106
7.1.5. BYE Response . . . . . . . . . . . . . . . . . . . . 107 7.1.5. BYE Response . . . . . . . . . . . . . . . . . . . . 106
7.2. Server Responses - Server and Mailbox Status . . . . . . 108 7.2. Server Responses - Server and Mailbox Status . . . . . . 107
7.2.1. The ENABLED Response . . . . . . . . . . . . . . . . 108 7.2.1. The ENABLED Response . . . . . . . . . . . . . . . . 107
7.2.2. CAPABILITY Response . . . . . . . . . . . . . . . . . 108 7.2.2. CAPABILITY Response . . . . . . . . . . . . . . . . . 107
7.2.3. LIST Response . . . . . . . . . . . . . . . . . . . . 109 7.2.3. LIST Response . . . . . . . . . . . . . . . . . . . . 108
7.2.4. NAMESPACE Response . . . . . . . . . . . . . . . . . 113 7.2.4. NAMESPACE Response . . . . . . . . . . . . . . . . . 112
7.2.5. STATUS Response . . . . . . . . . . . . . . . . . . . 113 7.2.5. STATUS Response . . . . . . . . . . . . . . . . . . . 113
7.2.6. ESEARCH Response . . . . . . . . . . . . . . . . . . 114 7.2.6. ESEARCH Response . . . . . . . . . . . . . . . . . . 113
7.2.7. FLAGS Response . . . . . . . . . . . . . . . . . . . 114 7.2.7. FLAGS Response . . . . . . . . . . . . . . . . . . . 113
7.3. Server Responses - Mailbox Size . . . . . . . . . . . . . 115 7.3. Server Responses - Mailbox Size . . . . . . . . . . . . . 114
7.3.1. EXISTS Response . . . . . . . . . . . . . . . . . . . 115 7.3.1. EXISTS Response . . . . . . . . . . . . . . . . . . . 114
7.4. Server Responses - Message Status . . . . . . . . . . . . 115 7.4. Server Responses - Message Status . . . . . . . . . . . . 114
7.4.1. EXPUNGE Response . . . . . . . . . . . . . . . . . . 115 7.4.1. EXPUNGE Response . . . . . . . . . . . . . . . . . . 114
7.4.2. FETCH Response . . . . . . . . . . . . . . . . . . . 116 7.4.2. FETCH Response . . . . . . . . . . . . . . . . . . . 115
7.5. Server Responses - Command Continuation Request . . . . . 122 7.5. Server Responses - Command Continuation Request . . . . . 121
8. Sample IMAP4rev2 connection . . . . . . . . . . . . . . . . . 122 8. Sample IMAP4rev2 connection . . . . . . . . . . . . . . . . . 122
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 123 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 123
10. Author's Note . . . . . . . . . . . . . . . . . . . . . . . . 140 10. Author's Note . . . . . . . . . . . . . . . . . . . . . . . . 140
11. Security Considerations . . . . . . . . . . . . . . . . . . . 140 11. Security Considerations . . . . . . . . . . . . . . . . . . . 140
11.1. STARTTLS Security Considerations . . . . . . . . . . . . 141 11.1. STARTTLS Security Considerations . . . . . . . . . . . . 140
11.2. COPYUID and APPENDUID response codes . . . . . . . . . . 141 11.2. COPYUID and APPENDUID response codes . . . . . . . . . . 140
11.3. LIST command and Other Users' namespace . . . . . . . . 141 11.3. LIST command and Other Users' namespace . . . . . . . . 141
11.4. Other Security Considerations . . . . . . . . . . . . . 142 11.4. Other Security Considerations . . . . . . . . . . . . . 141
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 142 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 142
12.1. Updates to IMAP4 Capabilities registry . . . . . . . . . 143 12.1. Updates to IMAP4 Capabilities registry . . . . . . . . . 142
12.2. GSSAPI/SASL service name . . . . . . . . . . . . . . . . 143 12.2. GSSAPI/SASL service name . . . . . . . . . . . . . . . . 142
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 143 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 142
13.1. Normative References . . . . . . . . . . . . . . . . . . 143 13.1. Normative References . . . . . . . . . . . . . . . . . . 142
13.2. Informative References (related protocols) . . . . . . . 146 13.2. Informative References (related protocols) . . . . . . . 145
13.3. Informative References (historical aspects of IMAP and 13.3. Informative References (historical aspects of IMAP and
related protocols) . . . . . . . . . . . . . . . . . . . 148 related protocols) . . . . . . . . . . . . . . . . . . . 147
Appendix A. Backward compatibility with IMAP4rev1 . . . . . . . 149 Appendix A. Backward compatibility with IMAP4rev1 . . . . . . . 148
A.1. Mailbox International Naming Convention for compatibility A.1. Mailbox International Naming Convention for compatibility
with IMAP4rev1 . . . . . . . . . . . . . . . . . . . . . 149 with IMAP4rev1 . . . . . . . . . . . . . . . . . . . . . 148
Appendix B. Backward compatibility with BINARY extension . . . . 151 Appendix B. Backward compatibility with BINARY extension . . . . 150
Appendix C. Changes from RFC 3501 / IMAP4rev1 . . . . . . . . . 151 Appendix C. Backward compatibility with LIST-EXTENDED extension 150
Appendix D. Acknowledgement . . . . . . . . . . . . . . . . . . 153 Appendix D. Changes from RFC 3501 / IMAP4rev1 . . . . . . . . . 150
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 Appendix E. Acknowledgement . . . . . . . . . . . . . . . . . . 153
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 159 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 158
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 6, line 38 skipping to change at page 6, line 41
IMAP4rev2 is designed to be upwards compatible from the [IMAP2] and IMAP4rev2 is designed to be upwards compatible from the [IMAP2] and
unpublished IMAP2bis protocols. IMAP4rev2 is largely compatible with unpublished IMAP2bis protocols. IMAP4rev2 is largely compatible with
the IMAP4rev1 protocol described in RFC 3501 and the IMAP4 protocol the IMAP4rev1 protocol described in RFC 3501 and the IMAP4 protocol
described in RFC 1730; the exception being in certain facilities described in RFC 1730; the exception being in certain facilities
added in RFC 1730 that proved problematic and were subsequently added in RFC 1730 that proved problematic and were subsequently
removed. In the course of the evolution of IMAP4rev2, some aspects removed. In the course of the evolution of IMAP4rev2, some aspects
in the earlier protocols have become obsolete. Obsolete commands, in the earlier protocols have become obsolete. Obsolete commands,
responses, and data formats which an IMAP4rev2 implementation can responses, and data formats which an IMAP4rev2 implementation can
encounter when used with an earlier implementation are described in encounter when used with an earlier implementation are described in
Appendix C and [IMAP-OBSOLETE]. Appendix D and [IMAP-OBSOLETE].
Other compatibility issues with IMAP2bis, the most common variant of Other compatibility issues with IMAP2bis, the most common variant of
the earlier protocol, are discussed in [IMAP-COMPAT]. A full the earlier protocol, are discussed in [IMAP-COMPAT]. A full
discussion of compatibility issues with rare (and presumed extinct) discussion of compatibility issues with rare (and presumed extinct)
variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is
primarily of historical interest. primarily of historical interest.
IMAP was originally developed for the older [RFC-822] standard, and IMAP was originally developed for the older [RFC-822] standard, and
as a consequence several fetch items in IMAP incorporate "RFC822" in as a consequence several fetch items in IMAP incorporate "RFC822" in
their name. In all cases, "RFC822" should be interpreted as a their name. In all cases, "RFC822" should be interpreted as a
skipping to change at page 9, line 36 skipping to change at page 9, line 36
mailbox; as each message is added to the mailbox it is assigned a mailbox; as each message is added to the mailbox it is assigned a
higher UID than the message(s) which were added previously. Unlike higher UID than the message(s) which were added previously. Unlike
message sequence numbers, unique identifiers are not necessarily message sequence numbers, unique identifiers are not necessarily
contiguous. contiguous.
The unique identifier of a message MUST NOT change during the The unique identifier of a message MUST NOT change during the
session, and SHOULD NOT change between sessions. Any change of session, and SHOULD NOT change between sessions. Any change of
unique identifiers between sessions MUST be detectable using the unique identifiers between sessions MUST be detectable using the
UIDVALIDITY mechanism discussed below. Persistent unique identifiers UIDVALIDITY mechanism discussed below. Persistent unique identifiers
are required for a client to resynchronize its state from a previous are required for a client to resynchronize its state from a previous
session with the server (e.g., disconnected or offline access session with the server (e.g., disconnected or offline access clients
clients); this is discussed further in [IMAP-DISC]. [IMAP-MODEL]); this is discussed further in [IMAP-DISC].
Associated with every mailbox are two 32-bit unsigned non-zero values Associated with every mailbox are two 32-bit unsigned non-zero values
which aid in unique identifier handling: the next unique identifier which aid in unique identifier handling: the next unique identifier
value (UIDNEXT) and the unique identifier validity value value (UIDNEXT) and the unique identifier validity value
(UIDVALIDITY). (UIDVALIDITY).
The next unique identifier value is the predicted value that will be The next unique identifier value is the predicted value that will be
assigned to a new message in the mailbox. Unless the unique assigned to a new message in the mailbox. Unless the unique
identifier validity also changes (see below), the next unique identifier validity also changes (see below), the next unique
identifier value MUST have the following two characteristics. First, identifier value MUST have the following two characteristics. First,
skipping to change at page 39, line 49 skipping to change at page 39, line 49
is the hierarchy delimiter character), removing "foo" MUST NOT remove is the hierarchy delimiter character), removing "foo" MUST NOT remove
"foo.bar". It is an error to attempt to delete a name that has "foo.bar". It is an error to attempt to delete a name that has
inferior hierarchical names and also has the \Noselect mailbox name inferior hierarchical names and also has the \Noselect mailbox name
attribute (see the description of the LIST response for more attribute (see the description of the LIST response for more
details). details).
It is permitted to delete a name that has inferior hierarchical names It is permitted to delete a name that has inferior hierarchical names
and does not have the \Noselect mailbox name attribute. If the and does not have the \Noselect mailbox name attribute. If the
server implementation does not permit deleting the name while server implementation does not permit deleting the name while
inferior hierarchical names exists then it SHOULD disallow the DELETE inferior hierarchical names exists then it SHOULD disallow the DELETE
command by returning tagged NO response or it MAY allow the DELETE command by returning a tagged NO response. The NO response SHOULD
command, but sets the \Noselect mailbox name attribute for that name. include the HASCHILDREN response code. Alternatively the server MAY
In any case, all messages in that mailbox are removed by the DELETE allow the DELETE command, but sets the \Noselect mailbox name
command. attribute for that name.
If the server returns OK response, all messages in that mailbox are
removed by the DELETE command.
The value of the highest-used unique identifier of the deleted The value of the highest-used unique identifier of the deleted
mailbox MUST be preserved so that a new mailbox created with the same mailbox MUST be preserved so that a new mailbox created with the same
name will not reuse the identifiers of the former incarnation, UNLESS name will not reuse the identifiers of the former incarnation, UNLESS
the new incarnation has a different unique identifier validity value. the new incarnation has a different unique identifier validity value.
See the description of the UID command for more detail. See the description of the UID command for more detail.
Examples: C: A682 LIST "" * Examples: C: A682 LIST "" *
S: * LIST () "/" blurdybloop S: * LIST () "/" blurdybloop
S: * LIST (\Noselect) "/" foo S: * LIST (\Noselect) "/" foo
skipping to change at page 41, line 31 skipping to change at page 41, line 34
server in which "/" is the hierarchy separator character SHOULD server in which "/" is the hierarchy separator character SHOULD
create baz/ and baz/rag/ if they do not already exist. create baz/ and baz/rag/ if they do not already exist.
The value of the highest-used unique identifier of the old mailbox The value of the highest-used unique identifier of the old mailbox
name MUST be preserved so that a new mailbox created with the same name MUST be preserved so that a new mailbox created with the same
name will not reuse the identifiers of the former incarnation, UNLESS name will not reuse the identifiers of the former incarnation, UNLESS
the new incarnation has a different unique identifier validity value. the new incarnation has a different unique identifier validity value.
See the description of the UID command for more detail. See the description of the UID command for more detail.
Renaming INBOX is permitted, and has special behavior. (Note that Renaming INBOX is permitted, and has special behavior. (Note that
some servers refuse renaming INBOX). It moves all messages in INBOX some servers disallow renaming INBOX, so clients need to be able to
to a new mailbox with the given name, leaving INBOX empty. If the handle such RENAME failing). It moves all messages in INBOX to a new
server implementation supports inferior hierarchical names of INBOX, mailbox with the given name, leaving INBOX empty. If the server
these are unaffected by a rename of INBOX. implementation supports inferior hierarchical names of INBOX, these
are unaffected by a rename of INBOX.
Examples: C: A682 LIST "" * Examples: C: A682 LIST "" *
S: * LIST () "/" blurdybloop S: * LIST () "/" blurdybloop
S: * LIST (\Noselect) "/" foo S: * LIST (\Noselect) "/" foo
S: * LIST () "/" foo/bar S: * LIST () "/" foo/bar
S: A682 OK LIST completed S: A682 OK LIST completed
C: A683 RENAME blurdybloop sarasoop C: A683 RENAME blurdybloop sarasoop
S: A683 OK RENAME completed S: A683 OK RENAME completed
C: A684 RENAME foo zowie C: A684 RENAME foo zowie
S: A684 OK RENAME Completed S: A684 OK RENAME Completed
skipping to change at page 44, line 29 skipping to change at page 44, line 29
\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, originally introduced in [RFC5258], The extended LIST command, originally introduced in [RFC5258],
provides capabilities beyond that of the original IMAP LIST command. provides capabilities beyond that of the original IMAP LIST command.
The extended syntax is being used if one or more of the following The extended syntax is being used if one or more of the following
conditions is true: conditions is true:
1. if the first word after the command name begins with a 1. if the first word after the command name begins with a
parenthesis ("LIST selection options") parenthesis ("LIST selection options");
2. if the second word after the command name begins with a 2. if the second word after the command name begins with a
parenthesis ("multiple mailbox patterns") parenthesis;
3. if the LIST command has more than 2 parameters ("LIST return 3. if the LIST command has more than 2 parameters ("LIST return
options") 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(s). A non-empty MUST match the supplied mailbox name pattern(s). A non-empty
reference name argument is the name of a mailbox or a level of reference name argument is the name of a mailbox or a level of
mailbox hierarchy, and indicates the context in which the mailbox mailbox hierarchy, and indicates the context in which the mailbox
name is interpreted. Clients SHOULD use the empty reference name is interpreted. Clients SHOULD use the empty reference
skipping to change at page 46, line 35 skipping to change at page 46, line 35
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 Any syntactically valid pattern that is not accepted by a server for
mailbox matches if it matches at least one mailbox pattern. If a any reason MUST be silently ignored. I.e. it results in no LIST
mailbox matches more than one pattern, it is still only returned responses and the LIST command still returns tagged OK response.
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 Selection options tell the server to limit the mailbox names that are
selected by the LIST operation. If selection options are used, the selected by the LIST operation. If selection options are used, the
mailboxes returned are those that match both the list of canonical mailboxes returned are those that match both the list of canonical
LIST patterns and the selection options. Unless a particular LIST patterns and the selection options. Unless a particular
selection option provides special rules, the selection options are selection option provides special rules, the selection options are
cumulative: a mailbox that matches the mailbox patterns is selected cumulative: a mailbox that matches the mailbox patterns is selected
only if it also matches all of the selection options. (An example of only if it also matches all of the selection options. (An example of
a selection option with special rules is the RECURSIVEMATCH option.) a selection option with special rules is the RECURSIVEMATCH option.)
skipping to change at page 54, line 36 skipping to change at page 54, line 20
S: * LIST () "/" "Fruit" S: * LIST () "/" "Fruit"
S: * LIST () "/" "Fruit/Apple" S: * LIST () "/" "Fruit/Apple"
S: * LIST () "/" "Fruit/Banana" S: * LIST () "/" "Fruit/Banana"
S: * LIST () "/" "Tofu" S: * LIST () "/" "Tofu"
S: * LIST () "/" "Vegetable" S: * LIST () "/" "Vegetable"
S: * LIST () "/" "Vegetable/Broccoli" S: * LIST () "/" "Vegetable/Broccoli"
S: * LIST () "/" "Vegetable/Corn" S: * LIST () "/" "Vegetable/Corn"
S: A01 OK done S: A01 OK done
2: In the next example, we will see the subscribed mailboxes. This 2: In the next example, we will see the subscribed mailboxes. This
is similar to, but not equivalent with, <LSUB "" "*">. Note is similar to, but not equivalent with now deprecated, <LSUB ""
"*"> (see [RFC3501] for more details on LSUB command). Note
that the mailbox called "Fruit/Peach" is subscribed to, but does that the mailbox called "Fruit/Peach" is subscribed to, but does
not actually exist (perhaps it was deleted while still not actually exist (perhaps it was deleted while still
subscribed). The "Fruit" mailbox is not subscribed to, but it subscribed). The "Fruit" mailbox is not subscribed to, but it
has two subscribed children. The "Vegetable" mailbox is has two subscribed children. The "Vegetable" mailbox is
subscribed and has two children; one of them is subscribed as subscribed and has two children; one of them is subscribed as
well. well.
C: A02 LIST (SUBSCRIBED) "" "*" C: A02 LIST (SUBSCRIBED) "" "*"
S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox" S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
S: * LIST (\Subscribed) "/" "Fruit/Banana" S: * LIST (\Subscribed) "/" "Fruit/Banana"
skipping to change at page 55, line 35 skipping to change at page 55, line 20
S: * LIST (\HasChildren) "/" "Fruit" S: * LIST (\HasChildren) "/" "Fruit"
S: * LIST (\HasNoChildren) "/" "Tofu" S: * LIST (\HasNoChildren) "/" "Tofu"
S: * LIST (\HasChildren) "/" "Vegetable" S: * LIST (\HasChildren) "/" "Vegetable"
S: * LIST (\Remote) "/" "Bread" S: * LIST (\Remote) "/" "Bread"
S: * LIST (\HasChildren \Remote) "/" "Meat" S: * LIST (\HasChildren \Remote) "/" "Meat"
S: A04 OK done S: A04 OK done
5: The following example also requests the server to include 5: The following example also requests the server to include
mailboxes that reside on another server. The server returns mailboxes that reside on another server. The server returns
information about all mailboxes that are subscribed. This is information about all mailboxes that are subscribed. This is
similar to the command <RLSUB "" "*">. We also see the use of similar to the command <RLSUB "" "*"> (see [RFC2193] for more
two selection options. details on RLSUB). We also see the use of two selection
options.
C: A05 LIST (REMOTE SUBSCRIBED) "" "*" C: A05 LIST (REMOTE SUBSCRIBED) "" "*"
S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox" S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
S: * LIST (\Subscribed) "/" "Fruit/Banana" S: * LIST (\Subscribed) "/" "Fruit/Banana"
S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach" S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
S: * LIST (\Subscribed) "/" "Vegetable" S: * LIST (\Subscribed) "/" "Vegetable"
S: * LIST (\Subscribed) "/" "Vegetable/Broccoli" S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
S: * LIST (\Remote \Subscribed) "/" "Bread" S: * LIST (\Remote \Subscribed) "/" "Bread"
S: A05 OK done S: A05 OK done
skipping to change at page 56, line 22 skipping to change at page 56, line 18
S: * LIST () "/" "Fruit/Apple" S: * LIST () "/" "Fruit/Apple"
S: * LIST (\Subscribed) "/" "Fruit/Banana" S: * LIST (\Subscribed) "/" "Fruit/Banana"
S: * LIST () "/" "Tofu" S: * LIST () "/" "Tofu"
S: * LIST (\Subscribed) "/" "Vegetable" S: * LIST (\Subscribed) "/" "Vegetable"
S: * LIST (\Subscribed) "/" "Vegetable/Broccoli" S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
S: * LIST () "/" "Vegetable/Corn" S: * LIST () "/" "Vegetable/Corn"
S: * LIST (\Remote \Subscribed) "/" "Bread" S: * LIST (\Remote \Subscribed) "/" "Bread"
S: * LIST (\Remote) "/" "Meat" S: * LIST (\Remote) "/" "Meat"
S: A06 OK done S: A06 OK done
7: In the following example, the client has specified multiple 7: The following example demonstrates the difference between the
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. \HasChildren attribute and the CHILDINFO extended data item.
Let's assume there is the following hierarchy: Let's assume there is the following hierarchy:
C: C01 LIST "" "*" C: C01 LIST "" "*"
S: * LIST (\Marked \NoInferiors) "/" "inbox" S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST () "/" "Foo" S: * LIST () "/" "Foo"
S: * LIST () "/" "Foo/Bar" S: * LIST () "/" "Foo/Bar"
S: * LIST () "/" "Foo/Baz" S: * LIST () "/" "Foo/Baz"
S: * LIST () "/" "Moo" S: * LIST () "/" "Moo"
skipping to change at page 58, line 4 skipping to change at page 57, line 33
("SUBSCRIBED")) ("SUBSCRIBED"))
S: C04 OK done S: C04 OK done
A2) If we assume instead that the mailbox "Foo" is not part of A2) If we assume instead that the mailbox "Foo" is not part of
the original hierarchy and is not subscribed, the last command the original hierarchy and is not subscribed, the last command
will give this result: will give this result:
C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
S: * LIST (\NonExistent) "/" "Foo" ("CHILDINFO" ("SUBSCRIBED")) S: * LIST (\NonExistent) "/" "Foo" ("CHILDINFO" ("SUBSCRIBED"))
S: C04 OK done S: C04 OK done
B) Now, let's assume that no mailbox is subscribed. In this B) Now, let's assume that no mailbox is subscribed. In this
case, the command <LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"> will case, the command <LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"> will
return no responses, as there are no subscribed children (even return no responses, as there are no subscribed children (even
though "Foo" has children). though "Foo" has children).
C) And finally, suppose that only the mailboxes "Foo" and "Moo" C) And finally, suppose that only the mailboxes "Foo" and "Moo"
are subscribed. In that case, we see this result: are subscribed. In that case, we see this result:
C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" RETURN (CHILDREN) C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" RETURN (CHILDREN)
S: * LIST (\HasChildren \Subscribed) "/" "Foo" S: * LIST (\HasChildren \Subscribed) "/" "Foo"
S: * LIST (\HasNoChildren \Subscribed) "/" "Moo" S: * LIST (\HasNoChildren \Subscribed) "/" "Moo"
S: C04 OK done S: C04 OK done
(which means that the mailbox "Foo" has children, but none of (which means that the mailbox "Foo" has children, but none of
them is subscribed). them is subscribed).
9: The following example demonstrates that the CHILDINFO extended 8: The following example demonstrates that the CHILDINFO extended
data item is returned whether or not children mailboxes match data item is returned whether or not children mailboxes match
the canonical LIST pattern. the canonical LIST pattern.
Let's assume there is the following hierarchy: Let's assume there is the following hierarchy:
C: D01 LIST "" "*" C: D01 LIST "" "*"
S: * LIST (\Marked \NoInferiors) "/" "inbox" S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST () "/" "foo2" S: * LIST () "/" "foo2"
S: * LIST () "/" "foo2/bar1" S: * LIST () "/" "foo2/bar1"
S: * LIST () "/" "foo2/bar2" S: * LIST () "/" "foo2/bar2"
skipping to change at page 59, line 50 skipping to change at page 59, line 32
S: * LIST (\Subscribed) "/" "eps2" ("CHILDINFO" ("SUBSCRIBED")) S: * LIST (\Subscribed) "/" "eps2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\Subscribed) "/" "eps2/mamba" S: * LIST (\Subscribed) "/" "eps2/mamba"
S: * LIST (\Subscribed) "/" "qux2/bar2" S: * LIST (\Subscribed) "/" "qux2/bar2"
S: D03 OK done S: D03 OK done
The LIST responses for mailboxes "foo2", "baz2", and "eps2" The LIST responses for mailboxes "foo2", "baz2", and "eps2"
still have the CHILDINFO extended data item, even though this still have the CHILDINFO extended data item, even though this
information is redundant and the client can determine it by information is redundant and the client can determine it by
itself. itself.
10: The following example shows usage of extended syntax for mailbox 9: The following example shows usage of extended syntax for mailbox
pattern. It also demonstrates that the presence of the pattern. It also demonstrates that the presence of the
CHILDINFO extended data item doesn't necessarily imply CHILDINFO extended data item doesn't necessarily imply
\HasChildren. \HasChildren.
C: a1 LIST "" ("foo") C: a1 LIST "" ("foo")
S: * LIST () "/" foo S: * LIST () "/" foo
S: a1 OK done S: a1 OK done
C: a2 LIST (SUBSCRIBED) "" "foo/*" C: a2 LIST (SUBSCRIBED) "" "foo/*"
S: * LIST (\Subscribed \NonExistent) "/" foo/bar S: * LIST (\Subscribed \NonExistent) "/" foo/bar
S: a2 OK done S: a2 OK done
C: a3 LIST (SUBSCRIBED RECURSIVEMATCH) "" foo RETURN (CHILDREN) C: a3 LIST (SUBSCRIBED RECURSIVEMATCH) "" foo RETURN (CHILDREN)
S: * LIST (\HasNoChildren) "/" foo ("CHILDINFO" ("SUBSCRIBED")) S: * LIST (\HasNoChildren) "/" foo ("CHILDINFO" ("SUBSCRIBED"))
S: a3 OK done S: a3 OK done
11: The following example shows how a server that supports missing 10: The following example shows how a server that supports missing
mailbox hierarchy elements can signal to a client that didn't mailbox hierarchy elements can signal to a client that didn't
specify the RECURSIVEMATCH selection option that there is a specify the RECURSIVEMATCH selection option that there is a
child mailbox that matches the selection criteria. child mailbox that matches the selection criteria.
C: a1 LIST (REMOTE) "" * C: a1 LIST (REMOTE) "" *
S: * LIST () "/" music/rock S: * LIST () "/" music/rock
S: * LIST (\Remote) "/" also/jazz S: * LIST (\Remote) "/" also/jazz
S: a1 OK done S: a1 OK done
C: a2 LIST () "" % C: a2 LIST () "" %
skipping to change at page 60, line 46 skipping to change at page 60, line 29
S: a3 OK done S: a3 OK done
C: a3.1 LIST "" (% music/rock) C: a3.1 LIST "" (% music/rock)
S: * LIST () "/" music/rock S: * LIST () "/" music/rock
S: a3.1 OK done S: a3.1 OK done
Because "music/rock" is the only mailbox under "music", there's Because "music/rock" is the only mailbox under "music", there's
no need for the server to also return "music". However clients no need for the server to also return "music". However clients
must handle both cases. must handle both cases.
12: The following examples show use of STATUS return option. 11: The following examples show use of STATUS return option.
C: A01 LIST "" % RETURN (STATUS (MESSAGES UNSEEN)) C: A01 LIST "" % RETURN (STATUS (MESSAGES UNSEEN))
S: * LIST () "." "INBOX" S: * LIST () "." "INBOX"
S: * STATUS "INBOX" (MESSAGES 17 UNSEEN 16) S: * STATUS "INBOX" (MESSAGES 17 UNSEEN 16)
S: * LIST () "." "foo" S: * LIST () "." "foo"
S: * STATUS "foo" (MESSAGES 30 UNSEEN 29) S: * STATUS "foo" (MESSAGES 30 UNSEEN 29)
S: * LIST (\NoSelect) "." "bar" S: * LIST (\NoSelect) "." "bar"
S: A01 OK List completed. S: A01 OK List completed.
The "bar" mailbox isn't selectable, so it has no STATUS reply. The "bar" mailbox isn't selectable, so it has no STATUS reply.
skipping to change at page 109, line 30 skipping to change at page 108, line 30
password are valid. An IMAP client MUST NOT issue the LOGIN command password are valid. An IMAP client MUST NOT issue the LOGIN command
if the server advertises the LOGINDISABLED capability. if the server advertises the LOGINDISABLED capability.
Other capability names indicate that the server supports an Other capability names indicate that the server supports an
extension, revision, or amendment to the IMAP4rev2 protocol. Server extension, revision, or amendment to the IMAP4rev2 protocol. Server
responses MUST conform to this document until the client issues a responses MUST conform to this document until the client issues a
command that uses the associated capability. command that uses the associated capability.
Capability names MUST either begin with "X" or be informational, Capability names MUST either begin with "X" or be informational,
experimental or standards-track IMAP4rev2 extensions, revisions, or experimental or standards-track IMAP4rev2 extensions, revisions, or
amendments registered with IANA. A server MUST NOT offer amendments registered with IANA. A server SHOULD NOT offer
unregistered or non-standard capability names, unless such names are unregistered or non-standard capability names, unless such names are
prefixed with an "X". prefixed with an "X".
Client implementations SHOULD NOT require any capability name other Client implementations SHOULD NOT require any capability name other
than "IMAP4rev2", and MUST ignore any unknown capability names. than "IMAP4rev2", and MUST ignore any unknown capability names.
A server MAY send capabilities automatically, by using the CAPABILITY A server MAY send capabilities automatically, by using the CAPABILITY
response code in the initial PREAUTH or OK responses, and by sending response code in the initial PREAUTH or OK responses, and by sending
an updated CAPABILITY response code in the tagged OK response as part an updated CAPABILITY response code in the tagged OK response as part
of a successful authentication. It is unnecessary for a client to of a successful authentication. It is unnecessary for a client to
skipping to change at page 113, line 17 skipping to change at page 112, line 17
hierarchy exists; the name is a "flat" name. hierarchy exists; the name is a "flat" name.
The name represents an unambiguous left-to-right hierarchy, and MUST The name represents an unambiguous left-to-right hierarchy, and MUST
be valid for use as a reference in LIST command. Unless \Noselect or be valid for use as a reference in LIST command. Unless \Noselect or
\NonExistent is indicated, the name MUST also be valid as an argument \NonExistent is indicated, the name MUST also be valid as an argument
for commands, such as SELECT, that accept mailbox names. for commands, such as SELECT, that accept mailbox names.
The name might be followed by an OPTIONAL series of extended fields, The name might be followed by an OPTIONAL series of extended fields,
a parenthesized list of tagged data (also referred to as "extended a parenthesized list of tagged data (also referred to as "extended
data item"). The first element of an extended field is a tag, which data item"). The first element of an extended field is a tag, which
identifies the type of data. The server MAY return data in the identifies the type of data. [RFC5258] specified requirements on tag
extended fields that was not directly solicited by the client in the registration, in particular it said that "Tags MUST be registered
corresponding LIST command. For example, the client can enable extra with IANA". This document doesn't change that. See Section 9.5 of
extended fields by using another IMAP extension that make use of the [RFC5258] for the registration template. The server MAY return data
extended LIST responses. The client MUST ignore all extended fields in the extended fields that was not directly solicited by the client
it doesn't recognize. in the corresponding LIST command. For example, the client can
enable extra extended fields by using another IMAP extension that
make use of the extended LIST responses. The client MUST ignore all
extended fields it doesn't recognize.
Example: S: * LIST (\Noselect) "/" ~/Mail/foo Example: S: * LIST (\Noselect) "/" ~/Mail/foo
Example: S: * LIST (\Marked) ":" Tables (tablecloth (("edge" "lacy") Example: S: * LIST (\Marked) ":" Tables (tablecloth (("edge" "lacy")
("color" "red")) Sample "text") ("color" "red")) Sample "text")
S: * LIST () ":" Tables:new (tablecloth ("edge" "lacy") S: * LIST () ":" Tables:new (tablecloth ("edge" "lacy")
Sample ("text" "more text")) Sample ("text" "more text"))
7.2.4. NAMESPACE Response 7.2.4. NAMESPACE Response
skipping to change at page 134, line 32 skipping to change at page 133, line 40
partial-range = number ["." nz-number] partial-range = number ["." nz-number]
; Copied from RFC 5092 (IMAP URL) ; Copied from RFC 5092 (IMAP URL)
partial = "<" number "." nz-number ">" partial = "<" number "." nz-number ">"
; Partial FETCH request. 0-based offset of ; Partial FETCH request. 0-based offset of
; the first octet, followed by the number of octets ; the first octet, followed by the number of octets
; in the fragment. ; in the fragment.
password = astring password = astring
patterns = "(" list-mailbox *(SP list-mailbox) ")" patterns = "(" list-mailbox ")"
; [RFC5258] supports multiple patterns,
; but this document only requires one
; to be supported.
; If the server is also implementing
; [RFC5258], "patterns" syntax from that
; document must be followed.
quoted = DQUOTE *QUOTED-CHAR DQUOTE quoted = DQUOTE *QUOTED-CHAR DQUOTE
QUOTED-CHAR = <any TEXT-CHAR except quoted-specials> / QUOTED-CHAR = <any TEXT-CHAR except quoted-specials> /
"\" quoted-specials / UTF8-2 / UTF8-3 / UTF8-4 "\" quoted-specials / UTF8-2 / UTF8-3 / UTF8-4
quoted-specials = DQUOTE / "\" quoted-specials = DQUOTE / "\"
rename = "RENAME" SP mailbox SP mailbox rename = "RENAME" SP mailbox SP mailbox
; Use of INBOX as a destination gives a NO error ; Use of INBOX as a destination gives a NO error
skipping to change at page 148, line 35 skipping to change at page 147, line 39
attributes/imap-mailbox-name-attributes.xhtml>. attributes/imap-mailbox-name-attributes.xhtml>.
[CHARSET-REG] [CHARSET-REG]
IANA, "Character Set Registrations", May 2015, IANA, "Character Set Registrations", May 2015,
<https://www.iana.org/assignments/charset-reg/charset- <https://www.iana.org/assignments/charset-reg/charset-
reg.xhtml>. reg.xhtml>.
13.3. Informative References (historical aspects of IMAP and related 13.3. Informative References (historical aspects of IMAP and related
protocols) protocols)
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
<https://www.rfc-editor.org/info/rfc3501>.
[IMAP-COMPAT] [IMAP-COMPAT]
Crispin, M., "IMAP4 Compatibility with IMAP2bis", Crispin, M., "IMAP4 Compatibility with IMAP2bis",
RFC 2061, December 1996, RFC 2061, December 1996,
<http://www.rfc-editor.org/info/rfc2061>. <http://www.rfc-editor.org/info/rfc2061>.
[IMAP-HISTORICAL] [IMAP-HISTORICAL]
Crispin, M., "IMAP4 Compatibility with IMAP2 and Crispin, M., "IMAP4 Compatibility with IMAP2 and
IMAP2bis", RFC 1732, December 1994, IMAP2bis", RFC 1732, December 1994,
<http://www.rfc-editor.org/info/rfc1732>. <http://www.rfc-editor.org/info/rfc1732>.
skipping to change at page 149, line 24 skipping to change at page 148, line 33
Appendix A. Backward compatibility with IMAP4rev1 Appendix A. Backward compatibility with IMAP4rev1
An implementation that wants to remain compatible with IMAP4rev1 can An implementation that wants to remain compatible with IMAP4rev1 can
advertise both IMAP4rev1 and IMAP4rev2 in its CAPABILITY response/ advertise both IMAP4rev1 and IMAP4rev2 in its CAPABILITY response/
response code. While some IMAP4rev1 responses were removed in response code. While some IMAP4rev1 responses were removed in
IMAP4rev2, their presence will not break IMAP4rev2-only clients. IMAP4rev2, their presence will not break IMAP4rev2-only clients.
If both IMAP4rev1 and IMAP4rev2 are advertised, an IMAP client that If both IMAP4rev1 and IMAP4rev2 are advertised, an IMAP client that
wants to use IMAP4rev2 MUST issue an "ENABLE IMAP4rev2" command. wants to use IMAP4rev2 MUST issue an "ENABLE IMAP4rev2" command.
Servers advertising both IMAP4rev1 and IMAP4rev2 SHOULD NOT generate Servers advertising both IMAP4rev1 and IMAP4rev2 MUST NOT generate
UTF-8 quoted strings unless the client has issued "ENABLE IMAP4rev2". UTF-8 quoted strings unless the client has issued "ENABLE IMAP4rev2".
Consider implementation of mechanisms described or referenced in Consider implementation of mechanisms described or referenced in
[IMAP-UTF-8] to achieve this goal. [IMAP-UTF-8] to achieve this goal.
Servers advertising both IMAP4rev1 and IMAP4rev2, and clients Servers advertising both IMAP4rev1 and IMAP4rev2, and clients
intending to be compatible with IMAP4rev1 servers MUST be compatible intending to be compatible with IMAP4rev1 servers MUST be compatible
with the international mailbox naming convention described in the with the international mailbox naming convention described in the
following subsection. following subsection.
A.1. Mailbox International Naming Convention for compatibility with A.1. Mailbox International Naming Convention for compatibility with
skipping to change at page 151, line 28 skipping to change at page 150, line 34
Appendix B. Backward compatibility with BINARY extension Appendix B. Backward compatibility with BINARY extension
IMAP4rev2 is incorporates subset of functionality provided by the IMAP4rev2 is incorporates subset of functionality provided by the
BINARY extension [RFC3516], in particular it includes additional BINARY extension [RFC3516], in particular it includes additional
FETCH items (BINARY, BINARY.PEEK and BINARY.SIZE), but not extensions FETCH items (BINARY, BINARY.PEEK and BINARY.SIZE), but not extensions
to the APPEND command. IMAP4rev2 implementations that supports full to the APPEND command. IMAP4rev2 implementations that supports full
RFC 3516 functionality need to also advertise the BINARY token in the RFC 3516 functionality need to also advertise the BINARY token in the
CAPABILITY response. CAPABILITY response.
Appendix C. Changes from RFC 3501 / IMAP4rev1 Appendix C. Backward compatibility with LIST-EXTENDED extension
IMAP4rev2 is incorporates most of functionality provided by the LIST-
EXTENDED extension [RFC5258]. In particular, multiple mailbox
patterns syntax is not supported in IMAP4rev2, unless LIST-EXTENDED
capability is also advertised in CAPABILITY response/response code.
Appendix D. Changes from RFC 3501 / IMAP4rev1
The following is the plan for remaining changes. The plan might The following is the plan for remaining changes. The plan might
change over time. change over time.
1. Revise IANA registration of IMAP extensions and give advice on 1. Revise IANA registration of IMAP extensions and give advice on
use of "X-" convention. use of "X-" convention.
2. Allow word-based searching (as per Chris Newman)? Need to 2. Allow word-based searching (as per Chris Newman)? Need to
discuss header field search, where exact/substring match is still discuss header field search, where exact/substring match is still
required for interoperability. required for interoperability.
3. Add a section on other recommended extensions? 3. Add a section on other recommended extensions?
The following changes were already done: The following changes were already done:
1. Fold in the following extensions/RFC: RFC 5530 (IMAP Response 1. Fold in the following extensions/RFC: RFC 5530 (IMAP Response
Codes), UIDPLUS, ENABLE, ESEARCH, SPECIAL-USE (list of new Codes), UIDPLUS, ENABLE, ESEARCH, SPECIAL-USE (list of new
mailbox attributes is done), LITERAL-, NAMESPACE, SASL-IR, IDLE, mailbox attributes), LITERAL-, NAMESPACE, SASL-IR, LIST-STATUS,
MOVE. SEARCHRES, IDLE, MOVE.
2. Add CLOSED response code (from CONDSTORE). 2. Add CLOSED response code (from CONDSTORE).
3. Add support for $Phishing, $Junk, $NonJunk, $MDNSent and 3. Add support for $Phishing, $Junk, $NonJunk, $MDNSent and
$Forwarded IMAP keywords. Add more examples showing their use? $Forwarded IMAP keywords. Add more examples showing their use?
4. Require all unsolicited FETCH updates to include UID. 4. Require all unsolicited FETCH updates to include UID.
5. Update recommendations on TLS ciphers to match UTA WG work (as 5. Update recommendations on TLS ciphers to match UTA WG work (as
per RFC 8314, RFC 7525 and RFC 7817). per RFC 8314, RFC 7525 and RFC 7817).
6. Possibly fold in the following extensions/RFC: Base LIST-EXTENDED 6. Fold in the following extensions/RFC: Base LIST-EXTENDED syntax
syntax plus deprecate LSUB (replace it with LIST \Subscribed) plus deprecate LSUB (replace it with LIST \Subscribed) minus the
minus the requirement to support multiple list patterns, STATUS- requirement to support multiple list patterns, BINARY (only the
in-LIST, SEARCHRES, BINARY (only the FETCH changes on leaf body FETCH changes on leaf body part and make APPEND related ones
part and make APPEND related ones optional. See the mailing list optional. See the mailing list discussion).
discussion).
7. Add STATUS SIZE (total mailbox size). Add STATUS DELETED (number 7. Add STATUS SIZE (total mailbox size). Add STATUS DELETED (number
of messages with \Deleted flag set). of messages with \Deleted flag set).
8. Drop UTF-7, all mailboxes are always in UTF-8. 8. Drop UTF-7, all mailboxes are always in UTF-8.
The following changes since RFC 3501 were done so far: The following changes since RFC 3501 were done so far:
1. Folded in IMAP UNSELECT (RFC 3691), UIDPLUS (RFC 4315), ESEARCH 1. Folded in IMAP UNSELECT (RFC 3691), UIDPLUS (RFC 4315), ESEARCH
(RFC 4731), ENABLE (RFC 5161), IDLE (RFC 2177), SASL-IR (RFC (RFC 4731), SEARCHRES (RFC 5182), ENABLE (RFC 5161), IDLE (RFC
4959), LIST-STATUS (RFC 5819) and MOVE (RFC 6851) extensions. 2177), SASL-IR (RFC 4959), LIST-STATUS (RFC 5819) and MOVE (RFC
Also folded RFC 5530 and FETCH side of the BINARY extension (RFC 6851) extensions. Also folded RFC 5530 and FETCH side of the
3516). BINARY extension (RFC 3516).
2. Clarified that server should decode parameter value 2. Clarified that server should decode parameter value
continuations as described in [RFC2231]. This requirement was continuations as described in [RFC2231]. This requirement was
hidden in RFC 2231 itself. hidden in RFC 2231 itself.
3. SEARCH command now requires to return ESEARCH response (SEARCH 3. SEARCH command now requires to return ESEARCH response (SEARCH
response is now deprecated). response is now deprecated).
4. Added CLOSED response code from RFC 7162. SELECT/EXAMINE when a 4. Added CLOSED response code from RFC 7162. SELECT/EXAMINE when a
mailbox is already selected now require for the CLOSED response mailbox is already selected now require for the CLOSED response
skipping to change at page 153, line 37 skipping to change at page 152, line 48
16. LSUB command was deprecated. Clients should use LIST 16. LSUB command was deprecated. Clients should use LIST
(SUBSCRIBED) instead. (SUBSCRIBED) instead.
17. resp-text ABNF non terminal was updated to allow for empty text. 17. resp-text ABNF non terminal was updated to allow for empty text.
18. IDLE command can now return updates not related to the currently 18. IDLE command can now return updates not related to the currently
selected mailbox state. selected mailbox state.
19. All unsolicited FETCH updates are required to include UID. 19. All unsolicited FETCH updates are required to include UID.
Appendix D. Acknowledgement 20. Clarified that client implementations MUST ignore response codes
that they do not recognize. (Change from a SHOULD to a MUST.)
Appendix E. Acknowledgement
Earlier versions of this document were edited by Mark Crispin. Earlier versions of this document were edited by Mark Crispin.
Sadly, he is no longer available to help with this work. Editors of Sadly, he is no longer available to help with this work. Editors of
this revisions are hoping that Mark would have approved. this revisions are hoping that Mark would have approved.
Chris Newman has contributed text on I18N and use of UTF-8 in Chris Newman has contributed text on I18N and use of UTF-8 in
messages and mailbox names. messages and mailbox names.
Thank you to Tony Hansen for helping with the index generation. Thank you to Tony Hansen for helping with the index generation.
Thank you to Timo Sirainen, Bron Gondwana and Arnt Gulbrandsen for Thank you to Timo Sirainen, Bron Gondwana and Arnt Gulbrandsen for
skipping to change at page 154, line 18 skipping to change at page 153, line 35
Index Index
$ $
$Forwarded (predefined flag) 12 $Forwarded (predefined flag) 12
$Junk (predefined flag) 12 $Junk (predefined flag) 12
$MDNSent (predefined flag) 12 $MDNSent (predefined flag) 12
$NotJunk (predefined flag) 12 $NotJunk (predefined flag) 12
$Phishing (predefined flag) 12 $Phishing (predefined flag) 12
+ +
+FLAGS <flag list> 91 +FLAGS <flag list> 90
+FLAGS.SILENT <flag list> 91 +FLAGS.SILENT <flag list> 90
- -
-FLAGS <flag list> 91 -FLAGS <flag list> 90
-FLAGS.SILENT <flag list> 91 -FLAGS.SILENT <flag list> 90
A A
ALERT (response code) 98 ALERT (response code) 97
ALL (fetch item) 87 ALL (fetch item) 86
ALL (search key) 77 ALL (search key) 76
ALL (search result option) 75 ALL (search result option) 74
ALREADYEXISTS (response code) 98 ALREADYEXISTS (response code) 97
ANSWERED (search key) 77 ANSWERED (search key) 76
APPEND (command) 67 APPEND (command) 66
APPENDUID (response code) 98 APPENDUID (response code) 97
AUTHENTICATE (command) 29 AUTHENTICATE (command) 29
AUTHENTICATIONFAILED (response code) 99 AUTHENTICATIONFAILED (response code) 98
AUTHORIZATIONFAILED (response code) 99 AUTHORIZATIONFAILED (response code) 98
B B
BAD (response) 107 BAD (response) 106
BADCHARSET (response code) 100 BADCHARSET (response code) 99
BCC <string> (search key) 77 BCC <string> (search key) 76
BEFORE <date> (search key) 77 BEFORE <date> (search key) 76
BINARY.PEEK[<section-binary>]<<partial>> (fetch item) 87 BINARY.PEEK[<section-binary>]<<partial>> (fetch item) 86
BINARY.SIZE[<section-binary>] (fetch item) 87 BINARY.SIZE[<section-binary>] (fetch item) 86
BINARY.SIZE[<section-binary>] (fetch result) 117 BINARY.SIZE[<section-binary>] (fetch result) 116
BINARY[<section-binary>]<<number>> (fetch result) 116 BINARY[<section-binary>]<<number>> (fetch result) 115
BINARY[<section-binary>]<<partial>> (fetch item) 87 BINARY[<section-binary>]<<partial>> (fetch item) 86
BODY (fetch item) 88 BODY (fetch item) 87
BODY (fetch result) 117 BODY (fetch result) 116
BODY <string> (search key) 77 BODY <string> (search key) 76
BODY.PEEK[<section>]<<partial>> (fetch item) 90 BODY.PEEK[<section>]<<partial>> (fetch item) 89
BODYSTRUCTURE (fetch item) 90 BODYSTRUCTURE (fetch item) 89
BODYSTRUCTURE (fetch result) 118 BODYSTRUCTURE (fetch result) 117
BODY[<section>]<<origin octet>> (fetch result) 117 BODY[<section>]<<origin octet>> (fetch result) 116
BODY[<section>]<<partial>> (fetch item) 88 BODY[<section>]<<partial>> (fetch item) 87
BYE (response) 107 BYE (response) 106
Body Structure (message attribute) 14 Body Structure (message attribute) 14
C C
CANNOT (response code) 100 CANNOT (response code) 99
CAPABILITY (command) 25 CAPABILITY (command) 25
CAPABILITY (response code) 100 CAPABILITY (response code) 99
CAPABILITY (response) 108 CAPABILITY (response) 107
CC <string> (search key) 77 CC <string> (search key) 76
CLIENTBUG (response code) 100 CLIENTBUG (response code) 99
CLOSE (command) 72 CLOSE (command) 71
CLOSED (response code) 100 CLOSED (response code) 99
CONTACTADMIN (response code) 101 CONTACTADMIN (response code) 100
COPY (command) 91 COPY (command) 90
COPYUID (response code) 101 COPYUID (response code) 100
CORRUPTION (response code) 101 CORRUPTION (response code) 100
COUNT (search result option) 75 COUNT (search result option) 74
CREATE (command) 38 CREATE (command) 38
D D
DELETE (command) 39 DELETE (command) 39
DELETED (search key) 77 DELETED (search key) 76
DELETED (status item) 67 DELETED (status item) 66
DRAFT (search key) 77 DRAFT (search key) 76
E E
ENABLE (command) 33 ENABLE (command) 33
ENVELOPE (fetch item) 90 ENVELOPE (fetch item) 89
ENVELOPE (fetch result) 120 ENVELOPE (fetch result) 119
ESEARCH (response) 114 ESEARCH (response) 113
EXAMINE (command) 37 EXAMINE (command) 37
EXPIRED (response code) 102 EXPIRED (response code) 101
EXPUNGE (command) 73 EXPUNGE (command) 72
EXPUNGE (response) 115 EXPUNGE (response) 114
EXPUNGEISSUED (response code) 102 EXPUNGEISSUED (response code) 101
Envelope Structure (message attribute) 14 Envelope Structure (message attribute) 14
F F
FAST (fetch item) 87 FAST (fetch item) 86
FETCH (command) 86 FETCH (command) 85
FETCH (response) 116 FETCH (response) 115
FLAGGED (search key) 77 FLAGGED (search key) 76
FLAGS (fetch item) 90 FLAGS (fetch item) 89
FLAGS (fetch result) 121 FLAGS (fetch result) 121
FLAGS (response) 114 FLAGS (response) 113
FLAGS <flag list> (store command data item) 91 FLAGS <flag list> (store command data item) 90
FLAGS.SILENT <flag list> (store command data item) 91 FLAGS.SILENT <flag list> (store command data item) 90
FROM <string> (search key) 77 FROM <string> (search key) 76
FULL (fetch item) 87 FULL (fetch item) 86
Flags (message attribute) 11 Flags (message attribute) 11
H H
HASCHILDREN (response code) 102 HASCHILDREN (response code) 101
HEADER (part specifier) 88 HEADER (part specifier) 87
HEADER <field-name> <string> (search key) 77 HEADER <field-name> <string> (search key) 76
HEADER.FIELDS (part specifier) 88 HEADER.FIELDS (part specifier) 87
HEADER.FIELDS.NOT (part specifier) 88 HEADER.FIELDS.NOT (part specifier) 87
I I
IDLE (command) 70 IDLE (command) 69
INTERNALDATE (fetch item) 90 INTERNALDATE (fetch item) 89
INTERNALDATE (fetch result) 121 INTERNALDATE (fetch result) 121
INUSE (response code) 102 INUSE (response code) 101
Internal Date (message attribute) 13 Internal Date (message attribute) 13
K K
KEYWORD <flag> (search key) 78 KEYWORD <flag> (search key) 77
Keyword (type of flag) 12 Keyword (type of flag) 12
L L
LARGER <n> (search key) 78 LARGER <n> (search key) 77
LIMIT (response code) 103 LIMIT (response code) 102
LIST (command) 43 LIST (command) 43
LIST (response) 109 LIST (response) 108
LOGOUT (command) 27 LOGOUT (command) 27
M M
MAX (search result option) 75 MAX (search result option) 74
MAY (specification requirement term) 5 MAY (specification requirement term) 5
MESSAGES (status item) 67 MESSAGES (status item) 66
MIME (part specifier) 89 MIME (part specifier) 88
MIN (search result option) 75 MIN (search result option) 74
MOVE (command) 92 MOVE (command) 91
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) 61 NAMESPACE (command) 61
NAMESPACE (response) 113 NAMESPACE (response) 112
NO (response) 106 NO (response) 105
NONEXISTENT (response code) 103 NONEXISTENT (response code) 102
NOOP (command) 26 NOOP (command) 26
NOPERM (response code) 103 NOPERM (response code) 102
NOT <search-key> (search key) 78 NOT <search-key> (search key) 77
NOT RECOMMENDED (specification requirement term) 5 NOT RECOMMENDED (specification requirement term) 5
O O
OK (response) 106 OK (response) 105
ON <date> (search key) 78 ON <date> (search key) 77
OPTIONAL (specification requirement term) 5 OPTIONAL (specification requirement term) 5
OR <search-key1> <search-key2> (search key) 78 OR <search-key1> <search-key2> (search key) 77
OVERQUOTA (response code) 103 OVERQUOTA (response code) 102
P P
PARSE (response code) 103 PARSE (response code) 102
PERMANENTFLAGS (response code) 104 PERMANENTFLAGS (response code) 103
PREAUTH (response) 107 PREAUTH (response) 106
PRIVACYREQUIRED (response code) 104 PRIVACYREQUIRED (response code) 103
Permanent Flag (class of flag) 13 Permanent Flag (class of flag) 13
Predefined keywords 12 Predefined keywords 12
R R
READ-ONLY (response code) 104 READ-ONLY (response code) 103
READ-WRITE (response code) 104 READ-WRITE (response code) 103
RECOMMENDED (specification requirement term) 5 RECOMMENDED (specification requirement term) 5
RENAME (command) 40 RENAME (command) 40
REQUIRED (specification requirement term) 5 REQUIRED (specification requirement term) 5
RFC822.SIZE (fetch item) 90 RFC822.SIZE (fetch item) 89
RFC822.SIZE (fetch result) 122 RFC822.SIZE (fetch result) 121
S S
SAVE (search result option) 75 SAVE (search result option) 74
SEARCH (command) 74 SEARCH (command) 73
SEEN (search key) 78 SEEN (search key) 77
SELECT (command) 35 SELECT (command) 35
SENTBEFORE <date> (search key) 78 SENTBEFORE <date> (search key) 77
SENTON <date> (search key) 78 SENTON <date> (search key) 77
SENTSINCE <date> (search key) 78 SENTSINCE <date> (search key) 77
SERVERBUG (response code) 104 SERVERBUG (response code) 103
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) 78 SINCE <date> (search key) 77
SIZE (status item) 67 SIZE (status item) 66
SMALLER <n> (search key) 78 SMALLER <n> (search key) 77
STARTTLS (command) 28 STARTTLS (command) 28
STATUS (command) 66 STATUS (command) 65
STATUS (response) 113 STATUS (response) 113
STORE (command) 90 STORE (command) 89
SUBJECT <string> (search key) 78 SUBJECT <string> (search key) 77
SUBSCRIBE (command) 42 SUBSCRIBE (command) 42
Session Flag (class of flag) 13 Session Flag (class of flag) 13
System Flag (type of flag) 11 System Flag (type of flag) 11
T T
TEXT (part specifier) 88 TEXT (part specifier) 87
TEXT <string> (search key) 78 TEXT <string> (search key) 77
TO <string> (search key) 78 TO <string> (search key) 77
TRYCREATE (response code) 105 TRYCREATE (response code) 104
U U
UID (command) 94 UID (command) 93
UID (fetch item) 90 UID (fetch item) 89
UID (fetch result) 122 UID (fetch result) 121
UID <sequence set> (search key) 79 UID <sequence set> (search key) 78
UIDNEXT (response code) 105 UIDNEXT (response code) 104
UIDNEXT (status item) 67 UIDNEXT (status item) 66
UIDNOTSTICKY (response code) 105 UIDNOTSTICKY (response code) 104
UIDVALIDITY (response code) 105 UIDVALIDITY (response code) 104
UIDVALIDITY (status item) 67 UIDVALIDITY (status item) 66
UNANSWERED (search key) 79 UNANSWERED (search key) 78
UNAVAILABLE (response code) 105 UNAVAILABLE (response code) 104
UNDELETED (search key) 79 UNDELETED (search key) 78
UNDRAFT (search key) 79 UNDRAFT (search key) 78
UNFLAGGED (search key) 79 UNFLAGGED (search key) 78
UNKEYWORD <flag> (search key) 79 UNKEYWORD <flag> (search key) 78
UNKNOWN-CTE (response code) 106 UNKNOWN-CTE (response code) 105
UNSEEN (search key) 79 UNSEEN (search key) 78
UNSEEN (status item) 67 UNSEEN (status item) 66
UNSELECT (command) 73 UNSELECT (command) 72
UNSUBSCRIBE (command) 43 UNSUBSCRIBE (command) 43
Unique Identifier (UID) (message attribute) 9 Unique Identifier (UID) (message attribute) 9
X X
X<atom> (command) 96 X<atom> (command) 95
[ [
[RFC-5322] Size (message attribute) 13 [RFC-5322] Size (message attribute) 13
\ \
\All (mailbox name attribute) 111 \All (mailbox name attribute) 110
\Answered (system flag) 11 \Answered (system flag) 11
\Archive (mailbox name attribute) 111 \Archive (mailbox name attribute) 110
\Deleted (system flag) 12 \Deleted (system flag) 12
\Draft (system flag) 12 \Draft (system flag) 12
\Drafts (mailbox name attribute) 112 \Drafts (mailbox name attribute) 111
\Flagged (mailbox name attribute) 112 \Flagged (mailbox name attribute) 111
\Flagged (system flag) 11 \Flagged (system flag) 11
\HasChildren (mailbox name attribute) 110 \HasChildren (mailbox name attribute) 109
\HasNoChildren (mailbox name attribute) 111 \HasNoChildren (mailbox name attribute) 110
\Junk (mailbox name attribute) 112 \Junk (mailbox name attribute) 111
\Marked (mailbox name attribute) 111 \Marked (mailbox name attribute) 110
\Noinferiors (mailbox name attribute) 110 \Noinferiors (mailbox name attribute) 109
\NonExistent (mailbox name attribute) 110 \NonExistent (mailbox name attribute) 109
\Noselect (mailbox name attribute) 110 \Noselect (mailbox name attribute) 109
\Recent (system flag) 12 \Recent (system flag) 12
\Remote (mailbox name attribute) 111 \Remote (mailbox name attribute) 110
\Seen (system flag) 11 \Seen (system flag) 11
\Sent (mailbox name attribute) 112 \Sent (mailbox name attribute) 111
\Subscribed (mailbox name attribute) 111 \Subscribed (mailbox name attribute) 110
\Trash (mailbox name attribute) 112 \Trash (mailbox name attribute) 111
\Unmarked (mailbox name attribute) 111 \Unmarked (mailbox name attribute) 110
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. 76 change blocks. 
266 lines changed or deleted 282 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/