< draft-ietf-extra-imap4rev2-08.txt   draft-ietf-extra-imap4rev2-09.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: May 22, 2020 November 19, 2019 Expires: May 27, 2020 November 24, 2019
INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev2 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev2
draft-ietf-extra-imap4rev2-08 draft-ietf-extra-imap4rev2-09
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 May 22, 2020. This Internet-Draft will expire on May 27, 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 . . . . . . . . . . . . . . . . . . . 32 6.3.1. ENABLE Command . . . . . . . . . . . . . . . . . . . 32
6.3.2. SELECT Command . . . . . . . . . . . . . . . . . . . 34 6.3.2. SELECT Command . . . . . . . . . . . . . . . . . . . 34
6.3.3. EXAMINE Command . . . . . . . . . . . . . . . . . . . 35 6.3.3. EXAMINE Command . . . . . . . . . . . . . . . . . . . 35
6.3.4. CREATE Command . . . . . . . . . . . . . . . . . . . 36 6.3.4. CREATE Command . . . . . . . . . . . . . . . . . . . 36
6.3.5. DELETE Command . . . . . . . . . . . . . . . . . . . 37 6.3.5. DELETE Command . . . . . . . . . . . . . . . . . . . 37
6.3.6. RENAME Command . . . . . . . . . . . . . . . . . . . 39 6.3.6. RENAME Command . . . . . . . . . . . . . . . . . . . 39
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. NAMESPACE Command . . . . . . . . . . . . . . . . . . 57 6.3.10. NAMESPACE Command . . . . . . . . . . . . . . . . . . 58
6.3.11. STATUS Command . . . . . . . . . . . . . . . . . . . 62 6.3.11. STATUS Command . . . . . . . . . . . . . . . . . . . 63
6.3.12. APPEND Command . . . . . . . . . . . . . . . . . . . 63 6.3.12. APPEND Command . . . . . . . . . . . . . . . . . . . 64
6.3.13. IDLE Command . . . . . . . . . . . . . . . . . . . . 66 6.3.13. IDLE Command . . . . . . . . . . . . . . . . . . . . 67
6.4. Client Commands - Selected State . . . . . . . . . . . . 68 6.4. Client Commands - Selected State . . . . . . . . . . . . 69
6.4.1. CLOSE Command . . . . . . . . . . . . . . . . . . . . 68 6.4.1. CLOSE Command . . . . . . . . . . . . . . . . . . . . 69
6.4.2. UNSELECT Command . . . . . . . . . . . . . . . . . . 69 6.4.2. UNSELECT Command . . . . . . . . . . . . . . . . . . 70
6.4.3. EXPUNGE Command . . . . . . . . . . . . . . . . . . . 69 6.4.3. EXPUNGE Command . . . . . . . . . . . . . . . . . . . 70
6.4.4. SEARCH Command . . . . . . . . . . . . . . . . . . . 70 6.4.4. SEARCH Command . . . . . . . . . . . . . . . . . . . 71
6.4.5. FETCH Command . . . . . . . . . . . . . . . . . . . . 76 6.4.5. FETCH Command . . . . . . . . . . . . . . . . . . . . 77
6.4.6. STORE Command . . . . . . . . . . . . . . . . . . . . 80 6.4.6. STORE Command . . . . . . . . . . . . . . . . . . . . 81
6.4.7. COPY Command . . . . . . . . . . . . . . . . . . . . 81 6.4.7. COPY Command . . . . . . . . . . . . . . . . . . . . 82
6.4.8. MOVE Command . . . . . . . . . . . . . . . . . . . . 82 6.4.8. MOVE Command . . . . . . . . . . . . . . . . . . . . 83
6.4.9. UID Command . . . . . . . . . . . . . . . . . . . . . 84 6.4.9. UID Command . . . . . . . . . . . . . . . . . . . . . 85
6.5. Client Commands - Experimental/Expansion . . . . . . . . 85 6.5. Client Commands - Experimental/Expansion . . . . . . . . 86
6.5.1. X<atom> Command . . . . . . . . . . . . . . . . . . . 85 6.5.1. X<atom> Command . . . . . . . . . . . . . . . . . . . 86
7. Server Responses . . . . . . . . . . . . . . . . . . . . . . 86 7. Server Responses . . . . . . . . . . . . . . . . . . . . . . 87
7.1. Server Responses - Status Responses . . . . . . . . . . . 87 7.1. Server Responses - Status Responses . . . . . . . . . . . 88
7.1.1. OK Response . . . . . . . . . . . . . . . . . . . . . 95 7.1.1. OK Response . . . . . . . . . . . . . . . . . . . . . 96
7.1.2. NO Response . . . . . . . . . . . . . . . . . . . . . 95 7.1.2. NO Response . . . . . . . . . . . . . . . . . . . . . 96
7.1.3. BAD Response . . . . . . . . . . . . . . . . . . . . 96 7.1.3. BAD Response . . . . . . . . . . . . . . . . . . . . 97
7.1.4. PREAUTH Response . . . . . . . . . . . . . . . . . . 96 7.1.4. PREAUTH Response . . . . . . . . . . . . . . . . . . 97
7.1.5. BYE Response . . . . . . . . . . . . . . . . . . . . 97 7.1.5. BYE Response . . . . . . . . . . . . . . . . . . . . 98
7.2. Server Responses - Server and Mailbox Status . . . . . . 97 7.2. Server Responses - Server and Mailbox Status . . . . . . 98
7.2.1. The ENABLED Response . . . . . . . . . . . . . . . . 97 7.2.1. The ENABLED Response . . . . . . . . . . . . . . . . 98
7.2.2. CAPABILITY Response . . . . . . . . . . . . . . . . . 98 7.2.2. CAPABILITY Response . . . . . . . . . . . . . . . . . 99
7.2.3. LIST Response . . . . . . . . . . . . . . . . . . . . 99 7.2.3. LIST Response . . . . . . . . . . . . . . . . . . . . 100
7.2.4. NAMESPACE Response . . . . . . . . . . . . . . . . . 102 7.2.4. NAMESPACE Response . . . . . . . . . . . . . . . . . 103
7.2.5. STATUS Response . . . . . . . . . . . . . . . . . . . 102 7.2.5. STATUS Response . . . . . . . . . . . . . . . . . . . 103
7.2.6. ESEARCH Response . . . . . . . . . . . . . . . . . . 103 7.2.6. ESEARCH Response . . . . . . . . . . . . . . . . . . 104
7.2.7. FLAGS Response . . . . . . . . . . . . . . . . . . . 103 7.2.7. FLAGS Response . . . . . . . . . . . . . . . . . . . 104
7.3. Server Responses - Mailbox Size . . . . . . . . . . . . . 104 7.3. Server Responses - Mailbox Size . . . . . . . . . . . . . 105
7.3.1. EXISTS Response . . . . . . . . . . . . . . . . . . . 104 7.3.1. EXISTS Response . . . . . . . . . . . . . . . . . . . 105
7.4. Server Responses - Message Status . . . . . . . . . . . . 104 7.4. Server Responses - Message Status . . . . . . . . . . . . 105
7.4.1. EXPUNGE Response . . . . . . . . . . . . . . . . . . 104 7.4.1. EXPUNGE Response . . . . . . . . . . . . . . . . . . 105
7.4.2. FETCH Response . . . . . . . . . . . . . . . . . . . 105 7.4.2. FETCH Response . . . . . . . . . . . . . . . . . . . 106
7.5. Server Responses - Command Continuation Request . . . . . 111 7.5. Server Responses - Command Continuation Request . . . . . 112
8. Sample IMAP4rev2 connection . . . . . . . . . . . . . . . . . 111 8. Sample IMAP4rev2 connection . . . . . . . . . . . . . . . . . 112
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 112 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 113
10. Author's Note . . . . . . . . . . . . . . . . . . . . . . . . 129 10. Author's Note . . . . . . . . . . . . . . . . . . . . . . . . 130
11. Security Considerations . . . . . . . . . . . . . . . . . . . 129 11. Security Considerations . . . . . . . . . . . . . . . . . . . 130
11.1. STARTTLS Security Considerations . . . . . . . . . . . . 129 11.1. STARTTLS Security Considerations . . . . . . . . . . . . 130
11.2. COPYUID and APPENDUID response codes . . . . . . . . . . 130 11.2. COPYUID and APPENDUID response codes . . . . . . . . . . 131
11.3. LIST command and Other Users' namespace . . . . . . . . 130 11.3. LIST command and Other Users' namespace . . . . . . . . 131
11.4. Other Security Considerations . . . . . . . . . . . . . 130 11.4. Other Security Considerations . . . . . . . . . . . . . 131
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 131 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 132
12.1. Updates to IMAP4 Capabilities registry . . . . . . . . . 131 12.1. Updates to IMAP4 Capabilities registry . . . . . . . . . 132
12.2. GSSAPI/SASL service name . . . . . . . . . . . . . . . . 132 12.2. GSSAPI/SASL service name . . . . . . . . . . . . . . . . 133
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 132 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 133
13.1. Normative References . . . . . . . . . . . . . . . . . . 132 13.1. Normative References . . . . . . . . . . . . . . . . . . 133
13.2. Informative References (related protocols) . . . . . . . 135 13.2. Informative References (related protocols) . . . . . . . 136
13.3. Informative References (historical aspects of IMAP and 13.3. Informative References (historical aspects of IMAP and
related protocols) . . . . . . . . . . . . . . . . . . . 136 related protocols) . . . . . . . . . . . . . . . . . . . 137
Appendix A. Backward compatibility with IMAP4rev1 . . . . . . . 137 Appendix A. Backward compatibility with IMAP4rev1 . . . . . . . 138
A.1. Mailbox International Naming Convention for compatibility A.1. Mailbox International Naming Convention for compatibility
with IMAP4rev1 . . . . . . . . . . . . . . . . . . . . . 137 with IMAP4rev1 . . . . . . . . . . . . . . . . . . . . . 138
Appendix B. Backward compatibility with BINARY extension . . . . 139 Appendix B. Backward compatibility with BINARY extension . . . . 140
Appendix C. Changes from RFC 3501 / IMAP4rev1 . . . . . . . . . 139 Appendix C. Changes from RFC 3501 / IMAP4rev1 . . . . . . . . . 140
Appendix D. Acknowledgement . . . . . . . . . . . . . . . . . . 141 Appendix D. Acknowledgement . . . . . . . . . . . . . . . . . . 142
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 147 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 148
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 7 skipping to change at page 6, line 7
"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
until its termination. until its termination.
"Session" refers to the sequence of client/server interaction from "Session" refers to the sequence of client/server interaction from
the time that a mailbox is selected (SELECT or EXAMINE command) until the time that a mailbox is selected (SELECT or EXAMINE command) until
the time that selection ends (SELECT or EXAMINE of another mailbox, the time that selection ends (SELECT or EXAMINE of another mailbox,
CLOSE command, UNSELECT command, or connection termination). CLOSE command, UNSELECT command, or connection termination).
Characters are 7-bit US-ASCII unless otherwise specified. Other Characters are 8-bit UTF-8 (of which 7-bit US-ASCII is a subset)
character sets are indicated using a "CHARSET", as described in unless otherwise specified. Other character sets are indicated using
[MIME-IMT] and defined in [CHARSET]. CHARSETs have important a "CHARSET", as described in [MIME-IMT] and defined in [CHARSET].
additional semantics in addition to defining character set; refer to CHARSETs have important additional semantics in addition to defining
these documents for more detail. character set; refer to these documents for more detail.
There are several protocol conventions in IMAP. These refer to There are several protocol conventions in IMAP. These refer to
aspects of the specification which are not strictly part of the IMAP aspects of the specification which are not strictly part of the IMAP
protocol, but reflect generally-accepted practice. Implementations protocol, but reflect generally-accepted practice. Implementations
need to be aware of these conventions, and avoid conflicts whether or need to be aware of these conventions, and avoid conflicts whether or
not they implement the convention. For example, "&" may not be used not they implement the convention. For example, "&" may not be used
as a hierarchy delimiter since it conflicts with the Mailbox as a hierarchy delimiter since it conflicts with the Mailbox
International Naming Convention, and other uses of "&" in mailbox International Naming Convention, and other uses of "&" in mailbox
names are impacted as well. names are impacted as well.
skipping to change at page 6, line 35 skipping to change at page 6, line 35
IMAP implementation recommendations document [IMAP-IMPLEMENTATION] in IMAP implementation recommendations document [IMAP-IMPLEMENTATION] in
conjunction with this document, to help understand the intricacies of conjunction with this document, to help understand the intricacies of
this protocol and how best to build an interoperable product. this protocol and how best to build an interoperable product.
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. in the earlier protocols have become obsolete. Obsolete commands,
responses, and data formats which an IMAP4rev2 implementation can
Obsolete commands, responses, and data formats which an IMAP4rev2 encounter when used with an earlier implementation are described in
implementation can encounter when used with an earlier implementation Appendix C and [IMAP-OBSOLETE].
are described in [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. With the exception of RFC822.SIZE, there are more modern their name. With the exception of RFC822.SIZE, there are more modern
skipping to change at page 39, line 32 skipping to change at page 39, line 32
If the name has inferior hierarchical names, then the inferior If the name has inferior hierarchical names, then the inferior
hierarchical names MUST also be renamed. For example, a rename of hierarchical names MUST also be renamed. For example, a rename of
"foo" to "zap" will rename "foo/bar" (assuming "/" is the hierarchy "foo" to "zap" will rename "foo/bar" (assuming "/" is the hierarchy
delimiter character) to "zap/bar". delimiter character) to "zap/bar".
If the server's hierarchy separator character appears in the name, If the server's hierarchy separator character appears in the name,
the server SHOULD create any superior hierarchical names that are the server SHOULD create any superior hierarchical names that are
needed for the RENAME command to complete successfully. In other needed for the RENAME command to complete successfully. In other
words, an attempt to rename "foo/bar/zap" to baz/rag/zowie on a words, an attempt to rename "foo/bar/zap" to baz/rag/zowie on a
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. It moves all Renaming INBOX is permitted, and has special behavior. (Note that
messages in INBOX to a new mailbox with the given name, leaving INBOX some servers refuse renaming INBOX). It moves all messages in INBOX
empty. If the server implementation supports inferior hierarchical to a new mailbox with the given name, leaving INBOX empty. If the
names of INBOX, these are unaffected by a rename of INBOX. server 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 40, line 32 skipping to change at page 40, line 32
S: * LIST () "." INBOX.bar S: * LIST () "." INBOX.bar
S: Z432 OK LIST completed S: Z432 OK LIST completed
C: Z433 RENAME INBOX old-mail C: Z433 RENAME INBOX old-mail
S: Z433 OK RENAME completed S: Z433 OK RENAME completed
C: Z434 LIST "" * C: Z434 LIST "" *
S: * LIST () "." INBOX S: * LIST () "." INBOX
S: * LIST () "." INBOX.bar S: * LIST () "." INBOX.bar
S: * LIST () "." old-mail S: * LIST () "." old-mail
S: Z434 OK LIST completed S: Z434 OK LIST completed
Note that renaming a mailbox doesn't update subscription information
on the original name. To keep subscription information in sync, the
following sequence of commands can be used:
C: 1001 RENAME X Y
C: 1002 SUBSCRIBE Y
C: 1003 UNSUBSCRIBE X
Note that the above sequence of commands doesn't account for updating
subscription for any children mailboxes of mailbox X.
6.3.7. SUBSCRIBE Command 6.3.7. SUBSCRIBE Command
Arguments: mailbox Arguments: mailbox
Responses: no specific responses for this command Responses: no specific responses for this command
Result: OK - subscribe completed Result: OK - subscribe completed
NO - subscribe failure: can't subscribe to that name NO - subscribe failure: can't subscribe to that name
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
skipping to change at page 46, line 38 skipping to change at page 46, line 42
particular, it has no interaction with RECURSIVEMATCH (see below). particular, it has no interaction with RECURSIVEMATCH (see below).
A request for (REMOTE RECURSIVEMATCH) is invalid, because a A request for (REMOTE RECURSIVEMATCH) is invalid, because a
request for (RECURSIVEMATCH) is also invalid. A request for request for (RECURSIVEMATCH) is also invalid. A request for
(REMOTE RECURSIVEMATCH SUBSCRIBED) is asking for all subscribed (REMOTE RECURSIVEMATCH SUBSCRIBED) is asking for all subscribed
mailboxes, both local and remote. mailboxes, both local and remote.
RECURSIVEMATCH - this option forces the server to return information RECURSIVEMATCH - this option forces the server to return information
about parent mailboxes that don't match other selection options, about parent mailboxes that don't match other selection options,
but have some submailboxes that do. Information about children is but have some submailboxes that do. Information about children is
returned in the CHILDINFO extended data item, as described in returned in the CHILDINFO extended data item, as described in
Section 6.3.9.5. Section 6.3.9.6.
Note 1: In order for a parent mailbox to be returned, it still has Note 1: In order for a parent mailbox to be returned, it still has
to match the canonical LIST pattern. to match the canonical LIST pattern.
Note 2: When returning the CHILDINFO extended data item, it Note 2: When returning the CHILDINFO extended data item, it
doesn't matter whether or not the submailbox matches the canonical doesn't matter whether or not the submailbox matches the canonical
LIST pattern. See also example 9 in Section 6.3.9.6. LIST pattern. See also example 9 in Section 6.3.9.7.
The RECURSIVEMATCH option MUST NOT occur as the only selection The RECURSIVEMATCH option MUST NOT occur as the only selection
option (or only with REMOTE), as it only makes sense when other option (or only with REMOTE), as it only makes sense when other
selection options are also used. The server MUST return BAD selection options are also used. The server MUST return BAD
tagged response in such case. tagged response in such case.
Note that even if the RECURSIVEMATCH option is specified, the Note that even if the RECURSIVEMATCH option is specified, the
client MUST still be able to handle a case when a CHILDINFO client MUST still be able to handle a case when a CHILDINFO
extended data item is returned and there are no submailboxes that extended data item is returned and there are no submailboxes that
meet the selection criteria of the subsequent LIST command, as meet the selection criteria of the subsequent LIST command, as
skipping to change at page 47, line 24 skipping to change at page 47, line 29
The return options defined in this specification are as follows: The return options defined in this specification are as follows:
SUBSCRIBED - causes the LIST command to return subscription state SUBSCRIBED - causes the LIST command to return subscription state
for all matching mailbox names. The "\Subscribed" attribute MUST for all matching mailbox names. The "\Subscribed" attribute MUST
be supported and MUST be accurately computed when the SUBSCRIBED be supported and MUST be accurately computed when the SUBSCRIBED
return option is specified. Further, all mailbox flags MUST be return option is specified. Further, all mailbox flags MUST be
accurately computed (this differs from the behavior of the accurately computed (this differs from the behavior of the
obsolete LSUB command from IMAP4rev1). obsolete LSUB command from IMAP4rev1).
CHILDREN - requests mailbox child information as originally proposed CHILDREN - requests mailbox child information as originally proposed
in [RFC3348]. See Section 6.3.9.4, below, for details. in [RFC3348]. See Section 6.3.9.5, below, for details.
CHILDREN - This option MUST be supported by all servers. CHILDREN - This option MUST be supported by all servers.
6.3.9.3. General Principles for Returning LIST Responses 6.3.9.3. General Principles for Returning LIST Responses
This section outlines several principles that can be used by server This section outlines several principles that can be used by server
implementations of this document to decide whether a LIST response implementations of this document to decide whether a LIST response
should be returned, as well as how many responses and what kind of should be returned, as well as how many responses and what kind of
information they may contain. information they may contain.
skipping to change at page 48, line 6 skipping to change at page 48, line 11
responses are not governed by this rule): responses are not governed by this rule):
A. The mailbox name also satisfies the selection criteria. A. The mailbox name also satisfies the selection criteria.
B. The mailbox name doesn't satisfy the selection criteria, but B. The mailbox name doesn't satisfy the selection criteria, but
it has at least one descendant mailbox name that satisfies it has at least one descendant mailbox name that satisfies
the selection criteria and that doesn't match the canonical the selection criteria and that doesn't match the canonical
LIST pattern. LIST pattern.
For more information on this case, see the CHILDINFO extended For more information on this case, see the CHILDINFO extended
data item described in Section 6.3.9.5. Note that the data item described in Section 6.3.9.6. Note that the
CHILDINFO extended data item can only be returned when the CHILDINFO extended data item can only be returned when the
RECURSIVEMATCH selection option is specified. RECURSIVEMATCH selection option is specified.
3. Attributes returned in the same LIST response must be treated 3. Attributes returned in the same LIST response must be treated
additively. For example, the following response additively. For example, the following response
S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach" S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
means that the "Fruit/Peach" mailbox doesn't exist, but it is means that the "Fruit/Peach" mailbox doesn't exist, but it is
subscribed. subscribed.
6.3.9.4. The CHILDREN Return Option 6.3.9.4. Additional LIST-related Requirements on Clients
All clients MUST treat a LIST attribute with a stronger meaning as
implying any attribute that can be inferred from it. (See
Section 7.2.3 for the list of currently defined attributes). For
example, the client must treat the presence of the \NoInferiors
attribute as if the \HasNoChildren attribute was also sent by the
server.
The following table summarizes inference rules described in
Section 6.3.9.
+--------------------+-------------------+
| returned attribute | implied attribute |
+--------------------+-------------------+
| \NoInferiors | \HasNoChildren |
| \NonExistent | \NoSelect |
+--------------------+-------------------+
6.3.9.5. The CHILDREN Return Option
The CHILDREN return option implements the Child Mailbox Extension, The CHILDREN return option implements the Child Mailbox Extension,
originally proposed by Mike Gahrns and Raymond Cheng, of Microsoft originally proposed by Mike Gahrns and Raymond Cheng, of Microsoft
Corporation. Most of the information in this section is taken Corporation. Most of the information in this section is taken
directly from their original specification [RFC3348]. The CHILDREN directly from their original specification [RFC3348]. The CHILDREN
return option is simply an indication that the client wants this return option is simply an indication that the client wants this
information; a server MAY provide it even if the option is not information; a server MAY provide it even if the option is not
specified. specified.
Many IMAP4 clients present to the user a hierarchical view of the Many IMAP4 clients present to the user a hierarchical view of the
skipping to change at page 49, line 30 skipping to change at page 50, line 9
child mailboxes that are accessible to the currently child mailboxes that are accessible to the currently
authenticated user. authenticated user.
It is an error for the server to return both a \HasChildren and a It is an error for the server to return both a \HasChildren and a
\HasNoChildren attribute in the same LIST response. \HasNoChildren attribute in the same LIST response.
Note: the \HasNoChildren attribute should not be confused with the Note: the \HasNoChildren attribute should not be confused with the
the \NoInferiors attribute, which indicates that no child mailboxes the \NoInferiors attribute, which indicates that no child mailboxes
exist now and none can be created in the future. exist now and none can be created in the future.
6.3.9.5. CHILDINFO Extended Data Item 6.3.9.6. CHILDINFO Extended Data Item
The CHILDINFO extended data item MUST NOT be returned unless the The CHILDINFO extended data item MUST NOT be returned unless the
client has specified the RECURSIVEMATCH selection option. client has specified the RECURSIVEMATCH selection option.
The CHILDINFO extended data item in a LIST response describes the The CHILDINFO extended data item in a LIST response describes the
selection criteria that has caused it to be returned and indicates selection criteria that has caused it to be returned and indicates
that the mailbox has at least one descendant mailbox that matches the that the mailbox has at least one descendant mailbox that matches the
selection criteria. selection criteria.
Note: Some servers allow for mailboxes to exist without requiring Note: Some servers allow for mailboxes to exist without requiring
their parent to exist. For example, a mailbox "Customers/ABC" can their parent to exist. For example, a mailbox "Customers/ABC" can
exist while the mailbox "Customers" does not. As CHILDINFO extended exist while the mailbox "Customers" does not. As CHILDINFO extended
data item is not allowed if the RECURSIVEMATCH selection option is data item is not allowed if the RECURSIVEMATCH selection option is
not specified, such servers SHOULD use the "\NonExistent not specified, such servers SHOULD use the "\NonExistent
\HasChildren" attribute pair to signal to the client that there is a \HasChildren" attribute pair to signal to the client that there is a
descendant mailbox that matches the selection criteria. See example descendant mailbox that matches the selection criteria. See example
11 in Section 6.3.9.6. 11 in Section 6.3.9.7.
The returned selection criteria allow the client to distinguish a The returned selection criteria allow the client to distinguish a
solicited response from an unsolicited one, as well as to distinguish solicited response from an unsolicited one, as well as to distinguish
among solicited responses caused by multiple pipelined LIST commands among solicited responses caused by multiple pipelined LIST commands
that specify different criteria. that specify different criteria.
Servers SHOULD ONLY return a non-matching mailbox name along with Servers SHOULD ONLY return a non-matching mailbox name along with
CHILDINFO if at least one matching child is not also being returned. CHILDINFO if at least one matching child is not also being returned.
That is, servers SHOULD suppress redundant CHILDINFO responses. That is, servers SHOULD suppress redundant CHILDINFO responses.
Examples 8 and 10 in Section 6.3.9.6 demonstrate the difference Examples 8 and 10 in Section 6.3.9.7 demonstrate the difference
between present CHILDINFO extended data item and the "\HasChildren" between present CHILDINFO extended data item and the "\HasChildren"
attribute. attribute.
The following table summarizes interaction between the "\NonExistent" The following table summarizes interaction between the "\NonExistent"
attribute and CHILDINFO (the first column indicates whether the attribute and CHILDINFO (the first column indicates whether the
parent mailbox exists): parent mailbox exists):
+--------+--------------+--------------------+----------------------+ +--------+--------------+--------------------+----------------------+
| exists | meets the | has a child that | returned LIST- | | exists | meets the | has a child that | returned LIST- |
| | selection | meets the | EXTENDED attributes | | | selection | meets the | EXTENDED attributes |
skipping to change at page 50, line 43 skipping to change at page 51, line 33
| yes | no | yes | () + CHILDINFO | | yes | no | yes | () + CHILDINFO |
| no | yes | yes | (\NonExistent | | no | yes | yes | (\NonExistent |
| | | | <attr>) + CHILDINFO | | | | | <attr>) + CHILDINFO |
| yes | yes | yes | (<attr>) + CHILDINFO | | yes | yes | yes | (<attr>) + CHILDINFO |
+--------+--------------+--------------------+----------------------+ +--------+--------------+--------------------+----------------------+
where <attr> is one or more attributes that correspond to the where <attr> is one or more attributes that correspond to the
selection criteria; for example, for the SUBSCRIBED option the <attr> selection criteria; for example, for the SUBSCRIBED option the <attr>
is \Subscribed. is \Subscribed.
6.3.9.6. LIST Command Examples 6.3.9.7. LIST Command Examples
This example shows some uses of the basic LIST command: 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 ""
skipping to change at page 58, line 4 skipping to change at page 58, line 32
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.
6.3.10. NAMESPACE Command 6.3.10. NAMESPACE Command
Arguments: none Arguments: none
Responses: REQUIRED untagged responses: NAMESPACE Responses: REQUIRED untagged responses: NAMESPACE
Result: OK - command completed Result: OK - command completed
NO - Can't complete the command NO - Can't complete the command
BAD - arguments invalid BAD - arguments invalid
The NAMESPACE command causes a single ungagged NAMESPACE response to The NAMESPACE command causes a single ungagged NAMESPACE response to
be returned. The untagged NAMESPACE response contains the prefix and be returned. The untagged NAMESPACE response contains the prefix and
hierarchy delimiter to the server's Personal Namespace(s), Other hierarchy delimiter to the server's Personal Namespace(s), Other
Users' Namespace(s), and Shared Namespace(s) that the server wishes Users' Namespace(s), and Shared Namespace(s) that the server wishes
to expose. The response will contain a NIL for any namespace class to expose. The response will contain a NIL for any namespace class
that is not available. Namespace-Response-Extensions ABNF non that is not available. Namespace-Response-Extensions ABNF non
terminal is defined for extensibility and MAY be included in the terminal is defined for extensibility and MAY be included in the
response. response.
Namespace-Response-Extensions which are not on the IETF standards
track, MUST be prefixed with an "X-".
Example 1: Example 1:
In this example a server supports a single personal namespace. No In this example a server supports a single personal namespace. No
leading prefix is used on personal mailboxes and "/" is the hierarchy leading prefix is used on personal mailboxes and "/" is the hierarchy
delimiter. delimiter.
C: A001 NAMESPACE C: A001 NAMESPACE
S: * NAMESPACE (("" "/")) NIL NIL S: * NAMESPACE (("" "/")) NIL NIL
S: A001 OK NAMESPACE command completed S: A001 OK NAMESPACE command completed
skipping to change at page 63, line 10 skipping to change at page 64, line 7
STATUS command can cause the mailbox to be opened internally, and STATUS command can cause the mailbox to be opened internally, and
because this information is available by other means on the because this information is available by other means on the
selected mailbox, the STATUS command SHOULD NOT be used on the selected mailbox, the STATUS command SHOULD NOT be used on the
currently selected mailbox. currently selected mailbox.
The STATUS command MUST NOT be used as a "check for new messages The STATUS command MUST NOT be used as a "check for new messages
in the selected mailbox" operation (refer to sections Section 7, in the selected mailbox" operation (refer to sections Section 7,
Section 7.3.1 for more information about the proper method for new Section 7.3.1 for more information about the proper method for new
message checking). message checking).
Because the STATUS command is not guaranteed to be fast in its STATUS SIZE (see below) can take a significant amount of time,
results, clients SHOULD NOT expect to be able to issue many depending upon server implementation. Clients should use STATUS
consecutive STATUS commands and obtain reasonable performance. SIZE cautiously.
The currently defined status data items that can be requested are: The currently defined status data items that can be requested are:
MESSAGES The number of messages in the mailbox. MESSAGES The number of messages in the mailbox.
UIDNEXT The next unique identifier value of the mailbox. Refer to UIDNEXT The next unique identifier value of the mailbox. Refer to
Section 2.3.1.1 for more information. Section 2.3.1.1 for more information.
UIDVALIDITY The unique identifier validity value of the mailbox. UIDVALIDITY The unique identifier validity value of the mailbox.
Refer to Section 2.3.1.1 for more information. Refer to Section 2.3.1.1 for more information.
skipping to change at page 64, line 28 skipping to change at page 65, line 24
If a flag parenthesized list is specified, the flags SHOULD be set in If a flag parenthesized list is specified, the flags SHOULD be set in
the resulting message; otherwise, the flag list of the resulting the resulting message; otherwise, the flag list of the resulting
message is set to empty by default. message is set to empty by default.
If a date-time is specified, the internal date SHOULD be set in the If a date-time is specified, the internal date SHOULD be set in the
resulting message; otherwise, the internal date of the resulting resulting message; otherwise, the internal date of the resulting
message is set to the current date and time by default. message is set to the current date and time by default.
If the append is unsuccessful for any reason, the mailbox MUST be If the append is unsuccessful for any reason, the mailbox MUST be
restored to its state before the APPEND attempt; no partial appending restored to its state before the APPEND attempt (other than possibly
is permitted. keeping the changed mailbox's UIDNEXT value); no partial appending is
permitted.
If the destination mailbox does not exist, a server MUST return an If the destination mailbox does not exist, a server MUST return an
error, and MUST NOT automatically create the mailbox. Unless it is error, and MUST NOT automatically create the mailbox. Unless it is
certain that the destination mailbox can not be created, the server certain that the destination mailbox can not be created, the server
MUST send the response code "[TRYCREATE]" as the prefix of the text MUST send the response code "[TRYCREATE]" as the prefix of the text
of the tagged NO response. This gives a hint to the client that it of the tagged NO response. This gives a hint to the client that it
can attempt a CREATE command and retry the APPEND if the CREATE is can attempt a CREATE command and retry the APPEND if the CREATE is
successful. successful.
On successful completion of an APPEND, the server SHOULD return an On successful completion of an APPEND, the server SHOULD return an
skipping to change at page 67, line 18 skipping to change at page 68, line 18
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
Without the IDLE command a client requires to poll the server for Without the IDLE command a client requires to poll the server for
changes to the selected mailbox (new mail, deletions, flag changes). changes to the selected mailbox (new mail, deletions, flag changes).
It's often more desirable to have the server transmit updates to the It's often more desirable to have the server transmit updates to the
client in real time. This allows a user to see new mail immediately. client in real time. This allows a user to see new mail immediately.
The IDLE command allows a client to tell the server that it's ready The IDLE command allows a client to tell the server that it's ready
to accept such real-time updates. to accept such real-time updates.
The IDLE command is sent from the client to the server when the The IDLE command is sent from the client to the server when the
client is ready to accept unsolicited mailbox client is ready to accept unsolicited update messages. The server
requests a response to the IDLE command using the continuation ("+")
update messages. The server requests a response to the IDLE command response. The IDLE command remains active until the client responds
using the continuation ("+") response. The IDLE command remains to the continuation, and as long as an IDLE command is active, the
active until the client responds to the continuation, and as long as server is now free to send untagged EXISTS, EXPUNGE, FETCH, and other
an IDLE command is active, the server is now free to send untagged responses at any time. If the server choose to send unsolicited
EXISTS, EXPUNGE, FETCH, and other responses at any time. If the FETCH responses, they MUST include UID FETCH item.
server choose to send unsolicited FETCH responses, they MUST include
UID FETCH item.
The IDLE command is terminated by the receipt of a "DONE" The IDLE command is terminated by the receipt of a "DONE"
continuation from the client; such response satisfies the server's continuation from the client; such response satisfies the server's
continuation request. At that point, the server MAY send any continuation request. At that point, the server MAY send any
remaining queued untagged responses and then MUST immediately send remaining queued untagged responses and then MUST immediately send
the tagged response to the IDLE command and prepare to process other the tagged response to the IDLE command and prepare to process other
commands. As for other commands, the processing of any new command commands. As for other commands, the processing of any new command
may cause the sending of unsolicited untagged responses, subject to may cause the sending of unsolicited untagged responses, subject to
the ambiguity limitations. The client MUST NOT send a command while the ambiguity limitations. The client MUST NOT send a command while
the server is waiting for the DONE, since the server will not be able the server is waiting for the DONE, since the server will not be able
skipping to change at page 102, line 37 skipping to change at page 103, line 37
Shared Namespace(s) Shared Namespace(s)
The NAMESPACE response occurs as a result of a NAMESPACE command. It The NAMESPACE response occurs as a result of a NAMESPACE command. It
contains the prefix and hierarchy delimiter to the server's Personal contains the prefix and hierarchy delimiter to the server's Personal
Namespace(s), Other Users' Namespace(s), and Shared Namespace(s) that Namespace(s), Other Users' Namespace(s), and Shared Namespace(s) that
the server wishes to expose. The response will contain a NIL for any the server wishes to expose. The response will contain a NIL for any
namespace class that is not available. Namespace-Response-Extensions namespace class that is not available. Namespace-Response-Extensions
ABNF non terminal is defined for extensibility and MAY be included in ABNF non terminal is defined for extensibility and MAY be included in
the response. the response.
Namespace-Response-Extensions which are not on the IETF standards
track, MUST be prefixed with an "X-".
Example: S: * NAMESPACE (("" "/")) (("~" "/")) NIL Example: S: * NAMESPACE (("" "/")) (("~" "/")) NIL
7.2.5. STATUS Response 7.2.5. STATUS Response
Contents: name Contents: name
status parenthesized list status parenthesized list
The STATUS response occurs as a result of an STATUS command. It The STATUS response occurs as a result of an STATUS command. It
returns the mailbox name that matches the STATUS specification and returns the mailbox name that matches the STATUS specification and
the requested mailbox status information. the requested mailbox status information.
skipping to change at page 107, line 46 skipping to change at page 108, line 46
a BODYSTRUCTURE fetch. Extension data, if present, MUST be in a BODYSTRUCTURE fetch. Extension data, if present, MUST be in
the defined order. The extension data of a multipart body part the defined order. The extension data of a multipart body part
are in the following order: are in the following order:
body parameter parenthesized list A parenthesized list of body parameter parenthesized list A parenthesized list of
attribute/value pairs [e.g., ("foo" "bar" "baz" "rag") where attribute/value pairs [e.g., ("foo" "bar" "baz" "rag") where
"bar" is the value of "foo", and "rag" is the value of "bar" is the value of "foo", and "rag" is the value of
"baz"] as defined in [MIME-IMB]. "baz"] as defined in [MIME-IMB].
body parameter parenthesized list Servers SHOULD decode body parameter parenthesized list Servers SHOULD decode
parameter value continuations as described in [RFC2231]. parameter value continuations as described in [RFC2231], for
example, if the message contains parameters "foo*0*" and
"foo*1*", the server should RFC2231-decode them, concatenate
and return the resulting value as "foo*".
body disposition A parenthesized list, consisting of a body disposition A parenthesized list, consisting of a
disposition type string, followed by a parenthesized list of disposition type string, followed by a parenthesized list of
disposition attribute/value pairs as defined in disposition attribute/value pairs as defined in
[DISPOSITION]. Servers SHOULD decode parameter value [DISPOSITION]. Servers SHOULD decode parameter value
continuations as described in [RFC2231]. continuations as described in [RFC2231].
body language A string or parenthesized list giving the body body language A string or parenthesized list giving the body
language value as defined in [LANGUAGE-TAGS]. language value as defined in [LANGUAGE-TAGS].
skipping to change at page 124, line 21 skipping to change at page 125, line 21
resp-cond-auth = ("OK" / "PREAUTH") SP resp-text resp-cond-auth = ("OK" / "PREAUTH") SP resp-text
; Authentication condition ; Authentication condition
resp-cond-bye = "BYE" SP resp-text resp-cond-bye = "BYE" SP resp-text
resp-cond-state = ("OK" / "NO" / "BAD") SP resp-text resp-cond-state = ("OK" / "NO" / "BAD") SP resp-text
; Status condition ; Status condition
resp-specials = "]" resp-specials = "]"
;; ////Can we make "text" optional? Will this have any bad side effects? resp-text = ["[" resp-text-code "]" SP] [text]
resp-text = ["[" resp-text-code "]" SP] text
resp-text-code = "ALERT" / resp-text-code = "ALERT" /
"BADCHARSET" [SP "(" charset *(SP charset) ")" ] / "BADCHARSET" [SP "(" charset *(SP charset) ")" ] /
capability-data / "PARSE" / capability-data / "PARSE" /
"PERMANENTFLAGS" SP "(" "PERMANENTFLAGS" SP "("
[flag-perm *(SP flag-perm)] ")" / [flag-perm *(SP flag-perm)] ")" /
"READ-ONLY" / "READ-WRITE" / "TRYCREATE" / "READ-ONLY" / "READ-WRITE" / "TRYCREATE" /
"UIDNEXT" SP nz-number / "UIDVALIDITY" SP nz-number / "UIDNEXT" SP nz-number / "UIDVALIDITY" SP nz-number /
resp-code-apnd / resp-code-copy / "UIDNOTSTICKY" / resp-code-apnd / resp-code-copy / "UIDNOTSTICKY" /
"UNAVAILABLE" / "AUTHENTICATIONFAILED" / "UNAVAILABLE" / "AUTHENTICATIONFAILED" /
skipping to change at page 137, line 9 skipping to change at page 138, line 9
<http://www.rfc-editor.org/info/rfc2062>. <http://www.rfc-editor.org/info/rfc2062>.
[IMAP2] Crispin, M., "Interactive Mail Access Protocol: Version [IMAP2] Crispin, M., "Interactive Mail Access Protocol: Version
2", RFC 1176, August 1990, 2", RFC 1176, August 1990,
<http://www.rfc-editor.org/info/rfc1176>. <http://www.rfc-editor.org/info/rfc1176>.
[RFC-822] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET [RFC-822] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET
TEXT MESSAGES", STD 11, RFC 822, August 1982, TEXT MESSAGES", STD 11, RFC 822, August 1982,
<http://www.rfc-editor.org/info/rfc822>. <http://www.rfc-editor.org/info/rfc822>.
[RFC-821] Postel, J., "Simple Mail Transfer Protocol", STD 10,
RFC 821, August 1982,
<http://www.rfc-editor.org/info/rfc821>.
[IMAP-TLS] [IMAP-TLS]
Newman, C., "Using TLS with IMAP, POP3 and ACAP", Newman, C., "Using TLS with IMAP, POP3 and ACAP",
RFC 2595, June 1999, RFC 2595, June 1999,
<http://www.rfc-editor.org/info/rfc2595>. <http://www.rfc-editor.org/info/rfc2595>.
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
skipping to change at page 141, line 32 skipping to change at page 142, line 26
14. RFC822, RFC822.HEADER and RFC822.TEXT FETCH data items were 14. RFC822, RFC822.HEADER and RFC822.TEXT FETCH data items were
deprecated. Clients should use the corresponding BODY[] deprecated. Clients should use the corresponding BODY[]
variants instead. variants instead.
15. Replaced DIGEST-MD5 SASL mechanism with SCRAM-SHA-256. DIGEST- 15. Replaced DIGEST-MD5 SASL mechanism with SCRAM-SHA-256. DIGEST-
MD5 was deprecated. MD5 was deprecated.
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.
18. IDLE command can now return no mailbox related updates.
Appendix D. Acknowledgement Appendix D. 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.
skipping to change at page 142, line 12 skipping to change at page 143, line 12
so work done by authors/editors of these documents is appreciated. so work done by authors/editors of these documents is appreciated.
Index Index
$ $
$Forwarded (predefined flag) 12 $Forwarded (predefined flag) 12
$MDNSent (predefined flag) 12 $MDNSent (predefined flag) 12
+ +
+FLAGS <flag list> 80 +FLAGS <flag list> 81
+FLAGS.SILENT <flag list> 80 +FLAGS.SILENT <flag list> 81
- -
-FLAGS <flag list> 80 -FLAGS <flag list> 81
-FLAGS.SILENT <flag list> 80 -FLAGS.SILENT <flag list> 81
A A
ALERT (response code) 87 ALERT (response code) 88
ALL (fetch item) 76 ALL (fetch item) 77
ALL (search key) 72 ALL (search key) 73
ALL (search result option) 71 ALL (search result option) 72
ALREADYEXISTS (response code) 87 ALREADYEXISTS (response code) 88
ANSWERED (search key) 72 ANSWERED (search key) 73
APPEND (command) 63 APPEND (command) 64
APPENDUID (response code) 88 APPENDUID (response code) 89
AUTHENTICATE (command) 28 AUTHENTICATE (command) 28
AUTHENTICATIONFAILED (response code) 88 AUTHENTICATIONFAILED (response code) 89
AUTHORIZATIONFAILED (response code) 89 AUTHORIZATIONFAILED (response code) 90
B B
BAD (response) 96 BAD (response) 97
BADCHARSET (response code) 89 BADCHARSET (response code) 90
BCC <string> (search key) 73 BCC <string> (search key) 74
BEFORE <date> (search key) 73 BEFORE <date> (search key) 74
BINARY.PEEK[<section-binary>]<<partial>> (fetch item) 77 BINARY.PEEK[<section-binary>]<<partial>> (fetch item) 78
BINARY.SIZE[<section-binary>] (fetch item) 77 BINARY.SIZE[<section-binary>] (fetch item) 78
BINARY.SIZE[<section-binary>] (fetch result) 106 BINARY.SIZE[<section-binary>] (fetch result) 107
BINARY[<section-binary>]<<number>> (fetch result) 105 BINARY[<section-binary>]<<number>> (fetch result) 106
BINARY[<section-binary>]<<partial>> (fetch item) 76 BINARY[<section-binary>]<<partial>> (fetch item) 77
BODY (fetch item) 77 BODY (fetch item) 78
BODY (fetch result) 106 BODY (fetch result) 107
BODY <string> (search key) 73 BODY <string> (search key) 74
BODY.PEEK[<section>]<<partial>> (fetch item) 79 BODY.PEEK[<section>]<<partial>> (fetch item) 80
BODYSTRUCTURE (fetch item) 79 BODYSTRUCTURE (fetch item) 80
BODYSTRUCTURE (fetch result) 107 BODYSTRUCTURE (fetch result) 108
BODY[<section>]<<origin octet>> (fetch result) 106 BODY[<section>]<<origin octet>> (fetch result) 107
BODY[<section>]<<partial>> (fetch item) 77 BODY[<section>]<<partial>> (fetch item) 78
BYE (response) 97 BYE (response) 98
Body Structure (message attribute) 13 Body Structure (message attribute) 13
C C
CANNOT (response code) 89 CANNOT (response code) 90
CAPABILITY (command) 24 CAPABILITY (command) 24
CAPABILITY (response code) 89 CAPABILITY (response code) 90
CAPABILITY (response) 98 CAPABILITY (response) 99
CC <string> (search key) 73 CC <string> (search key) 74
CLIENTBUG (response code) 89 CLIENTBUG (response code) 90
CLOSE (command) 68 CLOSE (command) 69
CLOSED (response code) 90 CLOSED (response code) 91
CONTACTADMIN (response code) 90 CONTACTADMIN (response code) 91
COPY (command) 81 COPY (command) 82
COPYUID (response code) 90 COPYUID (response code) 91
CORRUPTION (response code) 91 CORRUPTION (response code) 92
COUNT (search result option) 71 COUNT (search result option) 72
CREATE (command) 36 CREATE (command) 36
D D
DELETE (command) 37 DELETE (command) 37
DELETED (search key) 73 DELETED (search key) 74
DELETED (status item) 63 DELETED (status item) 64
DRAFT (search key) 73 DRAFT (search key) 74
E E
ENABLE (command) 32 ENABLE (command) 32
ENVELOPE (fetch item) 79 ENVELOPE (fetch item) 80
ENVELOPE (fetch result) 109 ENVELOPE (fetch result) 110
ESEARCH (response) 103 ESEARCH (response) 104
EXAMINE (command) 35 EXAMINE (command) 35
EXPIRED (response code) 91 EXPIRED (response code) 92
EXPUNGE (command) 69 EXPUNGE (command) 70
EXPUNGE (response) 104 EXPUNGE (response) 105
EXPUNGEISSUED (response code) 91 EXPUNGEISSUED (response code) 92
Envelope Structure (message attribute) 13 Envelope Structure (message attribute) 13
F F
FAST (fetch item) 76 FAST (fetch item) 77
FETCH (command) 76 FETCH (command) 77
FETCH (response) 105 FETCH (response) 106
FLAGGED (search key) 73 FLAGGED (search key) 74
FLAGS (fetch item) 79 FLAGS (fetch item) 80
FLAGS (fetch result) 110 FLAGS (fetch result) 111
FLAGS (response) 103 FLAGS (response) 104
FLAGS <flag list> (store command data item) 80 FLAGS <flag list> (store command data item) 81
FLAGS.SILENT <flag list> (store command data item) 80 FLAGS.SILENT <flag list> (store command data item) 81
FROM <string> (search key) 73 FROM <string> (search key) 74
FULL (fetch item) 76 FULL (fetch item) 77
Flags (message attribute) 11 Flags (message attribute) 11
H H
HEADER (part specifier) 77 HEADER (part specifier) 78
HEADER <field-name> <string> (search key) 73 HEADER <field-name> <string> (search key) 74
HEADER.FIELDS (part specifier) 77 HEADER.FIELDS (part specifier) 78
HEADER.FIELDS.NOT (part specifier) 77 HEADER.FIELDS.NOT (part specifier) 78
I I
IDLE (command) 66 IDLE (command) 67
INTERNALDATE (fetch item) 79 INTERNALDATE (fetch item) 80
INTERNALDATE (fetch result) 110 INTERNALDATE (fetch result) 111
INUSE (response code) 91 INUSE (response code) 92
Internal Date (message attribute) 12 Internal Date (message attribute) 12
K K
KEYWORD <flag> (search key) 73 KEYWORD <flag> (search key) 74
Keyword (type of flag) 12 Keyword (type of flag) 12
L L
LARGER <n> (search key) 73 LARGER <n> (search key) 74
LIMIT (response code) 92 LIMIT (response code) 93
LIST (command) 41 LIST (command) 41
LIST (response) 99 LIST (response) 100
LOGOUT (command) 26 LOGOUT (command) 26
M M
MAX (search result option) 71 MAX (search result option) 72
MAY (specification requirement term) 5 MAY (specification requirement term) 5
MESSAGES (status item) 63 MESSAGES (status item) 64
MIME (part specifier) 78 MIME (part specifier) 79
MIN (search result option) 71 MIN (search result option) 72
MOVE (command) 82 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) 57 NAMESPACE (command) 58
NAMESPACE (response) 102 NAMESPACE (response) 103
NO (response) 95 NO (response) 96
NONEXISTENT (response code) 92 NONEXISTENT (response code) 93
NOOP (command) 25 NOOP (command) 25
NOPERM (response code) 92 NOPERM (response code) 93
NOT <search-key> (search key) 73 NOT <search-key> (search key) 74
NOT RECOMMENDED (specification requirement term) 5 NOT RECOMMENDED (specification requirement term) 5
O O
OK (response) 95 OK (response) 96
ON <date> (search key) 73 ON <date> (search key) 74
OPTIONAL (specification requirement term) 5 OPTIONAL (specification requirement term) 5
OR <search-key1> <search-key2> (search key) 73 OR <search-key1> <search-key2> (search key) 74
OVERQUOTA (response code) 92 OVERQUOTA (response code) 93
P P
PARSE (response code) 93 PARSE (response code) 94
PERMANENTFLAGS (response code) 93 PERMANENTFLAGS (response code) 94
PREAUTH (response) 96 PREAUTH (response) 97
PRIVACYREQUIRED (response code) 93 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) 93 READ-ONLY (response code) 94
READ-WRITE (response code) 94 READ-WRITE (response code) 95
RECOMMENDED (specification requirement term) 5 RECOMMENDED (specification requirement term) 5
RENAME (command) 39 RENAME (command) 39
REQUIRED (specification requirement term) 5 REQUIRED (specification requirement term) 5
RFC822.SIZE (fetch item) 79 RFC822.SIZE (fetch item) 80
RFC822.SIZE (fetch result) 110 RFC822.SIZE (fetch result) 112
S S
SEARCH (command) 70 SEARCH (command) 71
SEEN (search key) 74 SEEN (search key) 75
SELECT (command) 34 SELECT (command) 34
SENTBEFORE <date> (search key) 74 SENTBEFORE <date> (search key) 75
SENTON <date> (search key) 74 SENTON <date> (search key) 75
SENTSINCE <date> (search key) 74 SENTSINCE <date> (search key) 75
SERVERBUG (response code) 94 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) 74 SINCE <date> (search key) 75
SIZE (status item) 63 SIZE (status item) 64
SMALLER <n> (search key) 74 SMALLER <n> (search key) 75
STARTTLS (command) 27 STARTTLS (command) 27
STATUS (command) 62 STATUS (command) 63
STATUS (response) 102 STATUS (response) 103
STORE (command) 80 STORE (command) 81
SUBJECT <string> (search key) 74 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) 77 TEXT (part specifier) 78
TEXT <string> (search key) 74 TEXT <string> (search key) 75
TO <string> (search key) 74 TO <string> (search key) 75
TRYCREATE (response code) 94 TRYCREATE (response code) 95
U U
UID (command) 84 UID (command) 85
UID (fetch item) 79 UID (fetch item) 80
UID (fetch result) 110 UID (fetch result) 112
UID <sequence set> (search key) 74 UID <sequence set> (search key) 75
UIDNEXT (response code) 94 UIDNEXT (response code) 95
UIDNEXT (status item) 63 UIDNEXT (status item) 64
UIDNOTSTICKY (response code) 94 UIDNOTSTICKY (response code) 95
UIDVALIDITY (response code) 94 UIDVALIDITY (response code) 95
UIDVALIDITY (status item) 63 UIDVALIDITY (status item) 64
UNANSWERED (search key) 74 UNANSWERED (search key) 75
UNAVAILABLE (response code) 95 UNAVAILABLE (response code) 96
UNDELETED (search key) 74 UNDELETED (search key) 75
UNDRAFT (search key) 74 UNDRAFT (search key) 75
UNFLAGGED (search key) 74 UNFLAGGED (search key) 75
UNKEYWORD <flag> (search key) 74 UNKEYWORD <flag> (search key) 75
UNKNOWN-CTE (response code) 95 UNKNOWN-CTE (response code) 96
UNSEEN (search key) 74 UNSEEN (search key) 75
UNSEEN (status item) 63 UNSEEN (status item) 64
UNSELECT (command) 69 UNSELECT (command) 70
UNSUBSCRIBE (command) 41 UNSUBSCRIBE (command) 41
Unique Identifier (UID) (message attribute) 9 Unique Identifier (UID) (message attribute) 9
X X
X<atom> (command) 85 X<atom> (command) 86
[ [
[RFC-5322] Size (message attribute) 13 [RFC-5322] Size (message attribute) 13
\ \
\All (mailbox name attribute) 100 \All (mailbox name attribute) 101
\Answered (system flag) 11 \Answered (system flag) 11
\Archive (mailbox name attribute) 101 \Archive (mailbox name attribute) 102
\Deleted (system flag) 12 \Deleted (system flag) 12
\Draft (system flag) 12 \Draft (system flag) 12
\Drafts (mailbox name attribute) 101 \Drafts (mailbox name attribute) 102
\Flagged (mailbox name attribute) 101 \Flagged (mailbox name attribute) 102
\Flagged (system flag) 11 \Flagged (system flag) 11
\HasChildren (mailbox name attribute) 99 \HasChildren (mailbox name attribute) 100
\HasNoChildren (mailbox name attribute) 100 \HasNoChildren (mailbox name attribute) 101
\Junk (mailbox name attribute) 101 \Junk (mailbox name attribute) 102
\Marked (mailbox name attribute) 100 \Marked (mailbox name attribute) 101
\Noinferiors (mailbox name attribute) 99 \Noinferiors (mailbox name attribute) 100
\NonExistent (mailbox name attribute) 99 \NonExistent (mailbox name attribute) 100
\Noselect (mailbox name attribute) 99 \Noselect (mailbox name attribute) 100
\Recent (system flag) 12 \Recent (system flag) 12
\Remote (mailbox name attribute) 100 \Remote (mailbox name attribute) 101
\Seen (system flag) 11 \Seen (system flag) 11
\Sent (mailbox name attribute) 101 \Sent (mailbox name attribute) 102
\Subscribed (mailbox name attribute) 100 \Subscribed (mailbox name attribute) 101
\Trash (mailbox name attribute) 101 \Trash (mailbox name attribute) 102
\Unmarked (mailbox name attribute) 100 \Unmarked (mailbox name attribute) 101
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. 68 change blocks. 
265 lines changed or deleted 292 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/