< draft-ietf-extra-imap4rev2-27.txt   draft-ietf-extra-imap4rev2-28.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: August 6, 2021 February 2, 2021 Expires: August 14, 2021 February 10, 2021
Internet Message Access Protocol (IMAP) - Version 4rev2 Internet Message Access Protocol (IMAP) - Version 4rev2
draft-ietf-extra-imap4rev2-27 draft-ietf-extra-imap4rev2-28
Abstract Abstract
The Internet Message Access Protocol, Version 4rev2 (IMAP4rev2) The Internet Message Access Protocol, Version 4rev2 (IMAP4rev2)
allows a client to access and manipulate electronic mail messages on allows a client to access and manipulate electronic mail messages on
a server. IMAP4rev2 permits manipulation of mailboxes (remote a server. IMAP4rev2 permits manipulation of mailboxes (remote
message folders) in a way that is functionally equivalent to local message folders) in a way that is functionally equivalent to local
folders. IMAP4rev2 also provides the capability for an offline folders. IMAP4rev2 also provides the capability for an offline
client to resynchronize with the server. client to resynchronize with the server.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 6, 2021. This Internet-Draft will expire on August 14, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 39 skipping to change at page 3, line 39
6.2.1. STARTTLS Command . . . . . . . . . . . . . . . . . . 28 6.2.1. STARTTLS Command . . . . . . . . . . . . . . . . . . 28
6.2.2. AUTHENTICATE Command . . . . . . . . . . . . . . . . 30 6.2.2. AUTHENTICATE Command . . . . . . . . . . . . . . . . 30
6.2.3. LOGIN Command . . . . . . . . . . . . . . . . . . . . 33 6.2.3. LOGIN Command . . . . . . . . . . . . . . . . . . . . 33
6.3. Client Commands - Authenticated State . . . . . . . . . . 34 6.3. Client Commands - Authenticated State . . . . . . . . . . 34
6.3.1. ENABLE Command . . . . . . . . . . . . . . . . . . . 34 6.3.1. ENABLE Command . . . . . . . . . . . . . . . . . . . 34
6.3.2. SELECT Command . . . . . . . . . . . . . . . . . . . 36 6.3.2. SELECT Command . . . . . . . . . . . . . . . . . . . 36
6.3.3. EXAMINE Command . . . . . . . . . . . . . . . . . . . 38 6.3.3. EXAMINE Command . . . . . . . . . . . . . . . . . . . 38
6.3.4. CREATE Command . . . . . . . . . . . . . . . . . . . 39 6.3.4. CREATE Command . . . . . . . . . . . . . . . . . . . 39
6.3.5. DELETE Command . . . . . . . . . . . . . . . . . . . 40 6.3.5. DELETE Command . . . . . . . . . . . . . . . . . . . 40
6.3.6. RENAME Command . . . . . . . . . . . . . . . . . . . 42 6.3.6. RENAME Command . . . . . . . . . . . . . . . . . . . 42
6.3.7. SUBSCRIBE Command . . . . . . . . . . . . . . . . . . 44 6.3.7. SUBSCRIBE Command . . . . . . . . . . . . . . . . . . 45
6.3.8. UNSUBSCRIBE Command . . . . . . . . . . . . . . . . . 45 6.3.8. UNSUBSCRIBE Command . . . . . . . . . . . . . . . . . 45
6.3.9. LIST Command . . . . . . . . . . . . . . . . . . . . 45 6.3.9. LIST Command . . . . . . . . . . . . . . . . . . . . 46
6.3.10. NAMESPACE Command . . . . . . . . . . . . . . . . . . 64 6.3.10. NAMESPACE Command . . . . . . . . . . . . . . . . . . 64
6.3.11. STATUS Command . . . . . . . . . . . . . . . . . . . 68 6.3.11. STATUS Command . . . . . . . . . . . . . . . . . . . 68
6.3.12. APPEND Command . . . . . . . . . . . . . . . . . . . 69 6.3.12. APPEND Command . . . . . . . . . . . . . . . . . . . 69
6.3.13. IDLE Command . . . . . . . . . . . . . . . . . . . . 72 6.3.13. IDLE Command . . . . . . . . . . . . . . . . . . . . 72
6.4. Client Commands - Selected State . . . . . . . . . . . . 74 6.4. Client Commands - Selected State . . . . . . . . . . . . 74
6.4.1. CLOSE Command . . . . . . . . . . . . . . . . . . . . 75 6.4.1. CLOSE Command . . . . . . . . . . . . . . . . . . . . 75
6.4.2. UNSELECT Command . . . . . . . . . . . . . . . . . . 75 6.4.2. UNSELECT Command . . . . . . . . . . . . . . . . . . 75
6.4.3. EXPUNGE Command . . . . . . . . . . . . . . . . . . . 76 6.4.3. EXPUNGE Command . . . . . . . . . . . . . . . . . . . 76
6.4.4. SEARCH Command . . . . . . . . . . . . . . . . . . . 76 6.4.4. SEARCH Command . . . . . . . . . . . . . . . . . . . 76
6.4.5. FETCH Command . . . . . . . . . . . . . . . . . . . . 88 6.4.5. FETCH Command . . . . . . . . . . . . . . . . . . . . 88
6.4.6. STORE Command . . . . . . . . . . . . . . . . . . . . 93 6.4.6. STORE Command . . . . . . . . . . . . . . . . . . . . 93
6.4.7. COPY Command . . . . . . . . . . . . . . . . . . . . 94 6.4.7. COPY Command . . . . . . . . . . . . . . . . . . . . 94
6.4.8. MOVE Command . . . . . . . . . . . . . . . . . . . . 95 6.4.8. MOVE Command . . . . . . . . . . . . . . . . . . . . 95
6.4.9. UID Command . . . . . . . . . . . . . . . . . . . . . 97 6.4.9. UID Command . . . . . . . . . . . . . . . . . . . . . 97
6.5. Client Commands - Experimental/Expansion . . . . . . . . 99 6.5. Client Commands - Experimental/Expansion . . . . . . . . 99
7. Server Responses . . . . . . . . . . . . . . . . . . . . . . 99 7. Server Responses . . . . . . . . . . . . . . . . . . . . . . 99
7.1. Server Responses - Generic Status Responses . . . . . . . 100 7.1. Server Responses - Generic Status Responses . . . . . . . 100
7.1.1. OK Response . . . . . . . . . . . . . . . . . . . . . 108 7.1.1. OK Response . . . . . . . . . . . . . . . . . . . . . 109
7.1.2. NO Response . . . . . . . . . . . . . . . . . . . . . 109 7.1.2. NO Response . . . . . . . . . . . . . . . . . . . . . 109
7.1.3. BAD Response . . . . . . . . . . . . . . . . . . . . 109 7.1.3. BAD Response . . . . . . . . . . . . . . . . . . . . 109
7.1.4. PREAUTH Response . . . . . . . . . . . . . . . . . . 110 7.1.4. PREAUTH Response . . . . . . . . . . . . . . . . . . 110
7.1.5. BYE Response . . . . . . . . . . . . . . . . . . . . 110 7.1.5. BYE Response . . . . . . . . . . . . . . . . . . . . 110
7.2. Server Responses - Server Status . . . . . . . . . . . . 111 7.2. Server Responses - Server Status . . . . . . . . . . . . 111
7.2.1. ENABLED Response . . . . . . . . . . . . . . . . . . 111 7.2.1. ENABLED Response . . . . . . . . . . . . . . . . . . 111
7.2.2. CAPABILITY Response . . . . . . . . . . . . . . . . . 111 7.2.2. CAPABILITY Response . . . . . . . . . . . . . . . . . 111
7.3. Server Responses - Mailbox Status . . . . . . . . . . . . 112 7.3. Server Responses - Mailbox Status . . . . . . . . . . . . 113
7.3.1. LIST Response . . . . . . . . . . . . . . . . . . . . 112 7.3.1. LIST Response . . . . . . . . . . . . . . . . . . . . 113
7.3.2. NAMESPACE Response . . . . . . . . . . . . . . . . . 116 7.3.2. NAMESPACE Response . . . . . . . . . . . . . . . . . 117
7.3.3. STATUS Response . . . . . . . . . . . . . . . . . . . 117 7.3.3. STATUS Response . . . . . . . . . . . . . . . . . . . 117
7.3.4. ESEARCH Response . . . . . . . . . . . . . . . . . . 117 7.3.4. ESEARCH Response . . . . . . . . . . . . . . . . . . 117
7.3.5. FLAGS Response . . . . . . . . . . . . . . . . . . . 117 7.3.5. FLAGS Response . . . . . . . . . . . . . . . . . . . 119
7.4. Server Responses - Mailbox Size . . . . . . . . . . . . . 118 7.4. Server Responses - Mailbox Size . . . . . . . . . . . . . 119
7.4.1. EXISTS Response . . . . . . . . . . . . . . . . . . . 118 7.4.1. EXISTS Response . . . . . . . . . . . . . . . . . . . 119
7.5. Server Responses - Message Status . . . . . . . . . . . . 118 7.5. Server Responses - Message Status . . . . . . . . . . . . 119
7.5.1. EXPUNGE Response . . . . . . . . . . . . . . . . . . 118 7.5.1. EXPUNGE Response . . . . . . . . . . . . . . . . . . 119
7.5.2. FETCH Response . . . . . . . . . . . . . . . . . . . 119 7.5.2. FETCH Response . . . . . . . . . . . . . . . . . . . 120
7.6. Server Responses - Command Continuation Request . . . . . 125 7.6. Server Responses - Command Continuation Request . . . . . 126
8. Sample IMAP4rev2 connection . . . . . . . . . . . . . . . . . 126 8. Sample IMAP4rev2 connection . . . . . . . . . . . . . . . . . 127
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 127 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 128
10. Author's Note . . . . . . . . . . . . . . . . . . . . . . . . 145 10. Author's Note . . . . . . . . . . . . . . . . . . . . . . . . 146
11. Security Considerations . . . . . . . . . . . . . . . . . . . 145 11. Security Considerations . . . . . . . . . . . . . . . . . . . 146
11.1. TLS related Security Considerations . . . . . . . . . . 145 11.1. TLS related Security Considerations . . . . . . . . . . 147
11.2. STARTTLS command versa use of Implicit TLS port . . . . 146 11.2. STARTTLS command versa use of Implicit TLS port . . . . 147
11.3. Client handling of unsolicited responses not suitable 11.3. Client handling of unsolicited responses not suitable
for the current connection state . . . . . . . . . . . . 146 for the current connection state . . . . . . . . . . . . 148
11.4. COPYUID and APPENDUID response codes . . . . . . . . . . 147 11.4. COPYUID and APPENDUID response codes . . . . . . . . . . 148
11.5. LIST command and Other Users' namespace . . . . . . . . 147 11.5. LIST command and Other Users' namespace . . . . . . . . 149
11.6. Other Security Considerations . . . . . . . . . . . . . 147 11.6. Other Security Considerations . . . . . . . . . . . . . 149
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 148 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 150
12.1. Updates to IMAP4 Capabilities registry . . . . . . . . . 149 12.1. Updates to IMAP4 Capabilities registry . . . . . . . . . 150
12.2. GSSAPI/SASL service name . . . . . . . . . . . . . . . . 149 12.2. GSSAPI/SASL service name . . . . . . . . . . . . . . . . 151
12.3. LIST Selection Options, LIST Return Options, LIST 12.3. LIST Selection Options, LIST Return Options, LIST
extended data items . . . . . . . . . . . . . . . . . . 149 extended data items . . . . . . . . . . . . . . . . . . 151
12.4. IMAP Mailbox Name Attributes and IMAP Response Codes . . 150 12.4. IMAP Mailbox Name Attributes and IMAP Response Codes . . 151
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 150 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 151
13.1. Normative References . . . . . . . . . . . . . . . . . . 150 13.1. Normative References . . . . . . . . . . . . . . . . . . 151
13.2. Informative References (related protocols) . . . . . . . 153 13.2. Informative References (related protocols) . . . . . . . 155
13.3. Informative References (historical aspects of IMAP and 13.3. Informative References (historical aspects of IMAP and
related protocols) . . . . . . . . . . . . . . . . . . . 155 related protocols) . . . . . . . . . . . . . . . . . . . 157
Appendix A. Backward compatibility with IMAP4rev1 . . . . . . . 156 Appendix A. Backward compatibility with IMAP4rev1 . . . . . . . 158
A.1. Mailbox International Naming Convention for compatibility A.1. Mailbox International Naming Convention for compatibility
with IMAP4rev1 . . . . . . . . . . . . . . . . . . . . . 157 with IMAP4rev1 . . . . . . . . . . . . . . . . . . . . . 158
Appendix B. Backward compatibility with BINARY extension . . . . 158 Appendix B. Backward compatibility with BINARY extension . . . . 160
Appendix C. Backward compatibility with LIST-EXTENDED extension 159 Appendix C. Backward compatibility with LIST-EXTENDED extension 160
Appendix D. 63 bit body part and message sizes . . . . . . . . . 159 Appendix D. 63 bit body part and message sizes . . . . . . . . . 160
Appendix E. Changes from RFC 3501 / IMAP4rev1 . . . . . . . . . 159 Appendix E. Changes from RFC 3501 / IMAP4rev1 . . . . . . . . . 161
Appendix F. Other Recommended IMAP Extensions . . . . . . . . . 161 Appendix F. Other Recommended IMAP Extensions . . . . . . . . . 163
Appendix G. Acknowledgement . . . . . . . . . . . . . . . . . . 162 Appendix G. Acknowledgement . . . . . . . . . . . . . . . . . . 163
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 167 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 169
1. How to Read This Document 1. How to Read This Document
1.1. Organization of This Document 1.1. Organization of This Document
This document is written from the point of view of the implementor of This document is written from the point of view of the implementor of
an IMAP4rev2 client or server. Beyond the protocol overview in an IMAP4rev2 client or server. Beyond the protocol overview in
section 2, it is not optimized for someone trying to understand the section 2, it is not optimized for someone trying to understand the
operation of the protocol. The material in sections 3 through 5 operation of the protocol. The material in sections 3 through 5
provides the general context and definitions with which IMAP4rev2 provides the general context and definitions with which IMAP4rev2
skipping to change at page 7, line 19 skipping to change at page 7, line 19
compatibility with BINARY and LIST-EXTENDED IMAP extensions are compatibility with BINARY and LIST-EXTENDED IMAP extensions are
described in Appendix B and Appendix C respectively. 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, "RFC822.SIZE" fetch item in IMAP incorporates
their name. In all cases, "RFC822" should be interpreted as a "RFC822" in its name. "RFC822" should be interpreted as a reference
reference to the updated [RFC-5322] standard. to the updated [RFC-5322] standard.
2. Protocol Overview 2. Protocol Overview
2.1. Link Level 2.1. Link Level
The IMAP4rev2 protocol assumes a reliable data stream such as that The IMAP4rev2 protocol assumes a reliable data stream such as that
provided by TCP. When TCP is used, an IMAP4rev2 server listens on provided by TCP. When TCP is used, an IMAP4rev2 server listens on
port 143 (cleartext port) or port 993 (Implicit TLS port). port 143 (cleartext port) or port 993 (Implicit TLS port).
2.2. Commands and Responses 2.2. Commands and Responses
skipping to change at page 8, line 18 skipping to change at page 8, line 18
There are two cases in which a line from the client does not There are two cases in which a line from the client does not
represent a complete command. In one case, a command argument is represent a complete command. In one case, a command argument is
quoted with an octet count (see the description of literal in quoted with an octet count (see the description of literal in
Section 4.3); in the other case, the command arguments require server Section 4.3); in the other case, the command arguments require server
feedback (see the AUTHENTICATE command in Section 6.2.2). In either feedback (see the AUTHENTICATE command in Section 6.2.2). In either
case, the server sends a command continuation request response if it case, the server sends a command continuation request response if it
is ready for the octets (if appropriate) and the remainder of the is ready for the octets (if appropriate) and the remainder of the
command. This response is prefixed with the token "+". command. This response is prefixed with the token "+".
Note: If instead, the server detected an error in the command, it Note: If, instead, the server detected an error in the command, it
sends a BAD completion response with a tag matching the command sends a BAD completion response with a tag matching the command
(as described below) to reject the command and prevent the client (as described below) to reject the command and prevent the client
from sending any more of the command. from sending any more of the command.
It is also possible for the server to send a completion response It is also possible for the server to send a completion response
for some other command (if multiple commands are in progress), or for some other command (if multiple commands are in progress), or
untagged data. In either case, the command continuation request untagged data. In either case, the command continuation request
is still pending; the client takes the appropriate action for the is still pending; the client takes the appropriate action for the
response, and reads another response from the server. In all response, and reads another response from the server. In all
cases, the client MUST send a complete command (including cases, the client MUST send a complete command (including
receiving all command continuation request responses and command receiving all command continuation request responses and sending
continuations for the command) before initiating a new command. command continuations for the command) before initiating a new
command.
The protocol receiver of an IMAP4rev2 server reads a command line The protocol receiver of an IMAP4rev2 server reads a command line
from the client, parses the command and its arguments, and transmits from the client, parses the command and its arguments, and transmits
server data and a server command completion result response. server data and a server command completion result response.
2.2.2. Server Protocol Sender and Client Protocol Receiver 2.2.2. Server Protocol Sender and Client Protocol Receiver
Data transmitted by the server to the client and status responses Data transmitted by the server to the client and status responses
that do not indicate command completion are prefixed with the token that do not indicate command completion are prefixed with the token
"*", and are called untagged responses. "*", and are called untagged responses.
skipping to change at page 13, line 7 skipping to change at page 13, line 7
$Forwarded Message has been forwarded to another email address, $Forwarded Message has been forwarded to another email address,
embedded within or attached to a new message. An email client embedded within or attached to a new message. An email client
sets this keyword when it successfully forwards the message to sets this keyword when it successfully forwards the message to
another email address. Typical usage of this keyword is to show a another email address. Typical usage of this keyword is to show a
different (or additional) icon for a message that has been different (or additional) icon for a message that has been
forwarded. Once set, the flag SHOULD NOT be cleared. forwarded. Once set, the flag SHOULD NOT be cleared.
$MDNSent Message Disposition Notification [RFC8098] was generated $MDNSent Message Disposition Notification [RFC8098] was generated
and sent for this message. See [RFC3503] for more details on how and sent for this message. See [RFC3503] for more details on how
this keyword is used. this keyword is used and for requirements on clients and servers.
$Junk The user (or a delivery agent on behalf of the user) may $Junk The user (or a delivery agent on behalf of the user) may
choose to mark a message as definitely containing junk ($Junk; see choose to mark a message as definitely containing junk ($Junk; see
also the related keyword $NotJunk). The $Junk keyword can be used also the related keyword $NotJunk). The $Junk keyword can be used
to mark (and potentially move/delete messages later), group or to mark (and potentially move/delete messages later), group or
hide undesirable messages. See [IMAP-KEYWORDS-REG] for more hide undesirable messages. See [IMAP-KEYWORDS-REG] for more
information. information.
$NotJunk The user (or a delivery agent on behalf of the user) may $NotJunk The user (or a delivery agent on behalf of the user) may
choose to mark a message as definitely not containing junk choose to mark a message as definitely not containing junk
skipping to change at page 15, line 21 skipping to change at page 15, line 21
entered when a connection starts unless the connection has been pre- entered when a connection starts unless the connection has been pre-
authenticated. authenticated.
3.2. Authenticated State 3.2. Authenticated State
In the authenticated state, the client is authenticated and MUST In the authenticated state, the client is authenticated and MUST
select a mailbox to access before commands that affect messages will select a mailbox to access before commands that affect messages will
be permitted. This state is entered when a pre-authenticated be permitted. This state is entered when a pre-authenticated
connection starts, when acceptable authentication credentials have connection starts, when acceptable authentication credentials have
been provided, after an error in selecting a mailbox, or after a been provided, after an error in selecting a mailbox, or after a
successful CLOSE command. successful CLOSE or UNSELECT command.
3.3. Selected State 3.3. Selected State
In a selected state, a mailbox has been selected to access. This In a selected state, a mailbox has been selected to access. This
state is entered when a mailbox has been successfully selected. state is entered when a mailbox has been successfully selected.
3.4. Logout State 3.4. Logout State
In the logout state, the connection is being terminated. This state In the logout state, the connection is being terminated. This state
can be entered as a result of a client request (via the LOGOUT can be entered as a result of a client request (via the LOGOUT
skipping to change at page 16, line 44 skipping to change at page 16, line 44
\/ \/
+-------------------------------+ +-------------------------------+
|both sides close the connection| |both sides close the connection|
+-------------------------------+ +-------------------------------+
(1) connection without pre-authentication (OK greeting) (1) connection without pre-authentication (OK greeting)
(2) pre-authenticated connection (PREAUTH greeting) (2) pre-authenticated connection (PREAUTH greeting)
(3) rejected connection (BYE greeting) (3) rejected connection (BYE greeting)
(4) successful LOGIN or AUTHENTICATE command (4) successful LOGIN or AUTHENTICATE command
(5) successful SELECT or EXAMINE command (5) successful SELECT or EXAMINE command
(6) CLOSE command, unsolicited CLOSED response code or (6) CLOSE or UNSELECT command, unsolicited CLOSED
failed SELECT or EXAMINE command response code or failed SELECT or EXAMINE command
(7) LOGOUT command, server shutdown, or connection closed (7) LOGOUT command, server shutdown, or connection closed
4. Data Formats 4. Data Formats
IMAP4rev2 uses textual commands and responses. Data in IMAP4rev2 can IMAP4rev2 uses textual commands and responses. Data in IMAP4rev2 can
be in one of several forms: atom, number, string, parenthesized list, be in one of several forms: atom, number, string, parenthesized list,
or NIL. Note that a particular data item may take more than one or NIL. Note that a particular data item may take more than one
form; for example, a data item defined as using "astring" syntax may form; for example, a data item defined as using "astring" syntax may
be either an atom or a string. be either an atom or a string.
skipping to change at page 17, line 45 skipping to change at page 17, line 45
4.3. String 4.3. String
A string is in one of three forms: synchronizing literal, non- A string is in one of three forms: synchronizing literal, non-
synchronizing literal or quoted string. The synchronizing literal synchronizing literal or quoted string. The synchronizing literal
form is the general form of string. The non-synchronizing literal form is the general form of string. The non-synchronizing literal
form is also the general form, but has length limitation. The quoted form is also the general form, but has length limitation. The quoted
string form is an alternative that avoids the overhead of processing 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 at the cost of limitations of characters which may be used.
When the distinction between synchronizing and non-synchronizing When the distinction between synchronizing and non-synchronizing
literals is not important, this document just uses the term literals is not important, this document only uses the term
"literal". "literal".
A synchronizing literal is a sequence of zero or more octets A synchronizing literal is a sequence of zero or more octets
(including CR and LF), prefix-quoted with an octet count in the form (including CR and LF), prefix-quoted with an octet count in the form
of an open brace ("{"), the number of octets, close brace ("}"), and of an open brace ("{"), the number of octets, close brace ("}"), and
CRLF. In the case of synchronizing literals transmitted from server CRLF. In the case of synchronizing literals transmitted from server
to client, the CRLF is immediately followed by the octet data. In to client, the CRLF is immediately followed by the octet data. In
the case of synchronizing literals transmitted from client to server, the case of synchronizing literals transmitted from client to server,
the client MUST wait to receive a command continuation request the client MUST wait to receive a command continuation request
(described later in this document) before sending the octet data (and (described later in this document) before sending the octet data (and
skipping to change at page 18, line 18 skipping to change at page 18, line 18
The non-synchronizing literal is an alternative form of synchronizing The non-synchronizing literal is an alternative form of synchronizing
literal, and it may appear in communication from client to server literal, and it may appear in communication from client to server
instead of the synchonizing form of literal. The non-synchronizing instead of the synchonizing form of literal. The non-synchronizing
literal form MUST NOT be sent from server to client. The non- literal form MUST NOT be sent from server to client. The non-
synchronizing literal is distinguished from the synchronizing literal synchronizing literal is distinguished from the synchronizing literal
by having a plus ("+") between the octet count and the closing brace by having a plus ("+") between the octet count and the closing brace
("}"). The server does not generate a command continuation request ("}"). The server does not generate a command continuation request
in response to a non-synchronizing literal, and clients are not in response to a non-synchronizing literal, and clients are not
required to wait before sending the octets of a non- synchronizing required to wait before sending the octets of a non- synchronizing
literal. Non-synchronizing literals MUST NOT be larger than 4096 literal. Unless specified otherwise in an IMAP extension, non-
octets. Any literal larger than 4096 bytes MUST be sent as a synchronizing literals MUST NOT be larger than 4096 octets. Any
synchronizing literal. (Non-synchronizing literals defined in this literal larger than 4096 bytes MUST be sent as a synchronizing
document are the same as non-synchronizing literals defined by the literal. (Non-synchronizing literals defined in this document are
LITERAL- extension from [RFC7888]. See that document for details on the same as non-synchronizing literals defined by the LITERAL-
how to handle invalid non-synchronizing literals longer than 4096 extension from [RFC7888]. See that document for details on how to
octets and for interaction with other IMAP extensions.) 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, A quoted string is a sequence of zero or more Unicode characters,
excluding CR and LF, encoded in UTF-8, with double quote (<">) excluding CR and LF, encoded in UTF-8, with double quote (<">)
characters at each end. characters at each end.
The empty string is represented as "" (a quoted string with zero The empty string is represented as "" (a quoted string with zero
characters between double quotes), as {0} followed by CRLF (a characters between double quotes), as {0} followed by CRLF (a
synchronizing literal with an octet count of 0) or as {0+} followed synchronizing literal with an octet count of 0) or as {0+} followed
by CRLF (a non-synchronizing literal with an octet count of 0). by CRLF (a non-synchronizing literal with an octet count of 0).
skipping to change at page 22, line 42 skipping to change at page 22, line 42
"#news.comp.mail.misc", and the name "comp.mail.misc" can refer to "#news.comp.mail.misc", and the name "comp.mail.misc" can refer to
a different object (e.g., a user's private mailbox). a different object (e.g., a user's private mailbox).
Namespaces that include the "#" character are not IMAP URL [IMAP-URL] Namespaces that include the "#" character are not IMAP URL [IMAP-URL]
friendly requiring the "#" character to be represented as %23 when friendly requiring the "#" character to be represented as %23 when
within URLs. As such, server implementors MAY instead consider using within URLs. As such, server implementors MAY instead consider using
namespace prefixes that do not contain the "#" character. namespace prefixes that do not contain the "#" character.
5.1.2.2. Common namespace models 5.1.2.2. Common namespace models
Previous version of this protocol does not define a default server The previous version of this protocol did not define a default server
namespace. Two common namespace models have evolved: namespace. Two common namespace models have evolved:
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.
skipping to change at page 26, line 32 skipping to change at page 26, line 32
with "IMAP4rev2" as one of the listed capabilities before the with "IMAP4rev2" as one of the listed capabilities before the
(tagged) OK response. (tagged) OK response.
A capability name which begins with "AUTH=" indicates that the server A capability name which begins with "AUTH=" indicates that the server
supports that particular authentication mechanism as defined in supports that particular authentication mechanism as defined in
[SASL]. All such names are, by definition, part of this [SASL]. All such names are, by definition, part of this
specification. specification.
Other capability names refer to extensions, revisions, or amendments Other capability names refer to extensions, revisions, or amendments
to this specification. See the documentation of the CAPABILITY to this specification. See the documentation of the CAPABILITY
response in Section 7.2.2 for additional information. No response in Section 7.2.2 for additional information. If IMAP4rev1
capabilities, beyond the base IMAP4rev2 set defined in this capability is not advertised, no capabilities, beyond the base
specification, are enabled without explicit client action to invoke IMAP4rev2 set defined in this specification, are enabled without
the capability. explicit client action to invoke the capability. If both IMAP4rev1
and IMAP4rev2 capabilities are advertised, no capabilities, beyond
the base IMAP4rev1 set specified in RFC 3501, are enabled without
explicit client action to invoke the capability.
Client and server implementations MUST implement the STARTTLS Client and server implementations MUST implement the STARTTLS
Section 6.2.1, LOGINDISABLED, and AUTH=PLAIN (described in [PLAIN]) Section 6.2.1, LOGINDISABLED, and AUTH=PLAIN (described in [PLAIN])
capabilities. See the Security Considerations (Section 11) for capabilities. See the Security Considerations (Section 11) for
important information. important information.
Unless specified otherwise, all registered extensions to IMAP4rev1 Unless specified otherwise, all registered extensions to IMAP4rev1
are also valid extensions to IMAP4rev2. are also valid extensions to IMAP4rev2.
Example: C: abcd CAPABILITY Example: C: abcd CAPABILITY
skipping to change at page 29, line 50 skipping to change at page 29, line 50
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 AUTHENTICATE PLAIN dGVzdAB0ZXN0AHRlc3Q=
S: a004 OK LOGIN completed S: a004 OK Success (tls protection)
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 30, line 48 skipping to change at page 30, line 48
authentication mechanism. A server challenge consists of a command authentication mechanism. A server challenge consists of a command
continuation request response with the "+" token followed by a BASE64 continuation request response with the "+" token followed by a BASE64
encoded (see Section 4 of [RFC4648]) string. The client response encoded (see Section 4 of [RFC4648]) string. The client response
consists of a single line consisting of a BASE64 encoded string. If consists of a single line consisting of a BASE64 encoded string. If
the client wishes to cancel an authentication exchange, it issues a the client wishes to cancel an authentication exchange, it issues a
line consisting of a single "*". If the server receives such a line consisting of a single "*". If the server receives such a
response, or if it receives an invalid BASE64 string (e.g. response, or if it receives an invalid BASE64 string (e.g.
characters outside the BASE64 alphabet, or non-terminal "="), it MUST characters outside the BASE64 alphabet, or non-terminal "="), it MUST
reject the AUTHENTICATE command by sending a tagged BAD response. reject the AUTHENTICATE command by sending a tagged BAD response.
As with any other client response, this initial response MUST be As with any other client response, the initial response MUST be
encoded as BASE64. It also MUST be transmitted outside of a quoted encoded as BASE64. It also MUST be transmitted outside of a quoted
string or literal. To send a zero-length initial response, the string or literal. To send a zero-length initial response, the
client MUST send a single pad character ("="). This indicates that client MUST send a single pad character ("="). This indicates that
the response is present, but is a zero-length string. the response is present, but is a zero-length string.
When decoding the BASE64 data in the initial response, decoding When decoding the BASE64 data in the initial response, decoding
errors MUST be treated as in any normal SASL client response, i.e. errors MUST be treated as in any normal SASL client response, i.e.
with a tagged BAD response. In particular, the server should check with a tagged BAD response. In particular, the server should check
for any characters not explicitly allowed by the BASE64 alphabet, as for any characters not explicitly allowed by the BASE64 alphabet, as
well as any sequence of BASE64 characters that contains the pad well as any sequence of BASE64 characters that contains the pad
skipping to change at page 33, line 16 skipping to change at page 33, line 16
Example: Example:
S: * OK [CAPABILITY IMAP4rev2 STARTTLS AUTH=GSSAPI S: * OK [CAPABILITY IMAP4rev2 STARTTLS AUTH=GSSAPI
LOGINDISABLED] Server ready LOGINDISABLED] Server ready
C: A01 STARTTLS C: A01 STARTTLS
S: A01 OK STARTLS completed S: A01 OK STARTLS completed
<TLS negotiation, further commands are under [TLS] layer> <TLS negotiation, further commands are under [TLS] layer>
C: A02 CAPABILITY C: A02 CAPABILITY
S: * CAPABILITY IMAP4rev2 AUTH=GSSAPI AUTH=PLAIN S: * CAPABILITY IMAP4rev2 AUTH=GSSAPI AUTH=PLAIN
S: A02 OK CAPABILITY completed S: A02 OK CAPABILITY completed
C: A01 AUTHENTICATE PLAIN dGVzdAB0ZXN0AHRlc3Q= C: A03 AUTHENTICATE PLAIN dGVzdAB0ZXN0AHRlc3Q=
S: A001 OK Success (tls protection) S: A03 OK Success (tls protection)
Note: The line breaks within server challenges and client responses Note: The line breaks within server challenges and client responses
are for editorial clarity and are not in real authenticators. are for editorial clarity and are not in real authenticators.
6.2.3. LOGIN Command 6.2.3. LOGIN Command
Arguments: user name Arguments: user name
password password
Responses: no specific responses for this command Responses: no specific responses for this command
skipping to change at page 36, line 17 skipping to change at page 36, line 17
C: t1 CAPABILITY C: t1 CAPABILITY
S: * CAPABILITY IMAP4rev2 ID LITERAL+ X-GOOD-IDEA S: * CAPABILITY IMAP4rev2 ID LITERAL+ X-GOOD-IDEA
S: t1 OK foo S: t1 OK foo
C: t2 ENABLE CONDSTORE X-GOOD-IDEA C: t2 ENABLE CONDSTORE X-GOOD-IDEA
S: * ENABLED X-GOOD-IDEA S: * ENABLED X-GOOD-IDEA
S: t2 OK foo S: t2 OK foo
C: t3 CAPABILITY C: t3 CAPABILITY
S: * CAPABILITY IMAP4rev2 ID LITERAL+ X-GOOD-IDEA S: * CAPABILITY IMAP4rev2 ID LITERAL+ X-GOOD-IDEA
S: t3 OK foo again S: t3 OK foo again
In the following example, the client enables CONDSTORE: In the following example, the client enables CONDSTORE extension
[RFC7162]:
C: a1 ENABLE CONDSTORE C: a1 ENABLE CONDSTORE
S: * ENABLED CONDSTORE S: * ENABLED CONDSTORE
S: a1 OK Conditional Store enabled S: a1 OK Conditional Store enabled
6.3.1.1. Note to Designers of Extensions That May Use the ENABLE 6.3.1.1. Note to Designers of Extensions That May Use the ENABLE
Command Command
Designers of IMAP extensions are discouraged from creating extensions Designers of IMAP extensions are discouraged from creating extensions
that require ENABLE unless there is no good alternative design. that require ENABLE unless there is no good alternative design.
skipping to change at page 42, line 5 skipping to change at page 42, line 5
If the server decides to convert (normalize) the mailbox name, it If the server decides to convert (normalize) the mailbox name, it
SHOULD return an untagged LIST with the "\NonExistent" attribute and SHOULD return an untagged LIST with the "\NonExistent" attribute and
OLDNAME extended data item, with the OLDNAME value being the supplied OLDNAME extended data item, with the OLDNAME value being the supplied
mailbox name and the name parameter being the normalized mailbox mailbox name and the name parameter being the normalized mailbox
name. (See Section 6.3.9.7 for more details.) name. (See Section 6.3.9.7 for more details.)
Mailboxes deleted in one IMAP session MAY be announced to other IMAP Mailboxes deleted in one IMAP session MAY be announced to other IMAP
sessions using unsolicited LIST response, containing the sessions using unsolicited LIST response, containing the
"\NonExistent" attribute. "\NonExistent" attribute.
Examples: C: A682 LIST "" * Example: C: A682 LIST "" *
S: * LIST () "/" blurdybloop S: * LIST () "/" blurdybloop
S: * LIST (\Noselect) "/" foo S: * LIST (\Noselect) "/" foo
S: * LIST () "/" foo/bar S: * LIST () "/" foo/bar
S: A682 OK LIST completed S: A682 OK LIST completed
C: A683 DELETE blurdybloop C: A683 DELETE blurdybloop
S: A683 OK DELETE completed S: A683 OK DELETE completed
C: A684 DELETE foo C: A684 DELETE foo
S: A684 NO Name "foo" has inferior hierarchical names S: A684 NO Name "foo" has inferior hierarchical names
C: A685 DELETE foo/bar C: A685 DELETE foo/bar
S: A685 OK DELETE Completed S: A685 OK DELETE Completed
C: A686 LIST "" * C: A686 LIST "" *
S: * LIST (\Noselect) "/" foo S: * LIST (\Noselect) "/" foo
S: A686 OK LIST completed S: A686 OK LIST completed
C: A687 DELETE foo C: A687 DELETE foo
S: A687 OK DELETE Completed S: A687 OK DELETE Completed
C: A82 LIST "" *
Example: C: A82 LIST "" *
S: * LIST () "." blurdybloop S: * LIST () "." blurdybloop
S: * LIST () "." foo S: * LIST () "." foo
S: * LIST () "." foo.bar S: * LIST () "." foo.bar
S: A82 OK LIST completed S: A82 OK LIST completed
C: A83 DELETE blurdybloop C: A83 DELETE blurdybloop
S: A83 OK DELETE completed S: A83 OK DELETE completed
C: A84 DELETE foo C: A84 DELETE foo
S: A84 OK DELETE Completed S: A84 OK DELETE Completed
C: A85 LIST "" * C: A85 LIST "" *
S: * LIST () "." foo.bar S: * LIST () "." foo.bar
skipping to change at page 43, line 12 skipping to change at page 43, line 12
response is returned only if the mailbox has been renamed. It is an response is returned only if the mailbox has been renamed. It is an
error to attempt to rename from a mailbox name that does not exist or error to attempt to rename from a mailbox name that does not exist or
to a mailbox name that already exists. Any error in renaming will to a mailbox name that already exists. Any error in renaming will
return a tagged NO response. return a tagged NO response.
If the name has inferior hierarchical names, then the inferior If the name has inferior hierarchical names, then the inferior
hierarchical names MUST also be renamed. For example, a rename of hierarchical names MUST also be renamed. For example, a rename of
"foo" to "zap" will rename "foo/bar" (assuming "/" is the hierarchy "foo" to "zap" will rename "foo/bar" (assuming "/" is the hierarchy
delimiter character) to "zap/bar". delimiter character) to "zap/bar".
If the server's hierarchy separator character appears in the name, If the server's hierarchy separator character appears in the new
the server SHOULD create any superior hierarchical names that are mailbox name, the server SHOULD create any superior hierarchical
needed for the RENAME command to complete successfully. In other names that are needed for the RENAME command to complete
words, an attempt to rename "foo/bar/zap" to baz/rag/zowie on a successfully. In other words, an attempt to rename "foo/bar/zap" to
server in which "/" is the hierarchy separator character in the baz/rag/zowie on a server in which "/" is the hierarchy separator
corresponding namespace SHOULD create baz/ and baz/rag/ if they do character in the corresponding namespace SHOULD create baz/ and baz/
not already exist. rag/ if they do not already exist.
The value of the highest-used unique identifier of the old mailbox The value of the highest-used unique identifier of the old mailbox
name MUST be preserved so that a new mailbox created with the same name MUST be preserved so that a new mailbox created with the same
name will not reuse the identifiers of the former incarnation, unless name will not reuse the identifiers of the former incarnation, unless
the new incarnation has a different unique identifier validity value. the new incarnation has a different unique identifier validity value.
See the description of the UID command in Section 6.4.9 for more See the description of the UID command in Section 6.4.9 for more
detail. detail.
Renaming INBOX is permitted (i.e. it doesn't result in a tagged BAD Renaming INBOX is permitted (i.e. it doesn't result in a tagged BAD
response), and has special behavior. (Note that some servers response), and has special behavior. (Note that some servers
skipping to change at page 43, line 43 skipping to change at page 43, line 43
names of INBOX, these are unaffected by a rename of INBOX. names of INBOX, these are unaffected by a rename of INBOX.
If the server allows creation of mailboxes with names that are not If the server allows creation of mailboxes with names that are not
valid Net-Unicode names, the server normalizes both the existing valid Net-Unicode names, the server normalizes both the existing
mailbox name parameter and the new mailbox name parameter. If the mailbox name parameter and the new mailbox name parameter. If the
normalized version of any of these 2 parameters differs from the normalized version of any of these 2 parameters differs from the
corresponding supplied version, the server SHOULD return an untagged corresponding supplied version, the server SHOULD return an untagged
LIST response with OLDNAME extended data item, with the OLDNAME value LIST response with OLDNAME extended data item, with the OLDNAME value
being the supplied existing mailbox name and the name parameter being being the supplied existing mailbox name and the name parameter being
the normalized new mailbox name (see Section 6.3.9.7). This would the normalized new mailbox name (see Section 6.3.9.7). This would
allow the client to correlate supplied name with the normalized name. allow the client to correlate the supplied name with the normalized
name.
Mailboxes renamed in one IMAP session MAY be announced to other IMAP Mailboxes renamed in one IMAP session MAY be announced to other IMAP
sessions using unsolicited LIST response with OLDNAME extended data sessions using unsolicited LIST response with OLDNAME extended data
item. item.
In both of the above cases: if the server automatically subscribes a In both of the above cases: if the server automatically subscribes a
mailbox when it is renamed, then the unsolicited LIST response for mailbox when it is renamed, then the unsolicited LIST response for
each affected subscribed mailbox name MUST include the \Subscribed each affected subscribed mailbox name MUST include the \Subscribed
attribute. No unsolicited LIST responses need to be sent for attribute. No unsolicited LIST responses need to be sent for
children mailboxes, if any. When INBOX is successfully renamed, a children mailboxes, if any. When INBOX is successfully renamed, a
skipping to change at page 58, line 10 skipping to change at page 58, line 10
S: A03 OK done S: A03 OK done
4: In this example, we see more mailboxes that reside on another 4: In this example, we see more mailboxes that reside on another
server. This is similar to the command <RLIST "" "%">. server. This is similar to the command <RLIST "" "%">.
C: A04 LIST (REMOTE) "" "%" RETURN (CHILDREN) C: A04 LIST (REMOTE) "" "%" RETURN (CHILDREN)
S: * LIST (\Marked \NoInferiors) "/" "inbox" S: * LIST (\Marked \NoInferiors) "/" "inbox"
S: * LIST (\HasChildren) "/" "Fruit" S: * LIST (\HasChildren) "/" "Fruit"
S: * LIST (\HasNoChildren) "/" "Tofu" S: * LIST (\HasNoChildren) "/" "Tofu"
S: * LIST (\HasChildren) "/" "Vegetable" S: * LIST (\HasChildren) "/" "Vegetable"
S: * LIST (\Remote) "/" "Bread" S: * LIST (\Remote \HasNoChildren) "/" "Bread"
S: * LIST (\HasChildren \Remote) "/" "Meat" S: * LIST (\HasChildren \Remote) "/" "Meat"
S: A04 OK done S: A04 OK done
5: The following example also requests the server to include 5: The following example also requests the server to include
mailboxes that reside on another server. The server returns mailboxes that reside on another server. The server returns
information about all mailboxes that are subscribed. This is information about all mailboxes that are subscribed. This is
similar to the command <RLSUB "" "*"> (see [RFC2193] for more similar to the command <RLSUB "" "*"> (see [RFC2193] for more
details on RLSUB). We also see the use of two selection details on RLSUB). We also see the use of two selection
options. options.
skipping to change at page 71, line 21 skipping to change at page 71, line 21
immediately via an untagged EXISTS response. If the server does not immediately via an untagged EXISTS response. If the server does not
do so, the client MAY issue a NOOP command after one or more APPEND do so, the client MAY issue a NOOP command after one or more APPEND
commands. commands.
If the server decides to convert (normalize) the mailbox name, it If the server decides to convert (normalize) the mailbox name, it
SHOULD return an untagged LIST with OLDNAME extended data item, with SHOULD return an untagged LIST with OLDNAME extended data item, with
the OLDNAME value being the supplied mailbox name and the name the OLDNAME value being the supplied mailbox name and the name
parameter being the normalized mailbox name. (See Section 6.3.9.7 parameter being the normalized mailbox name. (See Section 6.3.9.7
for more details.) for more details.)
Example: C: A003 APPEND saved-messages (\Seen) {310} Example: C: A003 APPEND saved-messages (\Seen) {326}
S: + Ready for literal data S: + Ready for literal data
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar <foobar@Blurdybloop.COM> C: From: Fred Foobar <foobar@Blurdybloop.example>
C: Subject: afternoon meeting C: Subject: afternoon meeting
C: To: mooch@owatagu.siam.edu C: To: mooch@owatagu.siam.edu.example
C: Message-Id: <B27397-0100000@Blurdybloop.COM> C: Message-Id: <B27397-0100000@Blurdybloop.example>
C: MIME-Version: 1.0 C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C: C:
C: Hello Joe, do you think we can meet at 3:30 tomorrow? C: Hello Joe, do you think we can meet at 3:30 tomorrow?
C: C:
S: A003 OK APPEND completed S: A003 OK APPEND completed
Example: C: A003 APPEND saved-messages (\Seen) {297} Example: C: A003 APPEND saved-messages (\Seen) {297+}
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar <foobar@example.com> C: From: Fred Foobar <foobar@example.com>
C: Subject: afternoon meeting C: Subject: afternoon meeting
C: To: mooch@example.com C: To: mooch@example.com
C: Message-Id: <B27397-0100000@example.com> C: Message-Id: <B27397-0100000@example.com>
C: MIME-Version: 1.0 C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C: C:
C: Hello Joe, do you think we can meet at 3:30 tomorrow? C: Hello Joe, do you think we can meet at 3:30 tomorrow?
C: C:
skipping to change at page 78, line 24 skipping to change at page 78, line 24
how it is affected by other commands executed, and how SAVE how it is affected by other commands executed, and how SAVE
return option interacts with other return options. return option interacts with other return options.
In absence of any other SEARCH result option, the SAVE result In absence of any other SEARCH result option, the SAVE result
option also suppresses any ESEARCH response that would have option also suppresses any ESEARCH response that would have
been otherwise returned by the SEARCH command. been otherwise returned by the SEARCH command.
Note: future extensions to this document can allow servers to return Note: future extensions to this document can allow servers to return
multiple ESEARCH responses for a single extended SEARCH command. multiple ESEARCH responses for a single extended SEARCH command.
However all options specified above MUST result in a single ESEARCH However all options specified above MUST result in a single ESEARCH
response if used by themselves or in combination. This guaranty response if used by themselves or in combination. This guarantee
simplifies processing in IMAP4rev2 clients. Future SEARCH extensions simplifies processing in IMAP4rev2 clients. Future SEARCH extensions
that relax this restriction will have to describe how results from that relax this restriction will have to describe how results from
multiple ESEARCH responses are to be combined. multiple ESEARCH responses are to be combined.
Searching criteria consist of one or more search keys. Searching criteria consist of one or more search keys.
When multiple keys are specified, the result is the intersection (AND When multiple keys are specified, the result is the intersection (AND
function) of all the messages that match those keys. For example, function) of all the messages that match those keys. For example,
the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers to all the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers to all
deleted messages from Smith with INTERNALDATE greater than February deleted messages from Smith with INTERNALDATE greater than February
skipping to change at page 78, line 49 skipping to change at page 78, line 49
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] [CHARSET-REG]. It indicates the followed by a registered [CHARSET] [CHARSET-REG]. It indicates the
[CHARSET] of the strings that appear in the search criteria. [CHARSET] of the strings that appear in the search criteria.
[MIME-IMB] content transfer encodings, and [MIME-HDRS] strings in [MIME-IMB] content transfer encodings, and [MIME-HDRS] strings in
[RFC-5322]/[MIME-IMB] headers, MUST be decoded before comparing text. [RFC-5322]/[MIME-IMB] headers, MUST be decoded before comparing text.
Servers MUST support US-ASCII and UTF-8 charsets; other [CHARSET]s Servers MUST support US-ASCII and UTF-8 charsets; other [CHARSET]s
MAY be supported. Clients SHOULD use UTF-8. Note that if "CHARSET" MAY be supported. Clients SHOULD use UTF-8. Note that if "CHARSET"
is not provided IMAP4rev2 server MUST assume UTF-8, so selecting is not provided IMAP4rev2 servers MUST assume UTF-8, so selecting
CHARSET UTF-8 is redundant. It is permitted for improved CHARSET UTF-8 is redundant. It is permitted for improved
compatibility with existing IMAP4rev1 clients. compatibility with existing IMAP4rev1 clients.
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 and unless specified otherwise, a In all search keys that use strings and unless specified otherwise, a
message matches the key if the string is a substring of the message matches the key if the string is a substring of the
skipping to change at page 86, line 9 skipping to change at page 86, line 9
C: A301 UID SEARCH $ SMALLER 4096 C: A301 UID SEARCH $ SMALLER 4096
and the result of the command would be the same. and the result of the command would be the same.
3) The following example shows that the "$" marker can be combined 3) The following example shows that the "$" marker can be combined
with other message numbers using the OR SEARCH criterion. with other message numbers using the OR SEARCH criterion.
Example 4: Example 4:
C: P282 SEARCH RETURN (SAVE) SINCE 1-Feb-1994 C: P282 SEARCH RETURN (SAVE) SINCE 1-Feb-1994
NOT FROM "Smith" NOT FROM "Smith"
S: P282 OK SEARCH completed S: P282 OK SEARCH completed
C: P283 SEARCH CHARSET UTF-8 (OR $ 1,3000:3021) TEXT {8} C: P283 SEARCH CHARSET UTF-8 (OR $ 1,3000:3021) TEXT {8+}
C: YYYYYYYY C: YYYYYYYY
S: * ESEARCH (TAG "P283") ALL 882,1102,3003,3005:3006 S: * ESEARCH (TAG "P283") ALL 882,1102,3003,3005:3006
S: P283 OK completed S: P283 OK completed
Note: Since this document format is restricted to 7-bit ASCII text, Note: Since this document format is restricted to 7-bit ASCII text,
it is not possible to show actual UTF-8 data. The "YYYYYYYY" is a it is not possible to show actual UTF-8 data. The "YYYYYYYY" is a
placeholder for what would be 8 octets of 8-bit data in an actual placeholder for what would be 8 octets of 8-bit data in an actual
transaction. transaction.
4) The following example demonstrates that a failed SEARCH sets the 4) The following example demonstrates that a failed SEARCH sets the
skipping to change at page 99, line 15 skipping to change at page 99, line 15
Example: C: A999 UID FETCH 4827313:4828442 FLAGS Example: C: A999 UID FETCH 4827313:4828442 FLAGS
S: * 23 FETCH (FLAGS (\Seen) UID 4827313) S: * 23 FETCH (FLAGS (\Seen) UID 4827313)
S: * 24 FETCH (FLAGS (\Seen) UID 4827943) S: * 24 FETCH (FLAGS (\Seen) UID 4827943)
S: * 25 FETCH (FLAGS (\Seen) UID 4828442) S: * 25 FETCH (FLAGS (\Seen) UID 4828442)
S: A999 OK UID FETCH completed S: A999 OK UID FETCH completed
6.5. Client Commands - Experimental/Expansion 6.5. Client Commands - Experimental/Expansion
Each command which is not part of this specification MUST have at Each command which is not part of this specification MUST have at
least one capability name (see Section 6.1.1) associated with it. least one capability name (see Section 6.1.1) associated with it.
(Multiple commands can be associated with the same capability name) (Multiple commands can be associated with the same capability name.)
Server implementations MUST NOT send any added (not specified in this Server implementations MUST NOT send any added (not specified in this
specification) untagged responses, unless the client requested it by specification) untagged responses, unless the client requested it by
issuing the associated experimental command or the ENABLE command issuing the associated experimental command (specified in an
(Section 6.3.1). extension document) or the ENABLE command (Section 6.3.1).
The following example demonstrates how a client can check for The following example demonstrates how a client can check for
presence of a fictitious XPIG-LATIN capability that adds the XPIG- presence of a fictitious XPIG-LATIN capability that adds the XPIG-
LATIN command and the the XPIG-LATIN untagged response. (Note that LATIN command and the the XPIG-LATIN untagged response. (Note that
for an extension the command name and the capability name don't have for an extension the command name and the capability name don't have
to be the same.) to be the same.)
Example: C: a441 CAPABILITY Example: C: a441 CAPABILITY
S: * CAPABILITY IMAP4rev2 XPIG-LATIN S: * CAPABILITY IMAP4rev2 XPIG-LATIN
S: a441 OK CAPABILITY completed S: a441 OK CAPABILITY completed
skipping to change at page 103, line 13 skipping to change at page 103, line 13
C: l create "///////" C: l create "///////"
S: l NO [CANNOT] Adjacent slashes are not supported S: l NO [CANNOT] Adjacent slashes are not supported
CAPABILITY CAPABILITY
Followed by a list of capabilities. This can appear in the Followed by a list of capabilities. This can appear in the
initial OK or PREAUTH response to transmit an initial initial OK or PREAUTH response to transmit an initial
capabilities list. It can also appear in tagged responses to capabilities list. It can also appear in tagged responses to
LOGIN or AUTHENTICATE commands. This makes it unnecessary for LOGIN or AUTHENTICATE commands. This makes it unnecessary for
a client to send a separate CAPABILITY command if it recognizes a client to send a separate CAPABILITY command if it recognizes
this response. this response code and there was no change to the TLS and/or
authentication state since it was received.
CLIENTBUG CLIENTBUG
The server has detected a client bug. This can accompany all The server has detected a client bug. This can accompany all
of OK, NO, and BAD, depending on what the client bug is. of OK, NO, and BAD, depending on what the client bug is.
C: k1 select "/archive/projects/experiment-iv" C: k1 select "/archive/projects/experiment-iv"
[...] [...]
S: k1 OK [READ-ONLY] Done S: k1 OK [READ-ONLY] Done
C: k2 status "/archive/projects/experiment-iv" (messages) C: k2 status "/archive/projects/experiment-iv" (messages)
skipping to change at page 104, line 4 skipping to change at page 104, line 6
CONTACTADMIN CONTACTADMIN
The user should contact the system administrator or support The user should contact the system administrator or support
desk. desk.
C: e login "fred" "foo" C: e login "fred" "foo"
S: e NO [CONTACTADMIN] S: e NO [CONTACTADMIN]
COPYUID COPYUID
Followed by the UIDVALIDITY of the destination mailbox, a UID Followed by the UIDVALIDITY of the destination mailbox, a UID
set containing the UIDs of the message(s) in the source mailbox set containing the UIDs of the message(s) in the source mailbox
that were copied to the destination mailbox and containing the that were copied to the destination mailbox, followed by
UIDs assigned to the copied message(s) in the destination another UID set containing the UIDs assigned to the copied
mailbox, indicates that the message(s) have been copied to the message(s) in the destination mailbox, indicates that the
destination mailbox with the stated UID(s). message(s) have been copied to the destination mailbox with the
stated UID(s).
The source UID set is in the order the message(s) were copied; The source UID set is in the order the message(s) were copied;
the destination UID set corresponds to the source UID set and the destination UID set corresponds to the source UID set and
is in the same order. Neither of the UID sets may contain is in the same order. Neither of the UID sets may contain
extraneous UIDs or the symbol "*". extraneous UIDs or the symbol "*".
UIDs are assigned in strictly ascending order in the mailbox UIDs are assigned in strictly ascending order in the mailbox
(refer to Section 2.3.1.1); note that a range of 12:10 is (refer to Section 2.3.1.1); note that a range of 12:10 is
exactly equivalent to 10:12 and refers to the sequence exactly equivalent to 10:12 and refers to the sequence
10,11,12. 10,11,12.
skipping to change at page 104, line 46 skipping to change at page 105, line 4
Either authentication succeeded or the server no longer had the Either authentication succeeded or the server no longer had the
necessary data; either way, access is no longer permitted using necessary data; either way, access is no longer permitted using
that passphrase. The client or user should get a new that passphrase. The client or user should get a new
passphrase. passphrase.
C: d login "fred" "foo" C: d login "fred" "foo"
S: d NO [EXPIRED] That password isn't valid any more S: d NO [EXPIRED] That password isn't valid any more
EXPUNGEISSUED EXPUNGEISSUED
Someone else has issued an EXPUNGE for the same mailbox. The Someone else has issued an EXPUNGE for the same mailbox. The
client may want to issue NOOP soon. [IMAP-MULTIACCESS] client may want to issue NOOP soon. [IMAP-MULTIACCESS]
discusses this subject in depth. discusses this subject in depth.
C: h search from fred@example.com C: h search from maria@example.com
S: * ESEARCH (TAG "h") ALL 1:3,5,8,13,21,42 S: * ESEARCH (TAG "h") ALL 1:3,5,8,13,21,42
S: h OK [EXPUNGEISSUED] Search completed S: h OK [EXPUNGEISSUED] Search completed
HASCHILDREN HASCHILDREN
The mailbox delete operation failed because the mailbox has one The mailbox delete operation failed because the mailbox has one
or more children and the server doesn't allow deletion of or more children and the server doesn't allow deletion of
mailboxes with children. mailboxes with children.
C: m356 DELETE Notes C: m356 DELETE Notes
skipping to change at page 105, line 50 skipping to change at page 106, line 8
The operation attempts to delete something that does not exist. The operation attempts to delete something that does not exist.
Similar to ALREADYEXISTS. Similar to ALREADYEXISTS.
C: p RENAME this that C: p RENAME this that
S: p NO [NONEXISTENT] No such mailbox S: p NO [NONEXISTENT] No such mailbox
NOPERM NOPERM
The access control system (e.g., Access Control List (ACL), see The access control system (e.g., Access Control List (ACL), see
[RFC4314] does not permit this user to carry out an operation, [RFC4314]) does not permit this user to carry out an operation,
such as selecting or creating a mailbox. such as selecting or creating a mailbox.
C: f select "/archive/projects/experiment-iv" C: f select "/archive/projects/experiment-iv"
S: f NO [NOPERM] Access denied S: f NO [NOPERM] Access denied
OVERQUOTA OVERQUOTA
The user would be over quota after the operation. (The user The user would be over quota after the operation. (The user
may or may not be over quota already.) may or may not be over quota already.)
skipping to change at page 111, line 12 skipping to change at page 111, line 27
(the other three cases) is that the connection closes immediately in (the other three cases) is that the connection closes immediately in
the failure case. In all cases the client SHOULD continue to read the failure case. In all cases the client SHOULD continue to read
response data from the server until the connection is closed; this response data from the server until the connection is closed; this
will ensure that any pending untagged or completion responses are will ensure that any pending untagged or completion responses are
read and processed. read and processed.
Example: S: * BYE Autologout; idle for too long Example: S: * BYE Autologout; idle for too long
7.2. Server Responses - Server Status 7.2. Server Responses - Server Status
These responses are always untagged. This is how server and mailbox These responses are always untagged. This is how server status data
status data are transmitted from the server to the client. are transmitted from the server to the client.
7.2.1. ENABLED Response 7.2.1. ENABLED Response
Contents: capability listing Contents: capability listing
The ENABLED response occurs as a result of an ENABLE command. The The ENABLED response occurs as a result of an ENABLE command. The
capability listing contains a space-separated listing of capability capability listing contains a space-separated listing of capability
names that the server supports and that were successfully enabled. names that the server supports and that were successfully enabled.
The ENABLED response may contain no capabilities, which means that no The ENABLED response may contain no capabilities, which means that no
extensions listed by the client were successfully enabled. extensions listed by the client were successfully enabled.
skipping to change at page 112, line 6 skipping to change at page 112, line 20
A capability name which begins with "AUTH=" indicates that the server A capability name which begins with "AUTH=" indicates that the server
supports that particular authentication mechanism [SASL]. supports that particular authentication mechanism [SASL].
The LOGINDISABLED capability indicates that the LOGIN command is The LOGINDISABLED capability indicates that the LOGIN command is
disabled, and that the server will respond with a tagged NO response disabled, and that the server will respond with a tagged NO response
to any attempt to use the LOGIN command even if the user name and to any attempt to use the LOGIN command even if the user name and
password are valid. An IMAP client MUST NOT issue the LOGIN command password are valid. An IMAP client MUST NOT issue the LOGIN command
if the server advertises the LOGINDISABLED capability. if the server advertises the LOGINDISABLED capability.
Other capability names indicate that the server supports an Other capability names indicate that the server supports an
extension, revision, or amendment to the IMAP4rev2 protocol. Server extension, revision, or amendment to the IMAP4rev2 protocol. If
responses MUST conform to this document until the client issues a IMAP4rev1 capability is not advertised, server responses MUST conform
command that uses the associated capability. to this document until the client issues a command that uses the
associated capability. If both IMAP4rev1 and IMAP4rev2 capabilities
are advertised, server responses MUST conform to RFC 3501 until the
client issues a command that uses the associated capability. (For
example, the client can issue ENABLE IMAP4rev2 to enable IMAP4rev2
specific behaviour).
Capability names SHOULD be registered with IANA using RFC Required Capability names SHOULD be registered with IANA using RFC Required
policy. A server SHOULD NOT offer unregistered capability names. policy. A server SHOULD NOT offer unregistered capability names.
Client implementations SHOULD NOT require any capability name other Client implementations SHOULD NOT require any capability name other
than "IMAP4rev2", and possibly "STARTTLS" and "LOGINDISABLED" (on a than "IMAP4rev2", and possibly "STARTTLS" and "LOGINDISABLED" (on a
non implicit TLS port). Client implementations MUST ignore any non implicit TLS port). Client implementations MUST ignore any
unknown capability names. unknown capability names.
A server MAY send capabilities automatically, by using the CAPABILITY A server MAY send capabilities automatically, by using the CAPABILITY
response code in the initial PREAUTH or OK responses, and by sending response code in the initial PREAUTH or OK responses, and by sending
an updated CAPABILITY response code in the tagged OK response as part an updated CAPABILITY response code in the tagged OK response as part
of a successful authentication. It is unnecessary for a client to of a successful authentication. It is unnecessary for a client to
send a separate CAPABILITY command if it recognizes these automatic send a separate CAPABILITY command if it recognizes these automatic
capabilities. capabilities and there was no change to the TLS and/or authentication
state since they were received.
The list of capabilities returned by a server MAY change during the The list of capabilities returned by a server MAY change during the
connection. In particular, it is quite common for the server to connection. In particular, it is quite common for the server to
change list of capabilities after successful TLS negotiation change list of capabilities after successful TLS negotiation
(STARTTLS command) and/or after successful authentication (STARTTLS command) and/or after successful authentication
(AUTHENTICATE or LOGIN commands). (AUTHENTICATE or LOGIN commands).
Example: S: * CAPABILITY STARTTLS AUTH=GSSAPI IMAP4rev2 LOGINDISABLED Example: S: * CAPABILITY STARTTLS AUTH=GSSAPI IMAP4rev2 LOGINDISABLED
XPIG-LATIN XPIG-LATIN
Note that in the above example XPIG-LATIN is a fictitious capability Note that in the above example XPIG-LATIN is a fictitious capability
name. name.
7.3. Server Responses - Mailbox Status 7.3. Server Responses - Mailbox Status
These responses are always untagged. This is how server and mailbox These responses are always untagged. This is how mailbox status data
status data are transmitted from the server to the client. Many of are transmitted from the server to the client. Many of these
these responses typically result from a command with the same name. responses typically result from a command with the same name.
7.3.1. LIST Response 7.3.1. LIST Response
Contents: name attributes Contents: name attributes
hierarchy delimiter hierarchy delimiter
name name
OPTIONAL extension data OPTIONAL extension data
The LIST response occurs as a result of a LIST command. It returns a The LIST response occurs as a result of a LIST command. It returns a
single name that matches the LIST specification. There can be single name that matches the LIST specification. There can be
skipping to change at page 117, line 38 skipping to change at page 118, line 11
The search correlator is followed by an optional UID indicator. If The search correlator is followed by an optional UID indicator. If
this indicator is present, all data in the ESEARCH response refers to this indicator is present, all data in the ESEARCH response refers to
UIDs, otherwise all returned data refers to message numbers. UIDs, otherwise all returned data refers to message numbers.
The rest of the ESEARCH response contains one or more search data The rest of the ESEARCH response contains one or more search data
pairs. Each pair starts with unique return item name, followed by a pairs. Each pair starts with unique return item name, followed by a
space and the corresponding data. Search data pairs may be returned space and the corresponding data. Search data pairs may be returned
in any order. Unless specified otherwise by an extension, any return in any order. Unless specified otherwise by an extension, any return
item name SHOULD appear only once in an ESEARCH response. item name SHOULD appear only once in an ESEARCH response.
[[TBD: describe the most common search data pairs returned.]] This document specifies the following return item names:
MIN
Returns the lowest message number/UID that satisfies the SEARCH
criteria.
If the SEARCH results in no matches, the server MUST NOT
include the MIN return item in the ESEARCH response; however,
it still MUST send the ESEARCH response.
MAX
Returns the highest message number/UID that satisfies the
SEARCH criteria.
If the SEARCH results in no matches, the server MUST NOT
include the MAX return item in the ESEARCH response; however,
it still MUST send the ESEARCH response.
ALL
Returns all message numbers/UIDs that satisfy the SEARCH
criteria using the sequence-set syntax. Note, the client MUST
NOT assume that messages/UIDs will be listed in any particular
order.
If the SEARCH results in no matches, the server MUST NOT
include the ALL return item in the ESEARCH response; however,
it still MUST send the ESEARCH response.
COUNT Returns the number of messages that satisfy the SEARCH
criteria. This return item MUST always be included in the ESEARCH
response.
Example: S: * ESEARCH UID COUNT 5 ALL 4:19,21,28 Example: S: * ESEARCH UID COUNT 5 ALL 4:19,21,28
Example: S: * ESEARCH (TAG "a567") UID COUNT 5 ALL 4:19,21,28 Example: S: * ESEARCH (TAG "a567") UID COUNT 5 ALL 4:19,21,28
Example: S: * ESEARCH COUNT 5 ALL 1:17,21 Example: S: * ESEARCH COUNT 5 ALL 1:17,21
7.3.5. FLAGS Response 7.3.5. FLAGS Response
Contents: flag parenthesized list Contents: flag parenthesized list
skipping to change at page 124, line 14 skipping to change at page 125, line 25
The fields of the envelope structure are in the following The fields of the envelope structure are in the following
order: date, subject, from, sender, reply-to, to, cc, bcc, in- order: date, subject, from, sender, reply-to, to, cc, bcc, in-
reply-to, and message-id. The date, subject, in-reply-to, and reply-to, and message-id. The date, subject, in-reply-to, and
message-id fields are strings. The from, sender, reply-to, to, message-id fields are strings. The from, sender, reply-to, to,
cc, and bcc fields are parenthesized lists of address cc, and bcc fields are parenthesized lists of address
structures. structures.
An address structure is a parenthesized list that describes an An address structure is a parenthesized list that describes an
electronic mail address. The fields of an address structure electronic mail address. The fields of an address structure
are in the following order: personal name, [SMTP] at-domain- are in the following order: display name, [SMTP] at-domain-list
list (source route, obs-route), mailbox name, and host name. (source route, obs-route ABNF production from [RFC-5322]),
mailbox name (local-part ABNF production from [RFC-5322]), and
host name.
[RFC-5322] group syntax is indicated by a special form of [RFC-5322] group syntax is indicated by a special form of
address structure in which the host name field is NIL. If the address structure in which the host name field is NIL. If the
mailbox name field is also NIL, this is an end of group marker mailbox name field is also NIL, this is an end of group marker
(semi-colon in RFC 822 syntax). If the mailbox name field is (semi-colon in RFC 822 syntax). If the mailbox name field is
non-NIL, this is a start of group marker, and the mailbox name non-NIL, this is a start of group marker, and the mailbox name
field holds the group name phrase. field holds the group name phrase.
If the Date, Subject, In-Reply-To, and Message-ID header fields If the Date, Subject, In-Reply-To, and Message-ID header fields
are absent in the [RFC-5322] header, the corresponding member are absent in the [RFC-5322] header, the corresponding member
skipping to change at page 125, line 26 skipping to change at page 126, line 40
INTERNALDATE A string representing the internal date of the message. INTERNALDATE A string representing the internal date of the message.
RFC822.SIZE A number expressing the [RFC-5322] size of the message. RFC822.SIZE A number expressing the [RFC-5322] size of the message.
UID A number expressing the unique identifier of the message. UID A number expressing the unique identifier of the message.
If the server chooses to send unsolicited FETCH responses, they MUST If the server chooses to send unsolicited FETCH responses, they MUST
include UID FETCH item. Note that this is a new requirement when include UID FETCH item. Note that this is a new requirement when
compared to RFC 3501. compared to RFC 3501.
Example: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827) Example: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827 UID 447)
7.6. Server Responses - Command Continuation Request 7.6. 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
skipping to change at page 130, line 32 skipping to change at page 131, line 40
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
capability = ("AUTH=" auth-type) / atom capability = ("AUTH=" auth-type) / atom
; New capabilities MUST begin with "X" or be ; New capabilities SHOULD be
; registered with IANA in ; registered with IANA using
; RFC Required policy, i.e. in
; a standards-track, an experimental ; a standards-track, an experimental
; or an informational RFC. ; or an informational RFC.
capability-data = "CAPABILITY" *(SP capability) SP "IMAP4rev2" capability-data = "CAPABILITY" *(SP capability) SP "IMAP4rev2"
*(SP capability) *(SP capability)
; Servers MUST implement the STARTTLS, AUTH=PLAIN, ; Servers MUST implement the STARTTLS, AUTH=PLAIN,
; and LOGINDISABLED capabilities. ; and LOGINDISABLED capabilities.
; Servers which offer RFC 1730 compatibility MUST ; Servers which offer RFC 1730 compatibility MUST
; list "IMAP4" as the first capability. ; list "IMAP4" as the first capability.
; Servers which offer RFC 3501 compatibility MUST ; Servers which offer RFC 3501 compatibility MUST
; list "IMAP4rev1" as one of capabilities. ; list "IMAP4rev1" as one of capabilities.
CHAR = <defined in [ABNF]> CHAR = <defined in [ABNF]>
CHAR8 = %x01-ff CHAR8 = %x01-ff
; any OCTET except NUL, %x00 ; any OCTET except NUL, %x00
charset = atom / quoted charset = atom / quoted
childinfo-extended-item = "CHILDINFO" SP "(" childinfo-extended-item = "CHILDINFO" SP "("
list-select-base-opt-quoted list-select-base-opt-quoted
*(SP list-select-base-opt-quoted) ")" *(SP list-select-base-opt-quoted) ")"
; Extended data item (mbox-list-extended-item) ; Extended data item (mbox-list-extended-item)
; returned when the RECURSIVEMATCH ; returned when the RECURSIVEMATCH
; selection option is specified. ; selection option is specified.
; Note 1: the CHILDINFO extended data item tag can be ; Note 1: the CHILDINFO extended data item tag can be
; returned with and without surrounding quotes, as per ; returned with and without surrounding quotes, as per
; mbox-list-extended-item-tag production. ; mbox-list-extended-item-tag production.
; Note 2: The selection options are always returned ; Note 2: The selection options are always returned
skipping to change at page 131, line 25 skipping to change at page 132, line 36
; the extended LIST command. ; the extended LIST command.
child-mbox-flag = "\HasChildren" / "\HasNoChildren" child-mbox-flag = "\HasChildren" / "\HasNoChildren"
; attributes for CHILDREN return option, at most one ; attributes for CHILDREN return option, at most one
; possible per LIST response ; possible per LIST response
command = tag SP (command-any / command-auth / command-nonauth / command = tag SP (command-any / command-auth / command-nonauth /
command-select) CRLF command-select) CRLF
; Modal based on state ; Modal based on state
command-any = "CAPABILITY" / "LOGOUT" / "NOOP" / x-command command-any = "CAPABILITY" / "LOGOUT" / "NOOP"
; Valid in all states ; Valid in all states
command-auth = append / create / delete / enable / examine / list / command-auth = append / create / delete / enable / examine / list /
Namespace-Command / Namespace-Command /
rename / select / status / subscribe / unsubscribe / rename / select / status / subscribe / unsubscribe /
idle idle
; Valid only in Authenticated or Selected state ; Valid only in Authenticated or Selected state
command-nonauth = login / authenticate / "STARTTLS" command-nonauth = login / authenticate / "STARTTLS"
; Valid only when in Not Authenticated state ; Valid only when in Not Authenticated state
skipping to change at page 134, line 4 skipping to change at page 135, line 15
flag-fetch = flag flag-fetch = flag
flag-keyword = "$MDNSent" / "$Forwarded" / "$Junk" / flag-keyword = "$MDNSent" / "$Forwarded" / "$Junk" /
"$NotJunk" / "$Phishing" / atom "$NotJunk" / "$Phishing" / atom
flag-list = "(" [flag *(SP flag)] ")" flag-list = "(" [flag *(SP flag)] ")"
flag-perm = flag / "\*" flag-perm = flag / "\*"
greeting = "*" SP (resp-cond-auth / resp-cond-bye) CRLF greeting = "*" SP (resp-cond-auth / resp-cond-bye) CRLF
header-fld-name = astring header-fld-name = astring
header-list = "(" header-fld-name *(SP header-fld-name) ")" header-list = "(" header-fld-name *(SP header-fld-name) ")"
idle = "IDLE" CRLF "DONE" idle = "IDLE" CRLF "DONE"
initial-resp = (base64 / "=") initial-resp = (base64 / "=")
; "initial response" defined in ; "initial response" defined in
; Section 5.1 of [RFC4422] ; Section 5.1 of [RFC4422]
list = "LIST" [SP list-select-opts] SP mailbox SP mbox-or-pat list = "LIST" [SP list-select-opts] SP mailbox SP mbox-or-pat
[SP list-return-opts] [SP list-return-opts]
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-return-opt = return-option
; Note that return-option is the ABNF
; non terminal used by RFC 5258
list-return-opts = "RETURN" SP list-return-opts = "RETURN" SP
"(" [return-option *(SP return-option)] ")" "(" [list-return-opt *(SP list-return-opt)] ")"
; list return options, e.g., CHILDREN ; list return options, e.g., CHILDREN
list-select-base-opt = "SUBSCRIBED" / option-extension list-select-base-opt = "SUBSCRIBED" / option-extension
; options that can be used by themselves ; options that can be used by themselves
list-select-base-opt-quoted = DQUOTE list-select-base-opt DQUOTE list-select-base-opt-quoted = DQUOTE list-select-base-opt DQUOTE
list-select-independent-opt = "REMOTE" / option-extension list-select-independent-opt = "REMOTE" / option-extension
; options that do not syntactically interact with ; options that do not syntactically interact with
; other options ; other options
skipping to change at page 136, line 32 skipping to change at page 137, line 46
"\Subscribed" / "\Remote" / flag-extension "\Subscribed" / "\Remote" / flag-extension
; Other flags; multiple possible per LIST response ; Other flags; multiple possible per LIST response
mbx-list-sflag = "\NonExistent" / "\Noselect" / "\Marked" / "\Unmarked" mbx-list-sflag = "\NonExistent" / "\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" /
"FONT" / "MESSAGE" / "MODEL" / "VIDEO" ) DQUOTE) "FONT" / "MESSAGE" / "MODEL" / "VIDEO" ) DQUOTE)
/ string) / string)
SP media-subtype SP media-subtype
; Defined in [MIME-IMT].
; FONT defined in RFC 8081. ; FONT defined in RFC 8081.
; MODEL defined in RFC 2077.
; Other top level media types
; are defined in [MIME-IMT].
media-message = DQUOTE "MESSAGE" DQUOTE SP media-message = DQUOTE "MESSAGE" DQUOTE SP
DQUOTE ("RFC822" / "GLOBAL") DQUOTE 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]
skipping to change at page 140, line 4 skipping to change at page 141, line 21
resp-specials = "]" resp-specials = "]"
resp-text = ["[" resp-text-code "]" SP] [text] resp-text = ["[" resp-text-code "]" SP] [text]
resp-text-code = "ALERT" / resp-text-code = "ALERT" /
"BADCHARSET" [SP "(" charset *(SP charset) ")" ] / "BADCHARSET" [SP "(" charset *(SP charset) ")" ] /
capability-data / "PARSE" / capability-data / "PARSE" /
"PERMANENTFLAGS" SP "PERMANENTFLAGS" SP
"(" [flag-perm *(SP flag-perm)] ")" / "(" [flag-perm *(SP flag-perm)] ")" /
"READ-ONLY" / "READ-WRITE" / "TRYCREATE" / "READ-ONLY" / "READ-WRITE" / "TRYCREATE" /
"UIDNEXT" SP nz-number / "UIDVALIDITY" SP nz-number / "UIDNEXT" SP nz-number / "UIDVALIDITY" SP nz-number /
resp-code-apnd / resp-code-copy / "UIDNOTSTICKY" / resp-code-apnd / resp-code-copy / "UIDNOTSTICKY" /
"UNAVAILABLE" / "AUTHENTICATIONFAILED" / "UNAVAILABLE" / "AUTHENTICATIONFAILED" /
"AUTHORIZATIONFAILED" / "EXPIRED" / "AUTHORIZATIONFAILED" / "EXPIRED" /
"PRIVACYREQUIRED" / "CONTACTADMIN" / "NOPERM" / "PRIVACYREQUIRED" / "CONTACTADMIN" / "NOPERM" /
"INUSE" / "EXPUNGEISSUED" / "CORRUPTION" / "INUSE" / "EXPUNGEISSUED" / "CORRUPTION" /
"SERVERBUG" / "CLIENTBUG" / "CANNOT" / "SERVERBUG" / "CLIENTBUG" / "CANNOT" /
"LIMIT" / "OVERQUOTA" / "ALREADYEXISTS" / "LIMIT" / "OVERQUOTA" / "ALREADYEXISTS" /
"NONEXISTENT" / "NOTSAVED" / "HASCHILDREN" / "NONEXISTENT" / "NOTSAVED" / "HASCHILDREN" /
"CLOSED" / "CLOSED" /
"UNKNOWN-CTE" / "UNKNOWN-CTE" /
atom [SP 1*<any TEXT-CHAR except "]">] atom [SP 1*<any TEXT-CHAR except "]">]
return-option = "SUBSCRIBED" / "CHILDREN" / status-option / return-option = "SUBSCRIBED" / "CHILDREN" / status-option /
option-extension option-extension
search = "SEARCH" [search-return-opts] search = "SEARCH" [search-return-opts]
SP search-program SP search-program
search-correlator = SP "(" "TAG" SP tag-string ")" search-correlator = SP "(" "TAG" SP tag-string ")"
search-key = "ALL" / "ANSWERED" / "BCC" SP astring / search-key = "ALL" / "ANSWERED" / "BCC" SP astring /
"BEFORE" SP date / "BODY" SP astring / "BEFORE" SP date / "BODY" SP astring /
"CC" SP astring / "DELETED" / "FLAGGED" / "CC" SP astring / "DELETED" / "FLAGGED" /
skipping to change at page 145, line 4 skipping to change at page 146, line 20
; 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-CHAR = <Defined in Section 4 of RFC 3629> UTF8-CHAR = <Defined in Section 4 of RFC 3629>
UTF8-2 = <Defined in Section 4 of RFC 3629> UTF8-2 = <Defined in Section 4 of RFC 3629>
UTF8-3 = <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> UTF8-4 = <Defined in Section 4 of RFC 3629>
vendor-token = "vendor." name-component vendor-token = "vendor." name-component
; Definition copied from RFC 2244. ; Definition copied from RFC 2244.
; MUST be registered with IANA ; MUST be registered with IANA
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".
10. Author's Note 10. Author's Note
skipping to change at page 147, line 14 skipping to change at page 148, line 29
See Section 7.1.4 for special security considerations related to See Section 7.1.4 for special security considerations related to
PREAUTH response. PREAUTH response.
Many server responses and response codes are only meaningful in Many server responses and response codes are only meaningful in
authenticated or even selected state. However, nothing prevents a authenticated or even selected state. However, nothing prevents a
server (or an on-path attacker) from sending such invalid server (or an on-path attacker) from sending such invalid
responses in cleartext before STARTTLS/AUTHENTICATE commands are responses in cleartext before STARTTLS/AUTHENTICATE commands are
issued. Before authentication clients SHOULD ignore any responses issued. Before authentication clients SHOULD ignore any responses
other than CAPABILITY and server status responses (Section 7.1), other than CAPABILITY and server status responses (Section 7.1),
as well as any response codes other than CAPABILITY. Client as well as any response codes other than CAPABILITY. (In
SHOULD ignore the ALERT response code until after TLS has been particular, some email clients are known to incorrectly process
successfully negotiated (whether using STARTTLS or TLS negotiation LIST responses received before authentication.) Clients SHOULD
on implicit TLS port). Unless explicitly allowed by an IMAP ignore the ALERT response code until after TLS (whether using
extension, when not in selected state clients MUST ignore STARTTLS or TLS negotiation on implicit TLS port) or SASL security
responses/response codes related to message and mailbox status layer with confidentiality protection has been successfully
such as FLAGS, EXIST, EXPUNGE and FETCH. negotiated. Unless explicitly allowed by an IMAP extension, when
not in selected state clients MUST ignore responses/response codes
related to message and mailbox status such as FLAGS, EXIST,
EXPUNGE and FETCH.
11.4. COPYUID and APPENDUID response codes 11.4. 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 33 skipping to change at page 150, line 7
correct. correct.
A server error message for a failing LOGIN command SHOULD NOT specify A server error message for a failing LOGIN command SHOULD NOT specify
that the user name, as opposed to the password, is invalid. that the user name, as opposed to the password, is invalid.
A server SHOULD have mechanisms in place to limit or delay failed A server SHOULD have mechanisms in place to limit or delay failed
AUTHENTICATE/LOGIN attempts. AUTHENTICATE/LOGIN attempts.
A server SHOULD report any authentication failure and analyze such A server SHOULD report any authentication failure and analyze such
authentication failure attempt with regard to a password brute force authentication failure attempt with regard to a password brute force
attack as well as a password spraying attack. Accounts that match attack as well as a password spraying attack. Accounts with
password spraying attacks MUST be blocked and request to change their passwords that match well known passwords from spraying attacks MUST
passwords and only password with significant strength SHOULD be be blocked and users associated with such accounts must be requested
accepted. to change their passwords. Only password with significant strength
SHOULD be accepted.
Additional security considerations are discussed in the section Additional security considerations are discussed in the section
discussing the AUTHENTICATE (see Section 6.2.2) and LOGIN (see discussing the AUTHENTICATE (see Section 6.2.2) and LOGIN (see
Section 6.2.3) commands. Section 6.2.3) commands.
Note that the BODYSTRUCTURE FETCH data item can contain an MD5 hash
taken from the Content-MD5 header field. This is used purely for
message integrity check, so it is only used for detecting unintended
modifications of the message.
12. IANA Considerations 12. IANA Considerations
IANA is requested to update "Service Names and Transport Protocol IANA is requested to update "Service Names and Transport Protocol
Port Numbers" registry as follows: Port Numbers" registry as follows:
1. Registration for TCP port 143 and the corresponding "imap" 1. Registration for TCP port 143 and the corresponding "imap"
service name should be updated to point to this document and RFC service name should be updated to point to this document and RFC
3501. 3501.
2. Registration for TCP port 993 and the corresponding "imaps" 2. Registration for TCP port 993 and the corresponding "imaps"
skipping to change at page 150, line 35 skipping to change at page 152, line 13
<https://www.rfc-editor.org/info/rfc5258>. <https://www.rfc-editor.org/info/rfc5258>.
[RFC5788] Melnikov, A. and D. Cridland, "IMAP4 Keyword Registry", [RFC5788] Melnikov, A. and D. Cridland, "IMAP4 Keyword Registry",
RFC 5788, DOI 10.17487/RFC5788, March 2010, RFC 5788, DOI 10.17487/RFC5788, March 2010,
<https://www.rfc-editor.org/info/rfc5788>. <https://www.rfc-editor.org/info/rfc5788>.
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008, Specifications: ABNF", STD 68, RFC 5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[ANONYMOUS]
Zeilenga, K., "Anonymous Simple Authentication and
Security Layer (SASL) Mechanism", RFC 4505, June 2006,
<https://www.rfc-editor.org/info/rfc4505>.
[CHARSET] Freed, N. and J. Postel, "IANA Charset Registration [CHARSET] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2978, October 2000, Procedures", BCP 19, RFC 2978, October 2000,
<https://www.rfc-editor.org/info/rfc2978>. <https://www.rfc-editor.org/info/rfc2978>.
[SCRAM-SHA-256] [SCRAM-SHA-256]
Hansen, T., "SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Hansen, T., "SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple
Authentication and Security Layer (SASL) Mechanisms", Authentication and Security Layer (SASL) Mechanisms",
RFC 7677, DOI 10.17487/RFC7677, November 2015, RFC 7677, DOI 10.17487/RFC7677, November 2015,
<https://www.rfc-editor.org/info/rfc7677>. <https://www.rfc-editor.org/info/rfc7677>.
skipping to change at page 153, line 5 skipping to change at page 154, line 24
[NET-UNICODE] [NET-UNICODE]
Klensin, J. and M. Padlipsky, "Unicode Format for Network Klensin, J. and M. Padlipsky, "Unicode Format for Network
Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008,
<https://www.rfc-editor.org/info/rfc5198>. <https://www.rfc-editor.org/info/rfc5198>.
[I18N-HDRS] [I18N-HDRS]
Yang, A., Steele, S., and N. Freed, "Internationalized Yang, A., Steele, S., and N. Freed, "Internationalized
Email Headers", RFC 6532, DOI 10.17487/RFC6532, February Email Headers", RFC 6532, DOI 10.17487/RFC6532, February
2012, <https://www.rfc-editor.org/info/rfc6532>. 2012, <https://www.rfc-editor.org/info/rfc6532>.
[RFC3503] Melnikov, A., "Message Disposition Notification (MDN)
profile for Internet Message Access Protocol (IMAP)",
RFC 3503, DOI 10.17487/RFC3503, March 2003,
<https://www.rfc-editor.org/info/rfc3503>.
[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>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>. 2015, <https://www.rfc-editor.org/info/rfc7525>.
skipping to change at page 154, line 10 skipping to change at page 155, line 31
[RFC2193] Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193, [RFC2193] Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193,
DOI 10.17487/RFC2193, September 1997, DOI 10.17487/RFC2193, September 1997,
<https://www.rfc-editor.org/info/rfc2193>. <https://www.rfc-editor.org/info/rfc2193>.
[RFC3348] Gahrns, M. and R. Cheng, "The Internet Message Action [RFC3348] Gahrns, M. and R. Cheng, "The Internet Message Action
Protocol (IMAP4) Child Mailbox Extension", RFC 3348, Protocol (IMAP4) Child Mailbox Extension", RFC 3348,
DOI 10.17487/RFC3348, July 2002, DOI 10.17487/RFC3348, July 2002,
<https://www.rfc-editor.org/info/rfc3348>. <https://www.rfc-editor.org/info/rfc3348>.
[RFC3503] Melnikov, A., "Message Disposition Notification (MDN)
profile for Internet Message Access Protocol (IMAP)",
RFC 3503, DOI 10.17487/RFC3503, March 2003,
<https://www.rfc-editor.org/info/rfc3503>.
[RFC5256] Crispin, M. and K. Murchison, "Internet Message Access [RFC5256] Crispin, M. and K. Murchison, "Internet Message Access
Protocol - SORT and THREAD Extensions", RFC 5256, Protocol - SORT and THREAD Extensions", RFC 5256,
DOI 10.17487/RFC5256, June 2008, DOI 10.17487/RFC5256, June 2008,
<https://www.rfc-editor.org/info/rfc5256>. <https://www.rfc-editor.org/info/rfc5256>.
[RFC5465] Gulbrandsen, A., King, C., and A. Melnikov, "The IMAP [RFC5465] Gulbrandsen, A., King, C., and A. Melnikov, "The IMAP
NOTIFY Extension", RFC 5465, DOI 10.17487/RFC5465, NOTIFY Extension", RFC 5465, DOI 10.17487/RFC5465,
February 2009, <https://www.rfc-editor.org/info/rfc5465>. February 2009, <https://www.rfc-editor.org/info/rfc5465>.
[RFC6186] Daboo, C., "Use of SRV Records for Locating Email [RFC6186] Daboo, C., "Use of SRV Records for Locating Email
Submission/Access Services", RFC 6186, Submission/Access Services", RFC 6186,
DOI 10.17487/RFC6186, March 2011, DOI 10.17487/RFC6186, March 2011,
<https://www.rfc-editor.org/info/rfc6186>. <https://www.rfc-editor.org/info/rfc6186>.
[RFC7162] Melnikov, A. and D. Cridland, "IMAP Extensions: Quick Flag
Changes Resynchronization (CONDSTORE) and Quick Mailbox
Resynchronization (QRESYNC)", RFC 7162,
DOI 10.17487/RFC7162, May 2014,
<https://www.rfc-editor.org/info/rfc7162>.
[RFC7888] Melnikov, A., Ed., "IMAP4 Non-synchronizing Literals", [RFC7888] Melnikov, A., Ed., "IMAP4 Non-synchronizing Literals",
RFC 7888, DOI 10.17487/RFC7888, May 2016, RFC 7888, DOI 10.17487/RFC7888, May 2016,
<https://www.rfc-editor.org/info/rfc7888>. <https://www.rfc-editor.org/info/rfc7888>.
[RFC8474] Gondwana, B., Ed., "IMAP Extension for Object
Identifiers", RFC 8474, DOI 10.17487/RFC8474, September
2018, <https://www.rfc-editor.org/info/rfc8474>.
[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,
<https://www.rfc-editor.org/info/rfc4549>. <https://www.rfc-editor.org/info/rfc4549>.
[IMAP-I18N] [IMAP-I18N]
Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet
Message Access Protocol Internationalization", RFC 5255, Message Access Protocol Internationalization", RFC 5255,
DOI 10.17487/RFC5255, June 2008, DOI 10.17487/RFC5255, June 2008,
<https://www.rfc-editor.org/info/rfc5255>. <https://www.rfc-editor.org/info/rfc5255>.
skipping to change at page 155, line 5 skipping to change at page 156, line 34
[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,
<https://www.rfc-editor.org/info/rfc1733>. <https://www.rfc-editor.org/info/rfc1733>.
[IMAP-UTF-8] [IMAP-UTF-8]
Resnick, P., Ed., Newman, C., Ed., and S. Shen, Ed., "IMAP Resnick, P., Ed., Newman, C., Ed., and S. Shen, Ed., "IMAP
Support for UTF-8", RFC 6855, DOI 10.17487/RFC6855, March Support for UTF-8", RFC 6855, DOI 10.17487/RFC6855, March
2013, <https://www.rfc-editor.org/info/rfc6855>. 2013, <https://www.rfc-editor.org/info/rfc6855>.
[ANONYMOUS]
Zeilenga, K., "Anonymous Simple Authentication and
Security Layer (SASL) Mechanism", RFC 4505, June 2006,
<https://www.rfc-editor.org/info/rfc4505>.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008, <https://www.rfc-editor.org/info/rfc5321>. October 2008, <https://www.rfc-editor.org/info/rfc5321>.
[RFC3516] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516, [RFC3516] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516,
DOI 10.17487/RFC3516, April 2003, DOI 10.17487/RFC3516, April 2003,
<https://www.rfc-editor.org/info/rfc3516>. <https://www.rfc-editor.org/info/rfc3516>.
[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,
<https://www.rfc-editor.org/info/rfc4314>. <https://www.rfc-editor.org/info/rfc4314>.
skipping to change at page 161, line 28 skipping to change at page 163, line 15
26. Added warnings about use of ALERT response codes and PREAUTH 26. Added warnings about use of ALERT response codes and PREAUTH
response. response.
27. Replaced DIGEST-MD5 SASL mechanism with SCRAM-SHA-256. DIGEST- 27. Replaced DIGEST-MD5 SASL mechanism with SCRAM-SHA-256. DIGEST-
MD5 was deprecated. MD5 was deprecated.
28. Clarified that any command received from the client resets 28. Clarified that any command received from the client resets
server autologout timer. server autologout timer.
29. Revised IANA registration procedure for IMAP extensions and 29. Revised IANA registration procedure for IMAP extensions and
removed "X" convention. removed "X" convention in accordance with BCP 178.
30. Loosened requirements on servers when closing connections to be 30. Loosened requirements on servers when closing connections to be
more aligned with existing practices. more aligned with existing practices.
Appendix F. Other Recommended IMAP Extensions Appendix F. Other Recommended IMAP Extensions
Support for the following extensions is recommended for all IMAP Support for the following extensions is recommended for all IMAP
client and servers. While they significantly reduce bandwidth and/or client and servers. While they significantly reduce bandwidth and/or
number of round trips used by IMAP in certain situations, the EXTRA 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 WG decided that requiring them as a part of IMAP4rev2 would push the
bar to implement too high for new implementations. Also note that bar to implement too high for new implementations. Also note that
absence of any IMAP extension from this list doesn't make it somehow absence of any IMAP extension from this list doesn't make it somehow
deficient or not recommended for use with IMAP4rev2. deficient or not recommended for use with IMAP4rev2.
1. QRESYNC and CONDSTORE extensions (RFC 7162). They make 1. QRESYNC and CONDSTORE extensions [RFC7162]. They make
discovering changes to IMAP mailboxes more efficient, at the discovering changes to IMAP mailboxes more efficient, at the
expense of storing a bit more state. expense of storing a bit more state.
2. OBJECTID extension (RFC 8474) helps with preserving IMAP client 2. OBJECTID extension [RFC8474] helps with preserving IMAP client
cache when messages moved/copied or mailboxes are renamed. cache when messages moved/copied or mailboxes are renamed.
Appendix G. Acknowledgement Appendix G. 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 Murray Kucherawy, Timo Sirainen, Bron Gondwana, Stephan Thank you to Murray Kucherawy, Timo Sirainen, Bron Gondwana, Stephan
Bosch, Robert Sparks, Arnt Gulbrandsen, Daniel Migault, Roman Danyliw Bosch, Robert Sparks, Arnt Gulbrandsen, Benjamin Kaduk, Daniel
and Eric Vyncke for extensive feedback. Migault, Roman Danyliw and Eric Vyncke for extensive feedback.
This document incorporates text from RFC 4315 (by Mark Crispin), RFC This document incorporates text from RFC 4315 (by Mark Crispin), RFC
4466 (by Cyrus Daboo), RFC 4731 (by Dave Cridland), RFC 5161 (by Arnt 4466 (by Cyrus Daboo), RFC 4731 (by Dave Cridland), RFC 5161 (by Arnt
Gulbrandsen), RFC 5465 (by Arnt Gulbrandsen and Curtis King), RFC Gulbrandsen), RFC 5465 (by Arnt Gulbrandsen and Curtis King), RFC
5530 (by Arnt Gulbrandsen), RFC 5819 (by Timo Sirainen), RFC 6154 (by 5530 (by Arnt Gulbrandsen), RFC 5819 (by Timo Sirainen), RFC 6154 (by
Jamie Nicolson), RFC 8438 (by Stephan Bosch) so work done by authors/ Jamie Nicolson), RFC 8438 (by Stephan Bosch) so work done by authors/
editors of these documents is appreciated. Note that editors of this editors of these documents is appreciated. Note that editors of this
document were redacted from the above list. document were redacted from the above list.
The CHILDREN return option was originally proposed by Mike Gahrns and The CHILDREN return option was originally proposed by Mike Gahrns and
skipping to change at page 163, line 11 skipping to change at page 164, line 43
- -
-FLAGS <flag list> 93 -FLAGS <flag list> 93
-FLAGS.SILENT <flag list> 93 -FLAGS.SILENT <flag list> 93
A A
ALERT (response code) 101 ALERT (response code) 101
ALL (fetch item) 89 ALL (fetch item) 89
ALL (search key) 79 ALL (search key) 79
ALL (search result option) 77 ALL (search result option) 77
ALL (search return item name) 118
ALREADYEXISTS (response code) 101 ALREADYEXISTS (response code) 101
ANSWERED (search key) 79 ANSWERED (search key) 79
APPEND (command) 69 APPEND (command) 69
APPENDUID (response code) 101 APPENDUID (response code) 101
AUTHENTICATE (command) 30 AUTHENTICATE (command) 30
AUTHENTICATIONFAILED (response code) 102 AUTHENTICATIONFAILED (response code) 102
AUTHORIZATIONFAILED (response code) 102 AUTHORIZATIONFAILED (response code) 102
B B
BAD (response) 109 BAD (response) 109
BADCHARSET (response code) 102 BADCHARSET (response code) 102
BCC <string> (search key) 79 BCC <string> (search key) 79
BEFORE <date> (search key) 79 BEFORE <date> (search key) 79
BINARY.PEEK[<section-binary>]<<partial>> (fetch item) 89 BINARY.PEEK[<section-binary>]<<partial>> (fetch item) 89
BINARY.SIZE[<section-binary>] (fetch item) 90 BINARY.SIZE[<section-binary>] (fetch item) 90
BINARY.SIZE[<section-binary>] (fetch result) 120 BINARY.SIZE[<section-binary>] (fetch result) 121
BINARY[<section-binary>]<<number>> (fetch result) 119 BINARY[<section-binary>]<<number>> (fetch result) 120
BINARY[<section-binary>]<<partial>> (fetch item) 89 BINARY[<section-binary>]<<partial>> (fetch item) 89
BODY (fetch item) 90 BODY (fetch item) 90
BODY (fetch result) 120 BODY (fetch result) 121
BODY <string> (search key) 79 BODY <string> (search key) 79
BODY.PEEK[<section>]<<partial>> (fetch item) 90 BODY.PEEK[<section>]<<partial>> (fetch item) 90
BODYSTRUCTURE (fetch item) 91 BODYSTRUCTURE (fetch item) 91
BODYSTRUCTURE (fetch result) 121 BODYSTRUCTURE (fetch result) 122
BODY[<section>]<<origin octet>> (fetch result) 120 BODY[<section>]<<origin octet>> (fetch result) 121
BODY[<section>]<<partial>> (fetch item) 90 BODY[<section>]<<partial>> (fetch item) 90
BYE (response) 110 BYE (response) 110
Body Structure (message attribute) 14 Body Structure (message attribute) 14
C C
CANNOT (response code) 102 CANNOT (response code) 102
CAPABILITY (command) 26 CAPABILITY (command) 26
CAPABILITY (response code) 103 CAPABILITY (response code) 103
CAPABILITY (response) 111 CAPABILITY (response) 111
CC <string> (search key) 79 CC <string> (search key) 79
CLIENTBUG (response code) 103 CLIENTBUG (response code) 103
CLOSE (command) 75 CLOSE (command) 75
CLOSED (response code) 103 CLOSED (response code) 103
CONTACTADMIN (response code) 103 CONTACTADMIN (response code) 103
COPY (command) 94 COPY (command) 94
COPYUID (response code) 103 COPYUID (response code) 104
CORRUPTION (response code) 104 CORRUPTION (response code) 104
COUNT (search result option) 77 COUNT (search result option) 77
COUNT (search return item name) 118
CREATE (command) 39 CREATE (command) 39
D D
DELETE (command) 40 DELETE (command) 40
DELETED (search key) 79 DELETED (search key) 79
DELETED (status item) 69 DELETED (status item) 69
DRAFT (search key) 79 DRAFT (search key) 79
E E
ENABLE (command) 34 ENABLE (command) 34
ENVELOPE (fetch item) 91 ENVELOPE (fetch item) 91
ENVELOPE (fetch result) 123 ENVELOPE (fetch result) 125
ESEARCH (response) 117 ESEARCH (response) 117
EXAMINE (command) 38 EXAMINE (command) 38
EXPIRED (response code) 104 EXPIRED (response code) 104
EXPUNGE (command) 76 EXPUNGE (command) 76
EXPUNGE (response) 118 EXPUNGE (response) 119
EXPUNGEISSUED (response code) 104 EXPUNGEISSUED (response code) 104
Envelope Structure (message attribute) 14 Envelope Structure (message attribute) 14
F F
FAST (fetch item) 89 FAST (fetch item) 89
FETCH (command) 88 FETCH (command) 88
FETCH (response) 119 FETCH (response) 120
FLAGGED (search key) 79 FLAGGED (search key) 79
FLAGS (fetch item) 91 FLAGS (fetch item) 91
FLAGS (fetch result) 125 FLAGS (fetch result) 126
FLAGS (response) 117 FLAGS (response) 119
FLAGS <flag list> (store command data item) 93 FLAGS <flag list> (store command data item) 93
FLAGS.SILENT <flag list> (store command data item) 93 FLAGS.SILENT <flag list> (store command data item) 93
FROM <string> (search key) 79 FROM <string> (search key) 79
FULL (fetch item) 89 FULL (fetch item) 89
Flags (message attribute) 12 Flags (message attribute) 12
H H
HASCHILDREN (response code) 105 HASCHILDREN (response code) 105
HEADER (part specifier) 91 HEADER (part specifier) 91
HEADER <field-name> <string> (search key) 80 HEADER <field-name> <string> (search key) 80
HEADER.FIELDS (part specifier) 91 HEADER.FIELDS (part specifier) 91
HEADER.FIELDS.NOT (part specifier) 91 HEADER.FIELDS.NOT (part specifier) 91
I I
IDLE (command) 72 IDLE (command) 72
INTERNALDATE (fetch item) 91 INTERNALDATE (fetch item) 91
INTERNALDATE (fetch result) 125 INTERNALDATE (fetch result) 126
INUSE (response code) 105 INUSE (response code) 105
Internal Date (message attribute) 14 Internal Date (message attribute) 14
K K
KEYWORD <flag> (search key) 80 KEYWORD <flag> (search key) 80
Keyword (type of flag) 12 Keyword (type of flag) 12
L L
LARGER <n> (search key) 80 LARGER <n> (search key) 80
LIMIT (response code) 105 LIMIT (response code) 105
LIST (command) 45 LIST (command) 46
LIST (response) 112 LIST (response) 113
LOGOUT (command) 27 LOGOUT (command) 27
M M
MAX (search result option) 77 MAX (search result option) 77
MAX (search return item name) 118
MAY (specification requirement term) 5 MAY (specification requirement term) 5
MESSAGES (status item) 69 MESSAGES (status item) 69
MIME (part specifier) 92 MIME (part specifier) 92
MIN (search result option) 77 MIN (search result option) 77
MIN (search return item name) 118
MOVE (command) 95 MOVE (command) 95
MUST (specification requirement term) 5 MUST (specification requirement term) 5
MUST NOT (specification requirement term) 5 MUST NOT (specification requirement term) 5
Message Sequence Number (message attribute) 11 Message Sequence Number (message attribute) 11
N N
NAMESPACE (command) 64 NAMESPACE (command) 64
NAMESPACE (response) 116 NAMESPACE (response) 117
NO (response) 109 NO (response) 109
NONEXISTENT (response code) 105 NONEXISTENT (response code) 105
NOOP (command) 27 NOOP (command) 27
NOPERM (response code) 105 NOPERM (response code) 106
NOT <search-key> (search key) 80 NOT <search-key> (search key) 80
NOT RECOMMENDED (specification requirement term) 5 NOT RECOMMENDED (specification requirement term) 5
O O
OK (response) 108 OK (response) 109
ON <date> (search key) 80 ON <date> (search key) 80
OPTIONAL (specification requirement term) 5 OPTIONAL (specification requirement term) 5
OR <search-key1> <search-key2> (search key) 80 OR <search-key1> <search-key2> (search key) 80
OVERQUOTA (response code) 106 OVERQUOTA (response code) 106
P P
PARSE (response code) 106 PARSE (response code) 106
PERMANENTFLAGS (response code) 106 PERMANENTFLAGS (response code) 106
PREAUTH (response) 110 PREAUTH (response) 110
PRIVACYREQUIRED (response code) 106 PRIVACYREQUIRED (response code) 107
Permanent Flag (class of flag) 13 Permanent Flag (class of flag) 13
Predefined keywords 12 Predefined keywords 12
R R
READ-ONLY (response code) 107 READ-ONLY (response code) 107
READ-WRITE (response code) 107 READ-WRITE (response code) 107
RECOMMENDED (specification requirement term) 5 RECOMMENDED (specification requirement term) 5
RENAME (command) 42 RENAME (command) 42
REQUIRED (specification requirement term) 5 REQUIRED (specification requirement term) 5
RFC822.SIZE (fetch item) 91 RFC822.SIZE (fetch item) 91
RFC822.SIZE (fetch result) 125 RFC822.SIZE (fetch result) 126
S S
SAVE (search result option) 77 SAVE (search result option) 77
SEARCH (command) 76 SEARCH (command) 76
SEEN (search key) 80 SEEN (search key) 80
SELECT (command) 36 SELECT (command) 36
SENTBEFORE <date> (search key) 80 SENTBEFORE <date> (search key) 80
SENTON <date> (search key) 80 SENTON <date> (search key) 80
SENTSINCE <date> (search key) 80 SENTSINCE <date> (search key) 80
SERVERBUG (response code) 107 SERVERBUG (response code) 107
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) 80 SINCE <date> (search key) 80
SIZE (status item) 69 SIZE (status item) 69
SMALLER <n> (search key) 80 SMALLER <n> (search key) 80
STARTTLS (command) 28 STARTTLS (command) 28
STATUS (command) 68 STATUS (command) 68
STATUS (response) 117 STATUS (response) 117
STORE (command) 93 STORE (command) 93
SUBJECT <string> (search key) 80 SUBJECT <string> (search key) 80
SUBSCRIBE (command) 44 SUBSCRIBE (command) 45
Session Flag (class of flag) 13 Session Flag (class of flag) 13
System Flag (type of flag) 12 System Flag (type of flag) 12
T T
TEXT (part specifier) 91 TEXT (part specifier) 91
TEXT <string> (search key) 81 TEXT <string> (search key) 81
TO <string> (search key) 81 TO <string> (search key) 81
TRYCREATE (response code) 107 TRYCREATE (response code) 107
U U
UID (command) 97 UID (command) 97
UID (fetch item) 91 UID (fetch item) 91
UID (fetch result) 125 UID (fetch result) 126
UID <sequence set> (search key) 81 UID <sequence set> (search key) 81
UIDNEXT (response code) 107 UIDNEXT (response code) 107
UIDNEXT (status item) 69 UIDNEXT (status item) 69
UIDNOTSTICKY (response code) 107 UIDNOTSTICKY (response code) 108
UIDVALIDITY (response code) 108 UIDVALIDITY (response code) 108
UIDVALIDITY (status item) 69 UIDVALIDITY (status item) 69
UNANSWERED (search key) 81 UNANSWERED (search key) 81
UNAVAILABLE (response code) 108 UNAVAILABLE (response code) 108
UNDELETED (search key) 81 UNDELETED (search key) 81
UNDRAFT (search key) 81 UNDRAFT (search key) 81
UNFLAGGED (search key) 81 UNFLAGGED (search key) 81
UNKEYWORD <flag> (search key) 81 UNKEYWORD <flag> (search key) 81
UNKNOWN-CTE (response code) 108 UNKNOWN-CTE (response code) 108
UNSEEN (search key) 81 UNSEEN (search key) 81
UNSEEN (status item) 69 UNSEEN (status item) 69
UNSELECT (command) 75 UNSELECT (command) 75
UNSUBSCRIBE (command) 45 UNSUBSCRIBE (command) 45
Unique Identifier (UID) (message attribute) 9 Unique Identifier (UID) (message attribute) 9
[ [
[RFC-5322] Size (message attribute) 14 [RFC-5322] Size (message attribute) 14
\ \
\All (mailbox name attribute) 114 \All (mailbox name attribute) 115
\Answered (system flag) 12 \Answered (system flag) 12
\Archive (mailbox name attribute) 114 \Archive (mailbox name attribute) 115
\Deleted (system flag) 12 \Deleted (system flag) 12
\Draft (system flag) 12 \Draft (system flag) 12
\Drafts (mailbox name attribute) 115 \Drafts (mailbox name attribute) 115
\Flagged (mailbox name attribute) 115 \Flagged (mailbox name attribute) 115
\Flagged (system flag) 12 \Flagged (system flag) 12
\HasChildren (mailbox name attribute) 113 \HasChildren (mailbox name attribute) 114
\HasNoChildren (mailbox name attribute) 113 \HasNoChildren (mailbox name attribute) 114
\Junk (mailbox name attribute) 115 \Junk (mailbox name attribute) 115
\Marked (mailbox name attribute) 114 \Marked (mailbox name attribute) 114
\Noinferiors (mailbox name attribute) 113 \Noinferiors (mailbox name attribute) 113
\NonExistent (mailbox name attribute) 113 \NonExistent (mailbox name attribute) 113
\Noselect (mailbox name attribute) 113 \Noselect (mailbox name attribute) 113
\Recent (system flag) 12 \Recent (system flag) 12
\Remote (mailbox name attribute) 114 \Remote (mailbox name attribute) 114
\Seen (system flag) 12 \Seen (system flag) 12
\Sent (mailbox name attribute) 115 \Sent (mailbox name attribute) 115
\Subscribed (mailbox name attribute) 114 \Subscribed (mailbox name attribute) 114
 End of changes. 104 change blocks. 
178 lines changed or deleted 260 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/