< draft-ietf-extra-imap4rev2-11.txt   draft-ietf-extra-imap4rev2-12.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: June 5, 2020 December 3, 2019 Expires: August 15, 2020 February 12, 2020
INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev2 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev2
draft-ietf-extra-imap4rev2-11 draft-ietf-extra-imap4rev2-12
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 June 5, 2020. This Internet-Draft will expire on August 15, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 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 . . . . . . . . . . . . . . . . . . . 14 3.2. Authenticated State . . . . . . . . . . . . . . . . . . . 13
3.3. Selected State . . . . . . . . . . . . . . . . . . . . . 14 3.3. Selected State . . . . . . . . . . . . . . . . . . . . . 14
3.4. Logout State . . . . . . . . . . . . . . . . . . . . . . 14 3.4. Logout State . . . . . . . . . . . . . . . . . . . . . . 14
4. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 16 4. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Atom . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1. Atom . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.1. Sequence set and UID set . . . . . . . . . . . . . . 16 4.1.1. Sequence set and UID set . . . . . . . . . . . . . . 16
4.2. Number . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2. Number . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3. String . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.3. String . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3.1. 8-bit and Binary Strings . . . . . . . . . . . . . . 17 4.3.1. 8-bit and Binary Strings . . . . . . . . . . . . . . 17
4.4. Parenthesized List . . . . . . . . . . . . . . . . . . . 18 4.4. Parenthesized List . . . . . . . . . . . . . . . . . . . 18
4.5. NIL . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.5. NIL . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
skipping to change at page 4, line 38 skipping to change at page 4, line 38
7.4.1. EXPUNGE Response . . . . . . . . . . . . . . . . . . 114 7.4.1. EXPUNGE Response . . . . . . . . . . . . . . . . . . 114
7.4.2. FETCH Response . . . . . . . . . . . . . . . . . . . 115 7.4.2. FETCH Response . . . . . . . . . . . . . . . . . . . 115
7.5. Server Responses - Command Continuation Request . . . . . 121 7.5. Server Responses - Command Continuation Request . . . . . 121
8. Sample IMAP4rev2 connection . . . . . . . . . . . . . . . . . 121 8. Sample IMAP4rev2 connection . . . . . . . . . . . . . . . . . 121
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 122 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 122
10. Author's Note . . . . . . . . . . . . . . . . . . . . . . . . 139 10. Author's Note . . . . . . . . . . . . . . . . . . . . . . . . 139
11. Security Considerations . . . . . . . . . . . . . . . . . . . 139 11. Security Considerations . . . . . . . . . . . . . . . . . . . 139
11.1. STARTTLS Security Considerations . . . . . . . . . . . . 140 11.1. STARTTLS Security Considerations . . . . . . . . . . . . 140
11.2. COPYUID and APPENDUID response codes . . . . . . . . . . 140 11.2. COPYUID and APPENDUID response codes . . . . . . . . . . 140
11.3. LIST command and Other Users' namespace . . . . . . . . 140 11.3. LIST command and Other Users' namespace . . . . . . . . 140
11.4. Other Security Considerations . . . . . . . . . . . . . 141 11.4. Other Security Considerations . . . . . . . . . . . . . 140
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 141 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 141
12.1. Updates to IMAP4 Capabilities registry . . . . . . . . . 142 12.1. Updates to IMAP4 Capabilities registry . . . . . . . . . 142
12.2. GSSAPI/SASL service name . . . . . . . . . . . . . . . . 142 12.2. GSSAPI/SASL service name . . . . . . . . . . . . . . . . 142
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 142 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 142
13.1. Normative References . . . . . . . . . . . . . . . . . . 142 13.1. Normative References . . . . . . . . . . . . . . . . . . 142
13.2. Informative References (related protocols) . . . . . . . 145 13.2. Informative References (related protocols) . . . . . . . 145
13.3. Informative References (historical aspects of IMAP and 13.3. Informative References (historical aspects of IMAP and
related protocols) . . . . . . . . . . . . . . . . . . . 147 related protocols) . . . . . . . . . . . . . . . . . . . 146
Appendix A. Backward compatibility with IMAP4rev1 . . . . . . . 147 Appendix A. Backward compatibility with IMAP4rev1 . . . . . . . 147
A.1. Mailbox International Naming Convention for compatibility A.1. Mailbox International Naming Convention for compatibility
with IMAP4rev1 . . . . . . . . . . . . . . . . . . . . . 148 with IMAP4rev1 . . . . . . . . . . . . . . . . . . . . . 148
Appendix B. Backward compatibility with BINARY extension . . . . 149 Appendix B. Backward compatibility with BINARY extension . . . . 149
Appendix C. Changes from RFC 3501 / IMAP4rev1 . . . . . . . . . 150 Appendix C. Changes from RFC 3501 / IMAP4rev1 . . . . . . . . . 149
Appendix D. Acknowledgement . . . . . . . . . . . . . . . . . . 152 Appendix D. Acknowledgement . . . . . . . . . . . . . . . . . . 152
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 157 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 157
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
skipping to change at page 7, line 11 skipping to change at page 7, line 11
as a consequence several fetch items in IMAP incorporate "RFC822" in as a consequence several fetch items in IMAP incorporate "RFC822" in
their name. In all cases, "RFC822" should be interpreted as a their name. In all cases, "RFC822" should be interpreted as a
reference to the updated [RFC-5322] standard. reference to the updated [RFC-5322] standard.
2. Protocol Overview 2. Protocol Overview
2.1. Link Level 2.1. Link Level
The IMAP4rev2 protocol assumes a reliable data stream such as that The IMAP4rev2 protocol assumes a reliable data stream such as that
provided by TCP. When TCP is used, an IMAP4rev2 server listens on provided by TCP. When TCP is used, an IMAP4rev2 server listens on
port 143. port 143 or port 993 (IMAP-over-TLS).
2.2. Commands and Responses 2.2. Commands and Responses
An IMAP4rev2 connection consists of the establishment of a client/ An IMAP4rev2 connection consists of the establishment of a client/
server network connection, an initial greeting from the server, and server network connection, an initial greeting from the server, and
client/server interactions. These client/server interactions consist client/server interactions. These client/server interactions consist
of a client command, server data, and a server completion result of a client command, server data, and a server completion result
response. response.
All interactions transmitted by client and server are in the form of All interactions transmitted by client and server are in the form of
skipping to change at page 11, line 40 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 "\". specification and begin with "\". Certain system flags (\Deleted and
\Seen) have special semantics described elsewhere in this document.
Certain system flags (\Deleted and \Seen) have special semantics The currently-defined system flags are:
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 28 skipping to change at page 12, line 26
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 22, line 48 skipping to change at page 22, line 48
The client MAY send another command without waiting for the The client MAY send another command without waiting for the
completion result response of a command, subject to ambiguity rules completion result response of a command, subject to ambiguity rules
(see below) and flow control constraints on the underlying data (see below) and flow control constraints on the underlying data
stream. Similarly, a server MAY begin processing another command stream. Similarly, a server MAY begin processing another command
before processing the current command to completion, subject to before processing the current command to completion, subject to
ambiguity rules. However, any command continuation request responses ambiguity rules. However, any command continuation request responses
and command continuations MUST be negotiated before any subsequent and command continuations MUST be negotiated before any subsequent
command is initiated. command is initiated.
The exception is if an ambiguity would result because of a command The exception is if an ambiguity would result because of a command
that would affect the results of other commands. that would affect the results of other commands. If the server
detects a possible ambiguity, it MUST execute commands to completion
If the server detects a possible ambiguity, it MUST execute commands in the order given by the client.
to completion in the order given by the client.
The most obvious example of ambiguity is when a command would affect The most obvious example of ambiguity is when a command would affect
the results of another command, e.g., a FETCH of a message's flags the results of another command, e.g., a FETCH of a message's flags
and a STORE of that same message's flags. and a STORE of that same message's flags.
A non-obvious ambiguity occurs with commands that permit an untagged A non-obvious ambiguity occurs with commands that permit an untagged
EXPUNGE response (commands other than FETCH, STORE, and SEARCH), EXPUNGE response (commands other than FETCH, STORE, and SEARCH),
since an untagged EXPUNGE response can invalidate sequence numbers in since an untagged EXPUNGE response can invalidate sequence numbers in
a subsequent command. This is not a problem for FETCH, STORE, or a subsequent command. This is not a problem for FETCH, STORE, or
SEARCH commands because servers are prohibited from sending EXPUNGE SEARCH commands because servers are prohibited from sending EXPUNGE
skipping to change at page 33, line 47 skipping to change at page 33, line 47
The ENABLE command is only valid in the authenticated state, before The ENABLE command is only valid in the authenticated state, before
any mailbox is selected. Clients MUST NOT issue ENABLE once they any mailbox is selected. Clients MUST NOT issue ENABLE once they
SELECT/EXAMINE a mailbox; however, server implementations don't have SELECT/EXAMINE a mailbox; however, server implementations don't have
to check that no mailbox is selected or was previously selected to check that no mailbox is selected or was previously selected
during the duration of a connection. during the duration of a connection.
The ENABLE command can be issued multiple times in a session. It is The ENABLE command can be issued multiple times in a session. It is
additive; i.e., "ENABLE a b", followed by "ENABLE c" is the same as a additive; i.e., "ENABLE a b", followed by "ENABLE c" is the same as a
single command "ENABLE a b c". When multiple ENABLE commands are single command "ENABLE a b c". When multiple ENABLE commands are
issued, each corresponding ENABLED response SHOULD only contain issued, each corresponding ENABLED response SHOULD only contain
extensions enabled by the corresponding ENABLE command. extensions enabled by the corresponding ENABLE command, i.e. for the
above example, the ENABLED response to "ENABLE c" should not contain
"a" or "b".
There are no limitations on pipelining ENABLE. For example, it is There are no limitations on pipelining ENABLE. For example, it is
possible to send ENABLE and then immediately SELECT, or a LOGIN possible to send ENABLE and then immediately SELECT, or a LOGIN
immediately followed by ENABLE. immediately followed by ENABLE.
The server MUST NOT change the CAPABILITY list as a result of The server MUST NOT change the CAPABILITY list as a result of
executing ENABLE; i.e., a CAPABILITY command issued right after an executing ENABLE; i.e., a CAPABILITY command issued right after an
ENABLE command MUST list the same capabilities as a CAPABILITY ENABLE command MUST list the same capabilities as a CAPABILITY
command issued before the ENABLE command. This is demonstrated in command issued before the ENABLE command. This is demonstrated in
the following example: the following example:
C: t1 CAPABILITY C: t1 CAPABILITY
S: * CAPABILITY IMAP4rev1 ID LITERAL+ ENABLE X-GOOD-IDEA S: * CAPABILITY IMAP4rev2 ID LITERAL+ X-GOOD-IDEA
S: t1 OK foo S: t1 OK foo
C: t2 ENABLE CONDSTORE X-GOOD-IDEA C: t2 ENABLE CONDSTORE X-GOOD-IDEA
S: * ENABLED X-GOOD-IDEA S: * ENABLED X-GOOD-IDEA
S: t2 OK foo S: t2 OK foo
C: t3 CAPABILITY C: t3 CAPABILITY
S: * CAPABILITY IMAP4rev1 ID LITERAL+ ENABLE X-GOOD-IDEA S: * CAPABILITY IMAP4rev2 ID LITERAL+ X-GOOD-IDEA
S: t3 OK foo again S: t3 OK foo again
In the following example, the client enables CONDSTORE: In the following example, the client enables CONDSTORE:
C: a1 ENABLE CONDSTORE C: a1 ENABLE CONDSTORE
S: * ENABLED CONDSTORE S: * ENABLED CONDSTORE
S: a1 OK Conditional Store enabled S: a1 OK Conditional Store enabled
6.3.1.1. Note to Designers of Extensions That May Use the ENABLE 6.3.1.1. Note to Designers of Extensions That May Use the ENABLE
Command Command
skipping to change at page 35, line 19 skipping to change at page 35, line 24
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. Section 2.3.1.1 for more information. If this is missing, the
client can not make any assumptions about the next unique
OK [UIDNEXT <n>] If this is missing, the client can not make any identifier value.
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 36, line 32 skipping to change at page 36, line 34
S: * OK [CLOSED] Previous mailbox is now closed S: * OK [CLOSED] Previous mailbox is now closed
S: * 5 EXISTS S: * 5 EXISTS
S: * OK [UIDVALIDITY 9877410381] UIDs valid S: * OK [UIDVALIDITY 9877410381] UIDs valid
S: * OK [UIDNEXT 102] Predicted next UID S: * OK [UIDNEXT 102] Predicted next UID
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Deleted \Seen \Answered S: * OK [PERMANENTFLAGS (\Deleted \Seen \Answered
\Flagged \Draft \*)] System flags and keywords allowed \Flagged \Draft \*)] System flags and keywords allowed
S: A143 OK [READ-WRITE] SELECT completed S: A143 OK [READ-WRITE] SELECT completed
Note that IMAP4rev1 compliant servers can also send the untagged Note that IMAP4rev1 compliant servers can also send the untagged
RECENT response which was depractated in IMAP4rev2. E.g. "* 0 RECENT response which was deprecated in IMAP4rev2. E.g. "* 0
RECENT". Pure IMAP4rev2 clients are advised to ignore the untagged RECENT". Pure IMAP4rev2 clients are advised to ignore the untagged
RECENT response. RECENT response.
6.3.3. EXAMINE Command 6.3.3. EXAMINE Command
Arguments: mailbox name Arguments: mailbox name
Responses: REQUIRED untagged responses: FLAGS, EXISTS Responses: REQUIRED untagged responses: FLAGS, EXISTS
REQUIRED OK untagged responses: PERMANENTFLAGS, REQUIRED OK untagged responses: PERMANENTFLAGS,
UIDNEXT, UIDVALIDITY UIDNEXT, UIDVALIDITY
skipping to change at page 38, line 44 skipping to change at page 38, line 48
example, if a mailbox "foo" has an inferior "foo.bar" (assuming "." example, if a mailbox "foo" has an inferior "foo.bar" (assuming "."
is the hierarchy delimiter character), removing "foo" MUST NOT remove is the hierarchy delimiter character), removing "foo" MUST NOT remove
"foo.bar". It is an error to attempt to delete a name that has "foo.bar". It is an error to attempt to delete a name that has
inferior hierarchical names and also has the \Noselect mailbox name inferior hierarchical names and also has the \Noselect mailbox name
attribute (see the description of the LIST response for more attribute (see the description of the LIST response for more
details). details).
It is permitted to delete a name that has inferior hierarchical names It is permitted to delete a name that has inferior hierarchical names
and does not have the \Noselect mailbox name attribute. If the and does not have the \Noselect mailbox name attribute. If the
server implementation does not permit deleting the name while server implementation does not permit deleting the name while
inferior hierarchical names exists the \Noselect mailbox name inferior hierarchical names exists then it SHOULD disallow the DELETE
attribute is set for that name. In any case, all messages in that command by returning tagged NO response or it MAY allow the DELETE
mailbox are removed by the DELETE command. command, but sets the \Noselect mailbox name attribute for that name.
In any case, all messages in that mailbox are removed by the DELETE
command.
The value of the highest-used unique identifier of the deleted The value of the highest-used unique identifier of the deleted
mailbox MUST be preserved so that a new mailbox created with the same mailbox MUST be preserved so that a new mailbox created with the same
name will not reuse the identifiers of the former incarnation, UNLESS name will not reuse the identifiers of the former incarnation, UNLESS
the new incarnation has a different unique identifier validity value. the new incarnation has a different unique identifier validity value.
See the description of the UID command for more detail. See the description of the UID command for more detail.
Examples: C: A682 LIST "" * Examples: C: A682 LIST "" *
S: * LIST () "/" blurdybloop S: * LIST () "/" blurdybloop
S: * LIST (\Noselect) "/" foo S: * LIST (\Noselect) "/" foo
skipping to change at page 42, line 7 skipping to change at page 42, line 7
Arguments: mailbox Arguments: mailbox
Responses: no specific responses for this command Responses: no specific responses for this command
Result: OK - subscribe completed Result: OK - subscribe completed
NO - subscribe failure: can't subscribe to that name NO - subscribe failure: can't subscribe to that name
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
The SUBSCRIBE command adds the specified mailbox name to the server's The SUBSCRIBE command adds the specified mailbox name to the server's
set of "active" or "subscribed" mailboxes as returned by the LIST set of "active" or "subscribed" mailboxes as returned by the LIST
(SUBSCRIBED) command. This command returns a tagged OK response only (SUBSCRIBED) command. This command returns a tagged OK response if
if the subscription is successful. the subscription is successful or if the mailbox is already
subscribed.
A server MAY validate the mailbox argument to SUBSCRIBE to verify A server MAY validate the mailbox argument to SUBSCRIBE to verify
that it exists. However, it MUST NOT unilaterally remove an existing that it exists. However, it SHOULD NOT unilaterally remove an
mailbox name from the subscription list even if a mailbox by that existing mailbox name from the subscription list even if a mailbox by
name no longer exists. that name no longer exists.
Note: This requirement is because a server site can choose to Note: This requirement is because a server site can choose to
routinely remove a mailbox with a well-known name (e.g., "system- routinely remove a mailbox with a well-known name (e.g., "system-
alerts") after its contents expire, with the intention of alerts") after its contents expire, with the intention of
recreating it when new contents are appropriate. recreating it when new contents are appropriate.
Example: C: A002 SUBSCRIBE #news.comp.mail.mime Example: C: A002 SUBSCRIBE #news.comp.mail.mime
S: A002 OK SUBSCRIBE completed S: A002 OK SUBSCRIBE completed
6.3.8. UNSUBSCRIBE Command 6.3.8. UNSUBSCRIBE Command
skipping to change at page 42, line 36 skipping to change at page 42, line 37
Responses: no specific responses for this command Responses: no specific responses for this command
Result: OK - unsubscribe completed Result: OK - unsubscribe completed
NO - unsubscribe failure: can't unsubscribe that name NO - unsubscribe failure: can't unsubscribe that name
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
The UNSUBSCRIBE command removes the specified mailbox name from the The UNSUBSCRIBE command removes the specified mailbox name from the
server's set of "active" or "subscribed" mailboxes as returned by the server's set of "active" or "subscribed" mailboxes as returned by the
LIST (SUBSCRIBED) command. This command returns a tagged OK response LIST (SUBSCRIBED) command. This command returns a tagged OK response
only if the unsubscription is successful. if the unsubscription is successful or if the mailbox is not
subscribed.
Example: C: A002 UNSUBSCRIBE #news.comp.mail.mime Example: C: A002 UNSUBSCRIBE #news.comp.mail.mime
S: A002 OK UNSUBSCRIBE completed S: A002 OK UNSUBSCRIBE completed
6.3.9. LIST Command 6.3.9. LIST Command
Arguments (basic): reference name Arguments (basic): reference name
mailbox name with possible wildcards mailbox name with possible wildcards
Arguments (extended): selection options (OPTIONAL) Arguments (extended): selection options (OPTIONAL)
skipping to change at page 44, line 12 skipping to change at page 44, line 12
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, form, that we call "canonical LIST pattern" later in this document.
To define the term "canonical LIST pattern" formally: it refers to
that we call "canonical LIST pattern" later in this document. To the canonical pattern constructed internally by the server from the
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 47, line 9 skipping to change at page 47, line 7
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 48, line 29 skipping to change at page 48, 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.5, below, for details. in [RFC3348]. See Section 6.3.9.5, below, for details. This
option MUST be supported by all servers.
CHILDREN - This option MUST be supported by all servers.
STATUS - requests STATUS response for each matching mailbox. STATUS - requests STATUS response for each matching mailbox.
This option takes STATUS data items as parameters. For each This option takes STATUS data items as parameters. For each
selectable mailbox matching the list pattern and selection selectable mailbox matching the list pattern and selection
options, the server MUST return an untagged LIST response options, the server MUST return an untagged LIST response
followed by an untagged STATUS response containing the followed by an untagged STATUS response containing the
information requested in the STATUS return option. information requested in the STATUS return option.
If an attempted STATUS for a listed mailbox fails because the If an attempted STATUS for a listed mailbox fails because the
skipping to change at page 58, line 50 skipping to change at page 58, line 50
S: * LIST (\Subscribed) "/" "eps2" ("CHILDINFO" ("SUBSCRIBED")) S: * LIST (\Subscribed) "/" "eps2" ("CHILDINFO" ("SUBSCRIBED"))
S: * LIST (\Subscribed) "/" "eps2/mamba" S: * LIST (\Subscribed) "/" "eps2/mamba"
S: * LIST (\Subscribed) "/" "qux2/bar2" S: * LIST (\Subscribed) "/" "qux2/bar2"
S: D03 OK done S: D03 OK done
The LIST responses for mailboxes "foo2", "baz2", and "eps2" The LIST responses for mailboxes "foo2", "baz2", and "eps2"
still have the CHILDINFO extended data item, even though this still have the CHILDINFO extended data item, even though this
information is redundant and the client can determine it by information is redundant and the client can determine it by
itself. itself.
10:
10: The following example shows usage of extended syntax for mailbox 10: The following example shows usage of extended syntax for mailbox
pattern. It also demonstrates that the presence of the pattern. It also demonstrates that the presence of the
CHILDINFO extended data item doesn't necessarily imply CHILDINFO extended data item doesn't necessarily imply
\HasChildren. \HasChildren.
C: a1 LIST "" ("foo") C: a1 LIST "" ("foo")
S: * LIST () "/" foo S: * LIST () "/" foo
S: a1 OK done S: a1 OK done
C: a2 LIST (SUBSCRIBED) "" "foo/*" C: a2 LIST (SUBSCRIBED) "" "foo/*"
skipping to change at page 65, line 48 skipping to change at page 65, line 48
slow. In some implementations, the server is obliged to open the slow. In some implementations, the server is obliged to open the
mailbox read-only internally to obtain certain status information. mailbox read-only internally to obtain certain status information.
Also unlike the LIST command, the STATUS command does not accept Also unlike the LIST command, the STATUS command does not accept
wildcards. wildcards.
Note: The STATUS command is intended to access the status of Note: The STATUS command is intended to access the status of
mailboxes other than the currently selected mailbox. Because the mailboxes other than the currently selected mailbox. Because the
STATUS command can cause the mailbox to be opened internally, and STATUS command can cause the mailbox to be opened internally, and
because this information is available by other means on the because this information is available by other means on the
selected mailbox, the STATUS command SHOULD NOT be used on the selected mailbox, the STATUS command SHOULD NOT be used on the
currently selected mailbox. currently selected mailbox. However, servers MUST be able to
execute STATUS command on the selected mailbox. (This might also
implicitly happen when STATUS return option is used in a LIST
command).
The STATUS command MUST NOT be used as a "check for new messages The STATUS command MUST NOT be used as a "check for new messages
in the selected mailbox" operation (refer to sections Section 7, in the selected mailbox" operation (refer to sections Section 7,
Section 7.3.1 for more information about the proper method for new Section 7.3.1 for more information about the proper method for new
message checking). message checking).
STATUS SIZE (see below) can take a significant amount of time, STATUS SIZE (see below) can take a significant amount of time,
depending upon server implementation. Clients should use STATUS depending upon server implementation. Clients should use STATUS
SIZE cautiously. SIZE cautiously.
skipping to change at page 66, line 30 skipping to change at page 66, line 33
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. 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 75, line 19 skipping to change at page 75, line 19
how it is affected by other commands executed, and how SAVE how it is affected by other commands executed, and how SAVE
return option interacts with other return options. return option interacts with other return options.
In absence of any other SEARCH result option, the SAVE result In absence of any other SEARCH result option, the SAVE result
option also suppresses any ESEARCH response that would have option also suppresses any ESEARCH response that would have
been otherwise returned by the SEARCH command. been otherwise returned by the SEARCH command.
Note: future extensions to this document can allow servers to return Note: future extensions to this document can allow servers to return
multiple ESEARCH responses for a single extended SEARCH command. multiple ESEARCH responses for a single extended SEARCH command.
However all options specified above MUST result in a single ESEARCH However all options specified above MUST result in a single ESEARCH
response. response. These extensions will have to describe how results from
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 with INTERNALDATE greater than February
February 1, 1994. A search key can also be a parenthesized list of 1, 1994. A search key can also be a parenthesized list of one or
one or more search keys (e.g., for use with the OR and NOT keys). more search keys (e.g., for use with the OR and NOT keys).
Server implementations MAY exclude [MIME-IMB] body parts with Server implementations MAY exclude [MIME-IMB] body parts with
terminal content media types other than TEXT and MESSAGE from terminal content media types other than TEXT and MESSAGE from
consideration in SEARCH matching. consideration in SEARCH matching.
The OPTIONAL [CHARSET] specification consists of the word "CHARSET" The OPTIONAL [CHARSET] specification consists of the word "CHARSET"
followed by a registered [CHARSET]. It indicates the [CHARSET] of followed by a registered [CHARSET]. 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. Servers MUST support headers, MUST be decoded before comparing text. Servers MUST support
skipping to change at page 76, line 16 skipping to change at page 76, line 16
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 83, line 5 skipping to change at page 83, line 5
Note: Since this document format is restricted to 7-bit ASCII text, Note: Since this document format is restricted to 7-bit ASCII text,
it is not possible to show actual UTF-8 data. The "YYYYYYYY" is a it is not possible to show actual UTF-8 data. The "YYYYYYYY" is a
placeholder for what would be 8 octets of 8-bit data in an actual placeholder for what would be 8 octets of 8-bit data in an actual
transaction. transaction.
4) The following example demonstrates that a failed SEARCH sets the 4) The following example demonstrates that a failed SEARCH sets the
search result variable to the empty list. The server doesn't search result variable to the empty list. The server doesn't
implement the KOI8-R charset. implement the KOI8-R charset.
Example 5: Example 5:
C: B282 SEARCH RETURN (SAVE) SINCE 1-Feb-1994 C: B282 SEARCH RETURN (SAVE) SINCE 1-Feb-1994
NOT FROM "Smith" NOT FROM "Smith"
S: B282 OK SEARCH completed S: B282 OK SEARCH completed
C: B283 SEARCH CHARSET KOI8-R (OR $ 1,3000:3021) TEXT {4} C: B283 SEARCH RETURN (SAVE) CHARSET KOI8-R
C: XXXX (OR $ 1,3000:3021) TEXT {4}
S: B283 NO [BADCHARSET UTF-8] KOI8-R is not supported C: XXXX
S: B283 NO [BADCHARSET UTF-8] KOI8-R is not supported
//After this command the saved result variable contains //After this command the saved result variable contains
//no messages. A client that wants to reissue the B283 //no messages. A client that wants to reissue the B283
//SEARCH command with another CHARSET would have to reissue //SEARCH command with another CHARSET would have to reissue
//the B282 command as well. One possible workaround for //the B282 command as well. One possible workaround for
//this is to include the desired CHARSET parameter //this is to include the desired CHARSET parameter
//in the earliest SEARCH RETURN (SAVE) command in a //in the earliest SEARCH RETURN (SAVE) command in a
//sequence of related SEARCH commands. //sequence of related SEARCH commands, to cause
//the earliest SEARCH in the sequence to fail.
//A better approach might be to always use CHARSET UTF-8 //A better approach might be to always use CHARSET UTF-8
//instead. //instead.
Note: Since this document format is restricted to 7-bit ASCII text, Note: Since this document format is restricted to 7-bit ASCII text,
it is not possible to show actual KOI8-R data. The "XXXX" is a it is not possible to show actual KOI8-R data. The "XXXX" is a
placeholder for what would be 4 octets of 8-bit data in an actual placeholder for what would be 4 octets of 8-bit data in an actual
transaction. transaction.
5) The following example demonstrates that it is not an error to use 5) The following example demonstrates that it is not an error to use
the "$" marker when it contains no messages. the "$" marker when it contains no messages.
Example 6: Example 6:
C: E282 SEARCH RETURN (SAVE) SINCE 28-Oct-2006 C: E282 SEARCH RETURN (SAVE) SINCE 28-Oct-2006
NOT FROM "Eric" NOT FROM "Eric"
C: E283 COPY $ "Other Messages" C: E283 COPY $ "Other Messages"
//The "$" contains no messages //The "$" contains no messages
S: E282 OK SEARCH completed S: E282 OK SEARCH completed
S: E283 OK COPY completed, nothing copied S: E283 OK COPY completed, nothing copied
Example 7: Example 7:
C: F282 SEARCH RETURN (SAVE) KEYWORD $Junk C: F282 SEARCH RETURN (SAVE) KEYWORD $Junk
C: F283 COPY $ "Junk" C: F283 COPY $ "Junk"
C: F284 STORE $ +FLAGS.Silent (\Deleted) C: F284 STORE $ +FLAGS.Silent (\Deleted)
S: F282 OK SEARCH completed S: F282 OK SEARCH completed
S: F283 OK COPY completed S: F283 OK COPY completed
S: F284 OK STORE completed S: F284 OK STORE completed
skipping to change at page 84, line 28 skipping to change at page 84, line 28
Example 9: Example 9:
C: H282 SEARCH RETURN (SAVE) KEYWORD $Junk C: H282 SEARCH RETURN (SAVE) KEYWORD $Junk
C: H283 SEARCH RETURN (SAVE) SINCE 28-Oct-2006 C: H283 SEARCH RETURN (SAVE) SINCE 28-Oct-2006
FROM "Eric" FROM "Eric"
S: H282 OK SEARCH completed S: H282 OK SEARCH completed
S: H283 OK SEARCH completed S: H283 OK SEARCH completed
// At this point "$" would contain results of H283 // At this point "$" would contain results of H283
The following example demonstrates behavioral difference for The following example demonstrates behavioral difference for
different combinations of ESEARCH result options. Explanatory different combinations of ESEARCH result options.
comments start with // and are not part of the protocol:
Example 10: Example 10:
C: C282 SEARCH RETURN (ALL) SINCE 12-Feb-2006 C: C282 SEARCH RETURN (ALL) SINCE 12-Feb-2006
NOT FROM "Smith" NOT FROM "Smith"
S: * ESEARCH (TAG "C283") ALL 2,10:15,21 S: * ESEARCH (TAG "C283") ALL 2,10:15,21
//$ value hasn't changed //$ value hasn't changed
S: C282 OK SEARCH completed S: C282 OK SEARCH completed
C: C283 SEARCH RETURN (ALL SAVE) SINCE 12-Feb-2006 C: C283 SEARCH RETURN (ALL SAVE) SINCE 12-Feb-2006
NOT FROM "Smith" NOT FROM "Smith"
skipping to change at page 97, line 42 skipping to change at page 97, line 42
The human-readable text contains a special alert that MUST be The human-readable text contains a special alert that MUST be
presented to the user in a fashion that calls the user's presented to the user in a fashion that calls the user's
attention to the message. attention to the message.
ALREADYEXISTS ALREADYEXISTS
The operation attempts to create something that already exists, The operation attempts to create something that already exists,
such as when the CREATE or RENAME directories attempt to create such as when the CREATE or RENAME directories attempt to create
a mailbox and there is already one of that name. a mailbox and there is already one of that name.
C: o RENAME this that C: o356 RENAME this that
S: o NO [ALREADYEXISTS] Mailbox "that" already exists S: o356 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
UID assigned to the appended message in the destination UID assigned to the appended message in the destination
mailbox, indicates that the message has been appended to the mailbox, indicates that the message has been appended to the
destination mailbox with that UID. destination mailbox with that UID.
If the server also supports the [MULTIAPPEND] extension, and if If the server also supports the [MULTIAPPEND] extension, and if
multiple messages were appended in the APPEND command, then the multiple messages were appended in the APPEND command, then the
skipping to change at page 112, line 10 skipping to change at page 112, line 10
hierarchy exists; the name is a "flat" name. hierarchy exists; the name is a "flat" name.
The name represents an unambiguous left-to-right hierarchy, and MUST The name represents an unambiguous left-to-right hierarchy, and MUST
be valid for use as a reference in LIST command. Unless \Noselect or be valid for use as a reference in LIST command. Unless \Noselect or
\NonExistent is indicated, the name MUST also be valid as an argument \NonExistent is indicated, the name MUST also be valid as an argument
for commands, such as SELECT, that accept mailbox names. for commands, such as SELECT, that accept mailbox names.
The name might be followed by an OPTIONAL series of extended fields, The name might be followed by an OPTIONAL series of extended fields,
a parenthesized list of tagged data (also referred to as "extended a parenthesized list of tagged data (also referred to as "extended
data item"). The first element of an extended field is a tag, which data item"). The first element of an extended field is a tag, which
identifies the type of data. identifies the type of data. The server MAY return data in the
extended fields that was not directly solicited by the client in the
The server MAY return data in the extended fields that was not corresponding LIST command. For example, the client can enable extra
directly solicited by the client in the corresponding LIST command. extended fields by using another IMAP extension that make use of the
For example, the client can enable extra extended fields by using extended LIST responses. The client MUST ignore all extended fields
another IMAP extension that make use of the extended LIST responses. it doesn't recognize.
The client MUST ignore all extended fields it doesn't recognize.
Example: S: * LIST (\Noselect) "/" ~/Mail/foo Example: S: * LIST (\Noselect) "/" ~/Mail/foo
Example: S: * LIST (\Marked) ":" Tables (tablecloth (("edge" "lacy") Example: S: * LIST (\Marked) ":" Tables (tablecloth (("edge" "lacy")
("color" "red")) Sample "text") ("color" "red")) Sample "text")
S: * LIST () ":" Tables:new (tablecloth ("edge" "lacy") S: * LIST () ":" Tables:new (tablecloth ("edge" "lacy")
Sample ("text" "more text")) Sample ("text" "more text"))
7.2.4. NAMESPACE Response 7.2.4. NAMESPACE Response
skipping to change at page 117, line 43 skipping to change at page 117, 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]. "baz"] as defined in [MIME-IMB]. Servers SHOULD decode
body parameter parenthesized list Servers SHOULD decode
parameter value continuations as described in [RFC2231], for parameter value continuations as described in [RFC2231], for
example, if the message contains parameters "foo*0*" and example, if the message contains parameters "foo*0*" and
"foo*1*", the server should RFC2231-decode them, concatenate "foo*1*", the server should RFC2231-decode them, concatenate
and return the resulting value as "foo*". and return the resulting value as "foo*".
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].
body location A string giving the body content URI as defined body location A string giving the body content URI as defined
in [LOCATION]. in [LOCATION].
Any following extension data are not yet defined in this Any following extension data are not yet defined in this
skipping to change at page 120, line 8 skipping to change at page 120, line 8
The fields of the envelope structure are in the following The fields of the envelope structure are in the following
order: date, subject, from, sender, reply-to, to, cc, bcc, in- order: date, subject, from, sender, reply-to, to, cc, bcc, in-
reply-to, and message-id. The date, subject, in-reply-to, and reply-to, and message-id. The date, subject, in-reply-to, and
message-id fields are strings. The from, sender, reply-to, to, message-id fields are strings. The from, sender, reply-to, to,
cc, and bcc fields are parenthesized lists of address cc, and bcc fields are parenthesized lists of address
structures. structures.
An address structure is a parenthesized list that describes an An address structure is a parenthesized list that describes an
electronic mail address. The fields of an address structure electronic mail address. The fields of an address structure
are in the following order: personal name, [SMTP] at-domain- are in the following order: personal name, [SMTP] at-domain-
list (source route), mailbox name, and host name. list (source route, obs-route), mailbox name, and host name.
[RFC-5322] group syntax is indicated by a special form of [RFC-5322] group syntax is indicated by a special form of
address structure in which the host name field is NIL. If the address structure in which the host name field is NIL. If the
mailbox name field is also NIL, this is an end of group marker mailbox name field is also NIL, this is an end of group marker
(semi-colon in RFC 822 syntax). If the mailbox name field is (semi-colon in RFC 822 syntax). If the mailbox name field is
non-NIL, this is a start of group marker, and the mailbox name non-NIL, this is a start of group marker, and the mailbox name
field holds the group name phrase. field holds the group name phrase.
If the Date, Subject, In-Reply-To, and Message-ID header lines If the Date, Subject, In-Reply-To, and Message-ID header lines
are absent in the [RFC-5322] header, the corresponding member are absent in the [RFC-5322] header, the corresponding member
skipping to change at page 123, line 29 skipping to change at page 123, line 29
(2) In all cases, SP refers to exactly one space. It is NOT (2) In all cases, SP refers to exactly one space. It is NOT
permitted to substitute TAB, insert additional spaces, or permitted to substitute TAB, insert additional spaces, or
otherwise treat SP as being equivalent to LWSP. otherwise treat SP as being equivalent to LWSP.
(3) The ASCII NUL character, %x00, MUST NOT be used at any time. (3) The ASCII NUL character, %x00, MUST NOT be used at any time.
address = "(" addr-name SP addr-adl SP addr-mailbox SP address = "(" addr-name SP addr-adl SP addr-mailbox SP
addr-host ")" addr-host ")"
addr-adl = nstring addr-adl = nstring
; Holds route from [RFC-5322] route-addr if ; Holds route from [RFC-5322] obs-route if
; non-NIL ; non-NIL
addr-host = nstring addr-host = nstring
; NIL indicates [RFC-5322] group syntax. ; NIL indicates [RFC-5322] group syntax.
; Otherwise, holds [RFC-5322] domain name ; Otherwise, holds [RFC-5322] domain name
addr-mailbox = nstring addr-mailbox = nstring
; NIL indicates end of [RFC-5322] group; if ; NIL indicates end of [RFC-5322] group; if
; non-NIL and addr-host is NIL, holds ; non-NIL and addr-host is NIL, holds
; [RFC-5322] group name. ; [RFC-5322] group name.
skipping to change at page 140, line 8 skipping to change at page 140, line 8
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]. recommendations from [RFC8314]. Additionally, when using TLS 1.2,
IMAP implementations MUST implement
Additionally, when using TLS 1.2, IMAP implementations MUST implement
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite, and SHOULD TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite, 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 147, line 46 skipping to change at page 147, line 38
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 Servers advertising both IMAP4rev1 and IMAP4rev2 SHOULD NOT generate
UTF-8 quoted strings unless the client has issued "ENABLE IMAP4rev2".
generate UTF-8 quoted strings unless the client has issued "ENABLE Consider implementation of mechanisms described or referenced in
IMAP4rev2". Consider implementation of mechanisms described or [IMAP-UTF-8] to achieve this goal.
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 150, line 34 skipping to change at page 150, line 29
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 - done, STATUS-in-LIST - done, SEARCHRES, BINARY (only patterns - done, STATUS-in-LIST - done, SEARCHRES, BINARY (only
the FETCH changes on leaf body part and make APPEND related ones the FETCH changes on leaf body part and make APPEND related ones
optional. See the mailing list discussion) - done. optional. See the mailing list discussion) - done.
6.
7. Add STATUS SIZE (total mailbox size) - done. Add STATUS DELETED 7. Add STATUS SIZE (total mailbox size) - done. Add STATUS DELETED
(number of messages with \Deleted flag set) - done. (number of messages with \Deleted flag set) - done.
8. Drop UTF-7, all mailboxes are always in UTF-8 - done. 8. Drop UTF-7, all mailboxes are always in UTF-8 - done.
9. 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.
10. 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
skipping to change at page 152, line 29 skipping to change at page 152, line 21
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 (by Mark Crispin), RFC This document incorporate text from RFC 4315 (by Mark Crispin), RFC
4466 (by Cyrus Daboo), RFC 4731 (by Dave Cridland), RFC 5161 (by Arnt 4466 (by Cyrus Daboo), RFC 4731 (by Dave Cridland), RFC 5161 (by Arnt
Gulbrandsen), RFC 5530 (by Arnt Gulbrandsen), RFC 5819 (by Timo Gulbrandsen), RFC 5530 (by Arnt Gulbrandsen), RFC 5819 (by Timo
Sirainen), RFC 6154 (by Jamie Nicolson) Sirainen), RFC 6154 (by Jamie Nicolson) so work done by authors/
editors of these documents is appreciated. Note that editors of this
so work done by authors/editors of these documents is appreciated. document were redacted from the above list.
Note that editors of this document were redacted from the above list.
Index Index
$ $
$Forwarded (predefined flag) 12 $Forwarded (predefined flag) 12
$MDNSent (predefined flag) 12 $MDNSent (predefined flag) 12
+ +
+FLAGS <flag list> 90 +FLAGS <flag list> 90
+FLAGS.SILENT <flag list> 90 +FLAGS.SILENT <flag list> 90
skipping to change at page 157, line 20 skipping to change at page 157, line 12
X X
X<atom> (command) 95 X<atom> (command) 95
[ [
[RFC-5322] Size (message attribute) 13 [RFC-5322] Size (message attribute) 13
\ \
\All (mailbox name attribute) 110 \All (mailbox name attribute) 110
\Answered (system flag) 11 \Answered (system flag) 11
\Archive (mailbox name attribute) 110 \Archive (mailbox name attribute) 110
\Deleted (system flag) 12 \Deleted (system flag) 11
\Draft (system flag) 12 \Draft (system flag) 12
\Drafts (mailbox name attribute) 110 \Drafts (mailbox name attribute) 110
\Flagged (mailbox name attribute) 111 \Flagged (mailbox name attribute) 111
\Flagged (system flag) 11 \Flagged (system flag) 11
\HasChildren (mailbox name attribute) 109 \HasChildren (mailbox name attribute) 109
\HasNoChildren (mailbox name attribute) 109 \HasNoChildren (mailbox name attribute) 109
\Junk (mailbox name attribute) 111 \Junk (mailbox name attribute) 111
\Marked (mailbox name attribute) 110 \Marked (mailbox name attribute) 110
\Noinferiors (mailbox name attribute) 109 \Noinferiors (mailbox name attribute) 109
\NonExistent (mailbox name attribute) 109 \NonExistent (mailbox name attribute) 109
 End of changes. 48 change blocks. 
106 lines changed or deleted 86 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/