< draft-ietf-extra-imap4rev2-18.txt   draft-ietf-extra-imap4rev2-19.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: March 19, 2021 September 15, 2020 Expires: April 30, 2021 October 27, 2020
Internet Message Access Protocol (IMAP) - Version 4rev2 Internet Message Access Protocol (IMAP) - Version 4rev2
draft-ietf-extra-imap4rev2-18 draft-ietf-extra-imap4rev2-19
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 March 19, 2021. This Internet-Draft will expire on April 30, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 4 skipping to change at page 3, line 4
2.3. Message Attributes . . . . . . . . . . . . . . . . . . . 9 2.3. Message Attributes . . . . . . . . . . . . . . . . . . . 9
2.3.1. Message Numbers . . . . . . . . . . . . . . . . . . . 9 2.3.1. Message Numbers . . . . . . . . . . . . . . . . . . . 9
2.3.2. Flags Message Attribute . . . . . . . . . . . . . . . 11 2.3.2. Flags Message Attribute . . . . . . . . . . . . . . . 11
2.3.3. Internal Date Message Attribute . . . . . . . . . . . 13 2.3.3. Internal Date Message Attribute . . . . . . . . . . . 13
2.3.4. [RFC-5322] Size Message Attribute . . . . . . . . . . 14 2.3.4. [RFC-5322] Size Message Attribute . . . . . . . . . . 14
2.3.5. Envelope Structure Message Attribute . . . . . . . . 14 2.3.5. Envelope Structure Message Attribute . . . . . . . . 14
2.3.6. Body Structure Message Attribute . . . . . . . . . . 14 2.3.6. Body Structure Message Attribute . . . . . . . . . . 14
2.4. Message Texts . . . . . . . . . . . . . . . . . . . . . . 14 2.4. Message Texts . . . . . . . . . . . . . . . . . . . . . . 14
3. State and Flow Diagram . . . . . . . . . . . . . . . . . . . 14 3. State and Flow Diagram . . . . . . . . . . . . . . . . . . . 14
3.1. Not Authenticated State . . . . . . . . . . . . . . . . . 14 3.1. Not Authenticated State . . . . . . . . . . . . . . . . . 14
3.2. Authenticated State . . . . . . . . . . . . . . . . . . . 14 3.2. Authenticated State . . . . . . . . . . . . . . . . . . . 15
3.3. Selected State . . . . . . . . . . . . . . . . . . . . . 15 3.3. Selected State . . . . . . . . . . . . . . . . . . . . . 15
3.4. Logout State . . . . . . . . . . . . . . . . . . . . . . 15 3.4. Logout State . . . . . . . . . . . . . . . . . . . . . . 15
4. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 17 4. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1. Atom . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.1. Atom . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.1. Sequence set and UID set . . . . . . . . . . . . . . 17 4.1.1. Sequence set and UID set . . . . . . . . . . . . . . 17
4.2. Number . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2. Number . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3. String . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.3. String . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.1. 8-bit and Binary Strings . . . . . . . . . . . . . . 18 4.3.1. 8-bit and Binary Strings . . . . . . . . . . . . . . 18
4.4. Parenthesized List . . . . . . . . . . . . . . . . . . . 19 4.4. Parenthesized List . . . . . . . . . . . . . . . . . . . 19
4.5. NIL . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.5. NIL . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
skipping to change at page 4, line 40 skipping to change at page 4, line 40
7.5. Server Responses - Command Continuation Request . . . . . 124 7.5. Server Responses - Command Continuation Request . . . . . 124
8. Sample IMAP4rev2 connection . . . . . . . . . . . . . . . . . 124 8. Sample IMAP4rev2 connection . . . . . . . . . . . . . . . . . 124
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 125 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 125
10. Author's Note . . . . . . . . . . . . . . . . . . . . . . . . 143 10. Author's Note . . . . . . . . . . . . . . . . . . . . . . . . 143
11. Security Considerations . . . . . . . . . . . . . . . . . . . 143 11. Security Considerations . . . . . . . . . . . . . . . . . . . 143
11.1. STARTTLS Security Considerations . . . . . . . . . . . . 143 11.1. STARTTLS Security Considerations . . . . . . . . . . . . 143
11.2. COPYUID and APPENDUID response codes . . . . . . . . . . 144 11.2. COPYUID and APPENDUID response codes . . . . . . . . . . 144
11.3. LIST command and Other Users' namespace . . . . . . . . 144 11.3. LIST command and Other Users' namespace . . . . . . . . 144
11.4. Other Security Considerations . . . . . . . . . . . . . 144 11.4. Other Security Considerations . . . . . . . . . . . . . 144
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 145 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 145
12.1. Updates to IMAP4 Capabilities registry . . . . . . . . . 145 12.1. Updates to IMAP4 Capabilities registry . . . . . . . . . 146
12.2. GSSAPI/SASL service name . . . . . . . . . . . . . . . . 146 12.2. GSSAPI/SASL service name . . . . . . . . . . . . . . . . 146
12.3. LIST Selection Options, LIST Return Options, LIST 12.3. LIST Selection Options, LIST Return Options, LIST
extended data items . . . . . . . . . . . . . . . . . . 146 extended data items . . . . . . . . . . . . . . . . . . 146
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 146 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 146
13.1. Normative References . . . . . . . . . . . . . . . . . . 146 13.1. Normative References . . . . . . . . . . . . . . . . . . 146
13.2. Informative References (related protocols) . . . . . . . 149 13.2. Informative References (related protocols) . . . . . . . 150
13.3. Informative References (historical aspects of IMAP and 13.3. Informative References (historical aspects of IMAP and
related protocols) . . . . . . . . . . . . . . . . . . . 151 related protocols) . . . . . . . . . . . . . . . . . . . 152
Appendix A. Backward compatibility with IMAP4rev1 . . . . . . . 152 Appendix A. Backward compatibility with IMAP4rev1 . . . . . . . 152
A.1. Mailbox International Naming Convention for compatibility A.1. Mailbox International Naming Convention for compatibility
with IMAP4rev1 . . . . . . . . . . . . . . . . . . . . . 152 with IMAP4rev1 . . . . . . . . . . . . . . . . . . . . . 153
Appendix B. Backward compatibility with BINARY extension . . . . 154 Appendix B. Backward compatibility with BINARY extension . . . . 154
Appendix C. Backward compatibility with LIST-EXTENDED extension 154 Appendix C. Backward compatibility with LIST-EXTENDED extension 155
Appendix D. Changes from RFC 3501 / IMAP4rev1 . . . . . . . . . 154 Appendix D. Changes from RFC 3501 / IMAP4rev1 . . . . . . . . . 155
Appendix E. Acknowledgement . . . . . . . . . . . . . . . . . . 157 Appendix E. Other Recommended IMAP Extensions . . . . . . . . . 156
Appendix F. Acknowledgement . . . . . . . . . . . . . . . . . . 157
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 162 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 163
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 36 skipping to change at page 6, line 40
Implementors of the IMAP protocol are strongly encouraged to read the Implementors of the IMAP protocol are strongly encouraged to read the
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 and RFC 3501 that proved problematic and were
removed. In the course of the evolution of IMAP4rev2, some aspects subsequently removed or replaced by better alternatives. In the
in the earlier protocols have become obsolete. Obsolete commands, course of the evolution of IMAP4rev2, some aspects in the earlier
responses, and data formats which an IMAP4rev2 implementation can protocols have become obsolete. Obsolete commands, responses, and
encounter when used with an earlier implementation are described in data formats which an IMAP4rev2 implementation can encounter when
Appendix D and [IMAP-OBSOLETE]. used with an earlier implementation are described in Appendix D,
Appendix A and [IMAP-OBSOLETE]. IMAP4rev2 compatibility with BINARY
and LIST-EXTENDED IMAP extensions are described in Appendix B and
Appendix C respectively.
Other compatibility issues with IMAP2bis, the most common variant of Other compatibility issues with IMAP2bis, the most common variant of
the earlier protocol, are discussed in [IMAP-COMPAT]. A full the earlier protocol, are discussed in [IMAP-COMPAT]. A full
discussion of compatibility issues with rare (and presumed extinct) discussion of compatibility issues with rare (and presumed extinct)
variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is
primarily of historical interest. primarily of historical interest.
IMAP was originally developed for the older [RFC-822] standard, and IMAP was originally developed for the older [RFC-822] standard, and
as a consequence several fetch items in IMAP incorporate "RFC822" in as a consequence several fetch items in IMAP incorporate "RFC822" in
their name. In all cases, "RFC822" should be interpreted as a their name. In all cases, "RFC822" should be interpreted as a
skipping to change at page 28, line 32 skipping to change at page 28, line 32
STARTTLS, AUTHENTICATE and LOGIN. See the Security Considerations STARTTLS, AUTHENTICATE and LOGIN. See the Security Considerations
section for important information about these commands. section for important information about these commands.
6.2.1. STARTTLS Command 6.2.1. STARTTLS Command
Arguments: none Arguments: none
Responses: no specific response for this command Responses: no specific response for this command
Result: OK - starttls completed, begin TLS negotiation Result: OK - starttls completed, begin TLS negotiation
BAD - command unknown or arguments invalid BAD - STARTTLS received after a successful TLS
negotiation or arguments invalid
A [TLS] negotiation begins immediately after the CRLF at the end of A TLS [TLS-1.3] negotiation begins immediately after the CRLF at the
the tagged OK response from the server. Once a client issues a end of the tagged OK response from the server. Once a client issues
STARTTLS command, it MUST NOT issue further commands until a server a STARTTLS command, it MUST NOT issue further commands until a server
response is seen and the [TLS] negotiation is complete. response is seen and the TLS negotiation is complete.
The server remains in the non-authenticated state, even if client The server remains in the non-authenticated state, even if client
credentials are supplied during the [TLS] negotiation. This does not credentials are supplied during the TLS negotiation. This does not
preclude an authentication mechanism such as EXTERNAL (defined in preclude an authentication mechanism such as EXTERNAL (defined in
[SASL]) from using client identity determined by the [TLS] [SASL]) from using client identity determined by the TLS negotiation.
negotiation.
Once [TLS] has been started, the client MUST discard cached Once TLS has been started, the client MUST discard cached information
information about server capabilities and SHOULD re-issue the about server capabilities and SHOULD re-issue the CAPABILITY command.
CAPABILITY command. This is necessary to protect against man-in- This is necessary to protect against man-in- the-middle attacks which
the-middle attacks which alter the capabilities list prior to alter the capabilities list prior to STARTTLS. The server MAY
STARTTLS. The server MAY advertise different capabilities, and in advertise different capabilities, and in particular SHOULD NOT
particular SHOULD NOT advertise the STARTTLS capability, after a advertise the STARTTLS capability, after a successful STARTTLS
successful STARTTLS command. command.
Example: C: a001 CAPABILITY Example: C: a001 CAPABILITY
S: * CAPABILITY IMAP4rev2 STARTTLS LOGINDISABLED S: * CAPABILITY IMAP4rev2 STARTTLS LOGINDISABLED
S: a001 OK CAPABILITY completed S: a001 OK CAPABILITY completed
C: a002 STARTTLS C: a002 STARTTLS
S: a002 OK Begin TLS negotiation now S: a002 OK Begin TLS negotiation now
<TLS negotiation, further commands are under [TLS] layer> <TLS negotiation, further commands are under TLS layer>
C: a003 CAPABILITY C: a003 CAPABILITY
S: * CAPABILITY IMAP4rev2 AUTH=PLAIN S: * CAPABILITY IMAP4rev2 AUTH=PLAIN
S: a003 OK CAPABILITY completed S: a003 OK CAPABILITY completed
C: a004 LOGIN joe password C: a004 LOGIN joe password
S: a004 OK LOGIN completed S: a004 OK LOGIN completed
6.2.2. AUTHENTICATE Command 6.2.2. AUTHENTICATE Command
Arguments: SASL authentication mechanism name Arguments: SASL authentication mechanism name
OPTIONAL initial response OPTIONAL initial response
Responses: continuation data can be requested Responses: continuation data can be requested
Result: OK - authenticate completed, now in authenticated state Result: OK - authenticate completed, now in authenticated state
NO - authenticate failure: unsupported authentication NO - authenticate failure: unsupported authentication
skipping to change at page 143, line 42 skipping to change at page 143, line 42
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 IMAPS
service, STARTTLS command, negotiated privacy protection in the service, STARTTLS command, negotiated privacy protection in the
AUTHENTICATE command, or some other protection mechanism. AUTHENTICATE command, or some other protection mechanism.
11.1. STARTTLS Security Considerations 11.1. STARTTLS Security Considerations
IMAP client and server implementations MUST comply with relevant TLS IMAP client and server implementations MUST comply with relevant TLS
recommendations from [RFC8314]. Additionally, when using TLS 1.2, recommendations from [RFC8314].
IMAP implementations MUST implement
Clients and servers MUST implement TLS 1.2 or newer. Use of TLS 1.3
[TLS-1.3] is RECOMMENDED. However [TLS-1.2] MAY be used.
Additionally, when using TLS 1.2, IMAP implementations MUST implement
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite, and SHOULD TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite, and SHOULD
implement the TLS_RSA_WITH_AES_128_CBC_SHA [TLS] cipher suite. This implement the TLS_RSA_WITH_AES_128_CBC_SHA [TLS-1.2] cipher suite.
is important as it assures that any two compliant implementations can This is important as it assures that any two compliant
be configured to interoperate. Other TLS cipher suites recommended implementations can be configured to interoperate. Other TLS cipher
in RFC 7525 are RECOMMENDED: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, suites recommended in RFC 7525 are RECOMMENDED:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 and TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 and
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. All other cipher suites are TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. All other cipher suites are
OPTIONAL. Note that this is a change from section 2.1 of [IMAP-TLS]. OPTIONAL. Note that this is a change from section 2.1 of [IMAP-TLS].
During the [TLS] negotiation, the client MUST check its understanding The list of mandatory-to-implement TLS 1.3 cipher suites is described
of the server hostname against the server's identity as presented in in Section 9.1 of [TLS-1.3].
the server Certificate message, in order to prevent man-in-the-middle
attacks. This procedure is described in [RFC7817]. During the TLS negotiation [TLS-1.3][TLS-1.2], the client MUST check
its understanding of the server hostname against the server's
identity as presented in the server Certificate message, in order to
prevent man-in-the-middle attacks. This procedure is described in
[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] negotiation to see whether acceptable command and subsequent TLS ([TLS-1.3][TLS-1.2]) negotiation to see
authentication and/or privacy was achieved. whether acceptable authentication and/or privacy was achieved.
11.2. COPYUID and APPENDUID response codes 11.2. COPYUID and APPENDUID response codes
The COPYUID and APPENDUID response codes return information about the The COPYUID and APPENDUID response codes return information about the
mailbox, which may be considered sensitive if the mailbox has mailbox, which may be considered sensitive if the mailbox has
permissions set that permit the client to COPY or APPEND to the permissions set that permit the client to COPY or APPEND to the
mailbox, but not SELECT or EXAMINE it. mailbox, but not SELECT or EXAMINE it.
Consequently, these response codes SHOULD NOT be issued if the client Consequently, these response codes SHOULD NOT be issued if the client
does not have access to SELECT or EXAMINE the mailbox. does not have access to SELECT or EXAMINE the mailbox.
skipping to change at page 148, line 35 skipping to change at page 148, line 45
1997, <https://www.rfc-editor.org/info/rfc2231>. 1997, <https://www.rfc-editor.org/info/rfc2231>.
[RFC-5322] [RFC-5322]
Resnick, P., Ed., "Internet Message Format", RFC 5322, Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008, <http://www.rfc-editor.org/info/rfc5322>. October 2008, <http://www.rfc-editor.org/info/rfc5322>.
[SASL] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple [SASL] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
Authentication and Security Layer (SASL)", RFC 4422, June Authentication and Security Layer (SASL)", RFC 4422, June
2006, <http://www.rfc-editor.org/info/rfc4422>. 2006, <http://www.rfc-editor.org/info/rfc4422>.
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security [TLS-1.2] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008, (TLS) Protocol Version 1.2", RFC 5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <http://www.rfc-editor.org/info/rfc5246>.
[TLS-1.3] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[UTF-7] Goldsmith, D. and M. Davis, "UTF-7 A Mail-Safe [UTF-7] Goldsmith, D. and M. Davis, "UTF-7 A Mail-Safe
Transformation Format of Unicode", RFC 2152, May 1997, Transformation Format of Unicode", RFC 2152, May 1997,
<http://www.rfc-editor.org/info/rfc2152>. <http://www.rfc-editor.org/info/rfc2152>.
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <http://www.rfc-editor.org/info/rfc3629>. 2003, <http://www.rfc-editor.org/info/rfc3629>.
[MULTIAPPEND] [MULTIAPPEND]
Crispin, M., "Internet Message Access Protocol (IMAP) - Crispin, M., "Internet Message Access Protocol (IMAP) -
skipping to change at page 152, line 35 skipping to change at page 153, line 4
An implementation that wants to remain compatible with IMAP4rev1 can An implementation that wants to remain compatible with IMAP4rev1 can
advertise both IMAP4rev1 and IMAP4rev2 in its CAPABILITY response/ advertise both IMAP4rev1 and IMAP4rev2 in its CAPABILITY response/
response code. While some IMAP4rev1 responses were removed in response code. While some IMAP4rev1 responses were removed in
IMAP4rev2, their presence will not break IMAP4rev2-only clients. IMAP4rev2, their presence will not break IMAP4rev2-only clients.
If both IMAP4rev1 and IMAP4rev2 are advertised, an IMAP client that If both IMAP4rev1 and IMAP4rev2 are advertised, an IMAP client that
wants to use IMAP4rev2 MUST issue an "ENABLE IMAP4rev2" command. wants to use IMAP4rev2 MUST issue an "ENABLE IMAP4rev2" command.
Servers advertising both IMAP4rev1 and IMAP4rev2 MUST NOT generate Servers advertising both IMAP4rev1 and IMAP4rev2 MUST NOT generate
UTF-8 quoted strings unless the client has issued "ENABLE IMAP4rev2". UTF-8 quoted strings unless the client has issued "ENABLE IMAP4rev2".
Consider implementation of mechanisms described or referenced in Consider implementation of mechanisms described or referenced in
[IMAP-UTF-8] to achieve this goal. [IMAP-UTF-8] to achieve this goal.
Servers advertising both IMAP4rev1 and IMAP4rev2, and clients Servers advertising both IMAP4rev1 and IMAP4rev2, and clients
intending to be compatible with IMAP4rev1 servers MUST be compatible intending to be compatible with IMAP4rev1 servers MUST be compatible
with the international mailbox naming convention described in the with the international mailbox naming convention described in the
following subsection. following subsection.
A.1. Mailbox International Naming Convention for compatibility with A.1. Mailbox International Naming Convention for compatibility with
IMAP4rev1 IMAP4rev1
Support for the Mailbox International Naming Convention described in Support for the Mailbox International Naming Convention described in
this section is not required for IMAP4rev2-only clients and servers. this section is not required for IMAP4rev2-only clients and servers.
It is only used for backward compatibility with IMAP4rev1
implementations.
By convention, international mailbox names in IMAP4rev1 are specified By convention, international mailbox names in IMAP4rev1 are specified
using a modified version of the UTF-7 encoding described in [UTF-7]. using a modified version of the UTF-7 encoding described in [UTF-7].
Modified UTF-7 may also be usable in servers that implement an Modified UTF-7 may also be usable in servers that implement an
earlier version of this protocol. earlier version of this protocol.
In modified UTF-7, printable US-ASCII characters, except for "&", In modified UTF-7, printable US-ASCII characters, except for "&",
represent themselves; that is, characters with octet values 0x20-0x25 represent themselves; that is, characters with octet values 0x20-0x25
and 0x27-0x7e. The character "&" (0x26) is represented by the two- and 0x27-0x7e. The character "&" (0x26) is represented by the two-
octet sequence "&-". octet sequence "&-".
skipping to change at page 154, line 43 skipping to change at page 155, line 17
Appendix C. Backward compatibility with LIST-EXTENDED extension Appendix C. Backward compatibility with LIST-EXTENDED extension
IMAP4rev2 is incorporates most of functionality provided by the LIST- IMAP4rev2 is incorporates most of functionality provided by the LIST-
EXTENDED extension [RFC5258]. In particular, multiple mailbox EXTENDED extension [RFC5258]. In particular, multiple mailbox
patterns syntax is not supported in IMAP4rev2, unless LIST-EXTENDED patterns syntax is not supported in IMAP4rev2, unless LIST-EXTENDED
capability is also advertised in CAPABILITY response/response code. capability is also advertised in CAPABILITY response/response code.
Appendix D. Changes from RFC 3501 / IMAP4rev1 Appendix D. Changes from RFC 3501 / IMAP4rev1
The following is the plan for remaining changes. The plan might Below is the summary of changes since RFC 3501:
change over time.
1. Revise IANA registration of IMAP extensions and give advice on
use of "X-" convention.
2. Add a section on other recommended extensions?
The following changes were already done:
1. Fold in the following extensions/RFC: RFC 5530 (IMAP Response
Codes), UIDPLUS, ENABLE, ESEARCH, SPECIAL-USE (list of new
mailbox attributes), LITERAL-, NAMESPACE, SASL-IR, LIST-STATUS,
SEARCHRES, IDLE, MOVE.
2. Add CLOSED response code (from CONDSTORE).
3. Add support for $Phishing, $Junk, $NonJunk, $MDNSent and
$Forwarded IMAP keywords. Add more examples showing their use?
4. Require all unsolicited FETCH updates to include UID.
5. Update recommendations on TLS ciphers to match UTA WG work (as
per RFC 8314, RFC 7525 and RFC 7817).
6. Fold in the following extensions/RFC: Base LIST-EXTENDED syntax
plus deprecate LSUB (replace it with LIST \Subscribed) minus the
requirement to support multiple list patterns, BINARY (only the
FETCH changes on leaf body part and make APPEND related ones
optional. See the mailing list discussion).
7. Add STATUS SIZE (total mailbox size). Add STATUS DELETED (number
of messages with \Deleted flag set).
8. Drop UTF-7, all mailboxes are always in UTF-8.
The following changes since RFC 3501 were done so far:
1. Folded in IMAP UNSELECT (RFC 3691), UIDPLUS (RFC 4315), ESEARCH 1. Folded in IMAP NAMESPACE (RFC 2342), UNSELECT (RFC 3691),
(RFC 4731), SEARCHRES (RFC 5182), ENABLE (RFC 5161), IDLE (RFC UIDPLUS (RFC 4315), ESEARCH (RFC 4731), SEARCHRES (RFC 5182),
2177), SASL-IR (RFC 4959), LIST-STATUS (RFC 5819) and MOVE (RFC ENABLE (RFC 5161), IDLE (RFC 2177), SASL-IR (RFC 4959), LIST-
6851) extensions. Also folded RFC 5530 and FETCH side of the EXTENDED (RFC 5258), LIST-STATUS (RFC 5819), MOVE (RFC 6851) and
BINARY extension (RFC 3516). LITERAL- (RFC 7888) extensions. Also folded RFC 4466 (IMAP ABNF
extensions), RFC 5530 (response codes), the FETCH side of the
BINARY extension (RFC 3516) and the list of new mailbox
attributes from SPECIAL-USE (RFC 6154).
2. Clarified that server should decode parameter value 2. Added STATUS SIZE (RFC 8438) and STATUS DELETED.
continuations as described in [RFC2231]. This requirement was
hidden in RFC 2231 itself.
3. SEARCH command now requires to return ESEARCH response (SEARCH 3. SEARCH command now requires to return ESEARCH response (SEARCH
response is now deprecated). response is now deprecated).
4. Clarified which SEARCH keys has to use substring match and which 4. Clarified which SEARCH keys has to use substring match and which
don't. don't.
5. Added CLOSED response code from RFC 7162. SELECT/EXAMINE when a 5. Clarified that server should decode parameter value
continuations as described in [RFC2231]. This requirement was
hidden in RFC 2231 itself.
6. Added CLOSED response code from RFC 7162. SELECT/EXAMINE when a
mailbox is already selected now require for the CLOSED response mailbox is already selected now require for the CLOSED response
code to be returned. code to be returned.
6. SELECT/EXAMINE are now required to return untagged LIST 7. SELECT/EXAMINE are now required to return untagged LIST
response. response.
7. Updated to use modern TLS-related recommendations as per RFC 8. UNSEEN response code on SELECT/EXAMINE is now deprecated.
8314, RFC 7817, RFC 7525.
8. For future extensibility extended ABNF for tagged-ext-simple to 9. RECENT response on SELECT/EXAMINE, \Recent flag, RECENT STATUS,
SEARCH NEW items are now deprecated.
10. Clarified that the server doesn't need to send a new
PERMANENTFLAGS response code when a new keyword was successfully
added and the server advertised \* earlier for the same mailbox.
11. For future extensibility extended ABNF for tagged-ext-simple to
allow for bare number64. allow for bare number64.
9. Added SHOULD level requirement on IMAP servers to support 12. Added SHOULD level requirement on IMAP servers to support
$MDNSent, $Forwarded, $Junk, $NonJunk and $Phishing keywords. $MDNSent, $Forwarded, $Junk, $NonJunk and $Phishing keywords.
10. Added STATUS SIZE (RFC 8438) and STATUS DELETED. 13. Mailbox names and message headers now allow for UTF-8. Support
11. Mailbox names and message headers now allow for UTF-8. Support
for Modified UTF-7 in mailbox names is not required, unless for Modified UTF-7 in mailbox names is not required, unless
compatibility with IMAP4rev1 is desired. compatibility with IMAP4rev1 is desired.
12. UNSEEN response code on SELECT/EXAMINE is now deprecated. 14. Removed the CHECK command. Clients should use NOOP instead.
13. RECENT response on SELECT/EXAMINE, \Recent flag, RECENT STATUS,
SEARCH NEW items are now deprecated.
14. Clarified that the server doesn't need to send a new
PERMANENTFLAGS response code when a new keyword was successfully
added and the server advertised \* earlier for the same mailbox.
15. Removed the CHECK command. Clients should use NOOP instead.
16. RFC822, RFC822.HEADER and RFC822.TEXT FETCH data items were 15. 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.
17. Replaced DIGEST-MD5 SASL mechanism with SCRAM-SHA-256. DIGEST- 16. LSUB command was deprecated. Clients should use LIST
MD5 was deprecated.
18. LSUB command was deprecated. Clients should use LIST
(SUBSCRIBED) instead. (SUBSCRIBED) instead.
19. resp-text ABNF non terminal was updated to allow for empty text. 17. IDLE command can now return updates not related to the currently
20. IDLE command can now return updates not related to the currently
selected mailbox state. selected mailbox state.
21. All unsolicited FETCH updates are required to include UID. 18. All unsolicited FETCH updates are required to include UID.
22. Clarified that client implementations MUST ignore response codes 19. Clarified that client implementations MUST ignore response codes
that they do not recognize. (Change from a SHOULD to a MUST.) that they do not recognize. (Change from a SHOULD to a MUST.)
23. After ENABLE IMAP4rev2 human readable response text can include 20. resp-text ABNF non terminal was updated to allow for empty text.
21. After ENABLE IMAP4rev2 human readable response text can include
non ASCII encoded in UTF-8. non ASCII encoded in UTF-8.
Appendix E. Acknowledgement 22. Updated to use modern TLS-related recommendations as per RFC
8314, RFC 7817, RFC 7525.
23. Replaced DIGEST-MD5 SASL mechanism with SCRAM-SHA-256. DIGEST-
MD5 was deprecated.
Appendix E. Other Recommended IMAP Extensions
Support for the following extensions is recommended for all IMAP
client and servers. Why they significantly reduce bandwidth and/or
number of round trips used by IMAP in certain situations, the EXTRA
WG decided that requiring them as a part of IMAP4rev2 would push the
bar to implement too high for new implementations. Also note that
absence of any IMAP extension from this list doesn't make it somehow
deficient or not recommended for use with IMAP4rev2.
1. QRESYNC and CONDSTORE extensions (RFC 7162). They make
discovering changes to IMAP mailboxes more efficient, at the
expense of storing a bit more state.
2. OBJECTID extension (RFC 8474) helps with preserving IMAP client
cache when messages moved/copied or mailboxes are renamed.
Appendix F. Acknowledgement
Earlier versions of this document were edited by Mark Crispin. Earlier versions of this document were edited by Mark Crispin.
Sadly, he is no longer available to help with this work. Editors of Sadly, he is no longer available to help with this work. Editors of
this revisions are hoping that Mark would have approved. this revisions are hoping that Mark would have approved.
Chris Newman has contributed text on I18N and use of UTF-8 in Chris Newman has contributed text on I18N and use of UTF-8 in
messages and mailbox names. messages and mailbox names.
Thank you to Tony Hansen for helping with the index generation. Thank you to Tony Hansen for helping with the index generation.
Thank you to Timo Sirainen, Bron Gondwana, Stephan Bosch and Arnt Thank you to Timo Sirainen, Bron Gondwana, Stephan Bosch and Arnt
skipping to change at page 157, line 41 skipping to change at page 157, line 48
Section 6.3.9.5 is taken directly from their original specification Section 6.3.9.5 is taken directly from their original specification
[RFC3348]. [RFC3348].
Index Index
$ $
$Forwarded (predefined flag) 12 $Forwarded (predefined flag) 12
$Junk (predefined flag) 12 $Junk (predefined flag) 12
$MDNSent (predefined flag) 12 $MDNSent (predefined flag) 12
$NotJunk (predefined flag) 12 $NotJunk (predefined flag) 12
$Phishing (predefined flag) 12 $Phishing (predefined flag) 13
+ +
+FLAGS <flag list> 92 +FLAGS <flag list> 92
+FLAGS.SILENT <flag list> 92 +FLAGS.SILENT <flag list> 92
- -
-FLAGS <flag list> 92 -FLAGS <flag list> 92
-FLAGS.SILENT <flag list> 92 -FLAGS.SILENT <flag list> 92
A A
skipping to change at page 162, line 22 skipping to change at page 162, line 30
Unique Identifier (UID) (message attribute) 9 Unique Identifier (UID) (message attribute) 9
X X
X<atom> (command) 97 X<atom> (command) 97
[ [
[RFC-5322] Size (message attribute) 14 [RFC-5322] Size (message attribute) 14
\ \
\All (mailbox name attribute) 113 \All (mailbox name attribute) 113
\Answered (system flag) 11 \Answered (system flag) 12
\Archive (mailbox name attribute) 113 \Archive (mailbox name attribute) 113
\Deleted (system flag) 12 \Deleted (system flag) 12
\Draft (system flag) 12 \Draft (system flag) 12
\Drafts (mailbox name attribute) 113 \Drafts (mailbox name attribute) 113
\Flagged (mailbox name attribute) 113 \Flagged (mailbox name attribute) 113
\Flagged (system flag) 11 \Flagged (system flag) 12
\HasChildren (mailbox name attribute) 112 \HasChildren (mailbox name attribute) 112
\HasNoChildren (mailbox name attribute) 112 \HasNoChildren (mailbox name attribute) 112
\Junk (mailbox name attribute) 113 \Junk (mailbox name attribute) 113
\Marked (mailbox name attribute) 112 \Marked (mailbox name attribute) 112
\Noinferiors (mailbox name attribute) 111 \Noinferiors (mailbox name attribute) 111
\NonExistent (mailbox name attribute) 111 \NonExistent (mailbox name attribute) 111
\Noselect (mailbox name attribute) 111 \Noselect (mailbox name attribute) 111
\Recent (system flag) 12 \Recent (system flag) 12
\Remote (mailbox name attribute) 112 \Remote (mailbox name attribute) 112
\Seen (system flag) 11 \Seen (system flag) 12
\Sent (mailbox name attribute) 113 \Sent (mailbox name attribute) 113
\Subscribed (mailbox name attribute) 112 \Subscribed (mailbox name attribute) 112
\Trash (mailbox name attribute) 113 \Trash (mailbox name attribute) 113
\Unmarked (mailbox name attribute) 112 \Unmarked (mailbox name attribute) 112
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
Barry Leiba (editor) Barry Leiba (editor)
Futurewei Technologies Futurewei Technologies
 End of changes. 47 change blocks. 
137 lines changed or deleted 142 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/