< draft-ietf-extra-imap4rev2-24.txt   draft-ietf-extra-imap4rev2-25.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 9, 2021 January 5, 2021 Expires: July 24, 2021 January 20, 2021
Internet Message Access Protocol (IMAP) - Version 4rev2 Internet Message Access Protocol (IMAP) - Version 4rev2
draft-ietf-extra-imap4rev2-24 draft-ietf-extra-imap4rev2-25
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 9, 2021. This Internet-Draft will expire on July 24, 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 2, line 45 skipping to change at page 2, line 45
1.1. Organization of This Document . . . . . . . . . . . . . . 5 1.1. Organization of This Document . . . . . . . . . . . . . . 5
1.2. Conventions Used in This Document . . . . . . . . . . . . 5 1.2. Conventions Used in This Document . . . . . . . . . . . . 5
1.3. Special Notes to Implementors . . . . . . . . . . . . . . 6 1.3. Special Notes to Implementors . . . . . . . . . . . . . . 6
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Link Level . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Link Level . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Commands and Responses . . . . . . . . . . . . . . . . . 7 2.2. Commands and Responses . . . . . . . . . . . . . . . . . 7
2.2.1. Client Protocol Sender and Server Protocol Receiver . 7 2.2.1. Client Protocol Sender and Server Protocol Receiver . 7
2.2.2. Server Protocol Sender and Client Protocol Receiver . 8 2.2.2. Server Protocol Sender and Client Protocol Receiver . 8
2.3. Message Attributes . . . . . . . . . . . . . . . . . . . 9 2.3. Message Attributes . . . . . . . . . . . . . . . . . . . 9
2.3.1. Message Numbers . . . . . . . . . . . . . . . . . . . 9 2.3.1. Message Numbers . . . . . . . . . . . . . . . . . . . 9
2.3.2. Flags Message Attribute . . . . . . . . . . . . . . . 11 2.3.2. Flags Message Attribute . . . . . . . . . . . . . . . 12
2.3.3. Internal Date Message Attribute . . . . . . . . . . . 13 2.3.3. Internal Date Message Attribute . . . . . . . . . . . 14
2.3.4. [RFC-5322] Size Message Attribute . . . . . . . . . . 14 2.3.4. [RFC-5322] Size Message Attribute . . . . . . . . . . 14
2.3.5. Envelope Structure Message Attribute . . . . . . . . 14 2.3.5. Envelope Structure Message Attribute . . . . . . . . 14
2.3.6. Body Structure Message Attribute . . . . . . . . . . 14 2.3.6. Body Structure Message Attribute . . . . . . . . . . 14
2.4. Message Texts . . . . . . . . . . . . . . . . . . . . . . 14 2.4. Message Texts . . . . . . . . . . . . . . . . . . . . . . 14
3. State and Flow Diagram . . . . . . . . . . . . . . . . . . . 14 3. State and Flow Diagram . . . . . . . . . . . . . . . . . . . 14
3.1. Not Authenticated State . . . . . . . . . . . . . . . . . 14 3.1. Not Authenticated State . . . . . . . . . . . . . . . . . 15
3.2. Authenticated State . . . . . . . . . . . . . . . . . . . 15 3.2. Authenticated State . . . . . . . . . . . . . . . . . . . 15
3.3. Selected State . . . . . . . . . . . . . . . . . . . . . 15 3.3. Selected State . . . . . . . . . . . . . . . . . . . . . 15
3.4. Logout State . . . . . . . . . . . . . . . . . . . . . . 15 3.4. Logout State . . . . . . . . . . . . . . . . . . . . . . 15
4. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 17 4. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1. Atom . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.1. Atom . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.1. Sequence set and UID set . . . . . . . . . . . . . . 17 4.1.1. Sequence set and UID set . . . . . . . . . . . . . . 17
4.2. Number . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2. Number . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3. String . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.3. String . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.1. 8-bit and Binary Strings . . . . . . . . . . . . . . 18 4.3.1. 8-bit and Binary Strings . . . . . . . . . . . . . . 18
4.4. Parenthesized List . . . . . . . . . . . . . . . . . . . 19 4.4. Parenthesized List . . . . . . . . . . . . . . . . . . . 19
skipping to change at page 3, line 30 skipping to change at page 3, line 30
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) . . . 24 5.5. Multiple Commands in Progress (Command Pipelining) . . . 24
6. Client Commands . . . . . . . . . . . . . . . . . . . . . . . 25 6. Client Commands . . . . . . . . . . . . . . . . . . . . . . . 25
6.1. Client Commands - Any State . . . . . . . . . . . . . . . 26 6.1. Client Commands - Any State . . . . . . . . . . . . . . . 26
6.1.1. CAPABILITY Command . . . . . . . . . . . . . . . . . 26 6.1.1. CAPABILITY Command . . . . . . . . . . . . . . . . . 26
6.1.2. NOOP Command . . . . . . . . . . . . . . . . . . . . 27 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 . . . . . . . . 28 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 . . . . . . . . . . . . . . . . 30
6.2.3. LOGIN Command . . . . . . . . . . . . . . . . . . . . 32 6.2.3. LOGIN Command . . . . . . . . . . . . . . . . . . . . 33
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 . . . . . . . . . . . . . . . . . . . 34
6.3.2. SELECT Command . . . . . . . . . . . . . . . . . . . 35 6.3.2. SELECT Command . . . . . . . . . . . . . . . . . . . 36
6.3.3. EXAMINE Command . . . . . . . . . . . . . . . . . . . 37 6.3.3. EXAMINE Command . . . . . . . . . . . . . . . . . . . 38
6.3.4. CREATE Command . . . . . . . . . . . . . . . . . . . 38 6.3.4. CREATE Command . . . . . . . . . . . . . . . . . . . 39
6.3.5. DELETE Command . . . . . . . . . . . . . . . . . . . 40 6.3.5. DELETE Command . . . . . . . . . . . . . . . . . . . 40
6.3.6. RENAME Command . . . . . . . . . . . . . . . . . . . 41 6.3.6. RENAME Command . . . . . . . . . . . . . . . . . . . 42
6.3.7. SUBSCRIBE Command . . . . . . . . . . . . . . . . . . 44 6.3.7. SUBSCRIBE Command . . . . . . . . . . . . . . . . . . 44
6.3.8. UNSUBSCRIBE Command . . . . . . . . . . . . . . . . . 44 6.3.8. UNSUBSCRIBE Command . . . . . . . . . . . . . . . . . 45
6.3.9. LIST Command . . . . . . . . . . . . . . . . . . . . 45 6.3.9. LIST Command . . . . . . . . . . . . . . . . . . . . 45
6.3.10. NAMESPACE Command . . . . . . . . . . . . . . . . . . 63 6.3.10. NAMESPACE Command . . . . . . . . . . . . . . . . . . 63
6.3.11. STATUS Command . . . . . . . . . . . . . . . . . . . 67 6.3.11. STATUS Command . . . . . . . . . . . . . . . . . . . 68
6.3.12. APPEND Command . . . . . . . . . . . . . . . . . . . 68 6.3.12. APPEND Command . . . . . . . . . . . . . . . . . . . 69
6.3.13. IDLE Command . . . . . . . . . . . . . . . . . . . . 71 6.3.13. IDLE Command . . . . . . . . . . . . . . . . . . . . 72
6.4. Client Commands - Selected State . . . . . . . . . . . . 73 6.4. Client Commands - Selected State . . . . . . . . . . . . 74
6.4.1. CLOSE Command . . . . . . . . . . . . . . . . . . . . 74 6.4.1. CLOSE Command . . . . . . . . . . . . . . . . . . . . 75
6.4.2. UNSELECT Command . . . . . . . . . . . . . . . . . . 74 6.4.2. UNSELECT Command . . . . . . . . . . . . . . . . . . 75
6.4.3. EXPUNGE Command . . . . . . . . . . . . . . . . . . . 75 6.4.3. EXPUNGE Command . . . . . . . . . . . . . . . . . . . 76
6.4.4. SEARCH Command . . . . . . . . . . . . . . . . . . . 75 6.4.4. SEARCH Command . . . . . . . . . . . . . . . . . . . 76
6.4.5. FETCH Command . . . . . . . . . . . . . . . . . . . . 87 6.4.5. FETCH Command . . . . . . . . . . . . . . . . . . . . 88
6.4.6. STORE Command . . . . . . . . . . . . . . . . . . . . 92 6.4.6. STORE Command . . . . . . . . . . . . . . . . . . . . 93
6.4.7. COPY Command . . . . . . . . . . . . . . . . . . . . 93 6.4.7. COPY Command . . . . . . . . . . . . . . . . . . . . 94
6.4.8. MOVE Command . . . . . . . . . . . . . . . . . . . . 94 6.4.8. MOVE Command . . . . . . . . . . . . . . . . . . . . 95
6.4.9. UID Command . . . . . . . . . . . . . . . . . . . . . 96 6.4.9. UID Command . . . . . . . . . . . . . . . . . . . . . 97
6.5. Client Commands - Experimental/Expansion . . . . . . . . 97 6.5. Client Commands - Experimental/Expansion . . . . . . . . 99
7. Server Responses . . . . . . . . . . . . . . . . . . . . . . 98 7. Server Responses . . . . . . . . . . . . . . . . . . . . . . 99
7.1. Server Responses - Status Responses . . . . . . . . . . . 99 7.1. Server Responses - Generic Status Responses . . . . . . . 100
7.1.1. OK Response . . . . . . . . . . . . . . . . . . . . . 107 7.1.1. OK Response . . . . . . . . . . . . . . . . . . . . . 108
7.1.2. NO Response . . . . . . . . . . . . . . . . . . . . . 107 7.1.2. NO Response . . . . . . . . . . . . . . . . . . . . . 109
7.1.3. BAD Response . . . . . . . . . . . . . . . . . . . . 108 7.1.3. BAD Response . . . . . . . . . . . . . . . . . . . . 109
7.1.4. PREAUTH Response . . . . . . . . . . . . . . . . . . 108 7.1.4. PREAUTH Response . . . . . . . . . . . . . . . . . . 110
7.1.5. BYE Response . . . . . . . . . . . . . . . . . . . . 109 7.1.5. BYE Response . . . . . . . . . . . . . . . . . . . . 110
7.2. Server Responses - Server and Mailbox Status . . . . . . 109 7.2. Server Responses - Server Status . . . . . . . . . . . . 111
7.2.1. The ENABLED Response . . . . . . . . . . . . . . . . 109 7.2.1. ENABLED Response . . . . . . . . . . . . . . . . . . 111
7.2.2. CAPABILITY Response . . . . . . . . . . . . . . . . . 110 7.2.2. CAPABILITY Response . . . . . . . . . . . . . . . . . 111
7.2.3. LIST Response . . . . . . . . . . . . . . . . . . . . 111 7.3. Server Responses - Mailbox Status . . . . . . . . . . . . 112
7.2.4. NAMESPACE Response . . . . . . . . . . . . . . . . . 114 7.3.1. LIST Response . . . . . . . . . . . . . . . . . . . . 112
7.2.5. STATUS Response . . . . . . . . . . . . . . . . . . . 115 7.3.2. NAMESPACE Response . . . . . . . . . . . . . . . . . 116
7.2.6. ESEARCH Response . . . . . . . . . . . . . . . . . . 115 7.3.3. STATUS Response . . . . . . . . . . . . . . . . . . . 117
7.2.7. FLAGS Response . . . . . . . . . . . . . . . . . . . 116 7.3.4. ESEARCH Response . . . . . . . . . . . . . . . . . . 117
7.3. Server Responses - Mailbox Size . . . . . . . . . . . . . 116 7.3.5. FLAGS Response . . . . . . . . . . . . . . . . . . . 117
7.3.1. EXISTS Response . . . . . . . . . . . . . . . . . . . 116 7.4. Server Responses - Mailbox Size . . . . . . . . . . . . . 118
7.4. Server Responses - Message Status . . . . . . . . . . . . 116 7.4.1. EXISTS Response . . . . . . . . . . . . . . . . . . . 118
7.4.1. EXPUNGE Response . . . . . . . . . . . . . . . . . . 117 7.5. Server Responses - Message Status . . . . . . . . . . . . 118
7.4.2. FETCH Response . . . . . . . . . . . . . . . . . . . 117 7.5.1. EXPUNGE Response . . . . . . . . . . . . . . . . . . 118
7.5. Server Responses - Command Continuation Request . . . . . 123 7.5.2. FETCH Response . . . . . . . . . . . . . . . . . . . 119
8. Sample IMAP4rev2 connection . . . . . . . . . . . . . . . . . 124 7.6. Server Responses - Command Continuation Request . . . . . 125
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 125 8. Sample IMAP4rev2 connection . . . . . . . . . . . . . . . . . 126
10. Author's Note . . . . . . . . . . . . . . . . . . . . . . . . 143 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 127
11. Security Considerations . . . . . . . . . . . . . . . . . . . 143 10. Author's Note . . . . . . . . . . . . . . . . . . . . . . . . 145
11.1. STARTTLS Security Considerations . . . . . . . . . . . . 143 11. Security Considerations . . . . . . . . . . . . . . . . . . . 146
11.2. COPYUID and APPENDUID response codes . . . . . . . . . . 144 11.1. TLS related Security Considerations . . . . . . . . . . 146
11.3. LIST command and Other Users' namespace . . . . . . . . 144 11.2. STARTTLS command versa use of Implicit TLS port . . . . 146
11.4. Other Security Considerations . . . . . . . . . . . . . 145 11.3. Client handling of unsolicited responses not suitable
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 145 for the current connection state . . . . . . . . . . . . 147
12.1. Updates to IMAP4 Capabilities registry . . . . . . . . . 146 11.4. COPYUID and APPENDUID response codes . . . . . . . . . . 147
12.2. GSSAPI/SASL service name . . . . . . . . . . . . . . . . 146 11.5. LIST command and Other Users' namespace . . . . . . . . 148
11.6. Other Security Considerations . . . . . . . . . . . . . 148
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 149
12.1. Updates to IMAP4 Capabilities registry . . . . . . . . . 149
12.2. GSSAPI/SASL service name . . . . . . . . . . . . . . . . 149
12.3. LIST Selection Options, LIST Return Options, LIST 12.3. LIST Selection Options, LIST Return Options, LIST
extended data items . . . . . . . . . . . . . . . . . . 146 extended data items . . . . . . . . . . . . . . . . . . 150
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 147 12.4. IMAP Mailbox Name Attributes and IMAP Response Codes . . 150
13.1. Normative References . . . . . . . . . . . . . . . . . . 147 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 150
13.2. Informative References (related protocols) . . . . . . . 150 13.1. Normative References . . . . . . . . . . . . . . . . . . 150
13.2. Informative References (related protocols) . . . . . . . 153
13.3. Informative References (historical aspects of IMAP and 13.3. Informative References (historical aspects of IMAP and
related protocols) . . . . . . . . . . . . . . . . . . . 152 related protocols) . . . . . . . . . . . . . . . . . . . 155
Appendix A. Backward compatibility with IMAP4rev1 . . . . . . . 152 Appendix A. Backward compatibility with IMAP4rev1 . . . . . . . 156
A.1. Mailbox International Naming Convention for compatibility A.1. Mailbox International Naming Convention for compatibility
with IMAP4rev1 . . . . . . . . . . . . . . . . . . . . . 153 with IMAP4rev1 . . . . . . . . . . . . . . . . . . . . . 157
Appendix B. Backward compatibility with BINARY extension . . . . 155 Appendix B. Backward compatibility with BINARY extension . . . . 158
Appendix C. Backward compatibility with LIST-EXTENDED extension 155 Appendix C. Backward compatibility with LIST-EXTENDED extension 158
Appendix D. 63 bit body part and message sizes . . . . . . . . . 155 Appendix D. 63 bit body part and message sizes . . . . . . . . . 159
Appendix E. Changes from RFC 3501 / IMAP4rev1 . . . . . . . . . 155 Appendix E. Changes from RFC 3501 / IMAP4rev1 . . . . . . . . . 159
Appendix F. Other Recommended IMAP Extensions . . . . . . . . . 157 Appendix F. Other Recommended IMAP Extensions . . . . . . . . . 161
Appendix G. Acknowledgement . . . . . . . . . . . . . . . . . . 158 Appendix G. Acknowledgement . . . . . . . . . . . . . . . . . . 161
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 163 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 167
1. How to Read This Document 1. How to Read This Document
1.1. Organization of This Document 1.1. Organization of This Document
This document is written from the point of view of the implementor of This document is written from the point of view of the implementor of
an IMAP4rev2 client or server. Beyond the protocol overview in an IMAP4rev2 client or server. Beyond the protocol overview in
section 2, it is not optimized for someone trying to understand the section 2, it is not optimized for someone trying to understand the
operation of the protocol. The material in sections 3 through 5 operation of the protocol. The material in sections 3 through 5
provides the general context and definitions with which IMAP4rev2 provides the general context and definitions with which IMAP4rev2
skipping to change at page 6, line 14 skipping to change at page 6, line 17
"Connection" refers to the entire sequence of client/server "Connection" refers to the entire sequence of client/server
interaction from the initial establishment of the network connection interaction from the initial establishment of the network connection
until its termination. until its termination.
"Session" refers to the sequence of client/server interaction from "Session" refers to the sequence of client/server interaction from
the time that a mailbox is selected (SELECT or EXAMINE command) until the time that a mailbox is selected (SELECT or EXAMINE command) until
the time that selection ends (SELECT or EXAMINE of another mailbox, the time that selection ends (SELECT or EXAMINE of another mailbox,
CLOSE command, UNSELECT command, or connection termination). CLOSE command, UNSELECT command, or connection termination).
The term "Implicit TLS" refers to the automatic negotiation of TLS
whenever a TCP connection is made on a particular TCP port that is
used exclusively by that server for TLS connections. The term
"Implicit TLS" is intended to contrast with the use of STARTTLS
command in IMAP that is used by the client and the server to
explicitly negotiate TLS on an established cleartext TCP connection.
Characters are 8-bit UTF-8 (of which 7-bit US-ASCII is a subset) Characters are 8-bit UTF-8 (of which 7-bit US-ASCII is a subset)
unless otherwise specified. Other character sets are indicated using unless otherwise specified. Other character sets are indicated using
a "CHARSET", as described in [MIME-IMT] and defined in [CHARSET]. a "CHARSET", as described in [MIME-IMT] and defined in [CHARSET].
CHARSETs have important additional semantics in addition to defining CHARSETs have important additional semantics in addition to defining
character set; refer to these documents for more detail. character set; refer to these documents for more detail.
There are several protocol conventions in IMAP. These refer to There are several protocol conventions in IMAP. These refer to
aspects of the specification which are not strictly part of the IMAP aspects of the specification which are not strictly part of the IMAP
protocol, but reflect generally-accepted practice. Implementations protocol, but reflect generally-accepted practice. Implementations
need to be aware of these conventions, and avoid conflicts whether or need to be aware of these conventions, and avoid conflicts whether or
skipping to change at page 7, line 39 skipping to change at page 7, line 49
All interactions transmitted by client and server are in the form of All interactions transmitted by client and server are in the form of
lines, that is, strings that end with a CRLF. The protocol receiver lines, that is, strings that end with a CRLF. The protocol receiver
of an IMAP4rev2 client or server is either reading a line, or is of an IMAP4rev2 client or server is either reading a line, or is
reading a sequence of octets with a known count followed by a line. reading a sequence of octets with a known count followed by a line.
2.2.1. Client Protocol Sender and Server Protocol Receiver 2.2.1. Client Protocol Sender and Server Protocol Receiver
The client command begins an operation. Each client command is The client command begins an operation. Each client command is
prefixed with an identifier (typically a short alphanumeric string, prefixed with an identifier (typically a short alphanumeric string,
e.g., A0001, A0002, etc.) called a "tag". A different tag is e.g., A0001, A0002, etc.) called a "tag". A different tag is
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 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
skipping to change at page 9, line 11 skipping to change at page 9, line 19
(but not limited to) missing or extraneous spaces or arguments, (but not limited to) missing or extraneous spaces or arguments,
SHOULD be rejected, and the client given a BAD server completion SHOULD be rejected, and the client given a BAD server completion
response. response.
The protocol receiver of an IMAP4rev2 client reads a response line The protocol receiver of an IMAP4rev2 client reads a response line
from the server. It then takes action on the response based upon the from the server. It then takes action on the response based upon the
first token of the response, which can be a tag, a "*", or a "+". first token of the response, which can be a tag, a "*", or a "+".
A client MUST be prepared to accept any server response at all times. A client MUST be prepared to accept any server response at all times.
This includes server data that was not requested. Server data SHOULD This includes server data that was not requested. Server data SHOULD
be recorded, so that the client can reference its recorded copy be remembered (cached), so that the client can reference its
rather than sending a command to the server to request the data. In remembered copy rather than sending a command to the server to
the case of certain server data, the data MUST be recorded. request the data. In the case of certain server data, the data MUST
be remembered, as specified elsewhere in this document.
This topic is discussed in greater detail in the Server Responses This topic is discussed in greater detail in the Server Responses
section. section.
2.3. Message Attributes 2.3. Message Attributes
In addition to message text, each message has several attributes In addition to message text, each message has several attributes
associated with it. These attributes can be retrieved individually associated with it. These attributes can be retrieved individually
or in conjunction with other attributes or message texts. or in conjunction with other attributes or message texts.
skipping to change at page 13, line 16 skipping to change at page 13, line 27
choose to mark a message as definitely not containing junk choose to mark a message as definitely not containing junk
($NotJunk; see also the related keyword $Junk). The $NotJunk ($NotJunk; see also the related keyword $Junk). The $NotJunk
keyword can be used to mark, group or show messages that the user keyword can be used to mark, group or show messages that the user
wants to see. See [IMAP-KEYWORDS-REG] for more information. wants to see. See [IMAP-KEYWORDS-REG] for more information.
$Phishing The $Phishing keyword can be used by a delivery agent to $Phishing The $Phishing keyword can be used by a delivery agent to
mark a message as highly likely to be a phishing email. An email mark a message as highly likely to be a phishing email. An email
that's determined to be a phishing email by the delivery agent that's determined to be a phishing email by the delivery agent
should also be considered a junk email and have the appropriate should also be considered a junk email and have the appropriate
junk filtering applied, including setting the $Junk flag and junk filtering applied, including setting the $Junk flag and
placing in the \Junk special-use mailbox (see Section 7.2.3) if placing in the \Junk special-use mailbox (see Section 7.3.1) if
available. available.
If both the $Phishing flag and the $Junk flag are set, the user If both the $Phishing flag and the $Junk flag are set, the user
agent should display an additional warning message to the user. agent should display an additional warning message to the user.
User agents should not use the term "phishing" in their warning Additionally the user agent may display a warning when clicking on
message as most users do not understand this term. Phrasing of any hyperlinks within the message.
the form "this message may be trying to steal your personal
information" is recommended. Additionally the user agent may
display a warning when clicking on any hyperlinks within the
message.
The requirement for both $Phishing and $Junk to be set before a The requirement for both $Phishing and $Junk to be set before a
user agent displays a warning is for better backwards user agent displays a warning is for better backwards
compatibility with existing clients that understand the $Junk flag compatibility with existing clients that understand the $Junk flag
but not the $Phishing flag. This so that when an unextended but not the $Phishing flag. This so that when an unextended
client removes the $Junk flag, an extended client will also show client removes the $Junk flag, an extended client will also show
the correct state. See [IMAP-KEYWORDS-REG] for more information. the correct state. See [IMAP-KEYWORDS-REG] for more information.
$Junk and $NotJunk are mutually exclusive. If more than one of them $Junk and $NotJunk are mutually exclusive. If more than one of them
is set for a message, the client MUST treat this as if none of them is set for a message, the client MUST treat this as if none of them
is set and SHOULD unset both of them on the IMAP server. is set and SHOULD unset both of them on the IMAP server.
skipping to change at page 20, line 12 skipping to change at page 20, line 12
because addr-name uses "nstring" syntax which is NIL or a string, because addr-name uses "nstring" syntax which is NIL or a string,
but never an atom. but never an atom.
Examples: Examples:
The following LIST response: The following LIST response:
* LIST () "/" NIL * LIST () "/" NIL
is equivalent to: is equivalent to:
* LIST () "/" "NIL" * LIST () "/" "NIL"
as LIST response ABNF is using astring for mailbox name. as LIST response ABNF is using "astring" for mailbox name.
However, the following response However, the following response
* FETCH 1 (BODY[1] NIL) * FETCH 1 (BODY[1] NIL)
is not equivalent to: is not equivalent to:
* FETCH 1 (BODY[1] "NIL")
* FETCH 1 (BODY[1] "NIL")
The former means absence of the body part, while the latter The former means absence of the body part, while the latter
means that it contains literal sequence of characters "NIL". means that it contains literal sequence of characters "NIL".
5. Operational Considerations 5. Operational Considerations
The following rules are listed here to ensure that all IMAP4rev2 The following rules are listed here to ensure that all IMAP4rev2
implementations interoperate properly. implementations interoperate properly.
5.1. Mailbox Naming 5.1. Mailbox Naming
skipping to change at page 21, line 51 skipping to change at page 22, line 5
5.1.2. Namespaces 5.1.2. Namespaces
Personal Namespace: A namespace that the server considers within the Personal Namespace: A namespace that the server considers within the
personal scope of the authenticated user on a particular connection. personal scope of the authenticated user on a particular connection.
Typically, only the authenticated user has access to mailboxes in Typically, only the authenticated user has access to mailboxes in
their Personal Namespace. It is the part of the namespace that their Personal Namespace. It is the part of the namespace that
belongs to the user that is allocated for mailboxes. If an INBOX belongs to the user that is allocated for mailboxes. If an INBOX
exists for a user, it MUST appear within the user's personal exists for a user, it MUST appear within the user's personal
namespace. In the typical case, there SHOULD be only one Personal namespace. In the typical case, there SHOULD be only one Personal
Namespace on a server. Namespace per user on a server.
Other Users' Namespace: A namespace that consists of mailboxes from Other Users' Namespace: A namespace that consists of mailboxes from
the Personal Namespaces of other users. To access mailboxes in the the Personal Namespaces of other users. To access mailboxes in the
Other Users' Namespace, the currently authenticated user MUST be Other Users' Namespace, the currently authenticated user MUST be
explicitly granted access rights. For example, it is common for a explicitly granted access rights. For example, it is common for a
manager to grant to their secretary access rights to their mailbox. manager to grant to their secretary access rights to their mailbox.
In the typical case, there SHOULD be only one Other Users' Namespace In the typical case, there SHOULD be only one Other Users' Namespace
on a server. per user on a server.
Shared Namespace: A namespace that consists of mailboxes that are Shared Namespace: A namespace that consists of mailboxes that are
intended to be shared amongst users and do not exist within a user's intended to be shared amongst users and do not exist within a user's
Personal Namespace. Personal Namespace.
The namespaces a server uses MAY differ on a per-user basis. The namespaces a server uses MAY differ on a per-user basis.
5.1.2.1. Historic Mailbox Namespace Naming Convention 5.1.2.1. Historic Mailbox Namespace Naming Convention
By convention, the first hierarchical element of any mailbox name By convention, the first hierarchical element of any mailbox name
skipping to change at page 23, line 20 skipping to change at page 23, line 24
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 (Section 7.4.1) for more detail. description of the EXPUNGE response (Section 7.5.1) for more detail.
In particular, it is NOT permitted to send an EXISTS response that In particular, it is NOT permitted to send an EXISTS response that
would reduce the number of messages in the mailbox; only the EXPUNGE would reduce the number of messages in the mailbox; only the EXPUNGE
response can do 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
mailbox size updates. It MUST NOT assume that any command after the remember mailbox size updates. It MUST NOT assume that any command
initial mailbox selection will return the size of the mailbox. after the 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
implementations that send such responses MUST deal with flow control implementations that send such responses MUST deal with flow control
considerations. Specifically, they MUST either (1) verify that the considerations. Specifically, they MUST either (1) verify that the
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 Note that this specification doesn't have any restrictions on
autologout timer used before successful client authentication. In autologout timer used before successful client authentication. In
particular, servers are allowed to use shorted pre-authentication particular, servers are allowed to use shortened pre-authentication
timer to protect themselves from Denial of Service attacks. 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
skipping to change at page 26, line 17 skipping to change at page 26, line 17
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 - arguments invalid
The CAPABILITY command requests a listing of capabilities (e.g. The CAPABILITY command requests a listing of capabilities (e.g.
extensions and/or modifications of server behaviour) that the server extensions and/or modifications of server behaviour) that the server
supports. The server MUST send a single untagged CAPABILITY response supports. The server MUST send a single untagged CAPABILITY response
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. No
capabilities, beyond the base IMAP4rev2 set defined in this capabilities, beyond the base IMAP4rev2 set defined in this
specification, are enabled without explicit client action to invoke specification, are enabled without explicit client action to invoke
the capability. 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. Section 6.2.1, LOGINDISABLED, and AUTH=PLAIN (described in [PLAIN])
See the Security Considerations (Section 11) for important capabilities. See the Security Considerations (Section 11) for
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
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
skipping to change at page 28, line 51 skipping to change at page 28, line 51
STARTTLS, AUTHENTICATE and LOGIN. See the Security Considerations STARTTLS, AUTHENTICATE and LOGIN. See the Security Considerations
(Section 11) 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
NO - TLS negotiation can't be initiated, due to server
configuration error
BAD - STARTTLS received after a successful TLS BAD - STARTTLS received after a successful TLS
negotiation or arguments invalid negotiation or arguments invalid
A TLS [TLS-1.3] negotiation begins immediately after the CRLF at the A TLS [TLS-1.3] negotiation begins immediately after the CRLF at the
end of the tagged OK response from the server. Once a client issues end of the tagged OK response from the server. Once a client issues
a STARTTLS command, it MUST NOT issue further commands until a server a STARTTLS command, it MUST NOT issue further commands until a server
response is seen and the TLS negotiation is complete. response is seen and the TLS negotiation is complete. Some past
server implementation incorrectly implemented STARTTLS processing and
are known to contain STARTTLS plaintext command injection
vulnerability [CERT-555316]. In order to avoid this vulnerability,
server implementations MUST do one of the following If any data is
received in the same TCP buffer after the CRLF that starts the
STARTTLS command:
The server remains in the non-authenticated state, even if client 1. Extra data from the TCP buffer is interpreted as beginning of the
credentials are supplied during the TLS negotiation. This does not TLS handshake. (If the data is in cleartext, this will result in
preclude an authentication mechanism such as EXTERNAL (defined in the TLS handshake failing.)
[SASL]) from using client identity determined by the TLS negotiation.
2. Extra data from the TCP buffer is thrown away.
Note that the first option is friendlier to clients that pipeline
beginning of STARTTLS command with TLS handshake data.
After successful TLS negotiation the server remains in the non-
authenticated state, even if client credentials are supplied during
the TLS negotiation. This does not preclude an authentication
mechanism such as EXTERNAL (defined in [SASL]) from using client
identity determined by the TLS negotiation.
Once TLS has been started, the client MUST discard cached information Once TLS has been started, the client MUST discard cached information
about server capabilities and SHOULD re-issue the CAPABILITY command. about server capabilities and SHOULD re-issue the CAPABILITY command.
This is necessary to protect against man-in- the-middle attacks which This is necessary to protect against man-in- the-middle attacks which
alter the capabilities list prior to STARTTLS. The server MAY alter the capabilities list prior to STARTTLS. The server MAY
advertise different capabilities, and in particular SHOULD NOT advertise different capabilities, and in particular SHOULD NOT
advertise the STARTTLS capability, after a successful STARTTLS advertise the STARTTLS capability, after a successful STARTTLS
command. command.
Example: C: a001 CAPABILITY Example: C: a001 CAPABILITY
skipping to change at page 32, line 47 skipping to change at page 33, line 17
Arguments: user name Arguments: user name
password password
Responses: no specific responses for this command Responses: no specific responses for this command
Result: OK - login completed, now in authenticated state Result: OK - login completed, now in authenticated state
NO - login failure: user name or password rejected NO - login failure: user name or password rejected
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
The LOGIN command identifies the client to the server and carries the The LOGIN command identifies the client to the server and carries the
plaintext password authenticating this user. plaintext password authenticating this user. The LOGIN command
SHOULD NOT be used except as a last resort (after attempting and
failing to authenticate using the AUTHENTICATE command one or more
times), and it is recommended that client implementations have a
means to disable any automatic use of the LOGIN command.
A server MAY include a CAPABILITY response code in the tagged OK A server MAY include a CAPABILITY response code in the tagged OK
response to a successful LOGIN command in order to send capabilities response to a successful LOGIN command in order to send capabilities
automatically. It is unnecessary for a client to send a separate automatically. It is unnecessary for a client to send a separate
CAPABILITY command if it recognizes these automatic capabilities. CAPABILITY command if it recognizes these automatic capabilities.
Example: C: a001 LOGIN SMITH SESAME Example: C: a001 LOGIN SMITH SESAME
S: a001 OK LOGIN completed S: a001 OK LOGIN completed
Note: Use of the LOGIN command over an insecure network (such as the Note: Use of the LOGIN command over an insecure network (such as the
Internet) is a security risk, because anyone monitoring network Internet) is a security risk, because anyone monitoring network
traffic can obtain plaintext passwords. The LOGIN command SHOULD NOT traffic can obtain plaintext passwords. For that reason clients MUST
be used except as a last resort, and it is recommended that client NOT use LOGIN on unsecure networks.
implementations have a means to disable any automatic use of the
LOGIN command.
Unless either the client is accessing IMAP service on IMAPS port Unless either the client is accessing IMAP service on IMAPS port
[RFC8314], the STARTTLS command has been negotiated or some other [RFC8314], the STARTTLS command has been negotiated or some other
mechanism that protects the session from password snooping has been mechanism that protects the session from password snooping has been
provided, a server implementation MUST implement a configuration in provided, a server implementation MUST implement a configuration in
which it advertises the LOGINDISABLED capability and does NOT permit which it advertises the LOGINDISABLED capability and does NOT permit
the LOGIN command. Server sites SHOULD NOT use any configuration the LOGIN command. Server sites SHOULD NOT use any configuration
which permits the LOGIN command without such a protection mechanism which permits the LOGIN command without such a protection mechanism
against password snooping. A client implementation MUST NOT send a against password snooping. A client implementation MUST NOT send a
LOGIN command if the LOGINDISABLED capability is advertised. LOGIN command if the LOGINDISABLED capability is advertised.
skipping to change at page 36, line 16 skipping to change at page 36, line 38
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 in Section 7.2.7 for more detail. FLAGS response in Section 7.3.5 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 in Section 7.3.1 for more description of the EXISTS response in Section 7.4.1 for more
detail. 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
skipping to change at page 40, line 25 skipping to change at page 41, line 5
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 (Section 7.2.3) attribute (see the description of the LIST response (Section 7.3.1)
for more 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.
skipping to change at page 45, line 26 skipping to change at page 46, line 19
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 responses 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 response (Section 7.2.3) for more detail. the description of the LIST response (Section 7.3.1) 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 45 skipping to change at page 48, line 41
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 name attribute (see the description of the LIST response
(Section 7.2.3) for more details). (Section 7.3.1) 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 52, line 9 skipping to change at page 52, line 52
S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach" S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
means that the "Fruit/Peach" mailbox doesn't exist, but it is means that the "Fruit/Peach" mailbox doesn't exist, but it is
subscribed. subscribed.
6.3.9.4. Additional LIST-related Requirements on Clients 6.3.9.4. Additional LIST-related Requirements on Clients
All clients MUST treat a LIST attribute with a stronger meaning as All clients MUST treat a LIST attribute with a stronger meaning as
implying any attribute that can be inferred from it. (See implying any attribute that can be inferred from it. (See
Section 7.2.3 for the list of currently defined attributes). For Section 7.3.1 for the list of currently defined attributes). For
example, the client must treat the presence of the \NoInferiors example, the client must treat the presence of the \NoInferiors
attribute as if the \HasNoChildren attribute was also sent by the attribute as if the \HasNoChildren attribute was also sent by the
server. server.
The following table summarizes inference rules. The following table summarizes inference rules.
+--------------------+-------------------+ +--------------------+-------------------+
| returned attribute | implied attribute | | returned attribute | implied attribute |
+--------------------+-------------------+ +--------------------+-------------------+
| \NoInferiors | \HasNoChildren | | \NoInferiors | \HasNoChildren |
skipping to change at page 63, line 20 skipping to change at page 63, line 41
Result: OK - command completed Result: OK - command completed
NO - Can't complete the command NO - Can't complete the command
BAD - arguments invalid BAD - arguments invalid
The NAMESPACE command causes a single untagged NAMESPACE response to The NAMESPACE command causes a single untagged NAMESPACE response to
be returned. The untagged NAMESPACE response contains the prefix and be returned. The untagged NAMESPACE response contains the prefix and
hierarchy delimiter to the server's Personal Namespace(s), Other hierarchy delimiter to the server's Personal Namespace(s), Other
Users' Namespace(s), and Shared Namespace(s) that the server wishes Users' Namespace(s), and Shared Namespace(s) that the server wishes
to expose. The response will contain a NIL for any namespace class to expose. The response will contain a NIL for any namespace class
that is not available. The Namespace-Response-Extensions ABNF non that is not available. The namespace-response-extensions ABNF non
terminal is defined for extensibility and MAY be included in the terminal is defined for extensibility and MAY be included in the
NAMESPACE response. NAMESPACE response.
Example 1: Example 1:
In this example a server supports a single personal namespace. No In this example a server supports a single personal namespace. No
leading prefix is used on personal mailboxes and "/" is the hierarchy leading prefix is used on personal mailboxes and "/" is the hierarchy
delimiter. delimiter.
C: A001 NAMESPACE C: A001 NAMESPACE
skipping to change at page 68, line 13 skipping to change at page 69, line 7
STATUS command can cause the mailbox to be opened internally, and STATUS command can cause the mailbox to be opened internally, and
because this information is available by other means on the because this information is available by other means on the
selected mailbox, the STATUS command SHOULD NOT be used on the selected mailbox, the STATUS command SHOULD NOT be used on the
currently selected mailbox. However, servers MUST be able to currently selected mailbox. However, servers MUST be able to
execute STATUS command on the selected mailbox. (This might also execute STATUS command on the selected mailbox. (This might also
implicitly happen when STATUS return option is used in a LIST implicitly happen when STATUS return option is used in a LIST
command). command).
The STATUS command MUST NOT be used as a "check for new messages The STATUS command MUST NOT be used as a "check for new messages
in the selected mailbox" operation (refer to Section 7 and in the selected mailbox" operation (refer to Section 7 and
Section 7.3.1 for more information about the proper method for new Section 7.4.1 for more information about the proper method for new
message checking). message checking).
STATUS SIZE (see below) can take a significant amount of time, STATUS SIZE (see below) can take a significant amount of time,
depending upon server implementation. Clients should use STATUS depending upon server implementation. Clients should use STATUS
SIZE cautiously. SIZE cautiously.
The currently defined status data items that can be requested are: The currently defined status data items that can be requested are:
MESSAGES The number of messages in the mailbox. MESSAGES The number of messages in the mailbox.
skipping to change at page 69, line 43 skipping to change at page 70, line 36
permitted. permitted.
If the destination mailbox does not exist, a server MUST return an If the destination mailbox does not exist, a server MUST return an
error, and MUST NOT automatically create the mailbox. Unless it is error, and MUST NOT automatically create the mailbox. Unless it is
certain that the destination mailbox can not be created, the server certain that the destination mailbox can not be created, the server
MUST send the response code "[TRYCREATE]" as the prefix of the text MUST send the response code "[TRYCREATE]" as the prefix of the text
of the tagged NO response. This gives a hint to the client that it of the tagged NO response. This gives a hint to the client that it
can attempt a CREATE command and retry the APPEND if the CREATE is can attempt a CREATE command and retry the APPEND if the CREATE is
successful. successful.
On successful completion of an APPEND, the server SHOULD return an On successful completion of an APPEND, the server returns an
APPENDUID response code (see Section 7.1). APPENDUID response code (see Section 7.1), unless specified otherwise
below.
In the case of a mailbox that has permissions set so that the client In the case of a mailbox that has permissions set so that the client
can APPEND to the mailbox, but not SELECT or EXAMINE it, the server can APPEND to the mailbox, but not SELECT or EXAMINE it, the server
SHOULD NOT send an APPENDUID response code as it would disclose MUST NOT send an APPENDUID response code as it would disclose
information about the mailbox. information about the mailbox.
In the case of a mailbox that has UIDNOTSTICKY status (see In the case of a mailbox that has UIDNOTSTICKY status (see
Section 7.1), the server MAY omit the APPENDUID response code as it Section 7.1), the server MAY omit the APPENDUID response code as it
is not meaningful. is not meaningful.
If the server does not return the APPENDUID response codes, the
client can discover this information by selecting the destination
mailbox. The location of messages placed in the destination mailbox
by APPEND can be determined by using FETCH and/or SEARCH commands
(e.g., for Message-ID or some unique marker placed in the message in
an APPEND).
If the mailbox is currently selected, the normal new message actions If the mailbox is currently selected, the normal new message actions
SHOULD occur. Specifically, the server SHOULD notify the client SHOULD occur. Specifically, the server SHOULD notify the client
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
skipping to change at page 75, line 29 skipping to change at page 76, 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 (Section 7.4.1) for set. See the description of the EXPUNGE response (Section 7.5.1) for
further 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
skipping to change at page 77, 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 a combination. This guaranty response if used by themselves or in combination. This guaranty
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 amalgamated. 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
1, 1994. A search key can also be a parenthesized list of one or 1, 1994. A search key can also be a parenthesized list of one or
more search keys (e.g., for use with the OR and NOT keys). more search keys (e.g., for use with the OR and NOT keys).
skipping to change at page 82, line 13 skipping to change at page 83, line 13
a successful SEARCH command with no SAVE result option. a successful SEARCH command with no SAVE result option.
A SEARCH command with the SAVE result option that caused the server A SEARCH command with the SAVE result option that caused the server
to return the NO tagged response sets the value of the search result to return the NO tagged response sets the value of the search result
variable to the empty sequence. variable to the empty sequence.
When a message listed in the search result variable is EXPUNGEd, it When a message listed in the search result variable is EXPUNGEd, it
is automatically removed from the list. Implementors are reminded is automatically removed from the list. Implementors are reminded
that if the server stores the list as a list of message numbers, it that if the server stores the list as a list of message numbers, it
MUST automatically adjust them when notifying the client about MUST automatically adjust them when notifying the client about
expunged messages, as described in Section 7.4.1. expunged messages, as described in Section 7.5.1.
If the server decides to send a new UIDVALIDITY value while the If the server decides to send a new UIDVALIDITY value while the
mailbox is opened, this causes resetting of the search variable to mailbox is opened, this causes resetting of the search variable to
the empty sequence. the empty sequence.
Note that even if the "$" marker contains the empty sequence of Note that even if the "$" marker contains the empty sequence of
messages, it must be treated by all commands accepting message sets messages, it must be treated by all commands accepting message sets
as parameters as a valid, but non-matching list of messages. For as parameters as a valid, but non-matching list of messages. For
example, the "FETCH $" command would return a tagged OK response and example, the "FETCH $" command would return a tagged OK response and
no FETCH responses. See also the Example 5 in Section 6.4.4.4. no FETCH responses. See also the Example 5 in Section 6.4.4.4.
skipping to change at page 90, line 7 skipping to change at page 91, line 7
subsetting the header. subsetting the header.
The \Seen flag is implicitly set; if this causes the flags to The \Seen flag is implicitly set; if this causes the flags to
change, they SHOULD be included as part of the FETCH responses. change, they SHOULD be included as part of the FETCH responses.
BODY.PEEK[<section>]<<partial>> An alternate form of BODY[<section>] BODY.PEEK[<section>]<<partial>> An alternate form of BODY[<section>]
that does not implicitly set the \Seen flag. that does not implicitly set the \Seen flag.
BODYSTRUCTURE The [MIME-IMB] body structure of the message. This is BODYSTRUCTURE The [MIME-IMB] body structure of the message. This is
computed by the server by parsing the [MIME-IMB] header fields in computed by the server by parsing the [MIME-IMB] header fields in
the [RFC-5322] header and [MIME-IMB] headers. See Section 7.4.2 the [RFC-5322] header and [MIME-IMB] headers. See Section 7.5.2
for more details. for more details.
ENVELOPE The envelope structure of the message. This is computed by ENVELOPE The envelope structure of the message. This is computed by
the server by parsing the [RFC-5322] header into the component the server by parsing the [RFC-5322] header into the component
parts, defaulting various fields as necessary. See Section 7.4.2 parts, defaulting various fields as necessary. See Section 7.5.2
for more details. for more details.
FLAGS The flags that are set for this message. FLAGS The flags that are set for this message.
INTERNALDATE The internal date of the message. INTERNALDATE The internal date of the message.
RFC822.SIZE The [RFC-5322] size of the message. RFC822.SIZE The [RFC-5322] size of the message.
UID The unique identifier for the message. UID The unique identifier for the message.
skipping to change at page 93, line 27 skipping to change at page 94, line 27
Result: OK - copy completed Result: OK - copy completed
NO - copy error: can't copy those messages or to that NO - copy error: can't copy those messages or to that
name name
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
The COPY command copies the specified message(s) to the end of the The COPY command copies the specified message(s) to the end of the
specified destination mailbox. The flags and internal date of the specified destination mailbox. The flags and internal date of the
message(s) SHOULD be preserved in the copy. message(s) SHOULD be preserved in the copy.
If the destination mailbox does not exist, a server SHOULD return an If the destination mailbox does not exist, a server MUST return an
error. It SHOULD NOT automatically create the mailbox. Unless it is error. It MUST NOT automatically create the mailbox. Unless it is
certain that the destination mailbox can not be created, the server certain that the destination mailbox can not be created, the server
MUST send the response code "[TRYCREATE]" as the prefix of the text MUST send the response code "[TRYCREATE]" as the prefix of the text
of the tagged NO response. This gives a hint to the client that it of the tagged NO response. This gives a hint to the client that it
can attempt a CREATE command and retry the COPY if the CREATE is can attempt a CREATE command and retry the COPY if the CREATE is
successful. successful.
If the COPY command is unsuccessful for any reason, server If the COPY command is unsuccessful for any reason, server
implementations MUST restore the destination mailbox to its state implementations MUST restore the destination mailbox to its state
before the COPY attempt. before the COPY attempt (other than possibly incrementing UIDNEXT),
i.e. partial copy MUST NOT be done.
On successful completion of a COPY, the server SHOULD return a On successful completion of a COPY, the server returns a COPYUID
COPYUID response code (see Section 7.1). response code (see Section 7.1). Two exception to this requirement
are listed below.
In the case of a mailbox that has permissions set so that the client In the case of a mailbox that has permissions set so that the client
can COPY to the mailbox, but not SELECT or EXAMINE it, the server can COPY to the mailbox, but not SELECT or EXAMINE it, the server
SHOULD NOT send an COPYUID response code as it would disclose MUST NOT send an COPYUID response code as it would disclose
information about the mailbox. information about the mailbox.
In the case of a mailbox that has UIDNOTSTICKY status (see In the case of a mailbox that has UIDNOTSTICKY status (see
Section 7.1), the server MAY omit the COPYUID response code as it is Section 7.1), the server MAY omit the COPYUID response code as it is
not meaningful. not meaningful.
If the server does not return the COPYUID response code, the client Example: C: A003 COPY 2:4 MEETING
can discover this information by selecting the destination mailbox. S: A003 OK [COPYUID 38505 304,319:320 3956:3958] COPY completed
The location of messages placed in the destination mailbox by COPY
can be determined by using FETCH and/or SEARCH commands (e.g., for
Message-ID).
Example: C: A003 COPY 2:4 MEETING
S: A003 OK COPY completed
6.4.8. MOVE Command 6.4.8. MOVE Command
Arguments: sequence set Arguments: sequence set
mailbox name mailbox name
Responses: no specific responses for this command Responses: no specific responses for this command
Result: OK - move completed Result: OK - move completed
NO - move error: can't move those messages or to that NO - move error: can't move those messages or to that
skipping to change at page 94, line 46 skipping to change at page 95, line 42
3. UID EXPUNGE 3. UID EXPUNGE
Although the effect of the MOVE is the same as the preceding steps, Although the effect of the MOVE is the same as the preceding steps,
the semantics are not identical: The intermediate states produced by the semantics are not identical: The intermediate states produced by
those steps do not occur, and the response codes are different. In those steps do not occur, and the response codes are different. In
particular, though the COPY and EXPUNGE response codes will be particular, though the COPY and EXPUNGE response codes will be
returned, response codes for a STORE MUST NOT be generated and the returned, response codes for a STORE MUST NOT be generated and the
\Deleted flag MUST NOT be set for any message. \Deleted flag MUST NOT be set for any message.
Because a MOVE applies to a set of messages, it might fail partway Unlike the COPY command, MOVE of a set of messages might fail partway
through the set. Regardless of whether the command is successful in through the set. Regardless of whether the command is successful in
moving the entire set, each individual message SHOULD either be moved moving the entire set, each individual message MUST either be moved
or unaffected. The server MUST leave each message in a state where or unaffected. The server MUST leave each message in a state where
it is in at least one of the source or target mailboxes (no message it is in at least one of the source or target mailboxes (no message
can be lost or orphaned). The server SHOULD NOT leave any message in can be lost or orphaned). The server SHOULD NOT leave any message in
both mailboxes (it would be bad for a partial failure to result in a both mailboxes (it would be bad for a partial failure to result in a
bunch of duplicate messages). This is true even if the server bunch of duplicate messages). This is true even if the server
returns a tagged NO response to the command. returns a tagged NO response to the command.
If the destination mailbox does not exist, a server MUST return an
error. It MUST NOT automatically create the mailbox. Unless it is
certain that the destination mailbox can not be created, the server
MUST send the response code "[TRYCREATE]" as the prefix of the text
of the tagged NO response. This gives a hint to the client that it
can attempt a CREATE command and retry the MOVE if the CREATE is
successful.
Because of the similarity of MOVE to COPY, extensions that affect Because of the similarity of MOVE to COPY, extensions that affect
COPY affect MOVE in the same way. Response codes such as TRYCREATE COPY affect MOVE in the same way. Response codes listed in
(see Section 7.1), as well as those defined by extensions, are sent Section 7.1, as well as those defined by extensions, are sent as
as appropriate. appropriate.
Servers SHOULD send COPYUID in response to a UID MOVE (see Servers send COPYUID in response to a MOVE or a UID MOVE (see
Section 6.4.9) command. For additional information see Section 7.1. Section 6.4.9) command. For additional information about COPYUID see
Section 7.1. Note that there are several exceptions listed in
Section 6.4.7 that allow servers not to return COPYUID.
Servers are also advised to send the COPYUID response code in an Servers are also REQUIRED to send the COPYUID response code in an
untagged OK before sending EXPUNGE or moved responses. (Sending untagged OK before sending EXPUNGE or similar responses. (Sending
COPYUID in the tagged OK, as described in the UIDPLUS specification, COPYUID in the tagged OK, as described in the UIDPLUS specification,
means that clients first receive an EXPUNGE for a message and means that clients first receive an EXPUNGE for a message and
afterwards COPYUID for the same message. It can be unnecessarily afterwards COPYUID for the same message. It can be unnecessarily
difficult to process that sequence usefully.) difficult to process that sequence usefully.)
An example: An example:
C: a UID MOVE 42:69 foo C: a UID MOVE 42:69 foo
S: * OK [COPYUID 432432 42:69 1202:1229] S: * OK [COPYUID 432432 42:69 1202:1229]
S: * 22 EXPUNGE S: * 22 EXPUNGE
S: (more expunges) ...More EXPUNGE responses from the server...
S: a OK Done S: a OK Done
Note that the server may send unrelated EXPUNGE responses as well, if Note that the server may send unrelated EXPUNGE responses as well, if
any happen to have been expunged at the same time; this is normal any happen to have been expunged at the same time; this is normal
IMAP operation. IMAP operation.
Note that moving a message to the currently selected mailbox (that Note that moving a message to the currently selected mailbox (that
is, where the source and target mailboxes are the same) is allowed is, where the source and target mailboxes are the same) is allowed
when copying the message to the currently selected mailbox is when copying the message to the currently selected mailbox is
allowed. allowed.
skipping to change at page 98, line 44 skipping to change at page 100, line 10
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
that does not indicate the completion of a command (for example, an that does not indicate the completion of a command (for example, an
impending system shutdown alert). For historical reasons, untagged impending system shutdown alert). For historical reasons, untagged
server data responses are also called "unsolicited data", although server data responses are also called "unsolicited data", although
strictly speaking, only unilateral server data is truly strictly speaking, only unilateral server data is truly
"unsolicited". "unsolicited".
Certain server data MUST be recorded by the client when it is Certain server data MUST be remembered by the client when it is
received; this is noted in the description of that data. Such data received; this is noted in the description of that data. Such data
conveys critical information which affects the interpretation of all conveys critical information which affects the interpretation of all
subsequent commands and responses (e.g., updates reflecting the subsequent commands and responses (e.g., updates reflecting the
creation or destruction of messages). creation or destruction of messages).
Other server data SHOULD be recorded for later reference; if the Other server data SHOULD be remembered for later reference; if the
client does not need to record the data, or if recording the data has client does not need to remember the data, or if remembering the data
no obvious purpose (e.g., a SEARCH response when no SEARCH command is has no obvious purpose (e.g., a SEARCH response when no SEARCH
in progress), the data SHOULD be ignored. command is in progress), the data can be ignored.
An example of unilateral untagged server data occurs when the IMAP An example of unilateral untagged server data occurs when the IMAP
connection is in the selected state. In the selected state, the connection is in the selected state. In the selected state, the
server checks the mailbox for new messages as part of command server checks the mailbox for new messages as part of command
execution. Normally, this is part of the execution of every command; execution. Normally, this is part of the execution of every command;
hence, a NOOP command suffices to check for new messages. If new hence, a NOOP command suffices to check for new messages. If new
messages are found, the server sends untagged EXISTS response messages are found, the server sends untagged EXISTS response
reflecting the new size of the mailbox. Server implementations that reflecting the new size of the mailbox. Server implementations that
offer multiple simultaneous access to the same mailbox SHOULD also offer multiple simultaneous access to the same mailbox SHOULD also
send appropriate unilateral untagged FETCH and EXPUNGE responses if send appropriate unilateral untagged FETCH and EXPUNGE responses if
another agent changes the state of any message flags or expunges any another agent changes the state of any message flags or expunges any
messages. messages.
Command continuation request responses use the token "+" instead of a Command continuation request responses use the token "+" instead of a
tag. These responses are sent by the server to indicate acceptance tag. These responses are sent by the server to indicate acceptance
of an incomplete client command and readiness for the remainder of of an incomplete client command and readiness for the remainder of
the command. the command.
7.1. Server Responses - Status Responses 7.1. Server Responses - Generic Status Responses
Status responses are OK, NO, BAD, PREAUTH and BYE. OK, NO, and BAD Status responses are OK, NO, BAD, PREAUTH and BYE. OK, NO, and BAD
can be tagged or untagged. PREAUTH and BYE are always untagged. can be tagged or untagged. PREAUTH and BYE are always untagged.
Status responses MAY include an OPTIONAL "response code". A response Status responses MAY include an OPTIONAL "response code". A response
code consists of data inside square brackets in the form of an atom, code consists of data inside square brackets in the form of an atom,
possibly followed by a space and arguments. The response code possibly followed by a space and arguments. The response code
contains additional information or status codes for client software contains additional information or status codes for client software
beyond the OK/NO/BAD condition, and are defined when there is a beyond the OK/NO/BAD condition, and are defined when there is a
specific action that a client can take based upon the additional specific action that a client can take based upon the additional
information. information.
The currently defined response codes are: The currently defined response codes are:
ALERT ALERT
The human-readable text contains a special alert that MUST be The human-readable text contains a special alert that are
presented to the user in a fashion that calls the user's presented to the user in a fashion that calls the user's
attention to the message. attention to the message. Content of ALERT response codes
received on a connection without TLS or SASL security layer
confidentiality SHOULD be ignored by clients. If displayed,
such alerts MUST be clearly marked as potentially suspicious.
(Note that some existing clients are known to hyperlink
returned text which make them very dangerous.) Alerts received
after successful establishment of a TLS/SASL confidentiality
layer MUST be presented to the user.
ALREADYEXISTS ALREADYEXISTS
The operation attempts to create something that already exists, The operation attempts to create something that already exists,
such as when the CREATE or RENAME directories attempt to create such as when the CREATE or RENAME directories attempt to create
a mailbox and there is already one of that name. a mailbox and there is already one of that name.
C: o356 RENAME this that C: o356 RENAME this that
S: o356 NO [ALREADYEXISTS] Mailbox "that" already exists S: o356 NO [ALREADYEXISTS] Mailbox "that" already exists
skipping to change at page 102, line 33 skipping to change at page 104, line 4
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 and containing the
UIDs assigned to the copied message(s) in the destination UIDs assigned to the copied message(s) in the destination
mailbox, indicates that the message(s) have been copied to the mailbox, indicates that the message(s) have been copied to the
destination mailbox with the stated UID(s). 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.
This response code is returned in a tagged OK response to the This response code is returned in a tagged OK response to the
COPY command. COPY/UID COPY command or in the untagged OK response to the
MOVE/UID MOVE command.
CORRUPTION CORRUPTION
The server discovered that some relevant data (e.g., the The server discovered that some relevant data (e.g., the
mailbox) are corrupt. This response code does not include any mailbox) are corrupt. This response code does not include any
information about what's corrupt, but the server can write that information about what's corrupt, but the server can write that
to its logfiles. to its logfiles.
C: i select "/archive/projects/experiment-iv" C: i select "/archive/projects/experiment-iv"
S: i NO [CORRUPTION] Cannot open mailbox S: i NO [CORRUPTION] Cannot open mailbox
skipping to change at page 106, line 20 skipping to change at page 107, line 34
SERVERBUG SERVERBUG
The server encountered a bug in itself or violated one of its The server encountered a bug in itself or violated one of its
own invariants. own invariants.
C: j select "/archive/projects/experiment-iv" C: j select "/archive/projects/experiment-iv"
S: j NO [SERVERBUG] This should not happen S: j NO [SERVERBUG] This should not happen
TRYCREATE TRYCREATE
An APPEND or COPY attempt is failing because the target mailbox An APPEND, COPY or MOVE attempt is failing because the target
does not exist (as opposed to some other reason). This is a mailbox does not exist (as opposed to some other reason). This
hint to the client that the operation can succeed if the is a hint to the client that the operation can succeed if the
mailbox is first created by the CREATE command. mailbox is first created by the CREATE command.
UIDNEXT UIDNEXT
Followed by a decimal number, indicates the next unique Followed by a decimal number, indicates the next unique
identifier value. Refer to Section 2.3.1.1 for more identifier value. Refer to Section 2.3.1.1 for more
information. information.
UIDNOTSTICKY UIDNOTSTICKY
skipping to change at page 108, line 46 skipping to change at page 110, line 15
7.1.4. PREAUTH Response 7.1.4. PREAUTH Response
Contents: OPTIONAL response code Contents: OPTIONAL response code
human-readable text human-readable text
The PREAUTH response is always untagged, and is one of three possible The PREAUTH response is always untagged, and is one of three possible
greetings at connection startup. It indicates that the connection greetings at connection startup. It indicates that the connection
has already been authenticated by external means; thus no LOGIN/ has already been authenticated by external means; thus no LOGIN/
AUTHENTICATE command is needed. AUTHENTICATE command is needed.
Because PREAUTH moves the connection directly to the authenticated
state, it effectively prevents the client from using the STARTTLS
command Section 6.2.1. For this reason PREAUTH response SHOULD only
be returned by servers on connections that are protected by TLS (such
as on IMAPS port [RFC8314]) or protected through other means such as
IPSec. Clients that require mandatory TLS MUST close the connection
after receiving PREAUTH response on a non protected port.
Example: S: * PREAUTH IMAP4rev2 server logged in as Smith Example: S: * PREAUTH IMAP4rev2 server logged in as Smith
7.1.5. BYE Response 7.1.5. BYE Response
Contents: OPTIONAL response code Contents: OPTIONAL response code
human-readable text human-readable text
The BYE response is always untagged, and indicates that the server is The BYE response is always untagged, and indicates that the server is
about to close the connection. The human-readable text MAY be about to close the connection. The human-readable text MAY be
displayed to the user in a status report by the client. The BYE displayed to the user in a status report by the client. The BYE
skipping to change at page 109, line 39 skipping to change at page 111, line 10
The difference between a BYE that occurs as part of a normal LOGOUT The difference between a BYE that occurs as part of a normal LOGOUT
sequence (the first case) and a BYE that occurs because of a failure sequence (the first case) and a BYE that occurs because of a failure
(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 and Mailbox 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 and mailbox
status data are transmitted from the server to the client. Many of status data are transmitted from the server to the client.
these responses typically result from a command with the same name.
7.2.1. The 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.
Example: S: * ENABLED CONDSTORE QRESYNC
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", but note that it doesn't have to MUST include the atom "IMAP4rev2", but note that it doesn't have to
be the first capability listed. be the first capability listed. The order of capability names has no
significance.
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 11) for capabilities. See the Security Considerations (Section 11) for
important information related to these capabilities. 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 [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
skipping to change at page 110, line 51 skipping to change at page 112, line 24
than "IMAP4rev2", "STARTTLS", "LOGINDISABLED". Client than "IMAP4rev2", "STARTTLS", "LOGINDISABLED". Client
implementations MUST ignore any unknown capability names. 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 The list of capabilities returned by a server MAY change during the
connection. In particular, it is quite common for the server to
change list of capabilities after successful TLS negotiation
(STARTTLS command) and/or after successful authentication
(AUTHENTICATE or LOGIN commands).
7.2.3. LIST Response Example: S: * CAPABILITY STARTTLS AUTH=GSSAPI IMAP4rev2 LOGINDISABLED
XPIG-LATIN
Note that in the above example XPIG-LATIN is a fictitious capability
name.
7.3. Server Responses - Mailbox Status
These responses are always untagged. This is how server and mailbox
status data are transmitted from the server to the client. Many of
these responses typically result from a command with the same name.
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
multiple LIST responses for a single LIST command. multiple LIST responses for a single LIST command.
skipping to change at page 114, line 46 skipping to change at page 116, line 36
responses. The client MUST ignore all extended fields it doesn't responses. The client MUST ignore all extended fields it doesn't
recognize. recognize.
Example: S: * LIST (\Noselect) "/" ~/Mail/foo Example: S: * LIST (\Noselect) "/" ~/Mail/foo
Example: S: * LIST (\Marked) ":" Tables (tablecloth (("edge" "lacy") Example: S: * LIST (\Marked) ":" Tables (tablecloth (("edge" "lacy")
("color" "red")) Sample "text") ("color" "red")) Sample "text")
S: * LIST () ":" Tables:new (tablecloth ("edge" "lacy") S: * LIST () ":" Tables:new (tablecloth ("edge" "lacy")
Sample ("text" "more text")) Sample ("text" "more text"))
7.2.4. NAMESPACE Response 7.3.2. NAMESPACE Response
Contents: the prefix and hierarchy delimiter to the server's Contents: the prefix and hierarchy delimiter to the server's
Personal Namespace(s), Other Users' Namespace(s), and Personal Namespace(s), Other Users' Namespace(s), and
Shared Namespace(s) Shared Namespace(s)
The NAMESPACE response occurs as a result of a NAMESPACE command. It The NAMESPACE response occurs as a result of a NAMESPACE command. It
contains the prefix and hierarchy delimiter to the server's Personal contains the prefix and hierarchy delimiter to the server's Personal
Namespace(s), Other Users' Namespace(s), and Shared Namespace(s) that Namespace(s), Other Users' Namespace(s), and Shared Namespace(s) that
the server wishes to expose. The response will contain a NIL for any the server wishes to expose. The response will contain a NIL for any
namespace class that is not available. Namespace-Response-Extensions namespace class that is not available. Namespace-Response-Extensions
ABNF non terminal is defined for extensibility and MAY be included in ABNF non terminal is defined for extensibility and MAY be included in
the response. the response.
Example: S: * NAMESPACE (("" "/")) (("~" "/")) NIL Example: S: * NAMESPACE (("" "/")) (("~" "/")) NIL
7.2.5. STATUS Response 7.3.3. STATUS Response
Contents: name Contents: name
status parenthesized list status parenthesized list
The STATUS response occurs as a result of an STATUS command. It The STATUS response occurs as a result of an STATUS command. It
returns the mailbox name that matches the STATUS specification and returns the mailbox name that matches the STATUS specification and
the requested mailbox status information. the requested mailbox status information.
Example: S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292) Example: S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
7.2.6. ESEARCH Response 7.3.4. ESEARCH Response
Contents: one or more search-return-data pairs Contents: one or more search-return-data pairs
The ESEARCH response occurs as a result of a SEARCH or UID SEARCH The ESEARCH response occurs as a result of a SEARCH or UID SEARCH
command. command.
The ESEARCH response starts with an optional search correlator. If The ESEARCH response starts with an optional search correlator. If
it is missing, then the response was not caused by a particular IMAP it is missing, then the response was not caused by a particular IMAP
command, whereas if it is present, it contains the tag of the command command, whereas if it is present, it contains the tag of the command
that caused the response to be returned. that caused the response to be returned.
skipping to change at page 116, line 4 skipping to change at page 117, line 39
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.]] [[TBD: describe the most common search data pairs returned.]]
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.2.7. FLAGS Response 7.3.5. FLAGS Response
Contents: flag parenthesized list Contents: flag parenthesized list
The FLAGS response occurs as a result of a SELECT or EXAMINE command. The FLAGS response occurs as a result of a SELECT or EXAMINE command.
The flag parenthesized list identifies the flags (at a minimum, the The flag parenthesized list identifies the flags (at a minimum, the
system-defined flags) that are applicable for this mailbox. Flags system-defined flags) that are applicable for this mailbox. Flags
other than the system flags can also exist, depending on server other than the system flags can also exist, depending on server
implementation. implementation.
The update from the FLAGS response MUST be recorded by the client. The update from the FLAGS response MUST be remembered by the client.
Example: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) Example: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
7.3. Server Responses - Mailbox Size 7.4. Server Responses - Mailbox Size
These responses are always untagged. This is how changes in the size These responses are always untagged. This is how changes in the size
of the mailbox are transmitted from the server to the client. of the mailbox are transmitted from the server to the client.
Immediately following the "*" token is a number that represents a Immediately following the "*" token is a number that represents a
message count. message count.
7.3.1. EXISTS Response 7.4.1. EXISTS Response
Contents: none Contents: none
The EXISTS response reports the number of messages in the mailbox. The EXISTS response reports the number of messages in the mailbox.
This response occurs as a result of a SELECT or EXAMINE command, and This response occurs as a result of a SELECT or EXAMINE command, and
if the size of the mailbox changes (e.g., new messages). if the size of the mailbox changes (e.g., new messages).
The update from the EXISTS response MUST be recorded by the client. The update from the EXISTS response MUST be remembered by the client.
Example: S: * 23 EXISTS Example: S: * 23 EXISTS
7.4. Server Responses - Message Status 7.5. Server Responses - Message Status
These responses are always untagged. This is how message data are These responses are always untagged. This is how message data are
transmitted from the server to the client, often as a result of a transmitted from the server to the client, often as a result of a
command with the same name. Immediately following the "*" token is a command with the same name. Immediately following the "*" token is a
number that represents a message sequence number. number that represents a message sequence number.
7.4.1. EXPUNGE Response 7.5.1. EXPUNGE Response
Contents: none Contents: none
The EXPUNGE response reports that the specified message sequence The EXPUNGE response reports that the specified message sequence
number has been permanently removed from the mailbox. The message number has been permanently removed from the mailbox. The message
sequence number for each successive message in the mailbox is sequence number for each successive message in the mailbox is
immediately decremented by 1, and this decrement is reflected in immediately decremented by 1, and this decrement is reflected in
message sequence numbers in subsequent responses (including other message sequence numbers in subsequent responses (including other
untagged EXPUNGE responses). untagged EXPUNGE responses).
skipping to change at page 117, line 42 skipping to change at page 119, line 27
is necessary to prevent a loss of synchronization of message sequence is necessary to prevent a loss of synchronization of message sequence
numbers between client and server. A command is not "in progress" numbers between client and server. A command is not "in progress"
until the complete command has been received; in particular, a until the complete command has been received; in particular, a
command is not "in progress" during the negotiation of command command is not "in progress" during the negotiation of command
continuation. continuation.
Note: UID FETCH, UID STORE, and UID SEARCH are different commands Note: UID FETCH, UID STORE, and UID SEARCH are different commands
from FETCH, STORE, and SEARCH. An EXPUNGE response MAY be sent from FETCH, STORE, and SEARCH. An EXPUNGE response MAY be sent
during a UID command. during a UID command.
The update from the EXPUNGE response MUST be recorded by the client. The update from the EXPUNGE response MUST be remembered by the
client.
Example: S: * 44 EXPUNGE Example: S: * 44 EXPUNGE
7.4.2. FETCH Response 7.5.2. FETCH Response
Contents: message data Contents: message data
The FETCH response returns data about a message to the client. The The FETCH response returns data about a message to the client. The
data are pairs of data item names and their values in parentheses. data are pairs of data item names and their values in parentheses.
This response occurs as the result of a FETCH or STORE command, as This response occurs as the result of a FETCH or STORE command, as
well as by unilateral server decision (e.g., flag updates). well as by unilateral server decision (e.g., flag updates).
The current data items are: The current data items are:
BINARY[<section-binary>]<<number>> BINARY[<section-binary>]<<number>>
An <nstring> or <literal8> expressing the content of the An <nstring> or <literal8> expressing the content of the
specified section after removing any Content-Transfer-Encoding- specified section after removing any Content-Transfer-Encoding-
related encoding. If <number> is present it refers to the related encoding. If <number> is present it refers to the
skipping to change at page 123, line 45 skipping to change at page 125, line 28
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)
7.5. 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
response is also used if an argument to any command is a response is also used if an argument to any command is a
synchronizing literal. synchronizing literal.
skipping to change at page 126, line 23 skipping to change at page 128, line 23
(1) Except as noted otherwise, all alphabetic characters are case- (1) Except as noted otherwise, all alphabetic characters are case-
insensitive. The use of upper or lower case characters to define insensitive. The use of upper or lower case characters to define
token strings is for editorial clarity only. Implementations MUST token strings is for editorial clarity only. Implementations MUST
accept these strings in a case-insensitive fashion. accept these strings in a case-insensitive fashion.
(2) In all cases, SP refers to exactly one space. It is NOT (2) In all cases, SP refers to exactly one space. It is NOT
permitted to substitute TAB, insert additional spaces, or permitted to substitute TAB, insert additional spaces, or
otherwise treat SP as being equivalent to LWSP. otherwise treat SP as being equivalent to LWSP.
(3) The ASCII NUL character, %x00, MUST NOT be used at any time. (3) The ASCII NUL character, %x00, MUST NOT be used anywhere, with
the exception of the OCTET production.
SP = <Defined in RFC 5234>
CTL = <Defined in RFC 5234>
CRLF = <Defined in RFC 5234>
ALPHA = <Defined in RFC 5234>
DIGIT = <Defined in RFC 5234>
DQUOTE = <Defined in RFC 5234>
OCTET = <Defined in RFC 5234>
address = "(" addr-name SP addr-adl SP addr-mailbox SP address = "(" addr-name SP addr-adl SP addr-mailbox SP
addr-host ")" addr-host ")"
addr-adl = nstring addr-adl = nstring
; Holds route from [RFC-5322] obs-route if ; Holds route from [RFC-5322] obs-route if
; non-NIL ; non-NIL
addr-host = nstring addr-host = nstring
; NIL indicates [RFC-5322] group syntax. ; NIL indicates [RFC-5322] group syntax.
skipping to change at page 135, line 31 skipping to change at page 137, line 40
"BODY" ["STRUCTURE"] SP body / "BODY" ["STRUCTURE"] SP body /
"BODY" section ["<" number ">"] SP nstring / "BODY" section ["<" number ">"] SP nstring /
"BINARY" section-binary SP (nstring / literal8) / "BINARY" section-binary SP (nstring / literal8) /
"BINARY.SIZE" section-binary SP number / "BINARY.SIZE" section-binary SP number /
"UID" SP uniqueid "UID" SP uniqueid
; MUST NOT change for a message ; MUST NOT change for a message
name-component = 1*UTF8-CHAR name-component = 1*UTF8-CHAR
; MUST NOT contain ".", "/", "%", or "*" ; MUST NOT contain ".", "/", "%", or "*"
Namespace = nil / "(" 1*Namespace-Descr ")" namespace = nil / "(" 1*namespace-descr ")"
Namespace-Command = "NAMESPACE" namespace-command = "NAMESPACE"
Namespace-Descr = "(" string SP namespace-descr = "(" string SP
(DQUOTE QUOTED-CHAR DQUOTE / nil) (DQUOTE QUOTED-CHAR DQUOTE / nil)
[Namespace-Response-Extensions] ")" [namespace-response-extensions] ")"
Namespace-Response-Extensions = *Namespace-Response-Extension namespace-response-extensions = *namespace-response-extension
Namespace-Response-Extension = SP string SP namespace-response-extension = SP string SP
"(" string *(SP string) ")" "(" string *(SP string) ")"
Namespace-Response = "NAMESPACE" SP Namespace namespace-response = "NAMESPACE" SP namespace
SP Namespace SP Namespace SP namespace SP namespace
; The first Namespace is the Personal Namespace(s). ; The first Namespace is the Personal Namespace(s).
; The second Namespace is the Other Users' ; The second Namespace is the Other Users'
; Namespace(s). ; Namespace(s).
; The third Namespace is the Shared Namespace(s). ; The third Namespace is the Shared Namespace(s).
nil = "NIL" nil = "NIL"
nstring = string / nil nstring = string / nil
number = 1*DIGIT number = 1*DIGIT
; Unsigned 32-bit integer ; Unsigned 32-bit integer
; (0 <= n < 4,294,967,296) ; (0 <= n < 4,294,967,296)
number64 = 1*DIGIT number64 = 1*DIGIT
; Unsigned 63-bit integer ; Unsigned 63-bit integer
; (0 <= n <= 9,223,372,036,854,775,807) ; (0 <= n <= 9,223,372,036,854,775,807)
skipping to change at page 143, line 12 skipping to change at page 145, line 21
; between these two regards of order. ; between these two regards of order.
; Example: 2:4 and 4:2 are equivalent. ; Example: 2:4 and 4:2 are equivalent.
uniqueid = nz-number uniqueid = nz-number
; Strictly ascending ; Strictly ascending
unsubscribe = "UNSUBSCRIBE" SP mailbox unsubscribe = "UNSUBSCRIBE" SP mailbox
userid = astring userid = astring
UTF8-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
skipping to change at page 143, line 47 skipping to change at page 146, line 13
RFC 1064. RFC 1064.
11. Security Considerations 11. Security Considerations
IMAP4rev2 protocol transactions, including electronic mail data, are IMAP4rev2 protocol transactions, including electronic mail data, are
sent in the clear over the network unless protection from snooping is sent in the clear over the network unless protection from snooping is
negotiated. This can be accomplished either by the use of IMAPS negotiated. This can be accomplished either by the use of IMAPS
service, STARTTLS command, negotiated privacy protection in the service, STARTTLS command, negotiated privacy protection in the
AUTHENTICATE command, or some other protection mechanism. AUTHENTICATE command, or some other protection mechanism.
11.1. STARTTLS Security Considerations 11.1. TLS related Security Considerations
This section applies to both use of STARTTLS command and Implicit TLS
port.
IMAP client and server implementations MUST comply with relevant TLS IMAP client and server implementations MUST comply with relevant TLS
recommendations from [RFC8314]. recommendations from [RFC8314].
Clients and servers MUST implement TLS 1.2 [TLS-1.2] or newer. Use Clients and servers MUST implement TLS 1.2 [TLS-1.2] or newer. Use
of TLS 1.3 [TLS-1.3] is RECOMMENDED. TLS 1.2 may be used only in of TLS 1.3 [TLS-1.3] is RECOMMENDED. TLS 1.2 may be used only in
cases where the other party has not yet implemented TLS 1.3. cases where the other party has not yet implemented TLS 1.3.
Additionally, when using TLS 1.2, IMAP implementations MUST implement Additionally, when using TLS 1.2, IMAP implementations MUST implement
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite, and SHOULD TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite. This is
implement the TLS_RSA_WITH_AES_128_CBC_SHA [TLS-1.2] cipher suite. important as it assures that any two compliant implementations can be
This is important as it assures that any two compliant configured to interoperate. Other TLS cipher suites recommended in
implementations can be configured to interoperate. Other TLS cipher RFC 7525 are RECOMMENDED: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
suites recommended in RFC 7525 are RECOMMENDED:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 and TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 and
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. All other cipher suites are TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. All other cipher suites are
OPTIONAL. Note that this is a change from section 2.1 of [IMAP-TLS]. OPTIONAL. Note that this is a change from section 2.1 of [IMAP-TLS].
The list of mandatory-to-implement TLS 1.3 cipher suites is described The list of mandatory-to-implement TLS 1.3 cipher suites is described
in Section 9.1 of [TLS-1.3]. in Section 9.1 of [TLS-1.3].
During the TLS negotiation [TLS-1.3][TLS-1.2], the client MUST check During the TLS negotiation [TLS-1.3][TLS-1.2], the client MUST check
its understanding of the server hostname against the server's its understanding of the server hostname against the server's
identity as presented in the server Certificate message, in order to identity as presented in the server Certificate message, in order to
prevent man-in-the-middle attacks. This procedure is described in prevent man-in-the-middle attacks. This procedure is described in
[RFC7817]. [RFC7817].
Both the client and server MUST check the result of the STARTTLS Both the client and server MUST check the result of the STARTTLS
command and subsequent TLS ([TLS-1.3][TLS-1.2]) negotiation to see command and subsequent TLS ([TLS-1.3][TLS-1.2]) negotiation to see
whether acceptable authentication and/or privacy was achieved. whether acceptable authentication and/or privacy was achieved.
11.2. COPYUID and APPENDUID response codes 11.2. STARTTLS command versa use of Implicit TLS port
For maximum backward compatibility clients MUST implement both TLS
negotiation using STARTTLS command and on implicit TLS port.
Servers MUST support TLS negotiation on implicit TLS port and SHOULD
support STARTTLS command.
Some site/firewall maintainers insist on TLS site-wide and prefer not
to rely on a configuration option in each higher-level protocol. For
this reason, IMAP4rev2 clients SHOULD try both ports 993 and 143 (and
both IPv4 and IPv6) concurrently by default, unless overriden by
either user configuration or SRV records. Note that if a server
answers on both ports, it MUST allow STARTTLS command on port 143.
11.3. Client handling of unsolicited responses not suitable for the
current connection state
Cleartext mail transmission (whether caused by firewall configuration
errors that result in TLS stripping or weak security policies in
email clients that choose not to negotiate TLS in the first place)
can enable injection of responses that can confuse or even cause
crashes in email clients. The following measures are recommended to
minimize damage from them.
See Section 7.1.4 for special security considerations related to
PREAUTH response.
Many server responses and response codes are only meaningful in
authenticated or even selected state. However, nothing prevents a
server (or a man-in-the-middle attacker) from sending such invalid
responses in cleartext before STARTTLS/AUTHENTICATE commands are
issued. Before authentication clients SHOULD ignore any responses
other than CAPABILITY and server status responses (Section 7.1),
as well as any response codes other than CAPABILITY. Client
SHOULD ignore the ALERT response code until after TLS has been
successfully negotiated (whether using STARTTLS or TLS negotiation
on implicit TLS port). 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
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.
11.3. LIST command and Other Users' namespace 11.5. LIST command and Other Users' namespace
In response to a LIST command containing an argument of the Other In response to a LIST command containing an argument of the Other
Users' Namespace prefix, a server SHOULD NOT list users that have not Users' Namespace prefix, a server SHOULD NOT list users that have not
granted list access to their personal mailboxes to the currently granted list access to their personal mailboxes to the currently
authenticated user. Providing such a list, could compromise security authenticated user. Providing such a list, could compromise security
by potentially disclosing confidential information of who is located by potentially disclosing confidential information of who is located
on the server, or providing a starting point of a list of user on the server, or providing a starting point of a list of user
accounts to attack. accounts to attack.
11.4. Other Security Considerations 11.6. Other Security Considerations
A server error message for an AUTHENTICATE command which fails due to A server error message for an AUTHENTICATE command which fails due to
invalid credentials SHOULD NOT detail why the credentials are invalid credentials SHOULD NOT detail why the credentials are
invalid. invalid.
Use of the LOGIN command sends passwords in the clear. This can be Use of the LOGIN command sends passwords in the clear. This can be
avoided by using the AUTHENTICATE command with a [SASL] mechanism avoided by using the AUTHENTICATE command with a [SASL] mechanism
that does not use plaintext passwords, by first negotiating that does not use plaintext passwords, by first negotiating
encryption via STARTTLS or some other protection mechanism. encryption via STARTTLS or some other protection mechanism.
A server implementation MUST implement a configuration that, at the A server implementation MUST implement a configuration that, at the
time of authentication, requires: time of authentication, requires:
(1) The STARTTLS command has been negotiated. (1) The STARTTLS command has been negotiated or TLS negotiated on
implicit TLS port.
OR OR
(2) Some other mechanism that protects the session from password (2) Some other mechanism that protects the session from password
snooping has been provided. snooping has been provided.
OR OR
(3) The following measures are in place: (3) The following measures are in place:
(a) The LOGINDISABLED capability is advertised, and [SASL] mechanisms (a) The LOGINDISABLED capability is advertised, and [SASL] mechanisms
(such as PLAIN) using plaintext passwords are NOT advertised in the (such as PLAIN) using plaintext passwords are NOT advertised in the
CAPABILITY list. CAPABILITY list.
AND AND
(b) The LOGIN command returns an error even if the password is (b) The LOGIN command returns an error even if the password is
skipping to change at page 145, line 41 skipping to change at page 149, line 5
(c) The AUTHENTICATE command returns an error with all [SASL] (c) The AUTHENTICATE command returns an error with all [SASL]
mechanisms that use plaintext passwords, even if the password is mechanisms that use plaintext passwords, even if the password is
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
authentication failure attempt with regard to a password brute force
attack as well as a password spraying attack. Accounts that match
password spraying attacks MUST be blocked and request to change their
passwords and 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.
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"
skipping to change at page 146, line 23 skipping to change at page 149, line 43
12.1. Updates to IMAP4 Capabilities registry 12.1. Updates to IMAP4 Capabilities registry
IMAP4 capabilities are registered by publishing a standards track or IMAP4 capabilities are registered by publishing a standards track or
IESG approved informational or experimental RFC. The registry is IESG approved informational or experimental RFC. The registry is
currently located at: https://www.iana.org/assignments/ currently located at: https://www.iana.org/assignments/
imap4-capabilities imap4-capabilities
As this specification revises the AUTH= prefix, STARTTLS and As this specification revises the AUTH= prefix, STARTTLS and
LOGINDISABLED extensions, IANA is requested to update registry LOGINDISABLED extensions, IANA is requested to update registry
entries for these 3 extensions to point to this document. entries for these 3 extensions to point to this document and RFC
3501.
12.2. GSSAPI/SASL service name 12.2. GSSAPI/SASL service name
GSSAPI/Kerberos/SASL service names are registered by publishing a GSSAPI/Kerberos/SASL service names are registered by publishing a
standards track or IESG approved experimental RFC. The registry is standards track or IESG approved experimental RFC. The registry is
currently located at: https://www.iana.org/assignments/gssapi- currently located at: https://www.iana.org/assignments/gssapi-
service-names service-names
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 both this document and RFC 3501.
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].
12.4. IMAP Mailbox Name Attributes and IMAP Response Codes
IANA is requested to update the "IMAP Mailbox Name Attributes"
registry to point to this document in addition to RFC 3501.
IANA is requested to update the "IMAP Response Codes" registry to
point to this document in addition to RFC 3501.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC5258] Leiba, B. and A. Melnikov, "Internet Message Access [RFC5258] Leiba, B. and A. Melnikov, "Internet Message Access
Protocol version 4 - LIST Command Extensions", RFC 5258, Protocol version 4 - LIST Command Extensions", RFC 5258,
DOI 10.17487/RFC5258, June 2008, DOI 10.17487/RFC5258, June 2008,
<https://www.rfc-editor.org/info/rfc5258>. <https://www.rfc-editor.org/info/rfc5258>.
[RFC5788] Melnikov, A. and D. Cridland, "IMAP4 Keyword Registry", [RFC5788] Melnikov, A. and D. Cridland, "IMAP4 Keyword Registry",
skipping to change at page 150, line 17 skipping to change at page 153, line 45
RFC 2683, September 1999, RFC 2683, September 1999,
<http://www.rfc-editor.org/info/rfc2683>. <http://www.rfc-editor.org/info/rfc2683>.
[IMAP-MULTIACCESS] [IMAP-MULTIACCESS]
Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice",
RFC 2180, July 1997, RFC 2180, July 1997,
<http://www.rfc-editor.org/info/rfc2180>. <http://www.rfc-editor.org/info/rfc2180>.
13.2. Informative References (related protocols) 13.2. Informative References (related protocols)
[CERT-555316]
CERT, "Vulnerability Note VU#555316: STARTTLS plaintext
command injection vulnerability", September 2011,
<https://www.kb.cert.org/vuls/id/555316>.
[RFC3503] Melnikov, A., "Message Disposition Notification (MDN) [RFC3503] Melnikov, A., "Message Disposition Notification (MDN)
profile for Internet Message Access Protocol (IMAP)", profile for Internet Message Access Protocol (IMAP)",
RFC 3503, DOI 10.17487/RFC3503, March 2003, RFC 3503, DOI 10.17487/RFC3503, March 2003,
<https://www.rfc-editor.org/info/rfc3503>. <https://www.rfc-editor.org/info/rfc3503>.
[RFC5256] Crispin, M. and K. Murchison, "Internet Message Access [RFC5256] Crispin, M. and K. Murchison, "Internet Message Access
Protocol - SORT and THREAD Extensions", RFC 5256, Protocol - SORT and THREAD Extensions", RFC 5256,
DOI 10.17487/RFC5256, June 2008, DOI 10.17487/RFC5256, June 2008,
<https://www.rfc-editor.org/info/rfc5256>. <https://www.rfc-editor.org/info/rfc5256>.
skipping to change at page 156, line 12 skipping to change at page 159, line 43
LITERAL- (RFC 7888) extensions. Also folded RFC 4466 (IMAP ABNF LITERAL- (RFC 7888) extensions. Also folded RFC 4466 (IMAP ABNF
extensions), RFC 5530 (response codes), the FETCH side of the extensions), RFC 5530 (response codes), the FETCH side of the
BINARY extension (RFC 3516) and the list of new mailbox BINARY extension (RFC 3516) and the list of new mailbox
attributes from SPECIAL-USE (RFC 6154). attributes from SPECIAL-USE (RFC 6154).
3. Added STATUS SIZE (RFC 8438) and STATUS DELETED. 3. Added STATUS SIZE (RFC 8438) and STATUS DELETED.
4. SEARCH command now requires to return ESEARCH response (SEARCH 4. SEARCH command now requires to return ESEARCH response (SEARCH
response is now deprecated). response is now deprecated).
5. Clarified which SEARCH keys has to use substring match and which 5. Clarified which SEARCH keys have to use substring match and
don't. which don't.
6. Clarified that server should decode parameter value 6. Clarified that server should decode parameter value
continuations as described in [RFC2231]. This requirement was continuations as described in [RFC2231]. This requirement was
hidden in RFC 2231 itself. hidden in RFC 2231 itself.
7. Added CLOSED response code from RFC 7162. SELECT/EXAMINE when a 7. Clarified that COPYUID response code is returned for both MOVE
mailbox is already selected now require for the CLOSED response and UID MOVE.
code to be returned.
8. SELECT/EXAMINE are now required to return untagged LIST 8. Tighen requirements about COPY/MOVE commands not creating target
mailbox. Also require them to return TRYCREATE response code,
if the target mailbox doesn't exist and can be created.
9. Added CLOSED response code from RFC 7162. SELECT/EXAMINE when a
mailbox is already selected now requires a CLOSED response code
to be returned.
10. SELECT/EXAMINE are now required to return untagged LIST
response. response.
9. UNSEEN response code on SELECT/EXAMINE is now deprecated. 11. UNSEEN response code on SELECT/EXAMINE is now deprecated.
10. RECENT response on SELECT/EXAMINE, \Recent flag, RECENT STATUS, 12. RECENT response on SELECT/EXAMINE, \Recent flag, RECENT STATUS,
SEARCH NEW items are now deprecated. SEARCH NEW items are now deprecated.
11. Clarified that the server doesn't need to send a new 13. Clarified that the server doesn't need to send a new
PERMANENTFLAGS response code when a new keyword was successfully PERMANENTFLAGS response code when a new keyword was successfully
added and the server advertised \* earlier for the same mailbox. added and the server advertised \* earlier for the same mailbox.
12. For future extensibility extended ABNF for tagged-ext-simple to 14. For future extensibility extended ABNF for tagged-ext-simple to
allow for bare number64. allow for bare number64.
13. Added SHOULD level requirement on IMAP servers to support 15. Added SHOULD level requirement on IMAP servers to support
$MDNSent, $Forwarded, $Junk, $NonJunk and $Phishing keywords. $MDNSent, $Forwarded, $Junk, $NonJunk and $Phishing keywords.
14. Mailbox names and message headers now allow for UTF-8. Support 16. Mailbox names and message headers now allow for UTF-8. Support
for Modified UTF-7 in mailbox names is not required, unless for Modified UTF-7 in mailbox names is not required, unless
compatibility with IMAP4rev1 is desired. compatibility with IMAP4rev1 is desired.
15. Removed the CHECK command. Clients should use NOOP instead. 17. Removed the CHECK command. Clients should use NOOP instead.
16. RFC822, RFC822.HEADER and RFC822.TEXT FETCH data items were 18. RFC822, RFC822.HEADER and RFC822.TEXT FETCH data items were
deprecated. Clients should use the corresponding BODY[] deprecated. Clients should use the corresponding BODY[]
variants instead. variants instead.
17. LSUB command was deprecated. Clients should use LIST 19. LSUB command was deprecated. Clients should use LIST
(SUBSCRIBED) instead. (SUBSCRIBED) instead.
18. IDLE command can now return updates not related to the currently 20. IDLE command can now return updates not related to the currently
selected mailbox state. selected mailbox state.
19. All unsolicited FETCH updates are required to include UID. 21. All unsolicited FETCH updates are required to include UID.
20. Clarified that client implementations MUST ignore response codes 22. Clarified that client implementations MUST ignore response codes
that they do not recognize. (Change from a SHOULD to a MUST.) that they do not recognize. (Change from a SHOULD to a MUST.)
21. resp-text ABNF non terminal was updated to allow for empty text. 23. resp-text ABNF non terminal was updated to allow for empty text.
22. After ENABLE IMAP4rev2 human readable response text can include 24. 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 25. 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- 26. Added warnings about use of ALERT response codes and PREAUTH
response.
27. 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 28. Clarified that any command received from the client resets
server autologout timer. server autologout timer.
26. Revised IANA registration procedure for IMAP extensions and 29. Revised IANA registration procedure for IMAP extensions and
removed "X" convention. removed "X" convention.
30. Loosened requirements on servers when closing connections to be
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. Why 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 (RFC 7162). 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.
skipping to change at page 158, line 16 skipping to change at page 162, line 7
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 and Arnt Gulbrandsen for extensive feedback. Bosch, Robert Sparks, Arnt Gulbrandsen and Daniel Migault for
extensive feedback.
This document incorporate 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
Raymond Cheng in [RFC3348]. Most of the information in Raymond Cheng in [RFC3348]. Most of the information in
Section 6.3.9.5 is taken directly from their original specification Section 6.3.9.5 is taken directly from their original specification
[RFC3348]. [RFC3348].
Thank you to Damian Poddebniak for pointing out that the ENABLE Thank you to Damian Poddebniak, Fabian Ising, Hanno Boeck and
command should be a member of "command-auth" and not "command-any" Sebastian Schinzel for pointing out that the ENABLE command should be
ABNF production. a member of "command-auth" and not "command-any" ABNF production, as
well as pointing out security issues associated with ALERT, PREAUTH
and other responses received before authentication.
Index Index
$ $
$Forwarded (predefined flag) 12 $Forwarded (predefined flag) 12
$Junk (predefined flag) 12 $Junk (predefined flag) 13
$MDNSent (predefined flag) 12 $MDNSent (predefined flag) 13
$NotJunk (predefined flag) 13 $NotJunk (predefined flag) 13
$Phishing (predefined flag) 13 $Phishing (predefined flag) 13
+ +
+FLAGS <flag list> 92 +FLAGS <flag list> 93
+FLAGS.SILENT <flag list> 92 +FLAGS.SILENT <flag list> 93
- -
-FLAGS <flag list> 92 -FLAGS <flag list> 93
-FLAGS.SILENT <flag list> 92 -FLAGS.SILENT <flag list> 93
A A
ALERT (response code) 99 ALERT (response code) 101
ALL (fetch item) 88 ALL (fetch item) 89
ALL (search key) 78 ALL (search key) 79
ALL (search result option) 76 ALL (search result option) 77
ALREADYEXISTS (response code) 99 ALREADYEXISTS (response code) 101
ANSWERED (search key) 78 ANSWERED (search key) 79
APPEND (command) 68 APPEND (command) 69
APPENDUID (response code) 100 APPENDUID (response code) 101
AUTHENTICATE (command) 29 AUTHENTICATE (command) 30
AUTHENTICATIONFAILED (response code) 100 AUTHENTICATIONFAILED (response code) 102
AUTHORIZATIONFAILED (response code) 100 AUTHORIZATIONFAILED (response code) 102
B B
BAD (response) 108 BAD (response) 109
BADCHARSET (response code) 101 BADCHARSET (response code) 102
BCC <string> (search key) 78 BCC <string> (search key) 79
BEFORE <date> (search key) 78 BEFORE <date> (search key) 79
BINARY.PEEK[<section-binary>]<<partial>> (fetch item) 88 BINARY.PEEK[<section-binary>]<<partial>> (fetch item) 89
BINARY.SIZE[<section-binary>] (fetch item) 89 BINARY.SIZE[<section-binary>] (fetch item) 90
BINARY.SIZE[<section-binary>] (fetch result) 118 BINARY.SIZE[<section-binary>] (fetch result) 120
BINARY[<section-binary>]<<number>> (fetch result) 118 BINARY[<section-binary>]<<number>> (fetch result) 119
BINARY[<section-binary>]<<partial>> (fetch item) 88 BINARY[<section-binary>]<<partial>> (fetch item) 89
BODY (fetch item) 89 BODY (fetch item) 90
BODY (fetch result) 118 BODY (fetch result) 120
BODY <string> (search key) 78 BODY <string> (search key) 79
BODY.PEEK[<section>]<<partial>> (fetch item) 89 BODY.PEEK[<section>]<<partial>> (fetch item) 90
BODYSTRUCTURE (fetch item) 90 BODYSTRUCTURE (fetch item) 91
BODYSTRUCTURE (fetch result) 119 BODYSTRUCTURE (fetch result) 121
BODY[<section>]<<origin octet>> (fetch result) 118 BODY[<section>]<<origin octet>> (fetch result) 120
BODY[<section>]<<partial>> (fetch item) 89 BODY[<section>]<<partial>> (fetch item) 90
BYE (response) 109 BYE (response) 110
Body Structure (message attribute) 14 Body Structure (message attribute) 14
C C
CANNOT (response code) 101 CANNOT (response code) 102
CAPABILITY (command) 26 CAPABILITY (command) 26
CAPABILITY (response code) 101 CAPABILITY (response code) 103
CAPABILITY (response) 110 CAPABILITY (response) 111
CC <string> (search key) 78 CC <string> (search key) 79
CLIENTBUG (response code) 101 CLIENTBUG (response code) 103
CLOSE (command) 74 CLOSE (command) 75
CLOSED (response code) 102 CLOSED (response code) 103
CONTACTADMIN (response code) 102 CONTACTADMIN (response code) 103
COPY (command) 93 COPY (command) 94
COPYUID (response code) 102 COPYUID (response code) 103
CORRUPTION (response code) 103 CORRUPTION (response code) 104
COUNT (search result option) 76 COUNT (search result option) 77
CREATE (command) 38 CREATE (command) 39
D D
DELETE (command) 40 DELETE (command) 40
DELETED (search key) 78 DELETED (search key) 79
DELETED (status item) 68 DELETED (status item) 69
DRAFT (search key) 78 DRAFT (search key) 79
E E
ENABLE (command) 33 ENABLE (command) 34
ENVELOPE (fetch item) 90 ENVELOPE (fetch item) 91
ENVELOPE (fetch result) 122 ENVELOPE (fetch result) 123
ESEARCH (response) 115 ESEARCH (response) 117
EXAMINE (command) 37 EXAMINE (command) 38
EXPIRED (response code) 103 EXPIRED (response code) 104
EXPUNGE (command) 75 EXPUNGE (command) 76
EXPUNGE (response) 117 EXPUNGE (response) 118
EXPUNGEISSUED (response code) 103 EXPUNGEISSUED (response code) 104
Envelope Structure (message attribute) 14 Envelope Structure (message attribute) 14
F F
FAST (fetch item) 88 FAST (fetch item) 89
FETCH (command) 87 FETCH (command) 88
FETCH (response) 117 FETCH (response) 119
FLAGGED (search key) 78 FLAGGED (search key) 79
FLAGS (fetch item) 90 FLAGS (fetch item) 91
FLAGS (fetch result) 123 FLAGS (fetch result) 125
FLAGS (response) 116 FLAGS (response) 117
FLAGS <flag list> (store command data item) 92 FLAGS <flag list> (store command data item) 93
FLAGS.SILENT <flag list> (store command data item) 92 FLAGS.SILENT <flag list> (store command data item) 93
FROM <string> (search key) 78 FROM <string> (search key) 79
FULL (fetch item) 88 FULL (fetch item) 89
Flags (message attribute) 11 Flags (message attribute) 12
H H
HASCHILDREN (response code) 103 HASCHILDREN (response code) 105
HEADER (part specifier) 90 HEADER (part specifier) 91
HEADER <field-name> <string> (search key) 79 HEADER <field-name> <string> (search key) 80
HEADER.FIELDS (part specifier) 90 HEADER.FIELDS (part specifier) 91
HEADER.FIELDS.NOT (part specifier) 90 HEADER.FIELDS.NOT (part specifier) 91
I I
IDLE (command) 71 IDLE (command) 72
INTERNALDATE (fetch item) 90 INTERNALDATE (fetch item) 91
INTERNALDATE (fetch result) 123 INTERNALDATE (fetch result) 125
INUSE (response code) 103 INUSE (response code) 105
Internal Date (message attribute) 13 Internal Date (message attribute) 14
K K
KEYWORD <flag> (search key) 79 KEYWORD <flag> (search key) 80
Keyword (type of flag) 12 Keyword (type of flag) 12
L L
LARGER <n> (search key) 79 LARGER <n> (search key) 80
LIMIT (response code) 104 LIMIT (response code) 105
LIST (command) 45 LIST (command) 45
LIST (response) 111 LIST (response) 112
LOGOUT (command) 27 LOGOUT (command) 27
M M
MAX (search result option) 76 MAX (search result option) 77
MAY (specification requirement term) 5 MAY (specification requirement term) 5
MESSAGES (status item) 68 MESSAGES (status item) 69
MIME (part specifier) 91 MIME (part specifier) 92
MIN (search result option) 76 MIN (search result option) 77
MOVE (command) 94 MOVE (command) 95
MUST (specification requirement term) 5 MUST (specification requirement term) 5
MUST NOT (specification requirement term) 5 MUST NOT (specification requirement term) 5
Message Sequence Number (message attribute) 11 Message Sequence Number (message attribute) 11
N N
NAMESPACE (command) 63 NAMESPACE (command) 63
NAMESPACE (response) 114 NAMESPACE (response) 116
NO (response) 107 NO (response) 109
NONEXISTENT (response code) 104 NONEXISTENT (response code) 105
NOOP (command) 27 NOOP (command) 27
NOPERM (response code) 104 NOPERM (response code) 105
NOT <search-key> (search key) 79 NOT <search-key> (search key) 80
NOT RECOMMENDED (specification requirement term) 5 NOT RECOMMENDED (specification requirement term) 5
O O
OK (response) 107 OK (response) 108
ON <date> (search key) 79 ON <date> (search key) 80
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) 80
OVERQUOTA (response code) 104 OVERQUOTA (response code) 106
P P
PARSE (response code) 105 PARSE (response code) 106
PERMANENTFLAGS (response code) 105 PERMANENTFLAGS (response code) 106
PREAUTH (response) 108 PREAUTH (response) 110
PRIVACYREQUIRED (response code) 105 PRIVACYREQUIRED (response code) 106
Permanent Flag (class of flag) 13 Permanent Flag (class of flag) 13
Predefined keywords 12 Predefined keywords 12
R R
READ-ONLY (response code) 105 READ-ONLY (response code) 107
READ-WRITE (response code) 106 READ-WRITE (response code) 107
RECOMMENDED (specification requirement term) 5 RECOMMENDED (specification requirement term) 5
RENAME (command) 41 RENAME (command) 42
REQUIRED (specification requirement term) 5 REQUIRED (specification requirement term) 5
RFC822.SIZE (fetch item) 90 RFC822.SIZE (fetch item) 91
RFC822.SIZE (fetch result) 123 RFC822.SIZE (fetch result) 125
S S
SAVE (search result option) 76 SAVE (search result option) 77
SEARCH (command) 75 SEARCH (command) 76
SEEN (search key) 79 SEEN (search key) 80
SELECT (command) 35 SELECT (command) 36
SENTBEFORE <date> (search key) 79 SENTBEFORE <date> (search key) 80
SENTON <date> (search key) 79 SENTON <date> (search key) 80
SENTSINCE <date> (search key) 79 SENTSINCE <date> (search key) 80
SERVERBUG (response code) 106 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) 79 SINCE <date> (search key) 80
SIZE (status item) 68 SIZE (status item) 69
SMALLER <n> (search key) 79 SMALLER <n> (search key) 80
STARTTLS (command) 28 STARTTLS (command) 28
STATUS (command) 67 STATUS (command) 68
STATUS (response) 115 STATUS (response) 117
STORE (command) 92 STORE (command) 93
SUBJECT <string> (search key) 79 SUBJECT <string> (search key) 80
SUBSCRIBE (command) 44 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) 91
TEXT <string> (search key) 80 TEXT <string> (search key) 81
TO <string> (search key) 80 TO <string> (search key) 81
TRYCREATE (response code) 106 TRYCREATE (response code) 107
U U
UID (command) 96 UID (command) 97
UID (fetch item) 90 UID (fetch item) 91
UID (fetch result) 123 UID (fetch result) 125
UID <sequence set> (search key) 80 UID <sequence set> (search key) 81
UIDNEXT (response code) 106 UIDNEXT (response code) 107
UIDNEXT (status item) 68 UIDNEXT (status item) 69
UIDNOTSTICKY (response code) 106 UIDNOTSTICKY (response code) 107
UIDVALIDITY (response code) 106 UIDVALIDITY (response code) 108
UIDVALIDITY (status item) 68 UIDVALIDITY (status item) 69
UNANSWERED (search key) 80 UNANSWERED (search key) 81
UNAVAILABLE (response code) 107 UNAVAILABLE (response code) 108
UNDELETED (search key) 80 UNDELETED (search key) 81
UNDRAFT (search key) 80 UNDRAFT (search key) 81
UNFLAGGED (search key) 80 UNFLAGGED (search key) 81
UNKEYWORD <flag> (search key) 80 UNKEYWORD <flag> (search key) 81
UNKNOWN-CTE (response code) 107 UNKNOWN-CTE (response code) 108
UNSEEN (search key) 80 UNSEEN (search key) 81
UNSEEN (status item) 68 UNSEEN (status item) 69
UNSELECT (command) 74 UNSELECT (command) 75
UNSUBSCRIBE (command) 44 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) 113 \All (mailbox name attribute) 114
\Answered (system flag) 12 \Answered (system flag) 12
\Archive (mailbox name attribute) 113 \Archive (mailbox name attribute) 114
\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) 115
\Flagged (mailbox name attribute) 113 \Flagged (mailbox name attribute) 115
\Flagged (system flag) 12 \Flagged (system flag) 12
\HasChildren (mailbox name attribute) 111 \HasChildren (mailbox name attribute) 113
\HasNoChildren (mailbox name attribute) 112 \HasNoChildren (mailbox name attribute) 113
\Junk (mailbox name attribute) 113 \Junk (mailbox name attribute) 115
\Marked (mailbox name attribute) 112 \Marked (mailbox name attribute) 114
\Noinferiors (mailbox name attribute) 111 \Noinferiors (mailbox name attribute) 113
\NonExistent (mailbox name attribute) 111 \NonExistent (mailbox name attribute) 113
\Noselect (mailbox name attribute) 111 \Noselect (mailbox name attribute) 113
\Recent (system flag) 12 \Recent (system flag) 12
\Remote (mailbox name attribute) 112 \Remote (mailbox name attribute) 114
\Seen (system flag) 12 \Seen (system flag) 12
\Sent (mailbox name attribute) 113 \Sent (mailbox name attribute) 115
\Subscribed (mailbox name attribute) 112 \Subscribed (mailbox name attribute) 114
\Trash (mailbox name attribute) 113 \Trash (mailbox name attribute) 115
\Unmarked (mailbox name attribute) 112 \Unmarked (mailbox name attribute) 114
Authors' Addresses Authors' Addresses
Alexey Melnikov (editor) Alexey Melnikov (editor)
Isode Ltd Isode Ltd
14 Castle Mews 14 Castle Mews
Hampton, Middlesex TW12 2NP Hampton, Middlesex TW12 2NP
UK UK
Email: Alexey.Melnikov@isode.com Email: Alexey.Melnikov@isode.com
 End of changes. 179 change blocks. 
412 lines changed or deleted 569 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/