draft-ietf-extra-imap4rev2-02.txt   draft-ietf-extra-imap4rev2-03.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: April 22, 2019 October 19, 2018 Expires: August 7, 2019 February 3, 2019
INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev2 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev2
draft-ietf-extra-imap4rev2-02.txt draft-ietf-extra-imap4rev2-03
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 April 22, 2019. This Internet-Draft will expire on August 7, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
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 . . . . . . . . . . . 13 2.3.3. Internal Date Message Attribute . . . . . . . . . . . 12
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 . . . . . . . . 13
2.3.6. Body Structure Message Attribute . . . . . . . . . . 13 2.3.6. Body Structure Message Attribute . . . . . . . . . . 13
2.4. Message Texts . . . . . . . . . . . . . . . . . . . . . . 13 2.4. Message Texts . . . . . . . . . . . . . . . . . . . . . . 13
3. State and Flow Diagram . . . . . . . . . . . . . . . . . . . 13 3. State and Flow Diagram . . . . . . . . . . . . . . . . . . . 13
3.1. Not Authenticated State . . . . . . . . . . . . . . . . . 14 3.1. Not Authenticated State . . . . . . . . . . . . . . . . . 13
3.2. Authenticated State . . . . . . . . . . . . . . . . . . . 14 3.2. Authenticated State . . . . . . . . . . . . . . . . . . . 13
3.3. Selected State . . . . . . . . . . . . . . . . . . . . . 14 3.3. Selected State . . . . . . . . . . . . . . . . . . . . . 14
3.4. Logout State . . . . . . . . . . . . . . . . . . . . . . 14 3.4. Logout State . . . . . . . . . . . . . . . . . . . . . . 14
4. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 16 4. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Atom . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1. Atom . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.1. Sequence set and UID set . . . . . . . . . . . . . . 16 4.1.1. Sequence set and UID set . . . . . . . . . . . . . . 16
4.2. Number . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2. Number . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3. String . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.3. String . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3.1. 8-bit and Binary Strings . . . . . . . . . . . . . . 17 4.3.1. 8-bit and Binary Strings . . . . . . . . . . . . . . 17
4.4. Parenthesized List . . . . . . . . . . . . . . . . . . . 18 4.4. Parenthesized List . . . . . . . . . . . . . . . . . . . 18
4.5. NIL . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.5. NIL . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
skipping to change at page 3, line 36 skipping to change at page 3, line 36
6.1.2. NOOP Command . . . . . . . . . . . . . . . . . . . . 25 6.1.2. NOOP Command . . . . . . . . . . . . . . . . . . . . 25
6.1.3. LOGOUT Command . . . . . . . . . . . . . . . . . . . 25 6.1.3. LOGOUT Command . . . . . . . . . . . . . . . . . . . 25
6.2. Client Commands - Not Authenticated State . . . . . . . . 26 6.2. Client Commands - Not Authenticated State . . . . . . . . 26
6.2.1. STARTTLS Command . . . . . . . . . . . . . . . . . . 26 6.2.1. STARTTLS Command . . . . . . . . . . . . . . . . . . 26
6.2.2. AUTHENTICATE Command . . . . . . . . . . . . . . . . 27 6.2.2. AUTHENTICATE Command . . . . . . . . . . . . . . . . 27
6.2.3. LOGIN Command . . . . . . . . . . . . . . . . . . . . 30 6.2.3. LOGIN Command . . . . . . . . . . . . . . . . . . . . 30
6.3. Client Commands - Authenticated State . . . . . . . . . . 31 6.3. Client Commands - Authenticated State . . . . . . . . . . 31
6.3.1. ENABLE Command . . . . . . . . . . . . . . . . . . . 31 6.3.1. ENABLE Command . . . . . . . . . . . . . . . . . . . 31
6.3.2. SELECT Command . . . . . . . . . . . . . . . . . . . 33 6.3.2. SELECT Command . . . . . . . . . . . . . . . . . . . 33
6.3.3. EXAMINE Command . . . . . . . . . . . . . . . . . . . 35 6.3.3. EXAMINE Command . . . . . . . . . . . . . . . . . . . 35
6.3.4. CREATE Command . . . . . . . . . . . . . . . . . . . 36 6.3.4. CREATE Command . . . . . . . . . . . . . . . . . . . 35
6.3.5. DELETE Command . . . . . . . . . . . . . . . . . . . 37 6.3.5. DELETE Command . . . . . . . . . . . . . . . . . . . 36
6.3.6. RENAME Command . . . . . . . . . . . . . . . . . . . 38 6.3.6. RENAME Command . . . . . . . . . . . . . . . . . . . 38
6.3.7. SUBSCRIBE Command . . . . . . . . . . . . . . . . . . 40 6.3.7. SUBSCRIBE Command . . . . . . . . . . . . . . . . . . 40
6.3.8. UNSUBSCRIBE Command . . . . . . . . . . . . . . . . . 41 6.3.8. UNSUBSCRIBE Command . . . . . . . . . . . . . . . . . 41
6.3.9. LIST Command . . . . . . . . . . . . . . . . . . . . 41 6.3.9. LIST Command . . . . . . . . . . . . . . . . . . . . 41
6.3.10. LSUB Command . . . . . . . . . . . . . . . . . . . . 44 6.3.10. LSUB Command . . . . . . . . . . . . . . . . . . . . 44
6.3.11. NAMESPACE Command . . . . . . . . . . . . . . . . . . 45 6.3.11. NAMESPACE Command . . . . . . . . . . . . . . . . . . 45
6.3.12. STATUS Command . . . . . . . . . . . . . . . . . . . 49 6.3.12. STATUS Command . . . . . . . . . . . . . . . . . . . 49
6.3.13. APPEND Command . . . . . . . . . . . . . . . . . . . 51 6.3.13. APPEND Command . . . . . . . . . . . . . . . . . . . 51
6.3.14. IDLE Command . . . . . . . . . . . . . . . . . . . . 54 6.3.14. IDLE Command . . . . . . . . . . . . . . . . . . . . 53
6.4. Client Commands - Selected State . . . . . . . . . . . . 55 6.4. Client Commands - Selected State . . . . . . . . . . . . 55
6.4.1. CHECK Command . . . . . . . . . . . . . . . . . . . . 56 6.4.1. CHECK Command . . . . . . . . . . . . . . . . . . . . 56
6.4.2. CLOSE Command . . . . . . . . . . . . . . . . . . . . 56 6.4.2. CLOSE Command . . . . . . . . . . . . . . . . . . . . 56
6.4.3. UNSELECT Command . . . . . . . . . . . . . . . . . . 57 6.4.3. UNSELECT Command . . . . . . . . . . . . . . . . . . 57
6.4.4. EXPUNGE Command . . . . . . . . . . . . . . . . . . . 57 6.4.4. EXPUNGE Command . . . . . . . . . . . . . . . . . . . 57
6.4.5. SEARCH Command . . . . . . . . . . . . . . . . . . . 58 6.4.5. SEARCH Command . . . . . . . . . . . . . . . . . . . 58
6.4.6. FETCH Command . . . . . . . . . . . . . . . . . . . . 63 6.4.6. FETCH Command . . . . . . . . . . . . . . . . . . . . 63
6.4.7. STORE Command . . . . . . . . . . . . . . . . . . . . 67 6.4.7. STORE Command . . . . . . . . . . . . . . . . . . . . 66
6.4.8. COPY Command . . . . . . . . . . . . . . . . . . . . 68 6.4.8. COPY Command . . . . . . . . . . . . . . . . . . . . 68
6.4.9. UID Command . . . . . . . . . . . . . . . . . . . . . 69 6.4.9. MOVE Command . . . . . . . . . . . . . . . . . . . . 69
6.5. Client Commands - Experimental/Expansion . . . . . . . . 71 6.4.10. UID Command . . . . . . . . . . . . . . . . . . . . . 70
6.5.1. X<atom> Command . . . . . . . . . . . . . . . . . . . 71 6.5. Client Commands - Experimental/Expansion . . . . . . . . 72
7. Server Responses . . . . . . . . . . . . . . . . . . . . . . 71 6.5.1. X<atom> Command . . . . . . . . . . . . . . . . . . . 72
7.1. Server Responses - Status Responses . . . . . . . . . . . 72 7. Server Responses . . . . . . . . . . . . . . . . . . . . . . 73
7.1.1. OK Response . . . . . . . . . . . . . . . . . . . . . 79 7.1. Server Responses - Status Responses . . . . . . . . . . . 74
7.1.2. NO Response . . . . . . . . . . . . . . . . . . . . . 80 7.1.1. OK Response . . . . . . . . . . . . . . . . . . . . . 81
7.1.3. BAD Response . . . . . . . . . . . . . . . . . . . . 80 7.1.2. NO Response . . . . . . . . . . . . . . . . . . . . . 81
7.1.4. PREAUTH Response . . . . . . . . . . . . . . . . . . 81 7.1.3. BAD Response . . . . . . . . . . . . . . . . . . . . 82
7.1.5. BYE Response . . . . . . . . . . . . . . . . . . . . 81 7.1.4. PREAUTH Response . . . . . . . . . . . . . . . . . . 82
7.2. Server Responses - Server and Mailbox Status . . . . . . 82 7.1.5. BYE Response . . . . . . . . . . . . . . . . . . . . 83
7.2.1. The ENABLED Response . . . . . . . . . . . . . . . . 82 7.2. Server Responses - Server and Mailbox Status . . . . . . 83
7.2.2. CAPABILITY Response . . . . . . . . . . . . . . . . . 82 7.2.1. The ENABLED Response . . . . . . . . . . . . . . . . 83
7.2.3. LIST Response . . . . . . . . . . . . . . . . . . . . 83 7.2.2. CAPABILITY Response . . . . . . . . . . . . . . . . . 84
7.2.4. LSUB Response . . . . . . . . . . . . . . . . . . . . 86 7.2.3. LIST Response . . . . . . . . . . . . . . . . . . . . 85
7.2.5. NAMESPACE Response . . . . . . . . . . . . . . . . . 86 7.2.4. LSUB Response . . . . . . . . . . . . . . . . . . . . 87
7.2.6. STATUS Response . . . . . . . . . . . . . . . . . . . 86 7.2.5. NAMESPACE Response . . . . . . . . . . . . . . . . . 88
7.2.7. ESEARCH Response . . . . . . . . . . . . . . . . . . 87 7.2.6. STATUS Response . . . . . . . . . . . . . . . . . . . 88
7.2.8. FLAGS Response . . . . . . . . . . . . . . . . . . . 87 7.2.7. ESEARCH Response . . . . . . . . . . . . . . . . . . 88
7.3. Server Responses - Mailbox Size . . . . . . . . . . . . . 88 7.2.8. FLAGS Response . . . . . . . . . . . . . . . . . . . 89
7.3.1. EXISTS Response . . . . . . . . . . . . . . . . . . . 88 7.3. Server Responses - Mailbox Size . . . . . . . . . . . . . 89
7.3.2. RECENT Response . . . . . . . . . . . . . . . . . . . 88 7.3.1. EXISTS Response . . . . . . . . . . . . . . . . . . . 89
7.4. Server Responses - Message Status . . . . . . . . . . . . 89 7.4. Server Responses - Message Status . . . . . . . . . . . . 90
7.4.1. EXPUNGE Response . . . . . . . . . . . . . . . . . . 89 7.4.1. EXPUNGE Response . . . . . . . . . . . . . . . . . . 90
7.4.2. FETCH Response . . . . . . . . . . . . . . . . . . . 90 7.4.2. FETCH Response . . . . . . . . . . . . . . . . . . . 91
7.5. Server Responses - Command Continuation Request . . . . . 95 7.5. Server Responses - Command Continuation Request . . . . . 96
8. Sample IMAP4rev2 connection . . . . . . . . . . . . . . . . . 95 8. Sample IMAP4rev2 connection . . . . . . . . . . . . . . . . . 96
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 97 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 97
10. Author's Note . . . . . . . . . . . . . . . . . . . . . . . . 111 10. Author's Note . . . . . . . . . . . . . . . . . . . . . . . . 112
11. Security Considerations . . . . . . . . . . . . . . . . . . . 111 11. Security Considerations . . . . . . . . . . . . . . . . . . . 112
11.1. STARTTLS Security Considerations . . . . . . . . . . . . 111 11.1. STARTTLS Security Considerations . . . . . . . . . . . . 112
11.2. COPYUID and APPENDUID response codes . . . . . . . . . . 111 11.2. COPYUID and APPENDUID response codes . . . . . . . . . . 112
11.3. Other Security Considerations . . . . . . . . . . . . . 112 11.3. Other Security Considerations . . . . . . . . . . . . . 113
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 112 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 113
12.1. Updates to IMAP4 Capabilities registry . . . . . . . . . 113 12.1. Updates to IMAP4 Capabilities registry . . . . . . . . . 114
12.2. GSSAPI/SASL service name . . . . . . . . . . . . . . . . 113 12.2. GSSAPI/SASL service name . . . . . . . . . . . . . . . . 114
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 113 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 114
13.1. Normative References . . . . . . . . . . . . . . . . . . 113 13.1. Normative References . . . . . . . . . . . . . . . . . . 114
13.2. Informative References (related protocols) . . . . . . . 116 13.2. Informative References (related protocols) . . . . . . . 117
13.3. Informative References (historical aspects of IMAP and 13.3. Informative References (historical aspects of IMAP and
related protocols) . . . . . . . . . . . . . . . . . . . 117 related protocols) . . . . . . . . . . . . . . . . . . . 118
Appendix A. Backward compatibility with IMAP4rev1 . . . . . . . 118 Appendix A. Backward compatibility with IMAP4rev1 . . . . . . . 119
A.1. Mailbox International Naming Convention . . . . . . . . . 118 A.1. Mailbox International Naming Convention . . . . . . . . . 119
Appendix B. Changes from RFC 3501 / IMAP4rev1 . . . . . . . . . 120 Appendix B. Changes from RFC 3501 / IMAP4rev1 . . . . . . . . . 121
Appendix C. Acknowledgement . . . . . . . . . . . . . . . . . . 121 Appendix C. Acknowledgement . . . . . . . . . . . . . . . . . . 122
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 128
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 11, line 42 skipping to change at page 11, line 42
2.3.2. Flags Message Attribute 2.3.2. Flags Message Attribute
A list of zero or more named tokens associated with the message. A A list of zero or more named tokens associated with the message. A
flag is set by its addition to this list, and is cleared by its flag is set by its addition to this list, and is cleared by its
removal. There are two types of flags in IMAP4rev2. A flag of removal. There are two types of flags in IMAP4rev2. A flag of
either type can be permanent or session-only. either type can be permanent or session-only.
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. The currently- \Seen) have special semantics described elsewhere in this document.
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 Message is "recently" arrived in this mailbox. This session \Recent This flag was in used in IMAP4rev1 and is now deprecated.
is the first session to have been notified about this message; if
the session is read-write, subsequent sessions will not see
\Recent set for this message. This flag can not be altered by the
client.
If it is not possible to determine whether or not this session is
the first session to be notified about a message, then that
message SHOULD be considered recent.
If multiple connections have the same mailbox selected
simultaneously, it is undefined which of these connections will
see newly-arrived messages with \Recent set and which will see it
without \Recent set.
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 and SEARCH commands) by server implementations: APPEND, COPY, MOVE and SEARCH 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 was generated and sent for $MDNSent Message Disposition Notification was generated and sent for
this message. this message.
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.
Note: The \Recent system flag is a special case of a session flag.
\Recent can not be used as an argument in a STORE or APPEND
command, and thus can not be changed at all.
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
the date and time in the [RFC-5322] header, but rather a date and the date and time in the [RFC-5322] header, but rather a date and
time which reflects when the message was received. In the case of time which reflects when the message was received. In the case of
messages delivered via [SMTP], this SHOULD be the date and time of messages delivered via [SMTP], this SHOULD be the date and time of
final delivery of the message as defined by [SMTP]. In the case of final delivery of the message as defined by [SMTP]. In the case of
messages delivered by the IMAP4rev2 COPY command, this SHOULD be the messages delivered by the IMAP4rev2 COPY or MOVE command, this SHOULD
internal date and time of the source message. In the case of be the internal date and time of the source message. In the case of
messages delivered by the IMAP4rev2 APPEND command, this SHOULD be messages delivered by the IMAP4rev2 APPEND command, this SHOULD be
the date and time as specified in the APPEND command description. the date and time as specified in the APPEND command description.
All other cases are implementation defined. All other cases are implementation defined.
2.3.4. [RFC-5322] Size Message Attribute 2.3.4. [RFC-5322] Size Message Attribute
The number of octets in the message, as expressed in [RFC-5322] The number of octets in the message, as expressed in [RFC-5322]
format. format.
2.3.5. Envelope Structure Message Attribute 2.3.5. Envelope Structure Message Attribute
skipping to change at page 17, line 19 skipping to change at page 17, line 19
instead of the synchonizing form of literal. The non-synchronizing instead of the synchonizing form of literal. The non-synchronizing
literal form MUST NOT be sent from server to client. The non- literal form MUST NOT be sent from server to client. The non-
synchronizing literal is distinguished from the synchronizing literal synchronizing literal is distinguished from the synchronizing literal
by having a plus ("+") between the octet count and the closing brace by having a plus ("+") between the octet count and the closing brace
("}"). The server does not generate a command continuation request ("}"). The server does not generate a command continuation request
in response to a non-synchronizing literal, and clients are not in response to a non-synchronizing literal, and clients are not
required to wait before sending the octets of a non- synchronizing required to wait before sending the octets of a non- synchronizing
literal. Non-synchronizing literals MUST NOT be larger than 4096 literal. Non-synchronizing literals MUST NOT be larger than 4096
octets. Any literal larger than 4096 bytes MUST be sent as a octets. Any literal larger than 4096 bytes MUST be sent as a
synchronizing literal. (Non-synchronizing literals defined in this synchronizing literal. (Non-synchronizing literals defined in this
document are the same as non-synchronizing literals defined by document are the same as non-synchronizing literals defined by the
LITERAL- extension from [RFC7888]. See that document for details on LITERAL- extension from [RFC7888]. See that document for details on
how to handle invalid non-synchronizing literals longer than 4096 how to handle invalid non-synchronizing literals longer than 4096
octets and for interaction with other IMAP extensions.) octets and for interaction with other IMAP extensions.)
A quoted string is a sequence of zero or more Unicode characters, A quoted string is a sequence of zero or more Unicode characters,
excluding CR and LF, encoded in UTF-8, with double quote (<">) excluding CR and LF, encoded in UTF-8, with double quote (<">)
characters at each end. characters at each end.
The empty string is represented as "" (a quoted string with zero The empty string is represented as "" (a quoted string with zero
characters between double quotes), as {0} followed by CRLF (a characters between double quotes), as {0} followed by CRLF (a
skipping to change at page 25, line 28 skipping to change at page 25, line 28
message status updates during a period of inactivity (this is the message status updates during a period of inactivity (this is the
preferred method to do this). The NOOP command can also be used to preferred method to do this). The NOOP command can also be used to
reset any inactivity autologout timer on the server. reset any inactivity autologout timer on the server.
Example: C: a002 NOOP Example: C: a002 NOOP
S: a002 OK NOOP completed S: a002 OK NOOP completed
. . . . . .
C: a047 NOOP C: a047 NOOP
S: * 22 EXPUNGE S: * 22 EXPUNGE
S: * 23 EXISTS S: * 23 EXISTS
S: * 3 RECENT
S: * 14 FETCH (FLAGS (\Seen \Deleted)) S: * 14 FETCH (FLAGS (\Seen \Deleted))
S: a047 OK NOOP completed S: a047 OK NOOP completed
6.1.3. LOGOUT Command 6.1.3. LOGOUT Command
Arguments: none Arguments: none
Responses: REQUIRED untagged response: BYE Responses: REQUIRED untagged response: BYE
Result: OK - logout completed Result: OK - logout completed
skipping to change at page 28, line 14 skipping to change at page 28, line 14
not specified by the client, the server handles this as specified in not specified by the client, the server handles this as specified in
Section 3 of [SASL]. Section 3 of [SASL].
The service name specified by this protocol's profile of [SASL] is The service name specified by this protocol's profile of [SASL] is
"imap". "imap".
The authentication protocol exchange consists of a series of server The authentication protocol exchange consists of a series of server
challenges and client responses that are specific to the challenges and client responses that are specific to the
authentication mechanism. A server challenge consists of a command authentication mechanism. A server challenge consists of a command
continuation request response with the "+" token followed by a BASE64 continuation request response with the "+" token followed by a BASE64
encoded string. The client response consists of a single line encoded (see Section 4 of [RFC4648]) string. The client response
consisting of a BASE64 encoded string. If the client wishes to consists of a single line consisting of a BASE64 encoded string. If
cancel an authentication exchange, it issues a line consisting of a the client wishes to cancel an authentication exchange, it issues a
single "*". If the server receives such a response, or if it line consisting of a single "*". If the server receives such a
receives an invalid BASE64 string (e.g. characters outside the response, or if it receives an invalid BASE64 string (e.g.
BASE64 alphabet, or non-terminal "="), it MUST reject the characters outside the BASE64 alphabet, or non-terminal "="), it MUST
AUTHENTICATE command by sending a tagged BAD response. reject the AUTHENTICATE command by sending a tagged BAD response.
As with any other client response, this initial response MUST be As with any other client response, this initial response MUST be
encoded as BASE64 (see Section 4 of [RFC4648]). It also MUST be encoded as BASE64. It also MUST be transmitted outside of a quoted
transmitted outside of a quoted string or literal. To send a zero- string or literal. To send a zero-length initial response, the
length initial response, the client MUST send a single pad character client MUST send a single pad character ("="). This indicates that
("="). This indicates that the response is present, but is a zero- the response is present, but is a zero-length string.
length string.
When decoding the BASE64 data in the initial response, decoding When decoding the BASE64 data in the initial response, decoding
errors MUST be treated as in any normal SASL client response, i.e. errors MUST be treated as in any normal SASL client response, i.e.
with a tagged BAD response. In particular, the server should check with a tagged BAD response. In particular, the server should check
for any characters not explicitly allowed by the BASE64 alphabet, as for any characters not explicitly allowed by the BASE64 alphabet, as
well as any sequence of BASE64 characters that contains the pad well as any sequence of BASE64 characters that contains the pad
character ('=') anywhere other than the end of the string (e.g., character ('=') anywhere other than the end of the string (e.g.,
"=AAA" and "AAA=BBB" are not allowed). "=AAA" and "AAA=BBB" are not allowed).
If the client uses an initial response with a SASL mechanism that If the client uses an initial response with a SASL mechanism that
skipping to change at page 33, line 36 skipping to change at page 33, line 36
Designers of IMAP extensions are discouraged from creating extensions Designers of IMAP extensions are discouraged from creating extensions
that require ENABLE unless there is no good alternative design. that require ENABLE unless there is no good alternative design.
Specifically, extensions that cause potentially incompatible behavior Specifically, extensions that cause potentially incompatible behavior
changes to deployed server responses (and thus benefit from ENABLE) changes to deployed server responses (and thus benefit from ENABLE)
have a higher complexity cost than extensions that do not. have a higher complexity cost than extensions that do not.
6.3.2. SELECT Command 6.3.2. SELECT Command
Arguments: mailbox name Arguments: mailbox name
Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT Responses: REQUIRED untagged responses: FLAGS, EXISTS
REQUIRED OK untagged responses: UNSEEN (if any unseen REQUIRED OK untagged responses: PERMANENTFLAGS,
exist), PERMANENTFLAGS,
UIDNEXT, UIDVALIDITY UIDNEXT, UIDVALIDITY
Result: OK - select completed, now in selected state Result: OK - select completed, now in selected state
NO - select failure, now in authenticated state: no NO - select failure, now in authenticated state: no
such mailbox, can't access mailbox such mailbox, can't access mailbox
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
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. Note that MUST send the following untagged data to the client. Note that
earlier versions of this protocol only required the FLAGS, EXISTS, earlier versions of this protocol only required the FLAGS and EXISTS
and RECENT untagged data; consequently, client implementations SHOULD untagged data; consequently, client implementations SHOULD implement
implement default behavior for missing data as discussed with the default behavior for missing data as discussed with the individual
individual item. item.
FLAGS Defined flags in the mailbox. See the description of the FLAGS Defined flags in the mailbox. See the description of the
FLAGS response for more detail. FLAGS response for more detail.
<n> EXISTS The number of messages in the mailbox. See the <n> EXISTS The number of messages in the mailbox. See the
description of the EXISTS response for more detail. description of the EXISTS response for more detail.
<n> RECENT The number of messages with the \Recent flag set. See
the description of the RECENT response for more detail.
OK [UNSEEN <n>] The message sequence number of the first unseen
message in the mailbox. If there are any unseen messages in the
mailbox, an UNSEEN response MUST be sent, if not it MUST be
omitted. If this is missing, the client can not make any
assumptions about the first unseen message in the mailbox, and
needs to issue a SEARCH command if it wants to find it.
OK [PERMANENTFLAGS (<list of flags>)] A list of message flags that OK [PERMANENTFLAGS (<list of flags>)] A list of message flags that
the client can change permanently. If this is missing, the client the client can change permanently. If this is missing, the client
should assume that all flags can be changed permanently. should assume that all flags can be changed permanently.
OK [UIDNEXT <n>] The next unique identifier value. Refer to OK [UIDNEXT <n>] The next unique identifier value. Refer to
Section 2.3.1.1 for more information. If this is missing, the Section 2.3.1.1 for more information. If this is missing, the
client can not make any assumptions about the next unique client can not make any assumptions about the next unique
identifier value. identifier value.
OK [UIDVALIDITY <n>] The unique identifier validity value. Refer to OK [UIDVALIDITY <n>] The unique identifier validity value. Refer to
skipping to change at page 34, line 44 skipping to change at page 34, line 32
server does not support unique identifiers. server does not support unique identifiers.
Only one mailbox can be selected at a time in a connection; Only one mailbox can be selected at a time in a connection;
simultaneous access to multiple mailboxes requires multiple simultaneous access to multiple mailboxes requires multiple
connections. The SELECT command automatically deselects any connections. The SELECT command automatically deselects any
currently selected mailbox before attempting the new selection. currently selected mailbox before attempting the new selection.
Consequently, if a mailbox is selected and a SELECT command that Consequently, if a mailbox is selected and a SELECT command that
fails is attempted, no mailbox is selected. When deselecting a fails is attempted, no mailbox is selected. When deselecting a
selected mailbox, the server MUST return an untagged OK response with selected mailbox, the server MUST return an untagged OK response with
the "[CLOSED]" response code when the currently selected mailbox is the "[CLOSED]" response code when the currently selected mailbox is
closed. closed (see Paragraph 10).
If the client is permitted to modify the mailbox, the server SHOULD If the client is permitted to modify the mailbox, the server SHOULD
prefix the text of the tagged OK response with the "[READ-WRITE]" prefix the text of the tagged OK response with the "[READ-WRITE]"
response code. response code.
If the client is not permitted to modify the mailbox but is permitted If the client is not permitted to modify the mailbox but is permitted
read access, the mailbox is selected as read-only, and the server read access, the mailbox is selected as read-only, and the server
MUST prefix the text of the tagged OK response to SELECT with the MUST prefix the text of the tagged OK response to SELECT with the
"[READ-ONLY]" response code. Read-only access through SELECT differs "[READ-ONLY]" response code. Read-only access through SELECT differs
from the EXAMINE command in that certain read-only mailboxes MAY from the EXAMINE command in that certain read-only mailboxes MAY
permit the change of permanent state on a per-user (as opposed to permit the change of permanent state on a per-user (as opposed to
global) basis. Netnews messages marked in a server-based .newsrc global) basis. Netnews messages marked in a server-based .newsrc
file are an example of such per-user permanent state that can be file are an example of such per-user permanent state that can be
modified with read-only mailboxes. modified with read-only mailboxes.
Example: C: A142 SELECT INBOX Example: C: A142 SELECT INBOX
S: * 172 EXISTS S: * 172 EXISTS
S: * 1 RECENT
S: * OK [UNSEEN 12] Message 12 is first unseen
S: * OK [UIDVALIDITY 3857529045] UIDs valid S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * OK [UIDNEXT 4392] Predicted next UID S: * OK [UIDNEXT 4392] Predicted next UID
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
S: A142 OK [READ-WRITE] SELECT completed S: A142 OK [READ-WRITE] SELECT completed
6.3.3. EXAMINE Command 6.3.3. EXAMINE Command
Arguments: mailbox name Arguments: mailbox name
Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT Responses: REQUIRED untagged responses: FLAGS, EXISTS
REQUIRED OK untagged responses: UNSEEN, PERMANENTFLAGS, REQUIRED OK untagged responses: PERMANENTFLAGS,
UIDNEXT, UIDVALIDITY UIDNEXT, UIDVALIDITY
Result: OK - examine completed, now in selected state Result: OK - examine completed, now in selected state
NO - examine failure, now in authenticated state: no NO - examine failure, now in authenticated state: no
such mailbox, can't access mailbox BAD - command unknown such mailbox, can't access mailbox BAD - command unknown
or arguments invalid or arguments invalid
The EXAMINE command is identical to SELECT and returns the same The EXAMINE command is identical to SELECT and returns the same
output; however, the selected mailbox is identified as read-only. No output; however, the selected mailbox is identified as read-only. No
changes to the permanent state of the mailbox, including per-user changes to the permanent state of the mailbox, including per-user
state, are permitted; in particular, EXAMINE MUST NOT cause messages state, are permitted.
to lose the \Recent flag.
The text of the tagged OK response to the EXAMINE command MUST begin The text of the tagged OK response to the EXAMINE command MUST begin
with the "[READ-ONLY]" response code. with the "[READ-ONLY]" response code.
Example: C: A932 EXAMINE blurdybloop Example: C: A932 EXAMINE blurdybloop
S: * 17 EXISTS S: * 17 EXISTS
S: * 2 RECENT
S: * OK [UNSEEN 8] Message 8 is first unseen
S: * OK [UIDVALIDITY 3857529045] UIDs valid S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * OK [UIDNEXT 4392] Predicted next UID S: * OK [UIDNEXT 4392] Predicted next UID
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS ()] No permanent flags permitted S: * OK [PERMANENTFLAGS ()] No permanent flags permitted
S: A932 OK [READ-ONLY] EXAMINE completed S: A932 OK [READ-ONLY] EXAMINE completed
6.3.4. CREATE Command 6.3.4. CREATE Command
Arguments: mailbox name Arguments: mailbox name
skipping to change at page 50, line 9 skipping to change at page 50, line 9
status data item names status data item names
Responses: REQUIRED untagged responses: STATUS Responses: REQUIRED untagged responses: STATUS
Result: OK - status completed Result: OK - status completed
NO - status failure: no status for that name NO - status failure: no status for that name
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
The STATUS command requests the status of the indicated mailbox. It The STATUS command requests the status of the indicated mailbox. It
does not change the currently selected mailbox, nor does it affect does not change the currently selected mailbox, nor does it affect
the state of any messages in the queried mailbox (in particular, the state of any messages in the queried mailbox.
STATUS MUST NOT cause messages to lose the \Recent flag).
The STATUS command provides an alternative to opening a second The STATUS command provides an alternative to opening a second
IMAP4rev2 connection and doing an EXAMINE command on a mailbox to IMAP4rev2 connection and doing an EXAMINE command on a mailbox to
query that mailbox's status without deselecting the current mailbox query that mailbox's status without deselecting the current mailbox
in the first IMAP4rev2 connection. in the first IMAP4rev2 connection.
Unlike the LIST command, the STATUS command is not guaranteed to be Unlike the LIST command, the STATUS command is not guaranteed to be
fast in its response. Under certain circumstances, it can be quite fast in its response. Under certain circumstances, it can be quite
slow. In some implementations, the server is obliged to open the slow. In some implementations, the server is obliged to open the
mailbox read-only internally to obtain certain status information. mailbox read-only internally to obtain certain status information.
skipping to change at page 50, line 32 skipping to change at page 50, line 31
wildcards. wildcards.
Note: The STATUS command is intended to access the status of Note: The STATUS command is intended to access the status of
mailboxes other than the currently selected mailbox. Because the mailboxes other than the currently selected mailbox. Because the
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. currently selected mailbox.
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 sections 7, in the selected mailbox" operation (refer to sections Section 7,
Section 7.3.1, and Section 7.3.2 for more information about the Section 7.3.1 for more information about the proper method for new
proper method for new message checking). message checking).
Because the STATUS command is not guaranteed to be fast in its Because the STATUS command is not guaranteed to be fast in its
results, clients SHOULD NOT expect to be able to issue many results, clients SHOULD NOT expect to be able to issue many
consecutive STATUS commands and obtain reasonable performance. consecutive STATUS commands and obtain reasonable performance.
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.
RECENT The number of messages with the \Recent flag set.
UIDNEXT The next unique identifier value of the mailbox. Refer to UIDNEXT The next unique identifier value of the mailbox. Refer to
Section 2.3.1.1 for more information. Section 2.3.1.1 for more information.
UIDVALIDITY The unique identifier validity value of the mailbox. UIDVALIDITY The unique identifier validity value of the mailbox.
Refer to Section 2.3.1.1 for more information. Refer to Section 2.3.1.1 for more information.
UNSEEN The number of messages which do not have the \Seen flag set. UNSEEN The number of messages which do not have the \Seen flag set.
SIZE The total size of the mailbox in octets. This is not strictly SIZE The total size of the mailbox in octets. This is not strictly
required to be an exact value, but it MUST be equal to or greater required to be an exact value, but it MUST be equal to or greater
skipping to change at page 51, line 45 skipping to change at page 51, line 43
reversibly convert 8-bit APPEND data to 7-bit using a [MIME-IMB] reversibly convert 8-bit APPEND data to 7-bit using a [MIME-IMB]
content transfer encoding. content transfer encoding.
Note: There may be exceptions, e.g., draft messages, in which Note: There may be exceptions, e.g., draft messages, in which
required [RFC-5322] header lines are omitted in the message required [RFC-5322] header lines are omitted in the message
literal argument to APPEND. The full implications of doing so literal argument to APPEND. The full implications of doing so
must be understood and carefully weighed. must be understood and carefully weighed.
If a flag parenthesized list is specified, the flags SHOULD be set in If a flag parenthesized list is specified, the flags SHOULD be set in
the resulting message; otherwise, the flag list of the resulting the resulting message; otherwise, the flag list of the resulting
message is set to empty by default. In either case, the Recent flag message is set to empty by default.
is also set.
If a date-time is specified, the internal date SHOULD be set in the If a date-time is specified, the internal date SHOULD be set in the
resulting message; otherwise, the internal date of the resulting resulting message; otherwise, the internal date of the resulting
message is set to the current date and time by default. message is set to the current date and time by default.
If the append is unsuccessful for any reason, the mailbox MUST be If the append is unsuccessful for any reason, the mailbox MUST be
restored to its state before the APPEND attempt; no partial appending restored to its state before the APPEND attempt; no partial appending
is permitted. is 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
skipping to change at page 53, line 39 skipping to change at page 53, line 25
C: C:
S: A003 OK [APPENDUID 38505 3955] APPEND completed S: A003 OK [APPENDUID 38505 3955] APPEND completed
C: A004 COPY 2:4 meeting C: A004 COPY 2:4 meeting
S: A004 OK [COPYUID 38505 304,319:320 3956:3958] Done S: A004 OK [COPYUID 38505 304,319:320 3956:3958] Done
C: A005 UID COPY 305:310 meeting C: A005 UID COPY 305:310 meeting
S: A005 OK No matching messages, so nothing copied S: A005 OK No matching messages, so nothing copied
C: A006 COPY 2 funny C: A006 COPY 2 funny
S: A006 OK Done S: A006 OK Done
C: A007 SELECT funny C: A007 SELECT funny
S: * 1 EXISTS S: * 1 EXISTS
S: * 1 RECENT
S: * OK [UNSEEN 1] Message 1 is first unseen
S: * OK [UIDVALIDITY 3857529045] Validity session-only S: * OK [UIDVALIDITY 3857529045] Validity session-only
S: * OK [UIDNEXT 2] Predicted next UID S: * OK [UIDNEXT 2] Predicted next UID
S: * NO [UIDNOTSTICKY] Non-persistent UIDs S: * NO [UIDNOTSTICKY] Non-persistent UIDs
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Deleted \Seen)] Limited S: * OK [PERMANENTFLAGS (\Deleted \Seen)] Limited
S: A007 OK [READ-WRITE] SELECT completed S: A007 OK [READ-WRITE] SELECT completed
In this example, A003 and A004 demonstrate successful appending and In this example, A003 and A004 demonstrate successful appending and
copying to a mailbox that returns the UIDs assigned to the messages. copying to a mailbox that returns the UIDs assigned to the messages.
A005 is an example in which no messages were copied; this is because A005 is an example in which no messages were copied; this is because
skipping to change at page 54, line 37 skipping to change at page 54, line 22
It's often more desirable to have the server transmit updates to the It's often more desirable to have the server transmit updates to the
client in real time. This allows a user to see new mail immediately. client in real time. This allows a user to see new mail immediately.
The IDLE command allows a client to tell the server that it's ready The IDLE command allows a client to tell the server that it's ready
to accept such real-time updates. to accept such real-time updates.
The IDLE command is sent from the client to the server when the The IDLE command is sent from the client to the server when the
client is ready to accept unsolicited mailbox update messages. The client is ready to accept unsolicited mailbox update messages. The
server requests a response to the IDLE command using the continuation server requests a response to the IDLE command using the continuation
("+") response. The IDLE command remains active until the client ("+") response. The IDLE command remains active until the client
responds to the continuation, and as long as an IDLE command is responds to the continuation, and as long as an IDLE command is
active, the server is now free to send untagged EXISTS, EXPUNGE, and active, the server is now free to send untagged EXISTS, EXPUNGE,
other responses at any time. FETCH, and other responses at any time. If the server choose to send
unsolicited FETCH responses, they MUST include UID FETCH item.
The IDLE command is terminated by the receipt of a "DONE" The IDLE command is terminated by the receipt of a "DONE"
continuation from the client; such response satisfies the server's continuation from the client; such response satisfies the server's
continuation request. At that point, the server MAY send any continuation request. At that point, the server MAY send any
remaining queued untagged responses and then MUST immediately send remaining queued untagged responses and then MUST immediately send
the tagged response to the IDLE command and prepare to process other the tagged response to the IDLE command and prepare to process other
commands. As in the base specification, the processing of any new commands. As in the base specification, the processing of any new
command may cause the sending of unsolicited untagged responses, command may cause the sending of unsolicited untagged responses,
subject to the ambiguity limitations. The client MUST NOT send a subject to the ambiguity limitations. The client MUST NOT send a
command while the server is waiting for the DONE, since the server command while the server is waiting for the DONE, since the server
will not be able to distinguish a command from a continuation. will not be able to distinguish a command from a continuation.
The server MAY consider a client inactive if it has an IDLE command The server MAY consider a client inactive if it has an IDLE command
running, and if such a server has an inactivity timeout it MAY log running, and if such a server has an inactivity timeout it MAY log
the client off implicitly at the end of its timeout period. Because the client off implicitly at the end of its timeout period. Because
of that, clients using IDLE are advised to terminate the IDLE and re- of that, clients using IDLE are advised to terminate the IDLE and re-
issue it at least every 29 minutes to avoid being logged off. This issue it at least every 29 minutes to avoid being logged off. This
still allows a client to receive immediate mailbox updates even still allows a client to receive immediate mailbox updates even
though it need only "poll" at half hour intervals. though it need only "poll" at half hour intervals.
Example: C: A001 SELECT INBOX Example: C: A001 SELECT INBOX
S: * FLAGS (Deleted Seen) S: * FLAGS (\Deleted \Seen \Flagged)
S: * 3 EXISTS S: * OK [PERMANENTFLAGS (\Deleted \Seen \Flagged)] Limited
S: * 0 RECENT S: * 3 EXISTS
S: * OK [UIDVALIDITY 1] S: * OK [UIDVALIDITY 1]
S: A001 OK SELECT completed S: A001 OK [READ-WRITE] SELECT completed
C: A002 IDLE C: A002 IDLE
S: + idling S: + idling
...time passes; new mail arrives... ...time passes; new mail arrives...
S: * 4 EXISTS S: * 4 EXISTS
C: DONE C: DONE
S: A002 OK IDLE terminated S: A002 OK IDLE terminated
...another client expunges message 2 now... ...another client expunges message 2 now...
C: A003 FETCH 4 ALL C: A003 FETCH 4 ALL
S: * 4 FETCH (...) S: * 4 FETCH (...)
S: A003 OK FETCH completed S: A003 OK FETCH completed
C: A004 IDLE C: A004 IDLE
S: * 2 EXPUNGE S: * 2 EXPUNGE
S: * 3 EXISTS S: * 3 EXISTS
S: + idling S: + idling
...time passes; another client expunges message 3... ...time passes; another client expunges message 3...
S: * 3 EXPUNGE S: * 3 EXPUNGE
S: * 2 EXISTS S: * 2 EXISTS
...time passes; new mail arrives... ...time passes; new mail arrives...
S: * 3 EXISTS S: * 3 EXISTS
C: DONE C: DONE
S: A004 OK IDLE terminated S: A004 OK IDLE terminated
C: A005 FETCH 3 ALL C: A005 FETCH 3 ALL
S: * 3 FETCH (...) S: * 3 FETCH (...)
S: A005 OK FETCH completed S: A005 OK FETCH completed
C: A006 IDLE C: A006 IDLE
6.4. Client Commands - Selected State 6.4. Client Commands - Selected State
In the selected state, commands that manipulate messages in a mailbox In the selected state, commands that manipulate messages in a mailbox
are permitted. are permitted.
In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
and the authenticated state commands (SELECT, EXAMINE, NAMESPACE, and the authenticated state commands (SELECT, EXAMINE, NAMESPACE,
CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB , STATUS, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB , STATUS,
and APPEND), the following commands are valid in the selected state: and APPEND), the following commands are valid in the selected state:
CHECK, CLOSE, UNSELECT, EXPUNGE, SEARCH, FETCH, STORE, COPY, and UID. CHECK, CLOSE, UNSELECT, EXPUNGE, SEARCH, FETCH, STORE, COPY, MOVE,
and UID.
6.4.1. CHECK Command 6.4.1. CHECK Command
Arguments: none Arguments: none
Responses: no specific responses for this command Responses: no specific responses for this command
Result: OK - check completed Result: OK - check completed
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
skipping to change at page 57, line 45 skipping to change at page 57, line 42
Responses: untagged responses: EXPUNGE Responses: untagged responses: EXPUNGE
Result: OK - expunge completed Result: OK - expunge completed
NO - expunge failure: can't expunge (e.g., permission NO - expunge failure: can't expunge (e.g., permission
denied) denied)
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
The EXPUNGE command permanently removes all messages that have the The EXPUNGE command permanently removes all messages that have the
\Deleted flag set from the currently selected mailbox. Before \Deleted flag set from the currently selected mailbox. Before
returning an OK to the client, an untagged EXPUNGE response is sent returning an OK to the client, an untagged EXPUNGE response is sent
for each message that is removed. Note that if any messages with the for each message that is removed.
\Recent flag set are expunged, an untagged RECENT response is sent
after the untagged EXPUNGE(s) to update the client's count of RECENT
messages.
Example: C: A202 EXPUNGE Example: C: A202 EXPUNGE
S: * 3 EXPUNGE S: * 3 EXPUNGE
S: * 3 EXPUNGE S: * 3 EXPUNGE
S: * 5 EXPUNGE S: * 5 EXPUNGE
S: * 8 EXPUNGE S: * 8 EXPUNGE
S: A202 OK EXPUNGE completed S: A202 OK EXPUNGE completed
Note: In this example, messages 3, 4, 7, and 11 had the \Deleted flag Note: In this example, messages 3, 4, 7, and 11 had the \Deleted flag
set. See the description of the EXPUNGE response for further set. See the description of the EXPUNGE response for further
skipping to change at page 61, line 20 skipping to change at page 61, line 12
the specified string in the text of the header (what comes after the specified string in the text of the header (what comes after
the colon). If the string to search is zero-length, this matches the colon). If the string to search is zero-length, this matches
all messages that have a header line with the specified field-name all messages that have a header line with the specified field-name
regardless of the contents. regardless of the contents.
KEYWORD <flag> Messages with the specified keyword flag set. KEYWORD <flag> Messages with the specified keyword flag set.
LARGER <n> Messages with an [RFC-5322] size larger than the LARGER <n> Messages with an [RFC-5322] size larger than the
specified number of octets. specified number of octets.
NEW Messages that have the \Recent flag set but not the \Seen flag. NEW [[Fix this]] Messages that have the \Recent flag set but not the
This is functionally equivalent to "(RECENT UNSEEN)". \Seen flag. This is functionally equivalent to "(RECENT UNSEEN)".
NOT <search-key> Messages that do not match the specified search NOT <search-key> Messages that do not match the specified search
key. key.
OLD Messages that do not have the \Recent flag set. This is
functionally equivalent to "NOT RECENT" (as opposed to "NOT NEW").
ON <date> Messages whose internal date (disregarding time and ON <date> Messages whose internal date (disregarding time and
timezone) is within the specified date. timezone) is within the specified date.
OR <search-key1> <search-key2> Messages that match either search OR <search-key1> <search-key2> Messages that match either search
key. key.
RECENT Messages that have the \Recent flag set.
SEEN Messages that have the \Seen flag set. SEEN Messages that have the \Seen flag set.
SENTBEFORE <date> Messages whose [RFC-5322] Date: header SENTBEFORE <date> Messages whose [RFC-5322] Date: header
(disregarding time and timezone) is earlier than the specified (disregarding time and timezone) is earlier than the specified
date. date.
SENTON <date> Messages whose [RFC-5322] Date: header (disregarding SENTON <date> Messages whose [RFC-5322] Date: header (disregarding
time and timezone) is within the specified date. time and timezone) is within the specified date.
SENTSINCE <date> Messages whose [RFC-5322] Date: header SENTSINCE <date> Messages whose [RFC-5322] Date: header
skipping to change at page 63, line 11 skipping to change at page 62, line 47
C: XXXXXX C: XXXXXX
S: * ESEARCH (TAG "A285") ALL 43 S: * ESEARCH (TAG "A285") ALL 43
S: A285 OK SEARCH completed S: A285 OK SEARCH completed
Note: Since this document is restricted to 7-bit ASCII text, it is Note: Since this document is restricted to 7-bit ASCII text, it is
not possible to show actual UTF-8 data. The "XXXXXX" is a not possible to show actual UTF-8 data. The "XXXXXX" is a
placeholder for what would be 6 octets of 8-bit data in an actual placeholder for what would be 6 octets of 8-bit data in an actual
transaction. transaction.
The following example demonstrates finding the first unseen message The following example demonstrates finding the first unseen message
as returned in the UNSEEN response code on a successful SELECT in the mailbox:
command:
Example: C: A284 SEARCH RETURN (MIN) UNSEEN Example: C: A284 SEARCH RETURN (MIN) UNSEEN
S: * ESEARCH (TAG "A284") MIN 4 S: * ESEARCH (TAG "A284") MIN 4
S: A284 OK SEARCH completed S: A284 OK SEARCH completed
The following example demonstrates that if the ESEARCH UID indicator The following example demonstrates that if the ESEARCH UID indicator
is present, all data in the ESEARCH response is referring to UIDs; is present, all data in the ESEARCH response is referring to UIDs;
for example, the MIN result specifier will be followed by a UID. for example, the MIN result specifier will be followed by a UID.
Example: C: A285 UID SEARCH RETURN (MIN MAX) 1:5000 Example: C: A285 UID SEARCH RETURN (MIN MAX) 1:5000
skipping to change at page 67, line 40 skipping to change at page 67, line 26
care about the updated value. care about the updated value.
Note: Regardless of whether or not the ".SILENT" suffix was used, Note: Regardless of whether or not the ".SILENT" suffix was used,
the server SHOULD send an untagged FETCH response if a change to a the server SHOULD send an untagged FETCH response if a change to a
message's flags from an external source is observed. The intent message's flags from an external source is observed. The intent
is that the status of the flags is determinate without a race is that the status of the flags is determinate without a race
condition. condition.
The currently defined data items that can be stored are: The currently defined data items that can be stored are:
FLAGS <flag list> Replace the flags for the message (other than FLAGS <flag list> Replace the flags for the message with the
\Recent) with the argument. The new value of the flags is argument. The new value of the flags is returned as if a FETCH of
returned as if a FETCH of those flags was done. those flags was done.
FLAGS.SILENT <flag list> Equivalent to FLAGS, but without returning FLAGS.SILENT <flag list> Equivalent to FLAGS, but without returning
a new value. a new value.
+FLAGS <flag list> Add the argument to the flags for the message. +FLAGS <flag list> Add the argument to the flags for the message.
The new value of the flags is returned as if a FETCH of those The new value of the flags is returned as if a FETCH of those
flags was done. flags was done.
+FLAGS.SILENT <flag list> Equivalent to +FLAGS, but without +FLAGS.SILENT <flag list> Equivalent to +FLAGS, but without
returning a new value. returning a new value.
skipping to change at page 68, line 32 skipping to change at page 68, line 19
Responses: no specific responses for this command Responses: no specific responses for this command
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, and the Recent flag SHOULD be set, in message(s) SHOULD be preserved in the copy.
the copy.
If the destination mailbox does not exist, a server SHOULD return an If the destination mailbox does not exist, a server SHOULD return an
error. It SHOULD NOT automatically create the mailbox. Unless it is error. It SHOULD 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
skipping to change at page 69, line 20 skipping to change at page 69, line 5
If the server does not return the COPYUID response code, the client If the server does not return the COPYUID response code, the client
can discover this information by selecting the destination mailbox. can discover this information by selecting the destination mailbox.
The location of messages placed in the destination mailbox by COPY The location of messages placed in the destination mailbox by COPY
can be determined by using FETCH and/or SEARCH commands (e.g., for can be determined by using FETCH and/or SEARCH commands (e.g., for
Message-ID). Message-ID).
Example: C: A003 COPY 2:4 MEETING Example: C: A003 COPY 2:4 MEETING
S: A003 OK COPY completed S: A003 OK COPY completed
6.4.9. UID Command 6.4.9. MOVE Command
Arguments: sequence set
mailbox name
Responses: no specific responses for this command
Result: OK - move completed
NO - move error: can't move those messages or to that
name
BAD - command unknown or arguments invalid
The MOVE command moves the specified message(s) to the end of the
specified destination mailbox. The flags and internal date of the
message(s) SHOULD be preserved.
This means that a new message is created in the target mailbox with a
new UID, the original message is removed from the source mailbox, and
it appears to the client as a single action. This has the same
effect for each message as this sequence:
1. [UID] COPY
2. [UID] STORE +FLAGS.SILENT \DELETED
3. UID EXPUNGE
Although the effect of the MOVE is the same as the preceding steps,
the semantics are not identical: The intermediate states produced by
those steps do not occur, and the response codes are different. In
particular, though the COPY and EXPUNGE response codes will be
returned, response codes for a STORE MUST NOT be generated and the
\Deleted flag MUST NOT be set for any message.
Because a MOVE applies to a set of messages, it might fail partway
through the set. Regardless of whether the command is successful in
moving the entire set, each individual message SHOULD either be moved
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
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
bunch of duplicate messages). This is true even if the server
returns a tagged NO response to the command.
Because of the similarity of MOVE to COPY, extensions that affect
COPY affect MOVE in the same way. Response codes such as TRYCREATE
(see Section 7.1), as well as those defined by extensions, are sent
as appropriate.
Servers SHOULD send COPYUID in response to a UID MOVE (see
Section 6.4.10) command. For additional information see Section 7.1.
Servers are also advised to send the COPYUID response code in an
untagged OK before sending EXPUNGE or moved responses. (Sending
COPYUID in the tagged OK, as described in the UIDPLUS specification,
means that clients first receive an EXPUNGE for a message and
afterwards COPYUID for the same message. It can be unnecessarily
difficult to process that sequence usefully.)
An example:
C: a UID MOVE 42:69 foo
S: * OK [COPYUID 432432 42:69 1202:1229]
S: * 22 EXPUNGE
S: (more expunges)
S: a OK Done
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
IMAP operation.
Note that moving a message to the currently selected mailbox (that
is, where the source and target mailboxes are the same) is allowed
when copying the message to the currently selected mailbox is
allowed.
The server may send EXPUNGE responses before the tagged response, so
the client cannot safely send more commands with message sequence
number arguments while the server is processing MOVE.
MOVE and UID MOVE can be pipelined with other commands, but care has
to be taken. Both commands modify sequence numbers and also allow
unrelated EXPUNGE responses. The renumbering of other messages in
the source mailbox following any EXPUNGE response can be surprising
and makes it unsafe to pipeline any command that relies on message
sequence numbers after a MOVE or UID MOVE. Similarly, MOVE cannot be
pipelined with a command that might cause message renumbering. See
Section 5.5, for more information about ambiguities as well as
handling requirements for both clients and servers.
6.4.10. UID Command
Arguments: command name Arguments: command name
command arguments command arguments
Responses: untagged responses: FETCH, SEARCH Responses: untagged responses: FETCH, ESEARCH
Result: OK - UID command completed Result: OK - UID command completed
NO - UID command error NO - UID command error
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
The UID command has three forms. In the first form, it takes as its The UID command has three forms. In the first form, it takes as its
arguments a COPY, FETCH, or STORE command with arguments appropriate arguments a COPY, MOVE, FETCH, or STORE command with arguments
for the associated command. However, the numbers in the sequence set appropriate for the associated command. However, the numbers in the
argument are unique identifiers instead of message sequence numbers. sequence set argument are unique identifiers instead of message
Sequence set ranges are permitted, but there is no guarantee that sequence numbers. Sequence set ranges are permitted, but there is no
unique identifiers will be contiguous. guarantee that unique identifiers will be contiguous.
A non-existent unique identifier is ignored without any error message A non-existent unique identifier is ignored without any error message
generated. Thus, it is possible for a UID FETCH command to return an generated. Thus, it is possible for a UID FETCH command to return an
OK without any data or a UID COPY or UID STORE to return an OK OK without any data or a UID COPY, UID MOVE or UID STORE to return an
without performing any operations. OK without performing any operations.
In the second form, the UID command takes an EXPUNGE command with an In the second form, the UID command takes an EXPUNGE command with an
extra parameter the specified a sequence set of UIDs to operate on. extra parameter the specified a sequence set of UIDs to operate on.
The UID EXPUNGE command permanently removes all messages that both The UID EXPUNGE command permanently removes all messages that both
have the \Deleted flag set and have a UID that is included in the have the \Deleted flag set and have a UID that is included in the
specified sequence set from the currently selected mailbox. If a specified sequence set from the currently selected mailbox. If a
message either does not have the \Deleted flag set or has a UID that message either does not have the \Deleted flag set or has a UID that
is not included in the specified sequence set, it is not affected. is not included in the specified sequence set, it is not affected.
UID EXPUNGE is particularly useful for disconnected use clients. UID EXPUNGE is particularly useful for disconnected use clients.
skipping to change at page 72, line 34 skipping to change at page 74, line 10
Other server data SHOULD be recorded for later reference; if the Other server data SHOULD be recorded for later reference; if the
client does not need to record the data, or if recording the data has client does not need to record the data, or if recording the data has
no obvious purpose (e.g., a SEARCH response when no SEARCH command is no obvious purpose (e.g., a SEARCH response when no SEARCH command is
in progress), the data SHOULD be ignored. in progress), the data SHOULD 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 and RECENT messages are found, the server sends untagged EXISTS response
responses reflecting the new size of the mailbox. Server reflecting the new size of the mailbox. Server implementations that
implementations that offer multiple simultaneous access to the same offer multiple simultaneous access to the same mailbox SHOULD also
mailbox SHOULD also send appropriate unilateral untagged FETCH and send appropriate unilateral untagged FETCH and EXPUNGE responses if
EXPUNGE responses if another agent changes the state of any message another agent changes the state of any message flags or expunges any
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 - 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.
skipping to change at page 79, line 38 skipping to change at page 81, line 19
UNAVAILABLE UNAVAILABLE
Temporary failure because a subsystem is down. For example, an Temporary failure because a subsystem is down. For example, an
IMAP server that uses a Lightweight Directory Access Protocol IMAP server that uses a Lightweight Directory Access Protocol
(LDAP) or Radius server for authentication might use this (LDAP) or Radius server for authentication might use this
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
UNSEEN Followed by a decimal number, indicates the number of the
first message without the \Seen flag set.
Additional response codes defined by particular client or server Additional response codes defined by particular client or server
implementations SHOULD be prefixed with an "X" until they are added implementations SHOULD be prefixed with an "X" until they are added
to a revision of this protocol. Client implementations SHOULD ignore to a revision of this protocol. Client implementations SHOULD ignore
response codes that they do not recognize. 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
skipping to change at page 88, line 26 skipping to change at page 90, line 5
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 recorded by the client.
Example: S: * 23 EXISTS Example: S: * 23 EXISTS
7.3.2. RECENT Response
Contents: none
The RECENT response reports the number of messages with the \Recent
flag set. This response occurs as a result of a SELECT or EXAMINE
command, and if the size of the mailbox changes (e.g., new messages).
Note: It is not guaranteed that the message sequence numbers of
recent messages will be a contiguous range of the highest n
messages in the mailbox (where n is the value reported by the
RECENT response). Examples of situations in which this is not the
case are: multiple clients having the same mailbox open (the first
session to be notified will see it as recent, others will probably
see it as non-recent), and when the mailbox is re-ordered by a
non-IMAP agent.
The only reliable way to identify recent messages is to look at
message flags to see which have the \Recent flag set, or to do a
SEARCH RECENT.
The update from the RECENT response MUST be recorded by the client.
Example: S: * 5 RECENT
7.4. Server Responses - Message Status 7.4. 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.4.1. EXPUNGE Response
Contents: none Contents: none
skipping to change at page 96, line 11 skipping to change at page 97, line 11
The following is a transcript of an IMAP4rev2 connection. A long The following is a transcript of an IMAP4rev2 connection. A long
line in this sample is broken for editorial clarity. line in this sample is broken for editorial clarity.
S: * OK IMAP4rev2 Service Ready S: * OK IMAP4rev2 Service Ready
C: a001 login mrc secret C: a001 login mrc secret
S: a001 OK LOGIN completed S: a001 OK LOGIN completed
C: a002 select inbox C: a002 select inbox
S: * 18 EXISTS S: * 18 EXISTS
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * 2 RECENT
S: * OK [UNSEEN 17] Message 17 is the first unseen message
S: * OK [UIDVALIDITY 3857529045] UIDs valid S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: a002 OK [READ-WRITE] SELECT completed S: a002 OK [READ-WRITE] SELECT completed
C: a003 fetch 12 full C: a003 fetch 12 full
S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700" S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700"
RFC822.SIZE 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)" RFC822.SIZE 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)"
"IMAP4rev2 WG mtg summary and minutes" "IMAP4rev2 WG mtg summary and minutes"
(("Terry Gray" NIL "gray" "cac.washington.edu")) (("Terry Gray" NIL "gray" "cac.washington.edu"))
(("Terry Gray" NIL "gray" "cac.washington.edu")) (("Terry Gray" NIL "gray" "cac.washington.edu"))
(("Terry Gray" NIL "gray" "cac.washington.edu")) (("Terry Gray" NIL "gray" "cac.washington.edu"))
((NIL NIL "imap" "cac.washington.edu")) ((NIL NIL "imap" "cac.washington.edu"))
skipping to change at page 100, line 29 skipping to change at page 101, line 24
command-auth = append / create / delete / examine / list / lsub / command-auth = append / create / delete / examine / list / lsub /
Namespace-Command / Namespace-Command /
rename / select / status / subscribe / unsubscribe / rename / select / status / subscribe / unsubscribe /
idle idle
; Valid only in Authenticated or Selected state ; Valid only in Authenticated or Selected state
command-nonauth = login / authenticate / "STARTTLS" command-nonauth = login / authenticate / "STARTTLS"
; Valid only when in Not Authenticated state ; Valid only when in Not Authenticated state
command-select = "CHECK" / "CLOSE" / "UNSELECT" / "EXPUNGE" / copy / command-select = "CHECK" / "CLOSE" / "UNSELECT" / "EXPUNGE" / copy /
fetch / store / search / uid move / fetch / store / search / uid
; Valid only when in Selected state ; Valid only when in Selected state
continue-req = "+" SP (resp-text / base64) CRLF continue-req = "+" SP (resp-text / base64) CRLF
copy = "COPY" SP sequence-set SP mailbox copy = "COPY" SP sequence-set SP mailbox
create = "CREATE" SP mailbox create = "CREATE" SP mailbox
; Use of INBOX gives a NO error ; Use of INBOX gives a NO error
date = date-text / DQUOTE date-text DQUOTE date = date-text / DQUOTE date-text DQUOTE
skipping to change at page 102, line 22 skipping to change at page 103, line 16
"\Seen" / "\Draft" / flag-keyword / flag-extension "\Seen" / "\Draft" / flag-keyword / flag-extension
; Does not include "\Recent" ; Does not include "\Recent"
flag-extension = "\" atom flag-extension = "\" atom
; Future expansion. Client implementations ; Future expansion. Client implementations
; 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
; and is now deprecated.
flag-fetch = flag / "\Recent" flag-fetch = flag
flag-keyword = "$MDNSent" / "$Forwarded" / atom flag-keyword = "$MDNSent" / "$Forwarded" / 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
skipping to change at page 103, line 4 skipping to change at page 103, line 49
list = "LIST" SP mailbox SP list-mailbox list = "LIST" SP mailbox SP list-mailbox
list-mailbox = 1*list-char / string list-mailbox = 1*list-char / string
list-char = ATOM-CHAR / list-wildcards / resp-specials list-char = ATOM-CHAR / list-wildcards / resp-specials
list-wildcards = "%" / "*" list-wildcards = "%" / "*"
literal = "{" number ["+"] "}" CRLF *CHAR8 literal = "{" number ["+"] "}" CRLF *CHAR8
; Number represents the number of CHAR8s. ; Number represents the number of CHAR8s.
; A non-synchronizing literal is distinguished from
; A non-synchronizing literal is distinguished ; a synchronizing literal by presence of the "+"
; from a synchronizing literal by presence of the "+"
; before the closing "}". ; before the closing "}".
; Non synchronizing literals are not allowed when sent ; Non synchronizing literals are not allowed when
; from server to the client. ; sent from server to the client.
login = "LOGIN" SP userid SP password login = "LOGIN" SP userid SP password
lsub = "LSUB" SP mailbox SP list-mailbox lsub = "LSUB" SP mailbox SP list-mailbox
mailbox = "INBOX" / astring mailbox = "INBOX" / astring
; INBOX is case-insensitive. All case variants of ; INBOX is case-insensitive. All case variants of
; INBOX (e.g., "iNbOx") MUST be interpreted as INBOX ; INBOX (e.g., "iNbOx") MUST be interpreted as INBOX
; not as an astring. An astring which consists of ; not as an astring. An astring which consists of
; the case-insensitive sequence "I" "N" "B" "O" "X" ; the case-insensitive sequence "I" "N" "B" "O" "X"
; is considered to be INBOX and not an astring. ; is considered to be INBOX and not an astring.
; Refer to section 5.1 for further ; Refer to section 5.1 for further
; semantic details of mailbox names. ; semantic details of mailbox names.
mailbox-data = "FLAGS" SP flag-list / "LIST" SP mailbox-list / mailbox-data = "FLAGS" SP flag-list / "LIST" SP mailbox-list /
"LSUB" SP mailbox-list / esearch-response / "LSUB" SP mailbox-list / esearch-response /
"STATUS" SP mailbox SP "(" [status-att-list] ")" / "STATUS" SP mailbox SP "(" [status-att-list] ")" /
number SP "EXISTS" / number SP "RECENT" / number SP "EXISTS" / Namespace-Response
Namespace-Response
mailbox-list = "(" [mbx-list-flags] ")" SP mailbox-list = "(" [mbx-list-flags] ")" SP
(DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox
mbx-list-flags = *(mbx-list-oflag SP) mbx-list-sflag mbx-list-flags = *(mbx-list-oflag SP) mbx-list-sflag
*(SP mbx-list-oflag) / *(SP mbx-list-oflag) /
mbx-list-oflag *(SP mbx-list-oflag) mbx-list-oflag *(SP mbx-list-oflag)
mbx-list-oflag = "\Noinferiors" / flag-extension mbx-list-oflag = "\Noinferiors" / flag-extension
; Other flags; multiple possible per LIST response ; Other flags; multiple possible per LIST response
mbx-list-sflag = "\Noselect" / "\Marked" / "\Unmarked" mbx-list-sflag = "\Noselect" / "\Marked" / "\Unmarked"
; Selectability flags; only one per LIST response ; Selectability flags; only one per LIST response
media-basic = ((DQUOTE ("APPLICATION" / "AUDIO" / "IMAGE" / media-basic = ((DQUOTE ("APPLICATION" / "AUDIO" / "IMAGE" /
"MESSAGE" / "VIDEO" / "FONT") DQUOTE) / string) SP "MESSAGE" / "VIDEO" / "FONT") DQUOTE) / string) SP
media-subtype media-subtype
; Defined in [MIME-IMT]. ; Defined in [MIME-IMT].
; FONT defined in RFC YYYY. ; FONT defined in RFC YYYY.
media-message = DQUOTE "MESSAGE" DQUOTE SP DQUOTE ("RFC822" / "GLOBAL") DQUOTE media-message = DQUOTE "MESSAGE" DQUOTE SP
DQUOTE ("RFC822" / "GLOBAL") DQUOTE
; Defined in [MIME-IMT] ; Defined in [MIME-IMT]
media-subtype = string media-subtype = string
; Defined in [MIME-IMT] ; Defined in [MIME-IMT]
media-text = DQUOTE "TEXT" DQUOTE SP media-subtype media-text = DQUOTE "TEXT" DQUOTE SP media-subtype
; Defined in [MIME-IMT] ; Defined in [MIME-IMT]
message-data = nz-number SP ("EXPUNGE" / ("FETCH" SP msg-att)) message-data = nz-number SP ("EXPUNGE" / ("FETCH" SP msg-att))
move = "MOVE" SP sequence-set SP mailbox
msg-att = "(" (msg-att-dynamic / msg-att-static) msg-att = "(" (msg-att-dynamic / msg-att-static)
*(SP (msg-att-dynamic / msg-att-static)) ")" *(SP (msg-att-dynamic / msg-att-static)) ")"
msg-att-dynamic = "FLAGS" SP "(" [flag-fetch *(SP flag-fetch)] ")" msg-att-dynamic = "FLAGS" SP "(" [flag-fetch *(SP flag-fetch)] ")"
; MAY change for a message ; MAY change for a message
msg-att-static = "ENVELOPE" SP envelope / "INTERNALDATE" SP date-time / msg-att-static = "ENVELOPE" SP envelope / "INTERNALDATE" SP date-time /
"RFC822" [".HEADER" / ".TEXT"] SP nstring / "RFC822" [".HEADER" / ".TEXT"] SP nstring /
"RFC822.SIZE" SP number / "RFC822.SIZE" SP number /
"BODY" ["STRUCTURE"] SP body / "BODY" ["STRUCTURE"] SP body /
skipping to change at page 106, line 19 skipping to change at page 107, line 17
;; ////Can we make "text" optional? Will this have any bad side effects? ;; ////Can we make "text" optional? Will this have any bad side effects?
resp-text = ["[" resp-text-code "]" SP] text resp-text = ["[" resp-text-code "]" SP] text
resp-text-code = "ALERT" / resp-text-code = "ALERT" /
"BADCHARSET" [SP "(" charset *(SP charset) ")" ] / "BADCHARSET" [SP "(" charset *(SP charset) ")" ] /
capability-data / "PARSE" / capability-data / "PARSE" /
"PERMANENTFLAGS" SP "(" "PERMANENTFLAGS" SP "("
[flag-perm *(SP flag-perm)] ")" / [flag-perm *(SP flag-perm)] ")" /
"READ-ONLY" / "READ-WRITE" / "TRYCREATE" / "READ-ONLY" / "READ-WRITE" / "TRYCREATE" /
"UIDNEXT" SP nz-number / "UIDVALIDITY" SP nz-number / "UIDNEXT" SP nz-number / "UIDVALIDITY" SP nz-number /
"UNSEEN" SP nz-number /
resp-code-apnd / resp-code-copy / "UIDNOTSTICKY" / resp-code-apnd / resp-code-copy / "UIDNOTSTICKY" /
"UNAVAILABLE" / "AUTHENTICATIONFAILED" / "UNAVAILABLE" / "AUTHENTICATIONFAILED" /
"AUTHORIZATIONFAILED" / "EXPIRED" / "AUTHORIZATIONFAILED" / "EXPIRED" /
"PRIVACYREQUIRED" / "CONTACTADMIN" / "NOPERM" / "PRIVACYREQUIRED" / "CONTACTADMIN" / "NOPERM" /
"INUSE" / "EXPUNGEISSUED" / "CORRUPTION" / "INUSE" / "EXPUNGEISSUED" / "CORRUPTION" /
"SERVERBUG" / "CLIENTBUG" / "CANNOT" / "SERVERBUG" / "CLIENTBUG" / "CANNOT" /
"LIMIT" / "OVERQUOTA" / "ALREADYEXISTS" / "LIMIT" / "OVERQUOTA" / "ALREADYEXISTS" /
"NONEXISTENT" / "NONEXISTENT" /
"CLOSED" / "CLOSED" /
atom [SP 1*<any TEXT-CHAR except "]">] atom [SP 1*<any TEXT-CHAR except "]">]
search = "SEARCH" [search-return-opts] search = "SEARCH" [search-return-opts]
SP search-program SP search-program
search-correlator = SP "(" "TAG" SP tag-string ")" search-correlator = SP "(" "TAG" SP tag-string ")"
search-key = "ALL" / "ANSWERED" / "BCC" SP astring / search-key = "ALL" / "ANSWERED" / "BCC" SP astring /
"BEFORE" SP date / "BODY" SP astring / "BEFORE" SP date / "BODY" SP astring /
"CC" SP astring / "DELETED" / "FLAGGED" / "CC" SP astring / "DELETED" / "FLAGGED" /
"FROM" SP astring / "KEYWORD" SP flag-keyword / "FROM" SP astring / "KEYWORD" SP flag-keyword /
"NEW" / "OLD" / "ON" SP date / "RECENT" / "SEEN" / "NEW" / "OLD" / "ON" SP date / "SEEN" /
"SINCE" SP date / "SUBJECT" SP astring / "SINCE" SP date / "SUBJECT" SP astring /
"TEXT" SP astring / "TO" SP astring / "TEXT" SP astring / "TO" SP astring /
"UNANSWERED" / "UNDELETED" / "UNFLAGGED" / "UNANSWERED" / "UNDELETED" / "UNFLAGGED" /
"UNKEYWORD" SP flag-keyword / "UNSEEN" / "UNKEYWORD" SP flag-keyword / "UNSEEN" /
; Above this line were in [IMAP2] ; Above this line were in [IMAP2]
"DRAFT" / "HEADER" SP header-fld-name SP astring / "DRAFT" / "HEADER" SP header-fld-name SP astring /
"LARGER" SP number / "NOT" SP search-key / "LARGER" SP number / "NOT" SP search-key /
"OR" SP search-key SP search-key / "OR" SP search-key SP search-key /
"SENTBEFORE" SP date / "SENTON" SP date / "SENTBEFORE" SP date / "SENTON" SP date /
"SENTSINCE" SP date / "SMALLER" SP number / "SENTSINCE" SP date / "SMALLER" SP number /
skipping to change at page 107, line 27 skipping to change at page 108, line 23
search-ret-data-ext = search-modifier-name SP search-return-value search-ret-data-ext = search-modifier-name SP search-return-value
; Note that not every SEARCH return option ; Note that not every SEARCH return option
; is required to have the corresponding ; is required to have the corresponding
; ESEARCH return data. ; ESEARCH return data.
search-return-data = "MIN" SP nz-number / search-return-data = "MIN" SP nz-number /
"MAX" SP nz-number / "MAX" SP nz-number /
"ALL" SP sequence-set / "ALL" SP sequence-set /
"COUNT" SP number / "COUNT" SP number /
search-ret-data-ext search-ret-data-ext
; All return data items conform to search-ret-data-ext ; All return data items conform to
; syntax ; search-ret-data-ext syntax
search-return-opts = SP "RETURN" SP "(" [search-return-opt search-return-opts = SP "RETURN" SP "(" [search-return-opt
*(SP search-return-opt)] ")" *(SP search-return-opt)] ")"
search-return-opt = "MIN" / "MAX" / "ALL" / "COUNT" / search-return-opt = "MIN" / "MAX" / "ALL" / "COUNT" /
search-ret-opt-ext search-ret-opt-ext
; conforms to generic search-ret-opt-ext ; conforms to generic search-ret-opt-ext
; syntax ; syntax
search-ret-opt-ext = search-modifier-name [SP search-mod-params] search-ret-opt-ext = search-modifier-name [SP search-mod-params]
skipping to change at page 109, line 8 skipping to change at page 110, line 5
; 2,4:7,9,12:* for a mailbox with 15 messages is ; 2,4:7,9,12:* for a mailbox with 15 messages is
; equivalent to 2,4,5,6,7,9,12,13,14,15 ; equivalent to 2,4,5,6,7,9,12,13,14,15
; Example: a message sequence number set of *:4,5:7 ; Example: a message sequence number set of *:4,5:7
; for a mailbox with 10 messages is equivalent to ; for a mailbox with 10 messages is equivalent to
; 10,9,8,7,6,5,4,5,6,7 and MAY be reordered and ; 10,9,8,7,6,5,4,5,6,7 and MAY be reordered and
; overlap coalesced to be 4,5,6,7,8,9,10. ; overlap coalesced to be 4,5,6,7,8,9,10.
status = "STATUS" SP mailbox SP status = "STATUS" SP mailbox SP
"(" status-att *(SP status-att) ")" "(" status-att *(SP status-att) ")"
status-att = "MESSAGES" / "RECENT" / "UIDNEXT" / "UIDVALIDITY" / status-att = "MESSAGES" / "UIDNEXT" / "UIDVALIDITY" /
"UNSEEN" / "SIZE" "UNSEEN" / "SIZE"
status-att-val = ("MESSAGES" SP number) / ("RECENT" SP number) / status-att-val = ("MESSAGES" SP number) /
("UIDNEXT" SP nz-number) / ("UIDVALIDITY" SP nz-number) / ("UIDNEXT" SP nz-number) /
("UNSEEN" SP number) / ("SIZE" SP number64) ("UIDVALIDITY" SP nz-number) /
("UNSEEN" SP number) /
("SIZE" SP number64)
; Extensions to the STATUS responses ; Extensions to the STATUS responses
; should extend this production. ; should extend this production.
; Extensions should use the generic ; Extensions should use the generic
; syntax defined by tagged-ext. ; syntax defined by tagged-ext.
status-att-list = status-att-val *(SP status-att-val) status-att-list = status-att-val *(SP status-att-val)
store = "STORE" SP sequence-set SP store-att-flags store = "STORE" SP sequence-set SP store-att-flags
store-att-flags = (["+" / "-"] "FLAGS" [".SILENT"]) SP store-att-flags = (["+" / "-"] "FLAGS" [".SILENT"]) SP
skipping to change at page 110, line 14 skipping to change at page 111, line 13
tagged-ext-val = tagged-ext-simple / tagged-ext-val = tagged-ext-simple /
"(" [tagged-ext-comp] ")" "(" [tagged-ext-comp] ")"
text = 1*TEXT-CHAR text = 1*TEXT-CHAR
TEXT-CHAR = <any CHAR except CR and LF> TEXT-CHAR = <any CHAR except CR and LF>
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
; Hours minutes seconds ; Hours minutes seconds
uid = "UID" SP (copy / fetch / search / store / uid-expunge) uid = "UID" SP
(copy / move / fetch / search / store / uid-expunge)
; Unique identifiers used instead of message ; Unique identifiers used instead of message
; sequence numbers ; sequence numbers
uid-expunge = "EXPUNGE" SP sequence-set uid-expunge = "EXPUNGE" SP sequence-set
; Unique identifiers used instead of message ; Unique identifiers used instead of message
; sequence numbers ; sequence numbers
uid-set = (uniqueid / uid-range) *("," uid-set) uid-set = (uniqueid / uid-range) *("," uid-set)
uid-range = (uniqueid ":" uniqueid) uid-range = (uniqueid ":" uniqueid)
skipping to change at page 113, line 6 skipping to change at page 114, line 6
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 "imap" port 143 should be updated to point 1. Registration for TCP "imap" port 143 should be updated to point
to this document and RFC 3501. to this document and RFC 3501.
2. Registration for TCP "imaps" port 993 should be updated to point 2. Registration for TCP "imaps" port 993 should be updated to point
to this document and RFC 3501. to this document, RFC 8314 and RFC 3501.
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
skipping to change at page 120, line 18 skipping to change at page 121, line 18
correct form is "&U,BTF2XlZyyKng-". correct form is "&U,BTF2XlZyyKng-".
Appendix B. Changes from RFC 3501 / IMAP4rev1 Appendix B. Changes from RFC 3501 / IMAP4rev1
The following is the plan for remaining changes. The plan might The following is the plan for remaining changes. The plan might
change over time. change over time.
1. Fold in the following extensions/RFC: RFC 5530 (IMAP Response 1. Fold in the following extensions/RFC: RFC 5530 (IMAP Response
Codes, done), UIDPLUS (done), ENABLE (done), ESEARCH (done), Codes, done), UIDPLUS (done), ENABLE (done), ESEARCH (done),
SPECIAL-USE (list of new mailbox attributes is done), LITERAL- SPECIAL-USE (list of new mailbox attributes is done), LITERAL-
(done), NAMESPACE (done), SASL-IR (done). (done), NAMESPACE (done), SASL-IR (done), IDLE (done), MOVE
(done).
2. Add CLOSED response code (from CONDSTORE) - done 2. Add CLOSED response code (from CONDSTORE) - done
3. Add support for $MDNSent and $Forwarded IMAP keywords - done. 3. Add support for $MDNSent and $Forwarded IMAP keywords - done.
Add more examples showing their use? Add more examples showing their use? Also add other keywords
like $Phishing, $Junk, $NonJunk?
4. Require all unsolicited updates to include UID (?) 4. Require all unsolicited FETCH updates to include UID - done.
5. Update recommendations on TLS ciphers to match UTA WG work (as 5. Update recommendations on TLS ciphers to match UTA WG work (as
per RFC 8314, RFC 7525 and RFC 7817) - done. per RFC 8314, RFC 7525 and RFC 7817) - done.
6. Possibly fold in the following extensions/RFC: Base LIST- 6. Possibly fold in the following extensions/RFC: Base LIST-
EXTENDED syntax plus deprecate LSUB (replace it with LIST EXTENDED syntax plus deprecate LSUB (replace it with LIST
\Subscribed) minus the requirement to support multiple list \Subscribed) minus the requirement to support multiple list
patterns, STATUS-in-LIST, Unique mailstore IDs for messages patterns, STATUS-in-LIST, SEARCHRES, BINARY (only the FETCH
(OBJECTID extension, RFC 8474), IDLE (done), SEARCHRES, BINARY changes on leaf body part and make APPEND related ones optional.
(possibly only the FETCH changes and make APPEND related ones See the mailing list discussion), Unique mailstore IDs for
optional?). messages (OBJECTID extension, RFC 8474) -- rough consensus to
keep it as an extension.
7. Add STATUS SIZE (total mailbox size) - done Add STATUS DELETED 7. Add STATUS SIZE (total mailbox size) - done Add STATUS DELETED
(number of messages with \Deleted flag set)? (number of messages with \Deleted flag set)? Or DELETEDSIZE?
8. Deprecate features: RECENT response on SELECT/EXAMINE, \Recent 8. Deprecate features: What should we do with NEW search key (which
flag, RECENT STATUS item. UNSEEN response code on SELECT/ implies RECENT): deprecate it or just redefine it to ignore
EXAMINE. SEARCH response (use ESEARCH instead). RECENT state?
9. Drop UTF-7, all mailboxes are always in UTF-8 - done. 9. Drop UTF-7, all mailboxes are always in UTF-8 - done.
10. Revise IANA registration of IMAP extensions and advice on use of 10. Revise IANA registration of IMAP extensions and give advice on
"X-" convention. use of "X-" convention.
11. Allow word-based searching (as per Chris Newman)?
The following changes since RFC 3501 were done so far: The following changes since RFC 3501 were done so far:
1. Folded in IMAP UNSELECT (RFC 3691), UIDPLUS (RFC 4315), ESEARCH 1. Folded in IMAP UNSELECT (RFC 3691), UIDPLUS (RFC 4315), ESEARCH
(RFC 4731), ENABLE (RFC 5161), IDLE (RFC 2177) and SASL-IR (RFC (RFC 4731), ENABLE (RFC 5161), IDLE (RFC 2177), SASL-IR (RFC
4959) extensions. Also folded RFC 5530. 4959) and MOVE (RFC 6851) extensions. Also folded RFC 5530.
2. Added CLOSED response code from RFC 7162. 2. SEARCH command now requires to return ESEARCH response (SEARCH
response is now deprecated).
3. Updated to use modern TLS-related recommendations as per RFC 3. Added CLOSED response code from RFC 7162.
8314, RFC 7817, RFC 7525.
4. For future extensibility extended ABNF for tagged-ext-simple to 4. Updated to use modern TLS-related recommendations as per RFC
allow for bare number64. 8314, RFC 7817, RFC 7525.
5. Added SHOULD level requirement on IMAP servers to support 5. For future extensibility extended ABNF for tagged-ext-simple to
$MDNSent and $Forwarded keywords. allow for bare number64.
6. Added STATUS SIZE. 6. Added SHOULD level requirement on IMAP servers to support
$MDNSent and $Forwarded keywords.
7. Mailbox names and message headers now allow for UTF-8. Support 7. Added STATUS SIZE.
for Modified UTF-7 in mailbox names is not required, unless
compatibility with IMAP4rev1 is desired. 8. Mailbox names and message headers now allow for UTF-8. Support
for Modified UTF-7 in mailbox names is not required, unless
compatibility with IMAP4rev1 is desired.
9. UNSEEN response code on SELECT/EXAMINE is now deprecated.
10. RECENT response on SELECT/EXAMINE, \Recent flag, RECENT STATUS
item are now deprecated.
Appendix C. Acknowledgement Appendix C. Acknowledgement
Earlier versions of this document were edited by Mark Crispin. Earlier versions of this document were edited by Mark Crispin.
Sadly, he is no longer available to help with this work. Editor of Sadly, he is no longer available to help with this work. Editors of
this revisions is 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.
This document incorporate text from RFC 4315, RFC 4466, RFC 4731, RFC This document incorporate text from RFC 4315, RFC 4466, RFC 4731, RFC
5161, RFC 6154 so work done by authors/editors of these documents is 5161, RFC 6154 so work done by authors/editors of these documents is
appreciated. appreciated.
skipping to change at page 121, line 52 skipping to change at page 123, line 16
$ $
$Forwarded (predefined flag) 12 $Forwarded (predefined flag) 12
$MDNSent (predefined flag) 12 $MDNSent (predefined flag) 12
+ +
+FLAGS <flag list> 67 +FLAGS <flag list> 67
+FLAGS.SILENT <flag list> 67 +FLAGS.SILENT <flag list> 67
- -
-FLAGS <flag list> 68 -FLAGS <flag list> 67
-FLAGS.SILENT <flag list> 68 -FLAGS.SILENT <flag list> 67
A A
ALERT (response code) 73 ALERT (response code) 74
ALL (fetch item) 64 ALL (fetch item) 63
ALL (search key) 60 ALL (search key) 60
ALL (search result option) 59 ALL (search result option) 59
ALREADYEXISTS (response code) 73 ALREADYEXISTS (response code) 74
ANSWERED (search key) 60 ANSWERED (search key) 60
APPEND (command) 51 APPEND (command) 51
APPENDUID (response code) 73 APPENDUID (response code) 74
AUTHENTICATE (command) 27 AUTHENTICATE (command) 27
AUTHENTICATIONFAILED (response code) 74 AUTHENTICATIONFAILED (response code) 75
AUTHORIZATIONFAILED (response code) 74 AUTHORIZATIONFAILED (response code) 75
B B
BAD (response) 80 BAD (response) 82
BADCHARSET (response code) 74 BADCHARSET (response code) 76
BCC <string> (search key) 60 BCC <string> (search key) 60
BEFORE <date> (search key) 60 BEFORE <date> (search key) 60
BODY (fetch item) 64 BODY (fetch item) 64
BODY (fetch result) 90 BODY (fetch result) 91
BODY <string> (search key) 60 BODY <string> (search key) 60
BODY.PEEK[<section>]<<partial>> (fetch item) 66 BODY.PEEK[<section>]<<partial>> (fetch item) 66
BODYSTRUCTURE (fetch item) 66 BODYSTRUCTURE (fetch item) 66
BODYSTRUCTURE (fetch result) 90 BODYSTRUCTURE (fetch result) 91
BODY[<section>]<<origin octet>> (fetch result) 90 BODY[<section>]<<origin octet>> (fetch result) 91
BODY[<section>]<<partial>> (fetch item) 64 BODY[<section>]<<partial>> (fetch item) 64
BYE (response) 81 BYE (response) 83
Body Structure (message attribute) 13 Body Structure (message attribute) 13
C C
CANNOT (response code) 74 CANNOT (response code) 76
CAPABILITY (command) 24 CAPABILITY (command) 24
CAPABILITY (response code) 74 CAPABILITY (response code) 76
CAPABILITY (response) 82 CAPABILITY (response) 84
CC <string> (search key) 60 CC <string> (search key) 60
CHECK (command) 56 CHECK (command) 56
CLIENTBUG (response code) 74 CLIENTBUG (response code) 76
CLOSE (command) 56 CLOSE (command) 56
CLOSED (response code) 75 CLOSED (response code) 76
CONTACTADMIN (response code) 75 CONTACTADMIN (response code) 77
COPY (command) 68 COPY (command) 68
COPYUID (response code) 75 COPYUID (response code) 77
CORRUPTION (response code) 76 CORRUPTION (response code) 77
COUNT (search result option) 59 COUNT (search result option) 59
CREATE (command) 36 CREATE (command) 35
D D
DELETE (command) 37 DELETE (command) 36
DELETED (search key) 60 DELETED (search key) 60
DRAFT (search key) 60 DRAFT (search key) 60
E E
ENABLE (command) 31 ENABLE (command) 31
ENVELOPE (fetch item) 66 ENVELOPE (fetch item) 66
ENVELOPE (fetch result) 93 ENVELOPE (fetch result) 94
ESEARCH (response) 87 ESEARCH (response) 88
EXAMINE (command) 35 EXAMINE (command) 35
EXPIRED (response code) 76 EXPIRED (response code) 78
EXPUNGE (command) 57 EXPUNGE (command) 57
EXPUNGE (response) 89 EXPUNGE (response) 90
EXPUNGEISSUED (response code) 76 EXPUNGEISSUED (response code) 78
Envelope Structure (message attribute) 13 Envelope Structure (message attribute) 13
F F
FAST (fetch item) 64 FAST (fetch item) 63
FETCH (command) 63 FETCH (command) 63
FETCH (response) 90 FETCH (response) 91
FLAGGED (search key) 60 FLAGGED (search key) 60
FLAGS (fetch item) 66 FLAGS (fetch item) 66
FLAGS (fetch result) 94 FLAGS (fetch result) 95
FLAGS (response) 87 FLAGS (response) 89
FLAGS <flag list> (store command data item) 67 FLAGS <flag list> (store command data item) 67
FLAGS.SILENT <flag list> (store command data item) 67 FLAGS.SILENT <flag list> (store command data item) 67
FROM <string> (search key) 61 FROM <string> (search key) 60
FULL (fetch item) 64 FULL (fetch item) 64
Flags (message attribute) 11 Flags (message attribute) 11
H H
HEADER (part specifier) 64 HEADER (part specifier) 64
HEADER <field-name> <string> (search key) 61 HEADER <field-name> <string> (search key) 60
HEADER.FIELDS (part specifier) 64 HEADER.FIELDS (part specifier) 64
HEADER.FIELDS.NOT (part specifier) 64 HEADER.FIELDS.NOT (part specifier) 64
I I
IDLE (command) 54 IDLE (command) 53
INTERNALDATE (fetch item) 66 INTERNALDATE (fetch item) 66
INTERNALDATE (fetch result) 94 INTERNALDATE (fetch result) 95
INUSE (response code) 76 INUSE (response code) 78
Internal Date (message attribute) 13 Internal Date (message attribute) 12
K K
KEYWORD <flag> (search key) 61 KEYWORD <flag> (search key) 61
Keyword (type of flag) 12 Keyword (type of flag) 12
L L
LARGER <n> (search key) 61 LARGER <n> (search key) 61
LIMIT (response code) 77 LIMIT (response code) 78
LIST (command) 41 LIST (command) 41
LIST (response) 83 LIST (response) 85
LOGOUT (command) 25 LOGOUT (command) 25
LSUB (command) 44 LSUB (command) 44
LSUB (response) 86 LSUB (response) 87
M M
MAX (search result option) 59 MAX (search result option) 58
MAY (specification requirement term) 5 MAY (specification requirement term) 5
MESSAGES (status item) 50 MESSAGES (status item) 50
MIME (part specifier) 65 MIME (part specifier) 65
MIN (search result option) 58 MIN (search result option) 58
MOVE (command) 69
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) 45 NAMESPACE (command) 45
NAMESPACE (response) 86 NAMESPACE (response) 88
NEW (search key) 61 NEW (search key) 61
NO (response) 80 NO (response) 81
NONEXISTENT (response code) 77 NONEXISTENT (response code) 78
NOOP (command) 25 NOOP (command) 25
NOPERM (response code) 77 NOPERM (response code) 79
NOT <search-key> (search key) 61 NOT <search-key> (search key) 61
O O
OK (response) 79 OK (response) 81
OLD (search key) 61
ON <date> (search key) 61 ON <date> (search key) 61
OPTIONAL (specification requirement term) 5 OPTIONAL (specification requirement term) 5
OR <search-key1> <search-key2> (search key) 61 OR <search-key1> <search-key2> (search key) 61
OVERQUOTA (response code) 77 OVERQUOTA (response code) 79
P P
PARSE (response code) 78 PARSE (response code) 79
PERMANENTFLAGS (response code) 78 PERMANENTFLAGS (response code) 79
PREAUTH (response) 81 PREAUTH (response) 82
PRIVACYREQUIRED (response code) 78 PRIVACYREQUIRED (response code) 79
Permanent Flag (class of flag) 12 Permanent Flag (class of flag) 12
Predefined keywords 12 Predefined keywords 12
R R
READ-ONLY (response code) 78 READ-ONLY (response code) 80
READ-WRITE (response code) 78 READ-WRITE (response code) 80
RECENT (search key) 61
RECENT (status item) 50
RECOMMENDED (specification requirement term) 5 RECOMMENDED (specification requirement term) 5
RENAME (command) 38 RENAME (command) 38
REQUIRED (specification requirement term) 5 REQUIRED (specification requirement term) 5
RFC822 (fetch item) 66 RFC822 (fetch item) 66
RFC822 (fetch result) 94 RFC822 (fetch result) 95
RFC822.HEADER (fetch item) 66 RFC822.HEADER (fetch item) 66
RFC822.HEADER (fetch result) 94 RFC822.HEADER (fetch result) 95
RFC822.SIZE (fetch item) 66 RFC822.SIZE (fetch item) 66
RFC822.SIZE (fetch result) 94 RFC822.SIZE (fetch result) 95
RFC822.TEXT (fetch item) 66 RFC822.TEXT (fetch item) 66
RFC822.TEXT (fetch result) 94 RFC822.TEXT (fetch result) 95
S S
SEARCH (command) 58 SEARCH (command) 58
SEEN (search key) 61 SEEN (search key) 61
SELECT (command) 33 SELECT (command) 33
SENTBEFORE <date> (search key) 61 SENTBEFORE <date> (search key) 61
SENTON <date> (search key) 61 SENTON <date> (search key) 61
SENTSINCE <date> (search key) 61 SENTSINCE <date> (search key) 61
SERVERBUG (response code) 78 SERVERBUG (response code) 80
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) 61 SINCE <date> (search key) 61
SIZE (status item) 51 SIZE (status item) 51
SMALLER <n> (search key) 62 SMALLER <n> (search key) 61
STARTTLS (command) 26 STARTTLS (command) 26
STATUS (command) 49 STATUS (command) 49
STATUS (response) 86 STATUS (response) 88
STORE (command) 67 STORE (command) 66
SUBJECT <string> (search key) 62 SUBJECT <string> (search key) 61
SUBSCRIBE (command) 40 SUBSCRIBE (command) 40
Session Flag (class of flag) 12 Session Flag (class of flag) 12
System Flag (type of flag) 11 System Flag (type of flag) 11
T T
TEXT (part specifier) 64 TEXT (part specifier) 64
TEXT <string> (search key) 62 TEXT <string> (search key) 61
TO <string> (search key) 62 TO <string> (search key) 61
TRYCREATE (response code) 78 TRYCREATE (response code) 80
U U
UID (command) 69 UID (command) 70
UID (fetch item) 67 UID (fetch item) 66
UID (fetch result) 94 UID (fetch result) 95
UID <sequence set> (search key) 62 UID <sequence set> (search key) 62
UIDNEXT (response code) 79 UIDNEXT (response code) 80
UIDNEXT (status item) 50 UIDNEXT (status item) 50
UIDNOTSTICKY (response code) 79 UIDNOTSTICKY (response code) 80
UIDVALIDITY (response code) 79 UIDVALIDITY (response code) 81
UIDVALIDITY (status item) 50 UIDVALIDITY (status item) 50
UNANSWERED (search key) 62 UNANSWERED (search key) 62
UNAVAILABLE (response code) 79 UNAVAILABLE (response code) 81
UNDELETED (search key) 62 UNDELETED (search key) 62
UNDRAFT (search key) 62 UNDRAFT (search key) 62
UNFLAGGED (search key) 62 UNFLAGGED (search key) 62
UNKEYWORD <flag> (search key) 62 UNKEYWORD <flag> (search key) 62
UNSEEN (response code) 79
UNSEEN (search key) 62 UNSEEN (search key) 62
UNSEEN (status item) 51 UNSEEN (status item) 50
UNSELECT (command) 57 UNSELECT (command) 57
UNSUBSCRIBE (command) 41 UNSUBSCRIBE (command) 41
Unique Identifier (UID) (message attribute) 9 Unique Identifier (UID) (message attribute) 9
X X
X<atom> (command) 71 X<atom> (command) 72
[ [
[RFC-5322] Size (message attribute) 13 [RFC-5322] Size (message attribute) 13
\ \
\All (mailbox name attribute) 84 \All (mailbox name attribute) 86
\Answered (system flag) 11 \Answered (system flag) 11
\Archive (mailbox name attribute) 84 \Archive (mailbox name attribute) 86
\Deleted (system flag) 11 \Deleted (system flag) 11
\Draft (system flag) 12 \Draft (system flag) 12
\Drafts (mailbox name attribute) 85 \Drafts (mailbox name attribute) 86
\Flagged (mailbox name attribute) 85 \Flagged (mailbox name attribute) 86
\Flagged (system flag) 11 \Flagged (system flag) 11
\HasChildren (mailbox name attribute) 83 \HasChildren (mailbox name attribute) 85
\HasNoChildren (mailbox name attribute) 84 \HasNoChildren (mailbox name attribute) 85
\Junk (mailbox name attribute) 85 \Junk (mailbox name attribute) 86
\Marked (mailbox name attribute) 84 \Marked (mailbox name attribute) 85
\Noinferiors (mailbox name attribute) 83 \Noinferiors (mailbox name attribute) 85
\Noselect (mailbox name attribute) 83 \Noselect (mailbox name attribute) 85
\Recent (system flag) 12 \Recent (system flag) 12
\Seen (system flag) 11 \Seen (system flag) 11
\Sent (mailbox name attribute) 85 \Sent (mailbox name attribute) 86
\Trash (mailbox name attribute) 85 \Trash (mailbox name attribute) 87
\Unmarked (mailbox name attribute) 84 \Unmarked (mailbox name attribute) 85
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. 141 change blocks. 
370 lines changed or deleted 395 lines changed or added

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