5Internet Engineering Task Force (IETF) A. Melnikov, Ed.
6Request for Comments: 9051 Isode Ltd
7Obsoletes: 3501 B. Leiba, Ed.
8Category: Standards Track Futurewei Technologies
9ISSN: 2070-1721 August 2021
12 Internet Message Access Protocol (IMAP) - Version 4rev2
16 The Internet Message Access Protocol Version 4rev2 (IMAP4rev2) allows
17 a client to access and manipulate electronic mail messages on a
18 server. IMAP4rev2 permits manipulation of mailboxes (remote message
19 folders) in a way that is functionally equivalent to local folders.
20 IMAP4rev2 also provides the capability for an offline client to
21 resynchronize with the server.
23 IMAP4rev2 includes operations for creating, deleting, and renaming
24 mailboxes; checking for new messages; removing messages permanently;
25 setting and clearing flags; parsing per RFCs 5322, 2045, and 2231;
26 searching; and selective fetching of message attributes, texts, and
27 portions thereof. Messages in IMAP4rev2 are accessed by the use of
28 numbers. These numbers are either message sequence numbers or unique
31 IMAP4rev2 does not specify a means of posting mail; this function is
32 handled by a mail submission protocol such as the one specified in
37 This is an Internet Standards Track document.
39 This document is a product of the Internet Engineering Task Force
40 (IETF). It represents the consensus of the IETF community. It has
41 received public review and has been approved for publication by the
42 Internet Engineering Steering Group (IESG). Further information on
43 Internet Standards is available in Section 2 of RFC 7841.
45 Information about the current status of this document, any errata,
46 and how to provide feedback on it may be obtained at
47 https://www.rfc-editor.org/info/rfc9051.
51 Copyright (c) 2021 IETF Trust and the persons identified as the
52 document authors. All rights reserved.
54 This document is subject to BCP 78 and the IETF Trust's Legal
55 Provisions Relating to IETF Documents
56 (https://trustee.ietf.org/license-info) in effect on the date of
57 publication of this document. Please review these documents
58 carefully, as they describe your rights and restrictions with respect
59 to this document. Code Components extracted from this document must
60 include Simplified BSD License text as described in Section 4.e of
61 the Trust Legal Provisions and are provided without warranty as
62 described in the Simplified BSD License.
64 This document may contain material from IETF Documents or IETF
65 Contributions published or made publicly available before November
66 10, 2008. The person(s) controlling the copyright in some of this
67 material may not have granted the IETF Trust the right to allow
68 modifications of such material outside the IETF Standards Process.
69 Without obtaining an adequate license from the person(s) controlling
70 the copyright in such materials, this document may not be modified
71 outside the IETF Standards Process, and derivative works of it may
72 not be created outside the IETF Standards Process, except to format
73 it for publication as an RFC or to translate it into languages other
78 1. How to Read This Document
79 1.1. Organization of This Document
80 1.2. Conventions Used in This Document
81 1.3. Special Notes to Implementors
84 2.2. Commands and Responses
85 2.2.1. Client Protocol Sender and Server Protocol Receiver
86 2.2.2. Server Protocol Sender and Client Protocol Receiver
87 2.3. Message Attributes
88 2.3.1. Message Numbers
89 2.3.2. Flags Message Attribute
90 2.3.3. Internal Date Message Attribute
91 2.3.4. RFC822.SIZE Message Attribute
92 2.3.5. Envelope Structure Message Attribute
93 2.3.6. Body Structure Message Attribute
95 3. State and Flow Diagram
96 3.1. Not Authenticated State
97 3.2. Authenticated State
102 4.1.1. Sequence Set and UID Set
105 4.3.1. 8-Bit and Binary Strings
106 4.4. Parenthesized List
108 5. Operational Considerations
110 5.1.1. Mailbox Hierarchy Naming
112 5.2. Mailbox Size and Message Status Updates
113 5.3. Response When No Command in Progress
114 5.4. Autologout Timer
115 5.5. Multiple Commands in Progress (Command Pipelining)
117 6.1. Client Commands - Any State
118 6.1.1. CAPABILITY Command
120 6.1.3. LOGOUT Command
121 6.2. Client Commands - Not Authenticated State
122 6.2.1. STARTTLS Command
123 6.2.2. AUTHENTICATE Command
125 6.3. Client Commands - Authenticated State
126 6.3.1. ENABLE Command
127 6.3.2. SELECT Command
128 6.3.3. EXAMINE Command
129 6.3.4. CREATE Command
130 6.3.5. DELETE Command
131 6.3.6. RENAME Command
132 6.3.7. SUBSCRIBE Command
133 6.3.8. UNSUBSCRIBE Command
135 6.3.10. NAMESPACE Command
136 6.3.11. STATUS Command
137 6.3.12. APPEND Command
139 6.4. Client Commands - Selected State
141 6.4.2. UNSELECT Command
142 6.4.3. EXPUNGE Command
143 6.4.4. SEARCH Command
149 6.5. Client Commands - Experimental/Expansion
151 7.1. Server Responses - Generic Status Responses
155 7.1.4. PREAUTH Response
157 7.2. Server Responses - Server Status
158 7.2.1. ENABLED Response
159 7.2.2. CAPABILITY Response
160 7.3. Server Responses - Mailbox Status
162 7.3.2. NAMESPACE Response
163 7.3.3. STATUS Response
164 7.3.4. ESEARCH Response
165 7.3.5. FLAGS Response
166 7.4. Server Responses - Mailbox Size
167 7.4.1. EXISTS Response
168 7.5. Server Responses - Message Status
169 7.5.1. EXPUNGE Response
170 7.5.2. FETCH Response
171 7.6. Server Responses - Command Continuation Request
172 8. Sample IMAP4rev2 Connection
175 11. Security Considerations
176 11.1. TLS-Related Security Considerations
177 11.2. STARTTLS Command versus Use of Implicit TLS Port
178 11.3. Client Handling of Unsolicited Responses Not Suitable for
179 the Current Connection State
180 11.4. COPYUID and APPENDUID Response Codes
181 11.5. LIST Command and Other Users' Namespace
183 11.7. Other Security Considerations
184 12. IANA Considerations
185 12.1. Updates to IMAP Capabilities Registry
186 12.2. GSSAPI/SASL Service Name
187 12.3. LIST Selection Options, LIST Return Options, and LIST
189 12.4. IMAP Mailbox Name Attributes and IMAP Response Codes
191 13.1. Normative References
192 13.2. Informative References
193 13.2.1. Related Protocols
194 13.2.2. Historical Aspects of IMAP and Related Protocols
195 Appendix A. Backward Compatibility with IMAP4rev1
196 A.1. Mailbox International Naming Convention for Compatibility
198 Appendix B. Backward Compatibility with BINARY Extension
199 Appendix C. Backward Compatibility with LIST-EXTENDED Extension
200 Appendix D. 63-Bit Body Part and Message Sizes
201 Appendix E. Changes from RFC 3501 / IMAP4rev1
202 Appendix F. Other Recommended IMAP Extensions
2071. How to Read This Document
2091.1. Organization of This Document
211 This document is written from the point of view of the implementor of
212 an IMAP4rev2 client or server. Beyond the protocol overview in
213 Section 2, it is not optimized for someone trying to understand the
214 operation of the protocol. The material in Sections 3, 4, and 5
215 provides the general context and definitions with which IMAP4rev2
218 Sections 6, 7, and 9 describe the IMAP commands, responses, and
219 syntax, respectively. The relationships among these are such that it
220 is almost impossible to understand any of them separately. In
221 particular, do not attempt to deduce command syntax from the command
222 section alone; instead, refer to "Formal Syntax" (Section 9).
2241.2. Conventions Used in This Document
226 "Conventions" are basic principles or procedures. Document
227 conventions are noted in this section.
229 In examples, "C:" and "S:" indicate lines sent by the client and
230 server, respectively. Note that each line includes the terminating
233 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
234 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
235 "OPTIONAL" in this document are to be interpreted as described in
236 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
237 capitals, as shown here.
239 The word "can" (not "may") is used to refer to a possible
240 circumstance or situation, as opposed to an optional facility of the
243 "User" is used to refer to a human user, whereas "client" refers to
244 the software being run by the user.
246 "Connection" refers to the entire sequence of client/server
247 interaction from the initial establishment of the network connection
248 until its termination.
250 "Session" refers to the sequence of client/server interaction from
251 the time that a mailbox is selected (SELECT or EXAMINE command) until
252 the time that selection ends (SELECT or EXAMINE of another mailbox,
253 CLOSE command, UNSELECT command, or connection termination).
255 The term "Implicit TLS" refers to the automatic negotiation of TLS
256 whenever a TCP connection is made on a particular TCP port that is
257 used exclusively by that server for TLS connections. The term
258 "Implicit TLS" is intended to contrast with the use of the STARTTLS
259 command in IMAP that is used by the client and the server to
260 explicitly negotiate TLS on an established cleartext TCP connection.
262 Characters are 8-bit UTF-8 (of which 7-bit US-ASCII is a subset),
263 unless otherwise specified. Other character sets are indicated using
264 a "CHARSET", as described in [MIME-IMT] and defined in [CHARSET].
265 CHARSETs have important additional semantics in addition to defining
266 a character set; refer to these documents for more detail.
268 There are several protocol conventions in IMAP. These refer to
269 aspects of the specification that are not strictly part of the IMAP
270 protocol but reflect generally accepted practice. Implementations
271 need to be aware of these conventions, and avoid conflicts whether or
272 not they implement the convention. For example, "&" may not be used
273 as a hierarchy delimiter since it conflicts with the Mailbox
274 International Naming Convention, and other uses of "&" in mailbox
275 names are impacted as well.
2771.3. Special Notes to Implementors
279 Implementors of the IMAP protocol are strongly encouraged to read the
280 IMAP implementation recommendations document [IMAP-IMPLEMENTATION] in
281 conjunction with this document, to help understand the intricacies of
282 this protocol and how best to build an interoperable product.
284 IMAP4rev2 is designed to be upwards compatible from the IMAP4rev1
285 [RFC3501], IMAP2 [IMAP2], and unpublished IMAP2bis [IMAP2BIS]
286 protocols. IMAP4rev2 is largely compatible with the IMAP4rev1
287 protocol described in RFC 3501 and the IMAP4 protocol described in
288 [RFC1730]; the exception being in certain facilities added in
289 [RFC1730] and [RFC3501] that proved problematic and were subsequently
290 removed or replaced by better alternatives. In the course of the
291 evolution of IMAP4rev2, some aspects in the earlier protocols have
292 become obsolete. Obsolete commands, responses, and data formats that
293 an IMAP4rev2 implementation can encounter when used with an earlier
294 implementation are described in Appendices A and E and
295 [IMAP-OBSOLETE]. IMAP4rev2 supports 63-bit body parts and message
296 sizes. IMAP4rev2 compatibility with BINARY and LIST-EXTENDED IMAP
297 extensions are described in Appendices B and C, respectively.
299 Other compatibility issues with IMAP2bis, the most common variant of
300 the earlier protocol, are discussed in [IMAP-COMPAT]. A full
301 discussion of compatibility issues with rare (and presumed extinct)
302 variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is
303 primarily of historical interest.
305 IMAP was originally developed for the older [RFC822] standard, and as
306 a consequence, the "RFC822.SIZE" fetch item in IMAP incorporates
307 "RFC822" in its name. "RFC822" should be interpreted as a reference
308 to the updated [RFC5322] standard.
310 IMAP4rev2 does not specify a means of posting mail; this function is
311 handled by a mail submission protocol such as the one specified in
318 The IMAP4rev2 protocol assumes a reliable data stream such as that
319 provided by TCP. When TCP is used, an IMAP4rev2 server listens on
320 port 143 (cleartext port) or port 993 (Implicit TLS port).
3222.2. Commands and Responses
324 An IMAP4rev2 connection consists of the establishment of a client/
325 server network connection, an initial greeting from the server, and
326 client/server interactions. These client/server interactions consist
327 of a client command, server data, and a server completion result
330 All interactions transmitted by client and server are in the form of
331 lines, that is, strings that end with a CRLF. The protocol receiver
332 of an IMAP4rev2 client or server is reading either a line or a
333 sequence of octets with a known count followed by a line.
3352.2.1. Client Protocol Sender and Server Protocol Receiver
337 The client command begins an operation. Each client command is
338 prefixed with an identifier (typically a short alphanumeric string,
339 e.g., A0001, A0002, etc.) called a "tag". A different tag is
340 generated by the client for each command. More formally: the client
341 SHOULD generate a unique tag for every command, but a server MUST
344 Clients MUST follow the syntax outlined in this specification
345 strictly. It is a syntax error to send a command with missing or
346 extraneous spaces or arguments.
348 There are two cases in which a line from the client does not
349 represent a complete command. In one case, a command argument is
350 quoted with an octet count (see the description of literal in
351 Section 4.3); in the other case, the command arguments require server
352 feedback (see the AUTHENTICATE command in Section 6.2.2). In either
353 case, the server sends a command continuation request response if it
354 is ready for the octets (if appropriate) and the remainder of the
355 command. This response is prefixed with the token "+".
357 Note: If, instead, the server detected an error in the command, it
358 sends a BAD completion response with a tag matching the command
359 (as described below) to reject the command and prevent the client
360 from sending any more of the command.
362 It is also possible for the server to send a completion response
363 for some other command (if multiple commands are in progress) or
364 untagged data. In either case, the command continuation request
365 is still pending; the client takes the appropriate action for the
366 response and reads another response from the server. In all
367 cases, the client MUST send a complete command (including
368 receiving all command continuation request responses and sending
369 command continuations for the command) before initiating a new
372 The protocol receiver of an IMAP4rev2 server reads a command line
373 from the client, parses the command and its arguments, and transmits
374 server data and a server command completion result response.
3762.2.2. Server Protocol Sender and Client Protocol Receiver
378 Data transmitted by the server to the client and status responses
379 that do not indicate command completion are prefixed with the token
380 "*" and are called untagged responses.
382 Server data MAY be sent as a result of a client command or MAY be
383 sent unilaterally by the server. There is no syntactic difference
384 between server data that resulted from a specific command and server
385 data that were sent unilaterally.
387 The server completion result response indicates the success or
388 failure of the operation. It is tagged with the same tag as the
389 client command that began the operation. Thus, if more than one
390 command is in progress, the tag in a server completion response
391 identifies the command to which the response applies. There are
392 three possible server completion responses: OK (indicating success),
393 NO (indicating failure), or BAD (indicating a protocol error such as
394 unrecognized command or command syntax error).
396 Servers SHOULD strictly enforce the syntax outlined in this
397 specification. Any client command with a protocol syntax error,
398 including (but not limited to) missing or extraneous spaces or
399 arguments, SHOULD be rejected and the client given a BAD server
402 The protocol receiver of an IMAP4rev2 client reads a response line
403 from the server. It then takes action on the response based upon the
404 first token of the response, which can be a tag, a "*", or a "+".
406 A client MUST be prepared to accept any server response at all times.
407 This includes server data that was not requested. Server data SHOULD
408 be remembered (cached), so that the client can reference its
409 remembered copy rather than sending a command to the server to
410 request the data. In the case of certain server data, the data MUST
411 be remembered, as specified elsewhere in this document.
413 This topic is discussed in greater detail in "Server Responses" (see
4162.3. Message Attributes
418 In addition to message text, each message has several attributes
419 associated with it. These attributes can be retrieved individually
420 or in conjunction with other attributes or message texts.
4222.3.1. Message Numbers
424 Messages in IMAP4rev2 are accessed by one of two numbers: the Unique
425 Identifier (UID) or the message sequence number.
4272.3.1.1. Unique Identifier (UID) Message Attribute
429 A UID is an unsigned non-zero 32-bit value assigned to each message,
430 which when used with the unique identifier validity value (see below)
431 forms a 64-bit value that MUST NOT refer to any other message in the
432 mailbox or any subsequent mailbox with the same name forever. Unique
433 identifiers are assigned in a strictly ascending fashion in the
434 mailbox; as each message is added to the mailbox, it is assigned a
435 higher UID than those of all message(s) that are already in the
436 mailbox. Unlike message sequence numbers, unique identifiers are not
437 necessarily contiguous.
439 The unique identifier of a message MUST NOT change during the session
440 and SHOULD NOT change between sessions. Any change of unique
441 identifiers between sessions MUST be detectable using the UIDVALIDITY
442 mechanism discussed below. Persistent unique identifiers are
443 required for a client to resynchronize its state from a previous
444 session with the server (e.g., disconnected or offline access clients
445 [IMAP-MODEL]); this is discussed further in [IMAP-DISC].
447 Associated with every mailbox are two 32-bit unsigned non-zero values
448 that aid in unique identifier handling: the next unique identifier
449 value (UIDNEXT) and the unique identifier validity value
452 The next unique identifier value is the predicted value that will be
453 assigned to a new message in the mailbox. Unless the unique
454 identifier validity also changes (see below), the next unique
455 identifier value MUST have the following two characteristics. First,
456 the next unique identifier value MUST NOT change unless new messages
457 are added to the mailbox; and second, the next unique identifier
458 value MUST change whenever new messages are added to the mailbox,
459 even if those new messages are subsequently expunged.
461 | Note: The next unique identifier value is intended to provide a
462 | means for a client to determine whether any messages have been
463 | delivered to the mailbox since the previous time it checked
464 | this value. It is not intended to provide any guarantee that
465 | any message will have this unique identifier. A client can
466 | only assume, at the time that it obtains the next unique
467 | identifier value, that messages arriving after that time will
468 | have a UID greater than or equal to that value.
470 The unique identifier validity value is sent in a UIDVALIDITY
471 response code in an OK untagged response at mailbox selection time.
472 If unique identifiers from an earlier session fail to persist in this
473 session, the unique identifier validity value MUST be greater than
474 the one used in the earlier session. A good UIDVALIDITY value to use
475 is a 32-bit representation of the current date/time when the value is
476 assigned: this ensures that the value is unique and always increases.
477 Another possible alternative is a global counter that gets
478 incremented every time a mailbox is created.
480 Note: Ideally, unique identifiers SHOULD persist at all times.
481 Although this specification recognizes that failure to persist can
482 be unavoidable in certain server environments, it strongly
483 encourages message store implementation techniques that avoid this
484 problem. For example:
486 1. Unique identifiers MUST be strictly ascending in the mailbox at
487 all times. If the physical message store is reordered by a non-
488 IMAP agent, the unique identifiers in the mailbox MUST be
489 regenerated, since the former unique identifiers are no longer
490 strictly ascending as a result of the reordering.
492 2. If the message store has no mechanism to store unique
493 identifiers, it must regenerate unique identifiers at each
494 session, and each session must have a unique UIDVALIDITY value.
495 Note that this situation can be very disruptive to client message
498 3. If the mailbox is deleted/renamed and a new mailbox with the same
499 name is created at a later date, the server must either keep
500 track of unique identifiers from the previous instance of the
501 mailbox or assign a new UIDVALIDITY value to the new instance of
504 4. The combination of mailbox name, UIDVALIDITY, and UID must refer
505 to a single, immutable (or expunged) message on that server
506 forever. In particular, the internal date, RFC822.SIZE,
507 envelope, body structure, and message texts (all BODY[...] fetch
508 data items) MUST never change. This does not include message
509 numbers, nor does it include attributes that can be set by a
510 STORE command (such as FLAGS). When a message is expunged, its
511 UID MUST NOT be reused under the same UIDVALIDITY value.
5132.3.1.2. Message Sequence Number Message Attribute
515 A message sequence number is a relative position from 1 to the number
516 of messages in the mailbox. This position MUST be ordered by
517 ascending unique identifiers. As each new message is added, it is
518 assigned a message sequence number that is 1 higher than the number
519 of messages in the mailbox before that new message was added.
521 Message sequence numbers can be reassigned during the session. For
522 example, when a message is permanently removed (expunged) from the
523 mailbox, the message sequence number for all subsequent messages is
524 decremented. The number of messages in the mailbox is also
525 decremented. Similarly, a new message can be assigned a message
526 sequence number that was once held by some other message prior to an
529 In addition to accessing messages by relative position in the
530 mailbox, message sequence numbers can be used in mathematical
531 calculations. For example, if an untagged "11 EXISTS" is received,
532 and previously an untagged "8 EXISTS" was received, three new
533 messages have arrived with message sequence numbers of 9, 10, and 11.
534 As another example, if message 287 in a 523-message mailbox has UID
535 12345, there are exactly 286 messages that have lesser UIDs and 236
536 messages that have greater UIDs.
5382.3.2. Flags Message Attribute
540 A message has a list of zero or more named tokens, known as "flags",
541 associated with it. A flag is set by its addition to this list and
542 is cleared by its removal. There are two types of flags in
543 IMAP4rev2: system flags and keywords. A flag of either type can be
544 permanent or session-only.
546 A system flag is a flag name that is predefined in this specification
547 and begins with "\". Certain system flags (\Deleted and \Seen) have
548 special semantics described elsewhere in this document. The
549 currently defined system flags are:
551 \Seen Message has been read
553 \Answered Message has been answered
555 \Flagged Message is "flagged" for urgent/special attention
557 \Deleted Message is "deleted" for removal by later EXPUNGE
559 \Draft Message has not completed composition (marked as a
562 \Recent This flag was in use in IMAP4rev1 and is now
565 A keyword is defined by the server implementation. Keywords do not
566 begin with "\". Servers MAY permit the client to define new keywords
567 in the mailbox (see the description of the PERMANENTFLAGS response
568 code for more information). Some keywords that start with "$" are
569 also defined in this specification.
571 This document defines several keywords that were not originally
572 defined in [RFC3501] but were found to be useful by client
573 implementations. These keywords SHOULD be supported (allowed in
574 SEARCH and allowed and preserved in APPEND, COPY, and MOVE commands)
575 by server implementations:
578 Message has been forwarded to another email address by being
579 embedded within, or attached to a new message. An email client
580 sets this keyword when it successfully forwards the message to
581 another email address. Typical usage of this keyword is to show a
582 different (or additional) icon for a message that has been
583 forwarded. Once set, the flag SHOULD NOT be cleared.
586 Message Disposition Notification [RFC8098] was generated and sent
587 for this message. See [RFC3503] for more details on how this
588 keyword is used and for requirements on clients and servers.
591 The user (or a delivery agent on behalf of the user) may choose to
592 mark a message as definitely containing junk ($Junk; see also the
593 related keyword $NotJunk). The $Junk keyword can be used to mark,
594 group, or hide undesirable messages (and such messages might be
595 moved or deleted later). See [IMAP-KEYWORDS-REG] for more
599 The user (or a delivery agent on behalf of the user) may choose to
600 mark a message as definitely not containing junk ($NotJunk; see
601 also the related keyword $Junk). The $NotJunk keyword can be used
602 to mark, group, or show messages that the user wants to see. See
603 [IMAP-KEYWORDS-REG] for more information.
606 The $Phishing keyword can be used by a delivery agent to mark a
607 message as highly likely to be a phishing email. A message that's
608 determined to be a phishing email by the delivery agent should
609 also be considered a junk email and have the appropriate junk
610 filtering applied, including setting the $Junk flag and placing
611 the message in the \Junk special-use mailbox (see Section 7.3.1),
614 If both the $Phishing flag and the $Junk flag are set, the user
615 agent should display an additional warning message to the user.
616 Additionally, the user agent might display a warning, such as
617 something of the form, "This message may be trying to steal your
618 personal information," when the user clicks on any hyperlinks
621 The requirement for both $Phishing and $Junk to be set before a
622 user agent displays a warning is for better backwards
623 compatibility with existing clients that understand the $Junk flag
624 but not the $Phishing flag. This is so that when an unextended
625 client removes the $Junk flag, an extended client will also show
626 the correct state. See [IMAP-KEYWORDS-REG] for more information.
628 $Junk and $NotJunk are mutually exclusive. If more than one of these
629 is set for a message, the client MUST treat it as if none are set,
630 and it SHOULD unset both of them on the IMAP server.
632 Other registered keywords can be found in the "IMAP and JMAP
633 Keywords" registry [IMAP-KEYWORDS-REG]. New keywords SHOULD be
634 registered in this registry using the procedure specified in
637 A flag can be permanent or session-only on a per-flag basis.
638 Permanent flags are those that the client can add or remove from the
639 message flags permanently; that is, concurrent and subsequent
640 sessions will see any change in permanent flags. Changes to session
641 flags are valid only in that session.
6432.3.3. Internal Date Message Attribute
645 An Internal Date message attribute is the internal date and time of
646 the message on the server. This is not the date and time in the
647 [RFC5322] header but rather a date and time that reflects when the
648 message was received. In the case of messages delivered via [SMTP],
649 this is the date and time of final delivery of the message as defined
650 by [SMTP]. In the case of messages created by the IMAP4rev2 COPY or
651 MOVE command, this SHOULD be the same as the Internal Date attribute
652 of the source message. In the case of messages created by the
653 IMAP4rev2 APPEND command, this SHOULD be the date and time as
654 specified in the APPEND command description. All other cases are
655 implementation defined.
6572.3.4. RFC822.SIZE Message Attribute
659 RFC822.SIZE is the number of octets in the message when the message
660 is expressed in [RFC5322] format. This size SHOULD match the result
661 of a "FETCH BODY[]" command. If the message is internally stored in
662 some other format, the server calculates the size and often stores it
663 for later use to avoid the need for recalculation.
6652.3.5. Envelope Structure Message Attribute
667 An envelope structure is a parsed representation of the [RFC5322]
668 header of the message. Note that the IMAP envelope structure is not
669 the same as an [SMTP] envelope.
6712.3.6. Body Structure Message Attribute
673 A body structure is a parsed representation of the [MIME-IMB] body
674 structure information of the message.
678 In addition to being able to fetch the full [RFC5322] text of a
679 message, IMAP4rev2 permits the fetching of portions of the full
680 message text. Specifically, it is possible to fetch the [RFC5322]
681 message header, the [RFC5322] message body, a [MIME-IMB] body part,
682 or a [MIME-IMB] header.
6843. State and Flow Diagram
686 Once the connection between client and server is established, an
687 IMAP4rev2 connection is in one of four states. The initial state is
688 identified in the server greeting. Most commands are only valid in
689 certain states. It is a protocol error for the client to attempt a
690 command while the connection is in an inappropriate state, and the
691 server will respond with a BAD or NO (depending upon server
692 implementation) command completion result.
6943.1. Not Authenticated State
696 In the not authenticated state, the client MUST supply authentication
697 credentials before most commands will be permitted. This state is
698 entered when a connection starts unless the connection has been pre-
7013.2. Authenticated State
703 In the authenticated state, the client is authenticated and MUST
704 select a mailbox to access before commands that affect messages will
705 be permitted. This state is entered when a pre-authenticated
706 connection starts, when acceptable authentication credentials have
707 been provided, after an error in selecting a mailbox, or after a
708 successful CLOSE or UNSELECT command.
712 In a selected state, a mailbox has been selected to access. This
713 state is entered when a mailbox has been successfully selected.
717 In the logout state, the connection is being terminated. This state
718 can be entered as a result of a client request (via the LOGOUT
719 command) or by unilateral action on the part of either the client or
722 If the client requests the logout state, the server MUST send an
723 untagged BYE response and a tagged OK response to the LOGOUT command
724 before the server closes the connection; and the client MUST read the
725 tagged OK response to the LOGOUT command before the client closes the
728 A server SHOULD NOT unilaterally close the connection without first
729 sending an untagged BYE response that contains the reason for doing
730 so. A client SHOULD NOT unilaterally close the connection; instead,
731 it SHOULD issue a LOGOUT command. If the server detects that the
732 client has unilaterally closed the connection, the server MAY omit
733 the untagged BYE response and simply close its connection.
735 +----------------------+
736 |connection established|
737 +----------------------+
740 +--------------------------------------+
742 +--------------------------------------+
745 +-----------------+ || ||
746 |Not Authenticated| || ||
747 +-----------------+ || ||
750 || +----------------+ ||
751 || | Authenticated |<=++ ||
752 || +----------------+ || ||
753 || || (7) || (5) || (6) ||
755 || || +--------+ || ||
756 || || |Selected|==++ ||
760 +--------------------------------------+
762 +--------------------------------------+
765 +-------------------------------+
766 |both sides close the connection|
767 +-------------------------------+
769 Legend for the above diagram:
771 (1) connection without pre-authentication (OK greeting)
772 (2) pre-authenticated connection (PREAUTH greeting)
773 (3) rejected connection (BYE greeting)
774 (4) successful LOGIN or AUTHENTICATE command
775 (5) successful SELECT or EXAMINE command
776 (6) CLOSE or UNSELECT command, unsolicited CLOSED response code, or
777 failed SELECT or EXAMINE command
778 (7) LOGOUT command, server shutdown, or connection closed
782 IMAP4rev2 uses textual commands and responses. Data in IMAP4rev2 can
783 be in one of several forms: atom, number, string, parenthesized list,
784 or NIL. Note that a particular data item may take more than one
785 form; for example, a data item defined as using "astring" syntax may
786 be either an atom or a string.
790 An atom consists of one or more non-special characters.
7924.1.1. Sequence Set and UID Set
794 A set of messages can be referenced by a sequence set containing
795 either message sequence numbers or unique identifiers. See Section 9
796 for details. A sequence set can contain ranges of sequence numbers
797 (such as "5:50"), an enumeration of specific sequence numbers, or a
798 combination of the above. A sequence set can use the special symbol
799 "*" to represent the maximum sequence number in the mailbox. A
800 sequence set never contains unique identifiers.
802 A "UID set" is similar to the sequence set, but uses unique
803 identifiers instead of message sequence numbers, and is not permitted
804 to contain the special symbol "*".
808 A number consists of one or more digit characters and represents a
813 A string is in one of three forms: synchronizing literal, non-
814 synchronizing literal, or quoted string. The synchronizing literal
815 form is the general form of a string, without limitation on the
816 characters the string may include. The non-synchronizing literal
817 form is also the general form, but it has a length restriction. The
818 quoted string form is an alternative that avoids the overhead of
819 processing a literal, but has limitations on the characters that may
822 When the distinction between synchronizing and non-synchronizing
823 literals is not important, this document only uses the term
826 A synchronizing literal is a sequence of zero or more octets
827 (including CR and LF), prefix-quoted with an octet count in the form
828 of an open brace ("{"), the number of octets, a close brace ("}"),
829 and a CRLF. In the case of synchronizing literals transmitted from
830 server to client, the CRLF is immediately followed by the octet data.
831 In the case of synchronizing literals transmitted from client to
832 server, the client MUST wait to receive a command continuation
833 request (described later in this document) before sending the octet
834 data (and the remainder of the command).
836 The non-synchronizing literal is an alternative form of synchronizing
837 literal and may be used from client to server anywhere a
838 synchronizing literal is permitted. The non-synchronizing literal
839 form MUST NOT be sent from server to client. The non-synchronizing
840 literal is distinguished from the synchronizing literal by having a
841 plus ("+") between the octet count and the closing brace ("}"). The
842 server does not generate a command continuation request in response
843 to a non-synchronizing literal, and clients are not required to wait
844 before sending the octets of a non-synchronizing literal. Unless
845 otherwise specified in an IMAP extension, non-synchronizing literals
846 MUST NOT be larger than 4096 octets. Any literal larger than 4096
847 bytes MUST be sent as a synchronizing literal. (Non-synchronizing
848 literals defined in this document are the same as non-synchronizing
849 literals defined by the LITERAL- extension from [RFC7888]. See that
850 document for details on how to handle invalid non-synchronizing
851 literals longer than 4096 octets and for interaction with other IMAP
854 A quoted string is a sequence of zero or more Unicode characters,
855 excluding CR and LF, encoded in UTF-8, with double quote (<">)
856 characters at each end.
858 The empty string is represented as "" (a quoted string with zero
859 characters between double quotes), as {0} followed by a CRLF (a
860 synchronizing literal with an octet count of 0), or as {0+} followed
861 by a CRLF (a non-synchronizing literal with an octet count of 0).
863 Note: Even if the octet count is 0, a client transmitting a
864 synchronizing literal MUST wait to receive a command continuation
8674.3.1. 8-Bit and Binary Strings
869 8-bit textual and binary mail is supported through the use of a
870 [MIME-IMB] content transfer encoding. IMAP4rev2 implementations MAY
871 transmit 8-bit or multi-octet characters in literals but SHOULD do so
872 only when the [CHARSET] is identified.
874 IMAP4rev2 is compatible with [I18N-HDRS]. As a result, the
875 identified charset for header-field values with 8-bit content is
876 UTF-8 [UTF-8]. IMAP4rev2 implementations MUST accept and MAY
877 transmit [UTF-8] text in quoted-strings as long as the string does
878 not contain NUL, CR, or LF. This differs from IMAP4rev1
881 Although a BINARY content transfer encoding is defined, unencoded
882 binary strings are not permitted, unless returned in a <literal8> in
883 response to a BINARY.PEEK[<section-binary>]<<partial>> or
884 BINARY[<section-binary>]<<partial>> FETCH data item. A "binary
885 string" is any string with NUL characters. A string with an
886 excessive amount of CTL characters MAY also be considered to be
887 binary. Unless returned in response to BINARY.PEEK[...]/BINARY[...]
888 FETCH, client and server implementations MUST encode binary data into
889 a textual form, such as base64, before transmitting the data.
8914.4. Parenthesized List
893 Data structures are represented as a "parenthesized list"; a sequence
894 of data items, delimited by space, and bounded at each end by
895 parentheses. A parenthesized list can contain other parenthesized
896 lists, using multiple levels of parentheses to indicate nesting.
898 The empty list is represented as () -- a parenthesized list with no
903 The special form "NIL" represents the non-existence of a particular
904 data item that is represented as a string or parenthesized list, as
905 distinct from the empty string "" or the empty parenthesized list ().
907 | Note: NIL is never used for any data item that takes the form
908 | of an atom. For example, a mailbox name of "NIL" is a mailbox
909 | named NIL as opposed to a non-existent mailbox name. This is
910 | because mailbox uses "astring" syntax, which is an atom or a
911 | string. Conversely, an addr-name of NIL is a non-existent
912 | personal name, because addr-name uses "nstring" syntax, which
913 | is NIL or a string, but never an atom.
917 The following LIST response:
925 as LIST response ABNF is using "astring" for mailbox name.
927 However, the following response:
929 * FETCH 1 (BODY[1] NIL)
931 is not equivalent to:
933 * FETCH 1 (BODY[1] "NIL")
935 The former indicates absence of the body part, while the latter means
936 that it contains a string with the three characters "NIL".
9385. Operational Considerations
940 The following rules are listed here to ensure that all IMAP4rev2
941 implementations interoperate properly.
945 In IMAP4rev2, mailbox names are encoded in Net-Unicode [NET-UNICODE]
946 (this differs from IMAP4rev1). Client implementations MAY attempt to
947 create Net-Unicode mailbox names and MUST interpret any 8-bit mailbox
948 names returned by LIST as [NET-UNICODE]. Server implementations MUST
949 prohibit the creation of 8-bit mailbox names that do not comply with
950 Net-Unicode. However, servers MAY accept a denormalized UTF-8
951 mailbox name and convert it to Unicode Normalization Form C (NFC) (as
952 per Net-Unicode requirements) prior to mailbox creation. Servers
953 that choose to accept such denormalized UTF-8 mailbox names MUST
954 accept them in all IMAP commands that have a mailbox name parameter.
955 In particular, SELECT <name> must open the same mailbox that was
956 successfully created with CREATE <name>, even if <name> is a
957 denormalized UTF-8 mailbox name.
959 The case-insensitive mailbox name INBOX is a special name reserved to
960 mean "the primary mailbox for this user on this server". (Note that
961 this special name might not exist on some servers for some users, for
962 example, if the user has no access to personal namespace.) The
963 interpretation of all other names is implementation dependent.
965 In particular, this specification takes no position on case
966 sensitivity in non-INBOX mailbox names. Some server implementations
967 are fully case sensitive in ASCII range; others preserve the case of
968 a newly created name but otherwise are case insensitive; and yet
969 others coerce names to a particular case. Client implementations
970 must be able to interact with any of these.
972 There are certain client considerations when creating a new mailbox
975 1. Any character that is one of the atom-specials (see "Formal
976 Syntax" in Section 9) will require that the mailbox name be
977 represented as a quoted string or literal.
980 in a user interface and are best avoided. Servers MAY refuse to
981 create mailbox names containing Unicode CTL characters.
984 a mailbox name, it is difficult to use such mailbox names with
985 the LIST command due to the conflict with wildcard
988 4. Usually, a character (determined by the server implementation) is
989 reserved to delimit levels of hierarchy.
992 should be avoided except when used in that convention. See
993 Section 5.1.2.1 and Appendix A.1, respectively.
9955.1.1. Mailbox Hierarchy Naming
997 If it is desired to export hierarchical mailbox names, mailbox names
998 MUST be left-to-right hierarchical, using a single ASCII character to
999 separate levels of hierarchy. The same hierarchy separator character
1000 is used for all levels of hierarchy within a single name.
1005 A namespace that the server considers within the personal scope of
1006 the authenticated user on a particular connection. Typically,
1007 only the authenticated user has access to mailboxes in their
1008 Personal Namespace. It is the part of the namespace that belongs
1009 to the user and is allocated for mailboxes. If an INBOX exists
1010 for a user, it MUST appear within the user's Personal Namespace.
1011 In the typical case, there SHOULD be only one Personal Namespace
1012 per user on a server.
1014 Other Users' Namespace:
1015 A namespace that consists of mailboxes from the Personal
1016 Namespaces of other users. To access mailboxes in the Other
1017 Users' Namespace, the currently authenticated user MUST be
1018 explicitly granted access rights. For example, it is common for a
1019 manager to grant to their administrative support staff access
1020 rights to their mailbox. In the typical case, there SHOULD be
1021 only one Other Users' Namespace per user on a server.
1024 A namespace that consists of mailboxes that are intended to be
1025 shared amongst users and do not exist within a user's Personal
1028 The namespaces a server uses MAY differ on a per-user basis.
10305.1.2.1. Historic Mailbox Namespace Naming Convention
1032 By convention, the first hierarchical element of any mailbox name
1033 that begins with "#" identifies the "namespace" of the remainder of
1034 the name. This makes it possible to disambiguate between different
1035 types of mailbox stores, each of which have their own namespaces.
1037 For example, implementations that offer access to USENET
1038 newsgroups MAY use the "#news" namespace to partition the USENET
1039 newsgroup namespace from that of other mailboxes. Thus, the
1040 comp.mail.misc newsgroup would have a mailbox name of
1041 "#news.comp.mail.misc", and the name "comp.mail.misc" can refer to
1042 a different object (e.g., a user's private mailbox).
1044 Namespaces that include the "#" character are not IMAP URL [IMAP-URL]
1045 friendly and require the "#" character to be represented as %23 when
1046 within URLs. As such, server implementors MAY instead consider using
1047 namespace prefixes that do not contain the "#" character.
10495.1.2.2. Common Namespace Models
1051 The previous version of this protocol did not define a default server
1052 namespace. Two common namespace models have evolved:
1054 The "Personal Mailbox" model, in which the default namespace that is
1055 presented consists of only the user's personal mailboxes. To access
1056 shared mailboxes, the user must use an escape mechanism to reach
1059 The "Complete Hierarchy" model, in which the default namespace that
1060 is presented includes the user's personal mailboxes along with any
1061 other mailboxes they have access to.
10635.2. Mailbox Size and Message Status Updates
1065 At any time, a server can send data that the client did not request.
1066 Sometimes, such behavior is required by this specification and/or
1067 extensions. For example, agents other than the server may add
1068 messages to the mailbox (e.g., new message delivery); change the
1069 flags of the messages in the mailbox (e.g., simultaneous access to
1070 the same mailbox by multiple agents); or even remove messages from
1071 the mailbox. A server MUST send mailbox size updates automatically
1072 if a mailbox size change is observed during the processing of a
1073 command. A server SHOULD send message flag updates automatically,
1074 without requiring the client to request such updates explicitly.
1076 Special rules exist for server notification of a client about the
1077 removal of messages to prevent synchronization errors; see the
1078 description of the EXPUNGE response (Section 7.5.1) for more detail.
1079 In particular, it is NOT permitted to send an EXISTS response that
1080 would reduce the number of messages in the mailbox; only the EXPUNGE
1081 response can do this.
1083 Regardless of what implementation decisions a client makes on
1084 remembering data from the server, a client implementation MUST
1085 remember mailbox size updates. It MUST NOT assume that any command
1086 after the initial mailbox selection will return the size of the
10895.3. Response When No Command in Progress
1091 Server implementations are permitted to send an untagged response
1092 (except for EXPUNGE) while there is no command in progress. Server
1093 implementations that send such responses MUST deal with flow control
1094 considerations. Specifically, they MUST either (1) verify that the
1095 size of the data does not exceed the underlying transport's available
1096 window size or (2) use non-blocking writes.
10985.4. Autologout Timer
1100 If a server has an inactivity autologout timer that applies to
1101 sessions after authentication, the duration of that timer MUST be at
1102 least 30 minutes. The receipt of any command from the client during
1103 that interval resets the autologout timer.
1105 Note that this specification doesn't have any restrictions on an
1106 autologout timer used before successful client authentication. In
1107 particular, servers are allowed to use a shortened pre-authentication
1108 timer to protect themselves from Denial-of-Service attacks.
1112 The client MAY send another command without waiting for the
1113 completion result response of a command, subject to ambiguity rules
1114 (see below) and flow control constraints on the underlying data
1115 stream. Similarly, a server MAY begin processing another command
1116 before processing the current command to completion, subject to
1117 ambiguity rules. However, any command continuation request responses
1118 and command continuations MUST be negotiated before any subsequent
1119 command is initiated.
1121 The exception is if an ambiguity would result because of a command
1122 that would affect the results of other commands. If the server
1123 detects a possible ambiguity, it MUST execute commands to completion
1124 in the order given by the client.
1126 The most obvious example of ambiguity is when a command would affect
1127 the results of another command. One example is a FETCH that would
1128 cause \Seen flags to be set and a SEARCH UNSEEN command.
1130 A non-obvious ambiguity occurs with commands that permit an untagged
1131 EXPUNGE response (commands other than FETCH, STORE, and SEARCH),
1132 since an untagged EXPUNGE response can invalidate sequence numbers in
1133 a subsequent command. This is not a problem for FETCH, STORE, or
1134 SEARCH commands because servers are prohibited from sending EXPUNGE
1135 responses while any of those commands are in progress. Therefore, if
1136 the client sends any command other than FETCH, STORE, or SEARCH, it
1137 MUST wait for the completion result response before sending a command
1138 with message sequence numbers.
1140 Note: EXPUNGE responses are permitted while UID FETCH, UID STORE,
1141 and UID SEARCH are in progress. If the client sends a UID
1142 command, it MUST wait for a completion result response before
1143 sending a command that uses message sequence numbers (this may
1144 include UID SEARCH). Any message sequence numbers in an argument
1145 to UID SEARCH are associated with messages prior to the effect of
1146 any untagged EXPUNGE responses returned by the UID SEARCH.
1148 For example, the following non-waiting command sequences are invalid:
1150 FETCH + NOOP + STORE
1152 STORE + COPY + FETCH
1156 The following are examples of valid non-waiting command sequences:
1158 FETCH + STORE + SEARCH + NOOP
1160 STORE + COPY + EXPUNGE
1162 UID SEARCH + UID SEARCH may be valid or invalid as a non-waiting
1163 command sequence, depending upon whether or not the second UID SEARCH
1164 contains message sequence numbers.
1166 Use of a SEARCH result variable (see Section 6.4.4.1) creates direct
1167 dependency between two commands. See Section 6.4.4.2 for more
1168 considerations about pipelining such dependent commands.
1172 IMAP4rev2 commands are described in this section. Commands are
1173 organized by the state in which the command is permitted. Commands
1174 that are permitted in multiple states are listed in the minimum
1175 permitted state (for example, commands valid in authenticated and
1176 selected states are listed in the authenticated state commands).
1178 Command arguments, identified by "Arguments:" in the command
1179 descriptions below, are described by function, not by syntax. The
1180 precise syntax of command arguments is described in "Formal Syntax"
1183 Some commands cause specific server responses to be returned; these
1184 are identified by "Responses:" in the command descriptions below.
1185 See the response descriptions in "Responses" (Section 7) for
1186 information on these responses and in "Formal Syntax" (Section 9) for
1187 the precise syntax of these responses. It is possible for server
1188 data to be transmitted as a result of any command. Thus, commands
1189 that do not specifically require server data specify "no specific
1190 responses for this command" instead of "none".
1192 The "Result:" in the command description refers to the possible
1193 tagged status responses to a command and any special interpretation
1194 of these status responses.
1196 The state of a connection is only changed by successful commands that
1197 are documented as changing state. A rejected command (BAD response)
1198 never changes the state of the connection or of the selected mailbox.
1199 A failed command (NO response) generally does not change the state of
1200 the connection or of the selected mailbox, with the exception of the
1201 SELECT and EXAMINE commands.
12036.1. Client Commands - Any State
1205 The following commands are valid in any state: CAPABILITY, NOOP, and
1212 Responses: REQUIRED untagged response: CAPABILITY
1214 Result: OK - capability completed
1215 BAD - arguments invalid
1217 The CAPABILITY command requests a listing of capabilities (e.g.,
1218 extensions and/or modifications of server behavior) that the server
1219 supports. The server MUST send a single untagged CAPABILITY response
1220 with "IMAP4rev2" as one of the listed capabilities before the
1221 (tagged) OK response.
1223 A capability name that begins with "AUTH=" indicates that the server
1224 supports that particular authentication mechanism as defined in the
1225 Simple Authentication and Security Layer (SASL) [SASL]. All such
1226 names are, by definition, part of this specification.
1228 Other capability names refer to extensions, revisions, or amendments
1229 to this specification. See the documentation of the CAPABILITY
1230 response in Section 7.2.2 for additional information. If IMAP4rev1
1231 capability is not advertised, no capabilities, beyond the base
1232 IMAP4rev2 set defined in this specification, are enabled without
1233 explicit client action to invoke the capability. If both IMAP4rev1
1234 and IMAP4rev2 capabilities are advertised, no capabilities, beyond
1235 the base IMAP4rev1 set specified in [RFC3501], are enabled without
1236 explicit client action to invoke the capability.
1239 (Section 6.2.1) and LOGINDISABLED capabilities on cleartext ports.
1240 Client and server implementations MUST also implement AUTH=PLAIN
1241 (described in [PLAIN]) capability on both cleartext and Implicit TLS
1242 ports. See the Security Considerations (Section 11) for important
1245 Unless otherwise specified, all registered extensions to IMAP4rev1
1246 are also valid extensions to IMAP4rev2.
1251 S: * CAPABILITY IMAP4rev2 STARTTLS AUTH=GSSAPI
1253 S: abcd OK CAPABILITY completed
1255 S: efgh OK STARTTLS completed
1256 <TLS negotiation, further commands are under TLS layer>
1258 S: * CAPABILITY IMAP4rev2 AUTH=GSSAPI AUTH=PLAIN
1259 S: ijkl OK CAPABILITY completed
1265 Responses: no specific responses for this command (but see below)
1267 Result: OK - noop completed
1268 BAD - command unknown or arguments invalid
1270 The NOOP command always succeeds. It does nothing.
1272 Since any command can return a status update as untagged data, the
1273 NOOP command can be used as a periodic poll for new messages or
1274 message status updates during a period of inactivity (the IDLE
1275 command; see Section 6.3.13) should be used instead of NOOP if real-
1276 time updates to mailbox state are desirable). The NOOP command can
1277 also be used to reset any inactivity autologout timer on the server.
1282 S: a002 OK NOOP completed
1287 S: * 14 FETCH (UID 1305 FLAGS (\Seen \Deleted))
1288 S: a047 OK NOOP completed
1294 Responses: REQUIRED untagged response: BYE
1296 Result: OK - logout completed
1297 BAD - command unknown or arguments invalid
1299 The LOGOUT command informs the server that the client is done with
1300 the connection. The server MUST send a BYE untagged response before
1301 the (tagged) OK response, and then close the network connection.
1306 S: * BYE IMAP4rev2 Server logging out
1307 S: A023 OK LOGOUT completed
1308 (Server and client then close the connection)
13106.2. Client Commands - Not Authenticated State
1312 In the not authenticated state, the AUTHENTICATE or LOGIN command
1313 establishes authentication and enters the authenticated state. The
1314 AUTHENTICATE command provides a general mechanism for a variety of
1315 authentication techniques, privacy protection, and integrity
1316 checking, whereas the LOGIN command uses a conventional user name and
1317 plaintext password pair and has no means of establishing privacy
1318 protection or integrity checking.
1320 The STARTTLS command is an alternative form of establishing session
1321 privacy protection and integrity checking but does not by itself
1322 establish authentication or enter the authenticated state.
1324 Server implementations MAY allow access to certain mailboxes without
1325 establishing authentication. This can be done by means of the
1326 ANONYMOUS [SASL] authenticator described in [ANONYMOUS]. An older
1327 convention is a LOGIN command using the userid "anonymous"; in this
1328 case, a password is required although the server may choose to accept
1329 any password. The restrictions placed on anonymous users are
1330 implementation dependent.
1332 Once authenticated (including as anonymous), it is not possible to
1333 re-enter not authenticated state.
1335 In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
1336 the following commands are valid in the not authenticated state:
1337 STARTTLS, AUTHENTICATE, and LOGIN. See the Security Considerations
1338 (Section 11) for important information about these commands.
1344 Responses: no specific response for this command
1346 Result: OK - starttls completed, begin TLS negotiation
1347 NO - TLS negotiation can't be initiated, due to server
1349 BAD - STARTTLS received after a successful TLS
1350 negotiation or arguments invalid
1352 Note that the STARTTLS command is available only on cleartext ports.
1354 STARTTLS command is received on an Implicit TLS port.
1356 A TLS [TLS-1.3] negotiation begins immediately after the CRLF at the
1357 end of the tagged OK response from the server. Once a client issues
1358 a STARTTLS command, it MUST NOT issue further commands until a server
1359 response is seen and the TLS negotiation is complete. Some past
1360 server implementations incorrectly implemented STARTTLS processing
1361 and are known to contain STARTTLS plaintext command injection
1362 vulnerability [CERT-555316]. In order to avoid this vulnerability,
1363 server implementations MUST do one of the following if any data is
1364 received in the same TCP buffer after the CRLF that starts the
1367 1. Extra data from the TCP buffer is interpreted as the beginning of
1368 the TLS handshake. (If the data is in cleartext, this will
1369 result in the TLS handshake failing.)
1371 2. Extra data from the TCP buffer is thrown away.
1373 Note that the first option is friendlier to clients that pipeline the
1374 beginning of the STARTTLS command with TLS handshake data.
1376 After successful TLS negotiation, the server remains in the non-
1377 authenticated state, even if client credentials are supplied during
1378 the TLS negotiation. This does not preclude an authentication
1379 mechanism such as EXTERNAL (defined in [SASL]) from using client
1380 identity determined by the TLS negotiation.
1382 Once TLS has been started, the client MUST discard cached information
1383 about server capabilities and SHOULD reissue the CAPABILITY command.
1384 This is necessary to protect against active attacks that alter the
1385 capabilities list prior to STARTTLS. The server MAY advertise
1386 different capabilities and, in particular, SHOULD NOT advertise the
1387 STARTTLS capability, after a successful STARTTLS command.
1392 S: * CAPABILITY IMAP4rev2 STARTTLS LOGINDISABLED
1393 S: a001 OK CAPABILITY completed
1395 S: a002 OK Begin TLS negotiation now
1396 <TLS negotiation, further commands are under TLS layer>
1398 S: * CAPABILITY IMAP4rev2 AUTH=PLAIN
1399 S: a003 OK CAPABILITY completed
1400 C: a004 AUTHENTICATE PLAIN dGVzdAB0ZXN0AHRlc3Q=
1401 S: a004 OK Success (tls protection)
1405 Arguments: SASL authentication mechanism name
1409 Responses: continuation data can be requested
1411 Result: OK - authenticate completed, now in authenticated
1413 NO - authenticate failure: unsupported authentication
1414 mechanism, credentials rejected
1415 BAD - command unknown or arguments invalid,
1416 authentication exchange canceled
1418 The AUTHENTICATE command indicates a [SASL] authentication mechanism
1419 to the server. If the server supports the requested authentication
1420 mechanism, it performs an authentication protocol exchange to
1421 authenticate and identify the client. It MAY also negotiate an
1422 OPTIONAL security layer for subsequent protocol interactions. If the
1423 requested authentication mechanism is not supported, the server
1424 SHOULD reject the AUTHENTICATE command by sending a tagged NO
1427 The AUTHENTICATE command supports the optional "initial response"
1428 feature defined in Section 4 of [SASL]. The client doesn't need to
1429 use it. If a SASL mechanism supports "initial response", but it is
1430 not specified by the client, the server handles it as specified in
1431 Section 3 of [SASL].
1433 The service name specified by this protocol's profile of [SASL] is
1436 The authentication protocol exchange consists of a series of server
1437 challenges and client responses that are specific to the
1438 authentication mechanism. A server challenge consists of a command
1439 continuation request response with the "+" token followed by a
1440 base64-encoded (see Section 4 of [RFC4648]) string. The client
1441 response consists of a single line consisting of a base64-encoded
1443 it issues a line consisting of a single "*". If the server receives
1444 such a response, or if it receives an invalid base64 string (e.g.,
1445 characters outside the base64 alphabet or non-terminal "="), it MUST
1446 reject the AUTHENTICATE command by sending a tagged BAD response.
1448 As with any other client response, the initial response MUST be
1449 encoded as base64. It also MUST be transmitted outside of a quoted
1451 client MUST send a single pad character ("="). This indicates that
1452 the response is present, but it is a zero-length string.
1454 When decoding the base64 data in the initial response, decoding
1455 errors MUST be treated as in any normal SASL client response, i.e.,
1456 with a tagged BAD response. In particular, the server should check
1457 for any characters not explicitly allowed by the base64 alphabet, as
1458 well as any sequence of base64 characters that contains the pad
1459 character ('=') anywhere other than the end of the string (e.g.,
1460 "=AAA" and "AAA=BBB" are not allowed).
1463 does not support an initial response, the server MUST reject the
1464 command with a tagged BAD response.
1466 If a security layer is negotiated through the [SASL] authentication
1467 exchange, it takes effect immediately following the CRLF that
1468 concludes the authentication exchange for the client and the CRLF of
1469 the tagged OK response for the server.
1471 While client and server implementations MUST implement the
1472 AUTHENTICATE command itself, it is not required to implement any
1473 authentication mechanisms other than the PLAIN mechanism described in
1474 [PLAIN]. Also, an authentication mechanism is not required to
1475 support any security layers.
1477 Note: a server implementation MUST implement a configuration in
1478 which it does NOT permit any plaintext password mechanisms, unless
1479 the STARTTLS command has been negotiated, TLS has been negotiated
1480 on an Implicit TLS port, or some other mechanism that protects the
1481 session from password snooping has been provided. Server sites
1482 SHOULD NOT use any configuration that permits a plaintext password
1483 mechanism without such a protection mechanism against password
1484 snooping. Client and server implementations SHOULD implement
1485 additional [SASL] mechanisms that do not use plaintext passwords,
1486 such as the GSSAPI mechanism described in [RFC4752], the SCRAM-
1487 SHA-256/SCRAM-SHA-256-PLUS [SCRAM-SHA-256] mechanisms, and/or the
1488 EXTERNAL [SASL] mechanism for mutual TLS authentication. (Note
1489 that the SASL framework allows for the creation of SASL mechanisms
1490 that support 2-factor authentication (2FA); however, none are
1491 fully ready to be recommended by this document.)
1493 Servers and clients can support multiple authentication mechanisms.
1494 The server SHOULD list its supported authentication mechanisms in the
1495 response to the CAPABILITY command so that the client knows which
1496 authentication mechanisms to use.
1498 A server MAY include a CAPABILITY response code in the tagged OK
1499 response of a successful AUTHENTICATE command in order to send
1500 capabilities automatically. It is unnecessary for a client to send a
1501 separate CAPABILITY command if it recognizes these automatic
1502 capabilities. This should only be done if a security layer was not
1503 negotiated by the AUTHENTICATE command, because the tagged OK
1504 response as part of an AUTHENTICATE command is not protected by
1505 encryption/integrity checking. [SASL] requires the client to re-
1506 issue a CAPABILITY command in this case. The server MAY advertise
1507 different capabilities after a successful AUTHENTICATE command.
1509 If an AUTHENTICATE command fails with a NO response, the client MAY
1510 try another authentication mechanism by issuing another AUTHENTICATE
1511 command. It MAY also attempt to authenticate by using the LOGIN
1512 command (see Section 6.2.3 for more detail). In other words, the
1513 client MAY request authentication types in decreasing order of
1514 preference, with the LOGIN command as a last resort.
1516 The authorization identity passed from the client to the server
1517 during the authentication exchange is interpreted by the server as
1518 the user name whose privileges the client is requesting.
1522 S: * OK [CAPABILITY IMAP4rev2 STARTTLS AUTH=GSSAPI]
1524 C: A001 AUTHENTICATE GSSAPI
1526 C: YIIB+wYJKoZIhvcSAQICAQBuggHqMIIB5qADAgEFoQMCAQ6iBw
1527 MFACAAAACjggEmYYIBIjCCAR6gAwIBBaESGxB1Lndhc2hpbmd0
1528 b24uZWR1oi0wK6ADAgEDoSQwIhsEaW1hcBsac2hpdmFtcy5jYW
1529 Mud2FzaGluZ3Rvbi5lZHWjgdMwgdCgAwIBAaEDAgEDooHDBIHA
1530 cS1GSa5b+fXnPZNmXB9SjL8Ollj2SKyb+3S0iXMljen/jNkpJX
1531 AleKTz6BQPzj8duz8EtoOuNfKgweViyn/9B9bccy1uuAE2HI0y
1532 C/PHXNNU9ZrBziJ8Lm0tTNc98kUpjXnHZhsMcz5Mx2GR6dGknb
1533 I0iaGcRerMUsWOuBmKKKRmVMMdR9T3EZdpqsBd7jZCNMWotjhi
1534 vd5zovQlFqQ2Wjc2+y46vKP/iXxWIuQJuDiisyXF0Y8+5GTpAL
1535 pHDc1/pIGmMIGjoAMCAQGigZsEgZg2on5mSuxoDHEA1w9bcW9n
1536 FdFxDKpdrQhVGVRDIzcCMCTzvUboqb5KjY1NJKJsfjRQiBYBdE
1537 NKfzK+g5DlV8nrw81uOcP8NOQCLR5XkoMHC0Dr/80ziQzbNqhx
1538 O6652Npft0LQwJvenwDI13YxpwOdMXzkWZN/XrEqOWp6GCgXTB
1539 vCyLWLlWnbaUkZdEYbKHBPjd8t/1x5Yg==
1540 S: + YGgGCSqGSIb3EgECAgIAb1kwV6ADAgEFoQMCAQ+iSzBJoAMC
1541 AQGiQgRAtHTEuOP2BXb9sBYFR4SJlDZxmg39IxmRBOhXRKdDA0
1542 uHTCOT9Bq3OsUTXUlk0CsFLoa8j+gvGDlgHuqzWHPSQg==
1544 S: + YDMGCSqGSIb3EgECAgIBAAD/////6jcyG4GE3KkTzBeBiVHe
1545 ceP2CWY0SR0fAQAgAAQEBAQ=
1546 C: YDMGCSqGSIb3EgECAgIBAAD/////3LQBHXTpFfZgrejpLlLImP
1547 wkhbfa2QteAQAgAG1yYwE=
1548 S: A001 OK GSSAPI authentication successful
1550 The following example demonstrates the use of an initial response.
1554 S: * OK [CAPABILITY IMAP4rev2 STARTTLS AUTH=GSSAPI
1555 LOGINDISABLED] Server ready
1557 S: A01 OK STARTTLS completed
1558 <TLS negotiation, further commands are under TLS layer>
1560 S: * CAPABILITY IMAP4rev2 AUTH=GSSAPI AUTH=PLAIN
1561 S: A02 OK CAPABILITY completed
1562 C: A03 AUTHENTICATE PLAIN dGVzdAB0ZXN0AHRlc3Q=
1563 S: A03 OK Success (tls protection)
1565 Note that because the initial response is optional, the following
1566 negotiation (which does not use the initial response) is still valid
1567 and MUST be supported by the server:
1569 ... client connects to server and negotiates a TLS
1570 protection layer ...
1572 S: * CAPABILITY IMAP4rev2 AUTH=PLAIN
1574 C: A01 AUTHENTICATE PLAIN
1576 C: dGVzdAB0ZXN0AHRlc3Q=
1577 S: A01 OK Success (tls protection)
1579 Note that in the above example there is a space following the "+"
1582 The following is an example authentication using the SASL EXTERNAL
1583 mechanism (defined in [SASL]) under a TLS protection layer and an
1584 empty initial response:
1586 ... client connects to server and negotiates a TLS
1587 protection layer ...
1589 S: * CAPABILITY IMAP4rev2 AUTH=PLAIN AUTH=EXTERNAL
1591 C: A01 AUTHENTICATE EXTERNAL =
1592 S: A01 OK Success (tls protection)
1594 Note: The line breaks within server challenges and client responses
1595 are for editorial clarity and are not in real authenticators.
1599 Arguments: user name
1603 Responses: no specific responses for this command
1605 Result: OK - login completed, now in authenticated state
1606 NO - login failure: user name or password rejected
1607 BAD - command unknown or arguments invalid
1609 The LOGIN command identifies the client to the server and carries the
1610 plaintext password authenticating this user. The LOGIN command
1611 SHOULD NOT be used except as a last resort (after attempting and
1612 failing to authenticate using the AUTHENTICATE command one or more
1613 times), and it is recommended that client implementations have a
1614 means to disable any automatic use of the LOGIN command.
1616 A server MAY include a CAPABILITY response code in the tagged OK
1617 response to a successful LOGIN command in order to send capabilities
1618 automatically. It is unnecessary for a client to send a separate
1619 CAPABILITY command if it recognizes these automatic capabilities.
1623 C: a001 LOGIN SMITH SESAME
1624 S: a001 OK LOGIN completed
1626 Note: Use of the LOGIN command over an insecure network (such as the
1627 Internet) is a security risk, because anyone monitoring network
1628 traffic can obtain plaintext passwords. For that reason, clients
1629 MUST NOT use LOGIN on unsecure networks.
1631 Unless the client is accessing IMAP service on an Implicit TLS port
1632 [RFC8314], the STARTTLS command has been negotiated, or some other
1633 mechanism that protects the session from password snooping has been
1634 provided, a server implementation MUST implement a configuration in
1635 which it advertises the LOGINDISABLED capability and does NOT permit
1636 the LOGIN command. Server sites SHOULD NOT use any configuration
1637 that permits the LOGIN command without such a protection mechanism
1638 against password snooping. A client implementation MUST NOT send a
1639 LOGIN command if the LOGINDISABLED capability is advertised.
16416.3. Client Commands - Authenticated State
1643 In the authenticated state, commands that manipulate mailboxes as
1644 atomic entities are permitted. Of these commands, SELECT and EXAMINE
1645 will select a mailbox for access and enter the selected state.
1647 In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
1648 the following commands are valid in the authenticated state: ENABLE,
1649 SELECT, EXAMINE, NAMESPACE, CREATE, DELETE, RENAME, SUBSCRIBE,
1650 UNSUBSCRIBE, LIST, STATUS, APPEND, and IDLE.
1654 Arguments: capability names
1656 Responses: no specific responses for this command
1658 Result: OK - Relevant capabilities enabled
1659 BAD - No arguments, or syntax error in an argument
1661 Several IMAP extensions allow the server to return unsolicited
1662 responses specific to these extensions in certain circumstances.
1663 However, servers cannot send those unsolicited responses (with the
1664 exception of response codes (see Section 7.1) included in tagged or
1665 untagged OK/NO/BAD responses, which can always be sent) until they
1666 know that the clients support such extensions and thus will be able
1667 to correctly parse and process the extension response data.
1669 The ENABLE command provides an explicit indication from the client
1670 that it supports particular extensions. It is designed such that the
1671 client can send a simple constant string with the extensions it
1672 supports, and the server will enable the shared subset that both
1675 The ENABLE command takes a list of capability names and requests the
1676 server to enable the named extensions. Once enabled using ENABLE,
1677 each extension remains active until the IMAP connection is closed.
1678 For each argument, the server does the following:
1680 * If the argument is not an extension known to the server, the
1681 server MUST ignore the argument.
1683 * If the argument is an extension known to the server, and it is not
1684 specifically permitted to be enabled using ENABLE, the server MUST
1685 ignore the argument. (Note that knowing about an extension
1686 doesn't necessarily imply supporting that extension.)
1688 * If the argument is an extension that is supported by the server
1689 and that needs to be enabled, the server MUST enable the extension
1690 for the duration of the connection. Note that once an extension
1691 is enabled, there is no way to disable it.
1693 If the ENABLE command is successful, the server MUST send an untagged
1694 ENABLED response (Section 7.2.1), which includes all enabled
1695 extensions as specified above. The ENABLED response is sent even if
1696 no extensions were enabled.
1698 Clients SHOULD only include extensions that need to be enabled by the
1699 server. For example, a client can enable IMAP4rev2-specific behavior
1700 when both IMAP4rev1 and IMAP4rev2 are advertised in the CAPABILITY
1701 response. Future RFCs may add to this list.
1703 The ENABLE command is only valid in the authenticated state, before
1704 any mailbox is selected. Clients MUST NOT issue ENABLE once they
1705 SELECT/EXAMINE a mailbox; however, server implementations don't have
1706 to check that no mailbox is selected or was previously selected
1707 during the duration of a connection.
1709 The ENABLE command can be issued multiple times in a session. It is
1710 additive; that is, "ENABLE a b", followed by "ENABLE c", is the same
1711 as a single command "ENABLE a b c". When multiple ENABLE commands
1712 are issued, each corresponding ENABLED response SHOULD only contain
1713 extensions enabled by the corresponding ENABLE command, i.e., for the
1714 above example, the ENABLED response to "ENABLE c" should not contain
1717 There are no limitations on pipelining ENABLE. For example, it is
1718 possible to send ENABLE and then immediately SELECT, or a LOGIN
1719 immediately followed by ENABLE.
1721 The server MUST NOT change the CAPABILITY list as a result of
1722 executing ENABLE; that is, a CAPABILITY command issued right after an
1723 ENABLE command MUST list the same capabilities as a CAPABILITY
1724 command issued before the ENABLE command. This is demonstrated in
1725 the following example. Note that below "X-GOOD-IDEA" is a fictitious
1726 extension capability that can be ENABLED.
1729 S: * CAPABILITY IMAP4rev2 ID LITERAL+ X-GOOD-IDEA
1731 C: t2 ENABLE CONDSTORE X-GOOD-IDEA
1732 S: * ENABLED X-GOOD-IDEA
1735 S: * CAPABILITY IMAP4rev2 ID LITERAL+ X-GOOD-IDEA
1738 In the following example, the client enables the Conditional Store
1739 (CONDSTORE) extension [RFC7162]:
1741 C: a1 ENABLE CONDSTORE
1742 S: * ENABLED CONDSTORE
1743 S: a1 OK Conditional Store enabled
17456.3.1.1. Note to Designers of Extensions That May Use the ENABLE
1748 Designers of IMAP extensions are discouraged from creating extensions
1749 that require ENABLE unless there is no good alternative design.
1750 Specifically, extensions that cause potentially incompatible behavior
1751 changes to deployed server responses (and thus benefit from ENABLE)
1752 have a higher complexity cost than extensions that do not.
1756 Arguments: mailbox name
1758 Responses: REQUIRED untagged responses: FLAGS, EXISTS, LIST
1759 REQUIRED OK untagged responses: PERMANENTFLAGS,
1760 UIDNEXT, UIDVALIDITY
1762 Result: OK - select completed, now in selected state
1763 NO - select failure, now in authenticated state: no
1764 such mailbox, can't access mailbox
1765 BAD - command unknown or arguments invalid
1767 The SELECT command selects a mailbox so that messages in the mailbox
1768 can be accessed. Before returning an OK to the client, the server
1769 MUST send the following untagged data to the client. (The order of
1770 individual responses is not important.) Note that earlier versions
1771 of this protocol, such as the IMAP4rev1 version specified in
1772 [RFC2060], only required the FLAGS and EXISTS untagged responses and
1773 UIDVALIDITY response code. Client implementations that need to
1774 remain compatible with such older IMAP versions have to implement
1775 default behavior for missing data, as discussed with the individual
1779 Defined flags in the mailbox. See the description of the FLAGS
1780 response in Section 7.3.5 for more detail.
1783 The number of messages in the mailbox. See the description of the
1784 EXISTS response in Section 7.4.1 for more detail.
1787 The server MUST return a LIST response with the mailbox name. The
1788 list of mailbox attributes MUST be accurate. If the server allows
1789 denormalized UTF-8 mailbox names (see Section 5.1) and the
1790 supplied mailbox name differs from the normalized version, the
1791 server MUST return LIST with the OLDNAME extended data item. See
1792 Section 6.3.9.7 for more details.
1794 OK [PERMANENTFLAGS (<list of flags>)]
1795 A list of message flags that the client can change permanently.
1796 If this is missing, the client should assume that all flags can be
1797 changed permanently.
1800 The next unique identifier value. Refer to Section 2.3.1.1 for
1803 OK [UIDVALIDITY <n>]
1804 The unique identifier validity value. Refer to Section 2.3.1.1
1805 for more information.
1807 Only one mailbox can be selected at a time in a connection;
1808 simultaneous access to multiple mailboxes requires multiple
1810 currently selected mailbox before attempting the new selection.
1811 Consequently, if a mailbox is selected and a SELECT command that
1813 selected mailbox, the server MUST return an untagged OK response with
1814 the "[CLOSED]" response code when the currently selected mailbox is
1815 closed (see Section 7.1).
1817 If the client is permitted to modify the mailbox, the server SHOULD
1818 prefix the text of the tagged OK response with the "[READ-WRITE]"
1821 If the client is not permitted to modify the mailbox but is permitted
1822 read access, the mailbox is selected as read-only, and the server
1823 MUST prefix the text of the tagged OK response to SELECT with the
1824 "[READ-ONLY]" response code. Read-only access through SELECT differs
1825 from the EXAMINE command in that certain read-only mailboxes MAY
1826 permit the change of permanent state on a per-user (as opposed to
1827 global) basis. Netnews messages marked in a server-based .newsrc
1828 file are an example of such per-user permanent state that can be
1829 modified with read-only mailboxes.
1833 C: A142 SELECT INBOX
1835 S: * OK [UIDVALIDITY 3857529045] UIDs valid
1836 S: * OK [UIDNEXT 4392] Predicted next UID
1837 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
1838 S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
1839 S: * LIST () "/" INBOX
1840 S: A142 OK [READ-WRITE] SELECT completed
1844 C: A142 SELECT INBOX
1846 S: * OK [UIDVALIDITY 3857529045] UIDs valid
1847 S: * OK [UIDNEXT 4392] Predicted next UID
1848 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
1849 S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
1850 S: A142 OK [READ-WRITE] SELECT completed
1851 [...some time later...]
1852 C: A143 SELECT Drafts
1853 S: * OK [CLOSED] Previous mailbox is now closed
1855 S: * OK [UIDVALIDITY 9877410381] UIDs valid
1856 S: * OK [UIDNEXT 102] Predicted next UID
1857 S: * LIST () "/" Drafts
1858 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
1859 S: * OK [PERMANENTFLAGS (\Deleted \Seen \Answered
1860 \Flagged \Draft \*)] System flags and keywords allowed
1861 S: A143 OK [READ-WRITE] SELECT completed
1863 Note that IMAP4rev1-compliant servers can also send the untagged
1864 RECENT response that was deprecated in IMAP4rev2, e.g., "* 0 RECENT".
1865 Pure IMAP4rev2 clients are advised to ignore the untagged RECENT
1870 Arguments: mailbox name
1872 Responses: REQUIRED untagged responses: FLAGS, EXISTS, LIST
1873 REQUIRED OK untagged responses: PERMANENTFLAGS,
1874 UIDNEXT, UIDVALIDITY
1876 Result: OK - examine completed, now in selected state
1877 NO - examine failure, now in authenticated state: no
1878 such mailbox, can't access mailbox
1879 BAD - command unknown or arguments invalid
1881 The EXAMINE command is identical to SELECT and returns the same
1882 output; however, the selected mailbox is identified as read-only. No
1883 changes to the permanent state of the mailbox, including per-user
1884 state, are permitted.
1886 The text of the tagged OK response to the EXAMINE command MUST begin
1887 with the "[READ-ONLY]" response code.
1891 C: A932 EXAMINE blurdybloop
1893 S: * OK [UIDVALIDITY 3857529045] UIDs valid
1894 S: * OK [UIDNEXT 4392] Predicted next UID
1895 S: * LIST () "/" blurdybloop
1896 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
1897 S: * OK [PERMANENTFLAGS ()] No permanent flags permitted
1898 S: A932 OK [READ-ONLY] EXAMINE completed
1902 Arguments: mailbox name
1904 Responses: OPTIONAL untagged response: LIST
1906 Result: OK - create completed
1907 NO - create failure: can't create mailbox with that
1909 BAD - command unknown or arguments invalid
1911 The CREATE command creates a mailbox with the given name. An OK
1912 response is returned only if a new mailbox with that name has been
1915 return a tagged NO response. If a client attempts to create a UTF-8
1916 mailbox name that is not a valid Net-Unicode name, the server MUST
1917 reject the creation or convert the name to Net-Unicode prior to
1918 creating the mailbox. If the server decides to convert (normalize)
1919 the name, it SHOULD return an untagged LIST with an OLDNAME extended
1920 data item, with the OLDNAME value being the supplied mailbox name and
1921 the name parameter being the normalized mailbox name. (See
1922 Section 6.3.9.7 for more details.)
1924 Mailboxes created in one IMAP session MAY be announced to other IMAP
1925 sessions using an unsolicited LIST response. If the server
1926 automatically subscribes a mailbox when it is created, then the
1927 unsolicited LIST response for each affected subscribed mailbox name
1928 MUST include the \Subscribed attribute.
1931 character (as returned from the server by a LIST command), this is a
1932 declaration that the client intends to create mailbox names under
1933 this name in the hierarchy. Server implementations that do not
1935 the name created is without the trailing hierarchy delimiter.
1938 the name, the server SHOULD create any superior hierarchical names
1939 that are needed for the CREATE command to be successfully completed.
1940 In other words, an attempt to create "foo/bar/zap" on a server in
1941 which "/" is the hierarchy separator character SHOULD create foo/ and
1942 foo/bar/ if they do not already exist.
1944 If a new mailbox is created with the same name as a mailbox that was
1945 deleted, its unique identifiers MUST be greater than any unique
1946 identifiers used in the previous incarnation of the mailbox unless
1947 the new incarnation has a different unique identifier validity value.
1948 See the description of the UID command in Section 6.4.9 for more
1953 C: A003 CREATE owatagusiam/
1954 S: A003 OK CREATE completed
1955 C: A004 CREATE owatagusiam/blurdybloop
1956 S: A004 OK CREATE completed
1957 C: A005 CREATE NonNormalized
1958 S: * LIST () "/" "Normalized" ("OLDNAME" ("NonNormalized"))
1959 S: A005 OK CREATE completed
1961 (In the last example, imagine that "NonNormalized" is a non-NFC
1962 normalized Unicode mailbox name and that "Normalized" is its NFC
1963 normalized version.)
1965 | Note: The interpretation of this example depends on whether "/"
1966 | was returned as the hierarchy separator from LIST. If "/" is
1967 | the hierarchy separator, a new level of hierarchy named
1968 | "owatagusiam" with a member called "blurdybloop" is created.
1969 | Otherwise, two mailboxes at the same hierarchy level are
1974 Arguments: mailbox name
1976 Responses: OPTIONAL untagged response: LIST
1978 Result: OK - delete completed
1979 NO - delete failure: can't delete mailbox with that
1981 BAD - command unknown or arguments invalid
1983 The DELETE command permanently removes the mailbox with the given
1984 name. A tagged OK response is returned only if the mailbox has been
1985 deleted. It is an error to attempt to delete INBOX or a mailbox name
1986 that does not exist.
1988 The DELETE command MUST NOT remove inferior hierarchical names. For
1989 example, if a mailbox "foo" has an inferior "foo.bar" (assuming "."
1990 is the hierarchy delimiter character), removing "foo" MUST NOT remove
1991 "foo.bar". It is an error to attempt to delete a name that has
1992 inferior hierarchical names and also has the \Noselect mailbox name
1993 attribute (see the description of the LIST response (Section 7.3.1)
1996 It is permitted to delete a name that has inferior hierarchical names
1997 and does not have the \Noselect mailbox name attribute. If the
1998 server implementation does not permit deleting the name while
1999 inferior hierarchical names exist, then it SHOULD disallow the DELETE
2001 include the HASCHILDREN response code. Alternatively, the server MAY
2002 allow the DELETE command, but it sets the \Noselect mailbox name
2003 attribute for that name.
2005 If the server returns an OK response, all messages in that mailbox
2006 are removed by the DELETE command.
2008 The value of the highest-used unique identifier of the deleted
2009 mailbox MUST be preserved so that a new mailbox created with the same
2010 name will not reuse the identifiers of the former incarnation, unless
2011 the new incarnation has a different unique identifier validity value.
2012 See the description of the UID command in Section 6.4.9 for more
2015 If the server decides to convert (normalize) the mailbox name, it
2016 SHOULD return an untagged LIST with the "\NonExistent" attribute and
2017 OLDNAME extended data item, with the OLDNAME value being the supplied
2018 mailbox name and the name parameter being the normalized mailbox
2019 name. (See Section 6.3.9.7 for more details.)
2021 Mailboxes deleted in one IMAP session MAY be announced to other IMAP
2022 sessions using an unsolicited LIST response, containing the
2023 "\NonExistent" attribute.
2028 S: * LIST () "/" blurdybloop
2029 S: * LIST (\Noselect) "/" foo
2030 S: * LIST () "/" foo/bar
2031 S: A682 OK LIST completed
2032 C: A683 DELETE blurdybloop
2033 S: A683 OK DELETE completed
2035 S: A684 NO Name "foo" has inferior hierarchical names
2036 C: A685 DELETE foo/bar
2037 S: A685 OK DELETE Completed
2039 S: * LIST (\Noselect) "/" foo
2040 S: A686 OK LIST completed
2042 S: A687 OK DELETE Completed
2047 S: * LIST () "." blurdybloop
2048 S: * LIST () "." foo
2049 S: * LIST () "." foo.bar
2050 S: A82 OK LIST completed
2051 C: A83 DELETE blurdybloop
2052 S: A83 OK DELETE completed
2054 S: A84 OK DELETE Completed
2056 S: * LIST () "." foo.bar
2057 S: A85 OK LIST completed
2059 S: * LIST (\Noselect) "." foo
2060 S: A86 OK LIST completed
2064 Arguments: existing mailbox name
2068 Responses: OPTIONAL untagged response: LIST
2070 Result: OK - rename completed
2071 NO - rename failure: can't rename mailbox with that
2072 name, can't rename to mailbox with that name
2073 BAD - command unknown or arguments invalid
2075 The RENAME command changes the name of a mailbox. A tagged OK
2076 response is returned only if the mailbox has been renamed. It is an
2077 error to attempt to rename from a mailbox name that does not exist or
2078 to a mailbox name that already exists. Any error in renaming will
2079 return a tagged NO response.
2081 If the name has inferior hierarchical names, then the inferior
2082 hierarchical names MUST also be renamed. For example, a rename of
2083 "foo" to "zap" will rename "foo/bar" (assuming "/" is the hierarchy
2084 delimiter character) to "zap/bar".
2086 If the server's hierarchy separator character appears in the new
2087 mailbox name, the server SHOULD create any superior hierarchical
2088 names that are needed for the RENAME command to complete
2089 successfully. In other words, an attempt to rename "foo/bar/zap" to
2090 "baz/rag/zowie" on a server in which "/" is the hierarchy separator
2091 character in the corresponding namespace SHOULD create "baz/" and
2092 "baz/rag/" if they do not already exist.
2094 The value of the highest-used unique identifier of the old mailbox
2095 name MUST be preserved so that a new mailbox created with the same
2096 name will not reuse the identifiers of the former incarnation, unless
2097 the new incarnation has a different unique identifier validity value.
2098 See the description of the UID command in Section 6.4.9 for more
2102 response, and it has special behavior: It moves all messages in INBOX
2103 to a new mailbox with the given name, leaving INBOX empty. If the
2104 server implementation supports inferior hierarchical names of INBOX,
2105 these are unaffected by a rename of INBOX. (Note that some servers
2106 disallow renaming INBOX by returning a tagged NO response, so clients
2107 need to be able to handle the failure of such RENAME commands.)
2109 If the server allows creation of mailboxes with names that are not
2110 valid Net-Unicode names, the server normalizes both the existing
2111 mailbox name parameter and the new mailbox name parameter. If the
2112 normalized version of any of these 2 parameters differs from the
2113 corresponding supplied version, the server SHOULD return an untagged
2114 LIST response with an OLDNAME extended data item, with the OLDNAME
2115 value being the supplied existing mailbox name and the name parameter
2116 being the normalized new mailbox name (see Section 6.3.9.7). This
2117 would allow the client to correlate the supplied name with the
2120 Mailboxes renamed in one IMAP session MAY be announced to other IMAP
2121 sessions using an unsolicited LIST response with an OLDNAME extended
2124 In both of the above cases, if the server automatically subscribes a
2125 mailbox when it is renamed, then the unsolicited LIST response for
2126 each affected subscribed mailbox name MUST include the \Subscribed
2127 attribute. No unsolicited LIST responses need to be sent for child
2128 mailboxes. When INBOX is successfully renamed, it is assumed that a
2129 new INBOX is created. No unsolicited LIST responses need to be sent
2130 for INBOX in this case.
2135 S: * LIST () "/" blurdybloop
2136 S: * LIST (\Noselect) "/" foo
2137 S: * LIST () "/" foo/bar
2138 S: A682 OK LIST completed
2139 C: A683 RENAME blurdybloop sarasoop
2140 S: A683 OK RENAME completed
2141 C: A684 RENAME foo zowie
2142 S: A684 OK RENAME Completed
2144 S: * LIST () "/" sarasoop
2145 S: * LIST (\Noselect) "/" zowie
2146 S: * LIST () "/" zowie/bar
2147 S: A685 OK LIST completed
2150 S: * LIST () "." INBOX
2151 S: * LIST () "." INBOX.bar
2152 S: Z432 OK LIST completed
2153 C: Z433 RENAME INBOX old-mail
2154 S: Z433 OK RENAME completed
2156 S: * LIST () "." INBOX
2157 S: * LIST () "." INBOX.bar
2158 S: * LIST () "." old-mail
2159 S: Z434 OK LIST completed
2161 Note that renaming a mailbox doesn't update subscription information
2162 on the original name. To keep subscription information in sync, the
2163 following sequence of commands can be used:
2167 C: 1003 UNSUBSCRIBE X
2169 Note that the above sequence of commands doesn't account for updating
2170 the subscription for any child mailboxes of mailbox X.
2176 Responses: no specific responses for this command
2178 Result: OK - subscribe completed
2179 NO - subscribe failure: can't subscribe to that name
2180 BAD - command unknown or arguments invalid
2182 The SUBSCRIBE command adds the specified mailbox name to the server's
2183 set of "active" or "subscribed" mailboxes as returned by the LIST
2184 (SUBSCRIBED) command. This command returns a tagged OK response if
2185 the subscription is successful or if the mailbox is already
2188 A server MAY validate the mailbox argument to SUBSCRIBE to verify
2189 that it exists. However, it SHOULD NOT unilaterally remove an
2190 existing mailbox name from the subscription list even if a mailbox by
2191 that name no longer exists.
2193 | Note: This requirement is because a server site can choose to
2194 | routinely remove a mailbox with a well-known name (e.g.,
2195 | "system-alerts") after its contents expire, with the intention
2196 | of recreating it when new contents are appropriate.
2200 C: A002 SUBSCRIBE #news.comp.mail.mime
2201 S: A002 OK SUBSCRIBE completed
2205 Arguments: mailbox name
2207 Responses: no specific responses for this command
2209 Result: OK - unsubscribe completed
2210 NO - unsubscribe failure: can't unsubscribe that name
2211 BAD - command unknown or arguments invalid
2213 The UNSUBSCRIBE command removes the specified mailbox name from the
2214 server's set of "active" or "subscribed" mailboxes as returned by the
2216 if the unsubscription is successful or if the mailbox is not
2221 C: A002 UNSUBSCRIBE #news.comp.mail.mime
2222 S: A002 OK UNSUBSCRIBE completed
2228 mailbox name with possible wildcards
2230 Arguments (extended):
2231 selection options (OPTIONAL)
2234 return options (OPTIONAL)
2236 Responses: untagged responses: LIST
2238 Result: OK - list completed
2239 NO - list failure: can't list that reference or
2241 BAD - command unknown or arguments invalid
2243 The LIST command returns a subset of mailbox names from the complete
2244 set of all mailbox names available to the client. Zero or more
2245 untagged LIST responses are returned, containing the name attributes,
2246 hierarchy delimiter, name, and possible extension information; see
2247 the description of the LIST response (Section 7.3.1) for more detail.
2249 The LIST command SHOULD return its data quickly, without undue delay.
2250 For example, it should not go to excess trouble to calculate the
2251 \Marked or \Unmarked status or perform other processing; if each name
2252 requires 1 second of processing, then a list of 1200 names would take
2255 The extended LIST command, originally introduced in [RFC5258],
2256 provides capabilities beyond that of the original IMAP LIST command.
2257 The extended syntax is being used if one or more of the following
2260 1. the first word after the command name begins with a parenthesis
2261 ("LIST selection options");
2263 2. the second word after the command name begins with a parenthesis;
2266 3. the LIST command has more than 2 parameters ("LIST return
2269 An empty ("" string) reference name argument indicates that the
2270 mailbox name is interpreted as by SELECT. The returned mailbox names
2271 MUST match the supplied mailbox name pattern(s). A non-empty
2272 reference name argument is the name of a mailbox or a level of
2273 mailbox hierarchy, and it indicates the context in which the mailbox
2274 name is interpreted. Clients SHOULD use the empty reference
2278 is a special request to return the hierarchy delimiter and the root
2279 name of the name given in the reference. The value returned as the
2280 root MAY be the empty string if the reference is non-rooted or is an
2281 empty string. In all cases, a hierarchy delimiter (or NIL if there
2282 is no hierarchy) is returned. This permits a client to get the
2283 hierarchy delimiter (or find out that the mailbox names are flat)
2284 even when no mailboxes by that name currently exist.
2287 strings are ignored. There is no special meaning for empty mailbox
2288 names when the extended syntax is used.
2290 The reference and mailbox name arguments are interpreted into a
2291 canonical form that represents an unambiguous left-to-right
2292 hierarchy. The returned mailbox names will be in the interpreted
2293 form, which we call a "canonical LIST pattern": the canonical pattern
2294 constructed internally by the server from the reference and mailbox
2297 Note: The interpretation of the reference argument is
2298 implementation defined. It depends on whether the server
2299 implementation has a concept of the "current working directory"
2300 and leading "break out characters", which override the current
2303 For example, on a server that exports a UNIX or NT file system,
2304 the reference argument contains the current working directory, and
2305 the mailbox name argument contains the name as interpreted in the
2306 current working directory.
2308 If a server implementation has no concept of break out characters,
2309 the canonical form is normally the reference name appended with
2310 the mailbox name. Note that if the server implements the
2311 namespace convention (Section 5.1.2.1), "#" is a break out
2312 character and must be treated as such.
2314 If the reference argument is not a level of mailbox hierarchy
2315 (that is, it is a \NoInferiors name), and/or the reference
2316 argument does not end with the hierarchy delimiter, it is
2317 interpreted as implementation dependent. For example, a reference
2318 of "foo/bar" and mailbox name of "rag/baz" could be interpreted as
2319 "foo/bar/rag/baz", "foo/barrag/baz", or "foo/rag/baz". A client
2320 SHOULD NOT use such a reference argument except at the explicit
2321 request of the user. A hierarchical browser MUST NOT make any
2322 assumptions about server interpretation of the reference unless
2323 the reference is a level of mailbox hierarchy AND ends with the
2324 hierarchy delimiter.
2326 Any part of the reference argument that is included in the
2327 interpreted form SHOULD prefix the interpreted form. It SHOULD also
2328 be in the same form as the reference name argument. This rule
2329 permits the client to determine if the returned mailbox name is in
2330 the context of the reference argument or if something about the
2331 mailbox argument overrode the reference argument. Without this rule,
2332 the client would have to have knowledge of the server's naming
2333 semantics including what characters are "breakouts" that override a
2336 Here are some examples of how references and mailbox names might be
2337 interpreted on a UNIX-based server:
2339 +==============+==============+===================+
2340 | Reference | Mailbox Name | Interpretation |
2341 +==============+==============+===================+
2342 | ~smith/Mail/ | foo.* | ~smith/Mail/foo.* |
2343 +--------------+--------------+-------------------+
2344 | archive/ | % | archive/% |
2345 +--------------+--------------+-------------------+
2346 | #news. | comp.mail.* | #news.comp.mail.* |
2347 +--------------+--------------+-------------------+
2348 | ~smith/Mail/ | /usr/doc/foo | /usr/doc/foo |
2349 +--------------+--------------+-------------------+
2350 | archive/ | ~fred/Mail/* | ~fred/Mail/* |
2351 +--------------+--------------+-------------------+
2355 The first three examples above demonstrate interpretations in the
2356 context of the reference argument. Note that "~smith/Mail" SHOULD
2357 NOT be transformed into something like "/u2/users/smith/Mail", or it
2358 would be impossible for the client to determine that the
2359 interpretation was in the context of the reference.
2362 at this position. The character "%" is similar to "*", but it does
2363 not match a hierarchy delimiter. If the "%" wildcard is the last
2364 character of a mailbox name argument, matching levels of hierarchy
2365 are also returned. If these levels of hierarchy are not also
2366 selectable mailboxes, they are returned with the \Noselect mailbox
2367 name attribute (see the description of the LIST response
2368 (Section 7.3.1) for more details).
2370 Any syntactically valid pattern that is not accepted by a server for
2371 any reason MUST be silently ignored, i.e., it results in no LIST
2372 responses, and the LIST command still returns a tagged OK response.
2374 Selection options tell the server to limit the mailbox names that are
2375 selected by the LIST operation. If selection options are used, the
2376 mailboxes returned are those that match both the list of canonical
2377 LIST patterns and the selection options. Unless a particular
2378 selection option provides special rules, the selection options are
2379 cumulative: a mailbox that matches the mailbox patterns is selected
2380 only if it also matches all of the selection options. (An example of
2381 a selection option with special rules is the RECURSIVEMATCH option.)
2383 Return options control what information is returned for each matched
2384 mailbox. Return options MUST NOT cause the server to report
2385 information about additional mailbox names other than those that
2386 match the canonical LIST patterns and selection options. If no
2387 return options are specified, the client is only expecting
2388 information about mailbox attributes. The server MAY return other
2389 information about the matched mailboxes, and clients MUST be able to
2390 handle that situation.
2392 Initial selection options and return options are defined in the
2393 following subsections, and new ones will also be defined in
2394 extensions. Initial options defined in this document MUST be
2395 supported. Each non-initial option will be enabled by a capability
2396 string (one capability may enable multiple options), and a client
2397 MUST NOT send an option for which the server has not advertised
2400 once; however, if the client does this, the server MUST act as if it
2401 received the option only once. The order in which options are
2402 specified by the client is not significant.
2404 In general, each selection option except RECURSIVEMATCH will have a
2405 corresponding return option with the same name. The REMOTE selection
2406 option is an anomaly in this regard and does not have a corresponding
2407 return option. That is because it expands, rather than restricts,
2408 the set of mailboxes that are returned. Future extensions to this
2409 specification should keep this parallelism in mind and define a pair
2410 of corresponding selection and return options.
2412 Server implementations are permitted to "hide" otherwise accessible
2413 mailboxes from the wildcard characters, by preventing certain
2414 characters or names from matching a wildcard in certain situations.
2415 For example, a UNIX-based server might restrict the interpretation of
2416 "*" so that an initial "/" character does not match.
2418 The special name INBOX is included in the output from LIST, if INBOX
2419 is supported by this server for this user and if the uppercase string
2420 "INBOX" matches the interpreted reference and mailbox name arguments
2421 with wildcards as described above. The criteria for omitting INBOX
2422 is whether SELECT INBOX will return a failure; it is not relevant
2423 whether the user's real INBOX resides on this or some other server.
24256.3.9.1. LIST Selection Options
2427 The selection options defined in this specification are as follows:
2430 Causes the LIST command to list subscribed names rather than the
2431 existing mailboxes. This will often be a subset of the actual
2432 mailboxes. It's also possible for this list to contain the names
2433 of mailboxes that don't exist. In any case, the list MUST include
2434 exactly those mailbox names that match the canonical list pattern
2435 and are subscribed to.
2437 This option defines a mailbox attribute, "\Subscribed", that
2438 indicates that a mailbox name is subscribed to. The "\Subscribed"
2439 attribute MUST be supported and MUST be accurately computed when
2440 the SUBSCRIBED selection option is specified.
2442 Note that the SUBSCRIBED selection option implies the SUBSCRIBED
2443 return option (see below).
2446 Causes the LIST command to show remote mailboxes as well as local
2447 ones, as described in [RFC2193]. This option is intended to
2448 replace the RLIST command and, in conjunction with the SUBSCRIBED
2449 selection option, the RLSUB command. Servers that don't support
2450 the concept of remote mailboxes can ignore this option.
2452 This option defines a mailbox attribute, "\Remote", that indicates
2453 that a mailbox is a remote mailbox. The "\Remote" attribute MUST
2454 be accurately computed when the REMOTE option is specified.
2456 The REMOTE selection option has no interaction with other options.
2457 Its effect is to tell the server to apply the other options, if
2458 any, to remote mailboxes, in addition to local ones. In
2459 particular, it has no interaction with RECURSIVEMATCH (see below).
2460 A request for (REMOTE RECURSIVEMATCH) is invalid, because a
2461 request for (RECURSIVEMATCH) is also invalid. A request for
2462 (REMOTE RECURSIVEMATCH SUBSCRIBED) is asking for all subscribed
2463 mailboxes, both local and remote.
2466 Forces the server to return information about parent mailboxes
2467 that don't match other selection options but have some
2468 submailboxes that do. Information about children is returned in
2469 the CHILDINFO extended data item, as described in Section 6.3.9.6.
2471 Note 1: In order for a parent mailbox to be returned, it still
2472 has to match the canonical LIST pattern.
2474 Note 2: When returning the CHILDINFO extended data item, it
2475 doesn't matter whether or not the submailbox matches the
2476 canonical LIST pattern. See also Example 9 in Section 6.3.9.8.
2478 The RECURSIVEMATCH option MUST NOT occur as the only selection
2479 option (or only with REMOTE), as it only makes sense when other
2480 selection options are also used. The server MUST return a BAD
2481 tagged response in such case.
2483 Note that even if the RECURSIVEMATCH option is specified, the
2484 client MUST still be able to handle cases when a CHILDINFO
2485 extended data item is returned and there are no submailboxes that
2486 meet the selection criteria of the subsequent LIST command, as
2487 they can be deleted/renamed after the LIST response was sent but
2488 before the client had a chance to access them.
24906.3.9.2. LIST Return Options
2492 The return options defined in this specification are as follows:
2495 Causes the LIST command to return subscription state for all
2496 matching mailbox names. The "\Subscribed" attribute MUST be
2497 supported and MUST be accurately computed when the SUBSCRIBED
2498 return option is specified. Furthermore, all other mailbox
2499 attributes MUST be accurately computed (this differs from the
2500 behavior of the obsolete LSUB command from [RFC3501]). Note that
2501 the above requirements don't override the requirement for the LIST
2502 command to return results quickly (see Section 6.3.9), i.e.,
2503 server implementations need to compute results quickly and
2504 accurately. For example, server implementors might need to create
2505 quick access indices.
2508 Requests mailbox child information as originally proposed in
2509 [RFC3348]. See Section 6.3.9.5, below, for details.
2512 Requests STATUS response for each matching mailbox.
2514 This option takes STATUS data items as parameters. For each
2515 selectable mailbox matching the list pattern and selection
2516 options, the server MUST return an untagged LIST response followed
2517 by an untagged STATUS response containing the information
2518 requested in the STATUS return option, except for some cases
2521 If an attempted STATUS for a listed mailbox fails because the
2522 mailbox can't be selected (e.g., if the "l" Access Control List
2523 (ACL) right [RFC4314] is granted to the mailbox and the "r" right
2524 is not granted, or is due to a race condition between LIST and
2525 STATUS changing the mailbox to \NoSelect), the STATUS response
2526 MUST NOT be returned, and the LIST response MUST include the
2527 \NoSelect attribute. This means the server may have to buffer the
2528 LIST reply until it has successfully looked up the necessary
2531 If the server runs into unexpected problems while trying to look
2532 up the STATUS information, it MAY drop the corresponding STATUS
2533 reply. In such a situation, the LIST command would still return a
2536 See the note in the discussion of the STATUS command in
2537 Section 6.3.11 for information about obtaining status on the
2538 currently selected mailbox.
25406.3.9.3. General Principles for Returning LIST Responses
2542 This section outlines several principles that can be used by server
2543 implementations of this document to decide whether a LIST response
2544 should be returned, as well as how many responses and what kind of
2545 information they may contain.
2547 1. At most, one LIST response should be returned for each mailbox
2548 name that matches the canonical LIST pattern. Server
2549 implementors must not assume that clients will be able to
2550 assemble mailbox attributes and other information returned in
2551 multiple LIST responses.
2553 2. There are only two reasons for including a matching mailbox name
2554 in the responses to the LIST command (note that the server is
2555 allowed to return unsolicited responses at any time, and such
2556 responses are not governed by this rule):
2558 A. The mailbox name also satisfies the selection criteria.
2560 B. The mailbox name doesn't satisfy the selection criteria, but
2561 it has at least one descendant mailbox name that satisfies
2562 the selection criteria and that doesn't match the canonical
2565 For more information on this case, see the CHILDINFO extended
2566 data item described in Section 6.3.9.6. Note that the
2567 CHILDINFO extended data item can only be returned when the
2568 RECURSIVEMATCH selection option is specified.
2570 3. Attributes returned in the same LIST response are treated
2571 additively. For example, the following response
2573 S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
2575 means that the "Fruit/Peach" mailbox doesn't exist, but it is
25786.3.9.4. Additional LIST-Related Requirements on Clients
2580 All clients MUST treat a LIST attribute with a stronger meaning as
2581 implying any attribute that can be inferred from it. (See
2582 Section 7.3.1 for the list of currently defined attributes.) For
2583 example, the client must treat the presence of the \NoInferiors
2584 attribute as if the \HasNoChildren attribute was also sent by the
2587 The following table summarizes inference rules.
2589 +====================+===================+
2590 | returned attribute | implied attribute |
2591 +====================+===================+
2592 | \NoInferiors | \HasNoChildren |
2593 +--------------------+-------------------+
2594 | \NonExistent | \NoSelect |
2595 +--------------------+-------------------+
25996.3.9.5. The CHILDREN Return Option
2601 The CHILDREN return option is simply an indication that the client
2602 wants information about whether or not mailboxes contain child
2603 mailboxes; a server MAY provide it even if the option is not
2606 Many IMAP clients present the user with a hierarchical view of the
2607 mailboxes that a user has access to. Rather than initially
2608 presenting the entire mailbox hierarchy to the user, it is often
2609 preferable to show the user a collapsed outline list of the mailbox
2610 hierarchy (particularly if there is a large number of mailboxes).
2611 The user can then expand the collapsed outline hierarchy as needed.
2612 It is common to include a visual clue (such as a ''+'') within the
2613 collapsed hierarchy to indicate that there are child mailboxes under
2614 a particular mailbox. When the visual clue is clicked, the hierarchy
2615 list is expanded to show the child mailboxes. The CHILDREN return
2616 option provides a mechanism for a client to efficiently determine
2617 whether a particular mailbox has children, without issuing a LIST ""
2618 * or a LIST "" % for each mailbox name. The CHILDREN return option
2619 defines two new attributes that MUST be returned within a LIST
2620 response: \HasChildren and \HasNoChildren. Although these attributes
2621 MAY be returned in response to any LIST command, the CHILDREN return
2622 option is provided to indicate that the client particularly wants
2623 this information. If the CHILDREN return option is present, the
2624 server MUST return these attributes even if their computation is
2628 The presence of this attribute indicates that the mailbox has
2629 child mailboxes. A server SHOULD NOT set this attribute if
2630 there are child mailboxes and the user does not have permission
2631 to access any of them. In this case, \HasNoChildren SHOULD be
2632 used. In many cases, however, a server may not be able to
2633 efficiently compute whether a user has access to any child
2634 mailbox. Note that even though the \HasChildren attribute for a
2635 mailbox must be correct at the time of processing the mailbox, a
2636 client must be prepared to deal with a situation when a mailbox
2637 is marked with the \HasChildren attribute, but no child mailbox
2638 appears in the response to the LIST command. This might happen,
2639 for example, due to child mailboxes being deleted or made
2640 inaccessible to the user (using access control) by another
2641 client before the server is able to list them.
2644 The presence of this attribute indicates that the mailbox has NO
2645 child mailboxes that are accessible to the currently
2648 It is an error for the server to return both a \HasChildren and a
2649 \HasNoChildren attribute in the same LIST response.
2651 Note: the \HasNoChildren attribute should not be confused with the
2652 \NoInferiors attribute, which indicates that no child mailboxes exist
2653 now and none can be created in the future.
26556.3.9.6. CHILDINFO Extended Data Item
2657 The CHILDINFO extended data item MUST NOT be returned unless the
2658 client has specified the RECURSIVEMATCH selection option.
2660 The CHILDINFO extended data item in a LIST response describes the
2661 selection criteria that has caused it to be returned and indicates
2662 that the mailbox has at least one descendant mailbox that matches the
2665 Note: Some servers allow for mailboxes to exist without requiring
2666 their parent to exist. For example, the mailbox "Customers/ABC" can
2667 exist while the mailbox "Customers" does not. As the CHILDINFO
2668 extended data item is not allowed if the RECURSIVEMATCH selection
2669 option is not specified, such servers SHOULD use the "\NonExistent
2670 \HasChildren" attribute pair to signal to the client that there is a
2671 descendant mailbox that matches the selection criteria. See Example
2672 11 in Section 6.3.9.8.
2674 The returned selection criteria allows the client to distinguish a
2675 solicited response from an unsolicited one, as well as to distinguish
2676 among solicited responses caused by multiple pipelined LIST commands
2677 that specify different criteria.
2679 Servers SHOULD only return a non-matching mailbox name along with
2680 CHILDINFO if at least one matching child is not also being returned.
2681 That is, servers SHOULD suppress redundant CHILDINFO responses.
2683 Examples 8 and 10 in Section 6.3.9.8 demonstrate the difference
2684 between the present CHILDINFO extended data item and the
2685 "\HasChildren" attribute.
2687 The following table summarizes interaction between the "\NonExistent"
2688 attribute and CHILDINFO (the first column indicates whether the
2689 parent mailbox exists):
2691 +========+===========+====================+=====================+
2692 | Exists | Meets the | Has a child that | Returned IMAP4rev2/ |
2693 | | selection | meets the | LIST-EXTENDED |
2694 | | criteria | selection criteria | attributes and |
2696 +========+===========+====================+=====================+
2697 | no | no | no | no LIST response |
2699 +--------+-----------+--------------------+---------------------+
2700 | yes | no | no | no LIST response |
2702 +--------+-----------+--------------------+---------------------+
2703 | no | yes | no | (\NonExistent |
2705 +--------+-----------+--------------------+---------------------+
2706 | yes | yes | no | (<attr>) |
2707 +--------+-----------+--------------------+---------------------+
2708 | no | no | yes | (\NonExistent) + |
2710 +--------+-----------+--------------------+---------------------+
2711 | yes | no | yes | () + CHILDINFO |
2712 +--------+-----------+--------------------+---------------------+
2713 | no | yes | yes | (\NonExistent |
2714 | | | | <attr>) + CHILDINFO |
2715 +--------+-----------+--------------------+---------------------+
2716 | yes | yes | yes | (<attr>) + |
2718 +--------+-----------+--------------------+---------------------+
2722 where <attr> is one or more attributes that correspond to the
2723 selection criteria; for example, for the SUBSCRIBED option, the
2724 <attr> is \Subscribed.
2728 The OLDNAME extended data item is included when a mailbox name is
2729 created (with the CREATE command), renamed (with the RENAME command),
2730 or deleted (with the DELETE command). (When a mailbox is deleted,
2731 the "\NonExistent" attribute is also included.) IMAP extensions can
2732 specify other conditions when the OLDNAME extended data item should
2735 If the server allows denormalized mailbox names (see Section 5.1) in
2736 SELECT/EXAMINE, CREATE, RENAME, or DELETE, it SHOULD return an
2737 unsolicited LIST response that includes the OLDNAME extended data
2738 item, whenever the supplied mailbox name differs from the resulting
2739 normalized mailbox name. From the client point of view, this is
2740 indistinguishable from another user renaming or deleting the mailbox,
2741 as specified in the previous paragraph.
2743 A deleted mailbox can be announced as follows:
2745 S: * LIST (\NonExistent) "." "INBOX.DeletedMailbox"
2747 Example of a renamed mailbox:
2749 S: * LIST () "/" "NewMailbox" ("OLDNAME" ("OldMailbox"))
27516.3.9.8. LIST Command Examples
2753 This example shows some uses of the basic LIST command:
2758 S: * LIST (\Noselect) "/" ""
2759 S: A101 OK LIST Completed
2760 C: A102 LIST #news.comp.mail.misc ""
2761 S: * LIST (\Noselect) "." #news.
2762 S: A102 OK LIST Completed
2763 C: A103 LIST /usr/staff/jones ""
2764 S: * LIST (\Noselect) "/" /
2765 S: A103 OK LIST Completed
2766 C: A202 LIST ~/Mail/ %
2767 S: * LIST (\Noselect) "/" ~/Mail/foo
2768 S: * LIST () "/" ~/Mail/meetings
2769 S: A202 OK LIST completed
2773 1: The first example shows the complete local hierarchy that will
2774 be used for the other examples.
2777 S: * LIST (\Marked \NoInferiors) "/" "inbox"
2778 S: * LIST () "/" "Fruit"
2779 S: * LIST () "/" "Fruit/Apple"
2780 S: * LIST () "/" "Fruit/Banana"
2781 S: * LIST () "/" "Tofu"
2782 S: * LIST () "/" "Vegetable"
2783 S: * LIST () "/" "Vegetable/Broccoli"
2784 S: * LIST () "/" "Vegetable/Corn"
2787 2: In the next example, we will see the subscribed mailboxes. This
2788 is similar to, but not equivalent with, the now deprecated <LSUB
2789 "" "*"> (see [RFC3501] for more details on the LSUB command).
2790 Note that the mailbox called "Fruit/Peach" is subscribed to, but
2791 it does not actually exist (perhaps it was deleted while still
2792 subscribed). The "Fruit" mailbox is not subscribed to, but it
2793 has two subscribed children. The "Vegetable" mailbox is
2794 subscribed and has two children; one of them is subscribed as
2797 C: A02 LIST (SUBSCRIBED) "" "*"
2798 S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
2799 S: * LIST (\Subscribed) "/" "Fruit/Banana"
2800 S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
2801 S: * LIST (\Subscribed) "/" "Vegetable"
2802 S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
2805 3: The next example shows the use of the CHILDREN option. The
2806 client, without having to list the second level of hierarchy,
2807 now knows which of the top-level mailboxes have submailboxes
2808 (children) and which do not. Note that it's not necessary for
2809 the server to return the \HasNoChildren attribute for the inbox,
2810 because the \NoInferiors attribute already implies that and has
2813 C: A03 LIST () "" "%" RETURN (CHILDREN)
2814 S: * LIST (\Marked \NoInferiors) "/" "inbox"
2815 S: * LIST (\HasChildren) "/" "Fruit"
2816 S: * LIST (\HasNoChildren) "/" "Tofu"
2817 S: * LIST (\HasChildren) "/" "Vegetable"
2820 4: In this example, we see more mailboxes that reside on another
2821 server. This is similar to the command <RLIST "" "%">.
2823 C: A04 LIST (REMOTE) "" "%" RETURN (CHILDREN)
2824 S: * LIST (\Marked \NoInferiors) "/" "inbox"
2825 S: * LIST (\HasChildren) "/" "Fruit"
2826 S: * LIST (\HasNoChildren) "/" "Tofu"
2827 S: * LIST (\HasChildren) "/" "Vegetable"
2828 S: * LIST (\Remote \HasNoChildren) "/" "Bread"
2829 S: * LIST (\HasChildren \Remote) "/" "Meat"
2832 5: The following example also requests the server to include
2833 mailboxes that reside on another server. The server returns
2834 information about all mailboxes that are subscribed. This is
2835 similar to the command <RLSUB "" "*"> (see [RFC2193] for more
2836 details on RLSUB). We also see the use of two selection
2839 C: A05 LIST (REMOTE SUBSCRIBED) "" "*"
2840 S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
2841 S: * LIST (\Subscribed) "/" "Fruit/Banana"
2842 S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
2843 S: * LIST (\Subscribed) "/" "Vegetable"
2844 S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
2845 S: * LIST (\Remote \Subscribed) "/" "Bread"
2848 6: The following example requests the server to include mailboxes
2849 that reside on another server. The server is asked to return
2850 subscription information for all returned mailboxes. This is
2851 different from the example above.
2853 Note that the output of this command is not a superset of the
2854 output in the previous example, as it doesn't include a LIST
2855 response for the non-existent "Fruit/Peach".
2857 C: A06 LIST (REMOTE) "" "*" RETURN (SUBSCRIBED)
2858 S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
2859 S: * LIST () "/" "Fruit"
2860 S: * LIST () "/" "Fruit/Apple"
2861 S: * LIST (\Subscribed) "/" "Fruit/Banana"
2862 S: * LIST () "/" "Tofu"
2863 S: * LIST (\Subscribed) "/" "Vegetable"
2864 S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
2865 S: * LIST () "/" "Vegetable/Corn"
2866 S: * LIST (\Remote \Subscribed) "/" "Bread"
2867 S: * LIST (\Remote) "/" "Meat"
2870 7: The following example demonstrates the difference between the
2871 \HasChildren attribute and the CHILDINFO extended data item.
2873 Let's assume there is the following hierarchy:
2876 S: * LIST (\Marked \NoInferiors) "/" "inbox"
2877 S: * LIST () "/" "Foo"
2878 S: * LIST () "/" "Foo/Bar"
2879 S: * LIST () "/" "Foo/Baz"
2880 S: * LIST () "/" "Moo"
2883 If the client asks RETURN (CHILDREN), it will get this:
2885 C: CA3 LIST "" "%" RETURN (CHILDREN)
2886 S: * LIST (\Marked \NoInferiors) "/" "inbox"
2887 S: * LIST (\HasChildren) "/" "Foo"
2888 S: * LIST (\HasNoChildren) "/" "Moo"
2891 A) Let's also assume that the mailbox "Foo/Baz" is the only
2892 subscribed mailbox. Then we get this result:
2894 C: C02 LIST (SUBSCRIBED) "" "*"
2895 S: * LIST (\Subscribed) "/" "Foo/Baz"
2898 Now, if the client issues <LIST (SUBSCRIBED) "" "%">, the
2899 server will return no mailboxes (as the mailboxes "Moo",
2900 "Foo", and "Inbox" are NOT subscribed). However, if the
2903 C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
2904 S: * LIST () "/" "Foo" ("CHILDINFO" ("SUBSCRIBED"))
2907 (that is, the mailbox "Foo" is not subscribed, but it has a
2908 child that is), then A1 or A2 occurs.
2910 A1) If the mailbox "Foo" had also been subscribed, the last
2911 command would return this:
2913 C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
2914 S: * LIST (\Subscribed) "/" "Foo" ("CHILDINFO"
2920 C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
2921 S: * LIST (\Subscribed \HasChildren) "/" "Foo"
2922 ("CHILDINFO" ("SUBSCRIBED"))
2925 A2) If we assume instead that the mailbox "Foo" is not part
2926 of the original hierarchy and is not subscribed, the
2927 last command will give this result:
2929 C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
2930 S: * LIST (\NonExistent) "/" "Foo" ("CHILDINFO"
2934 B) Now, let's assume that no mailbox is subscribed. In this
2935 case, the command <LIST (SUBSCRIBED RECURSIVEMATCH) "" "%">
2936 will return no responses, as there are no subscribed
2937 children (even though "Foo" has children).
2939 C) And finally, suppose that only the mailboxes "Foo" and "Moo"
2940 are subscribed. In that case, we see this result:
2942 C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" RETURN
2944 S: * LIST (\HasChildren \Subscribed) "/" "Foo"
2945 S: * LIST (\HasNoChildren \Subscribed) "/" "Moo"
2948 (which means that the mailbox "Foo" has children, but none
2949 of them is subscribed).
2951 8: The following example demonstrates that the CHILDINFO extended
2952 data item is returned whether or not child mailboxes match the
2953 canonical LIST pattern.
2955 Let's assume there is the following hierarchy:
2958 S: * LIST (\Marked \NoInferiors) "/" "inbox"
2959 S: * LIST () "/" "foo2"
2960 S: * LIST () "/" "foo2/bar1"
2961 S: * LIST () "/" "foo2/bar2"
2962 S: * LIST () "/" "baz2"
2963 S: * LIST () "/" "baz2/bar2"
2964 S: * LIST () "/" "baz2/bar22"
2965 S: * LIST () "/" "baz2/bar222"
2966 S: * LIST () "/" "eps2"
2967 S: * LIST () "/" "eps2/mamba"
2968 S: * LIST () "/" "qux2/bar2"
2971 And that the following mailboxes are subscribed:
2973 C: D02 LIST (SUBSCRIBED) "" "*"
2974 S: * LIST (\Subscribed) "/" "foo2/bar1"
2975 S: * LIST (\Subscribed) "/" "foo2/bar2"
2976 S: * LIST (\Subscribed) "/" "baz2/bar2"
2977 S: * LIST (\Subscribed) "/" "baz2/bar22"
2978 S: * LIST (\Subscribed) "/" "baz2/bar222"
2979 S: * LIST (\Subscribed) "/" "eps2"
2980 S: * LIST (\Subscribed) "/" "eps2/mamba"
2981 S: * LIST (\Subscribed) "/" "qux2/bar2"
2984 The client issues the following command first:
2986 C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*2"
2987 S: * LIST () "/" "foo2" ("CHILDINFO" ("SUBSCRIBED"))
2988 S: * LIST (\Subscribed) "/" "foo2/bar2"
2989 S: * LIST (\Subscribed) "/" "baz2/bar2"
2990 S: * LIST (\Subscribed) "/" "baz2/bar22"
2991 S: * LIST (\Subscribed) "/" "baz2/bar222"
2992 S: * LIST (\Subscribed) "/" "eps2" ("CHILDINFO" ("SUBSCRIBED"))
2993 S: * LIST (\Subscribed) "/" "qux2/bar2"
2996 and the server may also include the following (but this would
2997 violate a restriction in Section 6.3.9.6, because CHILDINFO is
3000 S: * LIST () "/" "baz2" ("CHILDINFO" ("SUBSCRIBED"))
3001 S: * LIST (\NonExistent) "/" "qux2" ("CHILDINFO" ("SUBSCRIBED"))
3003 The CHILDINFO extended data item is returned for mailboxes
3004 "foo2", "baz2", and "eps2" because all of them have subscribed
3005 children, even though for the mailbox "foo2", only one of the
3006 two subscribed children matches the pattern; for the mailbox
3007 "baz2", all of the subscribed children match the pattern; and
3008 for the mailbox "eps2", none of the subscribed children match
3011 Note that if the client issues the following:
3013 C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*"
3014 S: * LIST () "/" "foo2" ("CHILDINFO" ("SUBSCRIBED"))
3015 S: * LIST (\Subscribed) "/" "foo2/bar1"
3016 S: * LIST (\Subscribed) "/" "foo2/bar2"
3017 S: * LIST () "/" "baz2" ("CHILDINFO" ("SUBSCRIBED"))
3018 S: * LIST (\Subscribed) "/" "baz2/bar2"
3019 S: * LIST (\Subscribed) "/" "baz2/bar22"
3020 S: * LIST (\Subscribed) "/" "baz2/bar222"
3021 S: * LIST (\Subscribed) "/" "eps2" ("CHILDINFO" ("SUBSCRIBED"))
3022 S: * LIST (\Subscribed) "/" "eps2/mamba"
3023 S: * LIST (\Subscribed) "/" "qux2/bar2"
3026 the LIST responses for mailboxes "foo2", "baz2", and "eps2"
3027 still have the CHILDINFO extended data item, even though this
3028 information is redundant and the client can determine it by
3031 9: The following example shows usage of an extended syntax for the
3032 mailbox pattern. It also demonstrates that the presence of the
3033 CHILDINFO extended data item doesn't necessarily imply
3036 C: a1 LIST "" ("foo")
3037 S: * LIST () "/" foo
3040 C: a2 LIST (SUBSCRIBED) "" "foo/*"
3041 S: * LIST (\Subscribed \NonExistent) "/" foo/bar
3044 C: a3 LIST (SUBSCRIBED RECURSIVEMATCH) "" foo RETURN (CHILDREN)
3045 S: * LIST (\HasNoChildren) "/" foo ("CHILDINFO" ("SUBSCRIBED"))
3048 10: The following example shows how a server that supports missing
3049 mailbox hierarchy elements can signal to a client that didn't
3050 specify the RECURSIVEMATCH selection option that there is a
3051 child mailbox that matches the selection criteria.
3053 C: a1 LIST (REMOTE) "" *
3054 S: * LIST () "/" music/rock
3055 S: * LIST (\Remote) "/" also/jazz
3059 S: * LIST (\NonExistent \HasChildren) "/" music
3062 C: a3 LIST (REMOTE) "" %
3063 S: * LIST (\NonExistent \HasChildren) "/" music
3064 S: * LIST (\NonExistent \HasChildren) "/" also
3067 C: a3.1 LIST "" (% music/rock)
3068 S: * LIST () "/" music/rock
3071 Because "music/rock" is the only mailbox under "music", there's
3072 no need for the server to also return "music". However, clients
3073 must handle both cases.
3075 11: The following examples show use of the STATUS return option.
3077 C: A01 LIST "" % RETURN (STATUS (MESSAGES UNSEEN))
3078 S: * LIST () "." "INBOX"
3079 S: * STATUS "INBOX" (MESSAGES 17 UNSEEN 16)
3080 S: * LIST () "." "foo"
3081 S: * STATUS "foo" (MESSAGES 30 UNSEEN 29)
3082 S: * LIST (\NoSelect) "." "bar"
3083 S: A01 OK List completed.
3085 The "bar" mailbox isn't selectable, so it has no STATUS reply.
3087 C: A02 LIST (SUBSCRIBED RECURSIVEMATCH) "" % RETURN (STATUS
3089 S: * LIST (\Subscribed) "." "INBOX"
3090 S: * STATUS "INBOX" (MESSAGES 17)
3091 S: * LIST () "." "foo" (CHILDINFO ("SUBSCRIBED"))
3092 S: A02 OK List completed.
3094 The LIST reply for "foo" is returned because it has matching
3095 children, but no STATUS reply is returned because "foo" itself
3096 doesn't match the selection criteria.
3102 Responses: REQUIRED untagged responses: NAMESPACE
3104 Result: OK - command completed
3105 NO - Can't complete the command
3106 BAD - arguments invalid
3108 The NAMESPACE command causes a single untagged NAMESPACE response to
3109 be returned. The untagged NAMESPACE response contains the prefix and
3110 hierarchy delimiter to the server's Personal Namespace(s), Other
3111 Users' Namespace(s), and Shared Namespace(s) that the server wishes
3112 to expose. The response will contain a NIL for any namespace class
3113 that is not available. The namespace-response-extensions ABNF non-
3114 terminal is defined for extensibility and MAY be included in the
3119 In this example, a server supports a single Personal Namespace. No
3120 leading prefix is used on personal mailboxes, and "/" is the
3121 hierarchy delimiter.
3124 S: * NAMESPACE (("" "/")) NIL NIL
3125 S: A001 OK NAMESPACE command completed
3129 A user logged on anonymously to a server. No personal mailboxes are
3130 associated with the anonymous user, and the user does not have access
3131 to the Other Users' Namespace. No prefix is required to access
3132 shared mailboxes, and the hierarchy delimiter is "."
3135 S: * NAMESPACE NIL NIL (("" "."))
3136 S: A001 OK NAMESPACE command completed
3140 A server that contains a Personal Namespace and a single Shared
3144 S: * NAMESPACE (("" "/")) NIL (("Public Folders/" "/"))
3145 S: A001 OK NAMESPACE command completed
3149 A server that contains a Personal Namespace, Other Users' Namespace,
3150 and multiple Shared Namespaces. Note that the hierarchy delimiter
3151 used within each namespace can be different.
3154 S: * NAMESPACE (("" "/")) (("~" "/")) (("#shared/" "/")
3155 ("#public/" "/")("#ftp/" "/")("#news." "."))
3156 S: A001 OK NAMESPACE command completed
3158 The prefix string allows a client to do things such as automatically
3159 create personal mailboxes or LIST all available mailboxes within a
3164 A server that supports only the Personal Namespace, with a leading
3165 prefix of INBOX to personal mailboxes and a hierarchy delimiter of
3169 S: * NAMESPACE (("INBOX." ".")) NIL NIL
3170 S: A001 OK NAMESPACE command completed
3172 Automatically create a mailbox to store sent items.
3174 C: A002 CREATE "INBOX.Sent Mail"
3175 S: A002 OK CREATE command completed
3177 Although a server will typically support only a single Personal
3178 Namespace, and a single Other User's Namespace, circumstances exist
3179 where there MAY be multiples of these, and a client MUST be prepared
3180 for them. If a client is configured such that it is required to
3181 create a certain mailbox, there can be circumstances where it is
3182 unclear which Personal Namespaces it should create the mailbox in.
3183 In these situations, a client SHOULD let the user select which
3184 namespaces to create the mailbox in, or just use the first Personal
3189 In this example, a server supports two Personal Namespaces. In
3190 addition to the regular Personal Namespace, the user has an
3191 additional Personal Namespace that allows access to mailboxes in an
3192 MH format mailstore.
3194 The client is configured to save a copy of all mail sent by the user
3195 into a mailbox with the \Sent attribute (see Section 7.3.1).
3196 Furthermore, after a message is deleted from a mailbox, the client is
3197 configured to move that message to a mailbox with the \Trash
3198 attribute. The server signals with the \NonExistent mailbox
3199 attribute that the corresponding mailboxes don't exist yet and that
3200 it is possible to create them. Once created, they could be used for
3201 \Sent or \Trash purposes, and the server will no longer include the
3202 \NonExistent mailbox attribute for them.
3204 Note that this example demonstrates how some extension parameters can
3205 be passed to further describe the #mh namespace. See the fictitious
3206 "X-PARAM" extension parameter.
3209 S: * NAMESPACE (("" "/")("#mh/" "/" "X-PARAM"
3210 ("FLAG1" "FLAG2"))) NIL NIL
3211 S: A001 OK NAMESPACE command completed
3213 C: A002 LIST (SPECIAL-USE) "" "*"
3214 S: * LIST (\NonExistent \Archive) "/" Archives
3215 S: * LIST (\NonExistent \Drafts) "/" Drafts
3216 S: * LIST (\NonExistent \Junk) "/" Junk
3217 S: * LIST (\NonExistent \Sent) "/" "Sent Mail"
3218 S: * LIST (\NonExistent \Trash) "/" "Deleted Items"
3219 S: A002 OK LIST Completed
3221 C: A003 LIST (SPECIAL-USE) "#mh/" "*"
3222 S: * LIST (\NonExistent \Archive) "/" "#mh/Archives"
3223 S: * LIST (\NonExistent \Drafts) "/" "#mh/Drafts"
3224 S: * LIST (\NonExistent \Junk) "/" "#mh/Junk"
3225 S: * LIST (\NonExistent \Sent) "/" "#mh/Sent Mail"
3226 S: * LIST (\NonExistent \Trash) "/" "#mh/Deleted Items"
3227 S: A003 OK LIST Completed
3229 It is desired to keep only one copy of sent mail. It is unclear
3230 which Personal Namespace the client should use to create the 'Sent
3231 Mail' mailbox. The user is prompted to select a namespace, and only
3232 one 'Sent Mail' mailbox is created.
3234 C: A004 CREATE "Sent Mail"
3235 S: A004 OK CREATE command completed
3237 The client is designed so that it keeps two 'Deleted Items'
3238 mailboxes, one for each namespace.
3240 C: A005 CREATE "Delete Items"
3241 S: A005 OK CREATE command completed
3243 C: A006 CREATE "#mh/Deleted Items"
3244 S: A006 OK CREATE command completed
3246 The next level of hierarchy following the Other Users' Namespace
3247 prefix SHOULD consist of <username>, where <username> is a user name
3248 as per the LOGIN or AUTHENTICATE command.
3250 A client can construct a LIST command by appending a "%" to the Other
3251 Users' Namespace prefix to discover the Personal Namespaces of other
3252 users that are available to the currently authenticated user.
3254 In response to such a LIST command, a server SHOULD NOT return user
3255 names that have not granted access to their personal mailboxes to the
3258 A server MAY return a LIST response containing only the names of
3259 users that have explicitly granted access to the user in question.
3261 Alternatively, a server MAY return NO to such a LIST command,
3262 requiring that a user name be included with the Other Users'
3263 Namespace prefix before listing any other user's mailboxes.
3267 A server that supports providing a list of other user's mailboxes
3268 that are accessible to the currently logged on user.
3271 S: * NAMESPACE (("" "/")) (("Other Users/" "/")) NIL
3272 S: A001 OK NAMESPACE command completed
3274 C: A002 LIST "" "Other Users/%"
3275 S: * LIST () "/" "Other Users/Mike"
3276 S: * LIST () "/" "Other Users/Karen"
3277 S: * LIST () "/" "Other Users/Matthew"
3278 S: * LIST () "/" "Other Users/Tesa"
3279 S: A002 OK LIST command completed
3283 A server that does not support providing a list of other user's
3284 mailboxes that are accessible to the currently logged on user. The
3285 mailboxes are listable if the client includes the name of the other
3286 user with the Other Users' Namespace prefix.
3289 S: * NAMESPACE (("" "/")) (("#Users/" "/")) NIL
3290 S: A001 OK NAMESPACE command completed
3292 In this example, the currently logged on user has access to the
3293 Personal Namespace of user Mike, but the server chose to suppress
3294 this information in the LIST response. However, by appending the
3295 user name Mike (received through user input) to the Other Users'
3296 Namespace prefix, the client is able to get a listing of the personal
3297 mailboxes of user Mike.
3299 C: A002 LIST "" "#Users/%"
3300 S: A002 NO The requested item could not be found.
3302 C: A003 LIST "" "#Users/Mike/%"
3303 S: * LIST () "/" "#Users/Mike/INBOX"
3304 S: * LIST () "/" "#Users/Mike/Foo"
3305 S: A003 OK LIST command completed.
3307 A prefix string might not contain a hierarchy delimiter, because in
3308 some cases, it is not needed as part of the prefix.
3312 A server that allows access to the Other Users' Namespace by
3313 prefixing the others' mailboxes with a '~' followed by <username>,
3314 where <username> is a user name as per the LOGIN or AUTHENTICATE
3318 S: * NAMESPACE (("" "/")) (("~" "/")) NIL
3319 S: A001 OK NAMESPACE command completed
3321 List the mailboxes for user mark
3323 C: A002 LIST "" "~mark/%"
3324 S: * LIST () "/" "~mark/INBOX"
3325 S: * LIST () "/" "~mark/foo"
3326 S: A002 OK LIST command completed
3330 Arguments: mailbox name
3332 status data item names
3334 Responses: REQUIRED untagged responses: STATUS
3336 Result: OK - status completed
3337 NO - status failure: no status for that name
3338 BAD - command unknown or arguments invalid
3340 The STATUS command requests the status of the indicated mailbox. It
3341 does not change the currently selected mailbox, nor does it affect
3342 the state of any messages in the queried mailbox.
3344 The STATUS command provides an alternative to opening a second
3345 IMAP4rev2 connection and doing an EXAMINE command on a mailbox to
3346 query that mailbox's status without deselecting the current mailbox
3347 in the first IMAP4rev2 connection.
3349 Unlike the LIST command, the STATUS command is not guaranteed to be
3350 fast in its response. Under certain circumstances, it can be quite
3351 slow. In some implementations, the server is obliged to open the
3352 mailbox as "read-only" internally to obtain certain status
3353 information. Also unlike the LIST command, the STATUS command does
3354 not accept wildcards.
3356 Note: The STATUS command is intended to access the status of
3357 mailboxes other than the currently selected mailbox. Because the
3358 STATUS command can cause the mailbox to be opened internally, and
3359 because this information is available by other means on the
3360 selected mailbox, the STATUS command SHOULD NOT be used on the
3361 currently selected mailbox. However, servers MUST be able to
3362 execute the STATUS command on the selected mailbox. (This might
3363 also implicitly happen when the STATUS return option is used in a
3366 The STATUS command MUST NOT be used as a "check for new messages
3367 in the selected mailbox" operation (refer to Sections 7 and 7.4.1
3368 for more information about the proper method for new message
3371 STATUS SIZE (see below) can take a significant amount of time,
3372 depending upon server implementation. Clients should use STATUS
3375 The currently defined status data items that can be requested are:
3378 The number of messages in the mailbox.
3381 The next unique identifier value of the mailbox. Refer to
3382 Section 2.3.1.1 for more information.
3385 The unique identifier validity value of the mailbox. Refer to
3386 Section 2.3.1.1 for more information.
3389 The number of messages that do not have the \Seen flag set.
3392 The number of messages that have the \Deleted flag set.
3395 The total size of the mailbox in octets. This is not strictly
3396 required to be an exact value, but it MUST be equal to or greater
3397 than the sum of the values of the RFC822.SIZE FETCH message data
3398 items (see Section 6.4.5) of all messages in the mailbox.
3402 C: A042 STATUS blurdybloop (UIDNEXT MESSAGES)
3403 S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
3404 S: A042 OK STATUS completed
3408 Arguments: mailbox name
3410 OPTIONAL flag parenthesized list
3412 OPTIONAL date/time string
3416 Responses: OPTIONAL untagged response: LIST
3418 Result: OK - append completed
3419 NO - append error: can't append to that mailbox, error
3420 in flags or date/time or message text
3421 BAD - command unknown or arguments invalid
3423 The APPEND command appends the literal argument as a new message to
3424 the end of the specified destination mailbox. This argument SHOULD
3425 be in the format of an [RFC5322] or [I18N-HDRS] message. 8-bit
3426 characters are permitted in the message. A server implementation
3427 that is unable to preserve 8-bit data properly MUST be able to
3428 reversibly convert 8-bit APPEND data to 7 bits using a [MIME-IMB]
3429 content transfer encoding.
3431 Note: There may be exceptions, such as draft messages, in which
3432 required [RFC5322] header fields are omitted in the message
3433 literal argument to APPEND. The full implications of doing so
3434 must be understood and carefully weighed.
3436 If a flag parenthesized list is specified, the flags SHOULD be set in
3437 the resulting message; otherwise, the flag list of the resulting
3438 message is set to "empty" by default.
3440 If a date-time is specified, the internal date SHOULD be set in the
3441 resulting message; otherwise, the internal date of the resulting
3442 message is set to the current date and time by default.
3444 If the append is unsuccessful for any reason, the mailbox MUST be
3445 restored to its state before the APPEND attempt (other than possibly
3446 keeping the changed mailbox's UIDNEXT value); no partial appending is
3449 If the destination mailbox does not exist, a server MUST return an
3450 error and MUST NOT automatically create the mailbox. Unless it is
3451 certain that the destination mailbox cannot be created, the server
3452 MUST send the response code "[TRYCREATE]" as the prefix of the text
3453 of the tagged NO response. This gives a hint to the client that it
3454 can attempt a CREATE command and retry the APPEND if the CREATE is
3457 On successful completion of an APPEND, the server returns an
3458 APPENDUID response code (see Section 7.1), unless otherwise specified
3461 In the case of a mailbox that has permissions set so that the client
3462 can APPEND to the mailbox, but not SELECT or EXAMINE it, the server
3463 MUST NOT send an APPENDUID response code as it would disclose
3464 information about the mailbox.
3466 In the case of a mailbox that has UIDNOTSTICKY status (see
3467 Section 7.1), the server MAY omit the APPENDUID response code as it
3470 If the mailbox is currently selected, normal new message actions
3471 SHOULD occur. Specifically, the server SHOULD notify the client
3472 immediately via an untagged EXISTS response. If the server does not
3473 do so, the client MAY issue a NOOP command after one or more APPEND
3476 If the server decides to convert (normalize) the mailbox name, it
3477 SHOULD return an untagged LIST with an OLDNAME extended data item,
3478 with the OLDNAME value being the supplied mailbox name and the name
3479 parameter being the normalized mailbox name. (See Section 6.3.9.7
3484 C: A003 APPEND saved-messages (\Seen) {326}
3485 S: + Ready for literal data
3486 C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
3487 C: From: Fred Foobar <foobar@Blurdybloop.example>
3488 C: Subject: afternoon meeting
3489 C: To: mooch@owatagu.siam.edu.example
3490 C: Message-Id: <B27397-0100000@Blurdybloop.example>
3491 C: MIME-Version: 1.0
3492 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
3494 C: Hello Joe, do you think we can meet at 3:30 tomorrow?
3496 S: A003 OK APPEND completed
3500 C: A003 APPEND saved-messages (\Seen) {297+}
3501 C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
3502 C: From: Fred Foobar <foobar@example.com>
3503 C: Subject: afternoon meeting
3504 C: To: mooch@example.com
3505 C: Message-Id: <B27397-0100000@example.com>
3506 C: MIME-Version: 1.0
3507 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
3509 C: Hello Joe, do you think we can meet at 3:30 tomorrow?
3511 S: A003 OK [APPENDUID 38505 3955] APPEND completed
3512 C: A004 COPY 2:4 meeting
3513 S: A004 OK [COPYUID 38505 304,319:320 3956:3958] Done
3514 C: A005 UID COPY 305:310 meeting
3515 S: A005 OK No matching messages, so nothing copied
3516 C: A006 COPY 2 funny
3518 C: A007 SELECT funny
3520 S: * OK [UIDVALIDITY 3857529045] Validity session-only
3521 S: * OK [UIDNEXT 2] Predicted next UID
3522 S: * NO [UIDNOTSTICKY] Non-persistent UIDs
3523 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
3524 S: * OK [PERMANENTFLAGS (\Deleted \Seen)] Limited
3525 S: * LIST () "." funny
3526 S: A007 OK [READ-WRITE] SELECT completed
3528 In this example, A003 and A004 demonstrate successful appending and
3529 copying to a mailbox that returns the UIDs assigned to the messages.
3530 A005 is an example in which no messages were copied; this is because
3531 in A003, we see that message 2 had UID 304, and message 3 had UID
3532 319; therefore, UIDs 305 through 310 do not exist (refer to
3533 Section 2.3.1.1 for further explanation). A006 is an example of a
3534 message being copied that did not return a COPYUID; and, as expected,
3535 A007 shows that the mail store containing that mailbox does not
3536 support persistent UIDs.
3538 | Note: The APPEND command is not used for message delivery,
3539 | because it does not provide a mechanism to transfer [SMTP]
3540 | envelope information.
3546 Responses: continuation data will be requested; the client sends
3547 the continuation data "DONE" to end the command
3549 Result: OK - IDLE completed after client sent "DONE"
3550 NO - failure: the server will not allow the IDLE
3551 command at this time
3552 BAD - command unknown or arguments invalid
3554 Without the IDLE command, a client would need to poll the server for
3555 changes to the selected mailbox (new mail, deletions, and flag
3556 changes). It's often more desirable to have the server transmit
3557 updates to the client in real time. This allows a user to see new
3558 mail immediately. The IDLE command allows a client to tell the
3559 server that it's ready to accept such real-time updates.
3561 The IDLE command is sent from the client to the server when the
3562 client is ready to accept unsolicited update messages. The server
3563 requests a response to the IDLE command using the continuation ("+")
3564 response. The IDLE command remains active until the client responds
3565 to the continuation, and as long as an IDLE command is active, the
3566 server is now free to send untagged EXISTS, EXPUNGE, FETCH, and other
3567 responses at any time. If the server chooses to send unsolicited
3568 FETCH responses, they MUST include a UID FETCH item.
3570 The IDLE command is terminated by the receipt of a "DONE"
3571 continuation from the client; such response satisfies the server's
3572 continuation request. At that point, the server MAY send any
3573 remaining queued untagged responses and then MUST immediately send
3574 the tagged response to the IDLE command and prepare to process other
3575 commands. As for other commands, the processing of any new command
3576 may cause the sending of unsolicited untagged responses, subject to
3577 the ambiguity limitations. The client MUST NOT send a command while
3578 the server is waiting for the DONE, since the server will not be able
3579 to distinguish a command from a continuation.
3581 The server MAY consider a client inactive if it has an IDLE command
3582 running, and if such a server has an inactivity timeout, it MAY log
3583 the client off implicitly at the end of its timeout period. Because
3584 of that, clients using IDLE are advised to terminate IDLE and reissue
3585 it at least every 29 minutes to avoid being logged off. This still
3586 allows a client to receive immediate mailbox updates even though it
3587 need only "poll" at half hour intervals.
3591 C: A001 SELECT INBOX
3592 S: * FLAGS (\Deleted \Seen \Flagged)
3593 S: * OK [PERMANENTFLAGS (\Deleted \Seen \Flagged)] Limited
3595 S: * OK [UIDVALIDITY 1]
3597 S: * LIST () "/" INBOX
3598 S: A001 OK [READ-WRITE] SELECT completed
3601 ...time passes; new mail arrives...
3604 S: A002 OK IDLE terminated
3605 ...another client expunges message 2 now...
3608 S: A003 OK FETCH completed
3613 ...time passes; another client expunges message 3...
3616 ...time passes; new mail arrives...
3619 S: A004 OK IDLE terminated
3622 S: A005 OK FETCH completed
36256.4. Client Commands - Selected State
3627 In the selected state, commands that manipulate messages in a mailbox
3630 In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
3631 and the authenticated state commands (SELECT, EXAMINE, NAMESPACE,
3632 CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, STATUS, and
3633 APPEND), the following commands are valid in the selected state:
3634 CLOSE, UNSELECT, EXPUNGE, SEARCH, FETCH, STORE, COPY, MOVE, and UID.
3640 Responses: no specific responses for this command
3642 Result: OK - close completed, now in authenticated state
3643 BAD - command unknown or arguments invalid
3645 The CLOSE command permanently removes all messages that have the
3646 \Deleted flag set from the currently selected mailbox, and it returns
3647 to the authenticated state from the selected state. No untagged
3648 EXPUNGE responses are sent.
3650 No messages are removed, and no error is given, if the mailbox is
3651 selected by an EXAMINE command or is otherwise selected as read-only.
3653 Even if a mailbox is selected, a SELECT, EXAMINE, or LOGOUT command
3654 MAY be issued without previously issuing a CLOSE command. The
3655 SELECT, EXAMINE, and LOGOUT commands implicitly close the currently
3656 selected mailbox without doing an expunge. However, when many
3657 messages are deleted, a CLOSE-LOGOUT or CLOSE-SELECT sequence is
3658 considerably faster than an EXPUNGE-LOGOUT or EXPUNGE-SELECT because
3659 no untagged EXPUNGE responses (which the client would probably
3665 S: A341 OK CLOSE completed
3671 Responses: no specific responses for this command
3673 Result: OK - unselect completed, now in authenticated state
3674 BAD - no mailbox selected, or argument supplied but
3677 The UNSELECT command frees a session's resources associated with the
3678 selected mailbox and returns the server to the authenticated state.
3679 This command performs the same actions as CLOSE, except that no
3680 messages are permanently removed from the currently selected mailbox.
3685 S: A342 OK Unselect completed
3691 Responses: untagged responses: EXPUNGE
3693 Result: OK - expunge completed
3694 NO - expunge failure: can't expunge (e.g., permission
3696 BAD - command unknown or arguments invalid
3698 The EXPUNGE command permanently removes all messages that have the
3699 \Deleted flag set from the currently selected mailbox. Before
3700 returning an OK to the client, an untagged EXPUNGE response is sent
3701 for each message that is removed.
3710 S: A202 OK EXPUNGE completed
3712 Note: In this example, messages 3, 4, 7, and 11 had the \Deleted flag
3713 set. See the description of the EXPUNGE response (Section 7.5.1) for
3714 further explanation.
3718 Arguments: OPTIONAL result specifier
3720 OPTIONAL [CHARSET] specification
3722 searching criteria (one or more)
3724 Responses: OPTIONAL untagged response: ESEARCH
3726 Result: OK - search completed
3727 NO - search error: can't search that [CHARSET] or
3729 BAD - command unknown or arguments invalid
3731 The SEARCH command searches the mailbox for messages that match the
3732 given searching criteria.
3734 The SEARCH command may contain result options. Result options
3735 control what kind of information is returned about messages matching
3736 the search criteria in an untagged ESEARCH response. If no result
3738 ALL is assumed (see below). The order of individual options is
3739 arbitrary. Individual options may contain parameters enclosed in
3740 parentheses. (However, if an option has a mandatory parameter, which
3741 can always be represented as a number or a sequence-set, the option
3742 parameter does not need the enclosing parentheses. See "Formal
3743 Syntax" (Section 9) for more details.) If an option has parameters,
3744 they consist of atoms and/or strings and/or lists in a specific
3746 supports MUST be rejected with a BAD response.
3748 Note that IMAP4rev1 used SEARCH responses [RFC3501] instead of
3749 ESEARCH responses. Clients that support only IMAP4rev2 MUST ignore
3752 This document specifies the following result options:
3755 Return the lowest message number/UID that satisfies the SEARCH
3759 the MIN result option in the ESEARCH response; however, it still
3760 MUST send the ESEARCH response.
3763 Return the highest message number/UID that satisfies the SEARCH
3766 If the SEARCH results in no matches, the server MUST NOT include
3767 the MAX result option in the ESEARCH response; however, it still
3768 MUST send the ESEARCH response.
3771 Return all message numbers/UIDs that satisfy the SEARCH criteria
3772 using the sequence-set syntax. Note that the client MUST NOT
3773 assume that messages/UIDs will be listed in any particular order.
3775 If the SEARCH results in no matches, the server MUST NOT include
3776 the ALL result option in the ESEARCH response; however, it still
3777 MUST send the ESEARCH response.
3780 Return the number of messages that satisfy the SEARCH criteria.
3781 This result option MUST always be included in the ESEARCH
3785 This option tells the server to remember the result of the SEARCH
3786 or UID SEARCH command (as well as any command based on SEARCH,
3787 e.g., SORT and THREAD [RFC5256]) and store it in an internal
3788 variable that we will reference as the "search result variable".
3789 The client can use the "$" marker to reference the content of this
3790 internal variable. The "$" marker can be used instead of message
3791 sequence or UID sequence in order to indicate that the server
3792 should substitute it with the list of messages from the search
3793 result variable. Thus, the client can use the result of the
3794 latest remembered SEARCH command as a parameter to another
3795 command. See Section 6.4.4.1 for details on how the value of the
3796 search result variable is determined, how it is affected by other
3797 commands executed, and how the SAVE return option interacts with
3798 other return options.
3801 option also suppresses any ESEARCH response that would have been
3802 otherwise returned by the SEARCH command.
3804 Note: future extensions to this document can allow servers to return
3805 multiple ESEARCH responses for a single extended SEARCH command.
3806 However, all options specified above MUST result in a single ESEARCH
3807 response if used by themselves or in combination. This guarantee
3808 simplifies processing in IMAP4rev2 clients. Future SEARCH extensions
3809 that relax this restriction will have to describe how results from
3810 multiple ESEARCH responses are to be combined.
3812 Searching criteria consist of one or more search keys.
3814 When multiple keys are specified, the result is the intersection (AND
3815 function) of all the messages that match those keys. For example,
3816 the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers to all
3817 deleted messages from Smith with INTERNALDATE greater than February
3818 1, 1994. A search key can also be a parenthesized list of one or
3819 more search keys (e.g., for use with the OR and NOT keys).
3821 Server implementations MAY exclude [MIME-IMB] body parts with
3822 terminal content media types other than TEXT and MESSAGE from
3823 consideration in SEARCH matching.
3825 The OPTIONAL [CHARSET] specification consists of the word "CHARSET"
3826 followed by the name of a character set from the registry
3827 [CHARSET-REG]. It indicates the [CHARSET] of the strings that appear
3828 in the search criteria. [MIME-IMB] content transfer encodings and
3829 [MIME-HDRS] strings in [RFC5322]/[MIME-IMB] headers MUST be decoded
3830 before comparing text. Servers MUST support US-ASCII and UTF-8
3831 charsets; other CHARSETs MAY be supported. Clients SHOULD use UTF-8.
3832 Note that if CHARSET is not provided, IMAP4rev2 servers MUST assume
3833 UTF-8, so selecting CHARSET UTF-8 is redundant. It is permitted for
3834 improved compatibility with existing IMAP4rev1 clients.
3837 return a tagged NO response (not a BAD). This response SHOULD
3838 contain the BADCHARSET response code, which MAY list the CHARSETs
3839 supported by the server.
3841 In all search keys that use strings, and unless otherwise specified,
3842 a message matches the key if the string is a substring of the
3843 associated text. The matching SHOULD be case insensitive for
3844 characters within the ASCII range. Consider using [IMAP-I18N] for
3845 language-sensitive, case-insensitive searching. Note that the empty
3846 string is a substring; this is useful when performing a HEADER search
3847 in order to test for a header field presence in the message.
3849 The defined search keys are as follows. Refer to "Formal Syntax"
3850 (Section 9) for the precise syntactic definitions of the arguments.
3853 Messages with message sequence numbers corresponding to the
3854 specified message sequence number set.
3857 All messages in the mailbox; the default initial key for ANDing.
3860 Messages with the \Answered flag set.
3863 Messages that contain the specified string in the envelope
3864 structure's Blind Carbon Copy (BCC) field.
3867 Messages whose internal date (disregarding time and timezone) is
3868 earlier than the specified date.
3871 Messages that contain the specified string in the body of the
3872 message. Unlike TEXT (see below), this doesn't match any header
3873 fields. Servers are allowed to implement flexible matching for
3874 this search key, for example, by matching "swim" to both "swam"
3875 and "swum" in English language text or only performing full word
3876 matching (where "swim" will not match "swimming").
3879 Messages that contain the specified string in the envelope
3880 structure's CC field.
3883 Messages with the \Deleted flag set.
3886 Messages with the \Draft flag set.
3889 Messages with the \Flagged flag set.
3892 Messages that contain the specified string in the envelope
3893 structure's FROM field.
3896 Messages that have a header field with the specified field-name
3897 (as defined in [RFC5322]) and that contain the specified string in
3898 the text of the header field (what comes after the colon). If the
3899 string to search is zero-length, this matches all messages that
3900 have a header field with the specified field-name regardless of
3901 the contents. Servers should use a substring search for this
3902 SEARCH item, as clients can use it for automatic processing not
3903 initiated by end users. For example, this can be used when
3904 searching for Message-ID or Content-Type header field values that
3905 need to be exact or for searches in header fields that the IMAP
3906 server might not know anything about.
3909 Messages with the specified keyword flag set.
3912 Messages with an RFC822.SIZE larger than the specified number of
3916 Messages that do not match the specified search key.
3919 Messages whose internal date (disregarding time and timezone) is
3920 within the specified date.
3922 OR <search-key1> <search-key2>
3923 Messages that match either search key.
3926 Messages that have the \Seen flag set.
3929 Messages whose [RFC5322] Date: header field (disregarding time and
3930 timezone) is earlier than the specified date.
3933 Messages whose [RFC5322] Date: header field (disregarding time and
3934 timezone) is within the specified date.
3937 Messages whose [RFC5322] Date: header field (disregarding time and
3938 timezone) is within or later than the specified date.
3941 Messages whose internal date (disregarding time and timezone) is
3942 within or later than the specified date.
3945 Messages with an RFC822.SIZE smaller than the specified number of
3949 Messages that contain the specified string in the envelope
3950 structure's SUBJECT field.
3953 Messages that contain the specified string in the header
3954 (including MIME header fields) or body of the message. Servers
3955 are allowed to implement flexible matching for this search key,
3956 for example, matching "swim" to both "swam" and "swum" in English
3957 language text or only performing full-word matching (where "swim"
3958 will not match "swimming").
3961 Messages that contain the specified string in the envelope
3962 structure's TO field.
3965 Messages with unique identifiers corresponding to the specified
3966 unique identifier set. Sequence-set ranges are permitted.
3969 Messages that do not have the \Answered flag set.
3972 Messages that do not have the \Deleted flag set.
3975 Messages that do not have the \Draft flag set.
3978 Messages that do not have the \Flagged flag set.
3981 Messages that do not have the specified keyword flag set.
3984 Messages that do not have the \Seen flag set.
3988 C: A282 SEARCH RETURN (MIN COUNT) FLAGGED
3989 SINCE 1-Feb-1994 NOT FROM "Smith"
3990 S: * ESEARCH (TAG "A282") MIN 2 COUNT 3
3991 S: A282 OK SEARCH completed
3995 C: A283 SEARCH RETURN () FLAGGED
3996 SINCE 1-Feb-1994 NOT FROM "Smith"
3997 S: * ESEARCH (TAG "A283") ALL 2,10:11
3998 S: A283 OK SEARCH completed
4002 C: A284 SEARCH TEXT "string not in mailbox"
4003 S: * ESEARCH (TAG "A284")
4004 S: A284 OK SEARCH completed
4005 C: A285 SEARCH CHARSET UTF-8 TEXT {12}
4006 S: + Ready for literal text
4008 S: * ESEARCH (TAG "A285") ALL 43
4009 S: A285 OK SEARCH completed
4012 The following example demonstrates finding the first unseen message
4017 C: A284 SEARCH RETURN (MIN) UNSEEN
4018 S: * ESEARCH (TAG "A284") MIN 4
4019 S: A284 OK SEARCH completed
4021 The following example demonstrates that if the ESEARCH UID indicator
4022 is present, all data in the ESEARCH response is referring to UIDs;
4023 for example, the MIN result specifier will be followed by a UID.
4027 C: A285 UID SEARCH RETURN (MIN MAX) 1:5000
4028 S: * ESEARCH (TAG "A285") UID MIN 7 MAX 3800
4029 S: A285 OK SEARCH completed
4031 The following example demonstrates returning the number of deleted
4036 C: A286 SEARCH RETURN (COUNT) DELETED
4037 S: * ESEARCH (TAG "A286") COUNT 15
4038 S: A286 OK SEARCH completed
4042 Upon successful completion of a SELECT or an EXAMINE command (after
4043 the tagged OK response), the current search result variable is reset
4044 to the empty sequence.
4046 A successful SEARCH command with the SAVE result option sets the
4047 value of the search result variable to the list of messages found in
4048 the SEARCH command. For example, if no messages were found, the
4049 search result variable will contain the empty sequence.
4051 Any of the following SEARCH commands MUST NOT change the search
4054 a SEARCH command that caused the server to return the BAD tagged
4057 a SEARCH command with no SAVE result option that caused the server
4058 to return NO tagged response, and
4060 a successful SEARCH command with no SAVE result option.
4062 A SEARCH command with the SAVE result option that caused the server
4063 to return the NO tagged response sets the value of the search result
4064 variable to the empty sequence.
4066 When a message listed in the search result variable is EXPUNGEd, it
4067 is automatically removed from the list. Implementors are reminded
4068 that if the server stores the list as a list of message numbers, it
4069 MUST automatically adjust them when notifying the client about
4070 expunged messages, as described in Section 7.5.1.
4072 If the server decides to send a new UIDVALIDITY value while the
4073 mailbox is opened, it causes the resetting of the search variable to
4076 Note that even if the "$" marker contains the empty sequence of
4077 messages, it must be treated by all commands accepting message sets
4078 as parameters as a valid, but non-matching, list of messages. For
4079 example, the "FETCH $" command would return a tagged OK response and
4080 no FETCH responses. See also Example 5 in Section 6.4.4.4.
4082 The SAVE result option doesn't change whether the server would return
4083 items corresponding to MIN, MAX, ALL, or COUNT result options.
4085 When the SAVE result option is combined with the MIN or MAX result
4086 option, and both ALL and COUNT result options are absent, the
4087 corresponding MIN/MAX is returned (if the search result is not
4088 empty), but the "$" marker would contain a single message as returned
4089 in the MIN/MAX return item.
4091 If the SAVE result option is combined with both MIN and MAX result
4092 options, and both ALL and COUNT result options are absent, the "$"
4093 marker would contain zero messages, one message, or two messages as
4094 returned in the MIN/MAX return items.
4096 If the SAVE result option is combined with the ALL and/or COUNT
4097 result option(s), the "$" marker would always contain all messages
4098 found by the SEARCH or UID SEARCH command.
4100 The following table summarizes the additional requirement on ESEARCH
4101 server implementations described in this section.
4103 +==============================+====================+
4104 | Combination of Result Option | "$" Marker Value |
4105 +==============================+====================+
4107 +------------------------------+--------------------+
4109 +------------------------------+--------------------+
4110 | SAVE MIN MAX | MIN & MAX |
4111 +------------------------------+--------------------+
4112 | SAVE * [m] | all found messages |
4113 +------------------------------+--------------------+
4117 where '*' means "ALL" and/or "COUNT", and '[m]' means optional "MIN"
4120 Implementation note: server implementors should note that "$" can
4121 reference IMAP message sequences or UID sequences, depending on the
4122 context where it is used. For example, the "$" marker can be set as
4123 a result of a SEARCH (SAVE) command and used as a parameter to a UID
4124 FETCH command (which accepts a UID sequence, not a message sequence),
4125 or the "$" marker can be set as a result of a UID SEARCH (SAVE)
4126 command and used as a parameter to a FETCH command (which accepts a
4127 message sequence, not a UID sequence). Server implementations need
4128 to automatically map the "$" marker value to message numbers or UIDs,
4129 depending on the context where the "$" marker is used.
41316.4.4.2. Multiple Commands in Progress
4133 Use of a SEARCH RETURN (SAVE) command followed by a command using the
4134 "$" marker creates direct dependency between the two commands. As
4135 directed by Section 5.5, a server MUST execute the two commands in
4136 the order they were received.
4138 A client MAY pipeline a SEARCH RETURN (SAVE) command with one or more
4139 commands using the "$" marker, as long as this doesn't create an
4140 ambiguity, as described in Section 5.5. Examples 7-9 in
4141 Section 6.4.4.4 explain this in more details.
41436.4.4.3. Refusing to Save Search Results
4145 In some cases, the server MAY refuse to save a SEARCH (SAVE) result,
4146 for example, if an internal limit on the number of saved results is
4147 reached. In this case, the server MUST return a tagged NO response
4148 containing the NOTSAVED response code and set the search result
4149 variable to the empty sequence, as described in Section 6.4.4.1.
41516.4.4.4. Examples Showing Use of the SAVE Result Option
4153 Only in this section: explanatory comments in examples that start
4154 with // are not part of the protocol.
4156 1. The following example demonstrates how the client can use the
4157 result of a SEARCH command to FETCH headers of interesting
4162 C: A282 SEARCH RETURN (SAVE) FLAGGED SINCE 1-Feb-1994
4164 S: A282 OK SEARCH completed, result saved
4165 C: A283 FETCH $ (UID INTERNALDATE FLAGS BODY.PEEK[HEADER])
4166 S: * 2 FETCH (UID 14 ...
4167 S: * 84 FETCH (UID 100 ...
4168 S: * 882 FETCH (UID 1115 ...
4169 S: A283 OK completed
4171 The client can also pipeline the two commands:
4175 C: A282 SEARCH RETURN (SAVE) FLAGGED SINCE 1-Feb-1994
4177 C: A283 FETCH $ (UID INTERNALDATE FLAGS BODY.PEEK[HEADER])
4178 S: A282 OK SEARCH completed
4179 S: * 2 FETCH (UID 14 ...
4180 S: * 84 FETCH (UID 100 ...
4181 S: * 882 FETCH (UID 1115 ...
4182 S: A283 OK completed
4184 2. The following example demonstrates that the result of one SEARCH
4185 command can be used as input to another SEARCH command:
4189 C: A300 SEARCH RETURN (SAVE) SINCE 1-Jan-2004
4191 S: A300 OK SEARCH completed
4192 C: A301 UID SEARCH UID $ SMALLER 4096
4193 S: * ESEARCH (TAG "A301") UID ALL 17,900,901
4194 S: A301 OK completed
4196 Note that the second command in Example 3 can be replaced with:
4198 C: A301 UID SEARCH $ SMALLER 4096
4200 and the result of the command would be the same.
4202 3. The following example shows that the "$" marker can be combined
4203 with other message numbers using the OR SEARCH criterion.
4207 C: P282 SEARCH RETURN (SAVE) SINCE 1-Feb-1994
4209 S: P282 OK SEARCH completed
4210 C: P283 SEARCH CHARSET UTF-8 (OR $ 1,3000:3021) TEXT {8+}
4212 S: * ESEARCH (TAG "P283") ALL 882,1102,3003,3005:3006
4213 S: P283 OK completed
4215 4. The following example demonstrates that a failed SEARCH sets the
4216 search result variable to the empty list. The server doesn't
4217 implement the KOI8-R charset.
4221 C: B282 SEARCH RETURN (SAVE) SINCE 1-Feb-1994
4223 S: B282 OK SEARCH completed
4224 C: B283 SEARCH RETURN (SAVE) CHARSET KOI8-R
4225 (OR $ 1,3000:3021) TEXT {4}
4227 S: B283 NO [BADCHARSET UTF-8] KOI8-R is not supported
4228 //After this command, the saved result variable contains
4229 //no messages. A client that wants to reissue the B283
4230 //SEARCH command with another CHARSET would have to reissue
4231 //the B282 command as well. One possible workaround for
4232 //this is to include the desired CHARSET parameter
4233 //in the earliest SEARCH RETURN (SAVE) command in a
4234 //sequence of related SEARCH commands, to cause
4235 //the earliest SEARCH in the sequence to fail.
4236 //A better approach might be to always use CHARSET UTF-8
4239 Note: Since this document format is restricted to 7-bit ASCII
4240 text, it is not possible to show actual KOI8-R data. The "XXXX"
4241 is a placeholder for what would be 4 octets of 8-bit data in an
4244 5. The following example demonstrates that it is not an error to use
4245 the "$" marker when it contains no messages.
4249 C: E282 SEARCH RETURN (SAVE) SINCE 28-Oct-2006
4251 C: E283 COPY $ "Other Messages"
4252 //The "$" contains no messages
4253 S: E282 OK SEARCH completed
4254 S: E283 OK COPY completed, nothing copied
4258 C: F282 SEARCH RETURN (SAVE) KEYWORD $Junk
4259 C: F283 COPY $ "Junk"
4260 C: F284 STORE $ +FLAGS.Silent (\Deleted)
4261 S: F282 OK SEARCH completed
4262 S: F283 OK COPY completed
4263 S: F284 OK STORE completed
4267 C: G282 SEARCH RETURN (SAVE) KEYWORD $Junk
4268 C: G283 SEARCH RETURN (ALL) SINCE 28-Oct-2006
4270 // The server can execute the two SEARCH commands
4271 // in any order, as they don't have any dependency.
4272 // For example, it may return:
4273 S: * ESEARCH (TAG "G283") ALL 3:15,27,29:103
4274 S: G283 OK SEARCH completed
4275 S: G282 OK SEARCH completed
4277 The following example demonstrates that the result of the second
4278 SEARCH RETURN (SAVE) always overrides the result of the first.
4282 C: H282 SEARCH RETURN (SAVE) KEYWORD $Junk
4283 C: H283 SEARCH RETURN (SAVE) SINCE 28-Oct-2006
4285 S: H282 OK SEARCH completed
4286 S: H283 OK SEARCH completed
4287 // At this point "$" would contain results of H283
4289 The following example demonstrates behavioral difference for
4290 different combinations of ESEARCH result options.
4294 C: C282 SEARCH RETURN (ALL) SINCE 12-Feb-2006
4296 S: * ESEARCH (TAG "C283") ALL 2,10:15,21
4297 //$ value hasn't changed
4298 S: C282 OK SEARCH completed
4300 C: C283 SEARCH RETURN (ALL SAVE) SINCE 12-Feb-2006
4302 S: * ESEARCH (TAG "C283") ALL 2,10:15,21
4303 //$ value is 2,10:15,21
4304 S: C283 OK SEARCH completed
4306 C: C284 SEARCH RETURN (SAVE MIN) SINCE 12-Feb-2006
4308 S: * ESEARCH (TAG "C284") MIN 2
4310 S: C284 OK SEARCH completed
4312 C: C285 SEARCH RETURN (MAX SAVE MIN) SINCE
4313 12-Feb-2006 NOT FROM "Smith"
4314 S: * ESEARCH (TAG "C285") MIN 2 MAX 21
4316 S: C285 OK SEARCH completed
4318 C: C286 SEARCH RETURN (MAX SAVE MIN COUNT)
4319 SINCE 12-Feb-2006 NOT FROM "Smith"
4320 S: * ESEARCH (TAG "C286") MIN 2 MAX 21 COUNT 8
4321 //$ value is 2,10:15,21
4322 S: C286 OK SEARCH completed
4324 C: C286 SEARCH RETURN (ALL SAVE MIN) SINCE
4325 12-Feb-2006 NOT FROM "Smith"
4326 S: * ESEARCH (TAG "C286") MIN 2 ALL 2,10:15,21
4327 //$ value is 2,10:15,21
4328 S: C286 OK SEARCH completed
4332 Arguments: sequence set
4334 message data item names or macro
4336 Responses: untagged responses: FETCH
4338 Result: OK - fetch completed
4339 NO - fetch error: can't fetch that data
4340 BAD - command unknown or arguments invalid
4342 The FETCH command retrieves data associated with a message in the
4343 mailbox. The data items to be fetched can be either a single atom or
4344 a parenthesized list.
4346 Most data items, identified in the formal syntax (Section 9) under
4347 the msg-att-static rule, are static and MUST NOT change for any
4348 particular message. Other data items, identified in the formal
4349 syntax under the msg-att-dynamic rule, MAY change either as a result
4350 of a STORE command or due to external events.
4352 For example, if a client receives an ENVELOPE for a message when
4353 it already knows the envelope, it can safely ignore the newly
4354 transmitted envelope.
4356 There are three macros that specify commonly used sets of data items
4357 and can be used instead of data items. A macro must be used by
4358 itself and not in conjunction with other macros or data items.
4361 Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)
4364 Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE)
4367 Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE
4370 Several data items reference "section" or "section-binary". See
4371 Section 6.4.5.1 for their detailed definition.
4373 The currently defined data items that can be fetched are:
4375 BINARY[<section-binary>]<<partial>>
4376 Requests that the specified section be transmitted after
4377 performing decoding of the section's Content-Transfer-Encoding.
4379 The <partial> argument, if present, requests that a subset of the
4380 data be returned. The semantics of a partial FETCH BINARY command
4381 are the same as for a partial FETCH BODY command, with the
4382 exception that the <partial> arguments refer to the DECODED
4386 parts: those that have media types other than multipart/*,
4387 message/rfc822, or message/global.
4389 BINARY.PEEK[<section-binary>]<<partial>>
4390 An alternate form of BINARY[<section-binary>] that does not
4391 implicitly set the \Seen flag.
4393 BINARY.SIZE[<section-binary>]
4394 Requests the decoded size of the section (i.e., the size to expect
4395 in response to the corresponding FETCH BINARY request).
4397 Note: client authors are cautioned that this might be an expensive
4398 operation for some server implementations. Needlessly issuing
4399 this request could result in degraded performance due to servers
4400 having to calculate the value every time the request is issued.
4402 Note that this data item can only be requested for leaf body
4403 parts: those that have media types other than multipart/*,
4404 message/rfc822, or message/global.
4407 Non-extensible form of BODYSTRUCTURE.
4409 BODY[<section>]<<partial>>
4410 The text of a particular body section. If BODY[] is specified
4411 (the section specification is omitted), the FETCH is requesting
4412 the [RFC5322] expression of the entire message.
4414 It is possible to fetch a substring of the designated text. This
4415 is done by appending an open angle bracket ("<"), the octet
4416 position of the first desired octet, a period, the maximum number
4417 of octets desired, and a close angle bracket (">") to the part
4419 an empty string is returned.
4421 Any partial fetch that attempts to read beyond the end of the text
4422 is truncated as appropriate. A partial fetch that starts at octet
4423 0 is returned as a partial fetch, even if this truncation
4426 Note: This means that BODY[]<0.2048> of a 1500-octet message
4427 will return BODY[]<0> with a literal of size 1500, not BODY[].
4429 Note: A substring fetch of a HEADER.FIELDS or HEADER.FIELDS.NOT
4430 part specifier is calculated after subsetting the header.
4432 The \Seen flag is implicitly set; if this causes the flags to
4433 change, they SHOULD be included as part of the FETCH responses.
4435 BODY.PEEK[<section>]<<partial>>
4436 An alternate form of BODY[<section>] that does not implicitly set
4440 The [MIME-IMB] body structure of the message. This is computed by
4441 the server by parsing the [MIME-IMB] header fields in the
4442 [RFC5322] header and [MIME-IMB] headers. See Section 7.5.2 for
4446 The envelope structure of the message. This is computed by the
4447 server by parsing the [RFC5322] header into the component parts,
4448 defaulting various fields as necessary. See Section 7.5.2 for
4452 The flags that are set for this message.
4455 The internal date of the message.
4458 The size of the message, as defined in Section 2.3.4.
4461 The unique identifier for the message.
4465 C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)])
4469 S: A654 OK FETCH completed
44716.4.5.1. FETCH Section Specification
4473 Several FETCH data items reference "section" or "section-binary".
4474 The section specification is a set of zero or more part specifiers
4475 delimited by periods. A part specifier is either a part number or
4476 one of the following: HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME,
4477 and TEXT. (Non-numeric part specifiers have to be the last specifier
4478 in a section specification.) An empty section specification refers
4479 to the entire message, including the header.
4482 MIME, and MIME messages that are not multipart and have no
4483 encapsulated message within them, only have a part 1.
4486 occur in the message. If a particular part is of type message or
4487 multipart, its parts MUST be indicated by a period followed by the
4488 part number within that nested multipart part.
4490 A part of type MESSAGE/RFC822 or MESSAGE/GLOBAL also has nested part
4491 numbers, referring to parts of the MESSAGE part's body.
4493 The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, and TEXT part
4494 specifiers can be the sole part specifier or can be prefixed by one
4495 or more numeric part specifiers, provided that the numeric part
4496 specifier refers to a part of type MESSAGE/RFC822 or MESSAGE/GLOBAL.
4500 The HEADER, HEADER.FIELDS, and HEADER.FIELDS.NOT part specifiers
4501 refer to the [RFC5322] header of the message or of an encapsulated
4502 [MIME-IMT] MESSAGE/RFC822 or MESSAGE/GLOBAL message. HEADER.FIELDS
4503 and HEADER.FIELDS.NOT are followed by a list of field-names (as
4504 defined in [RFC5322]) and return a subset of the header. The subset
4505 returned by HEADER.FIELDS contains only those header fields with a
4506 field-name that matches one of the names in the list; similarly, the
4507 subset returned by HEADER.FIELDS.NOT contains only the header fields
4508 with a non-matching field-name. The field-matching is ASCII-range
4509 case insensitive but is otherwise exact. Subsetting does not exclude
4510 the [RFC5322] delimiting blank line between the header and the body;
4511 the blank line is included in all header fetches, except in the case
4512 of a message that has no body and no blank line.
4514 The MIME part specifier refers to the [MIME-IMB] header for this
4518 omitting the [RFC5322] header.
4523 HEADER ([RFC5322] header of the message)
4524 TEXT ([RFC5322] text body of the message) MULTIPART/MIXED
4526 2 APPLICATION/OCTET-STREAM
4528 3.HEADER ([RFC5322] header of the message)
4529 3.TEXT ([RFC5322] text body of the message) MULTIPART/MIXED
4531 3.2 APPLICATION/OCTET-STREAM
4536 4.2.HEADER ([RFC5322] header of the message)
4537 4.2.TEXT ([RFC5322] text body of the message) MULTIPART/MIXED
4539 4.2.2 MULTIPART/ALTERNATIVE
4541 4.2.2.2 TEXT/RICHTEXT
4545 Arguments: sequence set
4547 message data item name
4549 value for message data item
4551 Responses: untagged responses: FETCH
4553 Result: OK - store completed
4554 NO - store error: can't store that data
4555 BAD - command unknown or arguments invalid
4557 The STORE command alters data associated with a message in the
4558 mailbox. Normally, STORE will return the updated value of the data
4559 with an untagged FETCH response. A suffix of ".SILENT" in the data
4560 item name prevents the untagged FETCH, and the server SHOULD assume
4561 that the client has determined the updated value itself or does not
4562 care about the updated value.
4564 Note: Regardless of whether or not the ".SILENT" suffix was used,
4565 the server SHOULD send an untagged FETCH response if a change to a
4566 message's flags from an external source is observed. The intent
4567 is that the status of the flags is determinate without a race
4570 The currently defined data items that can be stored are:
4573 Replace the flags for the message with the argument. The new
4574 value of the flags is returned as if a FETCH of those flags was
4577 FLAGS.SILENT <flag list>
4578 Equivalent to FLAGS, but without returning a new value.
4581 Add the argument to the flags for the message. The new value of
4582 the flags is returned as if a FETCH of those flags was done.
4584 +FLAGS.SILENT <flag list>
4585 Equivalent to +FLAGS, but without returning a new value.
4588 Remove the argument from the flags for the message. The new value
4589 of the flags is returned as if a FETCH of those flags was done.
4591 -FLAGS.SILENT <flag list>
4592 Equivalent to -FLAGS, but without returning a new value.
4596 C: A003 STORE 2:4 +FLAGS (\Deleted)
4597 S: * 2 FETCH (FLAGS (\Deleted \Seen))
4598 S: * 3 FETCH (FLAGS (\Deleted))
4599 S: * 4 FETCH (FLAGS (\Deleted \Flagged \Seen))
4600 S: A003 OK STORE completed
4604 Arguments: sequence set
4608 Responses: no specific responses for this command
4610 Result: OK - copy completed
4611 NO - copy error: can't copy those messages or to that
4613 BAD - command unknown or arguments invalid
4615 The COPY command copies the specified message(s) to the end of the
4616 specified destination mailbox. The flags and internal date of the
4617 message(s) SHOULD be preserved in the copy.
4619 If the destination mailbox does not exist, a server MUST return an
4620 error. It MUST NOT automatically create the mailbox. Unless it is
4621 certain that the destination mailbox can not be created, the server
4622 MUST send the response code "[TRYCREATE]" as the prefix of the text
4623 of the tagged NO response. This gives a hint to the client that it
4624 can attempt a CREATE command and retry the COPY if the CREATE is
4627 If the COPY command is unsuccessful for any reason, server
4628 implementations MUST restore the destination mailbox to its state
4629 before the COPY attempt (other than possibly incrementing UIDNEXT),
4630 i.e., partial copy MUST NOT be done.
4632 On successful completion of a COPY, the server returns a COPYUID
4633 response code (see Section 7.1). Two exceptions to this requirement
4636 In the case of a mailbox that has permissions set so that the client
4637 can COPY to the mailbox, but not SELECT or EXAMINE it, the server
4638 MUST NOT send a COPYUID response code as it would disclose
4639 information about the mailbox.
4641 In the case of a mailbox that has UIDNOTSTICKY status (see
4642 Section 7.1), the server MAY omit the COPYUID response code as it is
4647 C: A003 COPY 2:4 MEETING
4648 S: A003 OK [COPYUID 38505 304,319:320 3956:3958] COPY completed
4652 Arguments: sequence set
4656 Responses: no specific responses for this command
4658 Result: OK - move completed
4659 NO - move error: can't move those messages or to that
4661 BAD - command unknown or arguments invalid
4663 The MOVE command moves the specified message(s) to the end of the
4664 specified destination mailbox. The flags and internal date of the
4665 message(s) SHOULD be preserved.
4667 This means that a new message is created in the target mailbox with a
4668 new UID, the original message is removed from the source mailbox, and
4669 it appears to the client as a single action. This has the same
4670 effect for each message as this sequence:
4674 2. [UID] STORE +FLAGS.SILENT \DELETED
4678 Although the effect of the MOVE is the same as the preceding steps,
4679 the semantics are not identical: the intermediate states produced by
4680 those steps do not occur, and the response codes are different. In
4681 particular, though the COPY and EXPUNGE response codes will be
4682 returned, response codes for a STORE MUST NOT be generated, and the
4683 \Deleted flag MUST NOT be set for any message.
4685 Unlike the COPY command, MOVE of a set of messages might fail partway
4686 through the set. Regardless of whether the command is successful in
4687 moving the entire set, each individual message MUST be either moved
4688 or unaffected. The server MUST leave each message in a state where
4689 it is in at least one of the source or target mailboxes (no message
4690 can be lost or orphaned). The server SHOULD NOT leave any message in
4691 both mailboxes (it would be bad for a partial failure to result in a
4692 bunch of duplicate messages). This is true even if the server
4693 returns a tagged NO response to the command.
4695 If the destination mailbox does not exist, a server MUST return an
4696 error. It MUST NOT automatically create the mailbox. Unless it is
4697 certain that the destination mailbox cannot be created, the server
4698 MUST send the response code "[TRYCREATE]" as the prefix of the text
4699 of the tagged NO response. This gives a hint to the client that it
4700 can attempt a CREATE command and retry the MOVE if the CREATE is
4703 Because of the similarity of MOVE to COPY, extensions that affect
4704 COPY affect MOVE in the same way. Response codes listed in
4705 Section 7.1, as well as those defined by extensions, are sent as
4709 Section 6.4.9) command. For additional information about COPYUID,
4710 see Section 7.1. Note that there are several exceptions listed in
4711 Section 6.4.7 that allow servers not to return COPYUID.
4714 untagged OK before sending EXPUNGE or similar responses. (Sending
4715 COPYUID in the tagged OK, as described in Section 6.4.7, means that
4716 clients first receive an EXPUNGE for a message and afterwards COPYUID
4717 for the same message. It can be unnecessarily difficult to process
4718 that sequence usefully.)
4722 C: a UID MOVE 42:69 foo
4723 S: * OK [COPYUID 432432 42:69 1202:1229]
4725 ...More EXPUNGE responses from the server...
4728 Note that the server may send unrelated EXPUNGE responses as well, if
4729 any happen to have been expunged at the same time; this is normal
4732 Note that moving a message to the currently selected mailbox (that
4733 is, where the source and target mailboxes are the same) is allowed
4734 when copying the message to the currently selected mailbox is
4737 The server may send EXPUNGE responses before the tagged response, so
4738 the client cannot safely send more commands with message sequence
4739 number arguments while the server is processing MOVE.
4741 MOVE and UID MOVE can be pipelined with other commands, but care has
4742 to be taken. Both commands modify sequence numbers and also allow
4743 unrelated EXPUNGE responses. The renumbering of other messages in
4744 the source mailbox following any EXPUNGE response can be surprising
4745 and makes it unsafe to pipeline any command that relies on message
4746 sequence numbers after a MOVE or UID MOVE. Similarly, MOVE cannot be
4747 pipelined with a command that might cause message renumbering. See
4748 Section 5.5 for more information about ambiguities as well as
4749 handling requirements for both clients and servers.
4753 Arguments: command name
4757 Responses: untagged responses: FETCH, ESEARCH, EXPUNGE
4759 Result: OK - UID command completed
4760 NO - UID command error
4761 BAD - command unknown or arguments invalid
4763 The UID command has three forms. In the first form, it takes as its
4764 arguments a COPY, MOVE, FETCH, or STORE command with arguments
4765 appropriate for the associated command. However, the numbers in the
4766 sequence-set argument are unique identifiers instead of message
4767 sequence numbers. Sequence-set ranges are permitted, but there is no
4768 guarantee that unique identifiers will be contiguous.
4770 A non-existent unique identifier is ignored without any error message
4771 generated. Thus, it is possible for a UID FETCH command to return an
4772 OK without any data or a UID COPY, UID MOVE, or UID STORE to return
4773 an OK without performing any operations.
4776 extra parameter that specifies a sequence set of UIDs to operate on.
4777 The UID EXPUNGE command permanently removes all messages that have
4778 both the \Deleted flag set and a UID that is included in the
4779 specified sequence set from the currently selected mailbox. If a
4780 message either does not have the \Deleted flag set or has a UID that
4781 is not included in the specified sequence set, it is not affected.
4783 UID EXPUNGE is particularly useful for disconnected use clients. By
4784 using UID EXPUNGE instead of EXPUNGE when resynchronizing with the
4785 server, the client can ensure that it does not inadvertently remove
4786 any messages that have been marked as \Deleted by other clients
4787 between the time that the client was last connected and the time the
4788 client resynchronizes.
4792 C: A003 UID EXPUNGE 3000:3002
4796 S: A003 OK UID EXPUNGE completed
4798 In the third form, the UID command takes a SEARCH command with SEARCH
4799 command arguments. The interpretation of the arguments is the same
4800 as with SEARCH; however, the numbers returned in an ESEARCH response
4801 for a UID SEARCH command are unique identifiers instead of message
4802 sequence numbers. Also, the corresponding ESEARCH response MUST
4803 include the UID indicator. For example, the command UID SEARCH 1:100
4804 UID 443:557 returns the unique identifiers corresponding to the
4805 intersection of two sequence sets, the message sequence number range
4806 1:100, and the UID range 443:557.
4808 Note: in the above example, the UID range 443:557 appears. The
4809 same comment about a non-existent unique identifier being ignored
4810 without any error message also applies here. Hence, even if
4811 neither UID 443 or 557 exist, this range is valid and would
4812 include an existing UID 495.
4815 last message in the mailbox, even if 559 is higher than any
4816 assigned UID value. This is because the contents of a range are
4817 independent of the order of the range endpoints. Thus, any UID
4818 range with * as one of the endpoints indicates at least one
4819 message (the message with the highest numbered UID), unless the
4822 The number after the "*" in an untagged FETCH or EXPUNGE response is
4823 always a message sequence number, not a unique identifier, even for a
4824 UID command response. However, server implementations MUST
4825 implicitly include the UID message data item as part of any FETCH
4826 response caused by a UID command, regardless of whether a UID was
4827 specified as a message data item to the FETCH.
4829 Note: The rule about including the UID message data item as part of a
4830 FETCH response primarily applies to the UID FETCH and UID STORE
4831 commands, including a UID FETCH command that does not include UID as
4832 a message data item. Although it is unlikely that the other UID
4833 commands will cause an untagged FETCH, this rule applies to these
4838 C: A999 UID FETCH 4827313:4828442 FLAGS
4839 S: * 23 FETCH (FLAGS (\Seen) UID 4827313)
4840 S: * 24 FETCH (FLAGS (\Seen) UID 4827943)
4841 S: * 25 FETCH (FLAGS (\Seen) UID 4828442)
4842 S: A999 OK UID FETCH completed
48446.5. Client Commands - Experimental/Expansion
4846 Each command that is not part of this specification MUST have at
4847 least one capability name (see Section 6.1.1) associated with it.
4848 (Multiple commands can be associated with the same capability name.)
4850 Server implementations MUST NOT send any added untagged responses
4851 (not specified in this specification), unless the client requested it
4852 by issuing the associated experimental command (specified in an
4853 extension document) or the ENABLE command (Section 6.3.1).
4855 The following example demonstrates how a client can check for the
4856 presence of a fictitious XPIG-LATIN capability that adds the XPIG-
4857 LATIN command and the XPIG-LATIN untagged response. (Note that for
4858 an extension, the command name and the capability name don't have to
4864 S: * CAPABILITY IMAP4rev2 XPIG-LATIN
4865 S: a441 OK CAPABILITY completed
4867 S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay
4868 S: A442 OK XPIG-LATIN ompleted-cay
4872 Server responses are in three forms: status responses, server data,
4873 and command continuation requests. The information contained in a
4874 server response, identified by "Contents:" in the response
4875 descriptions below, is described by function, not by syntax. The
4876 precise syntax of server responses is described in "Formal Syntax"
4879 The client MUST be prepared to accept any response at all times.
4881 Status responses can be tagged or untagged. Tagged status responses
4882 indicate the completion result (OK, NO, or BAD status) of a client
4883 command and have a tag matching the command.
4885 Some status responses, and all server data, are untagged. An
4886 untagged response is indicated by the token "*" instead of a tag.
4887 Untagged status responses indicate server greeting or server status
4888 that does not indicate the completion of a command (for example, an
4889 impending system shutdown alert). For historical reasons, untagged
4890 server data responses are also called "unsolicited data", although
4891 strictly speaking, only unilateral server data is truly
4894 Certain server data MUST be remembered by the client when it is
4895 received; this is noted in the description of that data. Such data
4896 conveys critical information that affects the interpretation of all
4897 subsequent commands and responses (e.g., updates reflecting the
4898 creation or destruction of messages).
4900 Other server data SHOULD be remembered for later reference; if the
4901 client does not need to remember the data, or if remembering the data
4902 has no obvious purpose (e.g., a SEARCH response when no SEARCH
4903 command is in progress), the data can be ignored.
4905 An example of unilateral untagged server data occurs when the IMAP
4906 connection is in the selected state. In the selected state, the
4907 server checks the mailbox for new messages as part of command
4908 execution. Normally, this is part of the execution of every command;
4909 hence, a NOOP command suffices to check for new messages. If new
4910 messages are found, the server sends an untagged EXISTS response
4911 reflecting the new size of the mailbox. Server implementations that
4912 offer multiple simultaneous access to the same mailbox SHOULD also
4913 send appropriate unilateral untagged FETCH and EXPUNGE responses if
4914 another agent changes the state of any message flags or expunges any
4917 Command continuation request responses use the token "+" instead of a
4918 tag. These responses are sent by the server to indicate acceptance
4919 of an incomplete client command and readiness for the remainder of
49227.1. Server Responses - Generic Status Responses
4924 Status responses are OK, NO, BAD, PREAUTH, and BYE. OK, NO, and BAD
4925 can be tagged or untagged. PREAUTH and BYE are always untagged.
4927 Status responses MAY include an OPTIONAL "response code". A response
4928 code consists of data inside square brackets in the form of an atom,
4929 possibly followed by a space and arguments. The response code
4930 contains additional information or status codes for client software
4931 beyond the OK/NO/BAD condition and are defined when there is a
4932 specific action that a client can take based upon the additional
4935 The currently defined response codes are:
4938 The human-readable text contains a special alert that is presented
4939 to the user in a fashion that calls the user's attention to the
4940 message. Content of ALERT response codes received on a connection
4941 without TLS or SASL security-layer confidentiality SHOULD be
4942 ignored by clients. If displayed, such alerts MUST be clearly
4943 marked as potentially suspicious. (Note that some existing
4944 clients are known to hyperlink returned text, which make them very
4945 dangerous.) Alerts received after successful establishment of a
4946 TLS/SASL confidentiality layer MUST be presented to the user.
4949 The operation attempts to create something that already exists,
4950 such as when a CREATE or RENAME command attempts to create a
4951 mailbox and there is already one of that name.
4953 C: o356 RENAME this that
4954 S: o356 NO [ALREADYEXISTS] Mailbox "that" already exists
4957 Followed by the UIDVALIDITY of the destination mailbox and the UID
4958 assigned to the appended message in the destination mailbox, it
4959 indicates that the message has been appended to the destination
4960 mailbox with that UID.
4962 If the server also supports the [MULTIAPPEND] extension, and if
4963 multiple messages were appended in the APPEND command, then the
4964 second value is a UID set containing the UIDs assigned to the
4965 appended messages, in the order they were transmitted in the
4966 APPEND command. This UID set may not contain extraneous UIDs or
4969 Note: the UID set form of the APPENDUID response code MUST NOT
4970 be used if only a single message was appended. In particular,
4971 a server MUST NOT send a range such as 123:123. This is
4972 because a client that does not support [MULTIAPPEND] expects
4973 only a single UID and not a UID set.
4975 UIDs are assigned in strictly ascending order in the mailbox
4976 (refer to Section 2.3.1.1); note that a range of 12:10 is exactly
4977 equivalent to 10:12 and refers to the sequence 10,11,12.
4979 This response code is returned in a tagged OK response to the
4982 AUTHENTICATIONFAILED
4983 Authentication failed for some reason on which the server is
4984 unwilling to elaborate. Typically, this includes "unknown user"
4987 This is the same as not sending any response code, except that
4988 when a client sees AUTHENTICATIONFAILED, it knows that the problem
4989 wasn't, e.g., UNAVAILABLE, so there's no point in trying the same
4990 login/password again later.
4992 C: b LOGIN "fred" "foo"
4993 S: b NO [AUTHENTICATIONFAILED] Authentication failed
4996 Authentication succeeded in using the authentication identity, but
4997 the server cannot or will not allow the authentication identity to
4998 act as the requested authorization identity. This is only
4999 applicable when the authentication and authorization identities
5002 C: c1 AUTHENTICATE PLAIN
5004 S: c1 NO [AUTHORIZATIONFAILED] No such authorization-ID
5006 C: c2 AUTHENTICATE PLAIN
5008 S: c2 NO [AUTHORIZATIONFAILED] Authenticator is not an admin
5011 Optionally followed by a parenthesized list of charsets. A SEARCH
5012 failed because the given charset is not supported by this
5013 implementation. If the optional list of charsets is given, this
5014 lists the charsets that are supported by this implementation.
5017 This operation violates some invariant of the server and can never
5020 C: l create "///////"
5021 S: l NO [CANNOT] Adjacent slashes are not supported
5024 Followed by a list of capabilities. This can appear in the
5025 initial OK or PREAUTH response to transmit an initial capabilities
5026 list. It can also appear in tagged responses to LOGIN or
5027 AUTHENTICATE commands. This makes it unnecessary for a client to
5028 send a separate CAPABILITY command if it recognizes this response
5029 code and there was no change to the TLS and/or authentication
5030 state since it was received.
5033 The server has detected a client bug. This can accompany any of
5034 OK, NO, and BAD, depending on what the client bug is.
5036 C: k1 select "/archive/projects/experiment-iv"
5038 S: k1 OK [READ-ONLY] Done
5039 C: k2 status "/archive/projects/experiment-iv" (messages)
5041 S: k2 OK [CLIENTBUG] Done
5044 The CLOSED response code has no parameters. A server returns the
5045 CLOSED response code when the currently selected mailbox is closed
5046 implicitly using the SELECT or EXAMINE command on another mailbox.
5047 The CLOSED response code serves as a boundary between responses
5048 for the previously opened mailbox (which was closed) and the newly
5049 selected mailbox; all responses before the CLOSED response code
5050 relate to the mailbox that was closed, and all subsequent
5051 responses relate to the newly opened mailbox.
5053 There is no need to return the CLOSED response code on completion
5054 of the CLOSE or the UNSELECT command (or similar), whose purpose
5055 is to close the currently selected mailbox without opening a new
5059 The user should contact the system administrator or support desk.
5061 C: e login "fred" "foo"
5062 S: e NO [CONTACTADMIN]
5065 Followed by the UIDVALIDITY of the destination mailbox, a UID set
5066 containing the UIDs of the message(s) in the source mailbox that
5067 were copied to the destination mailbox, followed by another UID
5068 set containing the UIDs assigned to the copied message(s) in the
5069 destination mailbox, indicates that the message(s) has been copied
5070 to the destination mailbox with the stated UID(s).
5073 destination UID set corresponds to the source UID set and is in
5074 the same order. Neither of the UID sets may contain extraneous
5075 UIDs or the symbol "*".
5077 UIDs are assigned in strictly ascending order in the mailbox
5078 (refer to Section 2.3.1.1); note that a range of 12:10 is exactly
5079 equivalent to 10:12 and refers to the sequence 10,11,12.
5081 This response code is returned in a tagged OK response to the COPY
5082 or UID COPY command or in the untagged OK response to the MOVE or
5086 The server discovered that some relevant data (e.g., the mailbox)
5087 are corrupt. This response code does not include any information
5088 about what's corrupt, but the server can write that to its
5091 C: i select "/archive/projects/experiment-iv"
5092 S: i NO [CORRUPTION] Cannot open mailbox
5095 Either authentication succeeded or the server no longer had the
5096 necessary data; either way, access is no longer permitted using
5097 that passphrase. The client or user should get a new passphrase.
5099 C: d login "fred" "foo"
5100 S: d NO [EXPIRED] That password isn't valid any more
5103 Someone else has issued an EXPUNGE for the same mailbox. The
5104 client may want to issue NOOP soon. [IMAP-MULTIACCESS] discusses
5105 this subject in depth.
5107 C: h search from maria@example.com
5108 S: * ESEARCH (TAG "h") ALL 1:3,5,8,13,21,42
5109 S: h OK [EXPUNGEISSUED] Search completed
5112 The mailbox delete operation failed because the mailbox has one or
5113 more children, and the server doesn't allow deletion of mailboxes
5116 C: m356 DELETE Notes
5117 S: o356 NO [HASCHILDREN] Mailbox "Notes" has children
5118 that need to be deleted first
5121 An operation has not been carried out because it involves sawing
5122 off a branch someone else is sitting on. Someone else may be
5123 holding an exclusive lock needed for this operation, or the
5124 operation may involve deleting a resource someone else is using,
5125 typically a mailbox.
5127 The operation may succeed if the client tries again later.
5129 C: g delete "/archive/projects/experiment-iv"
5130 S: g NO [INUSE] Mailbox in use
5133 The operation ran up against an implementation limit of some kind,
5134 such as the number of flags on a single message or the number of
5135 flags used in a mailbox.
5137 C: m STORE 42 FLAGS f1 f2 f3 f4 f5 ... f250
5138 S: m NO [LIMIT] At most 32 flags in one mailbox supported
5141 The operation attempts to delete something that does not exist.
5142 Similar to ALREADYEXISTS.
5144 C: p RENAME this that
5145 S: p NO [NONEXISTENT] No such mailbox
5148 The access control system (e.g., ACL; see [RFC4314]) does not
5149 permit this user to carry out an operation, such as selecting or
5152 C: f select "/archive/projects/experiment-iv"
5153 S: f NO [NOPERM] Access denied
5156 The user would be over quota after the operation. (The user may
5157 or may not be over quota already.)
5159 Note that if the server sends OVERQUOTA but doesn't support the
5160 IMAP QUOTA extension defined by [RFC2087], then there is a quota,
5161 but the client cannot find out what the quota is.
5163 C: n1 uid copy 1:* oldmail
5164 S: n1 NO [OVERQUOTA] Sorry
5166 C: n2 uid copy 1:* oldmail
5167 S: n2 OK [OVERQUOTA] You are now over your soft quota
5170 The human-readable text represents an error in parsing the
5171 [RFC5322] header or [MIME-IMB] headers of a message in the
5175 Followed by a parenthesized list of flags and indicates which of
5176 the known flags the client can change permanently. Any flags that
5177 are in the FLAGS untagged response, but not in the PERMANENTFLAGS
5178 list, cannot be set permanently. The PERMANENTFLAGS list can also
5179 include the special flag \*, which indicates that it is possible
5180 to create new keywords by attempting to store those keywords in
5181 the mailbox. If the client attempts to STORE a flag that is not
5182 in the PERMANENTFLAGS list, the server will either ignore the
5183 change or store the state change for the remainder of the current
5186 There is no need for a server that included the special flag \* to
5187 return a new PERMANENTFLAGS response code when a new keyword was
5188 successfully set on a message upon client request. However, if
5189 the server has a limit on the number of different keywords that
5190 can be stored in a mailbox and that limit is reached, the server
5191 MUST send a new PERMANENTFLAGS response code without the special
5195 The operation is not permitted due to a lack of data
5196 confidentiality. If TLS is not in use, the client could try
5197 STARTTLS (see Section 6.2.1) or alternatively reconnect on an
5198 Implicit TLS port, and then repeat the operation.
5200 C: d login "fred" "foo"
5201 S: d NO [PRIVACYREQUIRED] Connection offers no privacy
5204 S: d NO [PRIVACYREQUIRED] Connection offers no privacy
5207 The mailbox is selected as read-only, or its access while selected
5208 has changed from read-write to read-only.
5211 The mailbox is selected as read-write, or its access while
5212 selected has changed from read-only to read-write.
5215 The server encountered a bug in itself or violated one of its own
5218 C: j select "/archive/projects/experiment-iv"
5219 S: j NO [SERVERBUG] This should not happen
5222 An APPEND, COPY, or MOVE attempt is failing because the target
5223 mailbox does not exist (as opposed to some other reason). This is
5224 a hint to the client that the operation can succeed if the mailbox
5225 is first created by the CREATE command.
5228 Followed by a decimal number and indicates the next unique
5229 identifier value. Refer to Section 2.3.1.1 for more information.
5232 The selected mailbox is supported by a mail store that does not
5233 support persistent UIDs; that is, UIDVALIDITY will be different
5234 each time the mailbox is selected. Consequently, APPEND or COPY
5235 to this mailbox will not return an APPENDUID or COPYUID response
5238 This response code is returned in an untagged NO response to the
5241 Note: servers SHOULD NOT have any UIDNOTSTICKY mail stores.
5242 This facility exists to support legacy mail stores in which it
5243 is technically infeasible to support persistent UIDs. This
5244 should be avoided when designing new mail stores.
5247 Followed by a decimal number and indicates the unique identifier
5248 validity value. Refer to Section 2.3.1.1 for more information.
5251 Temporary failure because a subsystem is down. For example, an
5252 IMAP server that uses a Lightweight Directory Access Protocol
5253 (LDAP) or Radius server for authentication might use this response
5254 code when the LDAP/Radius server is down.
5256 C: a LOGIN "fred" "foo"
5257 S: a NO [UNAVAILABLE] User's backend down for maintenance
5260 The server does not know how to decode the section's Content-
5263 Client implementations MUST ignore response codes that they do not
5269 OPTIONAL response code
5272 The OK response indicates an information message from the server.
5273 When tagged, it indicates successful completion of the associated
5274 command. The human-readable text MAY be presented to the user as an
5275 information message. The untagged form indicates an information-only
5276 message; the nature of the information MAY be indicated by a response
5279 The untagged form is also used as one of three possible greetings at
5280 connection startup. It indicates that the connection is not yet
5281 authenticated and that a LOGIN or an AUTHENTICATE command is needed.
5285 S: * OK IMAP4rev2 server ready
5286 C: A001 LOGIN fred blurdybloop
5287 S: * OK [ALERT] System shutdown in 10 minutes
5288 S: A001 OK LOGIN Completed
5293 OPTIONAL response code
5296 The NO response indicates an operational error message from the
5297 server. When tagged, it indicates unsuccessful completion of the
5298 associated command. The untagged form indicates a warning; the
5299 command can still complete successfully. The human-readable text
5300 describes the condition.
5304 C: A222 COPY 1:2 owatagusiam
5305 S: * NO Disk is 98% full, please delete unnecessary data
5306 S: A222 OK COPY completed
5307 C: A223 COPY 3:200 blurdybloop
5308 S: * NO Disk is 98% full, please delete unnecessary data
5309 S: * NO Disk is 99% full, please delete unnecessary data
5310 S: A223 NO COPY failed: disk is full
5315 OPTIONAL response code
5318 The BAD response indicates an error message from the server. When
5319 tagged, it reports a protocol-level error in the client's command;
5320 the tag indicates the command that caused the error. The untagged
5321 form indicates a protocol-level error for which the associated
5322 command can not be determined; it can also indicate an internal
5323 server failure. The human-readable text describes the condition.
5327 C: ...very long command line...
5328 S: * BAD Command line too long
5330 S: * BAD Empty command line
5332 S: * BAD Disk crash, attempting salvage to a new disk!
5333 S: * OK Salvage successful, no data lost
5334 S: A443 OK Expunge completed
53367.1.4. PREAUTH Response
5339 OPTIONAL response code
5342 The PREAUTH response is always untagged and is one of three possible
5343 greetings at connection startup. It indicates that the connection
5344 has already been authenticated by external means; thus, no LOGIN/
5345 AUTHENTICATE command is needed.
5347 Because PREAUTH moves the connection directly to the authenticated
5348 state, it effectively prevents the client from using the STARTTLS
5349 command (Section 6.2.1). For this reason, the PREAUTH response
5350 SHOULD only be returned by servers on connections that are protected
5351 by TLS (such as on an Implicit TLS port [RFC8314]) or protected
5352 through other means such as IPsec. Clients that require mandatory
5353 TLS MUST close the connection after receiving the PREAUTH response on
5354 a non-protected port.
5358 S: * PREAUTH IMAP4rev2 server logged in as Smith
5363 OPTIONAL response code
5366 The BYE response is always untagged and indicates that the server is
5367 about to close the connection. The human-readable text MAY be
5368 displayed to the user in a status report by the client. The BYE
5369 response is sent under one of four conditions:
5371 1. as part of a normal logout sequence. The server will close the
5372 connection after sending the tagged OK response to the LOGOUT
5376 connection immediately.
5378 3. as an announcement of an inactivity autologout. The server
5379 closes the connection immediately.
5382 indicating that the server is not willing to accept a connection
5383 from this client. The server closes the connection immediately.
5385 The difference between a BYE that occurs as part of a normal LOGOUT
5386 sequence (the first case) and a BYE that occurs because of a failure
5387 (the other three cases) is that the connection closes immediately in
5388 the failure case. In all cases, the client SHOULD continue to read
5389 response data from the server until the connection is closed; this
5390 will ensure that any pending untagged or completion responses are
5395 S: * BYE Autologout; idle for too long
53977.2. Server Responses - Server Status
5399 These responses are always untagged. This is how server status data
5400 are transmitted from the server to the client.
54027.2.1. ENABLED Response
5404 Contents: capability listing
5406 The ENABLED response occurs as a result of an ENABLE command. The
5407 capability listing contains a space-separated listing of capability
5408 names that the server supports and that were successfully enabled.
5409 The ENABLED response may contain no capabilities, which means that no
5410 extensions listed by the client were successfully enabled.
5414 S: * ENABLED CONDSTORE QRESYNC
54167.2.2. CAPABILITY Response
5418 Contents: capability listing
5420 The CAPABILITY response occurs as a result of a CAPABILITY command.
5421 The capability listing contains a space-separated listing of
5422 capability names that the server supports. The capability listing
5423 MUST include the atom "IMAP4rev2", but note that it doesn't have to
5424 be the first capability listed. The order of capability names has no
5427 Client and server implementations MUST implement the capabilities
5428 "AUTH=PLAIN" (described in [PLAIN]), and MUST implement "STARTTLS"
5429 and "LOGINDISABLED" on the cleartext port. See the Security
5430 Considerations (Section 11) for important information related to
5433 A capability name that begins with "AUTH=" indicates that the server
5434 supports that particular authentication mechanism [SASL].
5436 The LOGINDISABLED capability indicates that the LOGIN command is
5437 disabled, and that the server will respond with a tagged NO response
5438 to any attempt to use the LOGIN command even if the user name and
5439 password are valid (their validity will not be checked). An IMAP
5440 client MUST NOT issue the LOGIN command if the server advertises the
5441 LOGINDISABLED capability.
5443 Other capability names indicate that the server supports an
5444 extension, revision, or amendment to the IMAP4rev2 protocol. If
5445 IMAP4rev1 capability is not advertised, server responses MUST conform
5446 to this document until the client issues a command that uses an
5447 additional capability. If both IMAP4rev1 and IMAP4rev2 capabilities
5448 are advertised, server responses MUST conform to [RFC3501] until the
5449 client issues a command that uses an additional capability. (For
5450 example, the client can issue ENABLE IMAP4rev2 to enable
5451 IMAP4rev2-specific behavior.)
5453 Capability names SHOULD be registered with IANA using the RFC
5454 Required policy [RFC8126]. A server SHOULD NOT offer unregistered
5457 Client implementations SHOULD NOT require any capability name other
5458 than "IMAP4rev2", and possibly "STARTTLS" and "LOGINDISABLED" (on a
5459 cleartext port). Client implementations MUST ignore any unknown
5462 A server MAY send capabilities automatically, by using the CAPABILITY
5463 response code in the initial PREAUTH or OK responses and by sending
5464 an updated CAPABILITY response code in the tagged OK response as part
5465 of a successful authentication. It is unnecessary for a client to
5466 send a separate CAPABILITY command if it recognizes these automatic
5467 capabilities and there was no change to the TLS and/or authentication
5468 state since they were received.
5470 The list of capabilities returned by a server MAY change during the
5471 connection. In particular, it is quite common for the server to
5472 change the list of capabilities after successful TLS negotiation
5473 (STARTTLS command) and/or after successful authentication
5474 (AUTHENTICATE or LOGIN commands).
5478 S: * CAPABILITY STARTTLS AUTH=GSSAPI IMAP4rev2 LOGINDISABLED
5481 Note that in the above example, XPIG-LATIN is a fictitious capability
54847.3. Server Responses - Mailbox Status
5486 These responses are always untagged. This is how mailbox status data
5487 are transmitted from the server to the client. Many of these
5488 responses typically result from a command with the same name.
5496 OPTIONAL extension data
5498 The LIST response occurs as a result of a LIST command. It returns a
5499 single name that matches the LIST specification. There can be
5500 multiple LIST responses for a single LIST command.
5502 The following base mailbox name attributes are defined:
5505 The "\NonExistent" attribute indicates that a mailbox name does
5506 not refer to an existing mailbox. Note that this attribute is not
5507 meaningful by itself, as mailbox names that match the canonical
5508 LIST pattern but don't exist must not be returned unless one of
5509 the two conditions listed below is also satisfied:
5511 1. The mailbox name also satisfies the selection criteria (for
5512 example, it is subscribed and the "SUBSCRIBED" selection
5513 option has been specified).
5515 2. "RECURSIVEMATCH" has been specified, and the mailbox name has
5516 at least one descendant mailbox name that does not match the
5517 LIST pattern and does match the selection criteria.
5519 In practice, this means that the "\NonExistent" attribute is
5520 usually returned with one or more of "\Subscribed", "\Remote",
5521 "\HasChildren", or the CHILDINFO extended data item.
5523 The "\NonExistent" attribute implies "\NoSelect".
5526 It is not possible for any child levels of hierarchy to exist
5527 under this name; no child levels exist now and none can be created
5531 It is not possible to use this name as a selectable mailbox.
5534 The presence of this attribute indicates that the mailbox has
5535 child mailboxes. A server SHOULD NOT set this attribute if there
5536 are child mailboxes and the user does not have permission to
5537 access any of them. In this case, \HasNoChildren SHOULD be used.
5538 In many cases, however, a server may not be able to efficiently
5539 compute whether a user has access to any child mailboxes. Note
5540 that even though the \HasChildren attribute for a mailbox must be
5541 correct at the time of processing the mailbox, a client must be
5542 prepared to deal with a situation when a mailbox is marked with
5543 the \HasChildren attribute, but no child mailbox appears in the
5544 response to the LIST command. This might happen, for example, due
5545 to child mailboxes being deleted or made inaccessible to the user
5546 (using access control) by another client before the server is able
5550 The presence of this attribute indicates that the mailbox has NO
5551 child mailboxes that are accessible to the currently authenticated
5555 The mailbox has been marked "interesting" by the server; the
5556 mailbox probably contains messages that have been added since the
5557 last time the mailbox was selected.
5560 The mailbox does not contain any additional messages since the
5561 last time the mailbox was selected.
5564 The mailbox name was subscribed to using the SUBSCRIBE command.
5567 The mailbox is a remote mailbox.
5569 It is an error for the server to return both a \HasChildren and a
5570 \HasNoChildren attribute in the same LIST response. A client that
5571 encounters a LIST response with both \HasChildren and \HasNoChildren
5572 attributes present should act as if both are absent in the LIST
5575 Note: the \HasNoChildren attribute should not be confused with the
5576 \NoInferiors attribute, which indicates that no child mailboxes
5577 exist now and none can be created in the future.
5579 If it is not feasible for the server to determine whether or not the
5580 mailbox is "interesting", the server SHOULD NOT send either \Marked
5581 or \Unmarked. The server MUST NOT send more than one of \Marked,
5582 \Unmarked, and \Noselect for a single mailbox, and it MAY send none
5585 In addition to the base mailbox name attributes defined above, an
5586 IMAP server MAY also include any or all of the following attributes
5587 that denote "role" (or "special-use") of a mailbox. These attributes
5588 are included along with base attributes defined above. A given
5589 mailbox may have none, one, or more than one of these attributes. In
5590 some cases, a special use is advice to a client about what to put in
5591 that mailbox. In other cases, it's advice to a client about what to
5592 expect to find there.
5595 This mailbox presents all messages in the user's message store.
5596 Implementations MAY omit some messages, such as, perhaps, those in
5597 \Trash and \Junk. When this special use is supported, it is
5598 almost certain to represent a virtual mailbox.
5601 This mailbox is used to archive messages. The meaning of an
5602 "archival" mailbox is server dependent; typically, it will be used
5603 to get messages out of the inbox, or otherwise keep them out of
5604 the user's way, while still making them accessible.
5607 This mailbox is used to hold draft messages -- typically, messages
5608 that are being composed but have not yet been sent. In some
5609 server implementations, this might be a virtual mailbox,
5610 containing messages from other mailboxes that are marked with the
5611 "\Draft" message flag. Alternatively, this might just be advice
5612 that a client put drafts here.
5615 This mailbox presents all messages marked in some way as
5616 "important". When this special use is supported, it is likely to
5617 represent a virtual mailbox collecting messages (from other
5618 mailboxes) that are marked with the "\Flagged" message flag.
5621 This mailbox is where messages deemed to be junk mail are held.
5622 Some server implementations might put messages here automatically.
5623 Alternatively, this might just be advice to a client-side spam
5627 This mailbox is used to hold copies of messages that have been
5628 sent. Some server implementations might put messages here
5629 automatically. Alternatively, this might just be advice that a
5630 client save sent messages here.
5633 This mailbox is used to hold messages that have been deleted or
5634 marked for deletion. In some server implementations, this might
5635 be a virtual mailbox, containing messages from other mailboxes
5636 that are marked with the "\Deleted" message flag. Alternatively,
5637 this might just be advice that a client that chooses not to use
5638 the IMAP "\Deleted" model should use as its trash location. In
5639 server implementations that strictly expect the IMAP "\Deleted"
5640 model, this special use is likely not to be supported.
5642 All special-use attributes are OPTIONAL, and any given server or
5643 message store may support any combination of the attributes, or none
5644 at all. In most cases, there will likely be at most one mailbox with
5645 a given attribute for a given user, but in some server or message
5646 store implementations, it might be possible for multiple mailboxes to
5647 have the same special-use attribute.
5649 Special-use attributes are likely to be user specific. User Adam
5650 might share his \Sent mailbox with user Barb, but that mailbox is
5651 unlikely to also serve as Barb's \Sent mailbox.
5653 Other mailbox name attributes can be found in the "IMAP Mailbox Name
5654 Attributes" registry [IMAP-MAILBOX-NAME-ATTRS-REG].
5656 The hierarchy delimiter is a character used to delimit levels of
5657 hierarchy in a mailbox name. A client can use it to create child
5658 mailboxes and to search higher or lower levels of naming hierarchy.
5659 All children of a top-level hierarchy node MUST use the same
5660 separator character. A NIL hierarchy delimiter means that no
5661 hierarchy exists; the name is a "flat" name.
5663 The name represents an unambiguous left-to-right hierarchy and MUST
5664 be valid for use as a reference in LIST command. Unless \Noselect or
5665 \NonExistent is indicated, the name MUST also be valid as an argument
5666 for commands, such as SELECT, that accept mailbox names.
5668 The name might be followed by an OPTIONAL series of extended fields,
5669 a parenthesized list of tagged data (also referred to as an "extended
5670 data item"). The first element of an extended field is a string,
5671 which identifies the type of data. [RFC5258] specifies requirements
5672 on string registration (which are called "tags"; such tags are not to
5673 be confused with IMAP command tags); in particular, it states that
5674 "Tags MUST be registered with IANA". This document doesn't change
5675 that. See Section 9.5 of [RFC5258] for the registration template.
5676 The server MAY return data in the extended fields that was not
5677 directly solicited by the client in the corresponding LIST command.
5678 For example, the client can enable extra extended fields by using
5679 another IMAP extension that makes use of the extended LIST responses.
5680 The client MUST ignore all extended fields it doesn't recognize.
5684 S: * LIST (\Noselect) "/" ~/Mail/foo
5688 S: * LIST (\Marked) ":" Tables (tablecloth (("edge" "lacy")
5689 ("color" "red")) Sample "text")
5690 S: * LIST () ":" Tables:new (tablecloth ("edge" "lacy")
5691 Sample ("text" "more text"))
56937.3.2. NAMESPACE Response
5695 Contents: the prefix and hierarchy delimiter to the server's
5696 Personal Namespace(s), Other Users' Namespace(s), and
5699 The NAMESPACE response occurs as a result of a NAMESPACE command. It
5700 contains the prefix and hierarchy delimiter to the server's Personal
5701 Namespace(s), Other Users' Namespace(s), and Shared Namespace(s) that
5702 the server wishes to expose. The response will contain a NIL for any
5703 namespace class that is not available. The Namespace-Response-
5704 Extensions ABNF non-terminal is defined for extensibility and MAY be
5705 included in the response.
5709 S: * NAMESPACE (("" "/")) (("~" "/")) NIL
57117.3.3. STATUS Response
5715 status parenthesized list
5717 The STATUS response occurs as a result of a STATUS command. It
5718 returns the mailbox name that matches the STATUS specification and
5719 the requested mailbox status information.
5723 S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
57257.3.4. ESEARCH Response
5727 Contents: one or more search-return-data pairs
5729 The ESEARCH response occurs as a result of a SEARCH or UID SEARCH
5732 The ESEARCH response starts with an optional search correlator. If
5733 it is missing, then the response was not caused by a particular IMAP
5734 command, whereas if it is present, it contains the tag of the command
5735 that caused the response to be returned.
5737 The search correlator is followed by an optional UID indicator. If
5738 this indicator is present, all data in the ESEARCH response refers to
5739 UIDs; otherwise, all returned data refers to message numbers.
5741 The rest of the ESEARCH response contains one or more search data
5742 pairs. Each pair starts with a unique return item name, followed by
5743 a space and the corresponding data. Search data pairs may be
5744 returned in any order. Unless otherwise specified by an extension,
5745 any return item name SHOULD appear only once in an ESEARCH response.
5747 This document specifies the following return item names:
5750 Returns the lowest message number/UID that satisfies the SEARCH
5753 If the SEARCH results in no matches, the server MUST NOT include
5754 the MIN return item in the ESEARCH response; however, it still
5755 MUST send the ESEARCH response.
5758 Returns the highest message number/UID that satisfies the SEARCH
5761 If the SEARCH results in no matches, the server MUST NOT include
5762 the MAX return item in the ESEARCH response; however, it still
5763 MUST send the ESEARCH response.
5766 Returns all message numbers/UIDs that satisfy the SEARCH criteria
5767 using the sequence-set syntax. Each set MUST be complete; in
5768 particular, a UID set is returned in an ESEARCH response only when
5769 each number in the range corresponds to an existing (matching)
5770 message. The client MUST NOT assume that messages/UIDs will be
5771 listed in any particular order.
5773 If the SEARCH results in no matches, the server MUST NOT include
5774 the ALL return item in the ESEARCH response; however, it still
5775 MUST send the ESEARCH response.
5778 Returns the number of messages that satisfy the SEARCH criteria.
5779 This return item MUST always be included in the ESEARCH response.
5783 S: * ESEARCH UID COUNT 17 ALL 4:18,21,28
5787 S: * ESEARCH (TAG "a567") UID COUNT 17 ALL 4:18,21,28
5791 S: * ESEARCH COUNT 18 ALL 1:17,21
57937.3.5. FLAGS Response
5795 Contents: flag parenthesized list
5797 The FLAGS response occurs as a result of a SELECT or EXAMINE command.
5798 The flag parenthesized list identifies the flags (at a minimum, the
5799 system-defined flags) that are applicable for this mailbox. Flags
5800 other than the system flags can also exist, depending on server
5803 The update from the FLAGS response MUST be remembered by the client.
5807 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
58097.4. Server Responses - Mailbox Size
5811 These responses are always untagged. This is how changes in the size
5812 of the mailbox are transmitted from the server to the client.
5813 Immediately following the "*" token is a number that represents a
58167.4.1. EXISTS Response
5820 The EXISTS response reports the number of messages in the mailbox.
5821 This response occurs as a result of a SELECT or EXAMINE command and
5822 if the size of the mailbox changes (e.g., new messages).
5824 The update from the EXISTS response MUST be remembered by the client.
58307.5. Server Responses - Message Status
5832 These responses are always untagged. This is how message data are
5833 transmitted from the server to the client, often as a result of a
5834 command with the same name. Immediately following the "*" token is a
5835 number that represents a message sequence number.
58377.5.1. EXPUNGE Response
5841 The EXPUNGE response reports that the specified message sequence
5842 number has been permanently removed from the mailbox. The message
5843 sequence number for each successive message in the mailbox is
5844 immediately decremented by 1, and this decrement is reflected in
5845 message sequence numbers in subsequent responses (including other
5846 untagged EXPUNGE responses).
5848 The EXPUNGE response also decrements the number of messages in the
5849 mailbox; it is not necessary to send an EXISTS response with the new
5852 As a result of the immediate decrement rule, message sequence numbers
5853 that appear in a set of successive EXPUNGE responses depend upon
5854 whether the messages are removed starting from lower numbers to
5855 higher numbers, or from higher numbers to lower numbers. For
5856 example, if the last 5 messages in a 9-message mailbox are expunged,
5857 a "lower to higher" server will send five untagged EXPUNGE responses
5858 for message sequence number 5, whereas a "higher to lower" server
5859 will send successive untagged EXPUNGE responses for message sequence
5860 numbers 9, 8, 7, 6, and 5.
5863 nor while responding to a FETCH, STORE, or SEARCH command. This rule
5864 is necessary to prevent a loss of synchronization of message sequence
5865 numbers between client and server. A command is not "in progress"
5866 until the complete command has been received; in particular, a
5867 command is not "in progress" during the negotiation of command
5870 Note: UID FETCH, UID STORE, and UID SEARCH are different commands
5871 from FETCH, STORE, and SEARCH. An EXPUNGE response MAY be sent
5872 during a UID command.
5874 The update from the EXPUNGE response MUST be remembered by the
58817.5.2. FETCH Response
5883 Contents: message data
5885 The FETCH response returns data about a message to the client. The
5886 data are pairs of data item names, and their values are in
5887 parentheses. This response occurs as the result of a FETCH or STORE
5888 command, as well as by a unilateral server decision (e.g., flag
5891 The current data items are:
5893 BINARY[<section-binary>]<<number>>
5894 An <nstring> or <literal8> expressing the content of the specified
5895 section after removing any encoding specified in the corresponding
5896 Content-Transfer-Encoding header field. If <number> is present,
5897 it refers to the offset within the DECODED section data.
5899 If the domain of the decoded data is "8bit" and the data does not
5900 contain the NUL octet, the server SHOULD return the data in a
5901 <string> instead of a <literal8>; this allows the client to
5902 determine if the "8bit" data contains the NUL octet without having
5903 to explicitly scan the data stream for NULs.
5905 Messaging clients and servers have been notoriously lax in their
5906 adherence to the Internet CRLF convention for terminating lines of
5907 textual data (text/* media types) in Internet protocols. When
5908 sending data in a BINARY[...] FETCH data item, servers MUST ensure
5909 that textual line-oriented sections are always transmitted using
5910 the IMAP CRLF line termination syntax, regardless of the
5911 underlying storage representation of the data on the server.
5914 Transfer-Encoding, it MUST fail the request and issue a "NO"
5915 response that contains the "UNKNOWN-CTE" response code.
5917 BINARY.SIZE[<section-binary>]
5918 The size of the section after removing any encoding specified in
5919 the corresponding Content-Transfer-Encoding header field. The
5920 value returned MUST match the size of the <nstring> or <literal8>
5921 that will be returned by the corresponding FETCH BINARY request.
5923 If the server does not know how to decode the section's Content-
5924 Transfer-Encoding, it MUST fail the request and issue a "NO"
5925 response that contains the "UNKNOWN-CTE" response code.
5928 A form of BODYSTRUCTURE without extension data.
5930 BODY[<section>]<<origin octet>>
5931 A string expressing the body contents of the specified section.
5932 The string SHOULD be interpreted by the client according to the
5933 content transfer encoding, body type, and subtype.
5935 If the origin octet is specified, this string is a substring of
5936 the entire body contents, starting at that origin octet. This
5937 means that BODY[]<0> MAY be truncated, but BODY[] is NEVER
5940 Note: The origin octet facility MUST NOT be used by a server in
5941 a FETCH response unless the client specifically requested it by
5942 means of a FETCH of a BODY[<section>]<<partial>> data item.
5944 8-bit textual data is permitted if a [CHARSET] identifier is part
5945 of the body parameter parenthesized list for this section. Note
5946 that headers (part specifiers HEADER or MIME, or the header
5947 portion of a MESSAGE/RFC822 or MESSAGE/GLOBAL part) MAY be in UTF-
5948 8. Note also that the [RFC5322] delimiting blank line between the
5949 header and the body is not affected by header-line subsetting; the
5950 blank line is always included as part of the header data, except
5951 in the case of a message that has no body and no blank line.
5953 Non-textual data such as binary data MUST be transfer encoded into
5954 a textual form, such as base64, prior to being sent to the client.
5955 To derive the original binary data, the client MUST decode the
5956 transfer-encoded string.
5959 A parenthesized list that describes the [MIME-IMB] body structure
5960 of a message. This is computed by the server by parsing the
5961 [MIME-IMB] header fields, defaulting various fields as necessary.
5963 For example, a simple text message of 48 lines and 2279 octets can
5964 have a body structure of:
5966 ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 2279 48)
5968 Multiple parts are indicated by parenthesis nesting. Instead of a
5969 body type as the first element of the parenthesized list, there is
5970 a sequence of one or more nested body structures. The second
5971 element of the parenthesized list is the multipart subtype (mixed,
5972 digest, parallel, alternative, etc.).
5974 For example, a two-part message consisting of a text and a
5975 base64-encoded text attachment can have a body structure of:
5978 (("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)
5979 ("TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" "cc.diff")
5980 "<960723163407.20117h@cac.washington.edu>" "Compiler diff"
5981 "BASE64" 4554 73) "MIXED")
5983 Extension data follows the multipart subtype. Extension data is
5984 never returned with the BODY fetch but can be returned with a
5985 BODYSTRUCTURE fetch. Extension data, if present, MUST be in the
5986 defined order. The extension data of a multipart body part are in
5987 the following order:
5989 body parameter parenthesized list
5990 A parenthesized list of attribute/value pairs (e.g., ("foo" "bar"
5991 "baz" "rag") where "bar" is the value of "foo", and "rag" is the
5992 value of "baz") as defined in [MIME-IMB]. Servers SHOULD decode
5993 parameter-value continuations and parameter-value character sets
5994 as described in [RFC2231], for example, if the message contains
5995 parameters "baz*0", "baz*1", and "baz*2", the server should decode
5996 them per [RFC2231], concatenate, and return the resulting value as
5997 a parameter "baz". Similarly, if the message contains parameters
5998 "foo*0*" and "foo*1*", the server should decode them per
5999 [RFC2231], convert to UTF-8, concatenate, and return the resulting
6000 value as a parameter "foo*".
6003 A parenthesized list, consisting of a disposition type string,
6004 followed by a parenthesized list of disposition attribute/value
6005 pairs as defined in [DISPOSITION]. Servers SHOULD decode
6006 parameter-value continuations as described in [RFC2231].
6009 A string or parenthesized list giving the body language value as
6010 defined in [LANGUAGE-TAGS].
6013 A string giving the body content URI as defined in [LOCATION].
6015 Any following extension data are not yet defined in this version
6016 of the protocol. Such extension data can consist of zero or more
6017 NILs, strings, numbers, or potentially nested parenthesized lists
6018 of such data. Client implementations that do a BODYSTRUCTURE
6019 fetch MUST be prepared to accept such extension data. Server
6020 implementations MUST NOT send such extension data until it has
6021 been defined by a revision of this protocol.
6023 The basic fields of a non-multipart body part are in the following
6027 A string giving the content media-type name as defined in
6031 A string giving the content subtype name as defined in [MIME-IMB].
6033 body parameter parenthesized list
6034 A parenthesized list of attribute/value pairs (e.g., ("foo" "bar"
6035 "baz" "rag") where "bar" is the value of "foo", and "rag" is the
6036 value of "baz") as defined in [MIME-IMB].
6039 A string giving the Content-ID header field value as defined in
6040 Section 7 of [MIME-IMB].
6043 A string giving the Content-Description header field value as
6044 defined in Section 8 of [MIME-IMB].
6047 A string giving the content transfer encoding as defined in
6048 Section 6 of [MIME-IMB].
6051 A number giving the size of the body in octets. Note that this
6052 size is the size in its transfer encoding and not the resulting
6053 size after any decoding.
6055 A body type of type MESSAGE and subtype RFC822 contains,
6056 immediately after the basic fields, the envelope structure, body
6057 structure, and size in text lines of the encapsulated message.
6059 A body type of type TEXT contains, immediately after the basic
6060 fields, the size of the body in text lines. Note that this size
6061 is the size in its content transfer encoding and not the resulting
6062 size after any decoding.
6064 Extension data follows the basic fields and the type-specific
6065 fields listed above. Extension data is never returned with the
6066 BODY fetch but can be returned with a BODYSTRUCTURE fetch.
6067 Extension data, if present, MUST be in the defined order.
6069 The extension data of a non-multipart body part are in the
6073 A string giving the body MD5 value as defined in [MD5].
6076 A parenthesized list with the same content and function as the
6077 body disposition for a multipart body part.
6080 A string or parenthesized list giving the body language value as
6081 defined in [LANGUAGE-TAGS].
6084 A string giving the body content URI as defined in [LOCATION].
6086 Any following extension data are not yet defined in this version
6087 of the protocol and would be as described above under multipart
6091 A parenthesized list that describes the envelope structure of a
6092 message. This is computed by the server by parsing the [RFC5322]
6093 header into the component parts, defaulting various fields as
6096 The fields of the envelope structure are in the following order:
6097 date, subject, from, sender, reply-to, to, cc, bcc, in-reply-to,
6098 and message-id. The date, subject, in-reply-to, and message-id
6099 fields are strings. The from, sender, reply-to, to, cc, and bcc
6100 fields are parenthesized lists of address structures.
6102 An address structure is a parenthesized list that describes an
6103 electronic mail address. The fields of an address structure are
6104 in the following order: display name, [SMTP] at-domain-list
6105 (source route and obs-route ABNF production from [RFC5322]),
6106 mailbox name (local-part ABNF production from [RFC5322]), and
6109 [RFC5322] group syntax is indicated by a special form of address
6110 structure in which the hostname field is NIL. If the mailbox name
6111 field is also NIL, this is an end-of-group marker (semicolon in
6112 RFC 822 syntax). If the mailbox name field is non-NIL, this is
6113 the start of a group marker, and the mailbox name field holds the
6116 If the Date, Subject, In-Reply-To, and Message-ID header fields
6117 are absent in the [RFC5322] header, the corresponding member of
6118 the envelope is NIL; if these header fields are present but empty,
6119 the corresponding member of the envelope is the empty string.
6121 Note: some servers may return a NIL envelope member in the
6122 "present but empty" case. Clients SHOULD treat NIL and the
6123 empty string as identical.
6125 Note: [RFC5322] requires that all messages have a valid Date
6126 header field. Therefore, for a well-formed message, the date
6127 member in the envelope cannot be NIL or the empty string.
6128 However, it can be NIL for a malformed or draft message.
6130 Note: [RFC5322] requires that the In-Reply-To and Message-ID
6131 header fields, if present, have non-empty content. Therefore,
6132 for a well-formed message, the in-reply-to and message-id
6133 members in the envelope cannot be the empty string. However,
6134 they can still be the empty string for a malformed message.
6136 If the From, To, Cc, and Bcc header fields are absent in the
6137 [RFC5322] header, or are present but empty, the corresponding
6138 member of the envelope is NIL.
6141 [RFC5322] header, or are present but empty, the server sets the
6142 corresponding member of the envelope to be the same value as the
6143 from member (the client is not expected to know how to do this).
6145 Note: [RFC5322] requires that all messages have a valid From
6146 header field. Therefore, for a well-formed message, the from,
6147 sender, and reply-to members in the envelope cannot be NIL.
6148 However, they can be NIL for a malformed or draft message.
6151 A parenthesized list of flags that are set for this message.
6154 A string representing the internal date of the message.
6157 A number expressing the size of a message, as described in
6161 A number expressing the unique identifier of the message.
6163 If the server chooses to send unsolicited FETCH responses, they MUST
6164 include UID FETCH item. Note that this is a new requirement when
6165 compared to [RFC3501].
6169 S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827 UID 447)
61717.6. Server Responses - Command Continuation Request
6173 The command continuation request response is indicated by a "+" token
6174 instead of a tag. This form of response indicates that the server is
6175 ready to accept the continuation of a command from the client. The
6176 remainder of this response is a line of text.
6178 This response is used in the AUTHENTICATE command to transmit server
6179 data to the client and request additional client data. This response
6180 is also used if an argument to any command is a synchronizing
6183 The client is not permitted to send the octets of the synchronizing
6184 literal unless the server indicates that it is expected. This
6185 permits the server to process commands and reject errors on a line-
6186 by-line basis. The remainder of the command, including the CRLF that
6187 terminates a command, follows the octets of the literal. If there
6188 are any additional command arguments, the literal octets are followed
6189 by a space and those arguments.
6194 S: + Ready for additional command text
6196 S: + Ready for additional command text
6198 S: A001 OK LOGIN completed
6199 C: A044 BLURDYBLOOP {102856}
6200 S: A044 BAD No such command as "BLURDYBLOOP"
62028. Sample IMAP4rev2 Connection
6204 The following is a transcript of an IMAP4rev2 connection on a non-TLS
6205 port. A long line in this sample is broken for editorial clarity.
6207 S: * OK [CAPABILITY STARTTLS AUTH=SCRAM-SHA-256 LOGINDISABLED
6208 IMAP4rev2] IMAP4rev2 Service Ready
6210 S: a000 OK Proceed with TLS negotiation
6212 C: A001 AUTHENTICATE SCRAM-SHA-256
6213 biwsbj11c2VyLHI9ck9wck5HZndFYmVSV2diTkVrcU8=
6214 S: + cj1yT3ByTkdmd0ViZVJXZ2JORWtxTyVodllEcFdVYTJSYVRDQWZ1eEZJbGopaE
6215 5sRiRrMCxzPVcyMlphSjBTTlk3c29Fc1VFamI2Z1E9PSxpPTQwOTY=
6216 C: Yz1iaXdzLHI9ck9wck5HZndFYmVSV2diTkVrcU8laHZZRHBXVWEyUmFUQ0FmdXhG
6217 SWxqKWhObEYkazAscD1kSHpiWmFwV0lrNGpVaE4rVXRlOXl0YWc5empmTUhnc3Ft
6219 S: + dj02cnJpVFJCaTIzV3BSUi93dHVwK21NaFVaVW4vZEI1bkxUSlJzamw5NUc0
6222 S: A001 OK SCRAM-SHA-256 authentication successful
6223 C: babc ENABLE IMAP4rev2
6224 S: * ENABLED IMAP4rev2
6225 S: babc OK Some capabilities enabled
6226 C: a002 select inbox
6228 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
6229 S: * OK [UIDVALIDITY 3857529045] UIDs valid
6230 S: * LIST () "/" INBOX ("OLDNAME" ("inbox"))
6231 S: a002 OK [READ-WRITE] SELECT completed
6232 C: a003 fetch 12 full
6233 S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE
6234 "17-Jul-1996 02:44:25 -0700" RFC822.SIZE 4286 ENVELOPE (
6235 "Wed, 17 Jul 1996 02:23:25 -0700 (PDT)"
6236 "IMAP4rev2 WG mtg summary and minutes"
6237 (("Terry Gray" NIL "gray" "cac.washington.edu"))
6238 (("Terry Gray" NIL "gray" "cac.washington.edu"))
6239 (("Terry Gray" NIL "gray" "cac.washington.edu"))
6240 ((NIL NIL "imap" "cac.washington.edu"))
6241 ((NIL NIL "minutes" "CNRI.Reston.VA.US")
6242 ("John Klensin" NIL "KLENSIN" "MIT.EDU")) NIL NIL
6243 "<B27397-0100000@cac.washington.ed>")
6244 BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT"
6246 S: a003 OK FETCH completed
6247 C: a004 fetch 12 body[header]
6248 S: * 12 FETCH (BODY[HEADER] {342}
6249 S: Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)
6250 S: From: Terry Gray <gray@cac.washington.edu>
6251 S: Subject: IMAP4rev2 WG mtg summary and minutes
6252 S: To: imap@cac.washington.edu
6253 S: cc: minutes@CNRI.Reston.VA.US, John Klensin <KLENSIN@MIT.EDU>
6254 S: Message-Id: <B27397-0100000@cac.washington.edu>
6255 S: MIME-Version: 1.0
6256 S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
6259 S: a004 OK FETCH completed
6260 C: a005 store 12 +flags \deleted
6261 S: * 12 FETCH (FLAGS (\Seen \Deleted))
6262 S: a005 OK +FLAGS completed
6264 S: * BYE IMAP4rev2 server terminating connection
6265 S: a006 OK LOGOUT completed
6269 The following syntax specification uses the Augmented Backus-Naur
6270 Form (ABNF) notation as specified in [ABNF].
6272 In the case of alternative or optional rules in which a later rule
6273 overlaps an earlier rule, the rule that is listed earlier MUST take
6274 priority. For example, "\Seen" when parsed as a flag is the \Seen
6275 flag name and not a flag-extension, even though "\Seen" can be parsed
6276 as a flag-extension. Some, but not all, instances of this rule are
6279 Note: [ABNF] rules MUST be followed strictly; in particular:
6281 1. Unless otherwise noted, all alphabetic characters are case
6282 insensitive. The use of uppercase or lowercase characters to
6283 define token strings is for editorial clarity only.
6284 Implementations MUST accept these strings in a case-insensitive
6287 2. In all cases, SP refers to exactly one space. It is NOT
6288 permitted to substitute TAB, insert additional spaces, or
6289 otherwise treat SP as being equivalent to linear whitespace
6292 3. The ASCII NUL character, %x00, MUST NOT be used anywhere, with
6293 the exception of the OCTET production.
6295 SP = <Defined in RFC 5234>
6296 CTL = <Defined in RFC 5234>
6297 CRLF = <Defined in RFC 5234>
6298 ALPHA = <Defined in RFC 5234>
6299 DIGIT = <Defined in RFC 5234>
6300 DQUOTE = <Defined in RFC 5234>
6301 OCTET = <Defined in RFC 5234>
6307 ; Holds route from [RFC5322] obs-route if
6311 ; NIL indicates [RFC5322] group syntax.
6312 ; Otherwise, holds [RFC5322] domain name
6314 addr-mailbox = nstring
6315 ; NIL indicates end of [RFC5322] group; if
6316 ; non-NIL and addr-host is NIL, holds
6317 ; [RFC5322] group name.
6318 ; Otherwise, holds [RFC5322] local-part
6319 ; after removing [RFC5322] quoting
6322 ; If non-NIL, holds phrase from [RFC5322]
6323 ; mailbox after removing [RFC5322] quoting
6328 append-uid = uniqueid
6330 astring = 1*ASTRING-CHAR / string
6332 ASTRING-CHAR = ATOM-CHAR / resp-specials
6336 ATOM-CHAR = <any CHAR except atom-specials>
6338 atom-specials = "(" / ")" / "{" / SP / CTL / list-wildcards /
6339 quoted-specials / resp-specials
6345 ; Authentication mechanism name, as defined by
6346 ; [SASL], Section 7.1
6348 base64 = *(4base64-char) [base64-terminal]
6350 base64-char = ALPHA / DIGIT / "+" / "/"
6353 base64-terminal = (2base64-char "==") / (3base64-char "=")
6357 body-extension = nstring / number / number64 /
6358 "(" body-extension *(SP body-extension) ")"
6359 ; Future expansion. Client implementations
6360 ; MUST accept body-extension fields. Server
6361 ; implementations MUST NOT generate
6362 ; body-extension fields except as defined by
6363 ; future Standard or Standards Track
6364 ; revisions of this specification.
6366 body-ext-1part = body-fld-md5 [SP body-fld-dsp [SP body-fld-lang
6367 [SP body-fld-loc *(SP body-extension)]]]
6368 ; MUST NOT be returned on non-extensible
6371 body-ext-mpart = body-fld-param [SP body-fld-dsp [SP body-fld-lang
6372 [SP body-fld-loc *(SP body-extension)]]]
6373 ; MUST NOT be returned on non-extensible
6377 body-fld-enc SP body-fld-octets
6379 body-fld-desc = nstring
6381 body-fld-dsp = "(" string SP body-fld-param ")" / nil
6383 body-fld-enc = (DQUOTE ("7BIT" / "8BIT" / "BINARY" / "BASE64"/
6384 "QUOTED-PRINTABLE") DQUOTE) / string
6385 ; Content-Transfer-Encoding header field value.
6386 ; Defaults to "7BIT" (as per RFC 2045)
6387 ; if not present in the body part.
6389 body-fld-id = nstring
6391 body-fld-lang = nstring / "(" string *(SP string) ")"
6393 body-fld-loc = nstring
6395 body-fld-lines = number64
6397 body-fld-md5 = nstring
6399 body-fld-octets = number
6408 ; MESSAGE subtype MUST NOT be "RFC822" or
6413 ; MULTIPART body part
6416 SP body SP body-fld-lines
6420 capability = ("AUTH=" auth-type) / atom
6421 ; New capabilities SHOULD be
6422 ; registered with IANA using the
6423 ; RFC Required policy, i.e., in
6424 ; a Standards Track, an Experimental,
6425 ; or an Informational RFC.
6429 ; See Section 6.1.1 for information about
6430 ; required security-related capabilities.
6431 ; Servers that offer RFC 1730 compatibility MUST
6432 ; list "IMAP4" as the first capability.
6433 ; Servers that offer RFC 3501 compatibility MUST
6434 ; list "IMAP4rev1" as one of the capabilities.
6436 CHAR = <defined in [ABNF]>
6439 ; any OCTET except NUL, %x00
6443 childinfo-extended-item = "CHILDINFO" SP "("
6444 list-select-base-opt-quoted
6445 *(SP list-select-base-opt-quoted) ")"
6446 ; Extended data item (mbox-list-extended-item)
6447 ; returned when the RECURSIVEMATCH
6448 ; selection option is specified.
6449 ; Note 1: the CHILDINFO extended data item tag can be
6450 ; returned with or without surrounding quotes, as per
6451 ; mbox-list-extended-item-tag production.
6452 ; Note 2: The selection options are always returned
6453 ; quoted, unlike their specification in
6454 ; the extended LIST command.
6456 child-mbox-flag = "\HasChildren" / "\HasNoChildren"
6457 ; attributes for the CHILDREN return option, at most
6458 ; one possible per LIST response
6460 command = tag SP (command-any / command-auth /
6461 command-nonauth / command-select) CRLF
6462 ; Modal based on state
6465 ; Valid in all states
6467 command-auth = append / create / delete / enable / examine /
6468 list / namespace-command / rename /
6469 select / status / subscribe / unsubscribe /
6471 ; Valid only in Authenticated or Selected state
6474 ; Valid only when in Not Authenticated state
6477 move / fetch / store / search / uid
6478 ; Valid only when in Selected state
6480 continue-req = "+" SP (resp-text / base64) CRLF
6485 ; Use of INBOX gives a NO error
6493 ; Fixed-format version of date-day
6496 "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"
6498 date-text = date-day "-" date-month "-" date-year
6503 SP time SP zone DQUOTE
6506 ; Use of INBOX gives a NO error
6511 eitem-standard-tag = atom
6512 ; a tag for LIST extended data item defined in a Standard
6513 ; Track or Experimental RFC.
6515 eitem-vendor-tag = vendor-token "-" atom
6516 ; a vendor-specific tag for LIST extended data item
6523 env-sender SP env-reply-to SP env-to SP env-cc SP
6524 env-bcc SP env-in-reply-to SP env-message-id ")"
6528 env-cc = "(" 1*address ")" / nil
6532 env-from = "(" 1*address ")" / nil
6534 env-in-reply-to = nstring
6536 env-message-id = nstring
6538 env-reply-to = "(" 1*address ")" / nil
6540 env-sender = "(" 1*address ")" / nil
6542 env-subject = nstring
6544 env-to = "(" 1*address ")" / nil
6547 *(SP search-return-data)
6548 ; ESEARCH response replaces SEARCH response
6554 "ALL" / "FULL" / "FAST" /
6555 fetch-att / "(" fetch-att *(SP fetch-att) ")")
6559 "BODY" ["STRUCTURE"] / "UID" /
6560 "BODY" section [partial] /
6561 "BODY.PEEK" section [partial] /
6562 "BINARY" [".PEEK"] section-binary [partial] /
6563 "BINARY.SIZE" section-binary
6566 "\Seen" / "\Draft" / flag-keyword / flag-extension
6567 ; Does not include "\Recent"
6569 flag-extension = "\" atom
6570 ; Future expansion. Client implementations
6571 ; MUST accept flag-extension flags. Server
6572 ; implementations MUST NOT generate
6573 ; flag-extension flags except as defined by
6574 ; a future Standard or Standards Track
6575 ; revisions of this specification.
6576 ; "\Recent" was defined in RFC 3501
6577 ; and is now deprecated.
6579 flag-fetch = flag / obsolete-flag-recent
6581 flag-keyword = "$MDNSent" / "$Forwarded" / "$Junk" /
6582 "$NotJunk" / "$Phishing" / atom
6586 flag-perm = flag / "\*"
6588 greeting = "*" SP (resp-cond-auth / resp-cond-bye) CRLF
6590 header-fld-name = astring
6592 header-list = "(" header-fld-name *(SP header-fld-name) ")"
6596 initial-resp = (base64 / "=")
6597 ; "initial response" defined in
6598 ; Section 4 of [SASL]
6601 mailbox SP mbox-or-pat
6602 [SP list-return-opts]
6607 list-char = ATOM-CHAR / list-wildcards / resp-specials
6609 list-return-opt = return-option
6610 ; Note that return-option is the ABNF
6611 ; non-terminal used by RFC 5258
6614 "(" [list-return-opt *(SP list-return-opt)] ")"
6615 ; list return options, e.g., CHILDREN
6617 list-select-base-opt = "SUBSCRIBED" / option-extension
6618 ; options that can be used by themselves
6620 list-select-base-opt-quoted = DQUOTE list-select-base-opt DQUOTE
6622 list-select-independent-opt = "REMOTE" / option-extension
6623 ; options that do not syntactically interact with
6626 list-select-mod-opt = "RECURSIVEMATCH" / option-extension
6627 ; options that require a list-select-base-opt
6628 ; to also be present
6630 list-select-opt = list-select-base-opt / list-select-independent-opt
6631 / list-select-mod-opt
6634 (*(list-select-opt SP) list-select-base-opt
6635 *(SP list-select-opt))
6636 / (list-select-independent-opt
6637 *(SP list-select-independent-opt))
6639 ; Any number of options may be in any order.
6641 ; list-select-base-opt must also appear.
6642 ; This allows these:
6646 ; (SUBSCRIBED REMOTE)
6647 ; (SUBSCRIBED RECURSIVEMATCH)
6648 ; (SUBSCRIBED REMOTE RECURSIVEMATCH)
6649 ; But does NOT allow these:
6651 ; (REMOTE RECURSIVEMATCH)
6653 list-wildcards = "%" / "*"
6656 ; <number64> represents the number of CHAR8s.
6657 ; A non-synchronizing literal is distinguished
6658 ; from a synchronizing literal by the presence of
6659 ; "+" before the closing "}".
6660 ; Non-synchronizing literals are not allowed when
6661 ; sent from server to the client.
6663 literal8 = "~{" number64 "}" CRLF *OCTET
6664 ; <number64> represents the number of OCTETs
6665 ; in the response string.
6669 mailbox = "INBOX" / astring
6670 ; INBOX is case insensitive. All case variants
6671 ; of INBOX (e.g., "iNbOx") MUST be interpreted as
6672 ; INBOX, not as an astring. An astring that
6673 ; consists of the case-insensitive sequence
6674 ; "I" "N" "B" "O" "X" is considered
6675 ; to be an INBOX and not an astring.
6676 ; Refer to Section 5.1 for further
6677 ; semantic details of mailbox names.
6679 mailbox-data = "FLAGS" SP flag-list / "LIST" SP mailbox-list /
6682 number SP "EXISTS" / namespace-response /
6683 obsolete-search-response /
6684 obsolete-recent-response
6685 ; obsolete-search-response and
6686 ; obsolete-recent-response can only be returned
6687 ; by servers that support both IMAPrev1
6691 (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox
6692 [SP mbox-list-extended]
6693 ; This is the list information pointed to by the ABNF
6694 ; item "mailbox-data", which is defined above
6696 mbox-list-extended = "(" [mbox-list-extended-item
6697 *(SP mbox-list-extended-item)] ")"
6702 mbox-list-extended-item-tag = astring
6703 ; The content MUST conform to either
6704 ; "eitem-vendor-tag" or "eitem-standard-tag"
6709 mbx-list-flags = *(mbx-list-oflag SP) mbx-list-sflag
6710 *(SP mbx-list-oflag) /
6711 mbx-list-oflag *(SP mbx-list-oflag)
6713 mbx-list-oflag = "\Noinferiors" / child-mbox-flag /
6714 "\Subscribed" / "\Remote" / flag-extension
6715 ; Other flags; multiple from this list are
6716 ; possible per LIST response, but each flag
6717 ; can only appear once per LIST response
6719 mbx-list-sflag = "\NonExistent" / "\Noselect" / "\Marked" /
6721 ; Selectability flags; only one per LIST response
6724 "FONT" / "MESSAGE" / "MODEL" / "VIDEO" ) DQUOTE)
6727 ; FONT defined in [RFC8081].
6728 ; MODEL defined in [RFC2077].
6729 ; Other top-level media types
6730 ; are defined in [MIME-IMT].
6733 DQUOTE ("RFC822" / "GLOBAL") DQUOTE
6734 ; Defined in [MIME-IMT]
6736 media-subtype = string
6737 ; Defined in [MIME-IMT]
6740 ; Defined in [MIME-IMT]
6747 *(SP (msg-att-dynamic / msg-att-static)) ")"
6750 ; MAY change for a message
6752 msg-att-static = "ENVELOPE" SP envelope /
6754 "RFC822.SIZE" SP number64 /
6755 "BODY" ["STRUCTURE"] SP body /
6758 "BINARY.SIZE" section-binary SP number /
6760 ; MUST NOT change for a message
6762 name-component = 1*UTF8-CHAR
6763 ; MUST NOT contain ".", "/", "%", or "*"
6770 (DQUOTE QUOTED-CHAR DQUOTE / nil)
6771 [namespace-response-extensions] ")"
6775 namespace-response-extension = SP string SP
6776 "(" string *(SP string) ")"
6779 SP namespace SP namespace
6780 ; The first Namespace is the Personal Namespace(s).
6781 ; The second Namespace is the Other Users'
6783 ; The third Namespace is the Shared Namespace(s).
6787 nstring = string / nil
6790 ; Unsigned 32-bit integer
6791 ; (0 <= n < 4,294,967,296)
6795 ; (0 <= n <= 9,223,372,036,854,775,807)
6797 nz-number = digit-nz *DIGIT
6798 ; Non-zero unsigned 32-bit integer
6799 ; (0 < n < 4,294,967,296)
6801 nz-number64 = digit-nz *DIGIT
6802 ; Unsigned 63-bit integer
6803 ; (0 < n <= 9,223,372,036,854,775,807)
6805 obsolete-flag-recent = "\Recent"
6807 obsolete-recent-response = number SP "RECENT"
6812 ; Extended data item (mbox-list-extended-item)
6813 ; returned in a LIST response when a mailbox is
6814 ; renamed or deleted. Also returned when
6815 ; the server canonicalized the provided mailbox
6817 ; Note 1: the OLDNAME tag can be returned
6818 ; with or without surrounding quotes, as per
6819 ; mbox-list-extended-item-tag production.
6824 option-standard-tag = atom
6825 ; an option defined in a Standards Track or
6828 option-val-comp = astring /
6829 option-val-comp *(SP option-val-comp) /
6830 "(" option-val-comp ")"
6832 option-value = "(" option-val-comp ")"
6834 option-vendor-tag = vendor-token "-" atom
6835 ; a vendor-specific option, non-standard
6837 partial-range = number64 ["." nz-number64]
6838 ; Copied from RFC 5092 (IMAP URL)
6839 ; and updated to support 64-bit sizes.
6842 ; Partial FETCH request. 0-based offset of
6843 ; the first octet, followed by the number of
6844 ; octets in the fragment.
6849 ; [RFC5258] supports multiple patterns,
6850 ; but this document only requires one
6852 ; If the server is also implementing
6853 ; [RFC5258], the "patterns" syntax from
6854 ; that document must be followed.
6858 QUOTED-CHAR = <any TEXT-CHAR except quoted-specials> /
6859 "\" quoted-specials / UTF8-2 / UTF8-3 / UTF8-4
6861 quoted-specials = DQUOTE / "\"
6864 ; Use of INBOX as a destination gives a NO error
6866 response = *(continue-req / response-data) response-done
6869 mailbox-data / message-data / capability-data /
6872 response-done = response-tagged / response-fatal
6874 response-fatal = "*" SP resp-cond-bye CRLF
6875 ; Server closes connection immediately
6877 response-tagged = tag SP resp-cond-state CRLF
6879 resp-code-apnd = "APPENDUID" SP nz-number SP append-uid
6883 resp-cond-auth = ("OK" / "PREAUTH") SP resp-text
6884 ; Authentication condition
6888 resp-cond-state = ("OK" / "NO" / "BAD") SP resp-text
6893 resp-text = ["[" resp-text-code "]" SP] [text]
6896 "BADCHARSET" [SP "(" charset *(SP charset) ")" ] /
6897 capability-data / "PARSE" /
6899 "(" [flag-perm *(SP flag-perm)] ")" /
6900 "READ-ONLY" / "READ-WRITE" / "TRYCREATE" /
6901 "UIDNEXT" SP nz-number /
6902 "UIDVALIDITY" SP nz-number /
6903 resp-code-apnd / resp-code-copy / "UIDNOTSTICKY" /
6904 "UNAVAILABLE" / "AUTHENTICATIONFAILED" /
6905 "AUTHORIZATIONFAILED" / "EXPIRED" /
6906 "PRIVACYREQUIRED" / "CONTACTADMIN" / "NOPERM" /
6907 "INUSE" / "EXPUNGEISSUED" / "CORRUPTION" /
6908 "SERVERBUG" / "CLIENTBUG" / "CANNOT" /
6909 "LIMIT" / "OVERQUOTA" / "ALREADYEXISTS" /
6910 "NONEXISTENT" / "NOTSAVED" / "HASCHILDREN" /
6913 atom [SP 1*<any TEXT-CHAR except "]">]
6924 "BEFORE" SP date / "BODY" SP astring /
6925 "CC" SP astring / "DELETED" / "FLAGGED" /
6926 "FROM" SP astring / "KEYWORD" SP flag-keyword /
6927 "ON" SP date / "SEEN" /
6928 "SINCE" SP date / "SUBJECT" SP astring /
6929 "TEXT" SP astring / "TO" SP astring /
6930 "UNANSWERED" / "UNDELETED" / "UNFLAGGED" /
6931 "UNKEYWORD" SP flag-keyword / "UNSEEN" /
6932 ; Above this line were in [IMAP2]
6933 "DRAFT" / "HEADER" SP header-fld-name SP astring /
6934 "LARGER" SP number64 / "NOT" SP search-key /
6935 "OR" SP search-key SP search-key /
6936 "SENTBEFORE" SP date / "SENTON" SP date /
6937 "SENTSINCE" SP date / "SMALLER" SP number64 /
6938 "UID" SP sequence-set / "UNDRAFT" / sequence-set /
6939 "(" search-key *(SP search-key) ")"
6941 search-modifier-name = tagged-ext-label
6943 search-mod-params = tagged-ext-val
6944 ; This non-terminal shows recommended syntax
6945 ; for future extensions.
6947 search-program = ["CHARSET" SP charset SP]
6948 search-key *(SP search-key)
6949 ; CHARSET argument to SEARCH MUST be
6950 ; registered with IANA.
6952 search-ret-data-ext = search-modifier-name SP search-return-value
6953 ; Note that not every SEARCH return option
6954 ; is required to have the corresponding
6955 ; ESEARCH return data.
6958 "MAX" SP nz-number /
6959 "ALL" SP sequence-set /
6962 ; All return data items conform to
6963 ; search-ret-data-ext syntax.
6964 ; Note that "$" marker is not allowed
6965 ; after the ALL return data item.
6968 *(SP search-return-opt)] ")"
6970 search-return-opt = "MIN" / "MAX" / "ALL" / "COUNT" /
6973 ; conforms to generic search-ret-opt-ext
6976 search-ret-opt-ext = search-modifier-name [SP search-mod-params]
6978 search-return-value = tagged-ext-val
6979 ; Data for the returned search option.
6980 ; A single "nz-number"/"number"/"number64" value
6981 ; can be returned as an atom (i.e., without
6982 ; quoting). A sequence-set can be returned
6983 ; as an atom as well.
6990 "HEADER.FIELDS" [".NOT"] SP header-list /
6992 ; top-level or MESSAGE/RFC822 or
6993 ; MESSAGE/GLOBAL part
6995 section-part = nz-number *("." nz-number)
6996 ; body part reference.
6997 ; Allows for accessing nested body parts.
7001 section-text = section-msgtext / "MIME"
7002 ; text other than actual body part (headers,
7007 seq-number = nz-number / "*"
7008 ; message sequence number (COPY, FETCH, STORE
7009 ; commands) or unique identifier (UID COPY,
7010 ; UID FETCH, UID STORE commands).
7011 ; * represents the largest number in use. In
7012 ; the case of message sequence numbers, it is
7013 ; the number of messages in a non-empty mailbox.
7014 ; In the case of unique identifiers, it is the
7015 ; unique identifier of the last message in the
7016 ; mailbox or, if the mailbox is empty, the
7017 ; mailbox's current UIDNEXT value.
7019 ; response to a command that uses a message
7020 ; sequence number greater than the number of
7021 ; messages in the selected mailbox. This
7022 ; includes "*" if the selected mailbox is empty.
7024 seq-range = seq-number ":" seq-number
7025 ; two seq-number values and all values between
7026 ; these two regardless of order.
7027 ; Example: 2:4 and 4:2 are equivalent and
7028 ; indicate values 2, 3, and 4.
7029 ; Example: a unique identifier sequence range of
7030 ; 3291:* includes the UID of the last message in
7031 ; the mailbox, even if that value is less than
7035 ; set of seq-number values, regardless of order.
7036 ; Servers MAY coalesce overlaps and/or execute
7037 ; the sequence in any order.
7038 ; Example: a message sequence number set of
7039 ; 2,4:7,9,12:* for a mailbox with 15 messages is
7040 ; equivalent to 2,4,5,6,7,9,12,13,14,15
7041 ; Example: a message sequence number set of
7042 ; *:4,5:7 for a mailbox with 10 messages is
7043 ; equivalent to 10,9,8,7,6,5,4,5,6,7 and MAY
7044 ; be reordered and overlap coalesced to be
7047 sequence-set =/ seq-last-command
7048 ; Allow for "result of the last command"
7051 seq-last-command = "$"
7054 "(" status-att *(SP status-att) ")"
7057 "UNSEEN" / "DELETED" / "SIZE"
7060 ("UIDNEXT" SP nz-number) /
7061 ("UIDVALIDITY" SP nz-number) /
7062 ("UNSEEN" SP number) /
7063 ("DELETED" SP number) /
7064 ("SIZE" SP number64)
7065 ; Extensions to the STATUS responses
7066 ; should extend this production.
7067 ; Extensions should use the generic
7068 ; syntax defined by tagged-ext.
7073 ; This ABNF production complies with
7074 ; <option-extension> syntax.
7078 store-att-flags = (["+" / "-"] "FLAGS" [".SILENT"]) SP
7079 (flag-list / (flag *(SP flag)))
7085 tag = 1*<any ASTRING-CHAR except "+">
7088 ; <tag> represented as <astring>
7091 ; Is a valid RFC 3501 "atom".
7093 tagged-label-fchar = ALPHA / "-" / "_" / "."
7095 tagged-label-char = tagged-label-fchar / DIGIT / ":"
7098 tagged-ext-comp *(SP tagged-ext-comp) /
7099 "(" tagged-ext-comp ")"
7100 ; Extensions that follow this general
7101 ; syntax should use nstring instead of
7102 ; astring when appropriate in the context
7104 ; Note that a message set or a "number"
7105 ; can always be represented as an "atom".
7106 ; A URL should be represented as
7107 ; a "quoted" string.
7109 tagged-ext-simple = sequence-set / number / number64
7112 "(" [tagged-ext-comp] ")"
7114 text = 1*(TEXT-CHAR / UTF8-2 / UTF8-3 / UTF8-4)
7115 ; Non-ASCII text can only be returned
7116 ; after ENABLE IMAP4rev2 command
7118 TEXT-CHAR = <any CHAR except CR and LF>
7121 ; Hours minutes seconds
7124 (copy / move / fetch / search / store /
7126 ; Unique identifiers used instead of message
7130 ; Unique identifiers used instead of message
7135 uid-range = (uniqueid ":" uniqueid)
7136 ; two uniqueid values and all values
7137 ; between these two regardless of order.
7138 ; Example: 2:4 and 4:2 are equivalent.
7140 uniqueid = nz-number
7141 ; Strictly ascending
7147 UTF8-CHAR = <Defined in Section 4 of RFC 3629>
7149 UTF8-2 = <Defined in Section 4 of RFC 3629>
7151 UTF8-3 = <Defined in Section 4 of RFC 3629>
7153 UTF8-4 = <Defined in Section 4 of RFC 3629>
7155 vendor-token = "vendor." name-component
7156 ; Definition copied from RFC 2244.
7157 ; MUST be registered with IANA
7160 ; Signed four-digit value of hhmm representing
7161 ; hours and minutes east of Greenwich (that is,
7162 ; the amount that the given time differs from
7163 ; Universal Time). Subtracting the timezone
7164 ; from the given time will give the UT form.
7165 ; The Universal Time zone is "+0000".
7169 This document is a revision or rewrite of earlier documents and
7170 supercedes the protocol specification in those documents: [RFC3501],
7171 [RFC2060], [RFC1730], unpublished IMAP2bis.TXT document, [IMAP2], and
717411. Security Considerations
7176 IMAP4rev2 protocol transactions, including electronic mail data, are
7177 sent in the clear over the network, exposing them to possible
7178 eavesdropping and manipulation unless protection is negotiated. This
7179 can be accomplished by use of the Implicit TLS port, the STARTTLS
7180 command, negotiated confidentiality protection in the AUTHENTICATE
7181 command, or some other protection mechanism.
718311.1. TLS-Related Security Considerations
7185 This section applies to use of both the STARTTLS command and the
7188 IMAP client and server implementations MUST comply with relevant TLS
7189 recommendations from [RFC8314]. If recommendations/requirements in
7190 this document conflict with recommendations from [RFC8314], for
7191 example in regards to TLS ciphersuites, recommendations from this
7192 document take precedence.
7194 Clients and servers MUST implement TLS 1.2 [TLS-1.2] or newer. Use
7195 of TLS 1.3 [TLS-1.3] is RECOMMENDED. TLS 1.2 may be used only in
7196 cases where the other party has not yet implemented TLS 1.3.
7197 Additionally, when using TLS 1.2, IMAP implementations MUST implement
7198 the TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite. This is
7199 important as it ensures that any two compliant implementations can be
7200 configured to interoperate. Other TLS cipher suites recommended in
7201 RFC 7525 [RFC7525] are RECOMMENDED:
7202 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
7203 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, and
7204 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. All other cipher suites are
7205 OPTIONAL. Note that this is a change from Section 2.1 of [IMAP-TLS].
7207 The list of mandatory-to-implement TLS 1.3 cipher suites is described
7208 in Section 9.1 of [TLS-1.3].
7210 During the TLS negotiation [TLS-1.3] [TLS-1.2], the client MUST check
7211 its understanding of the server hostname against the server's
7212 identity as presented in the server Certificate message, in order to
7213 prevent on-path attackers attempting to masquerade as the server.
7214 This procedure is described in [RFC7817].
7216 Both the client and server MUST check the result of the STARTTLS
7217 command and subsequent TLS [TLS-1.3] [TLS-1.2] negotiation to see
7218 whether acceptable authentication and/or privacy was achieved.
722011.2. STARTTLS Command versus Use of Implicit TLS Port
7222 For maximum backward compatibility, the client MUST implement both
7223 TLS negotiation on an Implicit TLS port and TLS negotiation using the
7224 STARTTLS command on a cleartext port.
7226 The server MUST implement TLS negotiation on an Implicit TLS port.
7227 The server SHOULD also implement IMAP on a cleartext port. If the
7228 server listens on a cleartext port, it MUST allow the STARTTLS
7231 Some site/firewall maintainers insist on TLS site-wide and prefer not
7232 to rely on a configuration option in each higher-level protocol. For
7233 this reason, IMAP4rev2 clients SHOULD try both ports 993 and 143 (and
7234 both IPv4 and IPv6) concurrently by default, unless overridden by
7235 either user configuration or DNS SRV records [RFC6186]. A good
7236 algorithm for implementing such concurrent connect is described in
723911.3. Client Handling of Unsolicited Responses Not Suitable for the
7240 Current Connection State
7242 Cleartext mail transmission (whether caused by firewall configuration
7243 errors that result in TLS stripping or weak security policies in
7244 email clients that choose not to negotiate TLS in the first place)
7245 can enable injection of responses that can confuse or even cause
7246 crashes in email clients. The following measures are recommended to
7247 minimize damage from them.
7249 * See Section 7.1.4 for special security considerations related to
7250 the PREAUTH response.
7252 * Many server responses and response codes are only meaningful in
7253 authenticated or even selected state. However, nothing prevents a
7254 server (or an on-path attacker) from sending such invalid
7255 responses in cleartext before STARTTLS/AUTHENTICATE commands are
7256 issued. Before authentication, clients SHOULD ignore any
7257 responses other than CAPABILITY and server status responses
7258 (Section 7.1), as well as any response codes other than
7259 CAPABILITY. (In particular, some email clients are known to
7260 incorrectly process LIST responses received before authentication,
7261 or FETCH responses when no mailbox is selected.) Clients SHOULD
7262 ignore the ALERT response code until after TLS (whether using
7263 STARTTLS or TLS negotiation on an Implicit TLS port) or a SASL
7264 security layer with confidentiality protection has been
7265 successfully negotiated. Unless explicitly allowed by an IMAP
7266 extension, when not in selected state, clients MUST ignore
7267 responses / response codes related to message and mailbox status
7268 such as FLAGS, EXIST, EXPUNGE, and FETCH.
727011.4. COPYUID and APPENDUID Response Codes
7272 The COPYUID and APPENDUID response codes return information about the
7273 mailbox, which may be considered sensitive if the mailbox has
7274 permissions set that permit the client to COPY or APPEND to the
7275 mailbox, but not SELECT or EXAMINE it.
7277 Consequently, these response codes SHOULD NOT be issued if the client
7278 does not have access to SELECT or EXAMINE the mailbox.
728011.5. LIST Command and Other Users' Namespace
7282 In response to a LIST command containing an argument of the Other
7283 Users' Namespace prefix, a server MUST NOT list users that have not
7284 granted list access to their personal mailboxes to the currently
7285 authenticated user. Providing such a list could compromise security
7286 by potentially disclosing confidential information of who is located
7287 on the server or providing a starting point for a list of user
7292 The BODYSTRUCTURE FETCH data item can contain the MD5 digest of the
7293 message body in the "body MD5" field (body-fld-md5 ABNF production).
7294 While MD5 is no longer considered a secure cryptographic hash
7295 [RFC6151], this field is used solely to expose the value of the
7296 Content-MD5 header field (if present in the original message), which
7297 is just a message integrity check and is not used for cryptographic
7298 purposes. Also note that other mechanisms that provide message
7299 integrity checks were defined since RFC 1864 [MD5] was published and
7300 are now more commonly used than Content-MD5. Two such mechanisms are
7301 the DKIM-Signature header field [RFC6376] and S/MIME signing
7302 [RFC8550] [RFC8551].
730411.7. Other Security Considerations
7306 A server error message for an AUTHENTICATE command that fails due to
7307 invalid credentials SHOULD NOT detail why the credentials are
7310 Use of the LOGIN command sends passwords in the clear. This can be
7311 avoided by using the AUTHENTICATE command with a [SASL] mechanism
7312 that does not use plaintext passwords, by first negotiating
7313 encryption via STARTTLS or some other protection mechanism.
7315 A server implementation MUST implement a configuration that, at the
7316 time of authentication, requires:
7318 1. The STARTTLS command has been negotiated or TLS negotiated on an
7321 2. Some other mechanism that protects the session from password
7322 snooping has been provided
7324 3. The following measures are in place:
7325 a) The LOGINDISABLED capability is advertised, and [SASL]
7326 mechanisms (such as PLAIN) using plaintext passwords are NOT
7327 advertised in the CAPABILITY list.
7329 b) The LOGIN command returns an error even if the password is
7332 c) The AUTHENTICATE command returns an error with all [SASL]
7333 mechanisms that use plaintext passwords, even if the password
7336 A server error message for a failing LOGIN command SHOULD NOT specify
7337 that the user name, as opposed to the password, is invalid.
7339 A server SHOULD have mechanisms in place to limit or delay failed
7340 AUTHENTICATE/LOGIN attempts.
7342 A server SHOULD report any authentication failure and analyze such
7343 authentication failure attempts with regard to a password brute-force
7344 attack as well as a password spraying attack [NCSC]. Accounts with
7345 passwords that match well-known passwords from spraying attacks MUST
7346 be blocked, and users associated with such accounts must be requested
7347 to change their passwords. Only a password with significant strength
7350 Additional security considerations are discussed in the sections that
7351 define the AUTHENTICATE and LOGIN commands (see Sections 6.2.2 and
7352 6.2.3, respectively).
735412. IANA Considerations
7356 IANA has updated the "Service Names and Transport Protocol Port
7357 Numbers" registry as follows:
7359 1. Registration for TCP port 143 and the corresponding "imap"
7360 service name have been updated to point to this document and
7363 2. Registration for TCP port 993 and the corresponding "imaps"
7364 service name have been updated to point to this document,
7365 [RFC8314], and [RFC3501].
7367 3. UDP ports 143 and 993 have both been marked as "Reserved" in the
7370 Additional IANA actions are specified in the subsections that follow.
737212.1. Updates to IMAP Capabilities Registry
7374 IMAP4 capabilities are registered by publishing a Standards Track or
7375 IESG-approved Informational or Experimental RFC. The registry is
7376 currently located at: <https://www.iana.org/assignments/
7379 As this specification revises the AUTH= prefix, STARTTLS, and
7380 LOGINDISABLED extensions, IANA has updated registry entries for these
7381 3 extensions to point to this document and [RFC3501].
738312.2. GSSAPI/SASL Service Name
7385 GSSAPI/Kerberos/SASL service names are registered by publishing a
7386 Standards Track or IESG-approved Experimental RFC. The registry is
7387 currently located at: <https://www.iana.org/assignments/gssapi-
7390 IANA has updated the "imap" service name previously registered in
7391 [RFC3501] to point to both this document and [RFC3501].
739312.3. LIST Selection Options, LIST Return Options, and LIST Extended
7396 [RFC5258] specifies IANA registration procedures for LIST selection
7397 options, LIST return options, and LIST extended data items. This
7398 document doesn't change these registration procedures. In
7399 particular, LIST selection options (Section 6.3.9.1) and LIST return
7400 options (Section 6.3.9.2) are registered using the procedure
7401 specified in Section 9 of [RFC5258] (and using the registration
7402 template from Section 9.3 of [RFC5258]). LIST extended data items
7403 are registered using the registration template from Section 9.6 of
7406 IANA has added a reference to RFC 9051 for the "OLDNAME" LIST-
7407 EXTENDED extended data item entry. This is in addition to the
7408 existing reference to [RFC5465].
741012.4. IMAP Mailbox Name Attributes and IMAP Response Codes
7412 IANA has updated the "IMAP Mailbox Name Attributes" registry to point
7413 to this document in addition to [RFC3501].
7415 IANA has updated the "IMAP Response Codes" registry to point to this
7416 document in addition to [RFC3501].
742013.1. Normative References
7422 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
7423 Specifications: ABNF", STD 68, RFC 5234,
7424 DOI 10.17487/RFC5234, January 2008,
7425 <https://www.rfc-editor.org/info/rfc5234>.
7427 [BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham,
7428 "Deprecating the "X-" Prefix and Similar Constructs in
7429 Application Protocols", BCP 178, RFC 6648, June 2012.
7431 <https://www.rfc-editor.org/info/bcp178>
7433 [CHARSET] Freed, N. and J. Postel, "IANA Charset Registration
7434 Procedures", BCP 19, RFC 2978, DOI 10.17487/RFC2978,
7435 October 2000, <https://www.rfc-editor.org/info/rfc2978>.
7438 Troost, R., Dorner, S., and K. Moore, Ed., "Communicating
7439 Presentation Information in Internet Messages: The
7440 Content-Disposition Header Field", RFC 2183,
7441 DOI 10.17487/RFC2183, August 1997,
7442 <https://www.rfc-editor.org/info/rfc2183>.
7445 Yang, A., Steele, S., and N. Freed, "Internationalized
7446 Email Headers", RFC 6532, DOI 10.17487/RFC6532, February
7447 2012, <https://www.rfc-editor.org/info/rfc6532>.
7449 [IMAP-IMPLEMENTATION]
7450 Leiba, B., "IMAP4 Implementation Recommendations",
7451 RFC 2683, DOI 10.17487/RFC2683, September 1999,
7452 <https://www.rfc-editor.org/info/rfc2683>.
7455 Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice",
7456 RFC 2180, DOI 10.17487/RFC2180, July 1997,
7457 <https://www.rfc-editor.org/info/rfc2180>.
7460 Alvestrand, H., "Content Language Headers", RFC 3282,
7461 DOI 10.17487/RFC3282, May 2002,
7462 <https://www.rfc-editor.org/info/rfc3282>.
7464 [LOCATION] Palme, J., Hopmann, A., and N. Shelness, "MIME
7465 Encapsulation of Aggregate Documents, such as HTML
7466 (MHTML)", RFC 2557, DOI 10.17487/RFC2557, March 1999,
7467 <https://www.rfc-editor.org/info/rfc2557>.
7469 [MD5] Myers, J. and M. Rose, "The Content-MD5 Header Field",
7470 RFC 1864, DOI 10.17487/RFC1864, October 1995,
7471 <https://www.rfc-editor.org/info/rfc1864>.
7474 Moore, K., "MIME (Multipurpose Internet Mail Extensions)
7475 Part Three: Message Header Extensions for Non-ASCII Text",
7476 RFC 2047, DOI 10.17487/RFC2047, November 1996,
7477 <https://www.rfc-editor.org/info/rfc2047>.
7479 [MIME-IMB] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
7480 Extensions (MIME) Part One: Format of Internet Message
7481 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
7482 <https://www.rfc-editor.org/info/rfc2045>.
7484 [MIME-IMT] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
7485 Extensions (MIME) Part Two: Media Types", RFC 2046,
7486 DOI 10.17487/RFC2046, November 1996,
7487 <https://www.rfc-editor.org/info/rfc2046>.
7490 Crispin, M., "Internet Message Access Protocol (IMAP) -
7491 MULTIAPPEND Extension", RFC 3502, DOI 10.17487/RFC3502,
7492 March 2003, <https://www.rfc-editor.org/info/rfc3502>.
7495 Klensin, J. and M. Padlipsky, "Unicode Format for Network
7496 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008,
7497 <https://www.rfc-editor.org/info/rfc5198>.
7499 [PLAIN] Zeilenga, K., Ed., "The PLAIN Simple Authentication and
7500 Security Layer (SASL) Mechanism", RFC 4616,
7501 DOI 10.17487/RFC4616, August 2006,
7502 <https://www.rfc-editor.org/info/rfc4616>.
7504 [RFC2077] Nelson, S., Parks, C., and , "The Model Primary Content
7505 Type for Multipurpose Internet Mail Extensions", RFC 2077,
7506 DOI 10.17487/RFC2077, January 1997,
7507 <https://www.rfc-editor.org/info/rfc2077>.
7509 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
7510 Requirement Levels", BCP 14, RFC 2119,
7511 DOI 10.17487/RFC2119, March 1997,
7512 <https://www.rfc-editor.org/info/rfc2119>.
7514 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
7515 Word Extensions: Character Sets, Languages, and
7516 Continuations", RFC 2231, DOI 10.17487/RFC2231, November
7517 1997, <https://www.rfc-editor.org/info/rfc2231>.
7519 [RFC3503] Melnikov, A., "Message Disposition Notification (MDN)
7520 profile for Internet Message Access Protocol (IMAP)",
7521 RFC 3503, DOI 10.17487/RFC3503, March 2003,
7522 <https://www.rfc-editor.org/info/rfc3503>.
7524 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
7525 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
7526 <https://www.rfc-editor.org/info/rfc4648>.
7528 [RFC4752] Melnikov, A., Ed., "The Kerberos V5 ("GSSAPI") Simple
7529 Authentication and Security Layer (SASL) Mechanism",
7530 RFC 4752, DOI 10.17487/RFC4752, November 2006,
7531 <https://www.rfc-editor.org/info/rfc4752>.
7533 [RFC5258] Leiba, B. and A. Melnikov, "Internet Message Access
7534 Protocol version 4 - LIST Command Extensions", RFC 5258,
7535 DOI 10.17487/RFC5258, June 2008,
7536 <https://www.rfc-editor.org/info/rfc5258>.
7538 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
7539 DOI 10.17487/RFC5322, October 2008,
7540 <https://www.rfc-editor.org/info/rfc5322>.
7542 [RFC5788] Melnikov, A. and D. Cridland, "IMAP4 Keyword Registry",
7543 RFC 5788, DOI 10.17487/RFC5788, March 2010,
7544 <https://www.rfc-editor.org/info/rfc5788>.
7546 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
7547 "Recommendations for Secure Use of Transport Layer
7548 Security (TLS) and Datagram Transport Layer Security
7549 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
7550 2015, <https://www.rfc-editor.org/info/rfc7525>.
7552 [RFC7817] Melnikov, A., "Updated Transport Layer Security (TLS)
7553 Server Identity Check Procedure for Email-Related
7554 Protocols", RFC 7817, DOI 10.17487/RFC7817, March 2016,
7555 <https://www.rfc-editor.org/info/rfc7817>.
7557 [RFC8081] Lilley, C., "The "font" Top-Level Media Type", RFC 8081,
7558 DOI 10.17487/RFC8081, February 2017,
7559 <https://www.rfc-editor.org/info/rfc8081>.
7561 [RFC8098] Hansen, T., Ed. and A. Melnikov, Ed., "Message Disposition
7562 Notification", STD 85, RFC 8098, DOI 10.17487/RFC8098,
7563 February 2017, <https://www.rfc-editor.org/info/rfc8098>.
7565 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
7566 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
7567 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
7569 [RFC8314] Moore, K. and C. Newman, "Cleartext Considered Obsolete:
7570 Use of Transport Layer Security (TLS) for Email Submission
7571 and Access", RFC 8314, DOI 10.17487/RFC8314, January 2018,
7572 <https://www.rfc-editor.org/info/rfc8314>.
7574 [SASL] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
7575 Authentication and Security Layer (SASL)", RFC 4422,
7576 DOI 10.17487/RFC4422, June 2006,
7577 <https://www.rfc-editor.org/info/rfc4422>.
7580 Hansen, T., "SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple
7581 Authentication and Security Layer (SASL) Mechanisms",
7582 RFC 7677, DOI 10.17487/RFC7677, November 2015,
7583 <https://www.rfc-editor.org/info/rfc7677>.
7585 [TLS-1.2] Dierks, T. and E. Rescorla, "The Transport Layer Security
7586 (TLS) Protocol Version 1.2", RFC 5246,
7587 DOI 10.17487/RFC5246, August 2008,
7588 <https://www.rfc-editor.org/info/rfc5246>.
7590 [TLS-1.3] Rescorla, E., "The Transport Layer Security (TLS) Protocol
7591 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
7592 <https://www.rfc-editor.org/info/rfc8446>.
7594 [UTF-7] Goldsmith, D. and M. Davis, "UTF-7 A Mail-Safe
7595 Transformation Format of Unicode", RFC 2152,
7596 DOI 10.17487/RFC2152, May 1997,
7597 <https://www.rfc-editor.org/info/rfc2152>.
7599 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
7600 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
7601 2003, <https://www.rfc-editor.org/info/rfc3629>.
760313.2. Informative References
760513.2.1. Related Protocols
7608 Zeilenga, K., "Anonymous Simple Authentication and
7609 Security Layer (SASL) Mechanism", RFC 4505,
7610 DOI 10.17487/RFC4505, June 2006,
7611 <https://www.rfc-editor.org/info/rfc4505>.
7614 Carnegie Mellon University, "STARTTLS plaintext command
7615 injection vulnerability", Software Engineering Institute,
7616 CERT Coordination Center, Vulnerability Note VU#555316,
7617 September 2011, <https://www.kb.cert.org/vuls/id/555316>.
7620 IANA, "Character Set Registrations",
7621 <https://www.iana.org/assignments/charset-reg/>.
7624 Melnikov, A., Ed., "Synchronization Operations for
7625 Disconnected IMAP4 Clients", RFC 4549,
7626 DOI 10.17487/RFC4549, June 2006,
7627 <https://www.rfc-editor.org/info/rfc4549>.
7630 Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet
7631 Message Access Protocol Internationalization", RFC 5255,
7632 DOI 10.17487/RFC5255, June 2008,
7633 <https://www.rfc-editor.org/info/rfc5255>.
7636 IANA, "IMAP and JMAP Keywords",
7637 <https://www.iana.org/assignments/imap-jmap-keywords/>.
7639 [IMAP-MAILBOX-NAME-ATTRS-REG]
7640 IANA, "IMAP Mailbox Name Attributes",
7641 <https://www.iana.org/assignments/imap-mailbox-name-
7645 Crispin, M., "Distributed Electronic Mail Models in
7646 IMAP4", RFC 1733, DOI 10.17487/RFC1733, December 1994,
7647 <https://www.rfc-editor.org/info/rfc1733>.
7649 [IMAP-URL] Melnikov, A., Ed. and C. Newman, "IMAP URL Scheme",
7650 RFC 5092, DOI 10.17487/RFC5092, November 2007,
7651 <https://www.rfc-editor.org/info/rfc5092>.
7654 Resnick, P., Ed., Newman, C., Ed., and S. Shen, Ed., "IMAP
7655 Support for UTF-8", RFC 6855, DOI 10.17487/RFC6855, March
7656 2013, <https://www.rfc-editor.org/info/rfc6855>.
7658 [NCSC] NCSC, "Spray you, spray me: defending against password
7659 spraying attacks", May 2018, <https://www.ncsc.gov.uk/
7660 blog-post/spray-you-spray-me-defending-against-password-
7663 [RFC2087] Myers, J., "IMAP4 QUOTA extension", RFC 2087,
7664 DOI 10.17487/RFC2087, January 1997,
7665 <https://www.rfc-editor.org/info/rfc2087>.
7667 [RFC2177] Leiba, B., "IMAP4 IDLE command", RFC 2177,
7668 DOI 10.17487/RFC2177, June 1997,
7669 <https://www.rfc-editor.org/info/rfc2177>.
7671 [RFC2193] Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193,
7672 DOI 10.17487/RFC2193, September 1997,
7673 <https://www.rfc-editor.org/info/rfc2193>.
7675 [RFC2342] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342,
7676 DOI 10.17487/RFC2342, May 1998,
7677 <https://www.rfc-editor.org/info/rfc2342>.
7679 [RFC3348] Gahrns, M. and R. Cheng, "The Internet Message Action
7680 Protocol (IMAP4) Child Mailbox Extension", RFC 3348,
7681 DOI 10.17487/RFC3348, July 2002,
7682 <https://www.rfc-editor.org/info/rfc3348>.
7684 [RFC3516] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516,
7685 DOI 10.17487/RFC3516, April 2003,
7686 <https://www.rfc-editor.org/info/rfc3516>.
7688 [RFC3691] Melnikov, A., "Internet Message Access Protocol (IMAP)
7689 UNSELECT command", RFC 3691, DOI 10.17487/RFC3691,
7690 February 2004, <https://www.rfc-editor.org/info/rfc3691>.
7692 [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
7693 RFC 4314, DOI 10.17487/RFC4314, December 2005,
7694 <https://www.rfc-editor.org/info/rfc4314>.
7696 [RFC4315] Crispin, M., "Internet Message Access Protocol (IMAP) -
7697 UIDPLUS extension", RFC 4315, DOI 10.17487/RFC4315,
7698 December 2005, <https://www.rfc-editor.org/info/rfc4315>.
7700 [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
7701 ABNF", RFC 4466, DOI 10.17487/RFC4466, April 2006,
7702 <https://www.rfc-editor.org/info/rfc4466>.
7704 [RFC4731] Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH
7705 Command for Controlling What Kind of Information Is
7706 Returned", RFC 4731, DOI 10.17487/RFC4731, November 2006,
7707 <https://www.rfc-editor.org/info/rfc4731>.
7709 [RFC4959] Siemborski, R. and A. Gulbrandsen, "IMAP Extension for
7710 Simple Authentication and Security Layer (SASL) Initial
7711 Client Response", RFC 4959, DOI 10.17487/RFC4959,
7712 September 2007, <https://www.rfc-editor.org/info/rfc4959>.
7714 [RFC5161] Gulbrandsen, A., Ed. and A. Melnikov, Ed., "The IMAP
7715 ENABLE Extension", RFC 5161, DOI 10.17487/RFC5161, March
7716 2008, <https://www.rfc-editor.org/info/rfc5161>.
7718 [RFC5182] Melnikov, A., "IMAP Extension for Referencing the Last
7719 SEARCH Result", RFC 5182, DOI 10.17487/RFC5182, March
7720 2008, <https://www.rfc-editor.org/info/rfc5182>.
7722 [RFC5256] Crispin, M. and K. Murchison, "Internet Message Access
7723 Protocol - SORT and THREAD Extensions", RFC 5256,
7724 DOI 10.17487/RFC5256, June 2008,
7725 <https://www.rfc-editor.org/info/rfc5256>.
7727 [RFC5465] Gulbrandsen, A., King, C., and A. Melnikov, "The IMAP
7728 NOTIFY Extension", RFC 5465, DOI 10.17487/RFC5465,
7729 February 2009, <https://www.rfc-editor.org/info/rfc5465>.
7731 [RFC5530] Gulbrandsen, A., "IMAP Response Codes", RFC 5530,
7732 DOI 10.17487/RFC5530, May 2009,
7733 <https://www.rfc-editor.org/info/rfc5530>.
7735 [RFC5819] Melnikov, A. and T. Sirainen, "IMAP4 Extension for
7736 Returning STATUS Information in Extended LIST", RFC 5819,
7737 DOI 10.17487/RFC5819, March 2010,
7738 <https://www.rfc-editor.org/info/rfc5819>.
7740 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
7741 for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
7742 RFC 6151, DOI 10.17487/RFC6151, March 2011,
7743 <https://www.rfc-editor.org/info/rfc6151>.
7745 [RFC6154] Leiba, B. and J. Nicolson, "IMAP LIST Extension for
7746 Special-Use Mailboxes", RFC 6154, DOI 10.17487/RFC6154,
7747 March 2011, <https://www.rfc-editor.org/info/rfc6154>.
7749 [RFC6186] Daboo, C., "Use of SRV Records for Locating Email
7750 Submission/Access Services", RFC 6186,
7751 DOI 10.17487/RFC6186, March 2011,
7752 <https://www.rfc-editor.org/info/rfc6186>.
7754 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
7755 "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
7756 RFC 6376, DOI 10.17487/RFC6376, September 2011,
7757 <https://www.rfc-editor.org/info/rfc6376>.
7759 [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",
7760 STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011,
7761 <https://www.rfc-editor.org/info/rfc6409>.
7763 [RFC6851] Gulbrandsen, A. and N. Freed, Ed., "Internet Message
7764 Access Protocol (IMAP) - MOVE Extension", RFC 6851,
7765 DOI 10.17487/RFC6851, January 2013,
7766 <https://www.rfc-editor.org/info/rfc6851>.
7768 [RFC7162] Melnikov, A. and D. Cridland, "IMAP Extensions: Quick Flag
7769 Changes Resynchronization (CONDSTORE) and Quick Mailbox
7770 Resynchronization (QRESYNC)", RFC 7162,
7771 DOI 10.17487/RFC7162, May 2014,
7772 <https://www.rfc-editor.org/info/rfc7162>.
7774 [RFC7888] Melnikov, A., Ed., "IMAP4 Non-synchronizing Literals",
7775 RFC 7888, DOI 10.17487/RFC7888, May 2016,
7776 <https://www.rfc-editor.org/info/rfc7888>.
7778 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
7779 Writing an IANA Considerations Section in RFCs", BCP 26,
7780 RFC 8126, DOI 10.17487/RFC8126, June 2017,
7781 <https://www.rfc-editor.org/info/rfc8126>.
7783 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
7784 Better Connectivity Using Concurrency", RFC 8305,
7785 DOI 10.17487/RFC8305, December 2017,
7786 <https://www.rfc-editor.org/info/rfc8305>.
7788 [RFC8438] Bosch, S., "IMAP Extension for STATUS=SIZE", RFC 8438,
7789 DOI 10.17487/RFC8438, August 2018,
7790 <https://www.rfc-editor.org/info/rfc8438>.
7792 [RFC8474] Gondwana, B., Ed., "IMAP Extension for Object
7793 Identifiers", RFC 8474, DOI 10.17487/RFC8474, September
7794 2018, <https://www.rfc-editor.org/info/rfc8474>.
7796 [RFC8550] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
7797 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
7798 Certificate Handling", RFC 8550, DOI 10.17487/RFC8550,
7799 April 2019, <https://www.rfc-editor.org/info/rfc8550>.
7801 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
7802 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
7803 Message Specification", RFC 8551, DOI 10.17487/RFC8551,
7804 April 2019, <https://www.rfc-editor.org/info/rfc8551>.
7806 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
7807 DOI 10.17487/RFC5321, October 2008,
7808 <https://www.rfc-editor.org/info/rfc5321>.
781013.2.2. Historical Aspects of IMAP and Related Protocols
7813 Crispin, M., "IMAP4 Compatibility with IMAP2bis",
7814 RFC 2061, DOI 10.17487/RFC2061, December 1996,
7815 <https://www.rfc-editor.org/info/rfc2061>.
7818 Crispin, M., "IMAP4 Compatibility with IMAP2 and
7819 IMAP2bis", RFC 1732, DOI 10.17487/RFC1732, December 1994,
7820 <https://www.rfc-editor.org/info/rfc1732>.
7823 Crispin, M., "Internet Message Access Protocol - Obsolete
7824 Syntax", RFC 2062, DOI 10.17487/RFC2062, December 1996,
7825 <https://www.rfc-editor.org/info/rfc2062>.
7827 [IMAP-TLS] Newman, C., "Using TLS with IMAP, POP3 and ACAP",
7828 RFC 2595, DOI 10.17487/RFC2595, June 1999,
7829 <https://www.rfc-editor.org/info/rfc2595>.
7831 [IMAP2] Crispin, M., "Interactive Mail Access Protocol: Version
7832 2", RFC 1176, DOI 10.17487/RFC1176, August 1990,
7833 <https://www.rfc-editor.org/info/rfc1176>.
7835 [IMAP2BIS] Crispin, M., "INTERACTIVE MAIL ACCESS PROTOCOL - VERSION
7836 2bis", Work in Progress, Internet-Draft, draft-ietf-imap-
7837 imap2bis-02, 29 October 1993,
7838 <https://datatracker.ietf.org/doc/html/draft-ietf-imap-
7841 [RFC1064] Crispin, M., "Interactive Mail Access Protocol: Version
7842 2", RFC 1064, DOI 10.17487/RFC1064, July 1988,
7843 <https://www.rfc-editor.org/info/rfc1064>.
7845 [RFC1730] Crispin, M., "Internet Message Access Protocol - Version
7846 4", RFC 1730, DOI 10.17487/RFC1730, December 1994,
7847 <https://www.rfc-editor.org/info/rfc1730>.
7849 [RFC2060] Crispin, M., "Internet Message Access Protocol - Version
7850 4rev1", RFC 2060, DOI 10.17487/RFC2060, December 1996,
7851 <https://www.rfc-editor.org/info/rfc2060>.
7853 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
7854 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
7855 <https://www.rfc-editor.org/info/rfc3501>.
7857 [RFC822] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET
7858 TEXT MESSAGES", STD 11, RFC 822, DOI 10.17487/RFC0822,
7859 August 1982, <https://www.rfc-editor.org/info/rfc822>.
7861Appendix A. Backward Compatibility with IMAP4rev1
7863 An implementation that wants to remain compatible with IMAP4rev1 can
7864 advertise both IMAP4rev1 and IMAP4rev2 in its CAPABILITY response /
7865 response code. (Such server implementation is likely to also want to
7866 advertise other IMAP4rev1 extensions that were folded into IMAP4rev2;
7867 see Appendix E.) While some IMAP4rev1 responses were removed in
7868 IMAP4rev2, their presence will not break IMAP4rev2-only clients.
7870 If both IMAP4rev1 and IMAP4rev2 are advertised, an IMAP client that
7871 wants to use IMAP4rev2 MUST issue an "ENABLE IMAP4rev2" command.
7873 When compared to IMAP4rev1, some request data items, corresponding
7874 response data items, and responses were removed in IMAP4rev2. See
7875 Appendix E for more details. With the exception of obsolete SEARCH
7876 and RECENT responses, servers advertising both IMAP4rev1 and
7877 IMAP4rev2 would never return such removed response data items/
7878 responses unless explicitly requested by an IMAPrev1 client.
7880 Servers advertising both IMAP4rev1 and IMAP4rev2 MUST NOT generate
7881 UTF-8-quoted strings unless the client has issued "ENABLE IMAP4rev2".
7882 Consider implementation of mechanisms described or referenced in
7883 [IMAP-UTF-8] to achieve this goal.
7886 intending to be compatible with IMAP4rev1 servers, MUST be compatible
7887 with the Mailbox International Naming Convention described in
7890 Also see Appendix D for special considerations for servers that
7891 support 63-bit body part / message sizes and want to advertise
7892 support for both IMAP4rev1 and IMAP4rev2.
7894A.1. Mailbox International Naming Convention for Compatibility with
7897 Support for the Mailbox International Naming Convention described in
7898 this section is not required for IMAP4rev2-only clients and servers.
7899 It is only used for backward compatibility with IMAP4rev1
7902 By convention, international mailbox names in IMAP4rev1 are specified
7903 using a modified version of the UTF-7 encoding described in [UTF-7].
7904 Modified UTF-7 may also be usable in servers that implement an
7905 earlier version of this protocol.
7907 In modified UTF-7, printable US-ASCII characters, except for "&",
7908 represent themselves; that is, characters with octet values 0x20-0x25
7909 and 0x27-0x7e. The character "&" (0x26) is represented by the
7910 2-octet sequence "&-".
7912 All other characters (octet values 0x00-0x1f and 0x7f-0xff) are
7913 represented in modified base64, with a further modification from
7914 [UTF-7] that "," is used instead of "/". Modified base64 MUST NOT be
7915 used to represent any printing of a US-ASCII character that can
7916 represent itself. Only characters inside the modified base64
7917 alphabet are permitted in modified base64 text.
7919 "&" is used to shift to modified base64 and "-" to shift back to US-
7920 ASCII. There is no implicit shift from base64 to US-ASCII, and null
7921 shifts ("-&" while in base64; note that "&-" while in US-ASCII means
7922 "&") are not permitted. However, all names start in US-ASCII and
7923 MUST end in US-ASCII; that is, a name that ends with a non-ASCII
7924 ISO-10646 character MUST end with a "-".
7926 The purpose of these modifications is to correct the following
7927 problems with UTF-7:
7929 1. UTF-7 uses the "+" character for shifting; this conflicts with
7930 the common use of "+" in mailbox names, in particular USENET
7933 2. UTF-7's encoding is base64, which uses the "/" character; this
7934 conflicts with the use of "/" as a popular hierarchy delimiter.
7936 3. UTF-7 prohibits the unencoded usage of "\"; this conflicts with
7937 the use of "\" as a popular hierarchy delimiter.
7939 4. UTF-7 prohibits the unencoded usage of "~"; this conflicts with
7940 the use of "~" in some servers as a home directory indicator.
7942 5. UTF-7 permits multiple alternate forms to represent the same
7943 string; in particular, printable US-ASCII characters can be
7944 represented in encoded form.
7946 Although modified UTF-7 is a convention, it establishes certain
7947 requirements on the server handling of any mailbox name with an
7948 embedded "&" character. In particular, server implementations MUST
7949 preserve the exact form of the modified base64 portion of a modified
7950 UTF-7 name and treat that text as case sensitive, even if names are
7951 otherwise case insensitive or case folded.
7954 embedded "&" character, used as an argument to CREATE, is: in the
7955 correctly modified UTF-7 syntax; has no superfluous shifts; and has
7956 no encoding in modified base64 of any printing US-ASCII character
7957 that can represent itself. However, client implementations MUST NOT
7958 depend upon the server doing this and SHOULD NOT attempt to create a
7959 mailbox name with an embedded "&" character unless it complies with
7960 the modified UTF-7 syntax.
7962 Server implementations that export a mail store that does not follow
7963 the modified UTF-7 convention MUST convert any mailbox name that
7964 contains either non-ASCII characters or the "&" character to modified
7968 and Japanese text: ~peter/mail/&U,BTFw-/&ZeVnLIqe-
7970 For example, the string "&Jjo!" is not a valid mailbox name
7971 because it does not contain a shift to US-ASCII before the "!".
7972 The correct form is "&Jjo-!". The string "&U,BTFw-&ZeVnLIqe-" is
7973 not permitted because it contains a superfluous shift. The
7974 correct form is "&U,BTF2XlZyyKng-".
7976Appendix B. Backward Compatibility with BINARY Extension
7978 IMAP4rev2 incorporates a subset of functionality provided by the
7979 BINARY extension [RFC3516]; in particular, it includes additional
7980 FETCH items (BINARY, BINARY.PEEK, and BINARY.SIZE) but not extensions
7981 to the APPEND command. IMAP4rev2 implementations that support full
7982 [RFC3516] functionality need to also advertise the BINARY capability
7983 in the CAPABILITY response / response code.
7985Appendix C. Backward Compatibility with LIST-EXTENDED Extension
7987 IMAP4rev2 incorporates most of the functionality provided by the
7988 LIST-EXTENDED extension [RFC5258]. In particular, the syntax for
7989 multiple mailbox patterns is not supported in IMAP4rev2, unless LIST-
7990 EXTENDED capability is also advertised in the CAPABILITY response /
7993Appendix D. 63-Bit Body Part and Message Sizes
7995 IMAP4rev2 increases allowed body part and message sizes that servers
7996 can support from 32 to 63 bits. Server implementations don't have to
7997 support 63-bit-long body parts/message sizes; however, client
7998 implementations have to expect them.
8000 As IMAP4rev1 didn't support 63-bit-long body part / message sizes,
8001 there is an interoperability issue exposed by 63-bit-capable servers/
8002 mailboxes that are accessible by both IMAP4rev1 and IMAP4rev2 email
8003 clients. As IMAP4rev1 would be unable to retrieve the full content
8004 of messages bigger than 4 Gb, such servers either need to replace
8005 messages bigger that 4 Gb with messages under 4 Gb or hide them from
8006 IMAP4rev1 clients. This document doesn't prescribe any
8007 implementation strategy to address this issue.
8009Appendix E. Changes from RFC 3501 / IMAP4rev1
8011 Below is the summary of changes since RFC 3501:
8013 1. Support for 64-bit message and body part sizes.
8015 2. Folded in IMAP NAMESPACE [RFC2342], UNSELECT [RFC3691], UIDPLUS
8016 [RFC4315], ESEARCH [RFC4731], SEARCHRES [RFC5182], ENABLE
8017 [RFC5161], IDLE [RFC2177], SASL-IR [RFC4959], LIST-EXTENDED
8018 [RFC5258], LIST-STATUS [RFC5819], MOVE [RFC6851], and LITERAL-
8019 extensions [RFC7888]. Also folded in IMAP ABNF extensions
8020 [RFC4466], response codes [RFC5530], the FETCH side of the
8021 BINARY extension [RFC3516], and the list of new mailbox
8022 attributes from SPECIAL-USE [RFC6154].
8026 4. SEARCH command now requires to return the ESEARCH response
8027 (SEARCH response is now deprecated).
8029 5. Clarified which SEARCH keys have to use substring match and
8032 6. Clarified that the server should decode parameter value
8033 continuations as described in [RFC2231]. This requirement was
8034 hidden in [RFC2231] itself.
8036 7. Clarified that the COPYUID response code is returned for both
8039 8. Tightened requirements about COPY/MOVE commands not creating a
8040 target mailbox. Also required them to return the TRYCREATE
8041 response code, if the target mailbox doesn't exist and can be
8044 9. Added the CLOSED response code from [RFC7162]. SELECT/EXAMINE
8045 when a mailbox is already selected now requires a CLOSED
8046 response code to be returned.
8048 10. SELECT/EXAMINE are now required to return an untagged LIST
8053 12. RECENT response on SELECT/EXAMINE, \Recent flag, RECENT STATUS,
8054 and SEARCH NEW items are now deprecated.
8056 13. Clarified that the server doesn't need to send a new
8057 PERMANENTFLAGS response code when a new keyword was successfully
8058 added and the server advertised \* earlier for the same mailbox.
8060 14. For future extensibility, extended ABNF for tagged-ext-simple to
8061 allow for bare number64.
8063 15. Added SHOULD level requirement on IMAP servers to support
8064 $MDNSent, $Forwarded, $Junk, $NonJunk, and $Phishing keywords.
8066 16. Mailbox names and message headers now allow for UTF-8. Support
8067 for modified UTF-7 in mailbox names is not required, unless
8068 compatibility with IMAP4rev1 is desired.
8070 17. Removed the CHECK command. Clients should use NOOP instead.
8072 18. RFC822, RFC822.HEADER, and RFC822.TEXT FETCH data items were
8073 deprecated. Clients should use the corresponding BODY[]
8076 19. LSUB command was deprecated. Clients should use LIST
8077 (SUBSCRIBED) instead.
8079 20. IDLE command can now return updates not related to the currently
8080 selected mailbox state.
8082 21. All unsolicited FETCH updates are required to include UID.
8084 22. Clarified that client implementations MUST ignore response codes
8085 that they do not recognize. (Changed from a SHOULD to a MUST.)
8087 23. resp-text ABNF non-terminal was updated to allow for empty text.
8089 24. After ENABLE, IMAP4rev2 human-readable response text can include
8090 non-ASCII encoded in UTF-8.
8092 25. Updated to use modern TLS-related recommendations as per
8093 [RFC7525], [RFC7817], and [RFC8314].
8095 26. Added warnings about use of ALERT response codes and PREAUTH
8098 27. Replaced DIGEST-MD5 SASL mechanism with SCRAM-SHA-256. DIGEST-
8101 28. Clarified that any command received from the client resets
8102 server autologout timer.
8104 29. Revised IANA registration procedure for IMAP extensions and
8105 removed "X" convention in accordance with [BCP178].
8107 30. Loosened requirements on servers when closing connections to be
8108 more aligned with existing practices.
8110Appendix F. Other Recommended IMAP Extensions
8112 Support for the following extensions is recommended for all IMAP
8113 clients and servers. While they significantly reduce bandwidth and/
8114 or number of round trips used by IMAP in certain situations, the
8115 EXTRA WG decided that requiring them as a part of IMAP4rev2 would
8116 push the bar to implement too high for new implementations. Also
8117 note that the absence of any IMAP extension from this list doesn't
8118 make it somehow deficient or not recommended for use with IMAP4rev2.
8120 1. Quick Mailbox Resynchronization (QRESYNC) and CONDSTORE
8121 extensions [RFC7162]. They make discovering changes to IMAP
8122 mailboxes more efficient, at the expense of storing a bit more
8125 2. OBJECTID extension [RFC8474] helps with preserving the IMAP
8126 client cache when messages are moved/copied or mailboxes are
8131 Earlier draft versions of this document were edited by Mark Crispin.
8132 Sadly, he is no longer available to help with this work. Editors of
8133 this revision are hoping that Mark would have approved.
8135 Chris Newman has contributed text on I18N and use of UTF-8 in
8136 messages and mailbox names.
8138 Thank you to Tony Hansen for helping with the index generation.
8139 Thank you to Murray Kucherawy, Timo Sirainen, Bron Gondwana, Stephan
8140 Bosch, Robert Sparks, Arnt Gulbrandsen, Benjamin Kaduk, Daniel
8141 Migaul, Roman Danyliw, and Éric Vyncke for extensive feedback.
8143 This document incorporates text from [RFC2342] (by Mike Gahrns and
8144 Chris Newman), [RFC3516] (by Lyndon Nerenberg), [RFC4315] (by Mark
8145 Crispin), [RFC4466] (by Cyrus Daboo), [RFC4731] (by Dave Cridland),
8146 [RFC4959] (by Rob Siemborski and Arnt Gulbrandsen), [RFC5161] (by
8147 Arnt Gulbrandsen), [RFC5465] (by Arnt Gulbrandsen and Curtis King),
8148 [RFC5530] (by Arnt Gulbrandsen), [RFC5819] (by Timo Sirainen),
8149 [RFC6154] (by Jamie Nicolson), [RFC6851] (by Arnt Gulbrandsen and Ned
8150 Freed), and [RFC8438] (by Stephan Bosch), so work done by authors/
8151 editors of these documents is appreciated. Note that editors of this
8152 document were redacted from the above list.
8154 The CHILDREN return option was originally proposed by Mike Gahrns and
8155 Raymond Cheng in [RFC3348]. Most of the information in
8156 Section 6.3.9.5 is taken directly from their original specification
8159 Thank you to Damian Poddebniak, Fabian Ising, Hanno Boeck, and
8160 Sebastian Schinzel for pointing out that the ENABLE command should be
8161 a member of "command-auth" and not "command-any" ABNF production, as
8162 well as pointing out security issues associated with ALERT, PREAUTH,
8163 and other responses received before authentication.
8167 $ + - \ A B C D E F H I K L M N O P R S T U
8171 $Forwarded (predefined flag)
8173 $Junk (predefined flag)
8175 $MDNSent (predefined flag)
8177 $NotJunk (predefined flag)
8179 $Phishing (predefined flag)
8180 Section 2.3.2, Paragraph 6.10.1
8186 +FLAGS.SILENT <flag list>
8193 -FLAGS.SILENT <flag list>
8198 \All (mailbox name attribute)
8200 \Answered (system flag)
8202 \Archive (mailbox name attribute)
8204 \Deleted (system flag)
8206 \Draft (system flag)
8208 \Drafts (mailbox name attribute)
8210 \Flagged (mailbox name attribute)
8212 \Flagged (system flag)
8214 \HasChildren (mailbox name attribute)
8216 \HasNoChildren (mailbox name attribute)
8218 \Junk (mailbox name attribute)
8220 \Marked (mailbox name attribute)
8222 \Noinferiors (mailbox name attribute)
8224 \NonExistent (mailbox name attribute)
8225 Section 7.3.1, Paragraph 4.2.1
8226 \Noselect (mailbox name attribute)
8228 \Recent (system flag)
8230 \Remote (mailbox name attribute)
8234 \Sent (mailbox name attribute)
8236 \Subscribed (mailbox name attribute)
8238 \Trash (mailbox name attribute)
8240 \Unmarked (mailbox name attribute)
8245 ALERT (response code)
8251 ALL (search result option)
8252 Section 6.4.4, Paragraph 6.6.1
8253 ALL (search return item name)
8254 Section 7.3.4, Paragraph 7.6.1
8255 ALREADYEXISTS (response code)
8256 Section 7.1, Paragraph 4.4.1
8257 ANSWERED (search key)
8261 APPENDUID (response code)
8262 Section 7.1, Paragraph 4.6.1
8263 AUTHENTICATE (command)
8265 AUTHENTICATIONFAILED (response code)
8266 Section 7.1, Paragraph 4.8.1
8267 AUTHORIZATIONFAILED (response code)
8268 Section 7.1, Paragraph 4.10.1
8274 BADCHARSET (response code)
8276 BCC <string> (search key)
8278 BEFORE <date> (search key)
8280 BINARY.PEEK[<section-binary>]<<partial>> (fetch item)
8282 BINARY.SIZE[<section-binary>] (fetch item)
8283 Section 6.4.5, Paragraph 9.6.1
8284 BINARY.SIZE[<section-binary>] (fetch result)
8285 Section 7.5.2, Paragraph 4.4.1
8286 BINARY[<section-binary>]<<number>> (fetch result)
8287 Section 7.5.2, Paragraph 4.2.1
8288 BINARY[<section-binary>]<<partial>> (fetch item)
8289 Section 6.4.5, Paragraph 9.2.1
8294 BODY <string> (search key)
8296 BODY.PEEK[<section>]<<partial>> (fetch item)
8298 BODYSTRUCTURE (fetch item)
8300 BODYSTRUCTURE (fetch result)
8301 Section 7.5.2, Paragraph 4.10.1
8302 BODY[<section>]<<origin octet>> (fetch result)
8303 Section 7.5.2, Paragraph 4.8.1
8304 BODY[<section>]<<partial>> (fetch item)
8305 Section 6.4.5, Paragraph 9.10.1
8308 Body Structure (message attribute)
8313 CANNOT (response code)
8314 Section 7.1, Paragraph 4.14.1
8315 CAPABILITY (command)
8317 CAPABILITY (response code)
8319 CAPABILITY (response)
8321 CC <string> (search key)
8323 CLIENTBUG (response code)
8324 Section 7.1, Paragraph 4.18.1
8327 CLOSED (response code)
8328 Section 7.1, Paragraph 4.20.1
8329 CONTACTADMIN (response code)
8330 Section 7.1, Paragraph 4.22.1
8333 COPYUID (response code)
8334 Section 7.1, Paragraph 4.24.1
8335 CORRUPTION (response code)
8336 Section 7.1, Paragraph 4.26.1
8337 COUNT (search result option)
8339 COUNT (search return item name)
8348 DELETED (search key)
8350 DELETED (status item)
8359 ENVELOPE (fetch item)
8361 ENVELOPE (fetch result)
8362 Section 7.5.2, Paragraph 4.42.1
8367 EXPIRED (response code)
8368 Section 7.1, Paragraph 4.28.1
8373 EXPUNGEISSUED (response code)
8374 Section 7.1, Paragraph 4.30.1
8375 Envelope Structure (message attribute)
8386 FLAGGED (search key)
8390 FLAGS (fetch result)
8394 FLAGS <flag list> (store command data item)
8396 FLAGS.SILENT <flag list> (store command data item)
8398 FROM <string> (search key)
8402 Flags (message attribute)
8407 HASCHILDREN (response code)
8408 Section 7.1, Paragraph 4.32.1
8409 HEADER (part specifier)
8410 Section 6.4.5.1, Paragraph 5
8411 HEADER <field-name> <string> (search key)
8413 HEADER.FIELDS (part specifier)
8414 Section 6.4.5.1, Paragraph 5
8415 HEADER.FIELDS.NOT (part specifier)
8416 Section 6.4.5.1, Paragraph 5
8422 INTERNALDATE ( fetch item)
8424 INTERNALDATE (fetch result)
8426 INUSE (response code)
8427 Section 7.1, Paragraph 4.34.1
8428 Internal Date (message attribute)
8433 KEYWORD <flag> (search key)
8435 Keyword (type of flag)
8436 Section 2.3.2, Paragraph 4
8440 LARGER <n> (search key)
8442 LIMIT (response code)
8443 Section 7.1, Paragraph 4.36.1
8453 MAX (search result option)
8454 Section 6.4.4, Paragraph 6.4.1
8455 MAX (search return item name)
8456 Section 7.3.4, Paragraph 7.4.1
8457 MAY (specification requirement term)
8459 MESSAGES (status item)
8461 MIME (part specifier)
8462 Section 6.4.5.1, Paragraph 7
8463 MIN (search result option)
8464 Section 6.4.4, Paragraph 6.2.1
8465 MIN (search return item name)
8466 Section 7.3.4, Paragraph 7.2.1
8469 MUST (specification requirement term)
8471 MUST NOT (specification requirement term)
8473 Message Sequence Number (message attribute)
8480 NAMESPACE (response)
8484 NONEXISTENT (response code)
8485 Section 7.1, Paragraph 4.38.1
8488 NOPERM (response code)
8489 Section 7.1, Paragraph 4.40.1
8490 NOT <search-key> (search key)
8492 NOT RECOMMENDED (specification requirement term)
8499 ON <date> (search key)
8501 OPTIONAL (specification requirement term)
8502 Section 1.2; Section 1.2
8503 OR <search-key1> <search-key2> (search key)
8505 OVERQUOTA (response code)
8506 Section 7.1, Paragraph 4.42.1
8510 PARSE (response code)
8512 PERMANENTFLAGS (response code)
8513 Section 7.1, Paragraph 4.46.1
8516 PRIVACYREQUIRED (response code)
8517 Section 7.1, Paragraph 4.48.1
8518 Permanent Flag (class of flag)
8519 Section 2.3.2, Paragraph 9
8521 Section 2.3.2, Paragraph 5
8525 READ-ONLY (response code)
8527 READ-WRITE (response code)
8529 RECOMMENDED (specification requirement term)
8533 REQUIRED (specification requirement term)
8535 RFC822.SIZE (fetch item)
8537 RFC822.SIZE (fetch result)
8539 RFC822.SIZE (message attribute)
8544 SAVE (search result option)
8545 Section 6.4.4, Paragraph 6.10.1
8552 SENTBEFORE <date> (search key)
8554 SENTON <date> (search key)
8556 SENTSINCE <date> (search key)
8558 SERVERBUG (response code)
8559 Section 7.1, Paragraph 4.54.1
8560 SHOULD (specification requirement term)
8562 SHOULD NOT (specification requirement term)
8564 SINCE <date> (search key)
8568 SMALLER <n> (search key)
8578 SUBJECT <string> (search key)
8582 Session Flag (class of flag)
8583 Section 2.3.2, Paragraph 9
8584 System Flag (type of flag)
8585 Section 2.3.2, Paragraph 2
8589 TEXT (part specifier)
8590 Section 6.4.5.1, Paragraph 5
8591 TEXT <string> (search key)
8593 TO <string> (search key)
8595 TRYCREATE (response code)
8606 UID <sequence set> (search key)
8608 UIDNEXT (response code)
8610 UIDNEXT (status item)
8612 UIDNOTSTICKY (response code)
8613 Section 7.1, Paragraph 4.60.1
8614 UIDVALIDITY (response code)
8616 UIDVALIDITY (status item)
8618 UNANSWERED (search key)
8620 UNAVAILABLE (response code)
8621 Section 7.1, Paragraph 4.64.1
8622 UNDELETED (search key)
8624 UNDRAFT (search key)
8626 UNFLAGGED (search key)
8628 UNKEYWORD <flag> (search key)
8630 UNKNOWN-CTE (response code)
8634 UNSEEN (status item)
8638 UNSUBSCRIBE (command)
8640 Unique Identifier (UID) (message attribute)
8645 Alexey Melnikov (editor)
8652 Email: Alexey.Melnikov@isode.com
8655 Barry Leiba (editor)
8656 Futurewei Technologies
8658 Email: barryleiba@computer.org
8659 URI: http://internetmessagingtechnology.org/