< draft-ietf-extra-imap4rev2-25.txt   draft-ietf-extra-imap4rev2-26.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: July 24, 2021 January 20, 2021 Expires: July 28, 2021 January 24, 2021
Internet Message Access Protocol (IMAP) - Version 4rev2 Internet Message Access Protocol (IMAP) - Version 4rev2
draft-ietf-extra-imap4rev2-25 draft-ietf-extra-imap4rev2-26
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 48 skipping to change at page 1, line 48
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 July 24, 2021. This Internet-Draft will expire on July 28, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 . . . . . . . . . . 33 6.3. Client Commands - Authenticated State . . . . . . . . . . 33
6.3.1. ENABLE Command . . . . . . . . . . . . . . . . . . . 34 6.3.1. ENABLE Command . . . . . . . . . . . . . . . . . . . 34
6.3.2. SELECT Command . . . . . . . . . . . . . . . . . . . 36 6.3.2. SELECT Command . . . . . . . . . . . . . . . . . . . 36
6.3.3. EXAMINE Command . . . . . . . . . . . . . . . . . . . 38 6.3.3. EXAMINE Command . . . . . . . . . . . . . . . . . . . 38
6.3.4. CREATE Command . . . . . . . . . . . . . . . . . . . 39 6.3.4. CREATE Command . . . . . . . . . . . . . . . . . . . 39
6.3.5. DELETE Command . . . . . . . . . . . . . . . . . . . 40 6.3.5. DELETE Command . . . . . . . . . . . . . . . . . . . 40
6.3.6. RENAME Command . . . . . . . . . . . . . . . . . . . 42 6.3.6. RENAME Command . . . . . . . . . . . . . . . . . . . 42
6.3.7. SUBSCRIBE Command . . . . . . . . . . . . . . . . . . 44 6.3.7. SUBSCRIBE Command . . . . . . . . . . . . . . . . . . 44
6.3.8. UNSUBSCRIBE Command . . . . . . . . . . . . . . . . . 45 6.3.8. UNSUBSCRIBE Command . . . . . . . . . . . . . . . . . 45
6.3.9. LIST Command . . . . . . . . . . . . . . . . . . . . 45 6.3.9. LIST Command . . . . . . . . . . . . . . . . . . . . 45
6.3.10. NAMESPACE Command . . . . . . . . . . . . . . . . . . 63 6.3.10. NAMESPACE Command . . . . . . . . . . . . . . . . . . 64
6.3.11. STATUS Command . . . . . . . . . . . . . . . . . . . 68 6.3.11. STATUS Command . . . . . . . . . . . . . . . . . . . 68
6.3.12. APPEND Command . . . . . . . . . . . . . . . . . . . 69 6.3.12. APPEND Command . . . . . . . . . . . . . . . . . . . 69
6.3.13. IDLE Command . . . . . . . . . . . . . . . . . . . . 72 6.3.13. IDLE Command . . . . . . . . . . . . . . . . . . . . 72
6.4. Client Commands - Selected State . . . . . . . . . . . . 74 6.4. Client Commands - Selected State . . . . . . . . . . . . 74
6.4.1. CLOSE Command . . . . . . . . . . . . . . . . . . . . 75 6.4.1. CLOSE Command . . . . . . . . . . . . . . . . . . . . 75
6.4.2. UNSELECT Command . . . . . . . . . . . . . . . . . . 75 6.4.2. UNSELECT Command . . . . . . . . . . . . . . . . . . 75
6.4.3. EXPUNGE Command . . . . . . . . . . . . . . . . . . . 76 6.4.3. EXPUNGE Command . . . . . . . . . . . . . . . . . . . 76
6.4.4. SEARCH Command . . . . . . . . . . . . . . . . . . . 76 6.4.4. SEARCH Command . . . . . . . . . . . . . . . . . . . 76
6.4.5. FETCH Command . . . . . . . . . . . . . . . . . . . . 88 6.4.5. FETCH Command . . . . . . . . . . . . . . . . . . . . 88
6.4.6. STORE Command . . . . . . . . . . . . . . . . . . . . 93 6.4.6. STORE Command . . . . . . . . . . . . . . . . . . . . 93
skipping to change at page 5, line 4 skipping to change at page 5, line 4
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 149 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 149
12.1. Updates to IMAP4 Capabilities registry . . . . . . . . . 149 12.1. Updates to IMAP4 Capabilities registry . . . . . . . . . 149
12.2. GSSAPI/SASL service name . . . . . . . . . . . . . . . . 149 12.2. GSSAPI/SASL service name . . . . . . . . . . . . . . . . 149
12.3. LIST Selection Options, LIST Return Options, LIST 12.3. LIST Selection Options, LIST Return Options, LIST
extended data items . . . . . . . . . . . . . . . . . . 150 extended data items . . . . . . . . . . . . . . . . . . 150
12.4. IMAP Mailbox Name Attributes and IMAP Response Codes . . 150 12.4. IMAP Mailbox Name Attributes and IMAP Response Codes . . 150
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 150 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 150
13.1. Normative References . . . . . . . . . . . . . . . . . . 150 13.1. Normative References . . . . . . . . . . . . . . . . . . 150
13.2. Informative References (related protocols) . . . . . . . 153 13.2. Informative References (related protocols) . . . . . . . 153
13.3. Informative References (historical aspects of IMAP and 13.3. Informative References (historical aspects of IMAP and
related protocols) . . . . . . . . . . . . . . . . . . . 155 related protocols) . . . . . . . . . . . . . . . . . . . 156
Appendix A. Backward compatibility with IMAP4rev1 . . . . . . . 156 Appendix A. Backward compatibility with IMAP4rev1 . . . . . . . 156
A.1. Mailbox International Naming Convention for compatibility A.1. Mailbox International Naming Convention for compatibility
with IMAP4rev1 . . . . . . . . . . . . . . . . . . . . . 157 with IMAP4rev1 . . . . . . . . . . . . . . . . . . . . . 157
Appendix B. Backward compatibility with BINARY extension . . . . 158 Appendix B. Backward compatibility with BINARY extension . . . . 159
Appendix C. Backward compatibility with LIST-EXTENDED extension 158 Appendix C. Backward compatibility with LIST-EXTENDED extension 159
Appendix D. 63 bit body part and message sizes . . . . . . . . . 159 Appendix D. 63 bit body part and message sizes . . . . . . . . . 159
Appendix E. Changes from RFC 3501 / IMAP4rev1 . . . . . . . . . 159 Appendix E. Changes from RFC 3501 / IMAP4rev1 . . . . . . . . . 159
Appendix F. Other Recommended IMAP Extensions . . . . . . . . . 161 Appendix F. Other Recommended IMAP Extensions . . . . . . . . . 161
Appendix G. Acknowledgement . . . . . . . . . . . . . . . . . . 161 Appendix G. Acknowledgement . . . . . . . . . . . . . . . . . . 162
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 167 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 168
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 7, line 29 skipping to change at page 7, line 29
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
reference to the updated [RFC-5322] standard. reference to the updated [RFC-5322] standard.
2. Protocol Overview 2. Protocol Overview
2.1. Link Level 2.1. Link Level
The IMAP4rev2 protocol assumes a reliable data stream such as that The IMAP4rev2 protocol assumes a reliable data stream such as that
provided by TCP. When TCP is used, an IMAP4rev2 server listens on provided by TCP. When TCP is used, an IMAP4rev2 server listens on
port 143 or port 993 (IMAP-over-TLS). port 143 (cleartext port) or port 993 (Implicit TLS port).
2.2. Commands and Responses 2.2. Commands and Responses
An IMAP4rev2 connection consists of the establishment of a client/ An IMAP4rev2 connection consists of the establishment of a client/
server network connection, an initial greeting from the server, and server network connection, an initial greeting from the server, and
client/server interactions. These client/server interactions consist client/server interactions. These client/server interactions consist
of a client command, server data, and a server completion result of a client command, server data, and a server completion result
response. response.
All interactions transmitted by client and server are in the form of All interactions transmitted by client and server are in the form of
skipping to change at page 31, line 30 skipping to change at page 31, line 30
the tagged OK response for the server. the tagged OK response for the server.
While client and server implementations MUST implement the While client and server implementations MUST implement the
AUTHENTICATE command itself, it is not required to implement any AUTHENTICATE command itself, it is not required to implement any
authentication mechanisms other than the PLAIN mechanism described in authentication mechanisms other than the PLAIN mechanism described in
[PLAIN]. Also, an authentication mechanism is not required to [PLAIN]. Also, an authentication mechanism is not required to
support any security layers. support any security layers.
Note: a server implementation MUST implement a configuration in Note: a server implementation MUST implement a configuration in
which it does NOT permit any plaintext password mechanisms, unless which it does NOT permit any plaintext password mechanisms, unless
either the STARTTLS command has been negotiated or some other either the STARTTLS command has been negotiated, TLS has been
mechanism that protects the session from password snooping has negotiated on an Implicit TLS port, or some other mechanism that
been provided. Server sites SHOULD NOT use any configuration protects the session from password snooping has been provided.
which permits a plaintext password mechanism without such a Server sites SHOULD NOT use any configuration which permits a
protection mechanism against password snooping. Client and server plaintext password mechanism without such a protection mechanism
implementations SHOULD implement additional [SASL] mechanisms that against password snooping. Client and server implementations
do not use plaintext passwords, such the GSSAPI mechanism SHOULD implement additional [SASL] mechanisms that do not use
described in [SASL] and/or the SCRAM-SHA-256/SCRAM-SHA-256-PLUS plaintext passwords, such the GSSAPI mechanism described in
[SCRAM-SHA-256] mechanisms. [RFC4752], the SCRAM-SHA-256/SCRAM-SHA-256-PLUS [SCRAM-SHA-256]
mechanisms and/or EXTERNAL [SASL] mechanism for mutual TLS
authentication. (Note that SASL framework allows creation of SASL
mechanisms that support 2FA (2-factor authentication), however
none are fully ready to be recommended by this document.)
Servers and clients can support multiple authentication mechanisms. Servers and clients can support multiple authentication mechanisms.
The server SHOULD list its supported authentication mechanisms in the The server SHOULD list its supported authentication mechanisms in the
response to the CAPABILITY command so that the client knows which response to the CAPABILITY command so that the client knows which
authentication mechanisms to use. authentication mechanisms to use.
A server MAY include a CAPABILITY response code in the tagged OK A server MAY include a CAPABILITY response code in the tagged OK
response of a successful AUTHENTICATE command in order to send response of a successful AUTHENTICATE command in order to send
capabilities automatically. It is unnecessary for a client to send a capabilities automatically. It is unnecessary for a client to send a
separate CAPABILITY command if it recognizes these automatic separate CAPABILITY command if it recognizes these automatic
skipping to change at page 33, line 36 skipping to change at page 33, line 36
CAPABILITY command if it recognizes these automatic capabilities. CAPABILITY command if it recognizes these automatic capabilities.
Example: C: a001 LOGIN SMITH SESAME Example: C: a001 LOGIN SMITH SESAME
S: a001 OK LOGIN completed S: a001 OK LOGIN completed
Note: Use of the LOGIN command over an insecure network (such as the Note: Use of the LOGIN command over an insecure network (such as the
Internet) is a security risk, because anyone monitoring network Internet) is a security risk, because anyone monitoring network
traffic can obtain plaintext passwords. For that reason clients MUST traffic can obtain plaintext passwords. For that reason clients MUST
NOT use LOGIN on unsecure networks. NOT use LOGIN on unsecure networks.
Unless either the client is accessing IMAP service on IMAPS port Unless either the client is accessing IMAP service on Implicit TLS
[RFC8314], the STARTTLS command has been negotiated or some other port [RFC8314], the STARTTLS command has been negotiated or some
mechanism that protects the session from password snooping has been other mechanism that protects the session from password snooping has
provided, a server implementation MUST implement a configuration in been provided, a server implementation MUST implement a configuration
which it advertises the LOGINDISABLED capability and does NOT permit in which it advertises the LOGINDISABLED capability and does NOT
the LOGIN command. Server sites SHOULD NOT use any configuration permit the LOGIN command. Server sites SHOULD NOT use any
which permits the LOGIN command without such a protection mechanism configuration which permits the LOGIN command without such a
against password snooping. A client implementation MUST NOT send a protection mechanism against password snooping. A client
LOGIN command if the LOGINDISABLED capability is advertised. implementation MUST NOT send a LOGIN command if the LOGINDISABLED
capability is advertised.
6.3. Client Commands - Authenticated State 6.3. Client Commands - Authenticated State
In the authenticated state, commands that manipulate mailboxes as In the authenticated state, commands that manipulate mailboxes as
atomic entities are permitted. Of these commands, the SELECT and atomic entities are permitted. Of these commands, the SELECT and
EXAMINE commands will select a mailbox for access and enter the EXAMINE commands will select a mailbox for access and enter the
selected state. selected state.
In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
the following commands are valid in the authenticated state: ENABLE, the following commands are valid in the authenticated state: ENABLE,
skipping to change at page 50, line 28 skipping to change at page 50, line 28
attribute MUST be supported and MUST be accurately computed when attribute MUST be supported and MUST be accurately computed when
the SUBSCRIBED selection option is specified. the SUBSCRIBED selection option is specified.
Note that the SUBSCRIBED selection option implies the SUBSCRIBED Note that the SUBSCRIBED selection option implies the SUBSCRIBED
return option (see below). return option (see below).
REMOTE - causes the LIST command to show remote mailboxes as well as REMOTE - causes the LIST command to show remote mailboxes as well as
local ones, as described in [RFC2193]. This option is intended to local ones, as described in [RFC2193]. This option is intended to
replace the RLIST command and, in conjunction with the SUBSCRIBED replace the RLIST command and, in conjunction with the SUBSCRIBED
selection option, the RLSUB command. Servers that don't support selection option, the RLSUB command. Servers that don't support
remote mailboxes just ignore this option. the concept of remote mailboxes just ignore this option.
This option defines a mailbox attribute, "\Remote", that indicates This option defines a mailbox attribute, "\Remote", that indicates
that a mailbox is a remote mailbox. The "\Remote" attribute MUST that a mailbox is a remote mailbox. The "\Remote" attribute MUST
be accurately computed when the REMOTE option is specified. be accurately computed when the REMOTE option is specified.
The REMOTE selection option has no interaction with other options. The REMOTE selection option has no interaction with other options.
Its effect is to tell the server to apply the other options, if Its effect is to tell the server to apply the other options, if
any, to remote mailboxes, in addition to local ones. In any, to remote mailboxes, in addition to local ones. In
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
skipping to change at page 51, line 28 skipping to change at page 51, line 28
they can be deleted/renamed after the LIST response was sent, but they can be deleted/renamed after the LIST response was sent, but
before the client had a chance to access them. before the client had a chance to access them.
6.3.9.2. LIST Return Options 6.3.9.2. LIST Return Options
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 other mailbox attributes
accurately computed (this differs from the behavior of the MUST be accurately computed (this differs from the behavior of the
obsolete LSUB command from IMAP4rev1). obsolete LSUB command from RFC 3501). Note that the above
requirements don't override the requirement for the LIST command
to return results quickly (see Section 6.3.9), i.e. server
implementations need to compute results quickly and accurately.
For example, server implementors might need to create quick access
indices.
CHILDREN - requests mailbox child information as originally proposed CHILDREN - requests mailbox child information as originally proposed
in [RFC3348]. See Section 6.3.9.5, below, for details. in [RFC3348]. See Section 6.3.9.5, below, for details.
STATUS - requests STATUS response for each matching mailbox. STATUS - requests STATUS response for each matching mailbox.
This option takes STATUS data items as parameters. For each This option takes STATUS data items as parameters. For each
selectable mailbox matching the list pattern and selection selectable mailbox matching the list pattern and selection
options, the server MUST return an untagged LIST response options, the server MUST return an untagged LIST response
followed by an untagged STATUS response containing the followed by an untagged STATUS response containing the
skipping to change at page 107, line 6 skipping to change at page 107, line 6
to return a new PERMANENTFLAGS response code when a new keyword to return a new PERMANENTFLAGS response code when a new keyword
was successfully set on a message upon client request. However was successfully set on a message upon client request. However
if the server has a limit on the number of different keywords if the server has a limit on the number of different keywords
that can be stored in a mailbox and that limit is reached, the that can be stored in a mailbox and that limit is reached, the
server MUST send a new PERMANENTFLAGS response code without the server MUST send a new PERMANENTFLAGS response code without the
special flag \*. special flag \*.
PRIVACYREQUIRED PRIVACYREQUIRED
The operation is not permitted due to a lack of privacy. If The operation is not permitted due to a lack of privacy. If
Transport Layer Security (TLS) is not in use, the client could Transport Layer Security (TLS) is not in use, the client could
try STARTTLS (see Section 6.2.1) and then repeat the operation. try STARTTLS (see Section 6.2.1) or alternatively reconnect to
Implicit TLS port, and then repeat the operation.
C: d login "fred" "foo" C: d login "fred" "foo"
S: d NO [PRIVACYREQUIRED] Connection offers no privacy S: d NO [PRIVACYREQUIRED] Connection offers no privacy
C: d select inbox C: d select inbox
S: d NO [PRIVACYREQUIRED] Connection offers no privacy S: d NO [PRIVACYREQUIRED] Connection offers no privacy
READ-ONLY READ-ONLY
The mailbox is selected read-only, or its access while selected The mailbox is selected read-only, or its access while selected
skipping to change at page 110, line 19 skipping to change at page 110, line 19
The PREAUTH response is always untagged, and is one of three possible The PREAUTH response is always untagged, and is one of three possible
greetings at connection startup. It indicates that the connection greetings at connection startup. It indicates that the connection
has already been authenticated by external means; thus no LOGIN/ has already been authenticated by external means; thus no LOGIN/
AUTHENTICATE command is needed. AUTHENTICATE command is needed.
Because PREAUTH moves the connection directly to the authenticated Because PREAUTH moves the connection directly to the authenticated
state, it effectively prevents the client from using the STARTTLS state, it effectively prevents the client from using the STARTTLS
command Section 6.2.1. For this reason PREAUTH response SHOULD only command Section 6.2.1. For this reason PREAUTH response SHOULD only
be returned by servers on connections that are protected by TLS (such be returned by servers on connections that are protected by TLS (such
as on IMAPS port [RFC8314]) or protected through other means such as as on implicit TLS port [RFC8314]) or protected through other means
IPSec. Clients that require mandatory TLS MUST close the connection such as IPSec. Clients that require mandatory TLS MUST close the
after receiving PREAUTH response on a non protected port. connection after receiving PREAUTH response on a non protected port.
Example: S: * PREAUTH IMAP4rev2 server logged in as Smith Example: S: * PREAUTH IMAP4rev2 server logged in as Smith
7.1.5. BYE Response 7.1.5. BYE Response
Contents: OPTIONAL response code Contents: OPTIONAL response code
human-readable text human-readable text
The BYE response is always untagged, and indicates that the server is The BYE response is always untagged, and indicates that the server is
about to close the connection. The human-readable text MAY be about to close the connection. The human-readable text MAY be
skipping to change at page 112, line 14 skipping to change at page 112, line 14
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 SHOULD be registered with IANA using RFC Required Capability names SHOULD be registered with IANA using RFC Required
policy. A server SHOULD NOT offer unregistered capability names. policy. A server SHOULD NOT offer unregistered capability names.
Client implementations SHOULD NOT require any capability name other Client implementations SHOULD NOT require any capability name other
than "IMAP4rev2", "STARTTLS", "LOGINDISABLED". Client than "IMAP4rev2", and possibly "STARTTLS" and "LOGINDISABLED" (on a
implementations MUST ignore any unknown capability names. non implicit TLS port). Client implementations 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
send a separate CAPABILITY command if it recognizes these automatic send a separate CAPABILITY command if it recognizes these automatic
capabilities. capabilities.
The list of capabilities returned by a server MAY change during the The list of capabilities returned by a server MAY change during the
connection. In particular, it is quite common for the server to connection. In particular, it is quite common for the server to
skipping to change at page 146, line 9 skipping to change at page 146, line 9
This document is a revision or rewrite of earlier documents, and This document is a revision or rewrite of earlier documents, and
supercedes the protocol specification in those documents: RFC 3501, supercedes the protocol specification in those documents: RFC 3501,
RFC 2060, RFC 1730, unpublished IMAP2bis.TXT document, RFC 1176, and RFC 2060, RFC 1730, unpublished IMAP2bis.TXT document, RFC 1176, and
RFC 1064. RFC 1064.
11. Security Considerations 11. Security Considerations
IMAP4rev2 protocol transactions, including electronic mail data, are IMAP4rev2 protocol transactions, including electronic mail data, are
sent in the clear over the network unless protection from snooping is sent in the clear over the network unless protection from snooping is
negotiated. This can be accomplished either by the use of IMAPS negotiated. This can be accomplished either by the use of Implicit
service, STARTTLS command, negotiated privacy protection in the TLS port, STARTTLS command, negotiated privacy protection in the
AUTHENTICATE command, or some other protection mechanism. AUTHENTICATE command, or some other protection mechanism.
11.1. TLS related Security Considerations 11.1. TLS related Security Considerations
This section applies to both use of STARTTLS command and Implicit TLS This section applies to both use of STARTTLS command and Implicit TLS
port. port.
IMAP client and server implementations MUST comply with relevant TLS IMAP client and server implementations MUST comply with relevant TLS
recommendations from [RFC8314]. recommendations from [RFC8314].
skipping to change at page 146, line 49 skipping to change at page 146, line 49
prevent man-in-the-middle attacks. This procedure is described in prevent man-in-the-middle attacks. This procedure is described in
[RFC7817]. [RFC7817].
Both the client and server MUST check the result of the STARTTLS Both the client and server MUST check the result of the STARTTLS
command and subsequent TLS ([TLS-1.3][TLS-1.2]) negotiation to see command and subsequent TLS ([TLS-1.3][TLS-1.2]) negotiation to see
whether acceptable authentication and/or privacy was achieved. whether acceptable authentication and/or privacy was achieved.
11.2. STARTTLS command versa use of Implicit TLS port 11.2. STARTTLS command versa use of Implicit TLS port
For maximum backward compatibility clients MUST implement both TLS For maximum backward compatibility clients MUST implement both TLS
negotiation using STARTTLS command and on implicit TLS port. negotiation on implicit TLS port and TLS negotiation using STARTTLS
command.
Servers MUST support TLS negotiation on implicit TLS port and SHOULD Servers MUST implement TLS negotiation on implicit TLS port and
support STARTTLS command. SHOULD implement STARTTLS command on cleartext port.
Some site/firewall maintainers insist on TLS site-wide and prefer not Some site/firewall maintainers insist on TLS site-wide and prefer not
to rely on a configuration option in each higher-level protocol. For to rely on a configuration option in each higher-level protocol. For
this reason, IMAP4rev2 clients SHOULD try both ports 993 and 143 (and this reason, IMAP4rev2 clients SHOULD try both ports 993 and 143 (and
both IPv4 and IPv6) concurrently by default, unless overriden by both IPv4 and IPv6) concurrently by default, unless overriden by
either user configuration or SRV records. Note that if a server either user configuration or DNS SRV records [RFC6186]. Note that if
answers on both ports, it MUST allow STARTTLS command on port 143. a server answers on both ports, it MUST allow STARTTLS command on
port 143.
11.3. Client handling of unsolicited responses not suitable for the 11.3. Client handling of unsolicited responses not suitable for the
current connection state current connection state
Cleartext mail transmission (whether caused by firewall configuration Cleartext mail transmission (whether caused by firewall configuration
errors that result in TLS stripping or weak security policies in errors that result in TLS stripping or weak security policies in
email clients that choose not to negotiate TLS in the first place) email clients that choose not to negotiate TLS in the first place)
can enable injection of responses that can confuse or even cause can enable injection of responses that can confuse or even cause
crashes in email clients. The following measures are recommended to crashes in email clients. The following measures are recommended to
minimize damage from them. minimize damage from them.
skipping to change at page 150, line 35 skipping to change at page 150, line 35
IANA is requested to update the "IMAP Mailbox Name Attributes" IANA is requested to update the "IMAP Mailbox Name Attributes"
registry to point to this document in addition to RFC 3501. registry to point to this document in addition to RFC 3501.
IANA is requested to update the "IMAP Response Codes" registry to IANA is requested to update the "IMAP Response Codes" registry to
point to this document in addition to RFC 3501. point to this document in addition to RFC 3501.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC4752] Melnikov, A., Ed., "The Kerberos V5 ("GSSAPI") Simple
Authentication and Security Layer (SASL) Mechanism",
RFC 4752, DOI 10.17487/RFC4752, November 2006,
<https://www.rfc-editor.org/info/rfc4752>.
[RFC5258] Leiba, B. and A. Melnikov, "Internet Message Access [RFC5258] Leiba, B. and A. Melnikov, "Internet Message Access
Protocol version 4 - LIST Command Extensions", RFC 5258, Protocol version 4 - LIST Command Extensions", RFC 5258,
DOI 10.17487/RFC5258, June 2008, DOI 10.17487/RFC5258, June 2008,
<https://www.rfc-editor.org/info/rfc5258>. <https://www.rfc-editor.org/info/rfc5258>.
[RFC5788] Melnikov, A. and D. Cridland, "IMAP4 Keyword Registry", [RFC5788] Melnikov, A. and D. Cridland, "IMAP4 Keyword Registry",
RFC 5788, DOI 10.17487/RFC5788, March 2010, RFC 5788, DOI 10.17487/RFC5788, March 2010,
<https://www.rfc-editor.org/info/rfc5788>. <https://www.rfc-editor.org/info/rfc5788>.
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
skipping to change at page 154, line 5 skipping to change at page 154, line 10
RFC 2180, July 1997, RFC 2180, July 1997,
<http://www.rfc-editor.org/info/rfc2180>. <http://www.rfc-editor.org/info/rfc2180>.
13.2. Informative References (related protocols) 13.2. Informative References (related protocols)
[CERT-555316] [CERT-555316]
CERT, "Vulnerability Note VU#555316: STARTTLS plaintext CERT, "Vulnerability Note VU#555316: STARTTLS plaintext
command injection vulnerability", September 2011, command injection vulnerability", September 2011,
<https://www.kb.cert.org/vuls/id/555316>. <https://www.kb.cert.org/vuls/id/555316>.
[RFC2193] Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193,
DOI 10.17487/RFC2193, September 1997,
<https://www.rfc-editor.org/info/rfc2193>.
[RFC3348] Gahrns, M. and R. Cheng, "The Internet Message Action
Protocol (IMAP4) Child Mailbox Extension", RFC 3348,
DOI 10.17487/RFC3348, July 2002,
<https://www.rfc-editor.org/info/rfc3348>.
[RFC3503] Melnikov, A., "Message Disposition Notification (MDN) [RFC3503] Melnikov, A., "Message Disposition Notification (MDN)
profile for Internet Message Access Protocol (IMAP)", profile for Internet Message Access Protocol (IMAP)",
RFC 3503, DOI 10.17487/RFC3503, March 2003, RFC 3503, DOI 10.17487/RFC3503, March 2003,
<https://www.rfc-editor.org/info/rfc3503>. <https://www.rfc-editor.org/info/rfc3503>.
[RFC5256] Crispin, M. and K. Murchison, "Internet Message Access [RFC5256] Crispin, M. and K. Murchison, "Internet Message Access
Protocol - SORT and THREAD Extensions", RFC 5256, Protocol - SORT and THREAD Extensions", RFC 5256,
DOI 10.17487/RFC5256, June 2008, DOI 10.17487/RFC5256, June 2008,
<https://www.rfc-editor.org/info/rfc5256>. <https://www.rfc-editor.org/info/rfc5256>.
[RFC2193] Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193,
DOI 10.17487/RFC2193, September 1997,
<https://www.rfc-editor.org/info/rfc2193>.
[RFC3348] Gahrns, M. and R. Cheng, "The Internet Message Action
Protocol (IMAP4) Child Mailbox Extension", RFC 3348,
DOI 10.17487/RFC3348, July 2002,
<https://www.rfc-editor.org/info/rfc3348>.
[RFC5465] Gulbrandsen, A., King, C., and A. Melnikov, "The IMAP [RFC5465] Gulbrandsen, A., King, C., and A. Melnikov, "The IMAP
NOTIFY Extension", RFC 5465, DOI 10.17487/RFC5465, NOTIFY Extension", RFC 5465, DOI 10.17487/RFC5465,
February 2009, <https://www.rfc-editor.org/info/rfc5465>. February 2009, <https://www.rfc-editor.org/info/rfc5465>.
[RFC6186] Daboo, C., "Use of SRV Records for Locating Email
Submission/Access Services", RFC 6186,
DOI 10.17487/RFC6186, March 2011,
<https://www.rfc-editor.org/info/rfc6186>.
[RFC7888] Melnikov, A., Ed., "IMAP4 Non-synchronizing Literals", [RFC7888] Melnikov, A., Ed., "IMAP4 Non-synchronizing Literals",
RFC 7888, DOI 10.17487/RFC7888, May 2016, RFC 7888, DOI 10.17487/RFC7888, May 2016,
<https://www.rfc-editor.org/info/rfc7888>. <https://www.rfc-editor.org/info/rfc7888>.
[IMAP-DISC] [IMAP-DISC]
Melnikov, A., Ed., "Synchronization Operations for Melnikov, A., Ed., "Synchronization Operations for
Disconnected IMAP4 Clients", RFC 4549, June 2006, Disconnected IMAP4 Clients", RFC 4549, June 2006,
<http://www.rfc-editor.org/info/rfc4549>. <http://www.rfc-editor.org/info/rfc4549>.
[IMAP-I18N] [IMAP-I18N]
skipping to change at page 165, line 19 skipping to change at page 165, line 35
MAY (specification requirement term) 5 MAY (specification requirement term) 5
MESSAGES (status item) 69 MESSAGES (status item) 69
MIME (part specifier) 92 MIME (part specifier) 92
MIN (search result option) 77 MIN (search result option) 77
MOVE (command) 95 MOVE (command) 95
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) 63 NAMESPACE (command) 64
NAMESPACE (response) 116 NAMESPACE (response) 116
NO (response) 109 NO (response) 109
NONEXISTENT (response code) 105 NONEXISTENT (response code) 105
NOOP (command) 27 NOOP (command) 27
NOPERM (response code) 105 NOPERM (response code) 105
NOT <search-key> (search key) 80 NOT <search-key> (search key) 80
NOT RECOMMENDED (specification requirement term) 5 NOT RECOMMENDED (specification requirement term) 5
O O
OK (response) 108 OK (response) 108
 End of changes. 25 change blocks. 
55 lines changed or deleted 79 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/