< draft-ietf-extra-imap4rev2-23.txt   draft-ietf-extra-imap4rev2-24.txt >
Network Working Group A. Melnikov, Ed. Network Working Group A. Melnikov, Ed.
Internet-Draft Isode Ltd Internet-Draft Isode Ltd
Obsoletes: 3501 (if approved) B. Leiba, Ed. Obsoletes: 3501 (if approved) B. Leiba, Ed.
Intended status: Standards Track Futurewei Technologies Intended status: Standards Track Futurewei Technologies
Expires: July 8, 2021 January 4, 2021 Expires: July 9, 2021 January 5, 2021
Internet Message Access Protocol (IMAP) - Version 4rev2 Internet Message Access Protocol (IMAP) - Version 4rev2
draft-ietf-extra-imap4rev2-23 draft-ietf-extra-imap4rev2-24
Abstract Abstract
The Internet Message Access Protocol, Version 4rev2 (IMAP4rev2) The Internet Message Access Protocol, Version 4rev2 (IMAP4rev2)
allows a client to access and manipulate electronic mail messages on allows a client to access and manipulate electronic mail messages on
a server. IMAP4rev2 permits manipulation of mailboxes (remote a server. IMAP4rev2 permits manipulation of mailboxes (remote
message folders) in a way that is functionally equivalent to local message folders) in a way that is functionally equivalent to local
folders. IMAP4rev2 also provides the capability for an offline folders. IMAP4rev2 also provides the capability for an offline
client to resynchronize with the server. client to resynchronize with the server.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 8, 2021. This Internet-Draft will expire on July 9, 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 22 skipping to change at page 3, line 22
4.3.1. 8-bit and Binary Strings . . . . . . . . . . . . . . 18 4.3.1. 8-bit and Binary Strings . . . . . . . . . . . . . . 18
4.4. Parenthesized List . . . . . . . . . . . . . . . . . . . 19 4.4. Parenthesized List . . . . . . . . . . . . . . . . . . . 19
4.5. NIL . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.5. NIL . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5. Operational Considerations . . . . . . . . . . . . . . . . . 20 5. Operational Considerations . . . . . . . . . . . . . . . . . 20
5.1. Mailbox Naming . . . . . . . . . . . . . . . . . . . . . 20 5.1. Mailbox Naming . . . . . . . . . . . . . . . . . . . . . 20
5.1.1. Mailbox Hierarchy Naming . . . . . . . . . . . . . . 21 5.1.1. Mailbox Hierarchy Naming . . . . . . . . . . . . . . 21
5.1.2. Namespaces . . . . . . . . . . . . . . . . . . . . . 21 5.1.2. Namespaces . . . . . . . . . . . . . . . . . . . . . 21
5.2. Mailbox Size and Message Status Updates . . . . . . . . . 23 5.2. Mailbox Size and Message Status Updates . . . . . . . . . 23
5.3. Response when no Command in Progress . . . . . . . . . . 23 5.3. Response when no Command in Progress . . . . . . . . . . 23
5.4. Autologout Timer . . . . . . . . . . . . . . . . . . . . 23 5.4. Autologout Timer . . . . . . . . . . . . . . . . . . . . 23
5.5. Multiple Commands in Progress (Command Pipelining) . . . 23 5.5. Multiple Commands in Progress (Command Pipelining) . . . 24
6. Client Commands . . . . . . . . . . . . . . . . . . . . . . . 25 6. Client Commands . . . . . . . . . . . . . . . . . . . . . . . 25
6.1. Client Commands - Any State . . . . . . . . . . . . . . . 25 6.1. Client Commands - Any State . . . . . . . . . . . . . . . 26
6.1.1. CAPABILITY Command . . . . . . . . . . . . . . . . . 25 6.1.1. CAPABILITY Command . . . . . . . . . . . . . . . . . 26
6.1.2. NOOP Command . . . . . . . . . . . . . . . . . . . . 26 6.1.2. NOOP Command . . . . . . . . . . . . . . . . . . . . 27
6.1.3. LOGOUT Command . . . . . . . . . . . . . . . . . . . 27 6.1.3. LOGOUT Command . . . . . . . . . . . . . . . . . . . 27
6.2. Client Commands - Not Authenticated State . . . . . . . . 27 6.2. Client Commands - Not Authenticated State . . . . . . . . 28
6.2.1. STARTTLS Command . . . . . . . . . . . . . . . . . . 28 6.2.1. STARTTLS Command . . . . . . . . . . . . . . . . . . 28
6.2.2. AUTHENTICATE Command . . . . . . . . . . . . . . . . 29 6.2.2. AUTHENTICATE Command . . . . . . . . . . . . . . . . 29
6.2.3. LOGIN Command . . . . . . . . . . . . . . . . . . . . 32 6.2.3. LOGIN Command . . . . . . . . . . . . . . . . . . . . 32
6.3. Client Commands - Authenticated State . . . . . . . . . . 33 6.3. Client Commands - Authenticated State . . . . . . . . . . 33
6.3.1. ENABLE Command . . . . . . . . . . . . . . . . . . . 33 6.3.1. ENABLE Command . . . . . . . . . . . . . . . . . . . 33
6.3.2. SELECT Command . . . . . . . . . . . . . . . . . . . 35 6.3.2. SELECT Command . . . . . . . . . . . . . . . . . . . 35
6.3.3. EXAMINE Command . . . . . . . . . . . . . . . . . . . 37 6.3.3. EXAMINE Command . . . . . . . . . . . . . . . . . . . 37
6.3.4. CREATE Command . . . . . . . . . . . . . . . . . . . 38 6.3.4. CREATE Command . . . . . . . . . . . . . . . . . . . 38
6.3.5. DELETE Command . . . . . . . . . . . . . . . . . . . 39 6.3.5. DELETE Command . . . . . . . . . . . . . . . . . . . 40
6.3.6. RENAME Command . . . . . . . . . . . . . . . . . . . 41 6.3.6. RENAME Command . . . . . . . . . . . . . . . . . . . 41
6.3.7. SUBSCRIBE Command . . . . . . . . . . . . . . . . . . 43 6.3.7. SUBSCRIBE Command . . . . . . . . . . . . . . . . . . 44
6.3.8. UNSUBSCRIBE Command . . . . . . . . . . . . . . . . . 44 6.3.8. UNSUBSCRIBE Command . . . . . . . . . . . . . . . . . 44
6.3.9. LIST Command . . . . . . . . . . . . . . . . . . . . 44 6.3.9. LIST Command . . . . . . . . . . . . . . . . . . . . 45
6.3.10. NAMESPACE Command . . . . . . . . . . . . . . . . . . 63 6.3.10. NAMESPACE Command . . . . . . . . . . . . . . . . . . 63
6.3.11. STATUS Command . . . . . . . . . . . . . . . . . . . 67 6.3.11. STATUS Command . . . . . . . . . . . . . . . . . . . 67
6.3.12. APPEND Command . . . . . . . . . . . . . . . . . . . 68 6.3.12. APPEND Command . . . . . . . . . . . . . . . . . . . 68
6.3.13. IDLE Command . . . . . . . . . . . . . . . . . . . . 71 6.3.13. IDLE Command . . . . . . . . . . . . . . . . . . . . 71
6.4. Client Commands - Selected State . . . . . . . . . . . . 73 6.4. Client Commands - Selected State . . . . . . . . . . . . 73
6.4.1. CLOSE Command . . . . . . . . . . . . . . . . . . . . 74 6.4.1. CLOSE Command . . . . . . . . . . . . . . . . . . . . 74
6.4.2. UNSELECT Command . . . . . . . . . . . . . . . . . . 74 6.4.2. UNSELECT Command . . . . . . . . . . . . . . . . . . 74
6.4.3. EXPUNGE Command . . . . . . . . . . . . . . . . . . . 75 6.4.3. EXPUNGE Command . . . . . . . . . . . . . . . . . . . 75
6.4.4. SEARCH Command . . . . . . . . . . . . . . . . . . . 75 6.4.4. SEARCH Command . . . . . . . . . . . . . . . . . . . 75
6.4.5. FETCH Command . . . . . . . . . . . . . . . . . . . . 87 6.4.5. FETCH Command . . . . . . . . . . . . . . . . . . . . 87
6.4.6. STORE Command . . . . . . . . . . . . . . . . . . . . 92 6.4.6. STORE Command . . . . . . . . . . . . . . . . . . . . 92
6.4.7. COPY Command . . . . . . . . . . . . . . . . . . . . 93 6.4.7. COPY Command . . . . . . . . . . . . . . . . . . . . 93
6.4.8. MOVE Command . . . . . . . . . . . . . . . . . . . . 94 6.4.8. MOVE Command . . . . . . . . . . . . . . . . . . . . 94
6.4.9. UID Command . . . . . . . . . . . . . . . . . . . . . 96 6.4.9. UID Command . . . . . . . . . . . . . . . . . . . . . 96
6.5. Client Commands - Experimental/Expansion . . . . . . . . 97 6.5. Client Commands - Experimental/Expansion . . . . . . . . 97
6.5.1. X<atom> Command . . . . . . . . . . . . . . . . . . . 97
7. Server Responses . . . . . . . . . . . . . . . . . . . . . . 98 7. Server Responses . . . . . . . . . . . . . . . . . . . . . . 98
7.1. Server Responses - Status Responses . . . . . . . . . . . 99 7.1. Server Responses - Status Responses . . . . . . . . . . . 99
7.1.1. OK Response . . . . . . . . . . . . . . . . . . . . . 107 7.1.1. OK Response . . . . . . . . . . . . . . . . . . . . . 107
7.1.2. NO Response . . . . . . . . . . . . . . . . . . . . . 108 7.1.2. NO Response . . . . . . . . . . . . . . . . . . . . . 107
7.1.3. BAD Response . . . . . . . . . . . . . . . . . . . . 108 7.1.3. BAD Response . . . . . . . . . . . . . . . . . . . . 108
7.1.4. PREAUTH Response . . . . . . . . . . . . . . . . . . 108 7.1.4. PREAUTH Response . . . . . . . . . . . . . . . . . . 108
7.1.5. BYE Response . . . . . . . . . . . . . . . . . . . . 109 7.1.5. BYE Response . . . . . . . . . . . . . . . . . . . . 109
7.2. Server Responses - Server and Mailbox Status . . . . . . 109 7.2. Server Responses - Server and Mailbox Status . . . . . . 109
7.2.1. The ENABLED Response . . . . . . . . . . . . . . . . 110 7.2.1. The ENABLED Response . . . . . . . . . . . . . . . . 109
7.2.2. CAPABILITY Response . . . . . . . . . . . . . . . . . 110 7.2.2. CAPABILITY Response . . . . . . . . . . . . . . . . . 110
7.2.3. LIST Response . . . . . . . . . . . . . . . . . . . . 111 7.2.3. LIST Response . . . . . . . . . . . . . . . . . . . . 111
7.2.4. NAMESPACE Response . . . . . . . . . . . . . . . . . 115 7.2.4. NAMESPACE Response . . . . . . . . . . . . . . . . . 114
7.2.5. STATUS Response . . . . . . . . . . . . . . . . . . . 115 7.2.5. STATUS Response . . . . . . . . . . . . . . . . . . . 115
7.2.6. ESEARCH Response . . . . . . . . . . . . . . . . . . 115 7.2.6. ESEARCH Response . . . . . . . . . . . . . . . . . . 115
7.2.7. FLAGS Response . . . . . . . . . . . . . . . . . . . 116 7.2.7. FLAGS Response . . . . . . . . . . . . . . . . . . . 116
7.3. Server Responses - Mailbox Size . . . . . . . . . . . . . 116 7.3. Server Responses - Mailbox Size . . . . . . . . . . . . . 116
7.3.1. EXISTS Response . . . . . . . . . . . . . . . . . . . 116 7.3.1. EXISTS Response . . . . . . . . . . . . . . . . . . . 116
7.4. Server Responses - Message Status . . . . . . . . . . . . 117 7.4. Server Responses - Message Status . . . . . . . . . . . . 116
7.4.1. EXPUNGE Response . . . . . . . . . . . . . . . . . . 117 7.4.1. EXPUNGE Response . . . . . . . . . . . . . . . . . . 117
7.4.2. FETCH Response . . . . . . . . . . . . . . . . . . . 118 7.4.2. FETCH Response . . . . . . . . . . . . . . . . . . . 117
7.5. Server Responses - Command Continuation Request . . . . . 124 7.5. Server Responses - Command Continuation Request . . . . . 123
8. Sample IMAP4rev2 connection . . . . . . . . . . . . . . . . . 124 8. Sample IMAP4rev2 connection . . . . . . . . . . . . . . . . . 124
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 125 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 125
10. Author's Note . . . . . . . . . . . . . . . . . . . . . . . . 143 10. Author's Note . . . . . . . . . . . . . . . . . . . . . . . . 143
11. Security Considerations . . . . . . . . . . . . . . . . . . . 143 11. Security Considerations . . . . . . . . . . . . . . . . . . . 143
11.1. STARTTLS Security Considerations . . . . . . . . . . . . 143 11.1. STARTTLS Security Considerations . . . . . . . . . . . . 143
11.2. COPYUID and APPENDUID response codes . . . . . . . . . . 144 11.2. COPYUID and APPENDUID response codes . . . . . . . . . . 144
11.3. LIST command and Other Users' namespace . . . . . . . . 144 11.3. LIST command and Other Users' namespace . . . . . . . . 144
11.4. Other Security Considerations . . . . . . . . . . . . . 145 11.4. Other Security Considerations . . . . . . . . . . . . . 145
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 145 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 145
12.1. Updates to IMAP4 Capabilities registry . . . . . . . . . 146 12.1. Updates to IMAP4 Capabilities registry . . . . . . . . . 146
skipping to change at page 5, line 4 skipping to change at page 4, line 51
12.3. LIST Selection Options, LIST Return Options, LIST 12.3. LIST Selection Options, LIST Return Options, LIST
extended data items . . . . . . . . . . . . . . . . . . 146 extended data items . . . . . . . . . . . . . . . . . . 146
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 147 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 147
13.1. Normative References . . . . . . . . . . . . . . . . . . 147 13.1. Normative References . . . . . . . . . . . . . . . . . . 147
13.2. Informative References (related protocols) . . . . . . . 150 13.2. Informative References (related protocols) . . . . . . . 150
13.3. Informative References (historical aspects of IMAP and 13.3. Informative References (historical aspects of IMAP and
related protocols) . . . . . . . . . . . . . . . . . . . 152 related protocols) . . . . . . . . . . . . . . . . . . . 152
Appendix A. Backward compatibility with IMAP4rev1 . . . . . . . 152 Appendix A. Backward compatibility with IMAP4rev1 . . . . . . . 152
A.1. Mailbox International Naming Convention for compatibility A.1. Mailbox International Naming Convention for compatibility
with IMAP4rev1 . . . . . . . . . . . . . . . . . . . . . 153 with IMAP4rev1 . . . . . . . . . . . . . . . . . . . . . 153
Appendix B. Backward compatibility with BINARY extension . . . . 155 Appendix B. Backward compatibility with BINARY extension . . . . 155
Appendix C. Backward compatibility with LIST-EXTENDED extension 155 Appendix C. Backward compatibility with LIST-EXTENDED extension 155
Appendix D. 63 bit body part and message sizes . . . . . . . . . 155 Appendix D. 63 bit body part and message sizes . . . . . . . . . 155
Appendix E. Changes from RFC 3501 / IMAP4rev1 . . . . . . . . . 155 Appendix E. Changes from RFC 3501 / IMAP4rev1 . . . . . . . . . 155
Appendix F. Other Recommended IMAP Extensions . . . . . . . . . 157 Appendix F. Other Recommended IMAP Extensions . . . . . . . . . 157
Appendix G. Acknowledgement . . . . . . . . . . . . . . . . . . 157 Appendix G. Acknowledgement . . . . . . . . . . . . . . . . . . 158
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 163 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 163
1. How to Read This Document 1. How to Read This Document
1.1. Organization of This Document 1.1. Organization of This Document
This document is written from the point of view of the implementor of This document is written from the point of view of the implementor of
an IMAP4rev2 client or server. Beyond the protocol overview in an IMAP4rev2 client or server. Beyond the protocol overview in
section 2, it is not optimized for someone trying to understand the section 2, it is not optimized for someone trying to understand the
operation of the protocol. The material in sections 3 through 5 operation of the protocol. The material in sections 3 through 5
provides the general context and definitions with which IMAP4rev2 provides the general context and definitions with which IMAP4rev2
operates. operates.
Sections 6, 7, and 9 describe the IMAP commands, responses, and Sections 6, 7, and 9 describe the IMAP commands, responses, and
syntax, respectively. The relationships among these are such that it syntax, respectively. The relationships among these are such that it
is almost impossible to understand any of them separately. In is almost impossible to understand any of them separately. In
particular, do not attempt to deduce command syntax from the command particular, do not attempt to deduce command syntax from the command
section alone; instead refer to the Formal Syntax section. section alone; instead refer to the Formal Syntax (Section 9).
1.2. Conventions Used in This Document 1.2. Conventions Used in This Document
"Conventions" are basic principles or procedures. Document "Conventions" are basic principles or procedures. Document
conventions are noted in this section. conventions are noted in this section.
In examples, "C:" and "S:" indicate lines sent by the client and In examples, "C:" and "S:" indicate lines sent by the client and
server respectively. Note that each line includes the terminating server respectively. Note that each line includes the terminating
CRLF. CRLF.
skipping to change at page 7, line 49 skipping to change at page 7, line 49
generated by the client for each command. (More formally: the client generated by the client for each command. (More formally: the client
SHOULD generate a unique tag for every command, but a server MUST SHOULD generate a unique tag for every command, but a server MUST
accept tag reuse.) accept tag reuse.)
Clients MUST follow the syntax outlined in this specification Clients MUST follow the syntax outlined in this specification
strictly. It is a syntax error to send a command with missing or strictly. It is a syntax error to send a command with missing or
extraneous spaces or arguments. extraneous spaces or arguments.
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 String quoted with an octet count (see the description of literal in
under Data Formats); in the other case, the command arguments require Section 4.3); in the other case, the command arguments require server
server feedback (see the AUTHENTICATE command). In either case, the feedback (see the AUTHENTICATE command in Section 6.2.2). In either
server sends a command continuation request response if it is ready case, the server sends a command continuation request response if it
for the octets (if appropriate) and the remainder of the command. is ready for the octets (if appropriate) and the remainder of the
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
skipping to change at page 21, line 16 skipping to change at page 21, line 16
sensitivity in non-INBOX mailbox names. Some server implementations sensitivity in non-INBOX mailbox names. Some server implementations
are fully case-sensitive in ASCII range; others preserve case of a are fully case-sensitive in ASCII range; others preserve case of a
newly-created name but otherwise are case-insensitive; and yet others newly-created name but otherwise are case-insensitive; and yet others
coerce names to a particular case. Client implementations must be coerce names to a particular case. Client implementations must be
able to interact with any of these. able to interact with any of these.
There are certain client considerations when creating a new mailbox There are certain client considerations when creating a new mailbox
name: name:
1. Any character which is one of the atom-specials (see the Formal 1. Any character which is one of the atom-specials (see the Formal
Syntax) will require that the mailbox name be represented as a Syntax in Section 9) will require that the mailbox name be
quoted string or literal. represented as a quoted string or literal.
2. CTL and other non-graphic characters are difficult to represent 2. CTL and other non-graphic characters are difficult to represent
in a user interface and are best avoided. Servers MAY refuse to in a user interface and are best avoided. Servers MAY refuse to
create mailbox names containing Unicode CTL characters. create mailbox names containing Unicode CTL characters.
3. Although the list-wildcard characters ("%" and "*") are valid in 3. Although the list-wildcard characters ("%" and "*") are valid in
a mailbox name, it is difficult to use such mailbox names with a mailbox name, it is difficult to use such mailbox names with
the LIST command due to the conflict with wildcard the LIST command due to the conflict with wildcard
interpretation. interpretation.
skipping to change at page 23, line 20 skipping to change at page 23, line 20
messages to the mailbox (e.g., new message delivery), change the messages to the mailbox (e.g., new message delivery), change the
flags of the messages in the mailbox (e.g., simultaneous access to flags of the messages in the mailbox (e.g., simultaneous access to
the same mailbox by multiple agents), or even remove messages from the same mailbox by multiple agents), or even remove messages from
the mailbox. A server MUST send mailbox size updates automatically the mailbox. A server MUST send mailbox size updates automatically
if a mailbox size change is observed during the processing of a if a mailbox size change is observed during the processing of a
command. A server SHOULD send message flag updates automatically, command. A server SHOULD send message flag updates automatically,
without requiring the client to request such updates explicitly. without requiring the client to request such updates explicitly.
Special rules exist for server notification of a client about the Special rules exist for server notification of a client about the
removal of messages to prevent synchronization errors; see the removal of messages to prevent synchronization errors; see the
description of the EXPUNGE response for more detail. In particular, description of the EXPUNGE response (Section 7.4.1) for more detail.
it is NOT permitted to send an EXISTS response that would reduce the In particular, it is NOT permitted to send an EXISTS response that
number of messages in the mailbox; only the EXPUNGE response can do would reduce the number of messages in the mailbox; only the EXPUNGE
this. response can do this.
Regardless of what implementation decisions a client makes on Regardless of what implementation decisions a client makes on
remembering data from the server, a client implementation MUST record remembering data from the server, a client implementation MUST record
mailbox size updates. It MUST NOT assume that any command after the mailbox size updates. It MUST NOT assume that any command after the
initial mailbox selection will return the size of the mailbox. initial mailbox selection will return the size of the mailbox.
5.3. Response when no Command in Progress 5.3. Response when no Command in Progress
Server implementations are permitted to send an untagged response Server implementations are permitted to send an untagged response
(except for EXPUNGE) while there is no command in progress. Server (except for EXPUNGE) while there is no command in progress. Server
skipping to change at page 23, line 46 skipping to change at page 23, line 46
size of the data does not exceed the underlying transport's available size of the data does not exceed the underlying transport's available
window size, or (2) use non-blocking writes. window size, or (2) use non-blocking writes.
5.4. Autologout Timer 5.4. Autologout Timer
If a server has an inactivity autologout timer that applies to If a server has an inactivity autologout timer that applies to
sessions after authentication, the duration of that timer MUST be at sessions after authentication, the duration of that timer MUST be at
least 30 minutes. The receipt of any command from the client during least 30 minutes. The receipt of any command from the client during
that interval resets the autologout timer. that interval resets the autologout timer.
Note that this specification doesn't have any restrictions on
autologout timer used before successful client authentication. In
particular, servers are allowed to use shorted pre-authentication
timer to protect themselves from Denial of Service attacks.
5.5. Multiple Commands in Progress (Command Pipelining) 5.5. Multiple Commands in Progress (Command Pipelining)
The client MAY send another command without waiting for the The client MAY send another command without waiting for the
completion result response of a command, subject to ambiguity rules completion result response of a command, subject to ambiguity rules
(see below) and flow control constraints on the underlying data (see below) and flow control constraints on the underlying data
stream. Similarly, a server MAY begin processing another command stream. Similarly, a server MAY begin processing another command
before processing the current command to completion, subject to before processing the current command to completion, subject to
ambiguity rules. However, any command continuation request responses ambiguity rules. However, any command continuation request responses
and command continuations MUST be negotiated before any subsequent and command continuations MUST be negotiated before any subsequent
command is initiated. command is initiated.
skipping to change at page 25, line 24 skipping to change at page 25, line 32
permitted state (for example, commands valid in authenticated and permitted state (for example, commands valid in authenticated and
selected state are listed in the authenticated state commands). selected state are listed in the authenticated state commands).
Command arguments, identified by "Arguments:" in the command Command arguments, identified by "Arguments:" in the command
descriptions below, are described by function, not by syntax. The descriptions below, are described by function, not by syntax. The
precise syntax of command arguments is described in the Formal Syntax precise syntax of command arguments is described in the Formal Syntax
(Section 9). (Section 9).
Some commands cause specific server responses to be returned; these Some commands cause specific server responses to be returned; these
are identified by "Responses:" in the command descriptions below. are identified by "Responses:" in the command descriptions below.
See the response descriptions in the Responses section for See the response descriptions in the Responses section (Section 7)
information on these responses, and the Formal Syntax section for the for information on these responses, and the Formal Syntax (Section 9)
precise syntax of these responses. It is possible for server data to for the precise syntax of these responses. It is possible for server
be transmitted as a result of any command. Thus, commands that do data to be transmitted as a result of any command. Thus, commands
not specifically require server data specify "no specific responses that do not specifically require server data specify "no specific
for this command" instead of "none". responses for this command" instead of "none".
The "Result:" in the command description refers to the possible The "Result:" in the command description refers to the possible
tagged status responses to a command, and any special interpretation tagged status responses to a command, and any special interpretation
of these status responses. of these status responses.
The state of a connection is only changed by successful commands The state of a connection is only changed by successful commands
which are documented as changing state. A rejected command (BAD which are documented as changing state. A rejected command (BAD
response) never changes the state of the connection or of the response) never changes the state of the connection or of the
selected mailbox. A failed command (NO response) generally does not selected mailbox. A failed command (NO response) generally does not
change the state of the connection or of the selected mailbox; the change the state of the connection or of the selected mailbox; the
skipping to change at page 26, line 4 skipping to change at page 26, line 15
6.1. Client Commands - Any State 6.1. Client Commands - Any State
The following commands are valid in any state: CAPABILITY, NOOP, and The following commands are valid in any state: CAPABILITY, NOOP, and
LOGOUT. LOGOUT.
6.1.1. CAPABILITY Command 6.1.1. CAPABILITY Command
Arguments: none Arguments: none
Responses: REQUIRED untagged response: CAPABILITY Responses: REQUIRED untagged response: CAPABILITY
Result: OK - capability completed Result: OK - capability completed
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
The CAPABILITY command requests a listing of capabilities that the The CAPABILITY command requests a listing of capabilities (e.g.
server supports. The server MUST send a single untagged CAPABILITY extensions and/or modifications of server behaviour) that the server
response with "IMAP4rev2" as one of the listed capabilities before supports. The server MUST send a single untagged CAPABILITY response
the (tagged) OK response. with "IMAP4rev2" as one of the listed capabilities before the
(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. All such names supports that particular authentication mechanism as defined in
are, by definition, part of this specification. For example, the [SASL]. All such names are, by definition, part of this
authorization capability for an experimental "blurdybloop" specification.
authenticator would be "AUTH=XBLURDYBLOOP" and not
"XAUTH=BLURDYBLOOP" or "XAUTH=XBLURDYBLOOP".
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 for additional information. No capabilities, beyond the response in Section 7.2.2 for additional information. No
base IMAP4rev2 set defined in this specification, are enabled without capabilities, beyond the base IMAP4rev2 set defined in this
explicit client action to invoke the capability. specification, 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,
LOGINDISABLED, and AUTH=PLAIN (described in [PLAIN]) capabilities. LOGINDISABLED, and AUTH=PLAIN (described in [PLAIN]) capabilities.
See the Security Considerations section for important information. See the Security Considerations (Section 11) for 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.
See the section entitled "Client Commands - Experimental/Expansion"
for information about the form of site or implementation-specific
capabilities.
Example: C: abcd CAPABILITY Example: C: abcd CAPABILITY
S: * CAPABILITY IMAP4rev2 STARTTLS AUTH=GSSAPI S: * CAPABILITY IMAP4rev2 STARTTLS AUTH=GSSAPI
LOGINDISABLED LOGINDISABLED
S: abcd OK CAPABILITY completed S: abcd OK CAPABILITY completed
C: efgh STARTTLS C: efgh STARTTLS
S: efgh OK STARTLS completed S: efgh OK STARTLS completed
<TLS negotiation, further commands are under [TLS] layer> <TLS negotiation, further commands are under [TLS] layer>
C: ijkl CAPABILITY C: ijkl CAPABILITY
S: * CAPABILITY IMAP4rev2 AUTH=GSSAPI AUTH=PLAIN S: * CAPABILITY IMAP4rev2 AUTH=GSSAPI AUTH=PLAIN
S: ijkl OK CAPABILITY completed S: ijkl OK CAPABILITY completed
6.1.2. NOOP Command 6.1.2. NOOP Command
skipping to change at page 28, line 23 skipping to change at page 28, line 42
case, a password is required although the server may choose to accept case, a password is required although the server may choose to accept
any password. The restrictions placed on anonymous users are any password. The restrictions placed on anonymous users are
implementation-dependent. implementation-dependent.
Once authenticated (including as anonymous), it is not possible to Once authenticated (including as anonymous), it is not possible to
re-enter not authenticated state. re-enter not authenticated state.
In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
the following commands are valid in the not authenticated state: the following commands are valid in the not authenticated state:
STARTTLS, AUTHENTICATE and LOGIN. See the Security Considerations STARTTLS, AUTHENTICATE and LOGIN. See the Security Considerations
section for important information about these commands. (Section 11) for important information about these commands.
6.2.1. STARTTLS Command 6.2.1. STARTTLS Command
Arguments: none Arguments: none
Responses: no specific response for this command Responses: no specific response for this command
Result: OK - starttls completed, begin TLS negotiation Result: OK - starttls completed, begin TLS negotiation
BAD - STARTTLS received after a successful TLS BAD - STARTTLS received after a successful TLS
negotiation or arguments invalid negotiation or arguments invalid
skipping to change at page 35, line 13 skipping to change at page 35, line 13
"a" or "b". "a" or "b".
There are no limitations on pipelining ENABLE. For example, it is There are no limitations on pipelining ENABLE. For example, it is
possible to send ENABLE and then immediately SELECT, or a LOGIN possible to send ENABLE and then immediately SELECT, or a LOGIN
immediately followed by ENABLE. immediately followed by ENABLE.
The server MUST NOT change the CAPABILITY list as a result of The server MUST NOT change the CAPABILITY list as a result of
executing ENABLE; i.e., a CAPABILITY command issued right after an executing ENABLE; i.e., a CAPABILITY command issued right after an
ENABLE command MUST list the same capabilities as a CAPABILITY ENABLE command MUST list the same capabilities as a CAPABILITY
command issued before the ENABLE command. This is demonstrated in command issued before the ENABLE command. This is demonstrated in
the following example: the following example. Note that below "X-GOOD-IDEA" is a fictitious
extension capability that can be ENABLEd.
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
skipping to change at page 36, line 15 skipping to change at page 36, line 16
The SELECT command selects a mailbox so that messages in the mailbox The SELECT command selects a mailbox so that messages in the mailbox
can be accessed. Before returning an OK to the client, the server can be accessed. Before returning an OK to the client, the server
MUST send the following untagged data to the client. (The order of MUST send the following untagged data to the client. (The order of
individual responses is not important.) Note that earlier versions individual responses is not important.) Note that earlier versions
of this protocol (e.g. IMAP2bis) only required the FLAGS and EXISTS of this protocol (e.g. IMAP2bis) only required the FLAGS and EXISTS
untagged data; consequently, client implementations SHOULD implement untagged data; consequently, client implementations SHOULD implement
default behavior for missing data as discussed with the individual default behavior for missing data as discussed with the individual
item. item.
FLAGS Defined flags in the mailbox. See the description of the FLAGS Defined flags in the mailbox. See the description of the
FLAGS response for more detail. FLAGS response in Section 7.2.7 for more detail.
<n> EXISTS The number of messages in the mailbox. See the <n> EXISTS The number of messages in the mailbox. See the
description of the EXISTS response for more detail. description of the EXISTS response in Section 7.3.1 for more
detail.
LIST The server MUST return a LIST response with the mailbox name. LIST The server MUST return a LIST response with the mailbox name.
If the server allows de-normalized UTF-8 mailbox names (see If the server allows de-normalized UTF-8 mailbox names (see
Section 5.1) and the supplied mailbox name differs from the Section 5.1) and the supplied mailbox name differs from the
normalized version, the server MUST return LIST with the OLDNAME normalized version, the server MUST return LIST with the OLDNAME
extended data item. See Section 6.3.9.7 for more details. extended data item. See Section 6.3.9.7 for more details.
OK [PERMANENTFLAGS (<list of flags>)] A list of message flags that OK [PERMANENTFLAGS (<list of flags>)] A list of message flags that
the client can change permanently. If this is missing, the client the client can change permanently. If this is missing, the client
should assume that all flags can be changed permanently. should assume that all flags can be changed permanently.
skipping to change at page 39, line 25 skipping to change at page 39, line 28
the name, the server SHOULD create any superior hierarchical names the name, the server SHOULD create any superior hierarchical names
that are needed for the CREATE command to be successfully completed. that are needed for the CREATE command to be successfully completed.
In other words, an attempt to create "foo/bar/zap" on a server in In other words, an attempt to create "foo/bar/zap" on a server in
which "/" is the hierarchy separator character SHOULD create foo/ and which "/" is the hierarchy separator character SHOULD create foo/ and
foo/bar/ if they do not already exist. foo/bar/ if they do not already exist.
If a new mailbox is created with the same name as a mailbox which was If a new mailbox is created with the same name as a mailbox which was
deleted, its unique identifiers MUST be greater than any unique deleted, its unique identifiers MUST be greater than any unique
identifiers used in the previous incarnation of the mailbox unless identifiers used in the previous incarnation of the mailbox unless
the new incarnation has a different unique identifier validity value. the new incarnation has a different unique identifier validity value.
See the description of the UID command for more detail. See the description of the UID command in Section 6.4.9 for more
detail.
Example: C: A003 CREATE owatagusiam/ Example: C: A003 CREATE owatagusiam/
S: A003 OK CREATE completed S: A003 OK CREATE completed
C: A004 CREATE owatagusiam/blurdybloop C: A004 CREATE owatagusiam/blurdybloop
S: A004 OK CREATE completed S: A004 OK CREATE completed
C: A005 CREATE NonNormalized C: A005 CREATE NonNormalized
S: * LIST () "/" "Normalized" ("OLDNAME" ("NonNormalized")) S: * LIST () "/" "Normalized" ("OLDNAME" ("NonNormalized"))
S: A005 OK CREATE completed S: A005 OK CREATE completed
(in the last example imagine that "NonNormalized" is (in the last example imagine that "NonNormalized" is
skipping to change at page 40, line 17 skipping to change at page 40, line 25
The DELETE command permanently removes the mailbox with the given The DELETE command permanently removes the mailbox with the given
name. A tagged OK response is returned only if the mailbox has been name. A tagged OK response is returned only if the mailbox has been
deleted. It is an error to attempt to delete INBOX or a mailbox name deleted. It is an error to attempt to delete INBOX or a mailbox name
that does not exist. that does not exist.
The DELETE command MUST NOT remove inferior hierarchical names. For The DELETE command MUST NOT remove inferior hierarchical names. For
example, if a mailbox "foo" has an inferior "foo.bar" (assuming "." example, if a mailbox "foo" has an inferior "foo.bar" (assuming "."
is the hierarchy delimiter character), removing "foo" MUST NOT remove is the hierarchy delimiter character), removing "foo" MUST NOT remove
"foo.bar". It is an error to attempt to delete a name that has "foo.bar". It is an error to attempt to delete a name that has
inferior hierarchical names and also has the \Noselect mailbox name inferior hierarchical names and also has the \Noselect mailbox name
attribute (see the description of the LIST response for more attribute (see the description of the LIST response (Section 7.2.3)
details). for more details).
It is permitted to delete a name that has inferior hierarchical names It is permitted to delete a name that has inferior hierarchical names
and does not have the \Noselect mailbox name attribute. If the and does not have the \Noselect mailbox name attribute. If the
server implementation does not permit deleting the name while server implementation does not permit deleting the name while
inferior hierarchical names exists then it SHOULD disallow the DELETE inferior hierarchical names exists then it SHOULD disallow the DELETE
command by returning a tagged NO response. The NO response SHOULD command by returning a tagged NO response. The NO response SHOULD
include the HASCHILDREN response code. Alternatively the server MAY include the HASCHILDREN response code. Alternatively the server MAY
allow the DELETE command, but sets the \Noselect mailbox name allow the DELETE command, but sets the \Noselect mailbox name
attribute for that name. attribute for that name.
If the server returns OK response, all messages in that mailbox are If the server returns OK response, all messages in that mailbox are
removed by the DELETE command. removed by the DELETE command.
The value of the highest-used unique identifier of the deleted The value of the highest-used unique identifier of the deleted
mailbox MUST be preserved so that a new mailbox created with the same mailbox MUST be preserved so that a new mailbox created with the same
name will not reuse the identifiers of the former incarnation, unless name will not reuse the identifiers of the former incarnation, unless
the new incarnation has a different unique identifier validity value. the new incarnation has a different unique identifier validity value.
See the description of the UID command for more detail. See the description of the UID command in Section 6.4.9 for more
detail.
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 "" * Examples: C: A682 LIST "" *
S: * LIST () "/" blurdybloop S: * LIST () "/" blurdybloop
S: * LIST (\Noselect) "/" foo S: * LIST (\Noselect) "/" foo
S: * LIST () "/" foo/bar S: * LIST () "/" foo/bar
S: A682 OK LIST completed S: A682 OK LIST completed
C: A683 DELETE blurdybloop C: A683 DELETE blurdybloop
skipping to change at page 42, line 24 skipping to change at page 42, line 28
needed for the RENAME command to complete successfully. In other needed for the RENAME command to complete successfully. In other
words, an attempt to rename "foo/bar/zap" to baz/rag/zowie on a words, an attempt to rename "foo/bar/zap" to baz/rag/zowie on a
server in which "/" is the hierarchy separator character in the server in which "/" is the hierarchy separator character in the
corresponding namespace SHOULD create baz/ and baz/rag/ if they do corresponding namespace SHOULD create baz/ and baz/rag/ if they do
not already exist. not already exist.
The value of the highest-used unique identifier of the old mailbox The value of the highest-used unique identifier of the old mailbox
name MUST be preserved so that a new mailbox created with the same name MUST be preserved so that a new mailbox created with the same
name will not reuse the identifiers of the former incarnation, unless name will not reuse the identifiers of the former incarnation, unless
the new incarnation has a different unique identifier validity value. the new incarnation has a different unique identifier validity value.
See the description of the UID command for more detail. See the description of the UID command in Section 6.4.9 for more
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
disallow renaming INBOX by returning a tagged NO response, so clients disallow renaming INBOX by returning a tagged NO response, so clients
need to be able to handle such RENAME failing). It moves all need to be able to handle such RENAME failing). It moves all
messages in INBOX to a new mailbox with the given name, leaving INBOX messages in INBOX to a new mailbox with the given name, leaving INBOX
empty. If the server implementation supports inferior hierarchical empty. If the server implementation supports inferior hierarchical
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
skipping to change at page 45, line 17 skipping to change at page 45, line 24
Responses: untagged responses: LIST Responses: untagged responses: LIST
Result: OK - list completed Result: OK - list completed
NO - list failure: can't list that reference or mailbox NO - list failure: can't list that reference or mailbox
name name
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
The LIST command returns a subset of mailbox names from the complete The LIST command returns a subset of mailbox names from the complete
set of all mailbox names available to the client. Zero or more set of all mailbox names available to the client. Zero or more
untagged LIST replies are returned, containing the name attributes, untagged LIST responses are returned, containing the name attributes,
hierarchy delimiter, name, and possible extension information; see hierarchy delimiter, name, and possible extension information; see
the description of the LIST reply for more detail. the description of the LIST response (Section 7.2.3) for more detail.
The LIST command SHOULD return its data quickly, without undue delay. The LIST command SHOULD return its data quickly, without undue delay.
For example, it SHOULD NOT go to excess trouble to calculate the For example, it SHOULD NOT go to excess trouble to calculate the
\Marked or \Unmarked status or perform other processing; if each name \Marked or \Unmarked status or perform other processing; if each name
requires 1 second of processing, then a list of 1200 names would take requires 1 second of processing, then a list of 1200 names would take
20 minutes! 20 minutes!
The extended LIST command, originally introduced in [RFC5258], The extended LIST command, originally introduced in [RFC5258],
provides capabilities beyond that of the original IMAP LIST command. provides capabilities beyond that of the original IMAP LIST command.
The extended syntax is being used if one or more of the following The extended syntax is being used if one or more of the following
skipping to change at page 47, line 40 skipping to change at page 47, line 44
like "/u2/users/smith/Mail", or it would be impossible like "/u2/users/smith/Mail", or it would be impossible
for the client to determine that the interpretation was for the client to determine that the interpretation was
in the context of the reference. in the context of the reference.
The character "*" is a wildcard, and matches zero or more characters The character "*" is a wildcard, and matches zero or more characters
at this position. The character "%" is similar to "*", but it does at this position. The character "%" is similar to "*", but it does
not match a hierarchy delimiter. If the "%" wildcard is the last not match a hierarchy delimiter. If the "%" wildcard is the last
character of a mailbox name argument, matching levels of hierarchy character of a mailbox name argument, matching levels of hierarchy
are also returned. If these levels of hierarchy are not also are also returned. If these levels of hierarchy are not also
selectable mailboxes, they are returned with the \Noselect mailbox selectable mailboxes, they are returned with the \Noselect mailbox
name attribute (see the description of the LIST response for more name attribute (see the description of the LIST response
details). (Section 7.2.3) for more details).
Any syntactically valid pattern that is not accepted by a server for Any syntactically valid pattern that is not accepted by a server for
any reason MUST be silently ignored. I.e. it results in no LIST any reason MUST be silently ignored. I.e. it results in no LIST
responses and the LIST command still returns tagged OK response. responses and the LIST command still returns tagged OK response.
Selection options tell the server to limit the mailbox names that are Selection options tell the server to limit the mailbox names that are
selected by the LIST operation. If selection options are used, the selected by the LIST operation. If selection options are used, the
mailboxes returned are those that match both the list of canonical mailboxes returned are those that match both the list of canonical
LIST patterns and the selection options. Unless a particular LIST patterns and the selection options. Unless a particular
selection option provides special rules, the selection options are selection option provides special rules, the selection options are
skipping to change at page 50, line 33 skipping to change at page 50, line 36
The return options defined in this specification are as follows: The return options defined in this specification are as follows:
SUBSCRIBED - causes the LIST command to return subscription state SUBSCRIBED - causes the LIST command to return subscription state
for all matching mailbox names. The "\Subscribed" attribute MUST for all matching mailbox names. The "\Subscribed" attribute MUST
be supported and MUST be accurately computed when the SUBSCRIBED be supported and MUST be accurately computed when the SUBSCRIBED
return option is specified. Further, all mailbox flags MUST be return option is specified. Further, all mailbox flags MUST be
accurately computed (this differs from the behavior of the accurately computed (this differs from the behavior of the
obsolete LSUB command from IMAP4rev1). obsolete LSUB command from IMAP4rev1).
CHILDREN - requests mailbox child information as originally proposed CHILDREN - requests mailbox child information as originally proposed
in [RFC3348]. See Section 6.3.9.5, below, for details. This in [RFC3348]. See Section 6.3.9.5, below, for details.
option MUST be supported by all servers.
STATUS - requests STATUS response for each matching mailbox. STATUS - requests STATUS response for each matching mailbox.
This option takes STATUS data items as parameters. For each This option takes STATUS data items as parameters. For each
selectable mailbox matching the list pattern and selection selectable mailbox matching the list pattern and selection
options, the server MUST return an untagged LIST response options, the server MUST return an untagged LIST response
followed by an untagged STATUS response containing the followed by an untagged STATUS response containing the
information requested in the STATUS return option, except for information requested in the STATUS return option, except for
some cases described below. some cases described below.
skipping to change at page 75, line 29 skipping to change at page 75, line 29
for each message that is removed. for each message that is removed.
Example: C: A202 EXPUNGE Example: C: A202 EXPUNGE
S: * 3 EXPUNGE S: * 3 EXPUNGE
S: * 3 EXPUNGE S: * 3 EXPUNGE
S: * 5 EXPUNGE S: * 5 EXPUNGE
S: * 8 EXPUNGE S: * 8 EXPUNGE
S: A202 OK EXPUNGE completed S: A202 OK EXPUNGE completed
Note: In this example, messages 3, 4, 7, and 11 had the \Deleted flag Note: In this example, messages 3, 4, 7, and 11 had the \Deleted flag
set. See the description of the EXPUNGE response for further set. See the description of the EXPUNGE response (Section 7.4.1) for
explanation. further explanation.
6.4.4. SEARCH Command 6.4.4. SEARCH Command
Arguments: OPTIONAL result specifier Arguments: OPTIONAL result specifier
OPTIONAL [CHARSET] specification OPTIONAL [CHARSET] specification
searching criteria (one or more) searching criteria (one or more)
Responses: OPTIONAL untagged response: ESEARCH Responses: OPTIONAL untagged response: ESEARCH
Result: OK - search completed Result: OK - search completed
skipping to change at page 76, line 7 skipping to change at page 76, line 7
given searching criteria. given searching criteria.
The SEARCH command may contain result options. Result options The SEARCH command may contain result options. Result options
control what kind of information is returned about messages matching control what kind of information is returned about messages matching
the search criteria in an untagged ESEARCH response. If no result the search criteria in an untagged ESEARCH response. If no result
option is specified or empty list of options is specified "()", ALL option is specified or empty list of options is specified "()", ALL
is assumed (see below). The order of individual options is is assumed (see below). The order of individual options is
arbitrary. Individual options may contain parameters enclosed in arbitrary. Individual options may contain parameters enclosed in
parentheses. (However, if an option has a mandatory parameter, which parentheses. (However, if an option has a mandatory parameter, which
can always be represented as a number or a sequence-set, the option can always be represented as a number or a sequence-set, the option
parameter does not need the enclosing parentheses. See the ABNF for parameter does not need the enclosing parentheses. See the Formal
more details). If an option has parameters, they consist of atoms Syntax (Section 9) for more details). If an option has parameters,
and/or strings and/or lists in a specific order. Any options not they consist of atoms and/or strings and/or lists in a specific
defined by extensions that the server supports MUST be rejected with order. Any options not defined by extensions that the server
a BAD response. supports MUST be rejected with a BAD response.
This document specifies the following result options: This document specifies the following result options:
MIN MIN
Return the lowest message number/UID that satisfies the SEARCH Return the lowest message number/UID that satisfies the SEARCH
criteria. criteria.
If the SEARCH results in no matches, the server MUST NOT If the SEARCH results in no matches, the server MUST NOT
include the MIN result option in the ESEARCH response; however, include the MIN result option in the ESEARCH response; however,
skipping to change at page 88, line 9 skipping to change at page 88, line 9
Responses: untagged responses: FETCH Responses: untagged responses: FETCH
Result: OK - fetch completed Result: OK - fetch completed
NO - fetch error: can't fetch that data NO - fetch error: can't fetch that data
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
The FETCH command retrieves data associated with a message in the The FETCH command retrieves data associated with a message in the
mailbox. The data items to be fetched can be either a single atom or mailbox. The data items to be fetched can be either a single atom or
a parenthesized list. a parenthesized list.
Most data items, identified in the formal syntax under the msg-att- Most data items, identified in the formal syntax (Section 9) under
static rule, are static and MUST NOT change for any particular the msg-att-static rule, are static and MUST NOT change for any
message. Other data items, identified in the formal syntax under the particular message. Other data items, identified in the formal
msg-att-dynamic rule, MAY change, either as a result of a STORE syntax under the msg-att-dynamic rule, MAY change, either as a result
command or due to external events. of a STORE command or due to external events.
For example, if a client receives an ENVELOPE for a message when For example, if a client receives an ENVELOPE for a message when
it already knows the envelope, it can safely ignore the newly it already knows the envelope, it can safely ignore the newly
transmitted envelope. transmitted envelope.
There are three macros which specify commonly-used sets of data There are three macros which specify commonly-used sets of data
items, and can be used instead of data items. A macro must be used items, and can be used instead of data items. A macro must be used
by itself, and not in conjunction with other macros or data items. by itself, and not in conjunction with other macros or data items.
ALL Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE) ALL Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)
skipping to change at page 97, line 46 skipping to change at page 97, line 46
commands as well. commands as well.
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
6.5.1. X<atom> Command Each command which is not part of this specification MUST have at
least one capability name (see Section 6.1.1) associated with it.
Arguments: implementation defined (Multiple commands can be associated with the same capability name)
Responses: implementation defined
Result: OK - command completed
NO - failure
BAD - command unknown or arguments invalid
Any command prefixed with an X is an experimental command. Commands Server implementations MUST NOT send any added (not specified in this
which are not part of this specification, a standard or standards- specification) untagged responses, unless the client requested it by
track revision of this specification, or an IESG-approved issuing the associated experimental command or the ENABLE command
experimental protocol, MUST use the X prefix. (Section 6.3.1).
Any added untagged responses issued by an experimental command MUST The following example demonstrates how a client can check for
also be prefixed with an X. Server implementations MUST NOT send any presence of a fictitious XPIG-LATIN capability that adds the XPIG-
such untagged responses, unless the client requested it by issuing LATIN command and the the XPIG-LATIN untagged response. (Note that
the associated experimental command. for an extension the command name and the capability name don't have
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
C: A442 XPIG-LATIN C: A442 XPIG-LATIN
S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay
S: A442 OK XPIG-LATIN ompleted-cay S: A442 OK XPIG-LATIN ompleted-cay
7. Server Responses 7. Server Responses
Server responses are in three forms: status responses, server data, Server responses are in three forms: status responses, server data,
and command continuation request. The information contained in a and command continuation request. The information contained in a
server response, identified by "Contents:" in the response server response, identified by "Contents:" in the response
descriptions below, is described by function, not by syntax. The descriptions below, is described by function, not by syntax. The
precise syntax of server responses is described in the Formal Syntax precise syntax of server responses is described in the Formal Syntax
section. (Section 9).
The client MUST be prepared to accept any response at all times. The client MUST be prepared to accept any response at all times.
Status responses can be tagged or untagged. Tagged status responses Status responses can be tagged or untagged. Tagged status responses
indicate the completion result (OK, NO, or BAD status) of a client indicate the completion result (OK, NO, or BAD status) of a client
command, and have a tag matching the command. command, and have a tag matching the command.
Some status responses, and all server data, are untagged. An Some status responses, and all server data, are untagged. An
untagged response is indicated by the token "*" instead of a tag. untagged response is indicated by the token "*" instead of a tag.
Untagged status responses indicate server greeting, or server status Untagged status responses indicate server greeting, or server status
skipping to change at page 110, line 12 skipping to change at page 110, line 4
status data are transmitted from the server to the client. Many of status data are transmitted from the server to the client. Many of
these responses typically result from a command with the same name. these responses typically result from a command with the same name.
7.2.1. The ENABLED Response 7.2.1. The 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.
7.2.2. CAPABILITY Response 7.2.2. CAPABILITY Response
Contents: capability listing Contents: capability listing
The CAPABILITY response occurs as a result of a CAPABILITY command. The CAPABILITY response occurs as a result of a CAPABILITY command.
The capability listing contains a space-separated listing of The capability listing contains a space-separated listing of
capability names that the server supports. The capability listing capability names that the server supports. The capability listing
MUST include the atom "IMAP4rev2". MUST include the atom "IMAP4rev2", but note that it doesn't have to
be the first capability listed.
In addition, client and server implementations MUST implement the In addition, client and server implementations MUST implement the
STARTTLS, LOGINDISABLED, and AUTH=PLAIN (described in [PLAIN]) "STARTTLS", "LOGINDISABLED", and "AUTH=PLAIN" (described in [PLAIN])
capabilities. See the Security Considerations section for important capabilities. See the Security Considerations (Section 11) for
information. important information related to these capabilities.
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. 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. Server
responses MUST conform to this document until the client issues a responses MUST conform to this document until the client issues a
command that uses the associated capability. command that uses the associated capability.
Capability names MUST either begin with "X" or be informational, Capability names SHOULD be registered with IANA using RFC Required
experimental or standards-track IMAP4rev2 extensions, revisions, or policy. A server SHOULD NOT offer unregistered capability names.
amendments registered with IANA. A server SHOULD NOT offer
unregistered or non-standard capability names, unless such names are
prefixed with an "X".
Client implementations SHOULD NOT require any capability name other Client implementations SHOULD NOT require any capability name other
than "IMAP4rev2", and MUST ignore any unknown capability names. than "IMAP4rev2", "STARTTLS", "LOGINDISABLED". Client
implementations MUST ignore any unknown capability names.
A server MAY send capabilities automatically, by using the CAPABILITY A server MAY send capabilities automatically, by using the CAPABILITY
response code in the initial PREAUTH or OK responses, and by sending response code in the initial PREAUTH or OK responses, and by sending
an updated CAPABILITY response code in the tagged OK response as part an updated CAPABILITY response code in the tagged OK response as part
of a successful authentication. It is unnecessary for a client to of a successful authentication. It is unnecessary for a client to
send a separate CAPABILITY command if it recognizes these automatic send a separate CAPABILITY command if it recognizes these automatic
capabilities. capabilities.
Example: S: * CAPABILITY IMAP4rev2 STARTTLS AUTH=GSSAPI XPIG-LATIN Example: S: * CAPABILITY IMAP4rev2 STARTTLS AUTH=GSSAPI XPIG-LATIN
skipping to change at page 146, line 41 skipping to change at page 146, line 41
IANA is requested to update the "imap" service name previously IANA is requested to update the "imap" service name previously
registered in RFC 3501, to point to this document. registered in RFC 3501, to point to this document.
12.3. LIST Selection Options, LIST Return Options, LIST extended data 12.3. LIST Selection Options, LIST Return Options, LIST extended data
items items
[RFC5258] specifies IANA registration procedures for LIST Selection [RFC5258] specifies IANA registration procedures for LIST Selection
Options, LIST Return Options, LIST extended data items. This Options, LIST Return Options, LIST extended data items. This
document doesn't change these registration procedures. In particular document doesn't change these registration procedures. In particular
LIST selection options Section 6.3.9.1 and LIST return options LIST selection options (Section 6.3.9.1) and LIST return options
Section 6.3.9.2 are registered using the procedure specified in (Section 6.3.9.2) are registered using the procedure specified in
Section 9 of [RFC5258] (and using the registration template from Section 9 of [RFC5258] (and using the registration template from
Section 9.3 of [RFC5258]). LIST Extended Data Items are registered Section 9.3 of [RFC5258]). LIST Extended Data Items are registered
using the registration template from Section 9.6 of [RFC5258]). using the registration template from Section 9.6 of [RFC5258]).
IANA is requested to add a reference to [RFCXXXX] for the "OLDNAME" IANA is requested to add a reference to [RFCXXXX] for the "OLDNAME"
LIST-EXTENDED extended data item entry. This is in addition to the LIST-EXTENDED extended data item entry. This is in addition to the
existing reference to [RFC5465]. existing reference to [RFC5465].
13. References 13. References
skipping to change at page 157, line 27 skipping to change at page 157, line 27
22. After ENABLE IMAP4rev2 human readable response text can include 22. After ENABLE IMAP4rev2 human readable response text can include
non ASCII encoded in UTF-8. non ASCII encoded in UTF-8.
23. Updated to use modern TLS-related recommendations as per RFC 23. Updated to use modern TLS-related recommendations as per RFC
8314, RFC 7817, RFC 7525. 8314, RFC 7817, RFC 7525.
24. Replaced DIGEST-MD5 SASL mechanism with SCRAM-SHA-256. DIGEST- 24. Replaced DIGEST-MD5 SASL mechanism with SCRAM-SHA-256. DIGEST-
MD5 was deprecated. MD5 was deprecated.
25. Clarified that any command received from the client resets
server autologout timer.
26. Revised IANA registration procedure for IMAP extensions and
removed "X" convention.
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. Why they significantly reduce bandwidth and/or client and servers. Why 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.
skipping to change at page 159, line 5 skipping to change at page 159, line 14
ALERT (response code) 99 ALERT (response code) 99
ALL (fetch item) 88 ALL (fetch item) 88
ALL (search key) 78 ALL (search key) 78
ALL (search result option) 76 ALL (search result option) 76
ALREADYEXISTS (response code) 99 ALREADYEXISTS (response code) 99
ANSWERED (search key) 78 ANSWERED (search key) 78
APPEND (command) 68 APPEND (command) 68
APPENDUID (response code) 100 APPENDUID (response code) 100
AUTHENTICATE (command) 29 AUTHENTICATE (command) 29
AUTHENTICATIONFAILED (response code) 100 AUTHENTICATIONFAILED (response code) 100
AUTHORIZATIONFAILED (response code) 101 AUTHORIZATIONFAILED (response code) 100
B B
BAD (response) 108 BAD (response) 108
BADCHARSET (response code) 101 BADCHARSET (response code) 101
BCC <string> (search key) 78 BCC <string> (search key) 78
BEFORE <date> (search key) 78 BEFORE <date> (search key) 78
BINARY.PEEK[<section-binary>]<<partial>> (fetch item) 88 BINARY.PEEK[<section-binary>]<<partial>> (fetch item) 88
BINARY.SIZE[<section-binary>] (fetch item) 89 BINARY.SIZE[<section-binary>] (fetch item) 89
BINARY.SIZE[<section-binary>] (fetch result) 118 BINARY.SIZE[<section-binary>] (fetch result) 118
BINARY[<section-binary>]<<number>> (fetch result) 118 BINARY[<section-binary>]<<number>> (fetch result) 118
BINARY[<section-binary>]<<partial>> (fetch item) 88 BINARY[<section-binary>]<<partial>> (fetch item) 88
BODY (fetch item) 89 BODY (fetch item) 89
BODY (fetch result) 119 BODY (fetch result) 118
BODY <string> (search key) 78 BODY <string> (search key) 78
BODY.PEEK[<section>]<<partial>> (fetch item) 89 BODY.PEEK[<section>]<<partial>> (fetch item) 89
BODYSTRUCTURE (fetch item) 90 BODYSTRUCTURE (fetch item) 90
BODYSTRUCTURE (fetch result) 119 BODYSTRUCTURE (fetch result) 119
BODY[<section>]<<origin octet>> (fetch result) 119 BODY[<section>]<<origin octet>> (fetch result) 118
BODY[<section>]<<partial>> (fetch item) 89 BODY[<section>]<<partial>> (fetch item) 89
BYE (response) 109 BYE (response) 109
Body Structure (message attribute) 14 Body Structure (message attribute) 14
C C
CANNOT (response code) 101 CANNOT (response code) 101
CAPABILITY (command) 25 CAPABILITY (command) 26
CAPABILITY (response code) 101 CAPABILITY (response code) 101
CAPABILITY (response) 110 CAPABILITY (response) 110
CC <string> (search key) 78 CC <string> (search key) 78
CLIENTBUG (response code) 101 CLIENTBUG (response code) 101
CLOSE (command) 74 CLOSE (command) 74
CLOSED (response code) 102 CLOSED (response code) 102
CONTACTADMIN (response code) 102 CONTACTADMIN (response code) 102
COPY (command) 93 COPY (command) 93
COPYUID (response code) 102 COPYUID (response code) 102
CORRUPTION (response code) 103 CORRUPTION (response code) 103
COUNT (search result option) 76 COUNT (search result option) 76
CREATE (command) 38 CREATE (command) 38
D D
DELETE (command) 39 DELETE (command) 40
DELETED (search key) 78 DELETED (search key) 78
DELETED (status item) 68 DELETED (status item) 68
DRAFT (search key) 78 DRAFT (search key) 78
E E
ENABLE (command) 33 ENABLE (command) 33
ENVELOPE (fetch item) 90 ENVELOPE (fetch item) 90
ENVELOPE (fetch result) 122 ENVELOPE (fetch result) 122
ESEARCH (response) 115 ESEARCH (response) 115
EXAMINE (command) 37 EXAMINE (command) 37
EXPIRED (response code) 103 EXPIRED (response code) 103
EXPUNGE (command) 75 EXPUNGE (command) 75
EXPUNGE (response) 117 EXPUNGE (response) 117
EXPUNGEISSUED (response code) 103 EXPUNGEISSUED (response code) 103
Envelope Structure (message attribute) 14 Envelope Structure (message attribute) 14
F F
FAST (fetch item) 88 FAST (fetch item) 88
FETCH (command) 87 FETCH (command) 87
FETCH (response) 118 FETCH (response) 117
FLAGGED (search key) 78 FLAGGED (search key) 78
FLAGS (fetch item) 90 FLAGS (fetch item) 90
FLAGS (fetch result) 123 FLAGS (fetch result) 123
FLAGS (response) 116 FLAGS (response) 116
FLAGS <flag list> (store command data item) 92 FLAGS <flag list> (store command data item) 92
FLAGS.SILENT <flag list> (store command data item) 92 FLAGS.SILENT <flag list> (store command data item) 92
FROM <string> (search key) 78 FROM <string> (search key) 78
FULL (fetch item) 88 FULL (fetch item) 88
Flags (message attribute) 11 Flags (message attribute) 11
skipping to change at page 160, line 39 skipping to change at page 160, line 48
HASCHILDREN (response code) 103 HASCHILDREN (response code) 103
HEADER (part specifier) 90 HEADER (part specifier) 90
HEADER <field-name> <string> (search key) 79 HEADER <field-name> <string> (search key) 79
HEADER.FIELDS (part specifier) 90 HEADER.FIELDS (part specifier) 90
HEADER.FIELDS.NOT (part specifier) 90 HEADER.FIELDS.NOT (part specifier) 90
I I
IDLE (command) 71 IDLE (command) 71
INTERNALDATE (fetch item) 90 INTERNALDATE (fetch item) 90
INTERNALDATE (fetch result) 123 INTERNALDATE (fetch result) 123
INUSE (response code) 104 INUSE (response code) 103
Internal Date (message attribute) 13 Internal Date (message attribute) 13
K K
KEYWORD <flag> (search key) 79 KEYWORD <flag> (search key) 79
Keyword (type of flag) 12 Keyword (type of flag) 12
L L
LARGER <n> (search key) 79 LARGER <n> (search key) 79
LIMIT (response code) 104 LIMIT (response code) 104
LIST (command) 44 LIST (command) 45
LIST (response) 111 LIST (response) 111
LOGOUT (command) 27 LOGOUT (command) 27
M M
MAX (search result option) 76 MAX (search result option) 76
MAY (specification requirement term) 5 MAY (specification requirement term) 5
MESSAGES (status item) 68 MESSAGES (status item) 68
MIME (part specifier) 91 MIME (part specifier) 91
MIN (search result option) 76 MIN (search result option) 76
MOVE (command) 94 MOVE (command) 94
MUST (specification requirement term) 5 MUST (specification requirement term) 5
MUST NOT (specification requirement term) 5 MUST NOT (specification requirement term) 5
Message Sequence Number (message attribute) 11 Message Sequence Number (message attribute) 11
N N
NAMESPACE (command) 63 NAMESPACE (command) 63
NAMESPACE (response) 115 NAMESPACE (response) 114
NO (response) 108 NO (response) 107
NONEXISTENT (response code) 104 NONEXISTENT (response code) 104
NOOP (command) 26 NOOP (command) 27
NOPERM (response code) 104 NOPERM (response code) 104
NOT <search-key> (search key) 79 NOT <search-key> (search key) 79
NOT RECOMMENDED (specification requirement term) 5 NOT RECOMMENDED (specification requirement term) 5
O O
OK (response) 107 OK (response) 107
ON <date> (search key) 79 ON <date> (search key) 79
OPTIONAL (specification requirement term) 5 OPTIONAL (specification requirement term) 5
OR <search-key1> <search-key2> (search key) 79 OR <search-key1> <search-key2> (search key) 79
OVERQUOTA (response code) 104 OVERQUOTA (response code) 104
P P
PARSE (response code) 105 PARSE (response code) 105
PERMANENTFLAGS (response code) 105 PERMANENTFLAGS (response code) 105
PREAUTH (response) 108 PREAUTH (response) 108
PRIVACYREQUIRED (response code) 105 PRIVACYREQUIRED (response code) 105
Permanent Flag (class of flag) 13 Permanent Flag (class of flag) 13
Predefined keywords 12 Predefined keywords 12
R R
READ-ONLY (response code) 106 READ-ONLY (response code) 105
READ-WRITE (response code) 106 READ-WRITE (response code) 106
RECOMMENDED (specification requirement term) 5 RECOMMENDED (specification requirement term) 5
RENAME (command) 41 RENAME (command) 41
REQUIRED (specification requirement term) 5 REQUIRED (specification requirement term) 5
RFC822.SIZE (fetch item) 90 RFC822.SIZE (fetch item) 90
RFC822.SIZE (fetch result) 123 RFC822.SIZE (fetch result) 123
S S
SAVE (search result option) 76 SAVE (search result option) 76
SEARCH (command) 75 SEARCH (command) 75
skipping to change at page 162, line 20 skipping to change at page 162, line 29
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) 79 SINCE <date> (search key) 79
SIZE (status item) 68 SIZE (status item) 68
SMALLER <n> (search key) 79 SMALLER <n> (search key) 79
STARTTLS (command) 28 STARTTLS (command) 28
STATUS (command) 67 STATUS (command) 67
STATUS (response) 115 STATUS (response) 115
STORE (command) 92 STORE (command) 92
SUBJECT <string> (search key) 79 SUBJECT <string> (search key) 79
SUBSCRIBE (command) 43 SUBSCRIBE (command) 44
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) 90 TEXT (part specifier) 90
TEXT <string> (search key) 80 TEXT <string> (search key) 80
TO <string> (search key) 80 TO <string> (search key) 80
TRYCREATE (response code) 106 TRYCREATE (response code) 106
U U
UID (command) 96 UID (command) 96
UID (fetch item) 90 UID (fetch item) 90
UID (fetch result) 123 UID (fetch result) 123
UID <sequence set> (search key) 80 UID <sequence set> (search key) 80
UIDNEXT (response code) 106 UIDNEXT (response code) 106
UIDNEXT (status item) 68 UIDNEXT (status item) 68
UIDNOTSTICKY (response code) 106 UIDNOTSTICKY (response code) 106
UIDVALIDITY (response code) 107 UIDVALIDITY (response code) 106
UIDVALIDITY (status item) 68 UIDVALIDITY (status item) 68
UNANSWERED (search key) 80 UNANSWERED (search key) 80
UNAVAILABLE (response code) 107 UNAVAILABLE (response code) 107
UNDELETED (search key) 80 UNDELETED (search key) 80
UNDRAFT (search key) 80 UNDRAFT (search key) 80
UNFLAGGED (search key) 80 UNFLAGGED (search key) 80
UNKEYWORD <flag> (search key) 80 UNKEYWORD <flag> (search key) 80
UNKNOWN-CTE (response code) 107 UNKNOWN-CTE (response code) 107
UNSEEN (search key) 80 UNSEEN (search key) 80
UNSEEN (status item) 68 UNSEEN (status item) 68
UNSELECT (command) 74 UNSELECT (command) 74
UNSUBSCRIBE (command) 44 UNSUBSCRIBE (command) 44
Unique Identifier (UID) (message attribute) 9 Unique Identifier (UID) (message attribute) 9
X
X<atom> (command) 97
[ [
[RFC-5322] Size (message attribute) 14 [RFC-5322] Size (message attribute) 14
\ \
\All (mailbox name attribute) 113 \All (mailbox name attribute) 113
\Answered (system flag) 12 \Answered (system flag) 12
\Archive (mailbox name attribute) 113 \Archive (mailbox name attribute) 113
\Deleted (system flag) 12 \Deleted (system flag) 12
\Draft (system flag) 12 \Draft (system flag) 12
\Drafts (mailbox name attribute) 113 \Drafts (mailbox name attribute) 113
\Flagged (mailbox name attribute) 113 \Flagged (mailbox name attribute) 113
\Flagged (system flag) 12 \Flagged (system flag) 12
\HasChildren (mailbox name attribute) 112 \HasChildren (mailbox name attribute) 111
\HasNoChildren (mailbox name attribute) 112 \HasNoChildren (mailbox name attribute) 112
\Junk (mailbox name attribute) 113 \Junk (mailbox name attribute) 113
\Marked (mailbox name attribute) 112 \Marked (mailbox name attribute) 112
\Noinferiors (mailbox name attribute) 111 \Noinferiors (mailbox name attribute) 111
\NonExistent (mailbox name attribute) 111 \NonExistent (mailbox name attribute) 111
\Noselect (mailbox name attribute) 111 \Noselect (mailbox name attribute) 111
\Recent (system flag) 12 \Recent (system flag) 12
\Remote (mailbox name attribute) 112 \Remote (mailbox name attribute) 112
\Seen (system flag) 12 \Seen (system flag) 12
\Sent (mailbox name attribute) 113 \Sent (mailbox name attribute) 113
 End of changes. 73 change blocks. 
133 lines changed or deleted 136 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/