draft-ietf-extra-imap4rev2-01.txt   draft-ietf-extra-imap4rev2-02.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) July 16, 2018 Obsoletes: 3501 (if approved) B. Leiba, Ed.
Intended status: Standards Track Intended status: Standards Track Huawei Technologies
Expires: January 17, 2019 Expires: April 22, 2019 October 19, 2018
INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev2 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev2
draft-ietf-extra-imap4rev2-01.txt draft-ietf-extra-imap4rev2-02.txt
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 January 17, 2019. This Internet-Draft will expire on April 22, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 13 skipping to change at page 3, line 13
3.1. Not Authenticated State . . . . . . . . . . . . . . . . . 14 3.1. Not Authenticated State . . . . . . . . . . . . . . . . . 14
3.2. Authenticated State . . . . . . . . . . . . . . . . . . . 14 3.2. Authenticated State . . . . . . . . . . . . . . . . . . . 14
3.3. Selected State . . . . . . . . . . . . . . . . . . . . . 14 3.3. Selected State . . . . . . . . . . . . . . . . . . . . . 14
3.4. Logout State . . . . . . . . . . . . . . . . . . . . . . 14 3.4. Logout State . . . . . . . . . . . . . . . . . . . . . . 14
4. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 16 4. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Atom . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1. Atom . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.1. Sequence set and UID set . . . . . . . . . . . . . . 16 4.1.1. Sequence set and UID set . . . . . . . . . . . . . . 16
4.2. Number . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2. Number . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3. String . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.3. String . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3.1. 8-bit and Binary Strings . . . . . . . . . . . . . . 17 4.3.1. 8-bit and Binary Strings . . . . . . . . . . . . . . 17
4.4. Parenthesized List . . . . . . . . . . . . . . . . . . . 17 4.4. Parenthesized List . . . . . . . . . . . . . . . . . . . 18
4.5. NIL . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.5. NIL . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5. Operational Considerations . . . . . . . . . . . . . . . . . 18 5. Operational Considerations . . . . . . . . . . . . . . . . . 18
5.1. Mailbox Naming . . . . . . . . . . . . . . . . . . . . . 18 5.1. Mailbox Naming . . . . . . . . . . . . . . . . . . . . . 18
5.1.1. Mailbox Hierarchy Naming . . . . . . . . . . . . . . 19 5.1.1. Mailbox Hierarchy Naming . . . . . . . . . . . . . . 19
5.1.2. Namespaces . . . . . . . . . . . . . . . . . . . . . 19 5.1.2. Namespaces . . . . . . . . . . . . . . . . . . . . . 19
5.1.3. Mailbox International Naming Convention . . . . . . . 20 5.2. Mailbox Size and Message Status Updates . . . . . . . . . 21
5.2. Mailbox Size and Message Status Updates . . . . . . . . . 22 5.3. Response when no Command in Progress . . . . . . . . . . 21
5.3. Response when no Command in Progress . . . . . . . . . . 22 5.4. Autologout Timer . . . . . . . . . . . . . . . . . . . . 21
5.4. Autologout Timer . . . . . . . . . . . . . . . . . . . . 22 5.5. Multiple Commands in Progress (Command Pipelining) . . . 22
5.5. Multiple Commands in Progress (Command Pipelining) . . . 23 6. Client Commands . . . . . . . . . . . . . . . . . . . . . . . 23
6. Client Commands . . . . . . . . . . . . . . . . . . . . . . . 24 6.1. Client Commands - Any State . . . . . . . . . . . . . . . 23
6.1. Client Commands - Any State . . . . . . . . . . . . . . . 24 6.1.1. CAPABILITY Command . . . . . . . . . . . . . . . . . 24
6.1.1. CAPABILITY Command . . . . . . . . . . . . . . . . . 25 6.1.2. NOOP Command . . . . . . . . . . . . . . . . . . . . 25
6.1.2. NOOP Command . . . . . . . . . . . . . . . . . . . . 26 6.1.3. LOGOUT Command . . . . . . . . . . . . . . . . . . . 25
6.1.3. LOGOUT Command . . . . . . . . . . . . . . . . . . . 26 6.2. Client Commands - Not Authenticated State . . . . . . . . 26
6.2. Client Commands - Not Authenticated State . . . . . . . . 27 6.2.1. STARTTLS Command . . . . . . . . . . . . . . . . . . 26
6.2.1. STARTTLS Command . . . . . . . . . . . . . . . . . . 27 6.2.2. AUTHENTICATE Command . . . . . . . . . . . . . . . . 27
6.2.2. AUTHENTICATE Command . . . . . . . . . . . . . . . . 28 6.2.3. LOGIN Command . . . . . . . . . . . . . . . . . . . . 30
6.2.3. LOGIN Command . . . . . . . . . . . . . . . . . . . . 31 6.3. Client Commands - Authenticated State . . . . . . . . . . 31
6.3. Client Commands - Authenticated State . . . . . . . . . . 32 6.3.1. ENABLE Command . . . . . . . . . . . . . . . . . . . 31
6.3.1. ENABLE Command . . . . . . . . . . . . . . . . . . . 32 6.3.2. SELECT Command . . . . . . . . . . . . . . . . . . . 33
6.3.2. SELECT Command . . . . . . . . . . . . . . . . . . . 34 6.3.3. EXAMINE Command . . . . . . . . . . . . . . . . . . . 35
6.3.3. EXAMINE Command . . . . . . . . . . . . . . . . . . . 36 6.3.4. CREATE Command . . . . . . . . . . . . . . . . . . . 36
6.3.4. CREATE Command . . . . . . . . . . . . . . . . . . . 37 6.3.5. DELETE Command . . . . . . . . . . . . . . . . . . . 37
6.3.5. DELETE Command . . . . . . . . . . . . . . . . . . . 38 6.3.6. RENAME Command . . . . . . . . . . . . . . . . . . . 38
6.3.6. RENAME Command . . . . . . . . . . . . . . . . . . . 39 6.3.7. SUBSCRIBE Command . . . . . . . . . . . . . . . . . . 40
6.3.7. SUBSCRIBE Command . . . . . . . . . . . . . . . . . . 41 6.3.8. UNSUBSCRIBE Command . . . . . . . . . . . . . . . . . 41
6.3.8. UNSUBSCRIBE Command . . . . . . . . . . . . . . . . . 42 6.3.9. LIST Command . . . . . . . . . . . . . . . . . . . . 41
6.3.9. LIST Command . . . . . . . . . . . . . . . . . . . . 42 6.3.10. LSUB Command . . . . . . . . . . . . . . . . . . . . 44
6.3.10. LSUB Command . . . . . . . . . . . . . . . . . . . . 45 6.3.11. NAMESPACE Command . . . . . . . . . . . . . . . . . . 45
6.3.11. NAMESPACE Command . . . . . . . . . . . . . . . . . . 46 6.3.12. STATUS Command . . . . . . . . . . . . . . . . . . . 49
6.3.12. STATUS Command . . . . . . . . . . . . . . . . . . . 50 6.3.13. APPEND Command . . . . . . . . . . . . . . . . . . . 51
6.3.13. APPEND Command . . . . . . . . . . . . . . . . . . . 52 6.3.14. IDLE Command . . . . . . . . . . . . . . . . . . . . 54
6.3.14. IDLE Command . . . . . . . . . . . . . . . . . . . . 55 6.4. Client Commands - Selected State . . . . . . . . . . . . 55
6.4. Client Commands - Selected State . . . . . . . . . . . . 56 6.4.1. CHECK Command . . . . . . . . . . . . . . . . . . . . 56
6.4.1. CHECK Command . . . . . . . . . . . . . . . . . . . . 57 6.4.2. CLOSE Command . . . . . . . . . . . . . . . . . . . . 56
6.4.2. CLOSE Command . . . . . . . . . . . . . . . . . . . . 57 6.4.3. UNSELECT Command . . . . . . . . . . . . . . . . . . 57
6.4.3. UNSELECT Command . . . . . . . . . . . . . . . . . . 58 6.4.4. EXPUNGE Command . . . . . . . . . . . . . . . . . . . 57
6.4.4. EXPUNGE Command . . . . . . . . . . . . . . . . . . . 58 6.4.5. SEARCH Command . . . . . . . . . . . . . . . . . . . 58
6.4.5. SEARCH Command . . . . . . . . . . . . . . . . . . . 59 6.4.6. FETCH Command . . . . . . . . . . . . . . . . . . . . 63
6.4.6. FETCH Command . . . . . . . . . . . . . . . . . . . . 64 6.4.7. STORE Command . . . . . . . . . . . . . . . . . . . . 67
6.4.7. STORE Command . . . . . . . . . . . . . . . . . . . . 68 6.4.8. COPY Command . . . . . . . . . . . . . . . . . . . . 68
6.4.8. COPY Command . . . . . . . . . . . . . . . . . . . . 69 6.4.9. UID Command . . . . . . . . . . . . . . . . . . . . . 69
6.4.9. UID Command . . . . . . . . . . . . . . . . . . . . . 70 6.5. Client Commands - Experimental/Expansion . . . . . . . . 71
6.5. Client Commands - Experimental/Expansion . . . . . . . . 72 6.5.1. X<atom> Command . . . . . . . . . . . . . . . . . . . 71
6.5.1. X<atom> Command . . . . . . . . . . . . . . . . . . . 72 7. Server Responses . . . . . . . . . . . . . . . . . . . . . . 71
7. Server Responses . . . . . . . . . . . . . . . . . . . . . . 72 7.1. Server Responses - Status Responses . . . . . . . . . . . 72
7.1. Server Responses - Status Responses . . . . . . . . . . . 73 7.1.1. OK Response . . . . . . . . . . . . . . . . . . . . . 79
7.1.1. OK Response . . . . . . . . . . . . . . . . . . . . . 80 7.1.2. NO Response . . . . . . . . . . . . . . . . . . . . . 80
7.1.2. NO Response . . . . . . . . . . . . . . . . . . . . . 81 7.1.3. BAD Response . . . . . . . . . . . . . . . . . . . . 80
7.1.3. BAD Response . . . . . . . . . . . . . . . . . . . . 81 7.1.4. PREAUTH Response . . . . . . . . . . . . . . . . . . 81
7.1.4. PREAUTH Response . . . . . . . . . . . . . . . . . . 82 7.1.5. BYE Response . . . . . . . . . . . . . . . . . . . . 81
7.1.5. BYE Response . . . . . . . . . . . . . . . . . . . . 82 7.2. Server Responses - Server and Mailbox Status . . . . . . 82
7.2. Server Responses - Server and Mailbox Status . . . . . . 83 7.2.1. The ENABLED Response . . . . . . . . . . . . . . . . 82
7.2.1. The ENABLED Response . . . . . . . . . . . . . . . . 83 7.2.2. CAPABILITY Response . . . . . . . . . . . . . . . . . 82
7.2.2. CAPABILITY Response . . . . . . . . . . . . . . . . . 83 7.2.3. LIST Response . . . . . . . . . . . . . . . . . . . . 83
7.2.3. LIST Response . . . . . . . . . . . . . . . . . . . . 84 7.2.4. LSUB Response . . . . . . . . . . . . . . . . . . . . 86
7.2.4. LSUB Response . . . . . . . . . . . . . . . . . . . . 87 7.2.5. NAMESPACE Response . . . . . . . . . . . . . . . . . 86
7.2.5. NAMESPACE Response . . . . . . . . . . . . . . . . . 87 7.2.6. STATUS Response . . . . . . . . . . . . . . . . . . . 86
7.2.6. STATUS Response . . . . . . . . . . . . . . . . . . . 87 7.2.7. ESEARCH Response . . . . . . . . . . . . . . . . . . 87
7.2.7. ESEARCH Response . . . . . . . . . . . . . . . . . . 88 7.2.8. FLAGS Response . . . . . . . . . . . . . . . . . . . 87
7.2.8. FLAGS Response . . . . . . . . . . . . . . . . . . . 88 7.3. Server Responses - Mailbox Size . . . . . . . . . . . . . 88
7.3. Server Responses - Mailbox Size . . . . . . . . . . . . . 89 7.3.1. EXISTS Response . . . . . . . . . . . . . . . . . . . 88
7.3.1. EXISTS Response . . . . . . . . . . . . . . . . . . . 89 7.3.2. RECENT Response . . . . . . . . . . . . . . . . . . . 88
7.3.2. RECENT Response . . . . . . . . . . . . . . . . . . . 89 7.4. Server Responses - Message Status . . . . . . . . . . . . 89
7.4. Server Responses - Message Status . . . . . . . . . . . . 90 7.4.1. EXPUNGE Response . . . . . . . . . . . . . . . . . . 89
7.4.1. EXPUNGE Response . . . . . . . . . . . . . . . . . . 90 7.4.2. FETCH Response . . . . . . . . . . . . . . . . . . . 90
7.4.2. FETCH Response . . . . . . . . . . . . . . . . . . . 91 7.5. Server Responses - Command Continuation Request . . . . . 95
7.5. Server Responses - Command Continuation Request . . . . . 96 8. Sample IMAP4rev2 connection . . . . . . . . . . . . . . . . . 95
8. Sample IMAP4rev2 connection . . . . . . . . . . . . . . . . . 96 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 97
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 98
10. Author's Note . . . . . . . . . . . . . . . . . . . . . . . . 111 10. Author's Note . . . . . . . . . . . . . . . . . . . . . . . . 111
11. Security Considerations . . . . . . . . . . . . . . . . . . . 111 11. Security Considerations . . . . . . . . . . . . . . . . . . . 111
11.1. STARTTLS Security Considerations . . . . . . . . . . . . 112 11.1. STARTTLS Security Considerations . . . . . . . . . . . . 111
11.2. COPYUID and APPENDUID response codes . . . . . . . . . . 112 11.2. COPYUID and APPENDUID response codes . . . . . . . . . . 111
11.3. Other Security Considerations . . . . . . . . . . . . . 112 11.3. Other Security Considerations . . . . . . . . . . . . . 112
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 113 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 112
12.1. Updates to IMAP4 Capabilities registry . . . . . . . . . 113 12.1. Updates to IMAP4 Capabilities registry . . . . . . . . . 113
12.2. GSSAPI/SASL service name . . . . . . . . . . . . . . . . 114 12.2. GSSAPI/SASL service name . . . . . . . . . . . . . . . . 113
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 114 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 113
13.1. Normative References . . . . . . . . . . . . . . . . . . 114 13.1. Normative References . . . . . . . . . . . . . . . . . . 113
13.2. Informative References (related protocols) . . . . . . . 116 13.2. Informative References (related protocols) . . . . . . . 116
13.3. Informative References (historical aspects of IMAP and 13.3. Informative References (historical aspects of IMAP and
related protocols) . . . . . . . . . . . . . . . . . . . 117 related protocols) . . . . . . . . . . . . . . . . . . . 117
Appendix A. Backward compatibility with IMAP4rev1 . . . . . . . 118 Appendix A. Backward compatibility with IMAP4rev1 . . . . . . . 118
Appendix B. Changes from RFC 3501 / IMAP4rev1 . . . . . . . . . 118 A.1. Mailbox International Naming Convention . . . . . . . . . 118
Appendix C. Acknowledgement . . . . . . . . . . . . . . . . . . 119 Appendix B. Changes from RFC 3501 / IMAP4rev1 . . . . . . . . . 120
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Appendix C. Acknowledgement . . . . . . . . . . . . . . . . . . 121
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 125 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 127
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 16, line 35 skipping to change at page 16, line 35
A "UID set" is similar to the sequence set of unique identifiers; A "UID set" is similar to the sequence set of unique identifiers;
however, the "*" value for a sequence number is not permitted. however, the "*" value for a sequence number is not permitted.
4.2. Number 4.2. Number
A number consists of one or more digit characters, and represents a A number consists of one or more digit characters, and represents a
numeric value. numeric value.
4.3. String 4.3. String
A string is in one of two forms: either literal or quoted string. A string is in one of three forms: synchonizing literal, non-
The literal form is the general form of string. The quoted string synchronizing literal or quoted string. The synchronizing literal
form is an alternative that avoids the overhead of processing a form is the general form of string. The non-synchronizing literal
literal at the cost of limitations of characters which may be used. form is also the general form, but has length limitation. The quoted
string form is an alternative that avoids the overhead of processing
a literal at the cost of limitations of characters which may be used.
A literal is a sequence of zero or more octets (including CR and LF), When the distinction between synchronizing and non-synchronizing
prefix-quoted with an octet count in the form of an open brace ("{"), literals is not important, this document just uses the term
the number of octets, close brace ("}"), and CRLF. In the case of "literal".
literals transmitted from server to client, the CRLF is immediately
followed by the octet data. In the case of literals transmitted from
client to server, the client MUST wait to receive a command
continuation request (described later in this document) before
sending the octet data (and the remainder of the command).
A quoted string is a sequence of zero or more 7-bit characters, A synchronizing literal is a sequence of zero or more octets
excluding CR and LF, with double quote (<">) characters at each end. (including CR and LF), prefix-quoted with an octet count in the form
of an open brace ("{"), the number of octets, close brace ("}"), and
CRLF. In the case of synchronizing literals transmitted from server
to client, the CRLF is immediately followed by the octet data. In
the case of synchronizing literals transmitted from client to server,
the client MUST wait to receive a command continuation request
(described later in this document) before sending the octet data (and
the remainder of the command).
The empty string is represented as either "" (a quoted string with The non-synchronizing literal is an alternate form of synchronizing
zero characters between double quotes) or as {0} followed by CRLF (a literal, and it may appear in communication from client to server
literal with an octet count of 0). instead of the synchonizing form of literal. The non-synchronizing
literal form MUST NOT be sent from server to client. The non-
synchronizing literal is distinguished from the synchronizing literal
by having a plus ("+") between the octet count and the closing brace
("}"). The server does not generate a command continuation request
in response to a non-synchronizing literal, and clients are not
required to wait before sending the octets of a non- synchronizing
literal. Non-synchronizing literals MUST NOT be larger than 4096
octets. Any literal larger than 4096 bytes MUST be sent as a
synchronizing literal. (Non-synchronizing literals defined in this
document are the same as non-synchronizing literals defined by
LITERAL- extension from [RFC7888]. See that document for details on
how to handle invalid non-synchronizing literals longer than 4096
octets and for interaction with other IMAP extensions.)
A quoted string is a sequence of zero or more Unicode characters,
excluding CR and LF, encoded in UTF-8, with double quote (<">)
characters at each end.
The empty string is represented as "" (a quoted string with zero
characters between double quotes), as {0} followed by CRLF (a
synchronizing literal with an octet count of 0) or as {0+} followed
by CRLF (a non-synchronizing literal with an octet count of 0).
Note: Even if the octet count is 0, a client transmitting a Note: Even if the octet count is 0, a client transmitting a
literal MUST wait to receive a command continuation request. synchronizing literal MUST wait to receive a command continuation
request.
4.3.1. 8-bit and Binary Strings 4.3.1. 8-bit and Binary Strings
8-bit textual and binary mail is supported through the use of a 8-bit textual and binary mail is supported through the use of a
[MIME-IMB] content transfer encoding. IMAP4rev2 implementations MAY [MIME-IMB] content transfer encoding. IMAP4rev2 implementations MAY
transmit 8-bit or multi-octet characters in literals, but SHOULD do transmit 8-bit or multi-octet characters in literals, but SHOULD do
so only when the [CHARSET] is identified. so only when the [CHARSET] is identified.
IMAP4rev2 is compatible with [I18N-HDRS]. As a result, the
identified charset for header-field values with 8-bit content is
UTF-8 [UTF-8]. IMAP4rev2 implementations MUST accept and MAY
transmit [UTF-8] text in quoted-strings as long as the string does
not contain NUL, CR, or LF. This differs from IMAP4rev1
implementations.
Although a BINARY body encoding is defined, unencoded binary strings Although a BINARY body encoding is defined, unencoded binary strings
are not permitted. A "binary string" is any string with NUL are not permitted. A "binary string" is any string with NUL
characters. Implementations MUST encode binary data into a textual characters. Implementations MUST encode binary data into a textual
form, such as BASE64, before transmitting the data. A string with an form, such as BASE64, before transmitting the data. A string with an
excessive amount of CTL characters MAY also be considered to be excessive amount of CTL characters MAY also be considered to be
binary. binary.
4.4. Parenthesized List 4.4. Parenthesized List
Data structures are represented as a "parenthesized list"; a sequence Data structures are represented as a "parenthesized list"; a sequence
skipping to change at page 18, line 12 skipping to change at page 18, line 43
because addr-name uses "nstring" syntax which is NIL or a string, because addr-name uses "nstring" syntax which is NIL or a string,
but never an atom. but never an atom.
5. Operational Considerations 5. Operational Considerations
The following rules are listed here to ensure that all IMAP4rev2 The following rules are listed here to ensure that all IMAP4rev2
implementations interoperate properly. implementations interoperate properly.
5.1. Mailbox Naming 5.1. Mailbox Naming
Mailbox names are 7-bit. Client implementations MUST NOT attempt to In IMAP4rev2, Mailbox names are encoded in Net-Unicode [NET-UNICODE]
create 8-bit mailbox names, and SHOULD interpret any 8-bit mailbox (this differs from IMAP4rev1). Client implementations MAY attempt to
names returned by LIST or LSUB as UTF-8. Server implementations create Net-Unicode mailbox names, and MUST interpret any 8-bit
SHOULD prohibit the creation of 8-bit mailbox names, and SHOULD NOT mailbox names returned by LIST or LSUB as [NET-UNICODE]. Server
return 8-bit mailbox names in LIST or LSUB. See Section 5.1.3 for implementations MUST prohibit the creation of 8-bit mailbox names
more information on how to represent non-ASCII mailbox names. that do not comply with Net-Unicode (however, servers MAY accept a
de-normalized UTF-8 mailbox name and convert it to Net-Unicode prior
Note: 8-bit mailbox names were undefined in earlier versions of to mailbox creation).
this protocol. Some sites used a local 8-bit character set to
represent non-ASCII mailbox names. Such usage is not
interoperable, and is now formally deprecated.
The case-insensitive mailbox name INBOX is a special name reserved to The case-insensitive mailbox name INBOX is a special name reserved to
mean "the primary mailbox for this user on this server". (Note that mean "the primary mailbox for this user on this server". (Note that
this special name may not exist on some servers for some users.) The this special name may not exist on some servers for some users.) The
interpretation of all other names is implementation-dependent. interpretation of all other names is implementation-dependent.
In particular, this specification takes no position on case In particular, this specification takes no position on case
sensitivity in non-INBOX mailbox names. Some server implementations sensitivity in non-INBOX mailbox names. Some server implementations
are fully case-sensitive; others preserve case of a newly-created are fully case-sensitive in ASCII range; others preserve case of a
name but otherwise are case-insensitive; and yet others coerce names newly-created name but otherwise are case-insensitive; and yet others
to a particular case. Client implementations MUST interact with any coerce names to a particular case. Client implementations MUST
of these. If a server implementation interprets non-INBOX mailbox interact with any of these.
names as case-insensitive, it MUST treat names using the
international naming convention specially as described in
Section 5.1.3.
There are certain client considerations when creating a new mailbox There are certain client considerations when creating a new mailbox
name: name:
1. Any character which is one of the atom-specials (see the Formal 1. Any character which is one of the atom-specials (see the Formal
Syntax) will require that the mailbox name be represented as a Syntax) will require that the mailbox name be represented as a
quoted string or literal. quoted string or literal.
2. CTL and other non-graphic characters are difficult to represent 2. CTL and other non-graphic characters are difficult to represent
in a user interface and are best avoided. in a user interface and are best avoided. Servers MAY refuse to
create mailbox names containing Unicode CTL characters.
3. Although the list-wildcard characters ("%" and "*") are valid in 3. Although the list-wildcard characters ("%" and "*") are valid in
a mailbox name, it is difficult to use such mailbox names with a mailbox name, it is difficult to use such mailbox names with
the LIST and LSUB commands due to the conflict with wildcard the LIST and LSUB commands due to the conflict with wildcard
interpretation. interpretation.
4. Usually, a character (determined by the server implementation) is 4. Usually, a character (determined by the server implementation) is
reserved to delimit levels of hierarchy. reserved to delimit levels of hierarchy.
5. Two characters, "#" and "&", have meanings by convention, and 5. Two characters, "#" and "&", have meanings by convention, and
skipping to change at page 20, line 27 skipping to change at page 21, line 9
The "Personal Mailbox" model, in which the default namespace that is The "Personal Mailbox" model, in which the default namespace that is
presented consists of only the user's personal mailboxes. To access presented consists of only the user's personal mailboxes. To access
shared mailboxes, the user must use an escape mechanism to reach shared mailboxes, the user must use an escape mechanism to reach
another namespace. another namespace.
The "Complete Hierarchy" model, in which the default namespace that The "Complete Hierarchy" model, in which the default namespace that
is presented includes the user's personal mailboxes along with any is presented includes the user's personal mailboxes along with any
other mailboxes they have access to. other mailboxes they have access to.
5.1.3. Mailbox International Naming Convention
By convention, international mailbox names in IMAP4rev2 are specified
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
earlier version of this protocol.
In modified UTF-7, printable US-ASCII characters, except for "&",
represent themselves; that is, characters with octet values 0x20-0x25
and 0x27-0x7e. The character "&" (0x26) is represented by the two-
octet sequence "&-".
All other characters (octet values 0x00-0x1f and 0x7f-0xff) are
represented in modified BASE64, with a further modification from
[UTF-7] that "," is used instead of "/". Modified BASE64 MUST NOT be
used to represent any printing US-ASCII character which can represent
itself. Only characters inside the modified BASE64 alphabet are
permitted in modified BASE64 text.
"&" is used to shift to modified BASE64 and "-" to shift back to US-
ASCII. There is no implicit shift from BASE64 to US-ASCII, and null
shifts ("-&" while in BASE64; note that "&-" while in US-ASCII means
"&") are not permitted. However, all names start in US-ASCII, and
MUST end in US-ASCII; that is, a name that ends with a non-ASCII
ISO-10646 character MUST end with a "-").
The purpose of these modifications is to correct the following
problems with UTF-7:
1. UTF-7 uses the "+" character for shifting; this conflicts with
the common use of "+" in mailbox names, in particular USENET
newsgroup names.
2. UTF-7's encoding is BASE64 which uses the "/" character; this
conflicts with the use of "/" as a popular hierarchy delimiter.
3. UTF-7 prohibits the unencoded usage of "\"; this conflicts with
the use of "\" as a popular hierarchy delimiter.
4. UTF-7 prohibits the unencoded usage of "~"; this conflicts with
the use of "~" in some servers as a home directory indicator.
5. UTF-7 permits multiple alternate forms to represent the same
string; in particular, printable US-ASCII characters can be
represented in encoded form.
Although modified UTF-7 is a convention, it establishes certain
requirements on server handling of any mailbox name with an embedded
"&" character. In particular, server implementations MUST preserve
the exact form of the modified BASE64 portion of a modified UTF-7
name and treat that text as case-sensitive, even if names are
otherwise case-insensitive or case-folded.
Server implementations SHOULD verify that any mailbox name with an
embedded "&" character, used as an argument to CREATE, is: in the
correctly modified UTF-7 syntax, has no superfluous shifts, and has
no encoding in modified BASE64 of any printing US-ASCII character
which can represent itself. However, client implementations MUST NOT
depend upon the server doing this, and SHOULD NOT attempt to create a
mailbox name with an embedded "&" character unless it complies with
the modified UTF-7 syntax.
Server implementations which export a mail store that does not follow
the modified UTF-7 convention MUST convert to modified UTF-7 any
mailbox name that contains either non-ASCII characters or the "&"
character.
For example, here is a mailbox name which mixes English, Chinese,
and Japanese text: ~peter/mail/&U,BTFw-/&ZeVnLIqe-
For example, the string "&Jjo!" is not a valid mailbox name
because it does not contain a shift to US-ASCII before the "!".
The correct form is "&Jjo-!". The string "&U,BTFw-&ZeVnLIqe-" is
not permitted because it contains a superfluous shift. The
correct form is "&U,BTF2XlZyyKng-".
5.2. Mailbox Size and Message Status Updates 5.2. Mailbox Size and Message Status Updates
At any time, a server can send data that the client did not request. At any time, a server can send data that the client did not request.
Sometimes, such behavior is REQUIRED. For example, agents other than Sometimes, such behavior is REQUIRED. For example, agents other than
the server MAY add messages to the mailbox (e.g., new message the server MAY add messages to the mailbox (e.g., new message
delivery), change the flags of the messages in the mailbox (e.g., delivery), change the flags of the messages in the mailbox (e.g.,
simultaneous access to the same mailbox by multiple agents), or even simultaneous access to the same mailbox by multiple agents), or even
remove messages from the mailbox. A server MUST send mailbox size remove messages from the mailbox. A server MUST send mailbox size
updates automatically if a mailbox size change is observed during the updates automatically if a mailbox size change is observed during the
processing of a command. A server SHOULD send message flag updates processing of a command. A server SHOULD send message flag updates
skipping to change at page 37, line 29 skipping to change at page 36, line 29
Responses: no specific responses for this command Responses: no specific responses for this command
Result: OK - create completed Result: OK - create completed
NO - create failure: can't create mailbox with that name NO - create failure: can't create mailbox with that name
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
The CREATE command creates a mailbox with the given name. An OK The CREATE command creates a mailbox with the given name. An OK
response is returned only if a new mailbox with that name has been response is returned only if a new mailbox with that name has been
created. It is an error to attempt to create INBOX or a mailbox with created. It is an error to attempt to create INBOX or a mailbox with
a name that refers to an extant mailbox. Any error in creation will a name that refers to an extant mailbox. Any error in creation will
return a tagged NO response. return a tagged NO response. If a client attempts to create a UTF-8
mailbox name that is not a valid Net-Unicode name, the server MUST
reject the creation or convert the name to Net-Unicode prior to
creating the mailbox.
If the mailbox name is suffixed with the server's hierarchy separator If the mailbox name is suffixed with the server's hierarchy separator
character (as returned from the server by a LIST command), this is a character (as returned from the server by a LIST command), this is a
declaration that the client intends to create mailbox names under declaration that the client intends to create mailbox names under
this name in the hierarchy. Server implementations that do not this name in the hierarchy. Server implementations that do not
require this declaration MUST ignore the declaration. In any case, require this declaration MUST ignore the declaration. In any case,
the name created is without the trailing hierarchy delimiter. the name created is without the trailing hierarchy delimiter.
If the server's hierarchy separator character appears elsewhere in If the server's hierarchy separator character appears elsewhere in
the name, the server SHOULD create any superior hierarchical names the name, the server SHOULD create any superior hierarchical names
skipping to change at page 52, line 7 skipping to change at page 51, line 7
RECENT The number of messages with the \Recent flag set. RECENT The number of messages with the \Recent flag set.
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.
UNSEEN The number of messages which do not have the \Seen flag set. UNSEEN The number of messages which do not have the \Seen flag set.
SIZE The total size of the mailbox in octets. This MUST be equal to SIZE The total size of the mailbox in octets. This is not strictly
the sum of the [RFC-5322] size of all messages in the mailbox.
The total size of the mailbox in octets. This is not strictly
required to be an exact value, but it MUST be equal to or greater required to be an exact value, but it MUST be equal to or greater
than the sum of the values of the RFC822.SIZE FETCH message data than the sum of the values of the RFC822.SIZE FETCH message data
items (see Section 6.4.6) of all messages in the mailbox. items (see Section 6.4.6) of all messages in the mailbox.
Example: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES) Example: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES)
S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292) S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
S: A042 OK STATUS completed S: A042 OK STATUS completed
6.3.13. APPEND Command 6.3.13. APPEND Command
skipping to change at page 52, line 34 skipping to change at page 51, line 32
Responses: no specific responses for this command Responses: no specific responses for this command
Result: OK - append completed Result: OK - append completed
NO - append error: can't append to that mailbox, error NO - append error: can't append to that mailbox, error
in flags or date/time or message text in flags or date/time or message text
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
The APPEND command appends the literal argument as a new message to The APPEND command appends the literal argument as a new message to
the end of the specified destination mailbox. This argument SHOULD the end of the specified destination mailbox. This argument SHOULD
be in the format of an [RFC-5322] message. 8-bit characters are be in the format of an [RFC-5322] or [I18N-HDRS] message. 8-bit
permitted in the message. A server implementation that is unable to characters are permitted in the message. A server implementation
preserve 8-bit data properly MUST be able to reversibly convert 8-bit that is unable to preserve 8-bit data properly MUST be able to
APPEND data to 7-bit using a [MIME-IMB] content transfer encoding. reversibly convert 8-bit APPEND data to 7-bit using a [MIME-IMB]
content transfer encoding.
Note: There may be exceptions, e.g., draft messages, in which Note: There may be exceptions, e.g., draft messages, in which
required [RFC-5322] header lines are omitted in the message required [RFC-5322] header lines are omitted in the message
literal argument to APPEND. The full implications of doing so literal argument to APPEND. The full implications of doing so
must be understood and carefully weighed. must be understood and carefully weighed.
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. In either case, the Recent flag message is set to empty by default. In either case, the Recent flag
is also set. is also set.
skipping to change at page 61, line 9 skipping to change at page 60, line 9
one or more search keys (e.g., for use with the OR and NOT keys). one or more search keys (e.g., for use with the OR and NOT keys).
Server implementations MAY exclude [MIME-IMB] body parts with Server implementations MAY exclude [MIME-IMB] body parts with
terminal content media types other than TEXT and MESSAGE from terminal content media types other than TEXT and MESSAGE from
consideration in SEARCH matching. consideration in SEARCH matching.
The OPTIONAL [CHARSET] specification consists of the word "CHARSET" The OPTIONAL [CHARSET] specification consists of the word "CHARSET"
followed by a registered [CHARSET]. It indicates the [CHARSET] of followed by a registered [CHARSET]. It indicates the [CHARSET] of
the strings that appear in the search criteria. [MIME-IMB] content the strings that appear in the search criteria. [MIME-IMB] content
transfer encodings, and [MIME-HDRS] strings in [RFC-5322]/[MIME-IMB] transfer encodings, and [MIME-HDRS] strings in [RFC-5322]/[MIME-IMB]
headers, MUST be decoded before comparing text. US-ASCII MUST be headers, MUST be decoded before comparing text. US-ASCII and UTF-8
supported; other [CHARSET]s MAY be supported. charsets MUST be supported; other [CHARSET]s MAY be supported. If
"CHARSET" is not provided, an IMAP4rev2 server MUST assume UTF-8.
If the server does not support the specified [CHARSET], it MUST If the server does not support the specified [CHARSET], it MUST
return a tagged NO response (not a BAD). This response SHOULD return a tagged NO response (not a BAD). This response SHOULD
contain the BADCHARSET response code, which MAY list the [CHARSET]s contain the BADCHARSET response code, which MAY list the [CHARSET]s
supported by the server. supported by the server.
In all search keys that use strings, a message matches the key if the In all search keys that use strings, a message matches the key if the
string is a substring of the associated text. The matching is case- string is a substring of the associated text. The matching SHOULD be
insensitive. Note that the empty string is a substring; this is case-insensitive for characters within ASCII range. Consider using
useful when doing a HEADER search. [IMAP-I18N] for language-sensitive case-insensitive searching. Note
that the empty string is a substring; this is useful when doing a
HEADER search in order to test for a header field presence in the
message.
The defined search keys are as follows. Refer to the Formal Syntax The defined search keys are as follows. Refer to the Formal Syntax
section for the precise syntactic definitions of the arguments. section for the precise syntactic definitions of the arguments.
<sequence set> Messages with message sequence numbers corresponding <sequence set> Messages with message sequence numbers corresponding
to the specified message sequence number set. to the specified message sequence number set.
ALL All messages in the mailbox; the default initial key for ANDing. ALL All messages in the mailbox; the default initial key for ANDing.
ANSWERED Messages with the \Answered flag set. ANSWERED Messages with the \Answered flag set.
skipping to change at page 65, line 43 skipping to change at page 64, line 43
Every message has at least one part number. Non-[MIME-IMB] Every message has at least one part number. Non-[MIME-IMB]
messages, and non-multipart [MIME-IMB] messages with no messages, and non-multipart [MIME-IMB] messages with no
encapsulated message, only have a part 1. encapsulated message, only have a part 1.
Multipart messages are assigned consecutive part numbers, as Multipart messages are assigned consecutive part numbers, as
they occur in the message. If a particular part is of type they occur in the message. If a particular part is of type
message or multipart, its parts MUST be indicated by a period message or multipart, its parts MUST be indicated by a period
followed by the part number within that nested multipart part. followed by the part number within that nested multipart part.
A part of type MESSAGE/RFC822 also has nested part numbers, A part of type MESSAGE/RFC822 or MESSAGE/GLOBAL also has nested
referring to parts of the MESSAGE part's body. part numbers, referring to parts of the MESSAGE part's body.
The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, and TEXT part The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, and TEXT part
specifiers can be the sole part specifier or can be prefixed by specifiers can be the sole part specifier or can be prefixed by
one or more numeric part specifiers, provided that the numeric one or more numeric part specifiers, provided that the numeric
part specifier refers to a part of type MESSAGE/RFC822. The part specifier refers to a part of type MESSAGE/RFC822 or
MIME part specifier MUST be prefixed by one or more numeric MESSAGE/GLOBAL. The MIME part specifier MUST be prefixed by
part specifiers. one or more numeric part specifiers.
The HEADER, HEADER.FIELDS, and HEADER.FIELDS.NOT part The HEADER, HEADER.FIELDS, and HEADER.FIELDS.NOT part
specifiers refer to the [RFC-5322] header of the message or of specifiers refer to the [RFC-5322] header of the message or of
an encapsulated [MIME-IMT] MESSAGE/RFC822 message. an encapsulated [MIME-IMT] MESSAGE/RFC822 or MESSAGE/GLOBAL
HEADER.FIELDS and HEADER.FIELDS.NOT are followed by a list of message. HEADER.FIELDS and HEADER.FIELDS.NOT are followed by a
field-name (as defined in [RFC-5322]) names, and return a list of field-name (as defined in [RFC-5322]) names, and return
subset of the header. The subset returned by HEADER.FIELDS a subset of the header. The subset returned by HEADER.FIELDS
contains only those header fields with a field-name that contains only those header fields with a field-name that
matches one of the names in the list; similarly, the subset matches one of the names in the list; similarly, the subset
returned by HEADER.FIELDS.NOT contains only the header fields returned by HEADER.FIELDS.NOT contains only the header fields
with a non-matching field-name. The field-matching is case- with a non-matching field-name. The field-matching is ASCII
insensitive but otherwise exact. Subsetting does not exclude range case-insensitive but otherwise exact. Subsetting does
the [RFC-5322] delimiting blank line between the header and the not exclude the [RFC-5322] delimiting blank line between the
body; the blank line is included in all header fetches, except header and the body; the blank line is included in all header
in the case of a message which has no body and no blank line. fetches, except in the case of a message which has no body and
no blank line.
The MIME part specifier refers to the [MIME-IMB] header for The MIME part specifier refers to the [MIME-IMB] header for
this part. this part.
The TEXT part specifier refers to the text body of the message, The TEXT part specifier refers to the text body of the message,
omitting the [RFC-5322] header. omitting the [RFC-5322] header.
Here is an example of a complex message with some of its Here is an example of a complex message with some of its
part specifiers: part specifiers:
skipping to change at page 91, line 37 skipping to change at page 90, line 37
truncated. truncated.
Note: The origin octet facility MUST NOT be used by a server Note: The origin octet facility MUST NOT be used by a server
in a FETCH response unless the client specifically requested in a FETCH response unless the client specifically requested
it by means of a FETCH of a BODY[<section>]<<partial>> data it by means of a FETCH of a BODY[<section>]<<partial>> data
item. item.
8-bit textual data is permitted if a [CHARSET] identifier is 8-bit textual data is permitted if a [CHARSET] identifier is
part of the body parameter parenthesized list for this section. part of the body parameter parenthesized list for this section.
Note that headers (part specifiers HEADER or MIME, or the Note that headers (part specifiers HEADER or MIME, or the
header portion of a MESSAGE/RFC822 part), MUST be 7-bit; 8-bit header portion of a MESSAGE/RFC822 or MESSAGE/GLOBAL part), MAY
characters are not permitted in headers. Note also that the be in UTF-8. Note also that the [RFC-5322] delimiting blank
[RFC-5322] delimiting blank line between the header and the line between the header and the body is not affected by header
body is not affected by header line subsetting; the blank line line subsetting; the blank line is always included as part of
is always included as part of header data, except in the case header data, except in the case of a message which has no body
of a message which has no body and no blank line. and no blank line.
Non-textual data such as binary data MUST be transfer encoded Non-textual data such as binary data MUST be transfer encoded
into a textual form, such as BASE64, prior to being sent to the into a textual form, such as BASE64, prior to being sent to the
client. To derive the original binary data, the client MUST client. To derive the original binary data, the client MUST
decode the transfer encoded string. decode the transfer encoded string.
BODYSTRUCTURE BODYSTRUCTURE
A parenthesized list that describes the [MIME-IMB] body A parenthesized list that describes the [MIME-IMB] body
structure of a message. This is computed by the server by structure of a message. This is computed by the server by
skipping to change at page 96, line 14 skipping to change at page 95, line 14
7.5. Server Responses - Command Continuation Request 7.5. Server Responses - Command Continuation Request
The command continuation request response is indicated by a "+" token The command continuation request response is indicated by a "+" token
instead of a tag. This form of response indicates that the server is instead of a tag. This form of response indicates that the server is
ready to accept the continuation of a command from the client. The ready to accept the continuation of a command from the client. The
remainder of this response is a line of text. remainder of this response is a line of text.
This response is used in the AUTHENTICATE command to transmit server This response is used in the AUTHENTICATE command to transmit server
data to the client, and request additional client data. This data to the client, and request additional client data. This
response is also used if an argument to any command is a literal. response is also used if an argument to any command is a
synchronizing literal.
The client is not permitted to send the octets of the literal unless The client is not permitted to send the octets of the synchronizing
the server indicates that it is expected. This permits the server to literal unless the server indicates that it is expected. This
process commands and reject errors on a line-by-line basis. The permits the server to process commands and reject errors on a line-
remainder of the command, including the CRLF that terminates a by-line basis. The remainder of the command, including the CRLF that
command, follows the octets of the literal. If there are any terminates a command, follows the octets of the literal. If there
additional command arguments, the literal octets are followed by a are any additional command arguments, the literal octets are followed
space and those arguments. by a space and those arguments.
Example: C: A001 LOGIN {11} Example: C: A001 LOGIN {11}
S: + Ready for additional command text S: + Ready for additional command text
C: FRED FOOBAR {7} C: FRED FOOBAR {7}
S: + Ready for additional command text S: + Ready for additional command text
C: fat man C: fat man
S: A001 OK LOGIN completed S: A001 OK LOGIN completed
C: A044 BLURDYBLOOP {102856} C: A044 BLURDYBLOOP {102856}
S: A044 BAD No such command as "BLURDYBLOOP" S: A044 BAD No such command as "BLURDYBLOOP"
skipping to change at page 100, line 33 skipping to change at page 99, line 33
body-fld-md5 = nstring body-fld-md5 = nstring
body-fld-octets = number body-fld-octets = number
body-fld-param = "(" string SP string *(SP string SP string) ")" / nil body-fld-param = "(" string SP string *(SP string SP string) ")" / nil
body-type-1part = (body-type-basic / body-type-msg / body-type-text) body-type-1part = (body-type-basic / body-type-msg / body-type-text)
[SP body-ext-1part] [SP body-ext-1part]
body-type-basic = media-basic SP body-fields body-type-basic = media-basic SP body-fields
; MESSAGE subtype MUST NOT be "RFC822" ; MESSAGE subtype MUST NOT be "RFC822" or "GLOBAL"
body-type-mpart = 1*body SP media-subtype body-type-mpart = 1*body SP media-subtype
[SP body-ext-mpart] [SP body-ext-mpart]
; MULTIPART body part ; MULTIPART body part
body-type-msg = media-message SP body-fields SP envelope body-type-msg = media-message SP body-fields SP envelope
SP body SP body-fld-lines SP body SP body-fld-lines
body-type-text = media-text SP body-fields SP body-fld-lines body-type-text = media-text SP body-fields SP body-fld-lines
skipping to change at page 103, line 51 skipping to change at page 102, line 51
; Section 5.1 of [RFC4422] ; Section 5.1 of [RFC4422]
list = "LIST" SP mailbox SP list-mailbox list = "LIST" SP mailbox SP list-mailbox
list-mailbox = 1*list-char / string list-mailbox = 1*list-char / string
list-char = ATOM-CHAR / list-wildcards / resp-specials list-char = ATOM-CHAR / list-wildcards / resp-specials
list-wildcards = "%" / "*" list-wildcards = "%" / "*"
literal = "{" number "}" CRLF *CHAR8 literal = "{" number ["+"] "}" CRLF *CHAR8
; Number represents the number of CHAR8s ; Number represents the number of CHAR8s.
; A non-synchronizing literal is distinguished
; from a synchronizing literal by presence of the "+"
; before the closing "}".
; Non synchronizing literals are not allowed when sent
; from server to the client.
login = "LOGIN" SP userid SP password login = "LOGIN" SP userid SP password
lsub = "LSUB" SP mailbox SP list-mailbox lsub = "LSUB" SP mailbox SP list-mailbox
mailbox = "INBOX" / astring mailbox = "INBOX" / astring
; INBOX is case-insensitive. All case variants of ; INBOX is case-insensitive. All case variants of
; INBOX (e.g., "iNbOx") MUST be interpreted as INBOX ; INBOX (e.g., "iNbOx") MUST be interpreted as INBOX
; not as an astring. An astring which consists of ; not as an astring. An astring which consists of
; the case-insensitive sequence "I" "N" "B" "O" "X" ; the case-insensitive sequence "I" "N" "B" "O" "X"
skipping to change at page 104, line 43 skipping to change at page 103, line 49
mbx-list-sflag = "\Noselect" / "\Marked" / "\Unmarked" mbx-list-sflag = "\Noselect" / "\Marked" / "\Unmarked"
; Selectability flags; only one per LIST response ; Selectability flags; only one per LIST response
media-basic = ((DQUOTE ("APPLICATION" / "AUDIO" / "IMAGE" / media-basic = ((DQUOTE ("APPLICATION" / "AUDIO" / "IMAGE" /
"MESSAGE" / "VIDEO" / "FONT") DQUOTE) / string) SP "MESSAGE" / "VIDEO" / "FONT") DQUOTE) / string) SP
media-subtype media-subtype
; Defined in [MIME-IMT]. ; Defined in [MIME-IMT].
; FONT defined in RFC YYYY. ; FONT defined in RFC YYYY.
media-message = DQUOTE "MESSAGE" DQUOTE SP DQUOTE "RFC822" DQUOTE media-message = DQUOTE "MESSAGE" DQUOTE SP DQUOTE ("RFC822" / "GLOBAL") DQUOTE
; Defined in [MIME-IMT] ; Defined in [MIME-IMT]
media-subtype = string media-subtype = string
; Defined in [MIME-IMT] ; Defined in [MIME-IMT]
media-text = DQUOTE "TEXT" DQUOTE SP media-subtype media-text = DQUOTE "TEXT" DQUOTE SP media-subtype
; Defined in [MIME-IMT] ; Defined in [MIME-IMT]
message-data = nz-number SP ("EXPUNGE" / ("FETCH" SP msg-att)) message-data = nz-number SP ("EXPUNGE" / ("FETCH" SP msg-att))
msg-att = "(" (msg-att-dynamic / msg-att-static) msg-att = "(" (msg-att-dynamic / msg-att-static)
*(SP (msg-att-dynamic / msg-att-static)) ")" *(SP (msg-att-dynamic / msg-att-static)) ")"
msg-att-dynamic = "FLAGS" SP "(" [flag-fetch *(SP flag-fetch)] ")" msg-att-dynamic = "FLAGS" SP "(" [flag-fetch *(SP flag-fetch)] ")"
; MAY change for a message ; MAY change for a message
msg-att-static = "ENVELOPE" SP envelope / "INTERNALDATE" SP date-time / msg-att-static = "ENVELOPE" SP envelope / "INTERNALDATE" SP date-time /
"RFC822" [".HEADER" / ".TEXT"] SP nstring / "RFC822" [".HEADER" / ".TEXT"] SP nstring /
"RFC822.SIZE" SP number / "RFC822.SIZE" SP number /
"BODY" ["STRUCTURE"] SP body / "BODY" ["STRUCTURE"] SP body /
skipping to change at page 106, line 15 skipping to change at page 105, line 23
; Copied from RFC 5092 (IMAP URL) ; Copied from RFC 5092 (IMAP URL)
partial = "<" number "." nz-number ">" partial = "<" number "." nz-number ">"
; Partial FETCH request. 0-based offset of ; Partial FETCH request. 0-based offset of
; the first octet, followed by the number of octets ; the first octet, followed by the number of octets
; in the fragment. ; in the fragment.
quoted = DQUOTE *QUOTED-CHAR DQUOTE quoted = DQUOTE *QUOTED-CHAR DQUOTE
QUOTED-CHAR = <any TEXT-CHAR except quoted-specials> / QUOTED-CHAR = <any TEXT-CHAR except quoted-specials> /
"\" quoted-specials "\" quoted-specials / UTF8-2 / UTF8-3 / UTF8-4
quoted-specials = DQUOTE / "\" quoted-specials = DQUOTE / "\"
rename = "RENAME" SP mailbox SP mailbox rename = "RENAME" SP mailbox SP mailbox
; Use of INBOX as a destination gives a NO error ; Use of INBOX as a destination gives a NO error
response = *(continue-req / response-data) response-done response = *(continue-req / response-data) response-done
response-data = "*" SP (resp-cond-state / resp-cond-bye / response-data = "*" SP (resp-cond-state / resp-cond-bye /
mailbox-data / message-data / capability-data / mailbox-data / message-data / capability-data /
skipping to change at page 108, line 44 skipping to change at page 107, line 51
; Data for the returned search option. ; Data for the returned search option.
; A single "nz-number"/"number"/"number64" value ; A single "nz-number"/"number"/"number64" value
; can be returned as an atom (i.e., without ; can be returned as an atom (i.e., without
; quoting). A sequence-set can be returned ; quoting). A sequence-set can be returned
; as an atom as well. ; as an atom as well.
section = "[" [section-spec] "]" section = "[" [section-spec] "]"
section-msgtext = "HEADER" / "HEADER.FIELDS" [".NOT"] SP header-list / section-msgtext = "HEADER" / "HEADER.FIELDS" [".NOT"] SP header-list /
"TEXT" "TEXT"
; top-level or MESSAGE/RFC822 part ; top-level or MESSAGE/RFC822 or MESSAGE/GLOBAL part
section-part = nz-number *("." nz-number) section-part = nz-number *("." nz-number)
; body part reference. ; body part reference.
; Allows for accessing nested body parts. ; Allows for accessing nested body parts.
section-spec = section-msgtext / (section-part ["." section-text]) section-spec = section-msgtext / (section-part ["." section-text])
section-text = section-msgtext / "MIME" section-text = section-msgtext / "MIME"
; text other than actual body part (headers, etc.) ; text other than actual body part (headers, etc.)
skipping to change at page 111, line 29 skipping to change at page 110, line 36
; between these two regards of order. ; between these two regards of order.
; Example: 2:4 and 4:2 are equivalent. ; Example: 2:4 and 4:2 are equivalent.
uniqueid = nz-number uniqueid = nz-number
; Strictly ascending ; Strictly ascending
unsubscribe = "UNSUBSCRIBE" SP mailbox unsubscribe = "UNSUBSCRIBE" SP mailbox
userid = astring userid = astring
UTF8-2 = <Defined in Section 4 of RFC 3629>
UTF8-3 = <Defined in Section 4 of RFC 3629>
UTF8-4 = <Defined in Section 4 of RFC 3629>
x-command = "X" atom <experimental command arguments> x-command = "X" atom <experimental command arguments>
zone = ("+" / "-") 4DIGIT zone = ("+" / "-") 4DIGIT
; Signed four-digit value of hhmm representing ; Signed four-digit value of hhmm representing
; hours and minutes east of Greenwich (that is, ; hours and minutes east of Greenwich (that is,
; the amount that the given time differs from ; the amount that the given time differs from
; Universal Time). Subtracting the timezone ; Universal Time). Subtracting the timezone
; from the given time will give the UT form. ; from the given time will give the UT form.
; The Universal Time zone is "+0000". ; The Universal Time zone is "+0000".
skipping to change at page 116, line 9 skipping to change at page 115, line 26
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] 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>.
[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
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <http://www.rfc-editor.org/info/rfc3629>.
[MULTIAPPEND] [MULTIAPPEND]
Crispin, M., "Internet Message Access Protocol (IMAP) - Crispin, M., "Internet Message Access Protocol (IMAP) -
MULTIAPPEND Extension", RFC 3502, March 2003, MULTIAPPEND Extension", RFC 3502, March 2003,
<http://www.rfc-editor.org/info/rfc3502>. <http://www.rfc-editor.org/info/rfc3502>.
[IMAP-IMPLEMENTATION] [IMAP-IMPLEMENTATION]
Leiba, B., "IMAP4 Implementation Recommendations", Leiba, B., "IMAP4 Implementation Recommendations",
RFC 2683, September 1999, RFC 2683, September 1999,
<http://www.rfc-editor.org/info/rfc2683>. <http://www.rfc-editor.org/info/rfc2683>.
[IMAP-MULTIACCESS] [IMAP-MULTIACCESS]
Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice",
RFC 2180, July 1997, RFC 2180, July 1997,
<http://www.rfc-editor.org/info/rfc2180>. <http://www.rfc-editor.org/info/rfc2180>.
[NET-UNICODE]
Klensin, J. and M. Padlipsky, "Unicode Format for Network
Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008,
<https://www.rfc-editor.org/info/rfc5198>.
[I18N-HDRS]
Yang, A., Steele, S., and N. Freed, "Internationalized
Email Headers", RFC 6532, DOI 10.17487/RFC6532, February
2012, <https://www.rfc-editor.org/info/rfc6532>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[RFC7817] Melnikov, A., "Updated Transport Layer Security (TLS) [RFC7817] Melnikov, A., "Updated Transport Layer Security (TLS)
Server Identity Check Procedure for Email-Related Server Identity Check Procedure for Email-Related
Protocols", RFC 7817, DOI 10.17487/RFC7817, March 2016, Protocols", RFC 7817, DOI 10.17487/RFC7817, March 2016,
<https://www.rfc-editor.org/info/rfc7817>. <https://www.rfc-editor.org/info/rfc7817>.
[RFC7888] Melnikov, A., Ed., "IMAP4 Non-synchronizing Literals",
RFC 7888, DOI 10.17487/RFC7888, May 2016,
<https://www.rfc-editor.org/info/rfc7888>.
[RFC8314] Moore, K. and C. Newman, "Cleartext Considered Obsolete: [RFC8314] Moore, K. and C. Newman, "Cleartext Considered Obsolete:
Use of Transport Layer Security (TLS) for Email Submission Use of Transport Layer Security (TLS) for Email Submission
and Access", RFC 8314, DOI 10.17487/RFC8314, January 2018, and Access", RFC 8314, DOI 10.17487/RFC8314, January 2018,
<https://www.rfc-editor.org/info/rfc8314>. <https://www.rfc-editor.org/info/rfc8314>.
13.2. Informative References (related protocols) 13.2. Informative References (related protocols)
[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]
Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet
Message Access Protocol Internationalization", RFC 5255,
DOI 10.17487/RFC5255, June 2008,
<http://www.rfc-editor.org/info/rfc5255>.
[IMAP-MODEL] [IMAP-MODEL]
Crispin, M., "Distributed Electronic Mail Models in Crispin, M., "Distributed Electronic Mail Models in
IMAP4", RFC 1733, December 1994, IMAP4", RFC 1733, December 1994,
<http://www.rfc-editor.org/info/rfc1733>. <http://www.rfc-editor.org/info/rfc1733>.
[IMAP-UTF-8]
Resnick, P., Ed., Newman, C., Ed., and S. Shen, Ed., "IMAP
Support for UTF-8", RFC 6855, DOI 10.17487/RFC6855, March
2013, <http://www.rfc-editor.org/info/rfc6855>.
[ACAP] Newman, C. and J. G. Myers, "ACAP -- Application [ACAP] Newman, C. and J. G. Myers, "ACAP -- Application
Configuration Access Protocol", RFC 2244, November 1997, Configuration Access Protocol", RFC 2244, November 1997,
<http://www.rfc-editor.org/info/rfc2244>. <http://www.rfc-editor.org/info/rfc2244>.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008, <http://www.rfc-editor.org/info/rfc5321>. October 2008, <http://www.rfc-editor.org/info/rfc5321>.
[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
RFC 4314, December 2005, RFC 4314, December 2005,
<http://www.rfc-editor.org/info/rfc4314>. <http://www.rfc-editor.org/info/rfc4314>.
skipping to change at page 118, line 14 skipping to change at page 118, line 14
[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 response 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 "ENABLE IMAP4rev2" command. wants to use IMAP4rev2 MUST issue an "ENABLE IMAP4rev2" command.
Servers advertising both IMAP4rev1 and IMAP4rev2 SHOULD NOT generate
UTF-8 quoted strings unless the client has issued "ENABLE IMAP4rev2".
Consider implementation of mechanisms described or referenced in
[IMAP-UTF-8] to achieve this goal.
Servers advertising both IMAP4rev1 and IMAP4rev2, and clients
intending to be compatible with IMAP4rev1 servers MUST be compatible
with the international mailbox naming convention described in the
following subsection.
A.1. Mailbox International Naming Convention
By convention, international mailbox names in IMAP4rev2 are specified
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
earlier version of this protocol.
In modified UTF-7, printable US-ASCII characters, except for "&",
represent themselves; that is, characters with octet values 0x20-0x25
and 0x27-0x7e. The character "&" (0x26) is represented by the two-
octet sequence "&-".
All other characters (octet values 0x00-0x1f and 0x7f-0xff) are
represented in modified BASE64, with a further modification from
[UTF-7] that "," is used instead of "/". Modified BASE64 MUST NOT be
used to represent any printing US-ASCII character which can represent
itself. Only characters inside the modified BASE64 alphabet are
permitted in modified BASE64 text.
"&" is used to shift to modified BASE64 and "-" to shift back to US-
ASCII. There is no implicit shift from BASE64 to US-ASCII, and null
shifts ("-&" while in BASE64; note that "&-" while in US-ASCII means
"&") are not permitted. However, all names start in US-ASCII, and
MUST end in US-ASCII; that is, a name that ends with a non-ASCII
ISO-10646 character MUST end with a "-").
The purpose of these modifications is to correct the following
problems with UTF-7:
1. UTF-7 uses the "+" character for shifting; this conflicts with
the common use of "+" in mailbox names, in particular USENET
newsgroup names.
2. UTF-7's encoding is BASE64 which uses the "/" character; this
conflicts with the use of "/" as a popular hierarchy delimiter.
3. UTF-7 prohibits the unencoded usage of "\"; this conflicts with
the use of "\" as a popular hierarchy delimiter.
4. UTF-7 prohibits the unencoded usage of "~"; this conflicts with
the use of "~" in some servers as a home directory indicator.
5. UTF-7 permits multiple alternate forms to represent the same
string; in particular, printable US-ASCII characters can be
represented in encoded form.
Although modified UTF-7 is a convention, it establishes certain
requirements on server handling of any mailbox name with an embedded
"&" character. In particular, server implementations MUST preserve
the exact form of the modified BASE64 portion of a modified UTF-7
name and treat that text as case-sensitive, even if names are
otherwise case-insensitive or case-folded.
Server implementations SHOULD verify that any mailbox name with an
embedded "&" character, used as an argument to CREATE, is: in the
correctly modified UTF-7 syntax, has no superfluous shifts, and has
no encoding in modified BASE64 of any printing US-ASCII character
which can represent itself. However, client implementations MUST NOT
depend upon the server doing this, and SHOULD NOT attempt to create a
mailbox name with an embedded "&" character unless it complies with
the modified UTF-7 syntax.
Server implementations which export a mail store that does not follow
the modified UTF-7 convention MUST convert to modified UTF-7 any
mailbox name that contains either non-ASCII characters or the "&"
character.
For example, here is a mailbox name which mixes English, Chinese,
and Japanese text: ~peter/mail/&U,BTFw-/&ZeVnLIqe-
For example, the string "&Jjo!" is not a valid mailbox name
because it does not contain a shift to US-ASCII before the "!".
The correct form is "&Jjo-!". The string "&U,BTFw-&ZeVnLIqe-" is
not permitted because it contains a superfluous shift. The
correct form is "&U,BTF2XlZyyKng-".
Appendix B. Changes from RFC 3501 / IMAP4rev1 Appendix B. Changes from RFC 3501 / IMAP4rev1
The following is the plan for remaining changes. The plan might The following is the plan for remaining changes. The plan might
change over time. change over time.
1. Fold in the following extensions/RFC: RFC 5530 (IMAP Response 1. Fold in the following extensions/RFC: RFC 5530 (IMAP Response
Codes, done), UIDPLUS (done), ENABLE (done), ESEARCH (done), Codes, done), UIDPLUS (done), ENABLE (done), ESEARCH (done),
SPECIAL-USE (list of new mailbox attributes is done), LITERAL-, SPECIAL-USE (list of new mailbox attributes is done), LITERAL-
NAMESPACE (done), SASL-IR (done). (done), NAMESPACE (done), SASL-IR (done).
2. Add CLOSED response code (from CONDSTORE) - done 2. Add CLOSED response code (from CONDSTORE) - done
3. Add support for $MDNSent and $Forwarded IMAP keywords - done. 3. Add support for $MDNSent and $Forwarded IMAP keywords - done.
Add more examples showing their use? Add more examples showing their use?
4. Require all unsolicited updates to include UID (?) 4. Require all unsolicited updates to include UID (?)
5. Update recommendations on TLS ciphers to match UTA WG work (as 5. Update recommendations on TLS ciphers to match UTA WG work (as
per RFC 8314, RFC 7525 and RFC 7817) - done. per RFC 8314, RFC 7525 and RFC 7817) - done.
6. Possibly fold in the following extensions/RFC: Base LIST- 6. Possibly fold in the following extensions/RFC: Base LIST-
EXTENDED syntax plus deprecate LSUB (replace it with LIST EXTENDED syntax plus deprecate LSUB (replace it with LIST
\Subscribed) minus the requirement to support multiple list \Subscribed) minus the requirement to support multiple list
patterns, STATUS-in-LIST, Unique mailstore IDs for messages patterns, STATUS-in-LIST, Unique mailstore IDs for messages
(OBJECTID extension, see draft-ietf-extra-imap-objectid), IDLE (OBJECTID extension, RFC 8474), IDLE (done), SEARCHRES, BINARY
(done), SEARCHRES, BINARY. (possibly only the FETCH changes and make APPEND related ones
optional?).
7. Add STATUS SIZE (total mailbox size) - done Add STATUS DELETED 7. Add STATUS SIZE (total mailbox size) - done Add STATUS DELETED
(number of messages with \Deleted flag set)? (number of messages with \Deleted flag set)?
8. Deprecate features: RECENT response on SELECT/EXAMINE, \Recent 8. Deprecate features: RECENT response on SELECT/EXAMINE, \Recent
flag, RECENT STATUS item. UNSEEN response code on SELECT/ flag, RECENT STATUS item. UNSEEN response code on SELECT/
EXAMINE. SEARCH response (use ESEARCH instead). EXAMINE. SEARCH response (use ESEARCH instead).
9. Drop UTF-7, all mailboxes are always in UTF-8. 9. Drop UTF-7, all mailboxes are always in UTF-8 - done.
10. Revise IANA registration of IMAP extensions and advice on use of 10. Revise IANA registration of IMAP extensions and advice on use of
"X-" convention. "X-" convention.
The following changes since RFC 3501 were done so far: The following changes since RFC 3501 were done so far:
1. Folded in IMAP UNSELECT (RFC 3691), UIDPLUS (RFC 4315), ESEARCH 1. Folded in IMAP UNSELECT (RFC 3691), UIDPLUS (RFC 4315), ESEARCH
(RFC 4731), ENABLE (RFC 5161), IDLE (RFC 2177) and SASL-IR (RFC (RFC 4731), ENABLE (RFC 5161), IDLE (RFC 2177) and SASL-IR (RFC
4959) extensions. Also folded RFC 5530. 4959) extensions. Also folded RFC 5530.
skipping to change at page 119, line 29 skipping to change at page 121, line 22
8314, RFC 7817, RFC 7525. 8314, RFC 7817, RFC 7525.
4. For future extensibility extended ABNF for tagged-ext-simple to 4. For future extensibility extended ABNF for tagged-ext-simple to
allow for bare number64. allow for bare number64.
5. Added SHOULD level requirement on IMAP servers to support 5. Added SHOULD level requirement on IMAP servers to support
$MDNSent and $Forwarded keywords. $MDNSent and $Forwarded keywords.
6. Added STATUS SIZE. 6. Added STATUS SIZE.
7. Mailbox names and message headers now allow for UTF-8. Support
for Modified UTF-7 in mailbox names is not required, unless
compatibility with IMAP4rev1 is desired.
Appendix C. Acknowledgement Appendix C. 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. Editor of Sadly, he is no longer available to help with this work. Editor of
this revisions is hoping that Mark would have approved. this revisions is hoping that Mark would have approved.
Chris Newman has contributed text on I18N and use of UTF-8 in
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.
This document incorporate text from RFC 4315, RFC 4466, RFC 4731, RFC This document incorporate text from RFC 4315, RFC 4466, RFC 4731, RFC
5161, RFC 6154 so work done by authors/editors of these documents is 5161, RFC 6154 so work done by authors/editors of these documents is
appreciated. appreciated.
Index Index
$ $
$Forwarded (predefined flag) 12 $Forwarded (predefined flag) 12
$MDNSent (predefined flag) 12 $MDNSent (predefined flag) 12
+ +
+FLAGS <flag list> 68 +FLAGS <flag list> 67
+FLAGS.SILENT <flag list> 68 +FLAGS.SILENT <flag list> 67
- -
-FLAGS <flag list> 69 -FLAGS <flag list> 68
-FLAGS.SILENT <flag list> 69 -FLAGS.SILENT <flag list> 68
A A
ALERT (response code) 74 ALERT (response code) 73
ALL (fetch item) 65 ALL (fetch item) 64
ALL (search key) 61 ALL (search key) 60
ALL (search result option) 60 ALL (search result option) 59
ALREADYEXISTS (response code) 74 ALREADYEXISTS (response code) 73
ANSWERED (search key) 61 ANSWERED (search key) 60
APPEND (command) 52 APPEND (command) 51
APPENDUID (response code) 74 APPENDUID (response code) 73
AUTHENTICATE (command) 28 AUTHENTICATE (command) 27
AUTHENTICATIONFAILED (response code) 75 AUTHENTICATIONFAILED (response code) 74
AUTHORIZATIONFAILED (response code) 75 AUTHORIZATIONFAILED (response code) 74
B B
BAD (response) 81 BAD (response) 80
BADCHARSET (response code) 75 BADCHARSET (response code) 74
BCC <string> (search key) 61 BCC <string> (search key) 60
BEFORE <date> (search key) 61 BEFORE <date> (search key) 60
BODY (fetch item) 65 BODY (fetch item) 64
BODY (fetch result) 91 BODY (fetch result) 90
BODY <string> (search key) 61 BODY <string> (search key) 60
BODY.PEEK[<section>]<<partial>> (fetch item) 67 BODY.PEEK[<section>]<<partial>> (fetch item) 66
BODYSTRUCTURE (fetch item) 67 BODYSTRUCTURE (fetch item) 66
BODYSTRUCTURE (fetch result) 91 BODYSTRUCTURE (fetch result) 90
BODY[<section>]<<origin octet>> (fetch result) 91 BODY[<section>]<<origin octet>> (fetch result) 90
BODY[<section>]<<partial>> (fetch item) 65 BODY[<section>]<<partial>> (fetch item) 64
BYE (response) 82 BYE (response) 81
Body Structure (message attribute) 13 Body Structure (message attribute) 13
C C
CANNOT (response code) 75 CANNOT (response code) 74
CAPABILITY (command) 25 CAPABILITY (command) 24
CAPABILITY (response code) 75 CAPABILITY (response code) 74
CAPABILITY (response) 83 CAPABILITY (response) 82
CC <string> (search key) 61 CC <string> (search key) 60
CHECK (command) 57 CHECK (command) 56
CLIENTBUG (response code) 75 CLIENTBUG (response code) 74
CLOSE (command) 57 CLOSE (command) 56
CLOSED (response code) 76 CLOSED (response code) 75
CONTACTADMIN (response code) 76 CONTACTADMIN (response code) 75
COPY (command) 69 COPY (command) 68
COPYUID (response code) 76 COPYUID (response code) 75
CORRUPTION (response code) 77 CORRUPTION (response code) 76
COUNT (search result option) 60 COUNT (search result option) 59
CREATE (command) 37 CREATE (command) 36
D D
DELETE (command) 38 DELETE (command) 37
DELETED (search key) 61 DELETED (search key) 60
DRAFT (search key) 61 DRAFT (search key) 60
E E
ENABLE (command) 32 ENABLE (command) 31
ENVELOPE (fetch item) 67 ENVELOPE (fetch item) 66
ENVELOPE (fetch result) 94 ENVELOPE (fetch result) 93
ESEARCH (response) 88 ESEARCH (response) 87
EXAMINE (command) 36 EXAMINE (command) 35
EXPIRED (response code) 77 EXPIRED (response code) 76
EXPUNGE (command) 58 EXPUNGE (command) 57
EXPUNGE (response) 90 EXPUNGE (response) 89
EXPUNGEISSUED (response code) 77 EXPUNGEISSUED (response code) 76
Envelope Structure (message attribute) 13 Envelope Structure (message attribute) 13
F F
FAST (fetch item) 65 FAST (fetch item) 64
FETCH (command) 64 FETCH (command) 63
FETCH (response) 91 FETCH (response) 90
FLAGGED (search key) 61 FLAGGED (search key) 60
FLAGS (fetch item) 67 FLAGS (fetch item) 66
FLAGS (fetch result) 95 FLAGS (fetch result) 94
FLAGS (response) 88 FLAGS (response) 87
FLAGS <flag list> (store command data item) 68 FLAGS <flag list> (store command data item) 67
FLAGS.SILENT <flag list> (store command data item) 68 FLAGS.SILENT <flag list> (store command data item) 67
FROM <string> (search key) 61 FROM <string> (search key) 61
FULL (fetch item) 65 FULL (fetch item) 64
Flags (message attribute) 11 Flags (message attribute) 11
H H
HEADER (part specifier) 65 HEADER (part specifier) 64
HEADER <field-name> <string> (search key) 62 HEADER <field-name> <string> (search key) 61
HEADER.FIELDS (part specifier) 65 HEADER.FIELDS (part specifier) 64
HEADER.FIELDS.NOT (part specifier) 65 HEADER.FIELDS.NOT (part specifier) 64
I I
IDLE (command) 55 IDLE (command) 54
INTERNALDATE (fetch item) 67 INTERNALDATE (fetch item) 66
INTERNALDATE (fetch result) 95 INTERNALDATE (fetch result) 94
INUSE (response code) 77 INUSE (response code) 76
Internal Date (message attribute) 13 Internal Date (message attribute) 13
K K
KEYWORD <flag> (search key) 62 KEYWORD <flag> (search key) 61
Keyword (type of flag) 12 Keyword (type of flag) 12
L L
LARGER <n> (search key) 62 LARGER <n> (search key) 61
LIMIT (response code) 78 LIMIT (response code) 77
LIST (command) 42 LIST (command) 41
LIST (response) 84 LIST (response) 83
LOGOUT (command) 26 LOGOUT (command) 25
LSUB (command) 45 LSUB (command) 44
LSUB (response) 87 LSUB (response) 86
M M
MAX (search result option) 60 MAX (search result option) 59
MAY (specification requirement term) 5 MAY (specification requirement term) 5
MESSAGES (status item) 51 MESSAGES (status item) 50
MIME (part specifier) 66 MIME (part specifier) 65
MIN (search result option) 59 MIN (search result option) 58
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) 46 NAMESPACE (command) 45
NAMESPACE (response) 87 NAMESPACE (response) 86
NEW (search key) 62 NEW (search key) 61
NO (response) 81 NO (response) 80
NONEXISTENT (response code) 78 NONEXISTENT (response code) 77
NOOP (command) 26 NOOP (command) 25
NOPERM (response code) 78 NOPERM (response code) 77
NOT <search-key> (search key) 62 NOT <search-key> (search key) 61
O O
OK (response) 80 OK (response) 79
OLD (search key) 62 OLD (search key) 61
ON <date> (search key) 62 ON <date> (search key) 61
OPTIONAL (specification requirement term) 5 OPTIONAL (specification requirement term) 5
OR <search-key1> <search-key2> (search key) 62 OR <search-key1> <search-key2> (search key) 61
OVERQUOTA (response code) 78 OVERQUOTA (response code) 77
P P
PARSE (response code) 79 PARSE (response code) 78
PERMANENTFLAGS (response code) 79 PERMANENTFLAGS (response code) 78
PREAUTH (response) 82 PREAUTH (response) 81
PRIVACYREQUIRED (response code) 79 PRIVACYREQUIRED (response code) 78
Permanent Flag (class of flag) 12 Permanent Flag (class of flag) 12
Predefined keywords 12 Predefined keywords 12
R R
READ-ONLY (response code) 79 READ-ONLY (response code) 78
READ-WRITE (response code) 79 READ-WRITE (response code) 78
RECENT (search key) 62 RECENT (search key) 61
RECENT (status item) 51 RECENT (status item) 50
RECOMMENDED (specification requirement term) 5 RECOMMENDED (specification requirement term) 5
RENAME (command) 39 RENAME (command) 38
REQUIRED (specification requirement term) 5 REQUIRED (specification requirement term) 5
RFC822 (fetch item) 67 RFC822 (fetch item) 66
RFC822 (fetch result) 95 RFC822 (fetch result) 94
RFC822.HEADER (fetch item) 67 RFC822.HEADER (fetch item) 66
RFC822.HEADER (fetch result) 95 RFC822.HEADER (fetch result) 94
RFC822.SIZE (fetch item) 67 RFC822.SIZE (fetch item) 66
RFC822.SIZE (fetch result) 95 RFC822.SIZE (fetch result) 94
RFC822.TEXT (fetch item) 67 RFC822.TEXT (fetch item) 66
RFC822.TEXT (fetch result) 95 RFC822.TEXT (fetch result) 94
S S
SEARCH (command) 59 SEARCH (command) 58
SEEN (search key) 62 SEEN (search key) 61
SELECT (command) 34 SELECT (command) 33
SENTBEFORE <date> (search key) 62 SENTBEFORE <date> (search key) 61
SENTON <date> (search key) 62 SENTON <date> (search key) 61
SENTSINCE <date> (search key) 62 SENTSINCE <date> (search key) 61
SERVERBUG (response code) 79 SERVERBUG (response code) 78
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) 62 SINCE <date> (search key) 61
SIZE (status item) 52 SIZE (status item) 51
SMALLER <n> (search key) 62 SMALLER <n> (search key) 62
STARTTLS (command) 27 STARTTLS (command) 26
STATUS (command) 50 STATUS (command) 49
STATUS (response) 87 STATUS (response) 86
STORE (command) 68 STORE (command) 67
SUBJECT <string> (search key) 63 SUBJECT <string> (search key) 62
SUBSCRIBE (command) 41 SUBSCRIBE (command) 40
Session Flag (class of flag) 12 Session Flag (class of flag) 12
System Flag (type of flag) 11 System Flag (type of flag) 11
T T
TEXT (part specifier) 65 TEXT (part specifier) 64
TEXT <string> (search key) 63 TEXT <string> (search key) 62
TO <string> (search key) 63 TO <string> (search key) 62
TRYCREATE (response code) 79 TRYCREATE (response code) 78
U U
UID (command) 70 UID (command) 69
UID (fetch item) 67 UID (fetch item) 67
UID (fetch result) 95 UID (fetch result) 94
UID <sequence set> (search key) 63 UID <sequence set> (search key) 62
UIDNEXT (response code) 80 UIDNEXT (response code) 79
UIDNEXT (status item) 51 UIDNEXT (status item) 50
UIDNOTSTICKY (response code) 80 UIDNOTSTICKY (response code) 79
UIDVALIDITY (response code) 80 UIDVALIDITY (response code) 79
UIDVALIDITY (status item) 51 UIDVALIDITY (status item) 50
UNANSWERED (search key) 63 UNANSWERED (search key) 62
UNAVAILABLE (response code) 80 UNAVAILABLE (response code) 79
UNDELETED (search key) 63 UNDELETED (search key) 62
UNDRAFT (search key) 63 UNDRAFT (search key) 62
UNFLAGGED (search key) 63 UNFLAGGED (search key) 62
UNKEYWORD <flag> (search key) 63 UNKEYWORD <flag> (search key) 62
UNSEEN (response code) 80 UNSEEN (response code) 79
UNSEEN (search key) 63 UNSEEN (search key) 62
UNSEEN (status item) 52 UNSEEN (status item) 51
UNSELECT (command) 58 UNSELECT (command) 57
UNSUBSCRIBE (command) 42 UNSUBSCRIBE (command) 41
Unique Identifier (UID) (message attribute) 9 Unique Identifier (UID) (message attribute) 9
X X
X<atom> (command) 72 X<atom> (command) 71
[ [
[RFC-5322] Size (message attribute) 13 [RFC-5322] Size (message attribute) 13
\ \
\All (mailbox name attribute) 85 \All (mailbox name attribute) 84
\Answered (system flag) 11 \Answered (system flag) 11
\Archive (mailbox name attribute) 85 \Archive (mailbox name attribute) 84
\Deleted (system flag) 11 \Deleted (system flag) 11
\Draft (system flag) 12 \Draft (system flag) 12
\Drafts (mailbox name attribute) 86 \Drafts (mailbox name attribute) 85
\Flagged (mailbox name attribute) 86 \Flagged (mailbox name attribute) 85
\Flagged (system flag) 11 \Flagged (system flag) 11
\HasChildren (mailbox name attribute) 84 \HasChildren (mailbox name attribute) 83
\HasNoChildren (mailbox name attribute) 85 \HasNoChildren (mailbox name attribute) 84
\Junk (mailbox name attribute) 86 \Junk (mailbox name attribute) 85
\Marked (mailbox name attribute) 85 \Marked (mailbox name attribute) 84
\Noinferiors (mailbox name attribute) 84 \Noinferiors (mailbox name attribute) 83
\Noselect (mailbox name attribute) 84 \Noselect (mailbox name attribute) 83
\Recent (system flag) 12 \Recent (system flag) 12
\Seen (system flag) 11 \Seen (system flag) 11
\Sent (mailbox name attribute) 86 \Sent (mailbox name attribute) 85
\Trash (mailbox name attribute) 86 \Trash (mailbox name attribute) 85
\Unmarked (mailbox name attribute) 85 \Unmarked (mailbox name attribute) 84
Author's Address 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)
Huawei Technologies
Phone: +1 646 827 0648
Email: barryleiba@computer.org
URI: http://internetmessagingtechnology.org/
 End of changes. 86 change blocks. 
418 lines changed or deleted 514 lines changed or added

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