< draft-ietf-extra-imap4rev2-12.txt   draft-ietf-extra-imap4rev2-13.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 Huawei Technologies Intended status: Standards Track Huawei Technologies
Expires: August 15, 2020 February 12, 2020 Expires: September 10, 2020 March 9, 2020
INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev2 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev2
draft-ietf-extra-imap4rev2-12 draft-ietf-extra-imap4rev2-13
Abstract Abstract
The Internet Message Access Protocol, Version 4rev2 (IMAP4rev2) The Internet Message Access Protocol, Version 4rev2 (IMAP4rev2)
allows a client to access and manipulate electronic mail messages on allows a client to access and manipulate electronic mail messages on
a server. IMAP4rev2 permits manipulation of mailboxes (remote a server. IMAP4rev2 permits manipulation of mailboxes (remote
message folders) in a way that is functionally equivalent to local message folders) in a way that is functionally equivalent to local
folders. IMAP4rev2 also provides the capability for an offline folders. IMAP4rev2 also provides the capability for an offline
client to resynchronize with the server. client to resynchronize with the server.
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 15, 2020. This Internet-Draft will expire on September 10, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 46 skipping to change at page 2, line 46
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 . . . . . . . . . . . . . . . 11
2.3.3. Internal Date Message Attribute . . . . . . . . . . . 12 2.3.3. Internal Date Message Attribute . . . . . . . . . . . 13
2.3.4. [RFC-5322] Size Message Attribute . . . . . . . . . . 13 2.3.4. [RFC-5322] Size Message Attribute . . . . . . . . . . 13
2.3.5. Envelope Structure Message Attribute . . . . . . . . 13 2.3.5. Envelope Structure Message Attribute . . . . . . . . 14
2.3.6. Body Structure Message Attribute . . . . . . . . . . 13 2.3.6. Body Structure Message Attribute . . . . . . . . . . 14
2.4. Message Texts . . . . . . . . . . . . . . . . . . . . . . 13 2.4. Message Texts . . . . . . . . . . . . . . . . . . . . . . 14
3. State and Flow Diagram . . . . . . . . . . . . . . . . . . . 13 3. State and Flow Diagram . . . . . . . . . . . . . . . . . . . 14
3.1. Not Authenticated State . . . . . . . . . . . . . . . . . 13 3.1. Not Authenticated State . . . . . . . . . . . . . . . . . 14
3.2. Authenticated State . . . . . . . . . . . . . . . . . . . 13 3.2. Authenticated State . . . . . . . . . . . . . . . . . . . 14
3.3. Selected State . . . . . . . . . . . . . . . . . . . . . 14 3.3. Selected State . . . . . . . . . . . . . . . . . . . . . 15
3.4. Logout State . . . . . . . . . . . . . . . . . . . . . . 14 3.4. Logout State . . . . . . . . . . . . . . . . . . . . . . 15
4. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 16 4. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1. Atom . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1. Atom . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.1. Sequence set and UID set . . . . . . . . . . . . . . 16 4.1.1. Sequence set and UID set . . . . . . . . . . . . . . 17
4.2. Number . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2. Number . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3. String . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.3. String . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.1. 8-bit and Binary Strings . . . . . . . . . . . . . . 17 4.3.1. 8-bit and Binary Strings . . . . . . . . . . . . . . 18
4.4. Parenthesized List . . . . . . . . . . . . . . . . . . . 18 4.4. Parenthesized List . . . . . . . . . . . . . . . . . . . 19
4.5. NIL . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.5. NIL . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5. Operational Considerations . . . . . . . . . . . . . . . . . 19 5. Operational Considerations . . . . . . . . . . . . . . . . . 20
5.1. Mailbox Naming . . . . . . . . . . . . . . . . . . . . . 19 5.1. Mailbox Naming . . . . . . . . . . . . . . . . . . . . . 20
5.1.1. Mailbox Hierarchy Naming . . . . . . . . . . . . . . 20 5.1.1. Mailbox Hierarchy Naming . . . . . . . . . . . . . . 21
5.1.2. Namespaces . . . . . . . . . . . . . . . . . . . . . 20 5.1.2. Namespaces . . . . . . . . . . . . . . . . . . . . . 21
5.2. Mailbox Size and Message Status Updates . . . . . . . . . 21 5.2. Mailbox Size and Message Status Updates . . . . . . . . . 23
5.3. Response when no Command in Progress . . . . . . . . . . 22 5.3. Response when no Command in Progress . . . . . . . . . . 23
5.4. Autologout Timer . . . . . . . . . . . . . . . . . . . . 22 5.4. Autologout Timer . . . . . . . . . . . . . . . . . . . . 23
5.5. Multiple Commands in Progress (Command Pipelining) . . . 22 5.5. Multiple Commands in Progress (Command Pipelining) . . . 23
6. Client Commands . . . . . . . . . . . . . . . . . . . . . . . 24 6. Client Commands . . . . . . . . . . . . . . . . . . . . . . . 25
6.1. Client Commands - Any State . . . . . . . . . . . . . . . 24 6.1. Client Commands - Any State . . . . . . . . . . . . . . . 25
6.1.1. CAPABILITY Command . . . . . . . . . . . . . . . . . 24 6.1.1. CAPABILITY Command . . . . . . . . . . . . . . . . . 25
6.1.2. NOOP Command . . . . . . . . . . . . . . . . . . . . 25 6.1.2. NOOP Command . . . . . . . . . . . . . . . . . . . . 26
6.1.3. LOGOUT Command . . . . . . . . . . . . . . . . . . . 26 6.1.3. LOGOUT Command . . . . . . . . . . . . . . . . . . . 27
6.2. Client Commands - Not Authenticated State . . . . . . . . 26 6.2. Client Commands - Not Authenticated State . . . . . . . . 27
6.2.1. STARTTLS Command . . . . . . . . . . . . . . . . . . 27 6.2.1. STARTTLS Command . . . . . . . . . . . . . . . . . . 28
6.2.2. AUTHENTICATE Command . . . . . . . . . . . . . . . . 28 6.2.2. AUTHENTICATE Command . . . . . . . . . . . . . . . . 29
6.2.3. LOGIN Command . . . . . . . . . . . . . . . . . . . . 31 6.2.3. LOGIN Command . . . . . . . . . . . . . . . . . . . . 32
6.3. Client Commands - Authenticated State . . . . . . . . . . 32 6.3. Client Commands - Authenticated State . . . . . . . . . . 33
6.3.1. ENABLE Command . . . . . . . . . . . . . . . . . . . 32 6.3.1. ENABLE Command . . . . . . . . . . . . . . . . . . . 33
6.3.2. SELECT Command . . . . . . . . . . . . . . . . . . . 34 6.3.2. SELECT Command . . . . . . . . . . . . . . . . . . . 35
6.3.3. EXAMINE Command . . . . . . . . . . . . . . . . . . . 36 6.3.3. EXAMINE Command . . . . . . . . . . . . . . . . . . . 37
6.3.4. CREATE Command . . . . . . . . . . . . . . . . . . . 37 6.3.4. CREATE Command . . . . . . . . . . . . . . . . . . . 38
6.3.5. DELETE Command . . . . . . . . . . . . . . . . . . . 38 6.3.5. DELETE Command . . . . . . . . . . . . . . . . . . . 39
6.3.6. RENAME Command . . . . . . . . . . . . . . . . . . . 39 6.3.6. RENAME Command . . . . . . . . . . . . . . . . . . . 40
6.3.7. SUBSCRIBE Command . . . . . . . . . . . . . . . . . . 41 6.3.7. SUBSCRIBE Command . . . . . . . . . . . . . . . . . . 42
6.3.8. UNSUBSCRIBE Command . . . . . . . . . . . . . . . . . 42 6.3.8. UNSUBSCRIBE Command . . . . . . . . . . . . . . . . . 43
6.3.9. LIST Command . . . . . . . . . . . . . . . . . . . . 42 6.3.9. LIST Command . . . . . . . . . . . . . . . . . . . . 43
6.3.10. NAMESPACE Command . . . . . . . . . . . . . . . . . . 60 6.3.10. NAMESPACE Command . . . . . . . . . . . . . . . . . . 61
6.3.11. STATUS Command . . . . . . . . . . . . . . . . . . . 65 6.3.11. STATUS Command . . . . . . . . . . . . . . . . . . . 66
6.3.12. APPEND Command . . . . . . . . . . . . . . . . . . . 66 6.3.12. APPEND Command . . . . . . . . . . . . . . . . . . . 67
6.3.13. IDLE Command . . . . . . . . . . . . . . . . . . . . 69 6.3.13. IDLE Command . . . . . . . . . . . . . . . . . . . . 70
6.4. Client Commands - Selected State . . . . . . . . . . . . 71 6.4. Client Commands - Selected State . . . . . . . . . . . . 72
6.4.1. CLOSE Command . . . . . . . . . . . . . . . . . . . . 71 6.4.1. CLOSE Command . . . . . . . . . . . . . . . . . . . . 72
6.4.2. UNSELECT Command . . . . . . . . . . . . . . . . . . 72 6.4.2. UNSELECT Command . . . . . . . . . . . . . . . . . . 73
6.4.3. EXPUNGE Command . . . . . . . . . . . . . . . . . . . 72 6.4.3. EXPUNGE Command . . . . . . . . . . . . . . . . . . . 73
6.4.4. SEARCH Command . . . . . . . . . . . . . . . . . . . 73 6.4.4. SEARCH Command . . . . . . . . . . . . . . . . . . . 74
6.4.5. FETCH Command . . . . . . . . . . . . . . . . . . . . 85 6.4.5. FETCH Command . . . . . . . . . . . . . . . . . . . . 86
6.4.6. STORE Command . . . . . . . . . . . . . . . . . . . . 89 6.4.6. STORE Command . . . . . . . . . . . . . . . . . . . . 90
6.4.7. COPY Command . . . . . . . . . . . . . . . . . . . . 90 6.4.7. COPY Command . . . . . . . . . . . . . . . . . . . . 91
6.4.8. MOVE Command . . . . . . . . . . . . . . . . . . . . 91 6.4.8. MOVE Command . . . . . . . . . . . . . . . . . . . . 92
6.4.9. UID Command . . . . . . . . . . . . . . . . . . . . . 93 6.4.9. UID Command . . . . . . . . . . . . . . . . . . . . . 94
6.5. Client Commands - Experimental/Expansion . . . . . . . . 95 6.5. Client Commands - Experimental/Expansion . . . . . . . . 96
6.5.1. X<atom> Command . . . . . . . . . . . . . . . . . . . 95 6.5.1. X<atom> Command . . . . . . . . . . . . . . . . . . . 96
7. Server Responses . . . . . . . . . . . . . . . . . . . . . . 96 7. Server Responses . . . . . . . . . . . . . . . . . . . . . . 97
7.1. Server Responses - Status Responses . . . . . . . . . . . 97 7.1. Server Responses - Status Responses . . . . . . . . . . . 98
7.1.1. OK Response . . . . . . . . . . . . . . . . . . . . . 105 7.1.1. OK Response . . . . . . . . . . . . . . . . . . . . . 106
7.1.2. NO Response . . . . . . . . . . . . . . . . . . . . . 105 7.1.2. NO Response . . . . . . . . . . . . . . . . . . . . . 106
7.1.3. BAD Response . . . . . . . . . . . . . . . . . . . . 106 7.1.3. BAD Response . . . . . . . . . . . . . . . . . . . . 106
7.1.4. PREAUTH Response . . . . . . . . . . . . . . . . . . 106 7.1.4. PREAUTH Response . . . . . . . . . . . . . . . . . . 107
7.1.5. BYE Response . . . . . . . . . . . . . . . . . . . . 106 7.1.5. BYE Response . . . . . . . . . . . . . . . . . . . . 107
7.2. Server Responses - Server and Mailbox Status . . . . . . 107 7.2. Server Responses - Server and Mailbox Status . . . . . . 108
7.2.1. The ENABLED Response . . . . . . . . . . . . . . . . 107 7.2.1. The ENABLED Response . . . . . . . . . . . . . . . . 108
7.2.2. CAPABILITY Response . . . . . . . . . . . . . . . . . 107 7.2.2. CAPABILITY Response . . . . . . . . . . . . . . . . . 108
7.2.3. LIST Response . . . . . . . . . . . . . . . . . . . . 108 7.2.3. LIST Response . . . . . . . . . . . . . . . . . . . . 109
7.2.4. NAMESPACE Response . . . . . . . . . . . . . . . . . 112 7.2.4. NAMESPACE Response . . . . . . . . . . . . . . . . . 113
7.2.5. STATUS Response . . . . . . . . . . . . . . . . . . . 112 7.2.5. STATUS Response . . . . . . . . . . . . . . . . . . . 113
7.2.6. ESEARCH Response . . . . . . . . . . . . . . . . . . 113 7.2.6. ESEARCH Response . . . . . . . . . . . . . . . . . . 113
7.2.7. FLAGS Response . . . . . . . . . . . . . . . . . . . 113 7.2.7. FLAGS Response . . . . . . . . . . . . . . . . . . . 114
7.3. Server Responses - Mailbox Size . . . . . . . . . . . . . 114 7.3. Server Responses - Mailbox Size . . . . . . . . . . . . . 114
7.3.1. EXISTS Response . . . . . . . . . . . . . . . . . . . 114 7.3.1. EXISTS Response . . . . . . . . . . . . . . . . . . . 115
7.4. Server Responses - Message Status . . . . . . . . . . . . 114 7.4. Server Responses - Message Status . . . . . . . . . . . . 115
7.4.1. EXPUNGE Response . . . . . . . . . . . . . . . . . . 114 7.4.1. EXPUNGE Response . . . . . . . . . . . . . . . . . . 115
7.4.2. FETCH Response . . . . . . . . . . . . . . . . . . . 115 7.4.2. FETCH Response . . . . . . . . . . . . . . . . . . . 116
7.5. Server Responses - Command Continuation Request . . . . . 121 7.5. Server Responses - Command Continuation Request . . . . . 122
8. Sample IMAP4rev2 connection . . . . . . . . . . . . . . . . . 121 8. Sample IMAP4rev2 connection . . . . . . . . . . . . . . . . . 122
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 122 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 123
10. Author's Note . . . . . . . . . . . . . . . . . . . . . . . . 139 10. Author's Note . . . . . . . . . . . . . . . . . . . . . . . . 140
11. Security Considerations . . . . . . . . . . . . . . . . . . . 139 11. Security Considerations . . . . . . . . . . . . . . . . . . . 140
11.1. STARTTLS Security Considerations . . . . . . . . . . . . 140 11.1. STARTTLS Security Considerations . . . . . . . . . . . . 141
11.2. COPYUID and APPENDUID response codes . . . . . . . . . . 140 11.2. COPYUID and APPENDUID response codes . . . . . . . . . . 141
11.3. LIST command and Other Users' namespace . . . . . . . . 140 11.3. LIST command and Other Users' namespace . . . . . . . . 141
11.4. Other Security Considerations . . . . . . . . . . . . . 140 11.4. Other Security Considerations . . . . . . . . . . . . . 141
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 141 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 142
12.1. Updates to IMAP4 Capabilities registry . . . . . . . . . 142 12.1. Updates to IMAP4 Capabilities registry . . . . . . . . . 143
12.2. GSSAPI/SASL service name . . . . . . . . . . . . . . . . 142 12.2. GSSAPI/SASL service name . . . . . . . . . . . . . . . . 143
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 142 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 143
13.1. Normative References . . . . . . . . . . . . . . . . . . 142 13.1. Normative References . . . . . . . . . . . . . . . . . . 143
13.2. Informative References (related protocols) . . . . . . . 145 13.2. Informative References (related protocols) . . . . . . . 146
13.3. Informative References (historical aspects of IMAP and 13.3. Informative References (historical aspects of IMAP and
related protocols) . . . . . . . . . . . . . . . . . . . 146 related protocols) . . . . . . . . . . . . . . . . . . . 148
Appendix A. Backward compatibility with IMAP4rev1 . . . . . . . 147 Appendix A. Backward compatibility with IMAP4rev1 . . . . . . . 149
A.1. Mailbox International Naming Convention for compatibility A.1. Mailbox International Naming Convention for compatibility
with IMAP4rev1 . . . . . . . . . . . . . . . . . . . . . 148 with IMAP4rev1 . . . . . . . . . . . . . . . . . . . . . 149
Appendix B. Backward compatibility with BINARY extension . . . . 149 Appendix B. Backward compatibility with BINARY extension . . . . 151
Appendix C. Changes from RFC 3501 / IMAP4rev1 . . . . . . . . . 149 Appendix C. Changes from RFC 3501 / IMAP4rev1 . . . . . . . . . 151
Appendix D. Acknowledgement . . . . . . . . . . . . . . . . . . 152 Appendix D. Acknowledgement . . . . . . . . . . . . . . . . . . 153
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 157 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 159
1. How to Read This Document 1. How to Read This Document
1.1. Organization of This Document 1.1. Organization of This Document
This document is written from the point of view of the implementor of This document is written from the point of view of the implementor of
an IMAP4rev2 client or server. Beyond the protocol overview in an IMAP4rev2 client or server. Beyond the protocol overview in
section 2, it is not optimized for someone trying to understand the section 2, it is not optimized for someone trying to understand the
operation of the protocol. The material in sections 3 through 5 operation of the protocol. The material in sections 3 through 5
provides the general context and definitions with which IMAP4rev2 provides the general context and definitions with which IMAP4rev2
skipping to change at page 7, line 31 skipping to change at page 7, line 31
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. generated by the client for each command. (More formally: the client
SHOULD generate a unique tag for every command, but a server MUST
accept tag reuse.)
Clients MUST follow the syntax outlined in this specification Clients MUST follow the syntax outlined in this specification
strictly. It is a syntax error to send a command with missing or strictly. It is a syntax error to send a command with missing or
extraneous spaces or arguments. extraneous spaces or arguments.
There are two cases in which a line from the client does not There are two cases in which a line from the client does not
represent a complete command. In one case, a command argument is represent a complete command. In one case, a command argument is
quoted with an octet count (see the description of literal in String quoted with an octet count (see the description of literal in String
under Data Formats); in the other case, the command arguments require under Data Formats); in the other case, the command arguments require
server feedback (see the AUTHENTICATE command). In either case, the server feedback (see the AUTHENTICATE command). In either case, the
skipping to change at page 9, line 21 skipping to change at page 9, line 21
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.
2.3.1. Message Numbers 2.3.1. Message Numbers
Messages in IMAP4rev2 are accessed by one of two numbers; the unique Messages in IMAP4rev2 are accessed by one of two numbers; the unique
identifier or the message sequence number. identifier or the message sequence number.
2.3.1.1. Unique Identifier (UID) Message Attribute 2.3.1.1. Unique Identifier (UID) Message Attribute
An unsigned 32-bit value assigned to each message, which when used An unsigned non-zero 32-bit value assigned to each message, which
with the unique identifier validity value (see below) forms a 64-bit when used with the unique identifier validity value (see below) forms
value that MUST NOT refer to any other message in the mailbox or any a 64-bit value that MUST NOT refer to any other message in the
subsequent mailbox with the same name forever. Unique identifiers mailbox or any subsequent mailbox with the same name forever. Unique
are assigned in a strictly ascending fashion in the mailbox; as each identifiers are assigned in a strictly ascending fashion in the
message is added to the mailbox it is assigned a higher UID than the mailbox; as each message is added to the mailbox it is assigned a
message(s) which were added previously. Unlike message sequence higher UID than the message(s) which were added previously. Unlike
numbers, unique identifiers are not necessarily contiguous. message sequence numbers, unique identifiers are not necessarily
contiguous.
The unique identifier of a message MUST NOT change during the The unique identifier of a message MUST NOT change during the
session, and SHOULD NOT change between sessions. Any change of session, and SHOULD NOT change between sessions. Any change of
unique identifiers between sessions MUST be detectable using the unique identifiers between sessions MUST be detectable using the
UIDVALIDITY mechanism discussed below. Persistent unique identifiers UIDVALIDITY mechanism discussed below. Persistent unique identifiers
are required for a client to resynchronize its state from a previous are required for a client to resynchronize its state from a previous
session with the server (e.g., disconnected or offline access session with the server (e.g., disconnected or offline access
clients); this is discussed further in [IMAP-DISC]. clients); this is discussed further in [IMAP-DISC].
Associated with every mailbox are two 32-bit unsigned values which Associated with every mailbox are two 32-bit unsigned non-zero values
aid in unique identifier handling: the next unique identifier value which aid in unique identifier handling: the next unique identifier
(UIDNEXT) and the unique identifier validity value (UIDVALIDITY). value (UIDNEXT) and the unique identifier validity value
(UIDVALIDITY).
The next unique identifier value is the predicted value that will be The next unique identifier value is the predicted value that will be
assigned to a new message in the mailbox. Unless the unique assigned to a new message in the mailbox. Unless the unique
identifier validity also changes (see below), the next unique identifier validity also changes (see below), the next unique
identifier value MUST have the following two characteristics. First, identifier value MUST have the following two characteristics. First,
the next unique identifier value MUST NOT change unless new messages the next unique identifier value MUST NOT change unless new messages
are added to the mailbox; and second, the next unique identifier are added to the mailbox; and second, the next unique identifier
value MUST change whenever new messages are added to the mailbox, value MUST change whenever new messages are added to the mailbox,
even if those new messages are subsequently expunged. even if those new messages are subsequently expunged.
skipping to change at page 11, line 49 skipping to change at page 12, line 4
A system flag is a flag name that is pre-defined in this A system flag is a flag name that is pre-defined in this
specification and begin with "\". Certain system flags (\Deleted and specification and begin with "\". Certain system flags (\Deleted and
\Seen) have special semantics described elsewhere in this document. \Seen) have special semantics described elsewhere in this document.
The currently-defined system flags are: The currently-defined system flags are:
\Seen Message has been read \Seen Message has been read
\Answered Message has been answered \Answered Message has been answered
\Flagged Message is "flagged" for urgent/special attention \Flagged Message is "flagged" for urgent/special attention
\Deleted Message is "deleted" for removal by later EXPUNGE \Deleted Message is "deleted" for removal by later EXPUNGE
\Draft Message has not completed composition (marked as a draft). \Draft Message has not completed composition (marked as a draft).
\Recent This flag was in used in IMAP4rev1 and is now deprecated. \Recent This flag was in used in IMAP4rev1 and is now deprecated.
A keyword is defined by the server implementation. Keywords do not A keyword is defined by the server implementation. Keywords do not
begin with "\". Servers MAY permit the client to define new keywords begin with "\". Servers MAY permit the client to define new keywords
in the mailbox (see the description of the PERMANENTFLAGS response in the mailbox (see the description of the PERMANENTFLAGS response
code for more information). Some keywords that start with "$" are code for more information). Some keywords that start with "$" are
also defined in this specification. also defined in this specification.
This document defines several keywords that were not originally This document defines several keywords that were not originally
defined in RFC 3501, but which were found to be useful by client defined in RFC 3501, but which were found to be useful by client
implementations. These keywords SHOULD be supported (i.e. allowed in implementations. These keywords SHOULD be supported (i.e. allowed in
APPEND, COPY, MOVE and SEARCH commands) by server implementations: SEARCH, allowed and preserved in APPEND, COPY, MOVE commands) by
server implementations:
$Forwarded Message has been forwarded to another email address, $Forwarded Message has been forwarded to another email address,
embedded within or attached to a new message. An email client embedded within or attached to a new message. An email client
sets this keyword when it successfully forwards the message to sets this keyword when it successfully forwards the message to
another email address. Typical usage of this keyword is to show a another email address. Typical usage of this keyword is to show a
different (or additional) icon for a message that has been different (or additional) icon for a message that has been
forwarded. Once set, the flag SHOULD NOT be cleared. forwarded. Once set, the flag SHOULD NOT be cleared.
$MDNSent Message Disposition Notification [RFC8098] was generated $MDNSent Message Disposition Notification [RFC8098] was generated
and sent for this message. and sent for this message. See [RFC3503] for more details on how
this keyword is used.
$Junk The user (or a delivery agent on behalf of the user) may
choose to mark a message as definitely containing junk ($Junk; see
also the related keyword $NotJunk). The $Junk keyword can be used
to mark (and potentially move/delete messages later), group or
hide undesirable messages. See [IMAP-KEYWORDS-REG] for more
information.
$NotJunk The user (or a delivery agent on behalf of the user) may
choose to mark a message as definitely not containing junk
($NotJunk; see also the related keyword $Junk). The $NotJunk
keyword can be used to mark, group or show messages that the user
wants to see. See [IMAP-KEYWORDS-REG] for more information.
$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
that's determined to be a phishing email by the delivery agent
should also be considered a junk email and have the appropriate
junk filtering applied, including setting the $Junk flag and
placing in the \Junk special-use mailbox if available.
If both the $Phishing flag and the $Junk flag are set, the user
agent should display an additional warning message to the user.
User agents should not use the term "phishing" in their warning
message as most users do not understand this term. Phrasing of
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
user agent displays a warning is for better backwards
compatibility with existing clients that understand the $Junk flag
but not the $Phishing flag. This so that when an unextended
client removes the $Junk flag, an extended client will also show
the correct state. See [IMAP-KEYWORDS-REG] for more information.
$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 and SHOULD unset both of them on the IMAP server.
Other registered keywords can be found in the "IMAP and JMAP
Keywords" registry [IMAP-KEYWORDS-REG].
A flag can be permanent or session-only on a per-flag basis. A flag can be permanent or session-only on a per-flag basis.
Permanent flags are those which the client can add or remove from the Permanent flags are those which the client can add or remove from the
message flags permanently; that is, concurrent and subsequent message flags permanently; that is, concurrent and subsequent
sessions will see any change in permanent flags. Changes to session sessions will see any change in permanent flags. Changes to session
flags are valid only in that session. flags are valid only in that session.
2.3.3. Internal Date Message Attribute 2.3.3. Internal Date Message Attribute
The internal date and time of the message on the server. This is not The internal date and time of the message on the server. This is not
skipping to change at page 19, line 37 skipping to change at page 20, line 37
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
In IMAP4rev2, Mailbox names are encoded in Net-Unicode [NET-UNICODE] In IMAP4rev2, Mailbox names are encoded in Net-Unicode [NET-UNICODE]
(this differs from IMAP4rev1). Client implementations MAY attempt to (this differs from IMAP4rev1). Client implementations MAY attempt to
create Net-Unicode mailbox names, and MUST interpret any 8-bit create Net-Unicode mailbox names, and MUST interpret any 8-bit
mailbox names returned by LIST as [NET-UNICODE]. Server mailbox names returned by LIST as [NET-UNICODE]. Server
implementations MUST prohibit the creation of 8-bit mailbox names implementations MUST prohibit the creation of 8-bit mailbox names
that do not comply with Net-Unicode (however, servers MAY accept a that do not comply with Net-Unicode. However, servers MAY accept a
de-normalized UTF-8 mailbox name and convert it to Net-Unicode prior de-normalized UTF-8 mailbox name and convert it to Unicode
to mailbox creation). normalization form "NFC" (as per Net-Unicode requirements) prior to
mailbox creation. Servers that choose to accept such de-normalized
UTF-8 mailbox names MUST accept them in all IMAP commands that have a
mailbox name parameter. In particular SELECT <name> must open the
same mailbox that was successfully created with CREATE <name>, even
if <name> is a de-normalized UTF-8 mailbox name.
The case-insensitive mailbox name INBOX is a special name reserved to The case-insensitive mailbox name INBOX is a special name reserved to
mean "the primary mailbox for this user on this server". (Note that mean "the primary mailbox for this user on this server". (Note that
this special name may not exist on some servers for some users, for this special name may not exist on some servers for some users, for
example if the user has no access to personal namespace.) The example if the user has no access to personal namespace.) The
interpretation of all other names is implementation-dependent. interpretation of all other names is implementation-dependent.
In particular, this specification takes no position on case In particular, this specification takes no position on case
sensitivity in non-INBOX mailbox names. Some server implementations sensitivity in non-INBOX mailbox names. Some server implementations
are fully case-sensitive in ASCII range; others preserve case of a are fully case-sensitive in ASCII range; others preserve case of a
newly-created name but otherwise are case-insensitive; and yet others newly-created name but otherwise are case-insensitive; and yet others
coerce names to a particular case. Client implementations MUST coerce names to a particular case. Client implementations must be
interact with any of these. able to interact with any of these.
There are certain client considerations when creating a new mailbox There are certain client considerations when creating a new mailbox
name: name:
1. Any character which is one of the atom-specials (see the Formal 1. Any character which is one of the atom-specials (see the Formal
Syntax) will require that the mailbox name be represented as a Syntax) will require that the mailbox name be represented as a
quoted string or literal. quoted string or literal.
2. CTL and other non-graphic characters are difficult to represent 2. CTL and other non-graphic characters are difficult to represent
in a user interface and are best avoided. Servers MAY refuse to in a user interface and are best avoided. Servers MAY refuse to
skipping to change at page 75, line 36 skipping to change at page 76, line 36
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).
Server implementations MAY exclude [MIME-IMB] body parts with Server implementations MAY exclude [MIME-IMB] body parts with
terminal content media types other than TEXT and MESSAGE from terminal content media types other than TEXT and MESSAGE from
consideration in SEARCH matching. consideration in SEARCH matching.
The OPTIONAL [CHARSET] specification consists of the word "CHARSET" The OPTIONAL [CHARSET] specification consists of the word "CHARSET"
followed by a registered [CHARSET]. It indicates the [CHARSET] of followed by a registered [CHARSET] [CHARSET-REG]. It indicates the
the strings that appear in the search criteria. [MIME-IMB] content [CHARSET] of the strings that appear in the search criteria.
transfer encodings, and [MIME-HDRS] strings in [RFC-5322]/[MIME-IMB] [MIME-IMB] content transfer encodings, and [MIME-HDRS] strings in
headers, MUST be decoded before comparing text. Servers MUST support [RFC-5322]/[MIME-IMB] headers, MUST be decoded before comparing text.
US-ASCII and UTF-8 charsets; other [CHARSET]s MAY be supported. Servers MUST support US-ASCII and UTF-8 charsets; other [CHARSET]s
Clients SHOULD use UTF-8. Note that if "CHARSET" is not provided MAY be supported. Clients SHOULD use UTF-8. Note that if "CHARSET"
IMAP4rev2 server MUST assume UTF-8, so selecting CHARSET UTF-8 is is not provided IMAP4rev2 server MUST assume UTF-8, so selecting
redundant. It is permitted for improved compatibility with existing CHARSET UTF-8 is redundant. It is permitted for improved
IMAP4rev1 clients. compatibility with existing IMAP4rev1 clients.
If the server does not support the specified [CHARSET], it MUST If the server does not support the specified [CHARSET], it MUST
return a tagged NO response (not a BAD). This response SHOULD return a tagged NO response (not a BAD). This response SHOULD
contain the BADCHARSET response code, which MAY list the [CHARSET]s contain the BADCHARSET response code, which MAY list the [CHARSET]s
supported by the server. supported by the server.
In all search keys that use strings, a message matches the key if the In all search keys that use strings, a message matches the key if the
string is a substring of the associated text. The matching SHOULD be string is a substring of the associated text. The matching SHOULD be
case-insensitive for characters within ASCII range. Consider using case-insensitive for characters within ASCII range. Consider using
[IMAP-I18N] for language-sensitive case-insensitive searching. Note [IMAP-I18N] for language-sensitive case-insensitive searching. Note
skipping to change at page 105, line 5 skipping to change at page 106, line 5
response code when the LDAP/Radius server is down. response code when the LDAP/Radius server is down.
C: a LOGIN "fred" "foo" C: a LOGIN "fred" "foo"
S: a NO [UNAVAILABLE] User's backend down for maintenance S: a NO [UNAVAILABLE] User's backend down for maintenance
UNKNOWN-CTE UNKNOWN-CTE
The server does not know how to decode the section's Content- The server does not know how to decode the section's Content-
Transfer-Encoding. Transfer-Encoding.
Additional response codes defined by particular client or server Client implementations MUST ignore response codes that they do not
implementations SHOULD be prefixed with an "X" until they are added recognize.
to a revision of this protocol. Client implementations SHOULD ignore
response codes that they do not recognize.
7.1.1. OK Response 7.1.1. OK Response
Contents: OPTIONAL response code Contents: OPTIONAL response code
human-readable text human-readable text
The OK response indicates an information message from the server. The OK response indicates an information message from the server.
When tagged, it indicates successful completion of the associated When tagged, it indicates successful completion of the associated
command. The human-readable text MAY be presented to the user as an command. The human-readable text MAY be presented to the user as an
information message. The untagged form indicates an information-only information message. The untagged form indicates an information-only
skipping to change at page 108, line 21 skipping to change at page 109, line 16
disabled, and that the server will respond with a tagged NO response disabled, and that the server will respond with a tagged NO response
to any attempt to use the LOGIN command even if the user name and to any attempt to use the LOGIN command even if the user name and
password are valid. An IMAP client MUST NOT issue the LOGIN command password are valid. An IMAP client MUST NOT issue the LOGIN command
if the server advertises the LOGINDISABLED capability. if the server advertises the LOGINDISABLED capability.
Other capability names indicate that the server supports an Other capability names indicate that the server supports an
extension, revision, or amendment to the IMAP4rev2 protocol. Server extension, revision, or amendment to the IMAP4rev2 protocol. Server
responses MUST conform to this document until the client issues a responses MUST conform to this document until the client issues a
command that uses the associated capability. command that uses the associated capability.
Capability names MUST either begin with "X" or be standard or Capability names MUST either begin with "X" or be informational,
standards-track IMAP4rev2 extensions, revisions, or amendments experimental or standards-track IMAP4rev2 extensions, revisions, or
registered with IANA. A server MUST NOT offer unregistered or non- amendments registered with IANA. A server MUST NOT offer
standard capability names, unless such names are prefixed with an unregistered or non-standard capability names, unless such names are
"X". prefixed with an "X".
Client implementations SHOULD NOT require any capability name other Client implementations SHOULD NOT require any capability name other
than "IMAP4rev2", and MUST ignore any unknown capability names. than "IMAP4rev2", and 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.
skipping to change at page 108, line 50 skipping to change at page 109, line 45
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.
The following base name attributes are defined: The following base mailbox name attributes are defined:
\NonExistent The "\NonExistent" attribute indicates that a mailbox \NonExistent The "\NonExistent" attribute indicates that a mailbox
name does not refer to an existing mailbox. Note that this name does not refer to an existing mailbox. Note that this
attribute is not meaningful by itself, as mailbox names that match attribute is not meaningful by itself, as mailbox names that match
the canonical LIST pattern but don't exist must not be returned the canonical LIST pattern but don't exist must not be returned
unless one of the two conditions listed below is also satisfied: unless one of the two conditions listed below is also satisfied:
1. The mailbox name also satisfies the selection criteria (for 1. The mailbox name also satisfies the selection criteria (for
example, it is subscribed and the "SUBSCRIBED" selection example, it is subscribed and the "SUBSCRIBED" selection
option has been specified). option has been specified).
skipping to change at page 110, line 30 skipping to change at page 111, line 23
Note: the \HasNoChildren attribute should not be confused with the Note: the \HasNoChildren attribute should not be confused with the
\NoInferiors attribute, which indicates that no child mailboxes \NoInferiors attribute, which indicates that no child mailboxes
exist now and none can be created in the future. exist now and none can be created in the future.
If it is not feasible for the server to determine whether or not the If it is not feasible for the server to determine whether or not the
mailbox is "interesting", the server SHOULD NOT send either \Marked mailbox is "interesting", the server SHOULD NOT send either \Marked
or \Unmarked. The server MUST NOT send more than one of \Marked, or \Unmarked. The server MUST NOT send more than one of \Marked,
\Unmarked, and \Noselect for a single mailbox, and MAY send none of \Unmarked, and \Noselect for a single mailbox, and MAY send none of
these. these.
In addition to the base name attributes defined above, an IMAP server In addition to the base mailbox name attributes defined above, an
MAY also include any or all of the following attributes that denote IMAP server MAY also include any or all of the following attributes
"role" (or "special-use") of a mailbox. These attributes are that denote "role" (or "special-use") of a mailbox. These attributes
included along with base attributes defined above. A given mailbox are included along with base attributes defined above. A given
may have none, one, or more than one of these attributes. In some mailbox may have none, one, or more than one of these attributes. In
cases, a special use is advice to a client about what to put in that some cases, a special use is advice to a client about what to put in
mailbox. In other cases, it's advice to a client about what to that mailbox. In other cases, it's advice to a client about what to
expect to find there. expect to find there.
\All This mailbox presents all messages in the user's message store. \All This mailbox presents all messages in the user's message store.
Implementations MAY omit some messages, such as, perhaps, those in Implementations MAY omit some messages, such as, perhaps, those in
\Trash and \Junk. When this special use is supported, it is \Trash and \Junk. When this special use is supported, it is
almost certain to represent a virtual mailbox. almost certain to represent a virtual mailbox.
\Archive This mailbox is used to archive messages. The meaning of \Archive This mailbox is used to archive messages. The meaning of
an "archival" mailbox is server-dependent; typically, it will be an "archival" mailbox is server-dependent; typically, it will be
used to get messages out of the inbox, or otherwise keep them out used to get messages out of the inbox, or otherwise keep them out
skipping to change at page 111, line 43 skipping to change at page 112, line 36
message store may support any combination of the attributes, or none message store may support any combination of the attributes, or none
at all. In most cases, there will likely be at most one mailbox with at all. In most cases, there will likely be at most one mailbox with
a given attribute for a given user, but in some server or message a given attribute for a given user, but in some server or message
store implementations it might be possible for multiple mailboxes to store implementations it might be possible for multiple mailboxes to
have the same special-use attribute. have the same special-use attribute.
Special-use attributes are likely to be user-specific. User Adam Special-use attributes are likely to be user-specific. User Adam
might share his \Sent mailbox with user Barb, but that mailbox is might share his \Sent mailbox with user Barb, but that mailbox is
unlikely to also serve as Barb's \Sent mailbox. unlikely to also serve as Barb's \Sent mailbox.
Other mailbox name attributes can be found in the "IMAP Mailbox Name
Attributes" registry [IMAP-MAILBOX-NAME-ATTRS-REG].
The hierarchy delimiter is a character used to delimit levels of The hierarchy delimiter is a character used to delimit levels of
hierarchy in a mailbox name. A client can use it to create child hierarchy in a mailbox name. A client can use it to create child
mailboxes, and to search higher or lower levels of naming hierarchy. mailboxes, and to search higher or lower levels of naming hierarchy.
All children of a top-level hierarchy node MUST use the same All children of a top-level hierarchy node MUST use the same
separator character. A NIL hierarchy delimiter means that no separator character. A NIL hierarchy delimiter means that no
hierarchy exists; the name is a "flat" name. hierarchy exists; the name is a "flat" name.
The name represents an unambiguous left-to-right hierarchy, and MUST The name represents an unambiguous left-to-right hierarchy, and MUST
be valid for use as a reference in LIST command. Unless \Noselect or be valid for use as a reference in LIST command. Unless \Noselect or
\NonExistent is indicated, the name MUST also be valid as an argument \NonExistent is indicated, the name MUST also be valid as an argument
skipping to change at page 121, line 9 skipping to change at page 121, line 46
members in the envelope can not be NIL. members in the envelope can not be NIL.
FLAGS A parenthesized list of flags that are set for this message. FLAGS A parenthesized list of flags that are set for this message.
INTERNALDATE A string representing the internal date of the message. INTERNALDATE A string representing the internal date of the message.
RFC822.SIZE A number expressing the [RFC-5322] size of the message. RFC822.SIZE A number expressing the [RFC-5322] size of the message.
UID A number expressing the unique identifier of the message. UID A number expressing the unique identifier of the message.
If the server chooses to send unsolicited FETCH responses, they MUST
include UID FETCH item. Note that this is a new requirement when
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.5. Server Responses - Command Continuation Request
The command continuation request response is indicated by a "+" token The command continuation request response is indicated by a "+" token
instead of a tag. This form of response indicates that the server is instead of a tag. This form of response indicates that the server is
ready to accept the continuation of a command from the client. The ready to accept the continuation of a command from the client. The
remainder of this response is a line of text. remainder of this response is a line of text.
This response is used in the AUTHENTICATE command to transmit server This response is used in the AUTHENTICATE command to transmit server
skipping to change at page 128, line 46 skipping to change at page 129, line 46
; MUST accept flag-extension flags. Server ; MUST accept flag-extension flags. Server
; implementations MUST NOT generate ; implementations MUST NOT generate
; flag-extension flags except as defined by ; flag-extension flags except as defined by
; future standard or standards-track ; future standard or standards-track
; revisions of this specification. ; revisions of this specification.
; "\Recent" was defined in RFC 3501 ; "\Recent" was defined in RFC 3501
; and is now deprecated. ; and is now deprecated.
flag-fetch = flag flag-fetch = flag
flag-keyword = "$MDNSent" / "$Forwarded" / atom flag-keyword = "$MDNSent" / "$Forwarded" / "$Junk" /
"$NotJunk" / "$Phishing" / atom
flag-list = "(" [flag *(SP flag)] ")" flag-list = "(" [flag *(SP flag)] ")"
flag-perm = flag / "\*" flag-perm = flag / "\*"
greeting = "*" SP (resp-cond-auth / resp-cond-bye) CRLF greeting = "*" SP (resp-cond-auth / resp-cond-bye) CRLF
header-fld-name = astring header-fld-name = astring
header-list = "(" header-fld-name *(SP header-fld-name) ")" header-list = "(" header-fld-name *(SP header-fld-name) ")"
skipping to change at page 142, line 9 skipping to change at page 143, line 9
3. Both UDP port 143 and UDP port 993 should be marked as "Reserved" 3. Both UDP port 143 and UDP port 993 should be marked as "Reserved"
in the registry. in the registry.
Additional IANA actions are specified in subsection of this section. Additional IANA actions are specified in subsection of this section.
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: http://www.iana.org/assignments/ currently located at: https://www.iana.org/assignments/
imap4-capabilities imap4-capabilities
As this specification revises the STARTTLS and LOGINDISABLED As this specification revises the STARTTLS and LOGINDISABLED
extensions previously defined in [IMAP-TLS], IANA is requested to extensions previously defined in [IMAP-TLS], IANA is requested to
update registry entries for these 2 extensions to point to this update registry entries for these 2 extensions to point to this
document. document.
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
skipping to change at page 145, line 31 skipping to change at page 146, line 31
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)
[RFC3503] Melnikov, A., "Message Disposition Notification (MDN)
profile for Internet Message Access Protocol (IMAP)",
RFC 3503, DOI 10.17487/RFC3503, March 2003,
<https://www.rfc-editor.org/info/rfc3503>.
[RFC5256] Crispin, M. and K. Murchison, "Internet Message Access [RFC5256] Crispin, M. and K. Murchison, "Internet Message Access
Protocol - SORT and THREAD Extensions", RFC 5256, Protocol - SORT and THREAD Extensions", RFC 5256,
DOI 10.17487/RFC5256, June 2008, DOI 10.17487/RFC5256, June 2008,
<https://www.rfc-editor.org/info/rfc5256>. <https://www.rfc-editor.org/info/rfc5256>.
[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>.
skipping to change at page 146, line 45 skipping to change at page 148, line 5
<http://www.rfc-editor.org/info/rfc4314>. <http://www.rfc-editor.org/info/rfc4314>.
[RFC2087] Myers, J., "IMAP4 QUOTA extension", RFC 2087, January [RFC2087] Myers, J., "IMAP4 QUOTA extension", RFC 2087, January
1997, <http://www.rfc-editor.org/info/rfc2087>. 1997, <http://www.rfc-editor.org/info/rfc2087>.
[IMAP-URL] [IMAP-URL]
Melnikov, A., Ed. and C. Newman, "IMAP URL Scheme", Melnikov, A., Ed. and C. Newman, "IMAP URL Scheme",
RFC 5092, DOI 10.17487/RFC5092, November 2007, RFC 5092, DOI 10.17487/RFC5092, November 2007,
<http://www.rfc-editor.org/info/rfc5092>. <http://www.rfc-editor.org/info/rfc5092>.
[IMAP-KEYWORDS-REG]
IANA, "IMAP and JMAP Keywords", December 2009,
<https://www.iana.org/assignments/imap-jmap-keywords/imap-
jmap-keywords.xhtml>.
[IMAP-MAILBOX-NAME-ATTRS-REG]
IANA, "IMAP Mailbox Name Attributes", June 2018,
<https://www.iana.org/assignments/imap-mailbox-name-
attributes/imap-mailbox-name-attributes.xhtml>.
[CHARSET-REG]
IANA, "Character Set Registrations", May 2015,
<https://www.iana.org/assignments/charset-reg/charset-
reg.xhtml>.
13.3. Informative References (historical aspects of IMAP and related 13.3. Informative References (historical aspects of IMAP and related
protocols) protocols)
[IMAP-COMPAT] [IMAP-COMPAT]
Crispin, M., "IMAP4 Compatibility with IMAP2bis", Crispin, M., "IMAP4 Compatibility with IMAP2bis",
RFC 2061, December 1996, RFC 2061, December 1996,
<http://www.rfc-editor.org/info/rfc2061>. <http://www.rfc-editor.org/info/rfc2061>.
[IMAP-HISTORICAL] [IMAP-HISTORICAL]
Crispin, M., "IMAP4 Compatibility with IMAP2 and Crispin, M., "IMAP4 Compatibility with IMAP2 and
skipping to change at page 149, line 32 skipping to change at page 151, line 4
mailbox name with an embedded "&" character unless it complies with mailbox name with an embedded "&" character unless it complies with
the modified UTF-7 syntax. the modified UTF-7 syntax.
Server implementations which export a mail store that does not follow Server implementations which export a mail store that does not follow
the modified UTF-7 convention MUST convert to modified UTF-7 any the modified UTF-7 convention MUST convert to modified UTF-7 any
mailbox name that contains either non-ASCII characters or the "&" mailbox name that contains either non-ASCII characters or the "&"
character. character.
For example, here is a mailbox name which mixes English, Chinese, For example, here is a mailbox name which mixes English, Chinese,
and Japanese text: ~peter/mail/&U,BTFw-/&ZeVnLIqe- and Japanese text: ~peter/mail/&U,BTFw-/&ZeVnLIqe-
For example, the string "&Jjo!" is not a valid mailbox name For example, the string "&Jjo!" is not a valid mailbox name
because it does not contain a shift to US-ASCII before the "!". because it does not contain a shift to US-ASCII before the "!".
The correct form is "&Jjo-!". The string "&U,BTFw-&ZeVnLIqe-" is The correct form is "&Jjo-!". The string "&U,BTFw-&ZeVnLIqe-" is
not permitted because it contains a superfluous shift. The not permitted because it contains a superfluous shift. The
correct form is "&U,BTF2XlZyyKng-". correct form is "&U,BTF2XlZyyKng-".
Appendix B. Backward compatibility with BINARY extension Appendix B. Backward compatibility with BINARY extension
IMAP4rev2 is incorporates subset of functionality provided by the IMAP4rev2 is incorporates subset of functionality provided by the
BINARY extension [RFC3516], in particular it includes additional BINARY extension [RFC3516], in particular it includes additional
FETCH items (BINARY, BINARY.PEEK and BINARY.SIZE), but not extensions FETCH items (BINARY, BINARY.PEEK and BINARY.SIZE), but not extensions
to the APPEND command. IMAP4rev2 implementations that supports full to the APPEND command. IMAP4rev2 implementations that supports full
RFC 3516 functionality need to also advertise the BINARY token in the RFC 3516 functionality need to also advertise the BINARY token in the
CAPABILITY response. CAPABILITY response.
Appendix C. Changes from RFC 3501 / IMAP4rev1 Appendix C. Changes from RFC 3501 / IMAP4rev1
The following is the plan for remaining changes. The plan might The following is the plan for remaining changes. The plan might
change over time. change over time.
1. Fold in the following extensions/RFC: RFC 5530 (IMAP Response 1. Revise IANA registration of IMAP extensions and give advice on
Codes, done), UIDPLUS (done), ENABLE (done), ESEARCH (done), use of "X-" convention.
SPECIAL-USE (list of new mailbox attributes is done), LITERAL-
(done), NAMESPACE (done), SASL-IR (done), IDLE (done), MOVE
(done).
2. Add CLOSED response code (from CONDSTORE) - done 2. Allow word-based searching (as per Chris Newman)? Need to
discuss header field search, where exact/substring match is still
required for interoperability.
3. Add support for $MDNSent and $Forwarded IMAP keywords - done. The following changes were already done:
Add more examples showing their use? Also add other keywords
like $Phishing, $Junk, $NonJunk?
4. Require all unsolicited FETCH updates to include UID - done. 1. Fold in the following extensions/RFC: RFC 5530 (IMAP Response
Codes), UIDPLUS, ENABLE, ESEARCH, SPECIAL-USE (list of new
mailbox attributes is done), LITERAL-, NAMESPACE, SASL-IR, IDLE,
MOVE.
5. Update recommendations on TLS ciphers to match UTA WG work (as 2. Add CLOSED response code (from CONDSTORE).
per RFC 8314, RFC 7525 and RFC 7817) - done.
6. Possibly fold in the following extensions/RFC: Base LIST- 3. Add support for $Phishing, $Junk, $NonJunk, $MDNSent and
EXTENDED syntax plus deprecate LSUB (replace it with LIST $Forwarded IMAP keywords. Add more examples showing their use?
\Subscribed) minus the requirement to support multiple list
patterns - done, STATUS-in-LIST - done, SEARCHRES, BINARY (only
the FETCH changes on leaf body part and make APPEND related ones
optional. See the mailing list discussion) - done.
7. Add STATUS SIZE (total mailbox size) - done. Add STATUS DELETED 4. Require all unsolicited FETCH updates to include UID.
(number of messages with \Deleted flag set) - done.
8. Drop UTF-7, all mailboxes are always in UTF-8 - done. 5. Update recommendations on TLS ciphers to match UTA WG work (as
per RFC 8314, RFC 7525 and RFC 7817).
9. Revise IANA registration of IMAP extensions and give advice on 6. Possibly fold in the following extensions/RFC: Base LIST-EXTENDED
use of "X-" convention. syntax plus deprecate LSUB (replace it with LIST \Subscribed)
minus the requirement to support multiple list patterns, STATUS-
in-LIST, SEARCHRES, BINARY (only the FETCH changes on leaf body
part and make APPEND related ones optional. See the mailing list
discussion).
10. Allow word-based searching (as per Chris Newman)? Need to 7. Add STATUS SIZE (total mailbox size). Add STATUS DELETED (number
discuss header field search, where exact/substring match is of messages with \Deleted flag set).
still required for interoperability.
8. Drop UTF-7, all mailboxes are always in UTF-8.
The following changes since RFC 3501 were done so far: The following changes since RFC 3501 were done so far:
1. Folded in IMAP UNSELECT (RFC 3691), UIDPLUS (RFC 4315), ESEARCH 1. Folded in IMAP UNSELECT (RFC 3691), UIDPLUS (RFC 4315), ESEARCH
(RFC 4731), ENABLE (RFC 5161), IDLE (RFC 2177), SASL-IR (RFC (RFC 4731), ENABLE (RFC 5161), IDLE (RFC 2177), SASL-IR (RFC
4959), LIST-STATUS (RFC 5819) and MOVE (RFC 6851) extensions. 4959), LIST-STATUS (RFC 5819) and MOVE (RFC 6851) extensions.
Also folded RFC 5530 and FETCH side of the BINARY extension (RFC Also folded RFC 5530 and FETCH side of the BINARY extension (RFC
3516). 3516).
2. Clarified that server should decode parameter value 2. Clarified that server should decode parameter value
skipping to change at page 151, line 19 skipping to change at page 152, line 38
mailbox is already selected now require for the CLOSED response mailbox is already selected now require for the CLOSED response
code to be returned. code to be returned.
5. Updated to use modern TLS-related recommendations as per RFC 5. Updated to use modern TLS-related recommendations as per RFC
8314, RFC 7817, RFC 7525. 8314, RFC 7817, RFC 7525.
6. For future extensibility extended ABNF for tagged-ext-simple to 6. For future extensibility extended ABNF for tagged-ext-simple to
allow for bare number64. allow for bare number64.
7. Added SHOULD level requirement on IMAP servers to support 7. Added SHOULD level requirement on IMAP servers to support
$MDNSent and $Forwarded keywords. $MDNSent, $Forwarded, $Junk, $NonJunk and $Phishing keywords.
8. Added STATUS SIZE and STATUS DELETED. 8. Added STATUS SIZE and STATUS DELETED.
9. Mailbox names and message headers now allow for UTF-8. Support 9. 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.
10. UNSEEN response code on SELECT/EXAMINE is now deprecated. 10. UNSEEN response code on SELECT/EXAMINE is now deprecated.
11. RECENT response on SELECT/EXAMINE, \Recent flag, RECENT STATUS, 11. RECENT response on SELECT/EXAMINE, \Recent flag, RECENT STATUS,
skipping to change at page 152, line 5 skipping to change at page 153, line 26
MD5 was deprecated. MD5 was deprecated.
16. LSUB command was deprecated. Clients should use LIST 16. LSUB command was deprecated. Clients should use LIST
(SUBSCRIBED) instead. (SUBSCRIBED) instead.
17. resp-text ABNF non terminal was updated to allow for empty text. 17. resp-text ABNF non terminal was updated to allow for empty text.
18. IDLE command can now return updates not related to the currently 18. 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.
Appendix D. Acknowledgement Appendix D. Acknowledgement
Earlier versions of this document were edited by Mark Crispin. Earlier versions of this document were edited by Mark Crispin.
Sadly, he is no longer available to help with this work. Editors of Sadly, he is no longer available to help with this work. Editors of
this revisions are hoping that Mark would have approved. this revisions are hoping that Mark would have approved.
Chris Newman has contributed text on I18N and use of UTF-8 in Chris Newman has contributed text on I18N and use of UTF-8 in
messages and mailbox names. messages and mailbox names.
Thank you to Tony Hansen for helping with the index generation. Thank you to Tony Hansen for helping with the index generation.
skipping to change at page 152, line 29 skipping to change at page 154, line 9
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 5530 (by Arnt Gulbrandsen), RFC 5819 (by Timo Gulbrandsen), RFC 5530 (by Arnt Gulbrandsen), RFC 5819 (by Timo
Sirainen), RFC 6154 (by Jamie Nicolson) so work done by authors/ Sirainen), RFC 6154 (by Jamie Nicolson) 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.
Index Index
$ $
$Forwarded (predefined flag) 12 $Forwarded (predefined flag) 12
$Junk (predefined flag) 12
$MDNSent (predefined flag) 12 $MDNSent (predefined flag) 12
$NotJunk (predefined flag) 12
$Phishing (predefined flag) 12
+ +
+FLAGS <flag list> 90 +FLAGS <flag list> 91
+FLAGS.SILENT <flag list> 90 +FLAGS.SILENT <flag list> 91
- -
-FLAGS <flag list> 90 -FLAGS <flag list> 91
-FLAGS.SILENT <flag list> 90 -FLAGS.SILENT <flag list> 91
A A
ALERT (response code) 97 ALERT (response code) 98
ALL (fetch item) 86 ALL (fetch item) 87
ALL (search key) 76 ALL (search key) 77
ALL (search result option) 74 ALL (search result option) 75
ALREADYEXISTS (response code) 97 ALREADYEXISTS (response code) 98
ANSWERED (search key) 76 ANSWERED (search key) 77
APPEND (command) 66 APPEND (command) 67
APPENDUID (response code) 97 APPENDUID (response code) 98
AUTHENTICATE (command) 28 AUTHENTICATE (command) 29
AUTHENTICATIONFAILED (response code) 98 AUTHENTICATIONFAILED (response code) 99
AUTHORIZATIONFAILED (response code) 98 AUTHORIZATIONFAILED (response code) 99
B B
BAD (response) 106 BAD (response) 106
BADCHARSET (response code) 99 BADCHARSET (response code) 100
BCC <string> (search key) 76 BCC <string> (search key) 77
BEFORE <date> (search key) 76 BEFORE <date> (search key) 77
BINARY.PEEK[<section-binary>]<<partial>> (fetch item) 86 BINARY.PEEK[<section-binary>]<<partial>> (fetch item) 87
BINARY.SIZE[<section-binary>] (fetch item) 86 BINARY.SIZE[<section-binary>] (fetch item) 87
BINARY.SIZE[<section-binary>] (fetch result) 116 BINARY.SIZE[<section-binary>] (fetch result) 117
BINARY[<section-binary>]<<number>> (fetch result) 115 BINARY[<section-binary>]<<number>> (fetch result) 116
BINARY[<section-binary>]<<partial>> (fetch item) 86 BINARY[<section-binary>]<<partial>> (fetch item) 87
BODY (fetch item) 87 BODY (fetch item) 88
BODY (fetch result) 116 BODY (fetch result) 117
BODY <string> (search key) 76 BODY <string> (search key) 77
BODY.PEEK[<section>]<<partial>> (fetch item) 89 BODY.PEEK[<section>]<<partial>> (fetch item) 90
BODYSTRUCTURE (fetch item) 89 BODYSTRUCTURE (fetch item) 90
BODYSTRUCTURE (fetch result) 117 BODYSTRUCTURE (fetch result) 117
BODY[<section>]<<origin octet>> (fetch result) 116 BODY[<section>]<<origin octet>> (fetch result) 117
BODY[<section>]<<partial>> (fetch item) 87 BODY[<section>]<<partial>> (fetch item) 88
BYE (response) 106 BYE (response) 107
Body Structure (message attribute) 13 Body Structure (message attribute) 14
C C
CANNOT (response code) 99 CANNOT (response code) 100
CAPABILITY (command) 24 CAPABILITY (command) 25
CAPABILITY (response code) 99 CAPABILITY (response code) 100
CAPABILITY (response) 107 CAPABILITY (response) 108
CC <string> (search key) 76 CC <string> (search key) 77
CLIENTBUG (response code) 99 CLIENTBUG (response code) 100
CLOSE (command) 71 CLOSE (command) 72
CLOSED (response code) 99 CLOSED (response code) 100
CONTACTADMIN (response code) 100 CONTACTADMIN (response code) 101
COPY (command) 90 COPY (command) 91
COPYUID (response code) 100 COPYUID (response code) 101
CORRUPTION (response code) 100 CORRUPTION (response code) 101
COUNT (search result option) 74 COUNT (search result option) 75
CREATE (command) 37 CREATE (command) 38
D D
DELETE (command) 38 DELETE (command) 39
DELETED (search key) 76 DELETED (search key) 77
DELETED (status item) 66 DELETED (status item) 67
DRAFT (search key) 76 DRAFT (search key) 77
E E
ENABLE (command) 32 ENABLE (command) 33
ENVELOPE (fetch item) 89 ENVELOPE (fetch item) 90
ENVELOPE (fetch result) 119 ENVELOPE (fetch result) 120
ESEARCH (response) 113 ESEARCH (response) 113
EXAMINE (command) 36 EXAMINE (command) 37
EXPIRED (response code) 101 EXPIRED (response code) 102
EXPUNGE (command) 72 EXPUNGE (command) 73
EXPUNGE (response) 114 EXPUNGE (response) 115
EXPUNGEISSUED (response code) 101 EXPUNGEISSUED (response code) 102
Envelope Structure (message attribute) 13 Envelope Structure (message attribute) 14
F F
FAST (fetch item) 86 FAST (fetch item) 87
FETCH (command) 85 FETCH (command) 86
FETCH (response) 115 FETCH (response) 116
FLAGGED (search key) 76 FLAGGED (search key) 77
FLAGS (fetch item) 89 FLAGS (fetch item) 90
FLAGS (fetch result) 120 FLAGS (fetch result) 121
FLAGS (response) 113 FLAGS (response) 114
FLAGS <flag list> (store command data item) 90 FLAGS <flag list> (store command data item) 91
FLAGS.SILENT <flag list> (store command data item) 90 FLAGS.SILENT <flag list> (store command data item) 91
FROM <string> (search key) 76 FROM <string> (search key) 77
FULL (fetch item) 86 FULL (fetch item) 87
Flags (message attribute) 11 Flags (message attribute) 11
H H
HEADER (part specifier) 87 HEADER (part specifier) 88
HEADER <field-name> <string> (search key) 76 HEADER <field-name> <string> (search key) 77
HEADER.FIELDS (part specifier) 87 HEADER.FIELDS (part specifier) 88
HEADER.FIELDS.NOT (part specifier) 87 HEADER.FIELDS.NOT (part specifier) 88
I I
IDLE (command) 69 IDLE (command) 70
INTERNALDATE (fetch item) 89 INTERNALDATE (fetch item) 90
INTERNALDATE (fetch result) 120 INTERNALDATE (fetch result) 121
INUSE (response code) 101 INUSE (response code) 102
Internal Date (message attribute) 12 Internal Date (message attribute) 13
K K
KEYWORD <flag> (search key) 77 KEYWORD <flag> (search key) 78
Keyword (type of flag) 12 Keyword (type of flag) 12
L L
LARGER <n> (search key) 77 LARGER <n> (search key) 78
LIMIT (response code) 101 LIMIT (response code) 102
LIST (command) 42 LIST (command) 43
LIST (response) 108 LIST (response) 109
LOGOUT (command) 26 LOGOUT (command) 27
M M
MAX (search result option) 74 MAX (search result option) 75
MAY (specification requirement term) 5 MAY (specification requirement term) 5
MESSAGES (status item) 66 MESSAGES (status item) 67
MIME (part specifier) 88 MIME (part specifier) 89
MIN (search result option) 74 MIN (search result option) 75
MOVE (command) 91 MOVE (command) 92
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) 60 NAMESPACE (command) 61
NAMESPACE (response) 112 NAMESPACE (response) 113
NO (response) 105 NO (response) 106
NONEXISTENT (response code) 102 NONEXISTENT (response code) 103
NOOP (command) 25 NOOP (command) 26
NOPERM (response code) 102 NOPERM (response code) 103
NOT <search-key> (search key) 77 NOT <search-key> (search key) 78
NOT RECOMMENDED (specification requirement term) 5 NOT RECOMMENDED (specification requirement term) 5
O O
OK (response) 105 OK (response) 106
ON <date> (search key) 77 ON <date> (search key) 78
OPTIONAL (specification requirement term) 5 OPTIONAL (specification requirement term) 5
OR <search-key1> <search-key2> (search key) 77 OR <search-key1> <search-key2> (search key) 78
OVERQUOTA (response code) 102 OVERQUOTA (response code) 103
P P
PARSE (response code) 102 PARSE (response code) 103
PERMANENTFLAGS (response code) 102 PERMANENTFLAGS (response code) 103
PREAUTH (response) 106 PREAUTH (response) 107
PRIVACYREQUIRED (response code) 103 PRIVACYREQUIRED (response code) 104
Permanent Flag (class of flag) 12 Permanent Flag (class of flag) 13
Predefined keywords 12 Predefined keywords 12
R R
READ-ONLY (response code) 103 READ-ONLY (response code) 104
READ-WRITE (response code) 103 READ-WRITE (response code) 104
RECOMMENDED (specification requirement term) 5 RECOMMENDED (specification requirement term) 5
RENAME (command) 39 RENAME (command) 40
REQUIRED (specification requirement term) 5 REQUIRED (specification requirement term) 5
RFC822.SIZE (fetch item) 89 RFC822.SIZE (fetch item) 90
RFC822.SIZE (fetch result) 121 RFC822.SIZE (fetch result) 121
S S
SAVE (search result option) 74 SAVE (search result option) 75
SEARCH (command) 73 SEARCH (command) 74
SEEN (search key) 77 SEEN (search key) 78
SELECT (command) 34 SELECT (command) 35
SENTBEFORE <date> (search key) 77 SENTBEFORE <date> (search key) 78
SENTON <date> (search key) 77 SENTON <date> (search key) 78
SENTSINCE <date> (search key) 77 SENTSINCE <date> (search key) 78
SERVERBUG (response code) 103 SERVERBUG (response code) 104
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) 77 SINCE <date> (search key) 78
SIZE (status item) 66 SIZE (status item) 67
SMALLER <n> (search key) 77 SMALLER <n> (search key) 78
STARTTLS (command) 27 STARTTLS (command) 28
STATUS (command) 65 STATUS (command) 66
STATUS (response) 112 STATUS (response) 113
STORE (command) 89 STORE (command) 90
SUBJECT <string> (search key) 77 SUBJECT <string> (search key) 78
SUBSCRIBE (command) 41 SUBSCRIBE (command) 42
Session Flag (class of flag) 12 Session Flag (class of flag) 13
System Flag (type of flag) 11 System Flag (type of flag) 11
T T
TEXT (part specifier) 87 TEXT (part specifier) 88
TEXT <string> (search key) 77 TEXT <string> (search key) 78
TO <string> (search key) 77 TO <string> (search key) 78
TRYCREATE (response code) 103 TRYCREATE (response code) 104
U U
UID (command) 93 UID (command) 94
UID (fetch item) 89 UID (fetch item) 90
UID (fetch result) 121 UID (fetch result) 121
UID <sequence set> (search key) 78 UID <sequence set> (search key) 79
UIDNEXT (response code) 104 UIDNEXT (response code) 105
UIDNEXT (status item) 66 UIDNEXT (status item) 67
UIDNOTSTICKY (response code) 104 UIDNOTSTICKY (response code) 105
UIDVALIDITY (response code) 104 UIDVALIDITY (response code) 105
UIDVALIDITY (status item) 66 UIDVALIDITY (status item) 67
UNANSWERED (search key) 78 UNANSWERED (search key) 79
UNAVAILABLE (response code) 104 UNAVAILABLE (response code) 105
UNDELETED (search key) 78 UNDELETED (search key) 79
UNDRAFT (search key) 78 UNDRAFT (search key) 79
UNFLAGGED (search key) 78 UNFLAGGED (search key) 79
UNKEYWORD <flag> (search key) 78 UNKEYWORD <flag> (search key) 79
UNKNOWN-CTE (response code) 104 UNKNOWN-CTE (response code) 105
UNSEEN (search key) 78 UNSEEN (search key) 79
UNSEEN (status item) 66 UNSEEN (status item) 67
UNSELECT (command) 72 UNSELECT (command) 73
UNSUBSCRIBE (command) 42 UNSUBSCRIBE (command) 43
Unique Identifier (UID) (message attribute) 9 Unique Identifier (UID) (message attribute) 9
X X
X<atom> (command) 95 X<atom> (command) 96
[ [
[RFC-5322] Size (message attribute) 13 [RFC-5322] Size (message attribute) 13
\ \
\All (mailbox name attribute) 110 \All (mailbox name attribute) 111
\Answered (system flag) 11 \Answered (system flag) 11
\Archive (mailbox name attribute) 110 \Archive (mailbox name attribute) 111
\Deleted (system flag) 11 \Deleted (system flag) 12
\Draft (system flag) 12 \Draft (system flag) 12
\Drafts (mailbox name attribute) 110 \Drafts (mailbox name attribute) 111
\Flagged (mailbox name attribute) 111 \Flagged (mailbox name attribute) 111
\Flagged (system flag) 11 \Flagged (system flag) 11
\HasChildren (mailbox name attribute) 109 \HasChildren (mailbox name attribute) 110
\HasNoChildren (mailbox name attribute) 109 \HasNoChildren (mailbox name attribute) 110
\Junk (mailbox name attribute) 111 \Junk (mailbox name attribute) 112
\Marked (mailbox name attribute) 110 \Marked (mailbox name attribute) 110
\Noinferiors (mailbox name attribute) 109 \Noinferiors (mailbox name attribute) 110
\NonExistent (mailbox name attribute) 109 \NonExistent (mailbox name attribute) 109
\Noselect (mailbox name attribute) 109 \Noselect (mailbox name attribute) 110
\Recent (system flag) 12 \Recent (system flag) 12
\Remote (mailbox name attribute) 110 \Remote (mailbox name attribute) 111
\Seen (system flag) 11 \Seen (system flag) 11
\Sent (mailbox name attribute) 111 \Sent (mailbox name attribute) 112
\Subscribed (mailbox name attribute) 110 \Subscribed (mailbox name attribute) 111
\Trash (mailbox name attribute) 111 \Trash (mailbox name attribute) 112
\Unmarked (mailbox name attribute) 110 \Unmarked (mailbox name attribute) 110
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
 End of changes. 82 change blocks. 
344 lines changed or deleted 427 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/