< draft-ietf-extra-imap4rev2-07.txt   draft-ietf-extra-imap4rev2-08.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: May 7, 2020 November 4, 2019 Expires: May 22, 2020 November 19, 2019
INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev2 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev2
draft-ietf-extra-imap4rev2-07 draft-ietf-extra-imap4rev2-08
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 May 7, 2020. This Internet-Draft will expire on May 22, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
skipping to change at page 3, line 4 skipping to change at page 3, line 4
2.3. Message Attributes . . . . . . . . . . . . . . . . . . . 9 2.3. Message Attributes . . . . . . . . . . . . . . . . . . . 9
2.3.1. Message Numbers . . . . . . . . . . . . . . . . . . . 9 2.3.1. Message Numbers . . . . . . . . . . . . . . . . . . . 9
2.3.2. Flags Message Attribute . . . . . . . . . . . . . . . 11 2.3.2. Flags Message Attribute . . . . . . . . . . . . . . . 11
2.3.3. Internal Date Message Attribute . . . . . . . . . . . 12 2.3.3. Internal Date Message Attribute . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 13 3.1. Not Authenticated State . . . . . . . . . . . . . . . . . 13
3.2. Authenticated State . . . . . . . . . . . . . . . . . . . 13 3.2. Authenticated State . . . . . . . . . . . . . . . . . . . 14
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 38 skipping to change at page 3, line 38
6.2. Client Commands - Not Authenticated State . . . . . . . . 26 6.2. Client Commands - Not Authenticated State . . . . . . . . 26
6.2.1. STARTTLS Command . . . . . . . . . . . . . . . . . . 27 6.2.1. STARTTLS Command . . . . . . . . . . . . . . . . . . 27
6.2.2. AUTHENTICATE Command . . . . . . . . . . . . . . . . 28 6.2.2. AUTHENTICATE Command . . . . . . . . . . . . . . . . 28
6.2.3. LOGIN Command . . . . . . . . . . . . . . . . . . . . 31 6.2.3. LOGIN Command . . . . . . . . . . . . . . . . . . . . 31
6.3. Client Commands - Authenticated State . . . . . . . . . . 31 6.3. Client Commands - Authenticated State . . . . . . . . . . 31
6.3.1. ENABLE Command . . . . . . . . . . . . . . . . . . . 32 6.3.1. ENABLE Command . . . . . . . . . . . . . . . . . . . 32
6.3.2. SELECT Command . . . . . . . . . . . . . . . . . . . 34 6.3.2. SELECT Command . . . . . . . . . . . . . . . . . . . 34
6.3.3. EXAMINE Command . . . . . . . . . . . . . . . . . . . 35 6.3.3. EXAMINE Command . . . . . . . . . . . . . . . . . . . 35
6.3.4. CREATE Command . . . . . . . . . . . . . . . . . . . 36 6.3.4. CREATE Command . . . . . . . . . . . . . . . . . . . 36
6.3.5. DELETE Command . . . . . . . . . . . . . . . . . . . 37 6.3.5. DELETE Command . . . . . . . . . . . . . . . . . . . 37
6.3.6. RENAME Command . . . . . . . . . . . . . . . . . . . 38 6.3.6. RENAME Command . . . . . . . . . . . . . . . . . . . 39
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. NAMESPACE Command . . . . . . . . . . . . . . . . . . 57 6.3.10. NAMESPACE Command . . . . . . . . . . . . . . . . . . 57
6.3.11. STATUS Command . . . . . . . . . . . . . . . . . . . 62 6.3.11. STATUS Command . . . . . . . . . . . . . . . . . . . 62
6.3.12. APPEND Command . . . . . . . . . . . . . . . . . . . 63 6.3.12. APPEND Command . . . . . . . . . . . . . . . . . . . 63
6.3.13. IDLE Command . . . . . . . . . . . . . . . . . . . . 66 6.3.13. IDLE Command . . . . . . . . . . . . . . . . . . . . 66
6.4. Client Commands - Selected State . . . . . . . . . . . . 68 6.4. Client Commands - Selected State . . . . . . . . . . . . 68
6.4.1. CLOSE Command . . . . . . . . . . . . . . . . . . . . 68 6.4.1. CLOSE Command . . . . . . . . . . . . . . . . . . . . 68
6.4.2. UNSELECT Command . . . . . . . . . . . . . . . . . . 68 6.4.2. UNSELECT Command . . . . . . . . . . . . . . . . . . 69
6.4.3. EXPUNGE Command . . . . . . . . . . . . . . . . . . . 69 6.4.3. EXPUNGE Command . . . . . . . . . . . . . . . . . . . 69
6.4.4. SEARCH Command . . . . . . . . . . . . . . . . . . . 69 6.4.4. SEARCH Command . . . . . . . . . . . . . . . . . . . 70
6.4.5. FETCH Command . . . . . . . . . . . . . . . . . . . . 75 6.4.5. FETCH Command . . . . . . . . . . . . . . . . . . . . 76
6.4.6. STORE Command . . . . . . . . . . . . . . . . . . . . 79 6.4.6. STORE Command . . . . . . . . . . . . . . . . . . . . 80
6.4.7. COPY Command . . . . . . . . . . . . . . . . . . . . 80 6.4.7. COPY Command . . . . . . . . . . . . . . . . . . . . 81
6.4.8. MOVE Command . . . . . . . . . . . . . . . . . . . . 81 6.4.8. MOVE Command . . . . . . . . . . . . . . . . . . . . 82
6.4.9. UID Command . . . . . . . . . . . . . . . . . . . . . 83 6.4.9. UID Command . . . . . . . . . . . . . . . . . . . . . 84
6.5. Client Commands - Experimental/Expansion . . . . . . . . 85 6.5. Client Commands - Experimental/Expansion . . . . . . . . 85
6.5.1. X<atom> Command . . . . . . . . . . . . . . . . . . . 85 6.5.1. X<atom> Command . . . . . . . . . . . . . . . . . . . 85
7. Server Responses . . . . . . . . . . . . . . . . . . . . . . 85 7. Server Responses . . . . . . . . . . . . . . . . . . . . . . 86
7.1. Server Responses - Status Responses . . . . . . . . . . . 86 7.1. Server Responses - Status Responses . . . . . . . . . . . 87
7.1.1. OK Response . . . . . . . . . . . . . . . . . . . . . 94 7.1.1. OK Response . . . . . . . . . . . . . . . . . . . . . 95
7.1.2. NO Response . . . . . . . . . . . . . . . . . . . . . 94 7.1.2. NO Response . . . . . . . . . . . . . . . . . . . . . 95
7.1.3. BAD Response . . . . . . . . . . . . . . . . . . . . 95 7.1.3. BAD Response . . . . . . . . . . . . . . . . . . . . 96
7.1.4. PREAUTH Response . . . . . . . . . . . . . . . . . . 95 7.1.4. PREAUTH Response . . . . . . . . . . . . . . . . . . 96
7.1.5. BYE Response . . . . . . . . . . . . . . . . . . . . 95 7.1.5. BYE Response . . . . . . . . . . . . . . . . . . . . 97
7.2. Server Responses - Server and Mailbox Status . . . . . . 96 7.2. Server Responses - Server and Mailbox Status . . . . . . 97
7.2.1. The ENABLED Response . . . . . . . . . . . . . . . . 96 7.2.1. The ENABLED Response . . . . . . . . . . . . . . . . 97
7.2.2. CAPABILITY Response . . . . . . . . . . . . . . . . . 96 7.2.2. CAPABILITY Response . . . . . . . . . . . . . . . . . 98
7.2.3. LIST Response . . . . . . . . . . . . . . . . . . . . 97 7.2.3. LIST Response . . . . . . . . . . . . . . . . . . . . 99
7.2.4. NAMESPACE Response . . . . . . . . . . . . . . . . . 101 7.2.4. NAMESPACE Response . . . . . . . . . . . . . . . . . 102
7.2.5. STATUS Response . . . . . . . . . . . . . . . . . . . 101 7.2.5. STATUS Response . . . . . . . . . . . . . . . . . . . 102
7.2.6. ESEARCH Response . . . . . . . . . . . . . . . . . . 101 7.2.6. ESEARCH Response . . . . . . . . . . . . . . . . . . 103
7.2.7. FLAGS Response . . . . . . . . . . . . . . . . . . . 102 7.2.7. FLAGS Response . . . . . . . . . . . . . . . . . . . 103
7.3. Server Responses - Mailbox Size . . . . . . . . . . . . . 102 7.3. Server Responses - Mailbox Size . . . . . . . . . . . . . 104
7.3.1. EXISTS Response . . . . . . . . . . . . . . . . . . . 102 7.3.1. EXISTS Response . . . . . . . . . . . . . . . . . . . 104
7.4. Server Responses - Message Status . . . . . . . . . . . . 103 7.4. Server Responses - Message Status . . . . . . . . . . . . 104
7.4.1. EXPUNGE Response . . . . . . . . . . . . . . . . . . 103 7.4.1. EXPUNGE Response . . . . . . . . . . . . . . . . . . 104
7.4.2. FETCH Response . . . . . . . . . . . . . . . . . . . 104 7.4.2. FETCH Response . . . . . . . . . . . . . . . . . . . 105
7.5. Server Responses - Command Continuation Request . . . . . 109 7.5. Server Responses - Command Continuation Request . . . . . 111
8. Sample IMAP4rev2 connection . . . . . . . . . . . . . . . . . 110 8. Sample IMAP4rev2 connection . . . . . . . . . . . . . . . . . 111
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 111 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 112
10. Author's Note . . . . . . . . . . . . . . . . . . . . . . . . 128 10. Author's Note . . . . . . . . . . . . . . . . . . . . . . . . 129
11. Security Considerations . . . . . . . . . . . . . . . . . . . 128 11. Security Considerations . . . . . . . . . . . . . . . . . . . 129
11.1. STARTTLS Security Considerations . . . . . . . . . . . . 128 11.1. STARTTLS Security Considerations . . . . . . . . . . . . 129
11.2. COPYUID and APPENDUID response codes . . . . . . . . . . 129 11.2. COPYUID and APPENDUID response codes . . . . . . . . . . 130
11.3. LIST command and Other Users' namespace . . . . . . . . 129 11.3. LIST command and Other Users' namespace . . . . . . . . 130
11.4. Other Security Considerations . . . . . . . . . . . . . 129 11.4. Other Security Considerations . . . . . . . . . . . . . 130
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 130 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 131
12.1. Updates to IMAP4 Capabilities registry . . . . . . . . . 130 12.1. Updates to IMAP4 Capabilities registry . . . . . . . . . 131
12.2. GSSAPI/SASL service name . . . . . . . . . . . . . . . . 131 12.2. GSSAPI/SASL service name . . . . . . . . . . . . . . . . 132
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 131 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 132
13.1. Normative References . . . . . . . . . . . . . . . . . . 131 13.1. Normative References . . . . . . . . . . . . . . . . . . 132
13.2. Informative References (related protocols) . . . . . . . 134 13.2. Informative References (related protocols) . . . . . . . 135
13.3. Informative References (historical aspects of IMAP and 13.3. Informative References (historical aspects of IMAP and
related protocols) . . . . . . . . . . . . . . . . . . . 135 related protocols) . . . . . . . . . . . . . . . . . . . 136
Appendix A. Backward compatibility with IMAP4rev1 . . . . . . . 136 Appendix A. Backward compatibility with IMAP4rev1 . . . . . . . 137
A.1. Mailbox International Naming Convention for compatibility A.1. Mailbox International Naming Convention for compatibility
with IMAP4rev1 . . . . . . . . . . . . . . . . . . . . . 136 with IMAP4rev1 . . . . . . . . . . . . . . . . . . . . . 137
Appendix B. Backward compatibility with BINARY extension . . . . 138 Appendix B. Backward compatibility with BINARY extension . . . . 139
Appendix C. Changes from RFC 3501 / IMAP4rev1 . . . . . . . . . 138 Appendix C. Changes from RFC 3501 / IMAP4rev1 . . . . . . . . . 139
Appendix D. Acknowledgement . . . . . . . . . . . . . . . . . . 140 Appendix D. Acknowledgement . . . . . . . . . . . . . . . . . . 141
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 146 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 147
1. How to Read This Document 1. How to Read This Document
1.1. Organization of This Document 1.1. Organization of This Document
This document is written from the point of view of the implementor of This document is written from the point of view of the implementor of
an IMAP4rev2 client or server. Beyond the protocol overview in an IMAP4rev2 client or server. Beyond the protocol overview in
section 2, it is not optimized for someone trying to understand the section 2, it is not optimized for someone trying to understand the
operation of the protocol. The material in sections 3 through 5 operation of the protocol. The material in sections 3 through 5
provides the general context and definitions with which IMAP4rev2 provides the general context and definitions with which IMAP4rev2
skipping to change at page 6, line 35 skipping to change at page 6, line 35
IMAP implementation recommendations document [IMAP-IMPLEMENTATION] in IMAP implementation recommendations document [IMAP-IMPLEMENTATION] in
conjunction with this document, to help understand the intricacies of conjunction with this document, to help understand the intricacies of
this protocol and how best to build an interoperable product. this protocol and how best to build an interoperable product.
IMAP4rev2 is designed to be upwards compatible from the [IMAP2] and IMAP4rev2 is designed to be upwards compatible from the [IMAP2] and
unpublished IMAP2bis protocols. IMAP4rev2 is largely compatible with unpublished IMAP2bis protocols. IMAP4rev2 is largely compatible with
the IMAP4rev1 protocol described in RFC 3501 and the IMAP4 protocol the IMAP4rev1 protocol described in RFC 3501 and the IMAP4 protocol
described in RFC 1730; the exception being in certain facilities described in RFC 1730; the exception being in certain facilities
added in RFC 1730 that proved problematic and were subsequently added in RFC 1730 that proved problematic and were subsequently
removed. In the course of the evolution of IMAP4rev2, some aspects removed. In the course of the evolution of IMAP4rev2, some aspects
in the earlier protocols have become obsolete. Obsolete commands, in the earlier protocols have become obsolete.
responses, and data formats which an IMAP4rev2 implementation can
encounter when used with an earlier implementation are described in Obsolete commands, responses, and data formats which an IMAP4rev2
[IMAP-OBSOLETE]. implementation can encounter when used with an earlier implementation
are described in [IMAP-OBSOLETE].
Other compatibility issues with IMAP2bis, the most common variant of Other compatibility issues with IMAP2bis, the most common variant of
the earlier protocol, are discussed in [IMAP-COMPAT]. A full the earlier protocol, are discussed in [IMAP-COMPAT]. A full
discussion of compatibility issues with rare (and presumed extinct) discussion of compatibility issues with rare (and presumed extinct)
variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is
primarily of historical interest. primarily of historical interest.
IMAP was originally developed for the older [RFC-822] standard, and IMAP was originally developed for the older [RFC-822] standard, and
as a consequence several fetch items in IMAP incorporate "RFC822" in as a consequence several fetch items in IMAP incorporate "RFC822" in
their name. With the exception of RFC822.SIZE, there are more modern their name. With the exception of RFC822.SIZE, there are more modern
skipping to change at page 10, line 50 skipping to change at page 10, line 50
this case is a 32-bit representation of the creation date/time this case is a 32-bit representation of the creation date/time
of the mailbox. It is alright to use a constant such as 1, of the mailbox. It is alright to use a constant such as 1,
but only if it guaranteed that unique identifiers will never but only if it guaranteed that unique identifiers will never
be reused, even in the case of a mailbox being deleted (or be reused, even in the case of a mailbox being deleted (or
renamed) and a new mailbox by the same name created at some renamed) and a new mailbox by the same name created at some
future time. future time.
4. The combination of mailbox name, UIDVALIDITY, and UID must 4. The combination of mailbox name, UIDVALIDITY, and UID must
refer to a single immutable message on that server forever. refer to a single immutable message on that server forever.
In particular, the internal date, [RFC-5322] size, envelope, In particular, the internal date, [RFC-5322] size, envelope,
body structure, and message texts (RFC822, RFC822.HEADER, body structure, and message texts (all BODY[...] fetch data
RFC822.TEXT, and all BODY[...] fetch data items) must never items) must never change. This does not include message
change. This does not include message numbers, nor does it numbers, nor does it include attributes that can be set by a
include attributes that can be set by a STORE command (e.g., STORE command (e.g., FLAGS).
FLAGS).
2.3.1.2. Message Sequence Number Message Attribute 2.3.1.2. Message Sequence Number Message Attribute
A relative position from 1 to the number of messages in the mailbox. A relative position from 1 to the number of messages in the mailbox.
This position MUST be ordered by ascending unique identifier. As This position MUST be ordered by ascending unique identifier. As
each new message is added, it is assigned a message sequence number each new message is added, it is assigned a message sequence number
that is 1 higher than the number of messages in the mailbox before that is 1 higher than the number of messages in the mailbox before
that new message was added. that new message was added.
Message sequence numbers can be reassigned during the session. For Message sequence numbers can be reassigned during the session. For
skipping to change at page 11, line 41 skipping to change at page 11, line 40
messages which have greater UIDs. messages which have greater UIDs.
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 "\".
\Seen) have special semantics described elsewhere in this document.
The currently-defined system flags are: Certain system flags (\Deleted and \Seen) have special semantics
described elsewhere in this document. The currently-defined system
flags are:
\Seen Message has been read \Seen Message has been read
\Answered Message has been answered \Answered Message has been answered
\Flagged Message is "flagged" for urgent/special attention \Flagged Message is "flagged" for urgent/special attention
\Deleted Message is "deleted" for removal by later EXPUNGE \Deleted Message is "deleted" for removal by later EXPUNGE
\Draft Message has not completed composition (marked as a draft). \Draft Message has not completed composition (marked as a draft).
\Recent This flag was in used in IMAP4rev1 and is now deprecated. \Recent This flag was in used in IMAP4rev1 and is now deprecated.
A keyword is defined by the server implementation. Keywords do not A keyword is defined by the server implementation. Keywords do not
begin with "\". Servers MAY permit the client to define new keywords begin with "\". Servers MAY permit the client to define new keywords
in the mailbox (see the description of the PERMANENTFLAGS response in the mailbox (see the description of the PERMANENTFLAGS response
code for more information). Some keywords that start with "$" are code for more information). Some keywords that start with "$" are
also defined in this specification. also defined in this specification.
skipping to change at page 12, line 26 skipping to change at page 12, line 28
implementations. These keywords SHOULD be supported (i.e. allowed in implementations. These keywords SHOULD be supported (i.e. allowed in
APPEND, COPY, MOVE and SEARCH commands) by server implementations: 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.
$Forwarded
$Forwarded
$MDNSent Message Disposition Notification [RFC8098] was generated $MDNSent Message Disposition Notification [RFC8098] was generated
and sent for this message. and sent for this message.
$MDNSent
A flag can be permanent or session-only on a per-flag basis. A flag can be permanent or session-only on a per-flag basis.
Permanent flags are those which the client can add or remove from the Permanent flags are those which the client can add or remove from the
message flags permanently; that is, concurrent and subsequent message flags permanently; that is, concurrent and subsequent
sessions will see any change in permanent flags. Changes to session sessions will see any change in permanent flags. Changes to session
flags are valid only in that session. flags are valid only in that session.
2.3.3. Internal Date Message Attribute 2.3.3. Internal Date Message Attribute
The internal date and time of the message on the server. This is not The internal date and time of the message on the server. This is not
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
skipping to change at page 32, line 25 skipping to change at page 32, line 25
Several IMAP extensions allow the server to return unsolicited Several IMAP extensions allow the server to return unsolicited
responses specific to these extensions in certain circumstances. responses specific to these extensions in certain circumstances.
However, servers cannot send those unsolicited responses (with the However, servers cannot send those unsolicited responses (with the
exception of response codes (see Section 7.1) included in tagged or exception of response codes (see Section 7.1) included in tagged or
untagged OK/NO/BAD responses, which can always be sent) until they untagged OK/NO/BAD responses, which can always be sent) until they
know that the clients support such extensions and thus won't choke on know that the clients support such extensions and thus won't choke on
the extension response data. the extension response data.
The ENABLE command provides an explicit indication from the client The ENABLE command provides an explicit indication from the client
that it supports particular extensions. that it supports particular extensions. It is designed such that the
client can send a simple constant string with the extensions it
supports, and the server will enable the shared subset that both
support.
The ENABLE command takes a list of capability names, and requests the The ENABLE command takes a list of capability names, and requests the
server to enable the named extensions. Once enabled using ENABLE, server to enable the named extensions. Once enabled using ENABLE,
each extension remains active until the IMAP connection is closed. each extension remains active until the IMAP connection is closed.
For each argument, the server does the following: For each argument, the server does the following:
o If the argument is not an extension known to the server, the o If the argument is not an extension known to the server, the
server MUST ignore the argument. server MUST ignore the argument.
o If the argument is an extension known to the server, and it is not o If the argument is an extension known to the server, and it is not
skipping to change at page 34, line 37 skipping to change at page 34, line 46
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.
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.
client can not make any assumptions about the next unique
identifier value. OK [UIDNEXT <n>] If this is missing, the client can not make any
assumptions about the next unique identifier value.
OK [UIDVALIDITY <n>] The unique identifier validity value. Refer to OK [UIDVALIDITY <n>] The unique identifier validity 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
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
skipping to change at page 42, line 49 skipping to change at page 42, line 49
hierarchy delimiter (or find out that the mailbox names are flat) hierarchy delimiter (or find out that the mailbox names are flat)
even when no mailboxes by that name currently exist. even when no mailboxes by that name currently exist.
In the extended syntax, any mailbox name arguments that are empty In the extended syntax, any mailbox name arguments that are empty
strings are ignored. There is no special meaning for empty mailbox strings are ignored. There is no special meaning for empty mailbox
names when the extended syntax is used. names when the extended syntax is used.
The reference and mailbox name arguments are interpreted into a The reference and mailbox name arguments are interpreted into a
canonical form that represents an unambiguous left-to-right canonical form that represents an unambiguous left-to-right
hierarchy. The returned mailbox names will be in the interpreted hierarchy. The returned mailbox names will be in the interpreted
form, that we call "canonical LIST pattern" later in this document. form,
To define the term "canonical LIST pattern" formally: it refers to
the canonical pattern constructed internally by the server from the that we call "canonical LIST pattern" later in this document. To
define the term "canonical LIST pattern" formally: it refers to the
canonical pattern constructed internally by the server from the
reference and mailbox name arguments. reference and mailbox name arguments.
Note: The interpretation of the reference argument is Note: The interpretation of the reference argument is
implementation-defined. It depends upon whether the server implementation-defined. It depends upon whether the server
implementation has a concept of the "current working directory" implementation has a concept of the "current working directory"
and leading "break out characters", which override the current and leading "break out characters", which override the current
working directory. working directory.
For example, on a server which exports a UNIX or NT filesystem, For example, on a server which exports a UNIX or NT filesystem,
the reference argument contains the current working directory, and the reference argument contains the current working directory, and
skipping to change at page 46, line 5 skipping to change at page 46, line 5
The selection options defined in this specification are as follows: The selection options defined in this specification are as follows:
SUBSCRIBED - causes the LIST command to list subscribed names, SUBSCRIBED - causes the LIST command to list subscribed names,
rather than the existing mailboxes. This will often be a subset rather than the existing mailboxes. This will often be a subset
of the actual mailboxes. It's also possible for this list to of the actual mailboxes. It's also possible for this list to
contain the names of mailboxes that don't exist. In any case, the contain the names of mailboxes that don't exist. In any case, the
list MUST include exactly those mailbox names that match the list MUST include exactly those mailbox names that match the
canonical list pattern and are subscribed to. canonical list pattern and are subscribed to.
SUBSCRIBED -
This option defines a mailbox attribute, "\Subscribed", that This option defines a mailbox attribute, "\Subscribed", that
indicates that a mailbox name is subscribed to. The "\Subscribed" indicates that a mailbox name is subscribed to. The "\Subscribed"
attribute MUST be supported and MUST be accurately computed when attribute MUST be supported and MUST be accurately computed when
the SUBSCRIBED selection option is specified. the SUBSCRIBED selection option is specified.
Note that the SUBSCRIBED selection option implies the SUBSCRIBED Note that the SUBSCRIBED selection option implies the SUBSCRIBED
return option (see below). return option (see below).
REMOTE - causes the LIST command to show remote mailboxes as well as REMOTE - causes the LIST command to show remote mailboxes as well as
local ones, as described in [RFC2193]. This option is intended to local ones, as described in [RFC2193]. This option is intended to
skipping to change at page 47, line 20 skipping to change at page 47, line 24
The return options defined in this specification are as follows: The return options defined in this specification are as follows:
SUBSCRIBED - causes the LIST command to return subscription state SUBSCRIBED - causes the LIST command to return subscription state
for all matching mailbox names. The "\Subscribed" attribute MUST for all matching mailbox names. The "\Subscribed" attribute MUST
be supported and MUST be accurately computed when the SUBSCRIBED be supported and MUST be accurately computed when the SUBSCRIBED
return option is specified. Further, all mailbox flags MUST be return option is specified. Further, all mailbox flags MUST be
accurately computed (this differs from the behavior of the accurately computed (this differs from the behavior of the
obsolete LSUB command from IMAP4rev1). obsolete LSUB command from IMAP4rev1).
CHILDREN - requests mailbox child information as originally proposed CHILDREN - requests mailbox child information as originally proposed
in [RFC3348]. See Section 6.3.9.4, below, for details. This in [RFC3348]. See Section 6.3.9.4, below, for details.
option MUST be supported by all servers.
CHILDREN - This option MUST be supported by all servers.
6.3.9.3. General Principles for Returning LIST Responses 6.3.9.3. General Principles for Returning LIST Responses
This section outlines several principles that can be used by server This section outlines several principles that can be used by server
implementations of this document to decide whether a LIST response implementations of this document to decide whether a LIST response
should be returned, as well as how many responses and what kind of should be returned, as well as how many responses and what kind of
information they may contain. information they may contain.
1. At most one LIST response should be returned for each mailbox 1. At most one LIST response should be returned for each mailbox
name that matches the canonical LIST pattern. Server name that matches the canonical LIST pattern. Server
skipping to change at page 58, line 15 skipping to change at page 58, line 15
NO - Can't complete the command NO - Can't complete the command
BAD - arguments invalid BAD - arguments invalid
The NAMESPACE command causes a single ungagged NAMESPACE response to The NAMESPACE command causes a single ungagged NAMESPACE response to
be returned. The untagged NAMESPACE response contains the prefix and be returned. The untagged NAMESPACE response contains the prefix and
hierarchy delimiter to the server's Personal Namespace(s), Other hierarchy delimiter to the server's Personal Namespace(s), Other
Users' Namespace(s), and Shared Namespace(s) that the server wishes Users' Namespace(s), and Shared Namespace(s) that the server wishes
to expose. The response will contain a NIL for any namespace class to expose. The response will contain a NIL for any namespace class
that is not available. Namespace-Response-Extensions ABNF non that is not available. Namespace-Response-Extensions ABNF non
terminal is defined for extensibility and MAY be included in the terminal is defined for extensibility and MAY be included in the
response. Namespace-Response-Extensions which are not on the IETF response.
standards track, MUST be prefixed with an "X-".
Namespace-Response-Extensions which are not on the IETF standards
track, MUST be prefixed with an "X-".
Example 1: Example 1:
In this example a server supports a single personal namespace. No In this example a server supports a single personal namespace. No
leading prefix is used on personal mailboxes and "/" is the hierarchy leading prefix is used on personal mailboxes and "/" is the hierarchy
delimiter. delimiter.
C: A001 NAMESPACE C: A001 NAMESPACE
S: * NAMESPACE (("" "/")) NIL NIL S: * NAMESPACE (("" "/")) NIL NIL
S: A001 OK NAMESPACE command completed S: A001 OK NAMESPACE command completed
skipping to change at page 63, line 26 skipping to change at page 63, line 26
MESSAGES The number of messages in the mailbox. MESSAGES The number of messages in the mailbox.
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.
DELETED The number of messages which have the \Deleted 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
than the sum of the values of the RFC822.SIZE FETCH message data than the sum of the values of the RFC822.SIZE FETCH message data
items (see Section 6.4.5) of all messages in the mailbox. items (see Section 6.4.5) of all messages in the mailbox.
SIZE
Example: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES) Example: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES)
S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292) S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
S: A042 OK STATUS completed S: A042 OK STATUS completed
6.3.12. APPEND Command 6.3.12. APPEND Command
Arguments: mailbox name Arguments: mailbox name
OPTIONAL flag parenthesized list OPTIONAL flag parenthesized list
OPTIONAL date/time string OPTIONAL date/time string
message literal message literal
skipping to change at page 66, line 39 skipping to change at page 67, line 18
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
Without the IDLE command a client requires to poll the server for Without the IDLE command a client requires to poll the server for
changes to the selected mailbox (new mail, deletions, flag changes). changes to the selected mailbox (new mail, deletions, flag changes).
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
server requests a response to the IDLE command using the continuation
("+") response. The IDLE command remains active until the client update messages. The server requests a response to the IDLE command
responds to the continuation, and as long as an IDLE command is using the continuation ("+") response. The IDLE command remains
active, the server is now free to send untagged EXISTS, EXPUNGE, active until the client responds to the continuation, and as long as
FETCH, and other responses at any time. If the server choose to send an IDLE command is active, the server is now free to send untagged
unsolicited FETCH responses, they MUST include UID FETCH item. EXISTS, EXPUNGE, 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 for other commands, the processing of any new command commands. As for other commands, the processing of any new command
may cause the sending of unsolicited untagged responses, subject to may cause the sending of unsolicited untagged responses, subject to
the ambiguity limitations. The client MUST NOT send a command while the ambiguity limitations. The client MUST NOT send a command while
the server is waiting for the DONE, since the server will not be able the server is waiting for the DONE, since the server will not be able
skipping to change at page 70, line 14 skipping to change at page 70, line 44
criteria criteria
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
The SEARCH command searches the mailbox for messages that match the The SEARCH command searches the mailbox for messages that match the
given searching criteria. given searching criteria.
The SEARCH command may contain result options. Result options The SEARCH command may contain result options. Result options
control what kind of information is returned about messages matching control what kind of information is returned about messages matching
the search criteria in an untagged ESEARCH response. If no result the search criteria in an untagged ESEARCH response. If no result
option is specified or empty list of options is specified "()", ALL option is specified or empty list of options is specified "()", ALL
is assumed (see below). The order of individual options is is assumed (see below).
arbitrary. Individual options may contain parameters enclosed in
parentheses (*). If an option has parameters, they consist of atoms The order of individual options is arbitrary. Individual options may
and/or strings and/or lists in a specific order. Any options not contain parameters enclosed in parentheses (*). If an option has
defined by extensions that the server supports must be rejected with parameters, they consist of atoms and/or strings and/or lists in a
a BAD response. specific order. Any options not defined by extensions that the
server supports must be rejected with a BAD response.
(*) - if an option has a mandatory parameter, which can always be (*) - if an option has a mandatory parameter, which can always be
represented as a number or a sequence-set, the option parameter does represented as a number or a sequence-set, the option parameter does
not need the enclosing (). See ABNF for more details. not need the enclosing (). See ABNF for more details.
This document specifies the following result options: This document specifies the following result options:
MIN MIN
Return the lowest message number/UID that satisfies the SEARCH Return the lowest message number/UID that satisfies the SEARCH
skipping to change at page 71, line 16 skipping to change at page 71, line 47
include the ALL result option in the ESEARCH response; however, include the ALL result option in the ESEARCH response; however,
it still MUST send the ESEARCH response. it still MUST send the ESEARCH response.
COUNT Return number of the messages that satisfy the SEARCH COUNT Return number of the messages that satisfy the SEARCH
criteria. This result option MUST always be included in the criteria. This result option MUST always be included in the
ESEARCH response. ESEARCH response.
Note: future extensions to this document can allow servers to return Note: future extensions to this document can allow servers to return
multiple ESEARCH responses for a single extended SEARCH command. multiple ESEARCH responses for a single extended SEARCH command.
However all options specified above MUST result in a single ESEARCH However all options specified above MUST result in a single ESEARCH
response. These extensions will have to describe how results from response.
multiple ESEARCH responses are to be amalgamated.
These extensions will have to describe how results from multiple
ESEARCH responses are to be amalgamated.
Searching criteria consist of one or more search keys. Searching criteria consist of one or more search keys.
When multiple keys are specified, the result is the intersection (AND When multiple keys are specified, the result is the intersection (AND
function) of all the messages that match those keys. For example, function) of all the messages that match those keys. For example,
the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers to all the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers to all
deleted messages from Smith that were placed in the mailbox since deleted messages from Smith that were placed in the mailbox since
February 1, 1994. A search key can also be a parenthesized list of February 1, 1994. A search key can also be a parenthesized list of
one or more search keys (e.g., for use with the OR and NOT keys). one or more search keys (e.g., for use with the OR and NOT keys).
Server implementations MAY exclude [MIME-IMB] body parts with Server implementations MAY exclude [MIME-IMB] body parts with
terminal content media types other than TEXT and MESSAGE from terminal content media types other than TEXT and MESSAGE from
consideration in SEARCH matching. consideration in SEARCH matching.
The OPTIONAL [CHARSET] specification consists of the word "CHARSET" The OPTIONAL [CHARSET] specification consists of the word "CHARSET"
followed by a registered [CHARSET]. It indicates the [CHARSET] of followed by a registered [CHARSET]. It indicates the [CHARSET] of
the strings that appear in the search criteria. [MIME-IMB] content the strings that appear in the search criteria. [MIME-IMB] content
transfer encodings, and [MIME-HDRS] strings in [RFC-5322]/[MIME-IMB] transfer encodings, and [MIME-HDRS] strings in [RFC-5322]/[MIME-IMB]
headers, MUST be decoded before comparing text. US-ASCII and UTF-8 headers, MUST be decoded before comparing text. Servers MUST support
charsets MUST be supported; other [CHARSET]s MAY be supported. If US-ASCII and UTF-8 charsets; other [CHARSET]s MAY be supported.
"CHARSET" is not provided, an IMAP4rev2 server MUST assume UTF-8. Clients SHOULD use UTF-8. Note that if "CHARSET" is not provided
IMAP4rev2 server MUST assume UTF-8, so selecting CHARSET UTF-8 is
redundant. It is permitted for improved compatibility with existing
IMAP4rev1 clients.
If the server does not support the specified [CHARSET], it MUST If the server does not support the specified [CHARSET], it MUST
return a tagged NO response (not a BAD). This response SHOULD return a tagged NO response (not a BAD). This response SHOULD
contain the BADCHARSET response code, which MAY list the [CHARSET]s contain the BADCHARSET response code, which MAY list the [CHARSET]s
supported by the server. supported by the server.
In all search keys that use strings, a message matches the key if the In all search keys that use strings, a message matches the key if the
string is a substring of the associated text. The matching SHOULD be string is a substring of the associated text. The matching SHOULD be
case-insensitive for characters within ASCII range. Consider using case-insensitive for characters within ASCII range. Consider using
[IMAP-I18N] for language-sensitive case-insensitive searching. Note [IMAP-I18N] for language-sensitive case-insensitive searching. Note
that the empty string is a substring; this is useful when doing a that the empty string is a substring; this is useful when doing a
HEADER search in order to test for a header field presence in the HEADER search in order to test for a header field presence in the
message. message.
The defined search keys are as follows. Refer to the Formal Syntax The defined search keys are as follows. Refer to the Formal Syntax
section for the precise syntactic definitions of the arguments. section for the precise syntactic definitions of the arguments.
<sequence set>
<sequence set> Messages with message sequence numbers corresponding <sequence set> Messages with message sequence numbers corresponding
to the specified message sequence number set. to the specified message sequence number set.
ALL All messages in the mailbox; the default initial key for ANDing. ALL All messages in the mailbox; the default initial key for ANDing.
ANSWERED Messages with the \Answered flag set. ANSWERED Messages with the \Answered flag set.
BCC <string> Messages that contain the specified string in the BCC <string> Messages that contain the specified string in the
envelope structure's BCC field. envelope structure's BCC field.
skipping to change at page 72, line 42 skipping to change at page 73, line 32
FLAGGED Messages with the \Flagged flag set. FLAGGED Messages with the \Flagged flag set.
FROM <string> Messages that contain the specified string in the FROM <string> Messages that contain the specified string in the
envelope structure's FROM field. envelope structure's FROM field.
HEADER <field-name> <string> Messages that have a header with the HEADER <field-name> <string> Messages that have a header with the
specified field-name (as defined in [RFC-5322]) and that contains specified field-name (as defined in [RFC-5322]) and that contains
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. Servers should use substring search
for this SEARCH item, as clients can use it for automatic
processing not initiated by end users. For example this can be
used for searching for Message-ID or Content-Type header field
values that need to be exact, or for searches in header fields
that the IMAP server might not know anything about.
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 [[Fix this]] Messages that have the \Recent flag set but not the
\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.
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.
SEEN Messages that have the \Seen flag set. SEEN Messages that have the \Seen flag set.
skipping to change at page 78, line 42 skipping to change at page 79, line 38
the [RFC-5322] header and [MIME-IMB] headers. the [RFC-5322] header and [MIME-IMB] headers.
ENVELOPE The envelope structure of the message. This is computed by ENVELOPE The envelope structure of the message. This is computed by
the server by parsing the [RFC-5322] header into the component the server by parsing the [RFC-5322] header into the component
parts, defaulting various fields as necessary. parts, defaulting various fields as necessary.
FLAGS The flags that are set for this message. FLAGS The flags that are set for this message.
INTERNALDATE The internal date of the message. INTERNALDATE The internal date of the message.
RFC822 Functionally equivalent to BODY[], differing in the syntax of
the resulting untagged FETCH data (RFC822 is returned). This
FETCH item is deprecated and will be removed in the next revision
of this document.
RFC822.HEADER Functionally equivalent to BODY.PEEK[HEADER],
differing in the syntax of the resulting untagged FETCH data
(RFC822.HEADER is returned). This FETCH item is deprecated and
will be removed in the next revision of this document.
RFC822.SIZE The [RFC-5322] size of the message. RFC822.SIZE The [RFC-5322] size of the message.
RFC822.TEXT Functionally equivalent to BODY[TEXT], differing in the
syntax of the resulting untagged FETCH data (RFC822.TEXT is
returned). This FETCH item is deprecated and will be removed in
the next revision of this document.
UID The unique identifier for the message. UID The unique identifier for the message.
Example: C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)]) Example: C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)])
S: * 2 FETCH .... S: * 2 FETCH ....
S: * 3 FETCH .... S: * 3 FETCH ....
S: * 4 FETCH .... S: * 4 FETCH ....
S: A654 OK FETCH completed S: A654 OK FETCH completed
6.4.6. STORE Command 6.4.6. STORE Command
skipping to change at page 87, line 12 skipping to change at page 87, line 44
Status responses MAY include an OPTIONAL "response code". A response Status responses MAY include an OPTIONAL "response code". A response
code consists of data inside square brackets in the form of an atom, code consists of data inside square brackets in the form of an atom,
possibly followed by a space and arguments. The response code possibly followed by a space and arguments. The response code
contains additional information or status codes for client software contains additional information or status codes for client software
beyond the OK/NO/BAD condition, and are defined when there is a beyond the OK/NO/BAD condition, and are defined when there is a
specific action that a client can take based upon the additional specific action that a client can take based upon the additional
information. information.
The currently defined response codes are: The currently defined response codes are:
ALERT The human-readable text contains a special alert that MUST be ALERT
presented to the user in a fashion that calls the user's attention
to the message.
ALREADYEXISTS The human-readable text contains a special alert that MUST be
presented to the user in a fashion that calls the user's
attention to the message.
ALREADYEXISTS
The operation attempts to create something that already exists, The operation attempts to create something that already exists,
such as when the CREATE or RENAME directories attempt to create such as when the CREATE or RENAME directories attempt to create
a mailbox and there is already one of that name. a mailbox and there is already one of that name.
C: o RENAME this that C: o RENAME this that
S: o NO [ALREADYEXISTS] Mailbox "that" already exists S: o NO [ALREADYEXISTS] Mailbox "that" already exists
APPENDUID APPENDUID
Followed by the UIDVALIDITY of the destination mailbox and the Followed by the UIDVALIDITY of the destination mailbox and the
skipping to change at page 88, line 22 skipping to change at page 89, line 8
user" and "bad password". user" and "bad password".
This is the same as not sending any response code, except that This is the same as not sending any response code, except that
when a client sees AUTHENTICATIONFAILED, it knows that the when a client sees AUTHENTICATIONFAILED, it knows that the
problem wasn't, e.g., UNAVAILABLE, so there's no point in problem wasn't, e.g., UNAVAILABLE, so there's no point in
trying the same login/password again later. trying the same login/password again later.
C: b LOGIN "fred" "foo" C: b LOGIN "fred" "foo"
S: b NO [AUTHENTICATIONFAILED] Authentication failed S: b NO [AUTHENTICATIONFAILED] Authentication failed
AUTHORIZATIONFAILED Authentication succeeded in using the AUTHORIZATIONFAILED
authentication identity, but the server cannot or will not allow
the authentication identity to act as the requested authorization
identity. This is only applicable when the authentication and
authorization identities are different. C: c1 AUTHENTICATE PLAIN
[...]
S: c1 NO [AUTHORIZATIONFAILED] No such authorization-ID
C: c2 AUTHENTICATE PLAIN
[...]
S: c2 NO [AUTHORIZATIONFAILED] Authenticator is not an admin
BADCHARSET Optionally followed by a parenthesized list of charsets. Authentication succeeded in using the authentication identity,
A SEARCH failed because the given charset is not supported by this but the server cannot or will not allow the authentication
implementation. If the optional list of charsets is given, this identity to act as the requested authorization identity. This
lists the charsets that are supported by this implementation. is only applicable when the authentication and authorization
identities are different.
C: c1 AUTHENTICATE PLAIN
[...]
S: c1 NO [AUTHORIZATIONFAILED] No such authorization-ID
C: c2 AUTHENTICATE PLAIN
[...]
S: c2 NO [AUTHORIZATIONFAILED] Authenticator is not an admin
BADCHARSET
Optionally followed by a parenthesized list of charsets. A
SEARCH failed because the given charset is not supported by
this implementation. If the optional list of charsets is
given, this lists the charsets that are supported by this
implementation.
CANNOT CANNOT
The operation violates some invariant of the server and can The operation violates some invariant of the server and can
never succeed. never succeed.
C: l create "///////" C: l create "///////"
S: l NO [CANNOT] Adjacent slashes are not supported S: l NO [CANNOT] Adjacent slashes are not supported
CAPABILITY Followed by a list of capabilities. This can appear in CAPABILITY
the initial OK or PREAUTH response to transmit an initial
capabilities list. It can also appear in tagged responses to
LOGIN or AUTHENTICATE commands. This makes it unnecessary for a
client to send a separate CAPABILITY command if it recognizes this
response.
CLIENTBUG Followed by a list of capabilities. This can appear in the
initial OK or PREAUTH response to transmit an initial
capabilities list. It can also appear in tagged responses to
LOGIN or AUTHENTICATE commands. This makes it unnecessary for
a client to send a separate CAPABILITY command if it recognizes
this response.
CLIENTBUG
The server has detected a client bug. This can accompany all The server has detected a client bug. This can accompany all
of OK, NO, and BAD, depending on what the client bug is. of OK, NO, and BAD, depending on what the client bug is.
C: k1 select "/archive/projects/experiment-iv" C: k1 select "/archive/projects/experiment-iv"
[...] [...]
S: k1 OK [READ-ONLY] Done S: k1 OK [READ-ONLY] Done
C: k2 status "/archive/projects/experiment-iv" (messages) C: k2 status "/archive/projects/experiment-iv" (messages)
[...] [...]
S: k2 OK [CLIENTBUG] Done S: k2 OK [CLIENTBUG] Done
skipping to change at page 90, line 47 skipping to change at page 91, line 45
C: d login "fred" "foo" C: d login "fred" "foo"
S: d NO [EXPIRED] That password isn't valid any more S: d NO [EXPIRED] That password isn't valid any more
EXPUNGEISSUED EXPUNGEISSUED
Someone else has issued an EXPUNGE for the same mailbox. The Someone else has issued an EXPUNGE for the same mailbox. The
client may want to issue NOOP soon. [IMAP-MULTIACCESS] client may want to issue NOOP soon. [IMAP-MULTIACCESS]
discusses this subject in depth. discusses this subject in depth.
C: h search from fred@example.com C: h search from fred@example.com
S: * SEARCH 1 2 3 5 8 13 21 42 S: * ESEARCH (TAG "h") ALL 1:3,5,8,13,21,42
S: h OK [EXPUNGEISSUED] Search completed S: h OK [EXPUNGEISSUED] Search completed
INUSE INUSE
An operation has not been carried out because it involves An operation has not been carried out because it involves
sawing off a branch someone else is sitting on. Someone else sawing off a branch someone else is sitting on. Someone else
may be holding an exclusive lock needed for this operation, or may be holding an exclusive lock needed for this operation, or
the operation may involve deleting a resource someone else is the operation may involve deleting a resource someone else is
using, typically a mailbox. using, typically a mailbox.
The operation may succeed if the client tries again later. The operation may succeed if the client tries again later.
C: g delete "/archive/projects/experiment-iv" C: g delete "/archive/projects/experiment-iv"
S: g NO [INUSE] Mailbox in use S: g NO [INUSE] Mailbox in use
skipping to change at page 92, line 4 skipping to change at page 92, line 49
The user would be over quota after the operation. (The user The user would be over quota after the operation. (The user
may or may not be over quota already.) may or may not be over quota already.)
Note that if the server sends OVERQUOTA but doesn't support the Note that if the server sends OVERQUOTA but doesn't support the
IMAP QUOTA extension defined by [RFC2087], then there is a IMAP QUOTA extension defined by [RFC2087], then there is a
quota, but the client cannot find out what the quota is. quota, but the client cannot find out what the quota is.
C: n1 uid copy 1:* oldmail C: n1 uid copy 1:* oldmail
S: n1 NO [OVERQUOTA] Sorry S: n1 NO [OVERQUOTA] Sorry
C: n2 uid copy 1:* oldmail C: n2 uid copy 1:* oldmail
S: n2 OK [OVERQUOTA] You are now over your soft quota S: n2 OK [OVERQUOTA] You are now over your soft quota
PARSE The human-readable text represents an error in parsing the PARSE
[RFC-5322] header or [MIME-IMB] headers of a message in the
mailbox.
PERMANENTFLAGS Followed by a parenthesized list of flags, indicates The human-readable text represents an error in parsing the
which of the known flags the client can change permanently. Any [RFC-5322] header or [MIME-IMB] headers of a message in the
flags that are in the FLAGS untagged response, but not the mailbox.
PERMANENTFLAGS list, can not be set permanently. The
PERMANENTFLAGS list can also include the special flag \*, which PERMANENTFLAGS
indicates that it is possible to create new keywords by attempting
to store those keywords in the mailbox. If the client attempts to Followed by a parenthesized list of flags, indicates which of
STORE a flag that is not in the PERMANENTFLAGS list, the server the known flags the client can change permanently. Any flags
will either ignore the change or store the state change for the that are in the FLAGS untagged response, but not the
remainder of the current session only. PERMANENTFLAGS list, can not be set permanently. The
There is no need for a server that included the special flag \* to PERMANENTFLAGS list can also include the special flag \*, which
return a new PERMANENTFLAGS response code when a new keyword was indicates that it is possible to create new keywords by
successfully set on a message upon client request. However if the attempting to store those keywords in the mailbox. If the
server has a limit on the number of different keywords that can be client attempts to STORE a flag that is not in the
stored in a mailbox and that limit is reached, the server MUST PERMANENTFLAGS list, the server will either ignore the change
send a new PERMANENTFLAGS response code without the special flag or store the state change for the remainder of the current
\*. session only.
There is no need for a server that included the special flag \*
to return a new PERMANENTFLAGS response code when a new keyword
was successfully set on a message upon client request. However
if the server has a limit on the number of different keywords
that can be stored in a mailbox and that limit is reached, the
server MUST send a new PERMANENTFLAGS response code without the
special flag \*.
PRIVACYREQUIRED PRIVACYREQUIRED
The operation is not permitted due to a lack of privacy. If The operation is not permitted due to a lack of privacy. If
Transport Layer Security (TLS) is not in use, the client could Transport Layer Security (TLS) is not in use, the client could
try STARTTLS (see Section 6.2.1) and then repeat the operation. try STARTTLS (see Section 6.2.1) and then repeat the operation.
C: d login "fred" "foo" C: d login "fred" "foo"
S: d NO [PRIVACYREQUIRED] Connection offers no privacy S: d NO [PRIVACYREQUIRED] Connection offers no privacy
C: d select inbox C: d select inbox
S: d NO [PRIVACYREQUIRED] Connection offers no privacy S: d NO [PRIVACYREQUIRED] Connection offers no privacy
READ-ONLY The mailbox is selected read-only, or its access while READ-ONLY
selected has changed from read-write to read-only.
READ-WRITE The mailbox is selected read-write, or its access while The mailbox is selected read-only, or its access while selected
selected has changed from read-only to read-write. has changed from read-write to read-only.
READ-WRITE
The mailbox is selected read-write, or its access while
selected has changed from read-only to read-write.
SERVERBUG SERVERBUG
The server encountered a bug in itself or violated one of its The server encountered a bug in itself or violated one of its
own invariants. own invariants.
C: j select "/archive/projects/experiment-iv" C: j select "/archive/projects/experiment-iv"
S: j NO [SERVERBUG] This should not happen S: j NO [SERVERBUG] This should not happen
TRYCREATE An APPEND or COPY attempt is failing because the target TRYCREATE
mailbox does not exist (as opposed to some other reason). This is
a hint to the client that the operation can succeed if the mailbox
is first created by the CREATE command.
UIDNEXT Followed by a decimal number, indicates the next unique An APPEND or COPY attempt is failing because the target mailbox
identifier value. Refer to Section 2.3.1.1 for more information. does not exist (as opposed to some other reason). This is a
hint to the client that the operation can succeed if the
mailbox is first created by the CREATE command.
UIDNEXT
Followed by a decimal number, indicates the next unique
identifier value. Refer to Section 2.3.1.1 for more
information.
UIDNOTSTICKY UIDNOTSTICKY
The selected mailbox is supported by a mail store that does not The selected mailbox is supported by a mail store that does not
support persistent UIDs; that is, UIDVALIDITY will be different support persistent UIDs; that is, UIDVALIDITY will be different
each time the mailbox is selected. Consequently, APPEND or each time the mailbox is selected. Consequently, APPEND or
COPY to this mailbox will not return an APPENDUID or COPYUID COPY to this mailbox will not return an APPENDUID or COPYUID
response code. response code.
This response code is returned in an untagged NO response to This response code is returned in an untagged NO response to
the SELECT command. the SELECT command.
Note: servers SHOULD NOT have any UIDNOTSTICKY mail stores. Note: servers SHOULD NOT have any UIDNOTSTICKY mail stores.
This facility exists to support legacy mail stores in which This facility exists to support legacy mail stores in which
it is technically infeasible to support persistent UIDs. it is technically infeasible to support persistent UIDs.
This should be avoided when designing new mail stores. This should be avoided when designing new mail stores.
UIDVALIDITY Followed by a decimal number, indicates the unique UIDVALIDITY
identifier validity value. Refer to Section 2.3.1.1 for more
information. Followed by a decimal number, indicates the unique identifier
validity value. Refer to Section 2.3.1.1 for more information.
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
skipping to change at page 101, line 21 skipping to change at page 102, line 35
Contents: the prefix and hierarchy delimiter to the server's Contents: the prefix and hierarchy delimiter to the server's
Personal Namespace(s), Other Users' Namespace(s), and Personal Namespace(s), Other Users' Namespace(s), and
Shared Namespace(s) Shared Namespace(s)
The NAMESPACE response occurs as a result of a NAMESPACE command. It The NAMESPACE response occurs as a result of a NAMESPACE command. It
contains the prefix and hierarchy delimiter to the server's Personal contains the prefix and hierarchy delimiter to the server's Personal
Namespace(s), Other Users' Namespace(s), and Shared Namespace(s) that Namespace(s), Other Users' Namespace(s), and Shared Namespace(s) that
the server wishes to expose. The response will contain a NIL for any the server wishes to expose. The response will contain a NIL for any
namespace class that is not available. Namespace-Response-Extensions namespace class that is not available. Namespace-Response-Extensions
ABNF non terminal is defined for extensibility and MAY be included in ABNF non terminal is defined for extensibility and MAY be included in
the response. Namespace-Response-Extensions which are not on the the response.
IETF standards track, MUST be prefixed with an "X-".
Namespace-Response-Extensions which are not on the IETF standards
track, MUST be prefixed with an "X-".
Example: S: * NAMESPACE (("" "/")) (("~" "/")) NIL Example: S: * NAMESPACE (("" "/")) (("~" "/")) NIL
7.2.5. STATUS Response 7.2.5. STATUS Response
Contents: name Contents: name
status parenthesized list status parenthesized list
The STATUS response occurs as a result of an STATUS command. It The STATUS response occurs as a result of an STATUS command. It
returns the mailbox name that matches the STATUS specification and returns the mailbox name that matches the STATUS specification and
skipping to change at page 106, line 23 skipping to change at page 107, line 43
Extension data follows the multipart subtype. Extension data Extension data follows the multipart subtype. Extension data
is never returned with the BODY fetch, but can be returned with is never returned with the BODY fetch, but can be returned with
a BODYSTRUCTURE fetch. Extension data, if present, MUST be in a BODYSTRUCTURE fetch. Extension data, if present, MUST be in
the defined order. The extension data of a multipart body part the defined order. The extension data of a multipart body part
are in the following order: are in the following order:
body parameter parenthesized list A parenthesized list of body parameter parenthesized list A parenthesized list of
attribute/value pairs [e.g., ("foo" "bar" "baz" "rag") where attribute/value pairs [e.g., ("foo" "bar" "baz" "rag") where
"bar" is the value of "foo", and "rag" is the value of "bar" is the value of "foo", and "rag" is the value of
"baz"] as defined in [MIME-IMB]. Servers SHOULD decode "baz"] as defined in [MIME-IMB].
body parameter parenthesized list Servers SHOULD decode
parameter value continuations as described in [RFC2231]. parameter value continuations as described in [RFC2231].
body disposition A parenthesized list, consisting of a body disposition A parenthesized list, consisting of a
disposition type string, followed by a parenthesized list of disposition type string, followed by a parenthesized list of
disposition attribute/value pairs as defined in disposition attribute/value pairs as defined in
[DISPOSITION]. Servers SHOULD decode parameter value [DISPOSITION]. Servers SHOULD decode parameter value
continuations as described in [RFC2231]. continuations as described in [RFC2231].
body language A string or parenthesized list giving the body body language A string or parenthesized list giving the body
language value as defined in [LANGUAGE-TAGS]. language value as defined in [LANGUAGE-TAGS].
skipping to change at page 109, line 28 skipping to change at page 110, line 49
this). this).
Note: [RFC-5322] requires that all messages have a valid Note: [RFC-5322] requires that all messages have a valid
From header. Therefore, the from, sender, and reply-to From header. Therefore, the from, sender, and reply-to
members in the envelope can not be NIL. members in the envelope can not be NIL.
FLAGS A parenthesized list of flags that are set for this message. FLAGS A parenthesized list of flags that are set for this message.
INTERNALDATE A string representing the internal date of the message. INTERNALDATE A string representing the internal date of the message.
RFC822 Equivalent to BODY[].
RFC822.HEADER Equivalent to BODY[HEADER]. Note that this did not
result in \Seen being set, because RFC822.HEADER response data
occurs as a result of a FETCH of RFC822.HEADER. BODY[HEADER]
response data occurs as a result of a FETCH of BODY[HEADER] (which
sets \Seen) or BODY.PEEK[HEADER] (which does not set \Seen).
RFC822.SIZE A number expressing the [RFC-5322] size of the message. RFC822.SIZE A number expressing the [RFC-5322] size of the message.
RFC822.TEXT Equivalent to BODY[TEXT].
UID A number expressing the unique identifier of the message. UID A number expressing the unique identifier of the message.
Example: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827) Example: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827)
7.5. Server Responses - Command Continuation Request 7.5. Server Responses - Command Continuation Request
The command continuation request response is indicated by a "+" token The command continuation request response is indicated by a "+" token
instead of a tag. This form of response indicates that the server is instead of a tag. This form of response indicates that the server is
ready to accept the continuation of a command from the client. The ready to accept the continuation of a command from the client. The
remainder of this response is a line of text. remainder of this response is a line of text.
skipping to change at page 117, line 28 skipping to change at page 118, line 28
fetch = "FETCH" SP sequence-set SP ("ALL" / "FULL" / "FAST" / fetch = "FETCH" SP sequence-set SP ("ALL" / "FULL" / "FAST" /
fetch-att / "(" fetch-att *(SP fetch-att) ")") fetch-att / "(" fetch-att *(SP fetch-att) ")")
fetch-att = "ENVELOPE" / "FLAGS" / "INTERNALDATE" / fetch-att = "ENVELOPE" / "FLAGS" / "INTERNALDATE" /
"RFC822.SIZE" / "RFC822.SIZE" /
"BODY" ["STRUCTURE"] / "UID" / "BODY" ["STRUCTURE"] / "UID" /
"BODY" section [partial] / "BODY" section [partial] /
"BODY.PEEK" section [partial] / "BODY.PEEK" section [partial] /
"BINARY" [".PEEK"] section-binary [partial] / "BINARY" [".PEEK"] section-binary [partial] /
"BINARY.SIZE" section-binary / "BINARY.SIZE" section-binary
fetch-att-deprecated
fetch-att-deprecated = "RFC822" [".HEADER" / .TEXT"]
flag = "\Answered" / "\Flagged" / "\Deleted" / flag = "\Answered" / "\Flagged" / "\Deleted" /
"\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 ; "\Recent" was defined in RFC 3501
; and is now deprecated. ; and is now deprecated.
flag-fetch = flag flag-fetch = flag
flag-keyword = "$MDNSent" / "$Forwarded" / atom flag-keyword = "$MDNSent" / "$Forwarded" / atom
flag-list = "(" [flag *(SP flag)] ")" flag-list = "(" [flag *(SP flag)] ")"
flag-perm = flag / "\*"
flag-perm = flag / "\*"
greeting = "*" SP (resp-cond-auth / resp-cond-bye) CRLF greeting = "*" SP (resp-cond-auth / resp-cond-bye) CRLF
header-fld-name = astring header-fld-name = astring
header-list = "(" header-fld-name *(SP header-fld-name) ")" header-list = "(" header-fld-name *(SP header-fld-name) ")"
idle = "IDLE" CRLF "DONE" idle = "IDLE" CRLF "DONE"
initial-resp = (base64 / "=") initial-resp = (base64 / "=")
; "initial response" defined in ; "initial response" defined in
skipping to change at page 121, line 10 skipping to change at page 122, line 9
move = "MOVE" SP sequence-set SP mailbox 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.SIZE" SP number / "RFC822.SIZE" SP number /
"BODY" ["STRUCTURE"] SP body / "BODY" ["STRUCTURE"] SP body /
"BODY" section ["<" number ">"] SP nstring / "BODY" section ["<" number ">"] SP nstring /
"BINARY" section-binary SP (nstring / literal8) / "BINARY" section-binary SP (nstring / literal8) /
"BINARY.SIZE" section-binary SP number / "BINARY.SIZE" section-binary SP number /
"UID" SP uniqueid "UID" SP uniqueid
; MUST NOT change for a message ; MUST NOT change for a message
Namespace = nil / "(" 1*Namespace-Descr ")" Namespace = nil / "(" 1*Namespace-Descr ")"
skipping to change at page 124, line 4 skipping to change at page 124, line 49
"CLOSED" / "CLOSED" /
"UNKNOWN-CTE" / "UNKNOWN-CTE" /
atom [SP 1*<any TEXT-CHAR except "]">] atom [SP 1*<any TEXT-CHAR except "]">]
return-option = "SUBSCRIBED" / "CHILDREN" / option-extension return-option = "SUBSCRIBED" / "CHILDREN" / option-extension
search = "SEARCH" [search-return-opts] search = "SEARCH" [search-return-opts]
SP search-program SP search-program
search-correlator = SP "(" "TAG" SP tag-string ")" search-correlator = SP "(" "TAG" SP tag-string ")"
search-key = "ALL" / "ANSWERED" / "BCC" SP astring / search-key = "ALL" / "ANSWERED" / "BCC" SP astring /
"BEFORE" SP date / "BODY" SP astring / "BEFORE" SP date / "BODY" SP astring /
"CC" SP astring / "DELETED" / "FLAGGED" / "CC" SP astring / "DELETED" / "FLAGGED" /
"FROM" SP astring / "KEYWORD" SP flag-keyword / "FROM" SP astring / "KEYWORD" SP flag-keyword /
"NEW" / "OLD" / "ON" SP date / "SEEN" / "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 126, line 8 skipping to change at page 127, line 4
; response to a command that uses a message ; response to a command that uses a message
; sequence number greater than the number of ; sequence number greater than the number of
; messages in the selected mailbox. This ; messages in the selected mailbox. This
; includes "*" if the selected mailbox is empty. ; includes "*" if the selected mailbox is empty.
seq-range = seq-number ":" seq-number seq-range = seq-number ":" seq-number
; two seq-number values and all values between ; two seq-number values and all values between
; these two regardless of order. ; these two regardless of order.
; Example: 2:4 and 4:2 are equivalent and indicate ; Example: 2:4 and 4:2 are equivalent and indicate
; values 2, 3, and 4. ; values 2, 3, and 4.
; Example: a unique identifier sequence range of ; Example: a unique identifier sequence range of
; 3291:* includes the UID of the last message in ; 3291:* includes the UID of the last message in
; the mailbox, even if that value is less than 3291. ; the mailbox, even if that value is less than 3291.
sequence-set = (seq-number / seq-range) ["," sequence-set] sequence-set = (seq-number / seq-range) ["," sequence-set]
; set of seq-number values, regardless of order. ; set of seq-number values, regardless of order.
; Servers MAY coalesce overlaps and/or execute the ; Servers MAY coalesce overlaps and/or execute the
; sequence in any order. ; sequence in any order.
; Example: a message sequence number set of ; Example: a message sequence number set of
; 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" / "UIDNEXT" / "UIDVALIDITY" / status-att = "MESSAGES" / "UIDNEXT" / "UIDVALIDITY" /
"UNSEEN" / "SIZE" "UNSEEN" / "DELETED" / "SIZE"
status-att-val = ("MESSAGES" SP number) / status-att-val = ("MESSAGES" SP number) /
("UIDNEXT" SP nz-number) / ("UIDNEXT" SP nz-number) /
("UIDVALIDITY" SP nz-number) / ("UIDVALIDITY" SP nz-number) /
("UNSEEN" SP number) / ("UNSEEN" SP number) /
("DELETED" SP number) /
("SIZE" SP number64) ("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
skipping to change at page 128, line 43 skipping to change at page 129, line 39
IMAP4rev2 protocol transactions, including electronic mail data, are IMAP4rev2 protocol transactions, including electronic mail data, are
sent in the clear over the network unless protection from snooping is sent in the clear over the network unless protection from snooping is
negotiated. This can be accomplished either by the use of IMAPS negotiated. This can be accomplished either by the use of IMAPS
service, STARTTLS command, negotiated privacy protection in the service, STARTTLS command, negotiated privacy protection in the
AUTHENTICATE command, or some other protection mechanism. AUTHENTICATE command, or some other protection mechanism.
11.1. STARTTLS Security Considerations 11.1. STARTTLS Security Considerations
IMAP client and server implementations MUST comply with relevant TLS IMAP client and server implementations MUST comply with relevant TLS
recommendations from [RFC8314]. Additionally, when using TLS 1.2, recommendations from [RFC8314].
IMAP implementations MUST implement
Additionally, when using TLS 1.2, IMAP implementations MUST implement
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite, and SHOULD TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite, and SHOULD
implement the TLS_RSA_WITH_AES_128_CBC_SHA [TLS] cipher suite. This implement the TLS_RSA_WITH_AES_128_CBC_SHA [TLS] cipher suite. This
is important as it assures that any two compliant implementations can is important as it assures that any two compliant implementations can
be configured to interoperate. Other TLS cipher suites recommended be configured to interoperate. Other TLS cipher suites recommended
in RFC 7525 are RECOMMENDED: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, in RFC 7525 are RECOMMENDED: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 and TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 and
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. All other cipher suites are TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. All other cipher suites are
OPTIONAL. Note that this is a change from section 2.1 of [IMAP-TLS]. OPTIONAL. Note that this is a change from section 2.1 of [IMAP-TLS].
During the [TLS] negotiation, the client MUST check its understanding During the [TLS] negotiation, the client MUST check its understanding
skipping to change at page 136, line 28 skipping to change at page 137, line 28
Appendix A. Backward compatibility with IMAP4rev1 Appendix A. Backward compatibility with IMAP4rev1
An implementation that wants to remain compatible with IMAP4rev1 can An implementation that wants to remain compatible with IMAP4rev1 can
advertise both IMAP4rev1 and IMAP4rev2 in its CAPABILITY response/ advertise both IMAP4rev1 and IMAP4rev2 in its CAPABILITY response/
response code. While some IMAP4rev1 responses were removed in response code. While some IMAP4rev1 responses were removed in
IMAP4rev2, their presence will not break IMAP4rev2-only clients. IMAP4rev2, their presence will not break IMAP4rev2-only clients.
If both IMAP4rev1 and IMAP4rev2 are advertised, an IMAP client that If both IMAP4rev1 and IMAP4rev2 are advertised, an IMAP client that
wants to use IMAP4rev2 MUST issue an "ENABLE IMAP4rev2" command. wants to use IMAP4rev2 MUST issue an "ENABLE IMAP4rev2" command.
Servers advertising both IMAP4rev1 and IMAP4rev2 SHOULD NOT generate Servers advertising both IMAP4rev1 and IMAP4rev2 SHOULD NOT
UTF-8 quoted strings unless the client has issued "ENABLE IMAP4rev2".
Consider implementation of mechanisms described or referenced in generate UTF-8 quoted strings unless the client has issued "ENABLE
[IMAP-UTF-8] to achieve this goal. IMAP4rev2". Consider implementation of mechanisms described or
referenced in [IMAP-UTF-8] to achieve this goal.
Servers advertising both IMAP4rev1 and IMAP4rev2, and clients Servers advertising both IMAP4rev1 and IMAP4rev2, and clients
intending to be compatible with IMAP4rev1 servers MUST be compatible intending to be compatible with IMAP4rev1 servers MUST be compatible
with the international mailbox naming convention described in the with the international mailbox naming convention described in the
following subsection. following subsection.
A.1. Mailbox International Naming Convention for compatibility with A.1. Mailbox International Naming Convention for compatibility with
IMAP4rev1 IMAP4rev1
Support for the Mailbox International Naming Convention described in Support for the Mailbox International Naming Convention described in
skipping to change at page 139, line 12 skipping to change at page 140, line 15
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, SEARCHRES, BINARY (only the FETCH patterns, STATUS-in-LIST, SEARCHRES, BINARY (only the FETCH
changes on leaf body part and make APPEND related ones optional. changes on leaf body part and make APPEND related ones optional.
See the mailing list discussion) - done. See the mailing list discussion) - done.
7. Add STATUS SIZE (total mailbox size) - done Add STATUS DELETED 6.
(number of messages with \Deleted flag set)? Or DELETEDSIZE?
8. Deprecate features: What should we do with NEW search key (which 7. Add STATUS SIZE (total mailbox size) - done. Add STATUS DELETED
implies RECENT): deprecate it or just redefine it to ignore (number of messages with \Deleted flag set) - done.
RECENT state?
9. Drop UTF-7, all mailboxes are always in UTF-8 - done. 8. Drop UTF-7, all mailboxes are always in UTF-8 - done.
10. Revise IANA registration of IMAP extensions and give advice on 9. Revise IANA registration of IMAP extensions and give advice on
use of "X-" convention. use of "X-" convention.
11. Allow word-based searching (as per Chris Newman)? Need to 10. Allow word-based searching (as per Chris Newman)? Need to
discuss header field search, where exact/substring match is discuss header field search, where exact/substring match is
still required for interoperability. still required for interoperability.
The following changes since RFC 3501 were done so far: The following changes since RFC 3501 were done so far:
1. Folded in IMAP UNSELECT (RFC 3691), UIDPLUS (RFC 4315), ESEARCH 1. Folded in IMAP UNSELECT (RFC 3691), UIDPLUS (RFC 4315), ESEARCH
(RFC 4731), ENABLE (RFC 5161), IDLE (RFC 2177), SASL-IR (RFC (RFC 4731), ENABLE (RFC 5161), IDLE (RFC 2177), SASL-IR (RFC
4959) and MOVE (RFC 6851) extensions. Also folded RFC 5530 and 4959) and MOVE (RFC 6851) extensions. Also folded RFC 5530 and
FETCH side of the BINARY extension (RFC 3516). FETCH side of the BINARY extension (RFC 3516).
skipping to change at page 140, line 5 skipping to change at page 141, line 5
5. Updated to use modern TLS-related recommendations as per RFC 5. Updated to use modern TLS-related recommendations as per RFC
8314, RFC 7817, RFC 7525. 8314, RFC 7817, RFC 7525.
6. For future extensibility extended ABNF for tagged-ext-simple to 6. For future extensibility extended ABNF for tagged-ext-simple to
allow for bare number64. allow for bare number64.
7. Added SHOULD level requirement on IMAP servers to support 7. Added SHOULD level requirement on IMAP servers to support
$MDNSent and $Forwarded keywords. $MDNSent and $Forwarded keywords.
8. Added STATUS SIZE. 8. Added STATUS SIZE and STATUS DELETED.
9. Mailbox names and message headers now allow for UTF-8. Support 9. Mailbox names and message headers now allow for UTF-8. Support
for Modified UTF-7 in mailbox names is not required, unless for Modified UTF-7 in mailbox names is not required, unless
compatibility with IMAP4rev1 is desired. compatibility with IMAP4rev1 is desired.
10. UNSEEN response code on SELECT/EXAMINE is now deprecated. 10. UNSEEN response code on SELECT/EXAMINE is now deprecated.
11. RECENT response on SELECT/EXAMINE, \Recent flag, RECENT STATUS 11. RECENT response on SELECT/EXAMINE, \Recent flag, RECENT STATUS,
item are now deprecated. SEARCH NEW items are now deprecated.
12. Clarified that the server doesn't need to send a new 12. Clarified that the server doesn't need to send a new
PERMANENTFLAGS response code when a new keyword was successfully PERMANENTFLAGS response code when a new keyword was successfully
added and the server advertised \* earlier for the same mailbox. added and the server advertised \* earlier for the same mailbox.
13. Removed the CHECK command. Clients should use NOOP instead. 13. Removed the CHECK command. Clients should use NOOP instead.
14. RFC822, RFC822.HEADER and RFC822.TEXT FETCH data items are 14. RFC822, RFC822.HEADER and RFC822.TEXT FETCH data items were
deprecated, but supported in this document. deprecated. Clients should use the corresponding BODY[]
variants instead.
15. Replaced DIGEST-MD5 SASL mechanism with SCRAM-SHA-256. DIGEST- 15. Replaced DIGEST-MD5 SASL mechanism with SCRAM-SHA-256. DIGEST-
MD5 was deprecated. MD5 was deprecated.
16. LSUB command was deprecated. Clients should use LIST 16. LSUB command was deprecated. Clients should use LIST
(SUBSCRIBED) instead. (SUBSCRIBED) instead.
Appendix D. Acknowledgement Appendix D. Acknowledgement
Earlier versions of this document were edited by Mark Crispin. Earlier versions of this document were edited by Mark Crispin.
Sadly, he is no longer available to help with this work. Editors of Sadly, he is no longer available to help with this work. Editors of
this revisions are hoping that Mark would have approved. this revisions are hoping that Mark would have approved.
Chris Newman has contributed text on I18N and use of UTF-8 in Chris Newman has contributed text on I18N and use of UTF-8 in
messages and mailbox names. messages and mailbox names.
Thank you to Tony Hansen for helping with the index generation. Thank you to Tony Hansen for helping with the index generation.
Thank you to Timo Sirainen, Bron Gondwana and Arnt Gulbrandsen for Thank you to Timo Sirainen, Bron Gondwana and Arnt Gulbrandsen for
extensive feedback. extensive feedback.
This document incorporate text from RFC 4315, RFC 4466, RFC 4731, RFC This document incorporate text from RFC 4315 (by Mark Crispin), RFC
5161, RFC 6154 so work done by authors/editors of these documents is 4466 (by Cyrus Daboo), RFC 4731 (by Dave Cridland), RFC 5161 (by Arnt
appreciated. Gulbrandsen), RFC 5530 (by Arnt Gulbrandsen), RFC 6154 (by Jamie
Nicolson)
so work done by authors/editors of these documents is appreciated.
Index Index
$ $
$Forwarded (predefined flag) 12 $Forwarded (predefined flag) 12
$MDNSent (predefined flag) 12 $MDNSent (predefined flag) 12
+ +
+FLAGS <flag list> 80 +FLAGS <flag list> 80
+FLAGS.SILENT <flag list> 80 +FLAGS.SILENT <flag list> 80
- -
-FLAGS <flag list> 80 -FLAGS <flag list> 80
-FLAGS.SILENT <flag list> 80 -FLAGS.SILENT <flag list> 80
A A
ALERT (response code) 87 ALERT (response code) 87
ALL (fetch item) 75 ALL (fetch item) 76
ALL (search key) 72 ALL (search key) 72
ALL (search result option) 70 ALL (search result option) 71
ALREADYEXISTS (response code) 87 ALREADYEXISTS (response code) 87
ANSWERED (search key) 72 ANSWERED (search key) 72
APPEND (command) 63 APPEND (command) 63
APPENDUID (response code) 87 APPENDUID (response code) 88
AUTHENTICATE (command) 28 AUTHENTICATE (command) 28
AUTHENTICATIONFAILED (response code) 88 AUTHENTICATIONFAILED (response code) 88
AUTHORIZATIONFAILED (response code) 88 AUTHORIZATIONFAILED (response code) 89
B B
BAD (response) 95 BAD (response) 96
BADCHARSET (response code) 88 BADCHARSET (response code) 89
BCC <string> (search key) 72 BCC <string> (search key) 73
BEFORE <date> (search key) 72 BEFORE <date> (search key) 73
BINARY.PEEK[<section-binary>]<<partial>> (fetch item) 76 BINARY.PEEK[<section-binary>]<<partial>> (fetch item) 77
BINARY.SIZE[<section-binary>] (fetch item) 76 BINARY.SIZE[<section-binary>] (fetch item) 77
BINARY.SIZE[<section-binary>] (fetch result) 104 BINARY.SIZE[<section-binary>] (fetch result) 106
BINARY[<section-binary>]<<number>> (fetch result) 104 BINARY[<section-binary>]<<number>> (fetch result) 105
BINARY[<section-binary>]<<partial>> (fetch item) 75 BINARY[<section-binary>]<<partial>> (fetch item) 76
BODY (fetch item) 76 BODY (fetch item) 77
BODY (fetch result) 105 BODY (fetch result) 106
BODY <string> (search key) 72 BODY <string> (search key) 73
BODY.PEEK[<section>]<<partial>> (fetch item) 78 BODY.PEEK[<section>]<<partial>> (fetch item) 79
BODYSTRUCTURE (fetch item) 78 BODYSTRUCTURE (fetch item) 79
BODYSTRUCTURE (fetch result) 105 BODYSTRUCTURE (fetch result) 107
BODY[<section>]<<origin octet>> (fetch result) 105 BODY[<section>]<<origin octet>> (fetch result) 106
BODY[<section>]<<partial>> (fetch item) 76 BODY[<section>]<<partial>> (fetch item) 77
BYE (response) 95 BYE (response) 97
Body Structure (message attribute) 13 Body Structure (message attribute) 13
C C
CANNOT (response code) 88 CANNOT (response code) 89
CAPABILITY (command) 24 CAPABILITY (command) 24
CAPABILITY (response code) 88 CAPABILITY (response code) 89
CAPABILITY (response) 96 CAPABILITY (response) 98
CC <string> (search key) 72 CC <string> (search key) 73
CLIENTBUG (response code) 89 CLIENTBUG (response code) 89
CLOSE (command) 68 CLOSE (command) 68
CLOSED (response code) 89 CLOSED (response code) 90
CONTACTADMIN (response code) 89 CONTACTADMIN (response code) 90
COPY (command) 80 COPY (command) 81
COPYUID (response code) 89 COPYUID (response code) 90
CORRUPTION (response code) 90 CORRUPTION (response code) 91
COUNT (search result option) 71 COUNT (search result option) 71
CREATE (command) 36 CREATE (command) 36
D D
DELETE (command) 37 DELETE (command) 37
DELETED (search key) 72 DELETED (search key) 73
DRAFT (search key) 72 DELETED (status item) 63
DRAFT (search key) 73
E E
ENABLE (command) 32 ENABLE (command) 32
ENVELOPE (fetch item) 78 ENVELOPE (fetch item) 79
ENVELOPE (fetch result) 108 ENVELOPE (fetch result) 109
ESEARCH (response) 101 ESEARCH (response) 103
EXAMINE (command) 35 EXAMINE (command) 35
EXPIRED (response code) 90 EXPIRED (response code) 91
EXPUNGE (command) 69 EXPUNGE (command) 69
EXPUNGE (response) 103 EXPUNGE (response) 104
EXPUNGEISSUED (response code) 90 EXPUNGEISSUED (response code) 91
Envelope Structure (message attribute) 13 Envelope Structure (message attribute) 13
F F
FAST (fetch item) 75 FAST (fetch item) 76
FETCH (command) 75 FETCH (command) 76
FETCH (response) 104 FETCH (response) 105
FLAGGED (search key) 72 FLAGGED (search key) 73
FLAGS (fetch item) 78 FLAGS (fetch item) 79
FLAGS (fetch result) 109 FLAGS (fetch result) 110
FLAGS (response) 102 FLAGS (response) 103
FLAGS <flag list> (store command data item) 79 FLAGS <flag list> (store command data item) 80
FLAGS.SILENT <flag list> (store command data item) 79 FLAGS.SILENT <flag list> (store command data item) 80
FROM <string> (search key) 72 FROM <string> (search key) 73
FULL (fetch item) 75 FULL (fetch item) 76
Flags (message attribute) 11 Flags (message attribute) 11
H H
HEADER (part specifier) 76 HEADER (part specifier) 77
HEADER <field-name> <string> (search key) 72 HEADER <field-name> <string> (search key) 73
HEADER.FIELDS (part specifier) 76 HEADER.FIELDS (part specifier) 77
HEADER.FIELDS.NOT (part specifier) 76 HEADER.FIELDS.NOT (part specifier) 77
I I
IDLE (command) 66 IDLE (command) 66
INTERNALDATE (fetch item) 78 INTERNALDATE (fetch item) 79
INTERNALDATE (fetch result) 109 INTERNALDATE (fetch result) 110
INUSE (response code) 90 INUSE (response code) 91
Internal Date (message attribute) 12 Internal Date (message attribute) 12
K K
KEYWORD <flag> (search key) 72 KEYWORD <flag> (search key) 73
Keyword (type of flag) 12 Keyword (type of flag) 12
L L
LARGER <n> (search key) 72 LARGER <n> (search key) 73
LIMIT (response code) 91 LIMIT (response code) 92
LIST (command) 41 LIST (command) 41
LIST (response) 97 LIST (response) 99
LOGOUT (command) 26 LOGOUT (command) 26
M M
MAX (search result option) 70 MAX (search result option) 71
MAY (specification requirement term) 5 MAY (specification requirement term) 5
MESSAGES (status item) 63 MESSAGES (status item) 63
MIME (part specifier) 77 MIME (part specifier) 78
MIN (search result option) 70 MIN (search result option) 71
MOVE (command) 81 MOVE (command) 82
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) 57 NAMESPACE (command) 57
NAMESPACE (response) 101 NAMESPACE (response) 102
NEW (search key) 72 NO (response) 95
NO (response) 94 NONEXISTENT (response code) 92
NONEXISTENT (response code) 91
NOOP (command) 25 NOOP (command) 25
NOPERM (response code) 91 NOPERM (response code) 92
NOT <search-key> (search key) 73 NOT <search-key> (search key) 73
NOT RECOMMENDED (specification requirement term) 5 NOT RECOMMENDED (specification requirement term) 5
O O
OK (response) 94 OK (response) 95
ON <date> (search key) 73 ON <date> (search key) 73
OPTIONAL (specification requirement term) 5 OPTIONAL (specification requirement term) 5
OR <search-key1> <search-key2> (search key) 73 OR <search-key1> <search-key2> (search key) 73
OVERQUOTA (response code) 91 OVERQUOTA (response code) 92
P P
PARSE (response code) 92 PARSE (response code) 93
PERMANENTFLAGS (response code) 92 PERMANENTFLAGS (response code) 93
PREAUTH (response) 95 PREAUTH (response) 96
PRIVACYREQUIRED (response code) 92 PRIVACYREQUIRED (response code) 93
Permanent Flag (class of flag) 12 Permanent Flag (class of flag) 12
Predefined keywords 12 Predefined keywords 12
R R
READ-ONLY (response code) 92 READ-ONLY (response code) 93
READ-WRITE (response code) 92 READ-WRITE (response code) 94
RECOMMENDED (specification requirement term) 5 RECOMMENDED (specification requirement term) 5
RENAME (command) 38 RENAME (command) 39
REQUIRED (specification requirement term) 5 REQUIRED (specification requirement term) 5
RFC822 (fetch item) 78
RFC822 (fetch result) 109
RFC822.HEADER (fetch item) 78
RFC822.HEADER (fetch result) 109
RFC822.SIZE (fetch item) 79 RFC822.SIZE (fetch item) 79
RFC822.SIZE (fetch result) 109 RFC822.SIZE (fetch result) 110
RFC822.TEXT (fetch item) 79
RFC822.TEXT (fetch result) 109
S S
SEARCH (command) 69 SEARCH (command) 70
SEEN (search key) 73 SEEN (search key) 74
SELECT (command) 34 SELECT (command) 34
SENTBEFORE <date> (search key) 73 SENTBEFORE <date> (search key) 74
SENTON <date> (search key) 73 SENTON <date> (search key) 74
SENTSINCE <date> (search key) 73 SENTSINCE <date> (search key) 74
SERVERBUG (response code) 92 SERVERBUG (response code) 94
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) 73 SINCE <date> (search key) 74
SIZE (status item) 63 SIZE (status item) 63
SMALLER <n> (search key) 73 SMALLER <n> (search key) 74
STARTTLS (command) 27 STARTTLS (command) 27
STATUS (command) 62 STATUS (command) 62
STATUS (response) 101 STATUS (response) 102
STORE (command) 79 STORE (command) 80
SUBJECT <string> (search key) 73 SUBJECT <string> (search key) 74
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) 76 TEXT (part specifier) 77
TEXT <string> (search key) 73 TEXT <string> (search key) 74
TO <string> (search key) 73 TO <string> (search key) 74
TRYCREATE (response code) 93 TRYCREATE (response code) 94
U U
UID (command) 83 UID (command) 84
UID (fetch item) 79 UID (fetch item) 79
UID (fetch result) 109 UID (fetch result) 110
UID <sequence set> (search key) 73 UID <sequence set> (search key) 74
UIDNEXT (response code) 93 UIDNEXT (response code) 94
UIDNEXT (status item) 63 UIDNEXT (status item) 63
UIDNOTSTICKY (response code) 93 UIDNOTSTICKY (response code) 94
UIDVALIDITY (response code) 93 UIDVALIDITY (response code) 94
UIDVALIDITY (status item) 63 UIDVALIDITY (status item) 63
UNANSWERED (search key) 73 UNANSWERED (search key) 74
UNAVAILABLE (response code) 93 UNAVAILABLE (response code) 95
UNDELETED (search key) 73 UNDELETED (search key) 74
UNDRAFT (search key) 73 UNDRAFT (search key) 74
UNFLAGGED (search key) 73 UNFLAGGED (search key) 74
UNKEYWORD <flag> (search key) 74 UNKEYWORD <flag> (search key) 74
UNKNOWN-CTE (response code) 93 UNKNOWN-CTE (response code) 95
UNSEEN (search key) 74 UNSEEN (search key) 74
UNSEEN (status item) 63 UNSEEN (status item) 63
UNSELECT (command) 68 UNSELECT (command) 69
UNSUBSCRIBE (command) 41 UNSUBSCRIBE (command) 41
Unique Identifier (UID) (message attribute) 9 Unique Identifier (UID) (message attribute) 9
X X
X<atom> (command) 85 X<atom> (command) 85
[ [
[RFC-5322] Size (message attribute) 13 [RFC-5322] Size (message attribute) 13
\ \
\All (mailbox name attribute) 99 \All (mailbox name attribute) 100
\Answered (system flag) 11 \Answered (system flag) 11
\Archive (mailbox name attribute) 99 \Archive (mailbox name attribute) 101
\Deleted (system flag) 11 \Deleted (system flag) 12
\Draft (system flag) 12 \Draft (system flag) 12
\Drafts (mailbox name attribute) 99 \Drafts (mailbox name attribute) 101
\Flagged (mailbox name attribute) 100 \Flagged (mailbox name attribute) 101
\Flagged (system flag) 11 \Flagged (system flag) 11
\HasChildren (mailbox name attribute) 98 \HasChildren (mailbox name attribute) 99
\HasNoChildren (mailbox name attribute) 98 \HasNoChildren (mailbox name attribute) 100
\Junk (mailbox name attribute) 100 \Junk (mailbox name attribute) 101
\Marked (mailbox name attribute) 99 \Marked (mailbox name attribute) 100
\Noinferiors (mailbox name attribute) 98 \Noinferiors (mailbox name attribute) 99
\NonExistent (mailbox name attribute) 98 \NonExistent (mailbox name attribute) 99
\Noselect (mailbox name attribute) 98 \Noselect (mailbox name attribute) 99
\Recent (system flag) 12 \Recent (system flag) 12
\Remote (mailbox name attribute) 99 \Remote (mailbox name attribute) 100
\Seen (system flag) 11 \Seen (system flag) 11
\Sent (mailbox name attribute) 100 \Sent (mailbox name attribute) 101
\Subscribed (mailbox name attribute) 99 \Subscribed (mailbox name attribute) 100
\Trash (mailbox name attribute) 100 \Trash (mailbox name attribute) 101
\Unmarked (mailbox name attribute) 99 \Unmarked (mailbox name attribute) 100
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. 123 change blocks. 
349 lines changed or deleted 388 lines changed or added

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