< draft-ietf-extra-imap4rev2-22.txt   draft-ietf-extra-imap4rev2-23.txt >
Network Working Group A. Melnikov, Ed. Network Working Group A. Melnikov, Ed.
Internet-Draft Isode Ltd Internet-Draft Isode Ltd
Obsoletes: 3501 (if approved) B. Leiba, Ed. Obsoletes: 3501 (if approved) B. Leiba, Ed.
Intended status: Standards Track Futurewei Technologies Intended status: Standards Track Futurewei Technologies
Expires: July 4, 2021 December 31, 2020 Expires: July 8, 2021 January 4, 2021
Internet Message Access Protocol (IMAP) - Version 4rev2 Internet Message Access Protocol (IMAP) - Version 4rev2
draft-ietf-extra-imap4rev2-22 draft-ietf-extra-imap4rev2-23
Abstract Abstract
The Internet Message Access Protocol, Version 4rev2 (IMAP4rev2) The Internet Message Access Protocol, Version 4rev2 (IMAP4rev2)
allows a client to access and manipulate electronic mail messages on allows a client to access and manipulate electronic mail messages on
a server. IMAP4rev2 permits manipulation of mailboxes (remote a server. IMAP4rev2 permits manipulation of mailboxes (remote
message folders) in a way that is functionally equivalent to local message folders) in a way that is functionally equivalent to local
folders. IMAP4rev2 also provides the capability for an offline folders. IMAP4rev2 also provides the capability for an offline
client to resynchronize with the server. client to resynchronize with the server.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 4, 2021. This Internet-Draft will expire on July 8, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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 42 skipping to change at page 3, line 42
6.3. Client Commands - Authenticated State . . . . . . . . . . 33 6.3. Client Commands - Authenticated State . . . . . . . . . . 33
6.3.1. ENABLE Command . . . . . . . . . . . . . . . . . . . 33 6.3.1. ENABLE Command . . . . . . . . . . . . . . . . . . . 33
6.3.2. SELECT Command . . . . . . . . . . . . . . . . . . . 35 6.3.2. SELECT Command . . . . . . . . . . . . . . . . . . . 35
6.3.3. EXAMINE Command . . . . . . . . . . . . . . . . . . . 37 6.3.3. EXAMINE Command . . . . . . . . . . . . . . . . . . . 37
6.3.4. CREATE Command . . . . . . . . . . . . . . . . . . . 38 6.3.4. CREATE Command . . . . . . . . . . . . . . . . . . . 38
6.3.5. DELETE Command . . . . . . . . . . . . . . . . . . . 39 6.3.5. DELETE Command . . . . . . . . . . . . . . . . . . . 39
6.3.6. RENAME Command . . . . . . . . . . . . . . . . . . . 41 6.3.6. RENAME Command . . . . . . . . . . . . . . . . . . . 41
6.3.7. SUBSCRIBE Command . . . . . . . . . . . . . . . . . . 43 6.3.7. SUBSCRIBE Command . . . . . . . . . . . . . . . . . . 43
6.3.8. UNSUBSCRIBE Command . . . . . . . . . . . . . . . . . 44 6.3.8. UNSUBSCRIBE Command . . . . . . . . . . . . . . . . . 44
6.3.9. LIST Command . . . . . . . . . . . . . . . . . . . . 44 6.3.9. LIST Command . . . . . . . . . . . . . . . . . . . . 44
6.3.10. NAMESPACE Command . . . . . . . . . . . . . . . . . . 62 6.3.10. NAMESPACE Command . . . . . . . . . . . . . . . . . . 63
6.3.11. STATUS Command . . . . . . . . . . . . . . . . . . . 67 6.3.11. STATUS Command . . . . . . . . . . . . . . . . . . . 67
6.3.12. APPEND Command . . . . . . . . . . . . . . . . . . . 68 6.3.12. APPEND Command . . . . . . . . . . . . . . . . . . . 68
6.3.13. IDLE Command . . . . . . . . . . . . . . . . . . . . 71 6.3.13. IDLE Command . . . . . . . . . . . . . . . . . . . . 71
6.4. Client Commands - Selected State . . . . . . . . . . . . 73 6.4. Client Commands - Selected State . . . . . . . . . . . . 73
6.4.1. CLOSE Command . . . . . . . . . . . . . . . . . . . . 74 6.4.1. CLOSE Command . . . . . . . . . . . . . . . . . . . . 74
6.4.2. UNSELECT Command . . . . . . . . . . . . . . . . . . 74 6.4.2. UNSELECT Command . . . . . . . . . . . . . . . . . . 74
6.4.3. EXPUNGE Command . . . . . . . . . . . . . . . . . . . 75 6.4.3. EXPUNGE Command . . . . . . . . . . . . . . . . . . . 75
6.4.4. SEARCH Command . . . . . . . . . . . . . . . . . . . 75 6.4.4. SEARCH Command . . . . . . . . . . . . . . . . . . . 75
6.4.5. FETCH Command . . . . . . . . . . . . . . . . . . . . 87 6.4.5. FETCH Command . . . . . . . . . . . . . . . . . . . . 87
6.4.6. STORE Command . . . . . . . . . . . . . . . . . . . . 92 6.4.6. STORE Command . . . . . . . . . . . . . . . . . . . . 92
skipping to change at page 5, line 37 skipping to change at page 5, line 37
is almost impossible to understand any of them separately. In is almost impossible to understand any of them separately. In
particular, do not attempt to deduce command syntax from the command particular, do not attempt to deduce command syntax from the command
section alone; instead refer to the Formal Syntax section. section alone; instead refer to the Formal Syntax section.
1.2. Conventions Used in This Document 1.2. Conventions Used in This Document
"Conventions" are basic principles or procedures. Document "Conventions" are basic principles or procedures. Document
conventions are noted in this section. conventions are noted in this section.
In examples, "C:" and "S:" indicate lines sent by the client and In examples, "C:" and "S:" indicate lines sent by the client and
server respectively. server respectively. Note that each line includes the terminating
CRLF.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The word "can" (not "may") is used to refer to a possible The word "can" (not "may") is used to refer to a possible
circumstance or situation, as opposed to an optional facility of the circumstance or situation, as opposed to an optional facility of the
protocol. protocol.
skipping to change at page 9, line 31 skipping to change at page 9, line 31
associated with it. These attributes can be retrieved individually associated with it. These attributes can be retrieved individually
or in conjunction with other attributes or message texts. or in conjunction with other attributes or message texts.
2.3.1. Message Numbers 2.3.1. Message Numbers
Messages in IMAP4rev2 are accessed by one of two numbers; the unique Messages in IMAP4rev2 are accessed by one of two numbers; the unique
identifier or the message sequence number. identifier or the message sequence number.
2.3.1.1. Unique Identifier (UID) Message Attribute 2.3.1.1. Unique Identifier (UID) Message Attribute
An unsigned non-zero 32-bit value assigned to each message, which A UID is an unsigned non-zero 32-bit value assigned to each message,
when used with the unique identifier validity value (see below) forms which when used with the unique identifier validity value (see below)
a 64-bit value that MUST NOT refer to any other message in the forms a 64-bit value that MUST NOT refer to any other message in the
mailbox or any subsequent mailbox with the same name forever. Unique mailbox or any subsequent mailbox with the same name forever. Unique
identifiers are assigned in a strictly ascending fashion in the identifiers are assigned in a strictly ascending fashion in the
mailbox; as each message is added to the mailbox it is assigned a mailbox; as each message is added to the mailbox it is assigned a
higher UID than the message(s) which were added previously. Unlike higher UID than the message(s) which were added previously. Unlike
message sequence numbers, unique identifiers are not necessarily message sequence numbers, unique identifiers are not necessarily
contiguous. contiguous.
The unique identifier of a message MUST NOT change during the The unique identifier of a message MUST NOT change during the
session, and SHOULD NOT change between sessions. Any change of session, and SHOULD NOT change between sessions. Any change of
unique identifiers between sessions MUST be detectable using the unique identifiers between sessions MUST be detectable using the
skipping to change at page 10, line 35 skipping to change at page 10, line 35
If unique identifiers from an earlier session fail to persist in this If unique identifiers from an earlier session fail to persist in this
session, the unique identifier validity value MUST be greater than session, the unique identifier validity value MUST be greater than
the one used in the earlier session. A good UIDVALIDITY value to use the one used in the earlier session. A good UIDVALIDITY value to use
is a 32-bit representation of the current date/time when the value is is a 32-bit representation of the current date/time when the value is
assigned: this ensures that the value is unique and always increases. assigned: this ensures that the value is unique and always increases.
Another possible alternative is a global counter that gets Another possible alternative is a global counter that gets
incremented every time a mailbox is created. incremented every time a mailbox is created.
Note: Ideally, unique identifiers SHOULD persist at all times. Note: Ideally, unique identifiers SHOULD persist at all times.
Although this specification recognizes that failure to persist can Although this specification recognizes that failure to persist can
be unavoidable in certain server environments, it STRONGLY be unavoidable in certain server environments, it strongly
ENCOURAGES message store implementation techniques that avoid this encourages message store implementation techniques that avoid this
problem. For example: problem. For example:
1. Unique identifiers MUST be strictly ascending in the mailbox 1. Unique identifiers MUST be strictly ascending in the mailbox
at all times. If the physical message store is re-ordered by at all times. If the physical message store is re-ordered by
a non-IMAP agent, this requires that the unique identifiers in a non-IMAP agent, this requires that the unique identifiers in
the mailbox be regenerated, since the former unique the mailbox be regenerated, since the former unique
identifiers are no longer strictly ascending as a result of identifiers are no longer strictly ascending as a result of
the re-ordering. the re-ordering.
2. If the message store has no mechanism to store unique 2. If the message store has no mechanism to store unique
skipping to change at page 11, line 20 skipping to change at page 11, line 20
server forever. In particular, the internal date, [RFC-5322] server forever. In particular, the internal date, [RFC-5322]
size, envelope, body structure, and message texts (all size, envelope, body structure, and message texts (all
BODY[...] fetch data items) must never change. This does not BODY[...] fetch data items) must never change. This does not
include message numbers, nor does it include attributes that include message numbers, nor does it include attributes that
can be set by a STORE command (e.g., FLAGS). When a message can be set by a STORE command (e.g., FLAGS). When a message
is expunged, its UID MUST NOT be reused under the same is expunged, its UID MUST NOT be reused under the same
UIDVALIDITY value. UIDVALIDITY value.
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 Message Sequence Number is a relative position from 1 to the number
This position MUST be ordered by ascending unique identifier. As of messages in the mailbox. This position MUST be ordered by
each new message is added, it is assigned a message sequence number ascending unique identifier. As each new message is added, it is
that is 1 higher than the number of messages in the mailbox before assigned a message sequence number that is 1 higher than the number
that new message was added. of messages in the mailbox before 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
example, when a message is permanently removed (expunged) from the example, when a message is permanently removed (expunged) from the
mailbox, the message sequence number for all subsequent messages is mailbox, the message sequence number for all subsequent messages is
decremented. The number of messages in the mailbox is also decremented. The number of messages in the mailbox is also
decremented. Similarly, a new message can be assigned a message decremented. Similarly, a new message can be assigned a message
sequence number that was once held by some other message prior to an sequence number that was once held by some other message prior to an
expunge. expunge.
In addition to accessing messages by relative position in the In addition to accessing messages by relative position in the
mailbox, message sequence numbers can be used in mathematical mailbox, message sequence numbers can be used in mathematical
calculations. For example, if an untagged "11 EXISTS" is received, calculations. For example, if an untagged "11 EXISTS" is received,
and previously an untagged "8 EXISTS" was received, three new and previously an untagged "8 EXISTS" was received, three new
messages have arrived with message sequence numbers of 9, 10, and 11. messages have arrived with message sequence numbers of 9, 10, and 11.
Another example, if message 287 in a 523 message mailbox has UID Another example, if message 287 in a 523 message mailbox has UID
12345, there are exactly 286 messages which have lesser UIDs and 236 12345, there are exactly 286 messages which have lesser UIDs and 236
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 message has associated with it a list of zero or more named tokens,
flag is set by its addition to this list, and is cleared by its known as "flags". A flag is set by its addition to this list, and is
removal. There are two types of flags in IMAP4rev2. A flag of cleared by its removal. There are two types of flags in IMAP4rev2:
either type can be permanent or session-only. system flags, and keywords. A flag of either type can also 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 begins with "\". Certain system flags (\Deleted
\Seen) have special semantics described elsewhere in this document. and \Seen) have special semantics described elsewhere in this
The currently-defined system flags are: 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 use in IMAP4rev1 and is now deprecated.
A keyword is defined by the server implementation. Keywords do not A keyword is defined by the server implementation. Keywords do not
begin with "\". Servers MAY permit the client to define new keywords begin with "\". Servers MAY permit the client to define new keywords
in the mailbox (see the description of the PERMANENTFLAGS response in the mailbox (see the description of the PERMANENTFLAGS response
code for more information). Some keywords that start with "$" are code for more information). Some keywords that start with "$" are
also defined in this specification. also defined in this specification.
This document defines several keywords that were not originally This document defines several keywords that were not originally
defined in RFC 3501, but which were found to be useful by client defined in RFC 3501, but which were found to be useful by client
implementations. These keywords SHOULD be supported (i.e. allowed in implementations. These keywords SHOULD be supported (i.e. allowed in
skipping to change at page 13, line 46 skipping to change at page 13, line 50
[RFC5788]. [RFC5788].
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 An Internal Date message attribute is the internal date and time of
the date and time in the [RFC-5322] header, but rather a date and the message on the server. This is not the date and time in the
time which reflects when the message was received. In the case of [RFC-5322] header, but rather a date and time which reflects when the
messages delivered via [SMTP], this SHOULD be the date and time of message was received. In the case of messages delivered via [SMTP],
final delivery of the message as defined by [SMTP]. In the case of this is the date and time of final delivery of the message as defined
messages delivered by the IMAP4rev2 COPY or MOVE command, this SHOULD by [SMTP]. In the case of messages delivered by the IMAP4rev2 COPY
be the internal date and time of the source message. In the case of or MOVE command, this SHOULD be the internal date and time of the
messages delivered by the IMAP4rev2 APPEND command, this SHOULD be source message. In the case of messages delivered by the IMAP4rev2
the date and time as specified in the APPEND command description. APPEND command, this SHOULD be the date and time as specified in the
All other cases are implementation defined. APPEND command description. All other cases are implementation
defined.
2.3.4. [RFC-5322] Size Message Attribute 2.3.4. [RFC-5322] Size Message Attribute
The number of octets in the message, as expressed in [RFC-5322] An RFC 5322 size is the number of octets in the message, as expressed
format. in [RFC-5322] format.
2.3.5. Envelope Structure Message Attribute 2.3.5. Envelope Structure Message Attribute
A parsed representation of the [RFC-5322] header of the message. An Envelope Structure is a parsed representation of the [RFC-5322]
Note that the IMAP Envelope structure is not the same as an [SMTP] header of the message. Note that the IMAP Envelope structure is not
envelope. the same as an [SMTP] envelope.
2.3.6. Body Structure Message Attribute 2.3.6. Body Structure Message Attribute
A parsed representation of the [MIME-IMB] body structure information A Body Structure is a parsed representation of the [MIME-IMB] body
of the message. structure information of the message.
2.4. Message Texts 2.4. Message Texts
In addition to being able to fetch the full [RFC-5322] text of a In addition to being able to fetch the full [RFC-5322] text of a
message, IMAP4rev2 permits the fetching of portions of the full message, IMAP4rev2 permits the fetching of portions of the full
message text. Specifically, it is possible to fetch the [RFC-5322] message text. Specifically, it is possible to fetch the [RFC-5322]
message header, [RFC-5322] message body, a [MIME-IMB] body part, or a message header, [RFC-5322] message body, a [MIME-IMB] body part, or a
[MIME-IMB] header. [MIME-IMB] header.
3. State and Flow Diagram 3. State and Flow Diagram
skipping to change at page 18, line 7 skipping to change at page 18, line 7
A synchronizing literal is a sequence of zero or more octets A synchronizing literal is a sequence of zero or more octets
(including CR and LF), prefix-quoted with an octet count in the form (including CR and LF), prefix-quoted with an octet count in the form
of an open brace ("{"), the number of octets, close brace ("}"), and of an open brace ("{"), the number of octets, close brace ("}"), and
CRLF. In the case of synchronizing literals transmitted from server CRLF. In the case of synchronizing literals transmitted from server
to client, the CRLF is immediately followed by the octet data. In to client, the CRLF is immediately followed by the octet data. In
the case of synchronizing literals transmitted from client to server, the case of synchronizing literals transmitted from client to server,
the client MUST wait to receive a command continuation request the client MUST wait to receive a command continuation request
(described later in this document) before sending the octet data (and (described later in this document) before sending the octet data (and
the remainder of the command). the remainder of the command).
The non-synchronizing literal is an alternate form of synchronizing The non-synchronizing literal is an alternative form of synchronizing
literal, and it may appear in communication from client to server literal, and it may appear in communication from client to server
instead of the synchonizing form of literal. The non-synchronizing instead of the synchonizing form of literal. The non-synchronizing
literal form MUST NOT be sent from server to client. The non- literal form MUST NOT be sent from server to client. The non-
synchronizing literal is distinguished from the synchronizing literal synchronizing literal is distinguished from the synchronizing literal
by having a plus ("+") between the octet count and the closing brace by having a plus ("+") between the octet count and the closing brace
("}"). The server does not generate a command continuation request ("}"). The server does not generate a command continuation request
in response to a non-synchronizing literal, and clients are not in response to a non-synchronizing literal, and clients are not
required to wait before sending the octets of a non- synchronizing required to wait before sending the octets of a non- synchronizing
literal. Non-synchronizing literals MUST NOT be larger than 4096 literal. Non-synchronizing literals MUST NOT be larger than 4096
octets. Any literal larger than 4096 bytes MUST be sent as a octets. Any literal larger than 4096 bytes MUST be sent as a
skipping to change at page 22, line 35 skipping to change at page 22, line 35
For example, implementations which offer access to USENET For example, implementations which offer access to USENET
newsgroups MAY use the "#news" namespace to partition the USENET newsgroups MAY use the "#news" namespace to partition the USENET
newsgroup namespace from that of other mailboxes. Thus, the newsgroup namespace from that of other mailboxes. Thus, the
comp.mail.misc newsgroup would have a mailbox name of comp.mail.misc newsgroup would have a mailbox name of
"#news.comp.mail.misc", and the name "comp.mail.misc" can refer to "#news.comp.mail.misc", and the name "comp.mail.misc" can refer to
a different object (e.g., a user's private mailbox). a different object (e.g., a user's private mailbox).
Namespaces that include the "#" character are not IMAP URL [IMAP-URL] Namespaces that include the "#" character are not IMAP URL [IMAP-URL]
friendly requiring the "#" character to be represented as %23 when friendly requiring the "#" character to be represented as %23 when
within URLs. As such, server implementers MAY instead consider using within URLs. As such, server implementors MAY instead consider using
namespace prefixes that do not contain the "#" character. namespace prefixes that do not contain the "#" character.
5.1.2.2. Common namespace models 5.1.2.2. Common namespace models
Previous version of this protocol does not define a default server Previous version of this protocol does not define a default server
namespace. Two common namespace models have evolved: namespace. Two common namespace models have evolved:
The "Personal Mailbox" model, in which the default namespace that is The "Personal Mailbox" model, in which the default namespace that is
presented consists of only the user's personal mailboxes. To access presented consists of only the user's personal mailboxes. To access
shared mailboxes, the user must use an escape mechanism to reach shared mailboxes, the user must use an escape mechanism to reach
another namespace. another namespace.
The "Complete Hierarchy" model, in which the default namespace that The "Complete Hierarchy" model, in which the default namespace that
is presented includes the user's personal mailboxes along with any is presented includes the user's personal mailboxes along with any
other mailboxes they have access to. other mailboxes they have access to.
5.2. Mailbox Size and Message Status Updates 5.2. Mailbox Size and Message Status Updates
At any time, a server can send data that the client did not request. At any time, a server can send data that the client did not request.
Sometimes, such behavior is REQUIRED. For example, agents other than Sometimes, such behavior is required by this specification and/or
the server MAY add messages to the mailbox (e.g., new message extensions. For example, agents other than the server MAY add
delivery), change the flags of the messages in the mailbox (e.g., messages to the mailbox (e.g., new message delivery), change the
simultaneous access to the same mailbox by multiple agents), or even flags of the messages in the mailbox (e.g., simultaneous access to
remove messages from the mailbox. A server MUST send mailbox size the same mailbox by multiple agents), or even remove messages from
updates automatically if a mailbox size change is observed during the the mailbox. A server MUST send mailbox size updates automatically
processing of a command. A server SHOULD send message flag updates if a mailbox size change is observed during the processing of a
automatically, without requiring the client to request such updates command. A server SHOULD send message flag updates automatically,
explicitly. without requiring the client to request such updates explicitly.
Special rules exist for server notification of a client about the Special rules exist for server notification of a client about the
removal of messages to prevent synchronization errors; see the removal of messages to prevent synchronization errors; see the
description of the EXPUNGE response for more detail. In particular, description of the EXPUNGE response for more detail. In particular,
it is NOT permitted to send an EXISTS response that would reduce the it is NOT permitted to send an EXISTS response that would reduce the
number of messages in the mailbox; only the EXPUNGE response can do number of messages in the mailbox; only the EXPUNGE response can do
this. this.
Regardless of what implementation decisions a client makes on Regardless of what implementation decisions a client makes on
remembering data from the server, a client implementation MUST record remembering data from the server, a client implementation MUST record
skipping to change at page 23, line 43 skipping to change at page 23, line 43
(except for EXPUNGE) while there is no command in progress. Server (except for EXPUNGE) while there is no command in progress. Server
implementations that send such responses MUST deal with flow control implementations that send such responses MUST deal with flow control
considerations. Specifically, they MUST either (1) verify that the considerations. Specifically, they MUST either (1) verify that the
size of the data does not exceed the underlying transport's available size of the data does not exceed the underlying transport's available
window size, or (2) use non-blocking writes. window size, or (2) use non-blocking writes.
5.4. Autologout Timer 5.4. Autologout Timer
If a server has an inactivity autologout timer that applies to If a server has an inactivity autologout timer that applies to
sessions after authentication, the duration of that timer MUST be at sessions after authentication, the duration of that timer MUST be at
least 30 minutes. The receipt of ANY command from the client during least 30 minutes. The receipt of any command from the client during
that interval SHOULD suffice to reset the autologout timer. that interval resets the autologout timer.
5.5. Multiple Commands in Progress (Command Pipelining) 5.5. Multiple Commands in Progress (Command Pipelining)
The client MAY send another command without waiting for the The client MAY send another command without waiting for the
completion result response of a command, subject to ambiguity rules completion result response of a command, subject to ambiguity rules
(see below) and flow control constraints on the underlying data (see below) and flow control constraints on the underlying data
stream. Similarly, a server MAY begin processing another command stream. Similarly, a server MAY begin processing another command
before processing the current command to completion, subject to before processing the current command to completion, subject to
ambiguity rules. However, any command continuation request responses ambiguity rules. However, any command continuation request responses
and command continuations MUST be negotiated before any subsequent and command continuations MUST be negotiated before any subsequent
skipping to change at page 28, line 5 skipping to change at page 28, line 5
6.2. Client Commands - Not Authenticated State 6.2. Client Commands - Not Authenticated State
In the not authenticated state, the AUTHENTICATE or LOGIN command In the not authenticated state, the AUTHENTICATE or LOGIN command
establishes authentication and enters the authenticated state. The establishes authentication and enters the authenticated state. The
AUTHENTICATE command provides a general mechanism for a variety of AUTHENTICATE command provides a general mechanism for a variety of
authentication techniques, privacy protection, and integrity authentication techniques, privacy protection, and integrity
checking; whereas the LOGIN command uses a traditional user name and checking; whereas the LOGIN command uses a traditional user name and
plaintext password pair and has no means of establishing privacy plaintext password pair and has no means of establishing privacy
protection or integrity checking. protection or integrity checking.
The STARTTLS command is an alternate form of establishing session The STARTTLS command is an alternative form of establishing session
privacy protection and integrity checking, but does not by itself privacy protection and integrity checking, but does not by itself
establish authentication or enter the authenticated state. establish authentication or enter the authenticated state.
Server implementations MAY allow access to certain mailboxes without Server implementations MAY allow access to certain mailboxes without
establishing authentication. This can be done by means of the establishing authentication. This can be done by means of the
ANONYMOUS [SASL] authenticator described in [ANONYMOUS]. An older ANONYMOUS [SASL] authenticator described in [ANONYMOUS]. An older
convention is a LOGIN command using the userid "anonymous"; in this convention is a LOGIN command using the userid "anonymous"; in this
case, a password is required although the server may choose to accept case, a password is required although the server may choose to accept
any password. The restrictions placed on anonymous users are any password. The restrictions placed on anonymous users are
implementation-dependent. implementation-dependent.
skipping to change at page 34, line 30 skipping to change at page 34, line 30
specifically permitted to be enabled using ENABLE, the server MUST specifically permitted to be enabled using ENABLE, the server MUST
ignore the argument. (Note that knowing about an extension ignore the argument. (Note that knowing about an extension
doesn't necessarily imply supporting that extension.) doesn't necessarily imply supporting that extension.)
o If the argument is an extension that is supported by the server o If the argument is an extension that is supported by the server
and that needs to be enabled, the server MUST enable the extension and that needs to be enabled, the server MUST enable the extension
for the duration of the connection. Note that once an extension for the duration of the connection. Note that once an extension
is enabled, there is no way to disable it. is enabled, there is no way to disable it.
If the ENABLE command is successful, the server MUST send an untagged If the ENABLE command is successful, the server MUST send an untagged
ENABLED response Section 7.2.1. ENABLED response Section 7.2.1, which includes all enabled extensions
as specified above. The ENABLED response is sent even if no
extensions were enabled.
Clients SHOULD only include extensions that need to be enabled by the Clients SHOULD only include extensions that need to be enabled by the
server. For example, a client can enable IMAP4rev2 specific server. For example, a client can enable IMAP4rev2 specific
behaviour when both IMAP4rev1 and IMAP4rev2 are advertised in the behaviour when both IMAP4rev1 and IMAP4rev2 are advertised in the
CAPABILITY response. Future RFCs may add to this list. CAPABILITY response. Future RFCs may add to this list.
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
skipping to change at page 39, line 23 skipping to change at page 39, line 23
If the server's hierarchy separator character appears elsewhere in If the server's hierarchy separator character appears elsewhere in
the name, the server SHOULD create any superior hierarchical names the name, the server SHOULD create any superior hierarchical names
that are needed for the CREATE command to be successfully completed. that are needed for the CREATE command to be successfully completed.
In other words, an attempt to create "foo/bar/zap" on a server in In other words, an attempt to create "foo/bar/zap" on a server in
which "/" is the hierarchy separator character SHOULD create foo/ and which "/" is the hierarchy separator character SHOULD create foo/ and
foo/bar/ if they do not already exist. foo/bar/ if they do not already exist.
If a new mailbox is created with the same name as a mailbox which was If a new mailbox is created with the same name as a mailbox which was
deleted, its unique identifiers MUST be greater than any unique deleted, its unique identifiers MUST be greater than any unique
identifiers used in the previous incarnation of the mailbox UNLESS identifiers used in the previous incarnation of the mailbox 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.
Example: C: A003 CREATE owatagusiam/ Example: C: A003 CREATE owatagusiam/
S: A003 OK CREATE completed S: A003 OK CREATE completed
C: A004 CREATE owatagusiam/blurdybloop C: A004 CREATE owatagusiam/blurdybloop
S: A004 OK CREATE completed S: A004 OK CREATE completed
C: A005 CREATE NonNormalized C: A005 CREATE NonNormalized
S: * LIST () "/" "Normalized" ("OLDNAME" ("NonNormalized")) S: * LIST () "/" "Normalized" ("OLDNAME" ("NonNormalized"))
S: A005 OK CREATE completed S: A005 OK CREATE completed
skipping to change at page 40, line 34 skipping to change at page 40, line 34
command by returning a tagged NO response. The NO response SHOULD command by returning a tagged NO response. The NO response SHOULD
include the HASCHILDREN response code. Alternatively the server MAY include the HASCHILDREN response code. Alternatively the server MAY
allow the DELETE command, but sets the \Noselect mailbox name allow the DELETE command, but sets the \Noselect mailbox name
attribute for that name. attribute for that name.
If the server returns OK response, all messages in that mailbox are If the server returns OK response, all messages in that mailbox are
removed by the DELETE command. 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.
If the server decides to convert (normalize) the mailbox name, it If the server decides to convert (normalize) the mailbox name, it
SHOULD return an untagged LIST with the "\NonExistent" attribute and SHOULD return an untagged LIST with the "\NonExistent" attribute and
OLDNAME extended data item, with the OLDNAME value being the supplied OLDNAME extended data item, with the OLDNAME value being the supplied
mailbox name and the name parameter being the normalized mailbox mailbox name and the name parameter being the normalized mailbox
name. (See Section 6.3.9.7 for more details.) name. (See Section 6.3.9.7 for more details.)
Mailboxes deleted in one IMAP session MAY be announced to other IMAP Mailboxes deleted in one IMAP session MAY be announced to other IMAP
skipping to change at page 42, line 22 skipping to change at page 42, line 22
If the server's hierarchy separator character appears in the name, If the server's hierarchy separator character appears in the name,
the server SHOULD create any superior hierarchical names that are the server SHOULD create any superior hierarchical names that are
needed for the RENAME command to complete successfully. In other needed for the RENAME command to complete successfully. In other
words, an attempt to rename "foo/bar/zap" to baz/rag/zowie on a words, an attempt to rename "foo/bar/zap" to baz/rag/zowie on a
server in which "/" is the hierarchy separator character in the server in which "/" is the hierarchy separator character in the
corresponding namespace SHOULD create baz/ and baz/rag/ if they do corresponding namespace SHOULD create baz/ and baz/rag/ if they do
not already exist. not already exist.
The value of the highest-used unique identifier of the old mailbox The value of the highest-used unique identifier of the old mailbox
name MUST be preserved so that a new mailbox created with the same name 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.
Renaming INBOX is permitted, and has special behavior. (Note that Renaming INBOX is permitted (i.e. it doesn't result in a tagged BAD
some servers disallow renaming INBOX, so clients need to be able to response), and has special behavior. (Note that some servers
handle such RENAME failing). It moves all messages in INBOX to a new disallow renaming INBOX by returning a tagged NO response, so clients
mailbox with the given name, leaving INBOX empty. If the server need to be able to handle such RENAME failing). It moves all
implementation supports inferior hierarchical names of INBOX, these messages in INBOX to a new mailbox with the given name, leaving INBOX
are unaffected by a rename of INBOX. empty. If the server implementation supports inferior hierarchical
names of INBOX, these are unaffected by a rename of INBOX.
If the server allows creation of mailboxes with names that are not If the server allows creation of mailboxes with names that are not
valid Net-Unicode names, the server normalizes both the existing valid Net-Unicode names, the server normalizes both the existing
mailbox name parameter and the new mailbox name parameter. If the mailbox name parameter and the new mailbox name parameter. If the
normalized version of any of these 2 parameters differs from the normalized version of any of these 2 parameters differs from the
corresponding supplied version, the server SHOULD return an untagged corresponding supplied version, the server SHOULD return an untagged
LIST response with OLDNAME extended data item, with the OLDNAME value LIST response with OLDNAME extended data item, with the OLDNAME value
being the supplied existing mailbox name and the name parameter being being the supplied existing mailbox name and the name parameter being
the normalized new mailbox name (see Section 6.3.9.7). This would the normalized new mailbox name (see Section 6.3.9.7). This would
allow the client to correlate supplied name with the normalized name. allow the client to correlate supplied name with the normalized name.
skipping to change at page 45, line 10 skipping to change at page 45, line 11
mailbox name with possible wildcards mailbox name with possible wildcards
Arguments (extended): selection options (OPTIONAL) Arguments (extended): selection options (OPTIONAL)
reference name reference name
mailbox patterns mailbox patterns
return options (OPTIONAL) return options (OPTIONAL)
Responses: untagged responses: LIST Responses: untagged responses: LIST
Result: OK - list completed Result: OK - list completed
NO - list failure: can't list that reference or name NO - list failure: can't list that reference or mailbox
name
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
The LIST command returns a subset of names from the complete set of The LIST command returns a subset of mailbox names from the complete
all names available to the client. Zero or more untagged LIST set of all mailbox names available to the client. Zero or more
replies are returned, containing the name attributes, hierarchy untagged LIST replies are returned, containing the name attributes,
delimiter, name, and possible extension information; see the hierarchy delimiter, name, and possible extension information; see
description of the LIST reply for more detail. the description of the LIST reply for more detail.
The LIST command SHOULD return its data quickly, without undue delay. The LIST command SHOULD return its data quickly, without undue delay.
For example, it SHOULD NOT go to excess trouble to calculate the For example, it SHOULD NOT go to excess trouble to calculate the
\Marked or \Unmarked status or perform other processing; if each name \Marked or \Unmarked status or perform other processing; if each name
requires 1 second of processing, then a list of 1200 names would take requires 1 second of processing, then a list of 1200 names would take
20 minutes! 20 minutes!
The extended LIST command, originally introduced in [RFC5258], The extended LIST command, originally introduced in [RFC5258],
provides capabilities beyond that of the original IMAP LIST command. provides capabilities beyond that of the original IMAP LIST command.
The extended syntax is being used if one or more of the following The extended syntax is being used if one or more of the following
skipping to change at page 47, line 11 skipping to change at page 47, line 15
Any part of the reference argument that is included in the Any part of the reference argument that is included in the
interpreted form SHOULD prefix the interpreted form. It SHOULD also interpreted form SHOULD prefix the interpreted form. It SHOULD also
be in the same form as the reference name argument. This rule be in the same form as the reference name argument. This rule
permits the client to determine if the returned mailbox name is in permits the client to determine if the returned mailbox name is in
the context of the reference argument, or if something about the the context of the reference argument, or if something about the
mailbox argument overrode the reference argument. Without this rule, mailbox argument overrode the reference argument. Without this rule,
the client would have to have knowledge of the server's naming the client would have to have knowledge of the server's naming
semantics including what characters are "breakouts" that override a semantics including what characters are "breakouts" that override a
naming context. naming context.
For example, here are some examples of how references Here are some examples of how references
and mailbox names might be interpreted on a UNIX-based and mailbox names might be interpreted on a UNIX-based
server: server:
Reference Mailbox Name Interpretation Reference Mailbox Name Interpretation
------------ ------------ -------------- ------------ ------------ --------------
~smith/Mail/ foo.* ~smith/Mail/foo.* ~smith/Mail/ foo.* ~smith/Mail/foo.*
archive/ % archive/% archive/ % archive/%
#news. comp.mail.* #news.comp.mail.* #news. comp.mail.* #news.comp.mail.*
~smith/Mail/ /usr/doc/foo /usr/doc/foo ~smith/Mail/ /usr/doc/foo /usr/doc/foo
archive/ ~fred/Mail/* ~fred/Mail/* archive/ ~fred/Mail/* ~fred/Mail/*
skipping to change at page 53, line 47 skipping to change at page 54, line 10
not specified, such servers SHOULD use the "\NonExistent not specified, such servers SHOULD use the "\NonExistent
\HasChildren" attribute pair to signal to the client that there is a \HasChildren" attribute pair to signal to the client that there is a
descendant mailbox that matches the selection criteria. See example descendant mailbox that matches the selection criteria. See example
11 in Section 6.3.9.8. 11 in Section 6.3.9.8.
The returned selection criteria allow the client to distinguish a The returned selection criteria allow the client to distinguish a
solicited response from an unsolicited one, as well as to distinguish solicited response from an unsolicited one, as well as to distinguish
among solicited responses caused by multiple pipelined LIST commands among solicited responses caused by multiple pipelined LIST commands
that specify different criteria. that specify different criteria.
Servers SHOULD ONLY return a non-matching mailbox name along with Servers SHOULD only return a non-matching mailbox name along with
CHILDINFO if at least one matching child is not also being returned. CHILDINFO if at least one matching child is not also being returned.
That is, servers SHOULD suppress redundant CHILDINFO responses. That is, servers SHOULD suppress redundant CHILDINFO responses.
Examples 8 and 10 in Section 6.3.9.8 demonstrate the difference Examples 8 and 10 in Section 6.3.9.8 demonstrate the difference
between present CHILDINFO extended data item and the "\HasChildren" between present CHILDINFO extended data item and the "\HasChildren"
attribute. attribute.
The following table summarizes interaction between the "\NonExistent" The following table summarizes interaction between the "\NonExistent"
attribute and CHILDINFO (the first column indicates whether the attribute and CHILDINFO (the first column indicates whether the
parent mailbox exists): parent mailbox exists):
skipping to change at page 54, line 51 skipping to change at page 55, line 12
deleted (with DELETE command). (When a mailbox is deleted the deleted (with DELETE command). (When a mailbox is deleted the
"\NonExistent" attribute is also included.) IMAP extensions can "\NonExistent" attribute is also included.) IMAP extensions can
specify other conditions when OLDNAME extended data item should be specify other conditions when OLDNAME extended data item should be
included. included.
If the server allows de-normalized mailbox names (see Section 5.1) in If the server allows de-normalized mailbox names (see Section 5.1) in
SELECT/EXAMINE, CREATE, RENAME or DELETE, it SHOULD return an SELECT/EXAMINE, CREATE, RENAME or DELETE, it SHOULD return an
unsolicited LIST response that includes OLDNAME extended data item, unsolicited LIST response that includes OLDNAME extended data item,
whenever the supplied mailbox name differs from the resulting whenever the supplied mailbox name differs from the resulting
normalized mailbox name. From the client point of view this is normalized mailbox name. From the client point of view this is
indistinguishable from another user renaming of deleting the mailbox, indistinguishable from another user renaming or deleting the mailbox,
as specified in the previous paragraph. as specified in the previous paragraph.
A deleted mailbox can be announced like this: A deleted mailbox can be announced like this:
S: * LIST (\NonExistent) "." "INBOX.DeletedMailbox" S: * LIST (\NonExistent) "." "INBOX.DeletedMailbox"
Example of a renamed mailbox: Example of a renamed mailbox:
S: * LIST () "/" "NewMailbox" ("OLDNAME" ("OldMailbox")) S: * LIST () "/" "NewMailbox" ("OLDNAME" ("OldMailbox"))
skipping to change at page 62, line 36 skipping to change at page 63, line 15
6.3.10. NAMESPACE Command 6.3.10. NAMESPACE Command
Arguments: none Arguments: none
Responses: REQUIRED untagged responses: NAMESPACE Responses: REQUIRED untagged responses: NAMESPACE
Result: OK - command completed Result: OK - command completed
NO - Can't complete the command NO - Can't complete the command
BAD - arguments invalid BAD - arguments invalid
The NAMESPACE command causes a single ungagged NAMESPACE response to The NAMESPACE command causes a single untagged NAMESPACE response to
be returned. The untagged NAMESPACE response contains the prefix and be returned. The untagged NAMESPACE response contains the prefix and
hierarchy delimiter to the server's Personal Namespace(s), Other hierarchy delimiter to the server's Personal Namespace(s), Other
Users' Namespace(s), and Shared Namespace(s) that the server wishes Users' Namespace(s), and Shared Namespace(s) that the server wishes
to expose. The response will contain a NIL for any namespace class to expose. The response will contain a NIL for any namespace class
that is not available. The Namespace-Response-Extensions ABNF non that is not available. The Namespace-Response-Extensions ABNF non
terminal is defined for extensibility and MAY be included in the terminal is defined for extensibility and MAY be included in the
NAMESPACE response. NAMESPACE response.
Example 1: Example 1:
skipping to change at page 64, line 25 skipping to change at page 64, line 47
where there MAY be multiples of these, and a client MUST be prepared where there MAY be multiples of these, and a client MUST be prepared
for them. If a client is configured such that it is required to for them. If a client is configured such that it is required to
create a certain mailbox, there can be circumstances where it is create a certain mailbox, there can be circumstances where it is
unclear which Personal Namespaces it should create the mailbox in. unclear which Personal Namespaces it should create the mailbox in.
In these situations a client SHOULD let the user select which In these situations a client SHOULD let the user select which
namespaces to create the mailbox in or just use the first personal namespaces to create the mailbox in or just use the first personal
namespace. namespace.
Example 6: Example 6:
In this example, a server supports 2 Personal Namespaces. In In this example, a server supports two Personal Namespaces. In
addition to the regular Personal Namespace, the user has an addition to the regular Personal Namespace, the user has an
additional personal namespace to allow access to mailboxes in an MH additional personal namespace to allow access to mailboxes in an MH
format mailstore. format mailstore.
The client is configured to save a copy of all mail sent by the user The client is configured to save a copy of all mail sent by the user
into a mailbox called 'Sent Mail'. Furthermore, after a message is into a mailbox called 'Sent Mail'. Furthermore, after a message is
deleted from a mailbox, the client is configured to move that message deleted from a mailbox, the client is configured to move that message
to a mailbox called 'Deleted Items'. to a mailbox called 'Deleted Items'.
Note that this example demonstrates how some extension flags can be Note that this example demonstrates how some extension parameters can
passed to further describe the #mh namespace. be passed to further describe the #mh namespace. See the fictitious
"X-PARAM" extension parameter.
C: A001 NAMESPACE C: A001 NAMESPACE
S: * NAMESPACE (("" "/")("#mh/" "/" "X-PARAM" S: * NAMESPACE (("" "/")("#mh/" "/" "X-PARAM"
("FLAG1" "FLAG2"))) NIL NIL ("FLAG1" "FLAG2"))) NIL NIL
S: A001 OK NAMESPACE command completed S: A001 OK NAMESPACE command completed
< It is desired to keep only one copy of sent mail. < It is desired to keep only one copy of sent mail.
It is unclear which Personal Namespace the client It is unclear which Personal Namespace the client
should use to create the 'Sent Mail' mailbox. should use to create the 'Sent Mail' mailbox.
The user is prompted to select a namespace and only The user is prompted to select a namespace and only
skipping to change at page 68, line 6 skipping to change at page 68, line 12
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. However, servers MUST be able to currently selected mailbox. However, servers MUST be able to
execute STATUS command on the selected mailbox. (This might also execute STATUS command on the selected mailbox. (This might also
implicitly happen when STATUS return option is used in a LIST implicitly happen when STATUS return option is used in a LIST
command). command).
The STATUS command MUST NOT be used as a "check for new messages The STATUS command MUST NOT be used as a "check for new messages
in the selected mailbox" operation (refer to sections Section 7, in the selected mailbox" operation (refer to Section 7 and
Section 7.3.1 for more information about the proper method for new Section 7.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.
The currently defined status data items that can be requested are: The currently defined status data items that can be requested are:
MESSAGES The number of messages in the mailbox. MESSAGES The number of messages in the mailbox.
skipping to change at page 68, line 45 skipping to change at page 69, line 4
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
Responses: OPTIONAL untagged response: LIST Responses: OPTIONAL untagged response: LIST
Result: OK - append completed Result: OK - append completed
NO - append error: can't append to that mailbox, error NO - append error: can't append to that mailbox, error
in flags or date/time or message text in flags or date/time or message text
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
The APPEND command appends the literal argument as a new message to The APPEND command appends the literal argument as a new message to
the end of the specified destination mailbox. This argument SHOULD the end of the specified destination mailbox. This argument SHOULD
be in the format of an [RFC-5322] or [I18N-HDRS] message. 8-bit be in the format of an [RFC-5322] or [I18N-HDRS] message. 8-bit
characters are permitted in the message. A server implementation characters are permitted in the message. A server implementation
that is unable to preserve 8-bit data properly MUST be able to that is unable to preserve 8-bit data properly MUST be able to
reversibly convert 8-bit APPEND data to 7-bit using a [MIME-IMB] reversibly convert 8-bit APPEND data to 7-bit using a [MIME-IMB]
content transfer encoding. content transfer encoding.
Note: There may be exceptions, e.g., draft messages, in which Note: There may be exceptions, e.g., draft messages, in which
required [RFC-5322] header lines are omitted in the message required [RFC-5322] header fields are omitted in the message
literal argument to APPEND. The full implications of doing so literal argument to APPEND. The full implications of doing so
must be understood and carefully weighed. must be understood and carefully weighed.
If a flag parenthesized list is specified, the flags SHOULD be set in If a flag parenthesized list is specified, the flags SHOULD be set in
the resulting message; otherwise, the flag list of the resulting the resulting message; otherwise, the flag list of the resulting
message is set to empty by default. message is set to empty by default.
If a date-time is specified, the internal date SHOULD be set in the If a date-time is specified, the internal date SHOULD be set in the
resulting message; otherwise, the internal date of the resulting resulting message; otherwise, the internal date of the resulting
message is set to the current date and time by default. message is set to the current date and time by default.
skipping to change at page 72, line 10 skipping to change at page 72, line 10
Arguments: none Arguments: none
Responses: continuation data will be requested; the client sends the Responses: continuation data will be requested; the client sends the
continuation data "DONE" to end the command continuation data "DONE" to end the command
Result: OK - IDLE completed after client sent "DONE" Result: OK - IDLE completed after client sent "DONE"
NO - failure: the server will not allow the IDLE command NO - failure: the server will not allow the IDLE command
at this time at this time
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 would need 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 update messages. The server client is ready to accept unsolicited update messages. The server
requests a response to the IDLE command using the continuation ("+") requests a response to the IDLE command using the continuation ("+")
response. The IDLE command remains active until the client responds response. The IDLE command remains active until the client responds
to the continuation, and as long as an IDLE command is active, the to the continuation, and as long as an IDLE command is active, the
server is now free to send untagged EXISTS, EXPUNGE, FETCH, and other server is now free to send untagged EXISTS, EXPUNGE, FETCH, and other
responses at any time. If the server choose to send unsolicited responses at any time. If the server chooses to send unsolicited
FETCH responses, they MUST include UID FETCH item. 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
skipping to change at page 74, line 44 skipping to change at page 74, line 44
6.4.2. UNSELECT Command 6.4.2. UNSELECT Command
Arguments: none Arguments: none
Responses: no specific responses for this command Responses: no specific responses for this command
Result: OK - unselect completed, now in authenticated state Result: OK - unselect completed, now in authenticated state
BAD - no mailbox selected, or argument supplied but none BAD - no mailbox selected, or argument supplied but none
permitted permitted
The UNSELECT command frees server's resources associated with the The UNSELECT command frees session's resources associated with the
selected mailbox and returns the server to the authenticated state. selected mailbox and returns the server to the authenticated state.
This command performs the same actions as CLOSE, except that no This command performs the same actions as CLOSE, except that no
messages are permanently removed from the currently selected mailbox. messages are permanently removed from the currently selected mailbox.
Example: C: A342 UNSELECT Example: C: A342 UNSELECT
S: A342 OK Unselect completed S: A342 OK Unselect completed
6.4.3. EXPUNGE Command 6.4.3. EXPUNGE Command
Arguments: none Arguments: none
skipping to change at page 76, line 5 skipping to change at page 76, line 5
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). The order of individual options is
arbitrary. Individual options may contain parameters enclosed in arbitrary. Individual options may contain parameters enclosed in
parentheses (*). If an option has parameters, they consist of atoms parentheses. (However, if an option has a mandatory parameter, which
can always be represented as a number or a sequence-set, the option
parameter does not need the enclosing parentheses. See the ABNF for
more details). If an option has parameters, they consist of atoms
and/or strings and/or lists in a specific order. Any options not and/or strings and/or lists in a specific order. Any options not
defined by extensions that the server supports must be rejected with defined by extensions that the server supports MUST be rejected with
a BAD response. a BAD response.
(*) - if an option has a mandatory parameter, which can always be
represented as a number or a sequence-set, the option parameter does
not need the enclosing (). See the 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
criteria. criteria.
If the SEARCH results in no matches, the server MUST NOT If the SEARCH results in no matches, the server MUST NOT
include the MIN result option in the ESEARCH response; however, include the MIN result option in the ESEARCH response; however,
it still MUST send the ESEARCH response. it still MUST send the ESEARCH response.
skipping to change at page 76, line 45 skipping to change at page 76, line 44
Return all message numbers/UIDs that satisfy the SEARCH Return all message numbers/UIDs that satisfy the SEARCH
criteria using the sequence-set syntax. Note, the client MUST criteria using the sequence-set syntax. Note, the client MUST
NOT assume that messages/UIDs will be listed in any particular NOT assume that messages/UIDs will be listed in any particular
order. order.
If the SEARCH results in no matches, the server MUST NOT If the SEARCH results in no matches, the server MUST NOT
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 the number of 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.
SAVE SAVE
This option tells the server to remember the result of the This option tells the server to remember the result of the
SEARCH or UID SEARCH command (as well as any command based on SEARCH or UID SEARCH command (as well as any command based on
SEARCH, e.g., SORT and THREAD [RFC5256]>) and store it in an SEARCH, e.g., SORT and THREAD [RFC5256]>) and store it in an
internal variable that we will reference as the "search result internal variable that we will reference as the "search result
variable". The client can use the "$" marker to reference the variable". The client can use the "$" marker to reference the
content of this internal variable. The "$" marker can be used content of this internal variable. The "$" marker can be used
instead of message sequence or UID sequence in order to instead of message sequence or UID sequence in order to
indicate that the server should substitute it with the list of indicate that the server should substitute it with the list of
messages from the search result variable. Thus, the client can messages from the search result variable. Thus, the client can
use the result of the latest remembered SEARCH command as a use the result of the latest remembered SEARCH command as a
skipping to change at page 79, line 8 skipping to change at page 79, line 5
DELETED Messages with the \Deleted flag set. DELETED Messages with the \Deleted flag set.
DRAFT Messages with the \Draft flag set. DRAFT Messages with the \Draft flag set.
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 field with
specified field-name (as defined in [RFC-5322]) and that contains the specified field-name (as defined in [RFC-5322]) and that
the specified string in the text of the header (what comes after contains the specified string in the text of the header field
the colon). If the string to search is zero-length, this matches (what comes after the colon). If the string to search is zero-
all messages that have a header line with the specified field-name length, this matches all messages that have a header field with
regardless of the contents. Servers should use substring search the specified field-name regardless of the contents. Servers
for this SEARCH item, as clients can use it for automatic should use substring search for this SEARCH item, as clients can
processing not initiated by end users. For example this can be use it for automatic processing not initiated by end users. For
used for searching for Message-ID or Content-Type header field example this can be used for searching for Message-ID or Content-
values that need to be exact, or for searches in header fields Type header field values that need to be exact, or for searches in
that the IMAP server might not know anything about. 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.
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.
SENTBEFORE <date> Messages whose [RFC-5322] Date: header SENTBEFORE <date> Messages whose [RFC-5322] Date: header field
(disregarding time and timezone) is earlier than the specified (disregarding time and timezone) is earlier than the specified
date. date.
SENTON <date> Messages whose [RFC-5322] Date: header (disregarding SENTON <date> Messages whose [RFC-5322] Date: header field
time and timezone) is within the specified date. (disregarding time and timezone) is within the specified date.
SENTSINCE <date> Messages whose [RFC-5322] Date: header SENTSINCE <date> Messages whose [RFC-5322] Date: header field
(disregarding time and timezone) is within or later than the (disregarding time and timezone) is within or later than the
specified date. specified date.
SINCE <date> Messages whose internal date (disregarding time and SINCE <date> Messages whose internal date (disregarding time and
timezone) is within or later than the specified date. timezone) is within or later than the specified date.
SMALLER <n> Messages with an [RFC-5322] size smaller than the SMALLER <n> Messages with an [RFC-5322] size smaller than the
specified number of octets. specified number of octets.
SUBJECT <string> Messages that contain the specified string in the SUBJECT <string> Messages that contain the specified string in the
skipping to change at page 83, line 40 skipping to change at page 83, line 40
6.4.4.2. Multiple Commands in Progress 6.4.4.2. Multiple Commands in Progress
Use of a SEARCH RETURN (SAVE) command followed by a command using the Use of a SEARCH RETURN (SAVE) command followed by a command using the
"$" marker creates direct dependency between the two commands. As "$" marker creates direct dependency between the two commands. As
directed by Section 5.5, a server MUST execute the two commands in directed by Section 5.5, a server MUST execute the two commands in
the order they were received. the order they were received.
A client MAY pipeline a SEARCH RETURN (SAVE) command with one or more A client MAY pipeline a SEARCH RETURN (SAVE) command with one or more
command using the "$" marker, as long as this doesn't create an command using the "$" marker, as long as this doesn't create an
ambiguity, as described in by Section 5.5. Examples 7-9 in ambiguity, as described in Section 5.5. Examples 7-9 in
Section 6.4.4.4 explain this in more details. Section 6.4.4.4 explain this in more details.
6.4.4.3. Refusing to Save Search Results 6.4.4.3. Refusing to Save Search Results
In some cases, the server MAY refuse to save a SEARCH (SAVE) result, In some cases, the server MAY refuse to save a SEARCH (SAVE) result,
for example, if an internal limit on the number of saved results is for example, if an internal limit on the number of saved results is
reached. In this case, the server MUST return a tagged NO response reached. In this case, the server MUST return a tagged NO response
containing the NOTSAVED response code and set the search result containing the NOTSAVED response code and set the search result
variable to the empty sequence, as described in Section 6.4.4.1. variable to the empty sequence, as described in Section 6.4.4.1.
skipping to change at page 102, line 36 skipping to change at page 102, line 36
completion of the CLOSE or the UNSELECT command (or similar), completion of the CLOSE or the UNSELECT command (or similar),
whose purpose is to close the currently selected mailbox whose purpose is to close the currently selected mailbox
without opening a new one. without opening a new one.
CONTACTADMIN CONTACTADMIN
The user should contact the system administrator or support The user should contact the system administrator or support
desk. desk.
C: e login "fred" "foo" C: e login "fred" "foo"
S: e OK [CONTACTADMIN] S: e NO [CONTACTADMIN]
COPYUID COPYUID
Followed by the UIDVALIDITY of the destination mailbox, a UID Followed by the UIDVALIDITY of the destination mailbox, a UID
set containing the UIDs of the message(s) in the source mailbox set containing the UIDs of the message(s) in the source mailbox
that were copied to the destination mailbox and containing the that were copied to the destination mailbox and containing the
UIDs assigned to the copied message(s) in the destination UIDs assigned to the copied message(s) in the destination
mailbox, indicates that the message(s) have been copied to the mailbox, indicates that the message(s) have been copied to the
destination mailbox with the stated UID(s). destination mailbox with the stated UID(s).
skipping to change at page 122, line 48 skipping to change at page 122, line 48
are in the following order: personal name, [SMTP] at-domain- are in the following order: personal name, [SMTP] at-domain-
list (source route, obs-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 fields
are absent in the [RFC-5322] header, the corresponding member are absent in the [RFC-5322] header, the corresponding member
of the envelope is NIL; if these header lines are present but of the envelope is NIL; if these header fields are present but
empty the corresponding member of the envelope is the empty empty the corresponding member of the envelope is the empty
string. string.
Note: some servers may return a NIL envelope member in the Note: some servers may return a NIL envelope member in the
"present but empty" case. Clients SHOULD treat NIL and "present but empty" case. Clients SHOULD treat NIL and
empty string as identical. empty string as identical.
Note: [RFC-5322] requires that all messages have a valid Note: [RFC-5322] requires that all messages have a valid
Date header. Therefore, for a well-formed message the date Date header field. Therefore, for a well-formed message the
member in the envelope can not be NIL or the empty string. date member in the envelope can not be NIL or the empty
However it can be NIL for a malformed or a draft message. string. However it can be NIL for a malformed or a draft
message.
Note: [RFC-5322] requires that the In-Reply-To and Message- Note: [RFC-5322] requires that the In-Reply-To and Message-
ID headers, if present, have non-empty content. Therefore, ID header fields, if present, have non-empty content.
for a well-formed message the in-reply-to and message-id Therefore, for a well-formed message the in-reply-to and
members in the envelope can not be the empty string. message-id members in the envelope can not be the empty
However they can still be the empty string for a malformed string. However they can still be the empty string for a
message. malformed message.
If the From, To, Cc, and Bcc header lines are absent in the If the From, To, Cc, and Bcc header fields are absent in the
[RFC-5322] header, or are present but empty, the corresponding [RFC-5322] header, or are present but empty, the corresponding
member of the envelope is NIL. member of the envelope is NIL.
If the Sender or Reply-To lines are absent in the [RFC-5322] If the Sender or Reply-To header fields are absent in the
header, or are present but empty, the server sets the [RFC-5322] header, or are present but empty, the server sets
corresponding member of the envelope to be the same value as the corresponding member of the envelope to be the same value
the from member (the client is not expected to know to do as the from member (the client is not expected to know to do
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, for a well-formed message the from, From header field. Therefore, for a well-formed message the
sender, and reply-to members in the envelope can not be NIL. from, sender, and reply-to members in the envelope can not
However they can be NIL for a malformed or a draft message. be NIL. However they can be NIL for a malformed or a draft
message.
FLAGS A parenthesized list of flags that are set for this message. FLAGS A parenthesized list of flags that are set for this message.
INTERNALDATE A string representing the internal date of the message. INTERNALDATE A string representing the internal date of the message.
RFC822.SIZE A number expressing the [RFC-5322] size of the message. RFC822.SIZE A number expressing the [RFC-5322] size of the message.
UID A number expressing the unique identifier of the message. UID A number expressing the unique identifier of the message.
If the server chooses to send unsolicited FETCH responses, they MUST If the server chooses to send unsolicited FETCH responses, they MUST
skipping to change at page 158, line 6 skipping to change at page 158, line 6
Appendix G. Acknowledgement Appendix G. 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, Stephan Bosch and Arnt Thank you to Murray Kucherawy, Timo Sirainen, Bron Gondwana, Stephan
Gulbrandsen for extensive feedback. Bosch and Arnt Gulbrandsen for 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 5465 (by Arnt Gulbrandsen and Curtis King), RFC Gulbrandsen), RFC 5465 (by Arnt Gulbrandsen and Curtis King), RFC
5530 (by Arnt Gulbrandsen), RFC 5819 (by Timo Sirainen), RFC 6154 (by 5530 (by Arnt Gulbrandsen), RFC 5819 (by Timo Sirainen), RFC 6154 (by
Jamie Nicolson), RFC 8438 (by Stephan Bosch) so work done by authors/ Jamie Nicolson), RFC 8438 (by Stephan Bosch) so work done by authors/
editors of these documents is appreciated. Note that editors of this editors of these documents is appreciated. Note that editors of this
document were redacted from the above list. document were redacted from the above list.
The CHILDREN return option was originally proposed by Mike Gahrns and The CHILDREN return option was originally proposed by Mike Gahrns and
skipping to change at page 158, line 32 skipping to change at page 158, line 32
Thank you to Damian Poddebniak for pointing out that the ENABLE Thank you to Damian Poddebniak for pointing out that the ENABLE
command should be a member of "command-auth" and not "command-any" command should be a member of "command-auth" and not "command-any"
ABNF production. ABNF production.
Index Index
$ $
$Forwarded (predefined flag) 12 $Forwarded (predefined flag) 12
$Junk (predefined flag) 12 $Junk (predefined flag) 12
$MDNSent (predefined flag) 12 $MDNSent (predefined flag) 12
$NotJunk (predefined flag) 12 $NotJunk (predefined flag) 13
$Phishing (predefined flag) 13 $Phishing (predefined flag) 13
+ +
+FLAGS <flag list> 92 +FLAGS <flag list> 92
+FLAGS.SILENT <flag list> 92 +FLAGS.SILENT <flag list> 92
- -
-FLAGS <flag list> 92 -FLAGS <flag list> 92
-FLAGS.SILENT <flag list> 92 -FLAGS.SILENT <flag list> 92
skipping to change at page 160, line 24 skipping to change at page 160, line 24
F F
FAST (fetch item) 88 FAST (fetch item) 88
FETCH (command) 87 FETCH (command) 87
FETCH (response) 118 FETCH (response) 118
FLAGGED (search key) 78 FLAGGED (search key) 78
FLAGS (fetch item) 90 FLAGS (fetch item) 90
FLAGS (fetch result) 123 FLAGS (fetch result) 123
FLAGS (response) 116 FLAGS (response) 116
FLAGS <flag list> (store command data item) 92 FLAGS <flag list> (store command data item) 92
FLAGS.SILENT <flag list> (store command data item) 92 FLAGS.SILENT <flag list> (store command data item) 92
FROM <string> (search key) 79 FROM <string> (search key) 78
FULL (fetch item) 88 FULL (fetch item) 88
Flags (message attribute) 11 Flags (message attribute) 11
H H
HASCHILDREN (response code) 103 HASCHILDREN (response code) 103
HEADER (part specifier) 90 HEADER (part specifier) 90
HEADER <field-name> <string> (search key) 79 HEADER <field-name> <string> (search key) 79
HEADER.FIELDS (part specifier) 90 HEADER.FIELDS (part specifier) 90
HEADER.FIELDS.NOT (part specifier) 90 HEADER.FIELDS.NOT (part specifier) 90
skipping to change at page 161, line 17 skipping to change at page 161, line 17
MAY (specification requirement term) 5 MAY (specification requirement term) 5
MESSAGES (status item) 68 MESSAGES (status item) 68
MIME (part specifier) 91 MIME (part specifier) 91
MIN (search result option) 76 MIN (search result option) 76
MOVE (command) 94 MOVE (command) 94
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) 62 NAMESPACE (command) 63
NAMESPACE (response) 115 NAMESPACE (response) 115
NO (response) 108 NO (response) 108
NONEXISTENT (response code) 104 NONEXISTENT (response code) 104
NOOP (command) 26 NOOP (command) 26
NOPERM (response code) 104 NOPERM (response code) 104
NOT <search-key> (search key) 79 NOT <search-key> (search key) 79
NOT RECOMMENDED (specification requirement term) 5 NOT RECOMMENDED (specification requirement term) 5
O O
OK (response) 107 OK (response) 107
skipping to change at page 162, line 19 skipping to change at page 162, line 19
SERVERBUG (response code) 106 SERVERBUG (response code) 106
SHOULD (specification requirement term) 5 SHOULD (specification requirement term) 5
SHOULD NOT (specification requirement term) 5 SHOULD NOT (specification requirement term) 5
SINCE <date> (search key) 79 SINCE <date> (search key) 79
SIZE (status item) 68 SIZE (status item) 68
SMALLER <n> (search key) 79 SMALLER <n> (search key) 79
STARTTLS (command) 28 STARTTLS (command) 28
STATUS (command) 67 STATUS (command) 67
STATUS (response) 115 STATUS (response) 115
STORE (command) 92 STORE (command) 92
SUBJECT <string> (search key) 80 SUBJECT <string> (search key) 79
SUBSCRIBE (command) 43 SUBSCRIBE (command) 43
Session Flag (class of flag) 13 Session Flag (class of flag) 13
System Flag (type of flag) 11 System Flag (type of flag) 12
T T
TEXT (part specifier) 90 TEXT (part specifier) 90
TEXT <string> (search key) 80 TEXT <string> (search key) 80
TO <string> (search key) 80 TO <string> (search key) 80
TRYCREATE (response code) 106 TRYCREATE (response code) 106
U U
UID (command) 96 UID (command) 96
UID (fetch item) 90 UID (fetch item) 90
 End of changes. 64 change blocks. 
133 lines changed or deleted 142 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/