anil.recoil.org
IMAP in OCaml
1
2
3
4
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
10
11
12 Internet Message Access Protocol (IMAP) - Version 4rev2
13
14Abstract
15
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.
22
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
29 identifiers.
30
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
33 RFC 6409.
34
35Status of This Memo
36
37 This is an Internet Standards Track document.
38
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.
44
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.
48
49Copyright Notice
50
51 Copyright (c) 2021 IETF Trust and the persons identified as the
52 document authors. All rights reserved.
53
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.
63
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
74 than English.
75
76Table of Contents
77
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
82 2. Protocol Overview
83 2.1. Link Level
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
94 2.4. Message Texts
95 3. State and Flow Diagram
96 3.1. Not Authenticated State
97 3.2. Authenticated State
98 3.3. Selected State
99 3.4. Logout State
100 4. Data Formats
101 4.1. Atom
102 4.1.1. Sequence Set and UID Set
103 4.2. Number
104 4.3. String
105 4.3.1. 8-Bit and Binary Strings
106 4.4. Parenthesized List
107 4.5. NIL
108 5. Operational Considerations
109 5.1. Mailbox Naming
110 5.1.1. Mailbox Hierarchy Naming
111 5.1.2. Namespaces
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)
116 6. Client Commands
117 6.1. Client Commands - Any State
118 6.1.1. CAPABILITY Command
119 6.1.2. NOOP 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
124 6.2.3. LOGIN 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
134 6.3.9. LIST Command
135 6.3.10. NAMESPACE Command
136 6.3.11. STATUS Command
137 6.3.12. APPEND Command
138 6.3.13. IDLE Command
139 6.4. Client Commands - Selected State
140 6.4.1. CLOSE Command
141 6.4.2. UNSELECT Command
142 6.4.3. EXPUNGE Command
143 6.4.4. SEARCH Command
144 6.4.5. FETCH Command
145 6.4.6. STORE Command
146 6.4.7. COPY Command
147 6.4.8. MOVE Command
148 6.4.9. UID Command
149 6.5. Client Commands - Experimental/Expansion
150 7. Server Responses
151 7.1. Server Responses - Generic Status Responses
152 7.1.1. OK Response
153 7.1.2. NO Response
154 7.1.3. BAD Response
155 7.1.4. PREAUTH Response
156 7.1.5. BYE 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
161 7.3.1. LIST Response
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
173 9. Formal Syntax
174 10. Author's Note
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
182 11.6. Use of MD5
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
188 Extended Data Items
189 12.4. IMAP Mailbox Name Attributes and IMAP Response Codes
190 13. References
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
197 with IMAP4rev1
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
203 Acknowledgements
204 Index
205 Authors' Addresses
206
2071. How to Read This Document
208
2091.1. Organization of This Document
210
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
216 operates.
217
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).
223
2241.2. Conventions Used in This Document
225
226 "Conventions" are basic principles or procedures. Document
227 conventions are noted in this section.
228
229 In examples, "C:" and "S:" indicate lines sent by the client and
230 server, respectively. Note that each line includes the terminating
231 CRLF.
232
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.
238
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
241 protocol.
242
243 "User" is used to refer to a human user, whereas "client" refers to
244 the software being run by the user.
245
246 "Connection" refers to the entire sequence of client/server
247 interaction from the initial establishment of the network connection
248 until its termination.
249
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).
254
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.
261
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.
267
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.
276
2771.3. Special Notes to Implementors
278
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.
283
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.
298
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.
304
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.
309
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
312 [RFC6409].
313
3142. Protocol Overview
315
3162.1. Link Level
317
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).
321
3222.2. Commands and Responses
323
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
328 response.
329
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.
334
3352.2.1. Client Protocol Sender and Server Protocol Receiver
336
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
342 accept tag reuse.
343
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.
347
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 "+".
356
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.
361
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
370 command.
371
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.
375
3762.2.2. Server Protocol Sender and Client Protocol Receiver
377
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.
381
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.
386
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).
395
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
400 completion response.
401
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 "+".
405
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.
412
413 This topic is discussed in greater detail in "Server Responses" (see
414 Section 7).
415
4162.3. Message Attributes
417
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.
421
4222.3.1. Message Numbers
423
424 Messages in IMAP4rev2 are accessed by one of two numbers: the Unique
425 Identifier (UID) or the message sequence number.
426
4272.3.1.1. Unique Identifier (UID) Message Attribute
428
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.
438
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].
446
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
450 (UIDVALIDITY).
451
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.
460
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.
469
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.
479
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:
485
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.
491
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
496 caching.
497
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
502 the mailbox.
503
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.
512
5132.3.1.2. Message Sequence Number Message Attribute
514
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.
520
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
527 expunge.
528
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.
537
5382.3.2. Flags Message Attribute
539
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.
545
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:
550
551 \Seen Message has been read
552
553 \Answered Message has been answered
554
555 \Flagged Message is "flagged" for urgent/special attention
556
557 \Deleted Message is "deleted" for removal by later EXPUNGE
558
559 \Draft Message has not completed composition (marked as a
560 draft).
561
562 \Recent This flag was in use in IMAP4rev1 and is now
563 deprecated.
564
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.
570
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:
576
577 $Forwarded
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.
584
585 $MDNSent
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.
589
590 $Junk
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
596 information.
597
598 $NotJunk
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.
604
605 $Phishing
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),
612 if available.
613
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
619 within the message.
620
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.
627
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.
631
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
635 [RFC5788].
636
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.
642
6432.3.3. Internal Date Message Attribute
644
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.
656
6572.3.4. RFC822.SIZE Message Attribute
658
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.
664
6652.3.5. Envelope Structure Message Attribute
666
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.
670
6712.3.6. Body Structure Message Attribute
672
673 A body structure is a parsed representation of the [MIME-IMB] body
674 structure information of the message.
675
6762.4. Message Texts
677
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.
683
6843. State and Flow Diagram
685
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.
693
6943.1. Not Authenticated State
695
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-
699 authenticated.
700
7013.2. Authenticated State
702
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.
709
7103.3. Selected State
711
712 In a selected state, a mailbox has been selected to access. This
713 state is entered when a mailbox has been successfully selected.
714
7153.4. Logout State
716
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
720 the server.
721
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
726 connection.
727
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.
734
735 +----------------------+
736 |connection established|
737 +----------------------+
738 ||
739 \/
740 +--------------------------------------+
741 | server greeting |
742 +--------------------------------------+
743 || (1) || (2) || (3)
744 \/ || ||
745 +-----------------+ || ||
746 |Not Authenticated| || ||
747 +-----------------+ || ||
748 || (7) || (4) || ||
749 || \/ \/ ||
750 || +----------------+ ||
751 || | Authenticated |<=++ ||
752 || +----------------+ || ||
753 || || (7) || (5) || (6) ||
754 || || \/ || ||
755 || || +--------+ || ||
756 || || |Selected|==++ ||
757 || || +--------+ ||
758 || || || (7) ||
759 \/ \/ \/ \/
760 +--------------------------------------+
761 | Logout |
762 +--------------------------------------+
763 ||
764 \/
765 +-------------------------------+
766 |both sides close the connection|
767 +-------------------------------+
768
769 Legend for the above diagram:
770
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
779
7804. Data Formats
781
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.
787
7884.1. Atom
789
790 An atom consists of one or more non-special characters.
791
7924.1.1. Sequence Set and UID Set
793
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.
801
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 "*".
805
8064.2. Number
807
808 A number consists of one or more digit characters and represents a
809 numeric value.
810
8114.3. String
812
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
820 be used.
821
822 When the distinction between synchronizing and non-synchronizing
823 literals is not important, this document only uses the term
824 "literal".
825
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).
835
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
852 extensions.)
853
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.
857
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).
862
863 Note: Even if the octet count is 0, a client transmitting a
864 synchronizing literal MUST wait to receive a command continuation
865 request.
866
8674.3.1. 8-Bit and Binary Strings
868
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.
873
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
879 implementations.
880
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.
890
8914.4. Parenthesized List
892
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.
897
898 The empty list is represented as () -- a parenthesized list with no
899 members.
900
9014.5. NIL
902
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 ().
906
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.
914
915 Examples:
916
917 The following LIST response:
918
919 * LIST () "/" NIL
920
921 is equivalent to:
922
923 * LIST () "/" "NIL"
924
925 as LIST response ABNF is using "astring" for mailbox name.
926
927 However, the following response:
928
929 * FETCH 1 (BODY[1] NIL)
930
931 is not equivalent to:
932
933 * FETCH 1 (BODY[1] "NIL")
934
935 The former indicates absence of the body part, while the latter means
936 that it contains a string with the three characters "NIL".
937
9385. Operational Considerations
939
940 The following rules are listed here to ensure that all IMAP4rev2
941 implementations interoperate properly.
942
9435.1. Mailbox Naming
944
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.
958
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.
964
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.
971
972 There are certain client considerations when creating a new mailbox
973 name:
974
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.
978
979 2. CTL and other non-graphic characters are difficult to represent
980 in a user interface and are best avoided. Servers MAY refuse to
981 create mailbox names containing Unicode CTL characters.
982
983 3. Although the list-wildcard characters ("%" and "*") are valid in
984 a mailbox name, it is difficult to use such mailbox names with
985 the LIST command due to the conflict with wildcard
986 interpretation.
987
988 4. Usually, a character (determined by the server implementation) is
989 reserved to delimit levels of hierarchy.
990
991 5. Two characters, "#" and "&", have meanings by convention and
992 should be avoided except when used in that convention. See
993 Section 5.1.2.1 and Appendix A.1, respectively.
994
9955.1.1. Mailbox Hierarchy Naming
996
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.
1001
10025.1.2. Namespaces
1003
1004 Personal Namespace:
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.
1013
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.
1022
1023 Shared Namespace:
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
1026 Namespace.
1027
1028 The namespaces a server uses MAY differ on a per-user basis.
1029
10305.1.2.1. Historic Mailbox Namespace Naming Convention
1031
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.
1036
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).
1043
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.
1048
10495.1.2.2. Common Namespace Models
1050
1051 The previous version of this protocol did not define a default server
1052 namespace. Two common namespace models have evolved:
1053
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
1057 another namespace.
1058
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.
1062
10635.2. Mailbox Size and Message Status Updates
1064
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.
1075
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.
1082
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
1087 mailbox.
1088
10895.3. Response When No Command in Progress
1090
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.
1097
10985.4. Autologout Timer
1099
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.
1104
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.
1109
11105.5. Multiple Commands in Progress (Command Pipelining)
1111
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.
1120
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.
1125
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.
1129
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.
1139
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.
1147
1148 For example, the following non-waiting command sequences are invalid:
1149
1150 FETCH + NOOP + STORE
1151
1152 STORE + COPY + FETCH
1153
1154 COPY + COPY
1155
1156 The following are examples of valid non-waiting command sequences:
1157
1158 FETCH + STORE + SEARCH + NOOP
1159
1160 STORE + COPY + EXPUNGE
1161
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.
1165
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.
1169
11706. Client Commands
1171
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).
1177
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"
1181 (Section 9).
1182
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".
1191
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.
1195
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.
1202
12036.1. Client Commands - Any State
1204
1205 The following commands are valid in any state: CAPABILITY, NOOP, and
1206 LOGOUT.
1207
12086.1.1. CAPABILITY Command
1209
1210 Arguments: none
1211
1212 Responses: REQUIRED untagged response: CAPABILITY
1213
1214 Result: OK - capability completed
1215 BAD - arguments invalid
1216
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.
1222
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.
1227
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.
1237
1238 Client and server implementations MUST implement the STARTTLS
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
1243 information.
1244
1245 Unless otherwise specified, all registered extensions to IMAP4rev1
1246 are also valid extensions to IMAP4rev2.
1247
1248 Example:
1249
1250 C: abcd CAPABILITY
1251 S: * CAPABILITY IMAP4rev2 STARTTLS AUTH=GSSAPI
1252 LOGINDISABLED
1253 S: abcd OK CAPABILITY completed
1254 C: efgh STARTTLS
1255 S: efgh OK STARTTLS completed
1256 <TLS negotiation, further commands are under TLS layer>
1257 C: ijkl CAPABILITY
1258 S: * CAPABILITY IMAP4rev2 AUTH=GSSAPI AUTH=PLAIN
1259 S: ijkl OK CAPABILITY completed
1260
12616.1.2. NOOP Command
1262
1263 Arguments: none
1264
1265 Responses: no specific responses for this command (but see below)
1266
1267 Result: OK - noop completed
1268 BAD - command unknown or arguments invalid
1269
1270 The NOOP command always succeeds. It does nothing.
1271
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.
1278
1279 Example:
1280
1281 C: a002 NOOP
1282 S: a002 OK NOOP completed
1283 . . .
1284 C: a047 NOOP
1285 S: * 22 EXPUNGE
1286 S: * 23 EXISTS
1287 S: * 14 FETCH (UID 1305 FLAGS (\Seen \Deleted))
1288 S: a047 OK NOOP completed
1289
12906.1.3. LOGOUT Command
1291
1292 Arguments: none
1293
1294 Responses: REQUIRED untagged response: BYE
1295
1296 Result: OK - logout completed
1297 BAD - command unknown or arguments invalid
1298
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.
1302
1303 Example:
1304
1305 C: A023 LOGOUT
1306 S: * BYE IMAP4rev2 Server logging out
1307 S: A023 OK LOGOUT completed
1308 (Server and client then close the connection)
1309
13106.2. Client Commands - Not Authenticated State
1311
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.
1319
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.
1323
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.
1331
1332 Once authenticated (including as anonymous), it is not possible to
1333 re-enter not authenticated state.
1334
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.
1339
13406.2.1. STARTTLS Command
1341
1342 Arguments: none
1343
1344 Responses: no specific response for this command
1345
1346 Result: OK - starttls completed, begin TLS negotiation
1347 NO - TLS negotiation can't be initiated, due to server
1348 configuration error
1349 BAD - STARTTLS received after a successful TLS
1350 negotiation or arguments invalid
1351
1352 Note that the STARTTLS command is available only on cleartext ports.
1353 The server MUST always respond with a tagged BAD response when the
1354 STARTTLS command is received on an Implicit TLS port.
1355
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
1365 STARTTLS command:
1366
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.)
1370
1371 2. Extra data from the TCP buffer is thrown away.
1372
1373 Note that the first option is friendlier to clients that pipeline the
1374 beginning of the STARTTLS command with TLS handshake data.
1375
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.
1381
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.
1388
1389 Example:
1390
1391 C: a001 CAPABILITY
1392 S: * CAPABILITY IMAP4rev2 STARTTLS LOGINDISABLED
1393 S: a001 OK CAPABILITY completed
1394 C: a002 STARTTLS
1395 S: a002 OK Begin TLS negotiation now
1396 <TLS negotiation, further commands are under TLS layer>
1397 C: a003 CAPABILITY
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)
1402
14036.2.2. AUTHENTICATE Command
1404
1405 Arguments: SASL authentication mechanism name
1406
1407 OPTIONAL initial response
1408
1409 Responses: continuation data can be requested
1410
1411 Result: OK - authenticate completed, now in authenticated
1412 state
1413 NO - authenticate failure: unsupported authentication
1414 mechanism, credentials rejected
1415 BAD - command unknown or arguments invalid,
1416 authentication exchange canceled
1417
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
1425 response.
1426
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].
1432
1433 The service name specified by this protocol's profile of [SASL] is
1434 "imap".
1435
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
1442 string. If the client wishes to cancel an authentication exchange,
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.
1447
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
1450 string or literal. To send a zero-length initial response, the
1451 client MUST send a single pad character ("="). This indicates that
1452 the response is present, but it is a zero-length string.
1453
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).
1461
1462 If the client uses an initial response with a SASL mechanism that
1463 does not support an initial response, the server MUST reject the
1464 command with a tagged BAD response.
1465
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.
1470
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.
1476
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.)
1492
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.
1497
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.
1508
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.
1515
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.
1519
1520 Example:
1521
1522 S: * OK [CAPABILITY IMAP4rev2 STARTTLS AUTH=GSSAPI]
1523 Capabilities
1524 C: A001 AUTHENTICATE GSSAPI
1525 S: +
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==
1543 C:
1544 S: + YDMGCSqGSIb3EgECAgIBAAD/////6jcyG4GE3KkTzBeBiVHe
1545 ceP2CWY0SR0fAQAgAAQEBAQ=
1546 C: YDMGCSqGSIb3EgECAgIBAAD/////3LQBHXTpFfZgrejpLlLImP
1547 wkhbfa2QteAQAgAG1yYwE=
1548 S: A001 OK GSSAPI authentication successful
1549
1550 The following example demonstrates the use of an initial response.
1551
1552 Example:
1553
1554 S: * OK [CAPABILITY IMAP4rev2 STARTTLS AUTH=GSSAPI
1555 LOGINDISABLED] Server ready
1556 C: A01 STARTTLS
1557 S: A01 OK STARTTLS completed
1558 <TLS negotiation, further commands are under TLS layer>
1559 C: A02 CAPABILITY
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)
1564
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:
1568
1569 ... client connects to server and negotiates a TLS
1570 protection layer ...
1571 C: C01 CAPABILITY
1572 S: * CAPABILITY IMAP4rev2 AUTH=PLAIN
1573 S: C01 OK Completed
1574 C: A01 AUTHENTICATE PLAIN
1575 S: +
1576 C: dGVzdAB0ZXN0AHRlc3Q=
1577 S: A01 OK Success (tls protection)
1578
1579 Note that in the above example there is a space following the "+"
1580 from the server.
1581
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:
1585
1586 ... client connects to server and negotiates a TLS
1587 protection layer ...
1588 C: C01 CAPABILITY
1589 S: * CAPABILITY IMAP4rev2 AUTH=PLAIN AUTH=EXTERNAL
1590 S: C01 OK Completed
1591 C: A01 AUTHENTICATE EXTERNAL =
1592 S: A01 OK Success (tls protection)
1593
1594 Note: The line breaks within server challenges and client responses
1595 are for editorial clarity and are not in real authenticators.
1596
15976.2.3. LOGIN Command
1598
1599 Arguments: user name
1600
1601 password
1602
1603 Responses: no specific responses for this command
1604
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
1608
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.
1615
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.
1620
1621 Example:
1622
1623 C: a001 LOGIN SMITH SESAME
1624 S: a001 OK LOGIN completed
1625
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.
1630
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.
1640
16416.3. Client Commands - Authenticated State
1642
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.
1646
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.
1651
16526.3.1. ENABLE Command
1653
1654 Arguments: capability names
1655
1656 Responses: no specific responses for this command
1657
1658 Result: OK - Relevant capabilities enabled
1659 BAD - No arguments, or syntax error in an argument
1660
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.
1668
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
1673 support.
1674
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:
1679
1680 * If the argument is not an extension known to the server, the
1681 server MUST ignore the argument.
1682
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.)
1687
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.
1692
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.
1697
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.
1702
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.
1708
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
1715 "a" or "b".
1716
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.
1720
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.
1727
1728 C: t1 CAPABILITY
1729 S: * CAPABILITY IMAP4rev2 ID LITERAL+ X-GOOD-IDEA
1730 S: t1 OK foo
1731 C: t2 ENABLE CONDSTORE X-GOOD-IDEA
1732 S: * ENABLED X-GOOD-IDEA
1733 S: t2 OK foo
1734 C: t3 CAPABILITY
1735 S: * CAPABILITY IMAP4rev2 ID LITERAL+ X-GOOD-IDEA
1736 S: t3 OK foo again
1737
1738 In the following example, the client enables the Conditional Store
1739 (CONDSTORE) extension [RFC7162]:
1740
1741 C: a1 ENABLE CONDSTORE
1742 S: * ENABLED CONDSTORE
1743 S: a1 OK Conditional Store enabled
1744
17456.3.1.1. Note to Designers of Extensions That May Use the ENABLE
1746 Command
1747
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.
1753
17546.3.2. SELECT Command
1755
1756 Arguments: mailbox name
1757
1758 Responses: REQUIRED untagged responses: FLAGS, EXISTS, LIST
1759 REQUIRED OK untagged responses: PERMANENTFLAGS,
1760 UIDNEXT, UIDVALIDITY
1761
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
1766
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
1776 items.
1777
1778 FLAGS
1779 Defined flags in the mailbox. See the description of the FLAGS
1780 response in Section 7.3.5 for more detail.
1781
1782 <n> EXISTS
1783 The number of messages in the mailbox. See the description of the
1784 EXISTS response in Section 7.4.1 for more detail.
1785
1786 LIST
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.
1793
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.
1798
1799 OK [UIDNEXT <n>]
1800 The next unique identifier value. Refer to Section 2.3.1.1 for
1801 more information.
1802
1803 OK [UIDVALIDITY <n>]
1804 The unique identifier validity value. Refer to Section 2.3.1.1
1805 for more information.
1806
1807 Only one mailbox can be selected at a time in a connection;
1808 simultaneous access to multiple mailboxes requires multiple
1809 connections. The SELECT command automatically deselects any
1810 currently selected mailbox before attempting the new selection.
1811 Consequently, if a mailbox is selected and a SELECT command that
1812 fails is attempted, no mailbox is selected. When deselecting a
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).
1816
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]"
1819 response code.
1820
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.
1830
1831 Example:
1832
1833 C: A142 SELECT INBOX
1834 S: * 172 EXISTS
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
1841
1842 Example:
1843
1844 C: A142 SELECT INBOX
1845 S: * 172 EXISTS
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
1854 S: * 5 EXISTS
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
1862
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
1866 response.
1867
18686.3.3. EXAMINE Command
1869
1870 Arguments: mailbox name
1871
1872 Responses: REQUIRED untagged responses: FLAGS, EXISTS, LIST
1873 REQUIRED OK untagged responses: PERMANENTFLAGS,
1874 UIDNEXT, UIDVALIDITY
1875
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
1880
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.
1885
1886 The text of the tagged OK response to the EXAMINE command MUST begin
1887 with the "[READ-ONLY]" response code.
1888
1889 Example:
1890
1891 C: A932 EXAMINE blurdybloop
1892 S: * 17 EXISTS
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
1899
19006.3.4. CREATE Command
1901
1902 Arguments: mailbox name
1903
1904 Responses: OPTIONAL untagged response: LIST
1905
1906 Result: OK - create completed
1907 NO - create failure: can't create mailbox with that
1908 name
1909 BAD - command unknown or arguments invalid
1910
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
1913 created. It is an error to attempt to create INBOX or a mailbox with
1914 a name that refers to an extant mailbox. Any error in creation will
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.)
1923
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.
1929
1930 If the mailbox name is suffixed with the server's hierarchy separator
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
1934 require this declaration MUST ignore the declaration. In any case,
1935 the name created is without the trailing hierarchy delimiter.
1936
1937 If the server's hierarchy separator character appears elsewhere in
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.
1943
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
1949 detail.
1950
1951 Example:
1952
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
1960
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.)
1964
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
1970 | created.
1971
19726.3.5. DELETE Command
1973
1974 Arguments: mailbox name
1975
1976 Responses: OPTIONAL untagged response: LIST
1977
1978 Result: OK - delete completed
1979 NO - delete failure: can't delete mailbox with that
1980 name
1981 BAD - command unknown or arguments invalid
1982
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.
1987
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)
1994 for more details).
1995
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
2000 command by returning a tagged NO response. The NO response SHOULD
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.
2004
2005 If the server returns an OK response, all messages in that mailbox
2006 are removed by the DELETE command.
2007
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
2013 detail.
2014
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.)
2020
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.
2024
2025 Example:
2026
2027 C: A682 LIST "" *
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
2034 C: A684 DELETE foo
2035 S: A684 NO Name "foo" has inferior hierarchical names
2036 C: A685 DELETE foo/bar
2037 S: A685 OK DELETE Completed
2038 C: A686 LIST "" *
2039 S: * LIST (\Noselect) "/" foo
2040 S: A686 OK LIST completed
2041 C: A687 DELETE foo
2042 S: A687 OK DELETE Completed
2043
2044 Example:
2045
2046 C: A82 LIST "" *
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
2053 C: A84 DELETE foo
2054 S: A84 OK DELETE Completed
2055 C: A85 LIST "" *
2056 S: * LIST () "." foo.bar
2057 S: A85 OK LIST completed
2058 C: A86 LIST "" %
2059 S: * LIST (\Noselect) "." foo
2060 S: A86 OK LIST completed
2061
20626.3.6. RENAME Command
2063
2064 Arguments: existing mailbox name
2065
2066 new mailbox name
2067
2068 Responses: OPTIONAL untagged response: LIST
2069
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
2074
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.
2080
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".
2085
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.
2093
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
2099 detail.
2100
2101 Renaming INBOX is permitted and does not result in a tagged BAD
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.)
2108
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
2118 normalized name.
2119
2120 Mailboxes renamed in one IMAP session MAY be announced to other IMAP
2121 sessions using an unsolicited LIST response with an OLDNAME extended
2122 data item.
2123
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.
2131
2132 Examples:
2133
2134 C: A682 LIST "" *
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
2143 C: A685 LIST "" *
2144 S: * LIST () "/" sarasoop
2145 S: * LIST (\Noselect) "/" zowie
2146 S: * LIST () "/" zowie/bar
2147 S: A685 OK LIST completed
2148
2149 C: Z432 LIST "" *
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
2155 C: Z434 LIST "" *
2156 S: * LIST () "." INBOX
2157 S: * LIST () "." INBOX.bar
2158 S: * LIST () "." old-mail
2159 S: Z434 OK LIST completed
2160
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:
2164
2165 C: 1001 RENAME X Y
2166 C: 1002 SUBSCRIBE Y
2167 C: 1003 UNSUBSCRIBE X
2168
2169 Note that the above sequence of commands doesn't account for updating
2170 the subscription for any child mailboxes of mailbox X.
2171
21726.3.7. SUBSCRIBE Command
2173
2174 Arguments: mailbox
2175
2176 Responses: no specific responses for this command
2177
2178 Result: OK - subscribe completed
2179 NO - subscribe failure: can't subscribe to that name
2180 BAD - command unknown or arguments invalid
2181
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
2186 subscribed.
2187
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.
2192
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.
2197
2198 Example:
2199
2200 C: A002 SUBSCRIBE #news.comp.mail.mime
2201 S: A002 OK SUBSCRIBE completed
2202
22036.3.8. UNSUBSCRIBE Command
2204
2205 Arguments: mailbox name
2206
2207 Responses: no specific responses for this command
2208
2209 Result: OK - unsubscribe completed
2210 NO - unsubscribe failure: can't unsubscribe that name
2211 BAD - command unknown or arguments invalid
2212
2213 The UNSUBSCRIBE command removes the specified mailbox name from the
2214 server's set of "active" or "subscribed" mailboxes as returned by the
2215 LIST (SUBSCRIBED) command. This command returns a tagged OK response
2216 if the unsubscription is successful or if the mailbox is not
2217 subscribed.
2218
2219 Example:
2220
2221 C: A002 UNSUBSCRIBE #news.comp.mail.mime
2222 S: A002 OK UNSUBSCRIBE completed
2223
22246.3.9. LIST Command
2225
2226 Arguments (basic):
2227 reference name
2228 mailbox name with possible wildcards
2229
2230 Arguments (extended):
2231 selection options (OPTIONAL)
2232 reference name
2233 mailbox patterns
2234 return options (OPTIONAL)
2235
2236 Responses: untagged responses: LIST
2237
2238 Result: OK - list completed
2239 NO - list failure: can't list that reference or
2240 mailbox name
2241 BAD - command unknown or arguments invalid
2242
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.
2248
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
2253 20 minutes!
2254
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
2258 conditions is true:
2259
2260 1. the first word after the command name begins with a parenthesis
2261 ("LIST selection options");
2262
2263 2. the second word after the command name begins with a parenthesis;
2264 and
2265
2266 3. the LIST command has more than 2 parameters ("LIST return
2267 options").
2268
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
2275 argument.
2276
2277 In the basic syntax only, an empty ("" string) mailbox name argument
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.
2285
2286 In the extended syntax, any mailbox name arguments that are empty
2287 strings are ignored. There is no special meaning for empty mailbox
2288 names when the extended syntax is used.
2289
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
2295 name arguments.
2296
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
2301 working directory.
2302
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.
2307
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.
2313
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.
2325
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
2334 naming context.
2335
2336 Here are some examples of how references and mailbox names might be
2337 interpreted on a UNIX-based server:
2338
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 +--------------+--------------+-------------------+
2352
2353 Table 1
2354
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.
2360
2361 The character "*" is a wildcard and matches zero or more characters
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).
2369
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.
2373
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.)
2382
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.
2391
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
2398 support. A server MUST respond to options it does not recognize with
2399 a BAD response. The client SHOULD NOT specify any option more than
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.
2403
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.
2411
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.
2417
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.
2424
24256.3.9.1. LIST Selection Options
2426
2427 The selection options defined in this specification are as follows:
2428
2429 SUBSCRIBED
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.
2436
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.
2441
2442 Note that the SUBSCRIBED selection option implies the SUBSCRIBED
2443 return option (see below).
2444
2445 REMOTE
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.
2451
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.
2455
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.
2464
2465 RECURSIVEMATCH
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.
2470
2471 Note 1: In order for a parent mailbox to be returned, it still
2472 has to match the canonical LIST pattern.
2473
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.
2477
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.
2482
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.
2489
24906.3.9.2. LIST Return Options
2491
2492 The return options defined in this specification are as follows:
2493
2494 SUBSCRIBED
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.
2506
2507 CHILDREN
2508 Requests mailbox child information as originally proposed in
2509 [RFC3348]. See Section 6.3.9.5, below, for details.
2510
2511 STATUS
2512 Requests STATUS response for each matching mailbox.
2513
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
2519 described below.
2520
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
2529 STATUS information.
2530
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
2534 tagged OK reply.
2535
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.
2539
25406.3.9.3. General Principles for Returning LIST Responses
2541
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.
2546
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.
2552
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):
2557
2558 A. The mailbox name also satisfies the selection criteria.
2559
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
2563 LIST pattern.
2564
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.
2569
2570 3. Attributes returned in the same LIST response are treated
2571 additively. For example, the following response
2572
2573 S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
2574
2575 means that the "Fruit/Peach" mailbox doesn't exist, but it is
2576 subscribed.
2577
25786.3.9.4. Additional LIST-Related Requirements on Clients
2579
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
2585 server.
2586
2587 The following table summarizes inference rules.
2588
2589 +====================+===================+
2590 | returned attribute | implied attribute |
2591 +====================+===================+
2592 | \NoInferiors | \HasNoChildren |
2593 +--------------------+-------------------+
2594 | \NonExistent | \NoSelect |
2595 +--------------------+-------------------+
2596
2597 Table 2
2598
25996.3.9.5. The CHILDREN Return Option
2600
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
2604 specified.
2605
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
2625 expensive.
2626
2627 \HasChildren
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.
2642
2643 \HasNoChildren
2644 The presence of this attribute indicates that the mailbox has NO
2645 child mailboxes that are accessible to the currently
2646 authenticated user.
2647
2648 It is an error for the server to return both a \HasChildren and a
2649 \HasNoChildren attribute in the same LIST response.
2650
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.
2654
26556.3.9.6. CHILDINFO Extended Data Item
2656
2657 The CHILDINFO extended data item MUST NOT be returned unless the
2658 client has specified the RECURSIVEMATCH selection option.
2659
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
2663 selection criteria.
2664
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.
2673
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.
2678
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.
2682
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.
2686
2687 The following table summarizes interaction between the "\NonExistent"
2688 attribute and CHILDINFO (the first column indicates whether the
2689 parent mailbox exists):
2690
2691 +========+===========+====================+=====================+
2692 | Exists | Meets the | Has a child that | Returned IMAP4rev2/ |
2693 | | selection | meets the | LIST-EXTENDED |
2694 | | criteria | selection criteria | attributes and |
2695 | | | | CHILDINFO |
2696 +========+===========+====================+=====================+
2697 | no | no | no | no LIST response |
2698 | | | | returned |
2699 +--------+-----------+--------------------+---------------------+
2700 | yes | no | no | no LIST response |
2701 | | | | returned |
2702 +--------+-----------+--------------------+---------------------+
2703 | no | yes | no | (\NonExistent |
2704 | | | | <attr>) |
2705 +--------+-----------+--------------------+---------------------+
2706 | yes | yes | no | (<attr>) |
2707 +--------+-----------+--------------------+---------------------+
2708 | no | no | yes | (\NonExistent) + |
2709 | | | | CHILDINFO |
2710 +--------+-----------+--------------------+---------------------+
2711 | yes | no | yes | () + CHILDINFO |
2712 +--------+-----------+--------------------+---------------------+
2713 | no | yes | yes | (\NonExistent |
2714 | | | | <attr>) + CHILDINFO |
2715 +--------+-----------+--------------------+---------------------+
2716 | yes | yes | yes | (<attr>) + |
2717 | | | | CHILDINFO |
2718 +--------+-----------+--------------------+---------------------+
2719
2720 Table 3
2721
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.
2725
27266.3.9.7. OLDNAME Extended Data Item
2727
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
2733 be included.
2734
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.
2742
2743 A deleted mailbox can be announced as follows:
2744
2745 S: * LIST (\NonExistent) "." "INBOX.DeletedMailbox"
2746
2747 Example of a renamed mailbox:
2748
2749 S: * LIST () "/" "NewMailbox" ("OLDNAME" ("OldMailbox"))
2750
27516.3.9.8. LIST Command Examples
2752
2753 This example shows some uses of the basic LIST command:
2754
2755 Example:
2756
2757 C: A101 LIST "" ""
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
2770
2771 Extended examples:
2772
2773 1: The first example shows the complete local hierarchy that will
2774 be used for the other examples.
2775
2776 C: A01 LIST "" "*"
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"
2785 S: A01 OK done
2786
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
2795 well.
2796
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"
2803 S: A02 OK done
2804
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
2811 a stronger meaning.
2812
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"
2818 S: A03 OK done
2819
2820 4: In this example, we see more mailboxes that reside on another
2821 server. This is similar to the command <RLIST "" "%">.
2822
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"
2830 S: A04 OK done
2831
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
2837 options.
2838
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"
2846 S: A05 OK done
2847
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.
2852
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".
2856
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"
2868 S: A06 OK done
2869
2870 7: The following example demonstrates the difference between the
2871 \HasChildren attribute and the CHILDINFO extended data item.
2872
2873 Let's assume there is the following hierarchy:
2874
2875 C: C01 LIST "" "*"
2876 S: * LIST (\Marked \NoInferiors) "/" "inbox"
2877 S: * LIST () "/" "Foo"
2878 S: * LIST () "/" "Foo/Bar"
2879 S: * LIST () "/" "Foo/Baz"
2880 S: * LIST () "/" "Moo"
2881 S: C01 OK done
2882
2883 If the client asks RETURN (CHILDREN), it will get this:
2884
2885 C: CA3 LIST "" "%" RETURN (CHILDREN)
2886 S: * LIST (\Marked \NoInferiors) "/" "inbox"
2887 S: * LIST (\HasChildren) "/" "Foo"
2888 S: * LIST (\HasNoChildren) "/" "Moo"
2889 S: CA3 OK done
2890
2891 A) Let's also assume that the mailbox "Foo/Baz" is the only
2892 subscribed mailbox. Then we get this result:
2893
2894 C: C02 LIST (SUBSCRIBED) "" "*"
2895 S: * LIST (\Subscribed) "/" "Foo/Baz"
2896 S: C02 OK done
2897
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
2901 client issues this:
2902
2903 C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
2904 S: * LIST () "/" "Foo" ("CHILDINFO" ("SUBSCRIBED"))
2905 S: C04 OK done
2906
2907 (that is, the mailbox "Foo" is not subscribed, but it has a
2908 child that is), then A1 or A2 occurs.
2909
2910 A1) If the mailbox "Foo" had also been subscribed, the last
2911 command would return this:
2912
2913 C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
2914 S: * LIST (\Subscribed) "/" "Foo" ("CHILDINFO"
2915 ("SUBSCRIBED"))
2916 S: C04 OK done
2917
2918 or even this:
2919
2920 C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
2921 S: * LIST (\Subscribed \HasChildren) "/" "Foo"
2922 ("CHILDINFO" ("SUBSCRIBED"))
2923 S: C04 OK done
2924
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:
2928
2929 C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
2930 S: * LIST (\NonExistent) "/" "Foo" ("CHILDINFO"
2931 ("SUBSCRIBED"))
2932 S: C04 OK done
2933
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).
2938
2939 C) And finally, suppose that only the mailboxes "Foo" and "Moo"
2940 are subscribed. In that case, we see this result:
2941
2942 C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" RETURN
2943 (CHILDREN)
2944 S: * LIST (\HasChildren \Subscribed) "/" "Foo"
2945 S: * LIST (\HasNoChildren \Subscribed) "/" "Moo"
2946 S: C04 OK done
2947
2948 (which means that the mailbox "Foo" has children, but none
2949 of them is subscribed).
2950
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.
2954
2955 Let's assume there is the following hierarchy:
2956
2957 C: D01 LIST "" "*"
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"
2969 S: D01 OK done
2970
2971 And that the following mailboxes are subscribed:
2972
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"
2982 S: D02 OK done
2983
2984 The client issues the following command first:
2985
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"
2994 S: D03 OK done
2995
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
2998 redundant):
2999
3000 S: * LIST () "/" "baz2" ("CHILDINFO" ("SUBSCRIBED"))
3001 S: * LIST (\NonExistent) "/" "qux2" ("CHILDINFO" ("SUBSCRIBED"))
3002
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
3009 the pattern.
3010
3011 Note that if the client issues the following:
3012
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"
3024 S: D03 OK done
3025
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
3029 itself.
3030
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
3034 \HasChildren.
3035
3036 C: a1 LIST "" ("foo")
3037 S: * LIST () "/" foo
3038 S: a1 OK done
3039
3040 C: a2 LIST (SUBSCRIBED) "" "foo/*"
3041 S: * LIST (\Subscribed \NonExistent) "/" foo/bar
3042 S: a2 OK done
3043
3044 C: a3 LIST (SUBSCRIBED RECURSIVEMATCH) "" foo RETURN (CHILDREN)
3045 S: * LIST (\HasNoChildren) "/" foo ("CHILDINFO" ("SUBSCRIBED"))
3046 S: a3 OK done
3047
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.
3052
3053 C: a1 LIST (REMOTE) "" *
3054 S: * LIST () "/" music/rock
3055 S: * LIST (\Remote) "/" also/jazz
3056 S: a1 OK done
3057
3058 C: a2 LIST () "" %
3059 S: * LIST (\NonExistent \HasChildren) "/" music
3060 S: a2 OK done
3061
3062 C: a3 LIST (REMOTE) "" %
3063 S: * LIST (\NonExistent \HasChildren) "/" music
3064 S: * LIST (\NonExistent \HasChildren) "/" also
3065 S: a3 OK done
3066
3067 C: a3.1 LIST "" (% music/rock)
3068 S: * LIST () "/" music/rock
3069 S: a3.1 OK done
3070
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.
3074
3075 11: The following examples show use of the STATUS return option.
3076
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.
3084
3085 The "bar" mailbox isn't selectable, so it has no STATUS reply.
3086
3087 C: A02 LIST (SUBSCRIBED RECURSIVEMATCH) "" % RETURN (STATUS
3088 (MESSAGES))
3089 S: * LIST (\Subscribed) "." "INBOX"
3090 S: * STATUS "INBOX" (MESSAGES 17)
3091 S: * LIST () "." "foo" (CHILDINFO ("SUBSCRIBED"))
3092 S: A02 OK List completed.
3093
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.
3097
30986.3.10. NAMESPACE Command
3099
3100 Arguments: none
3101
3102 Responses: REQUIRED untagged responses: NAMESPACE
3103
3104 Result: OK - command completed
3105 NO - Can't complete the command
3106 BAD - arguments invalid
3107
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
3115 NAMESPACE response.
3116
3117 Example 1:
3118
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.
3122
3123 C: A001 NAMESPACE
3124 S: * NAMESPACE (("" "/")) NIL NIL
3125 S: A001 OK NAMESPACE command completed
3126
3127 Example 2:
3128
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 "."
3133
3134 C: A001 NAMESPACE
3135 S: * NAMESPACE NIL NIL (("" "."))
3136 S: A001 OK NAMESPACE command completed
3137
3138 Example 3:
3139
3140 A server that contains a Personal Namespace and a single Shared
3141 Namespace.
3142
3143 C: A001 NAMESPACE
3144 S: * NAMESPACE (("" "/")) NIL (("Public Folders/" "/"))
3145 S: A001 OK NAMESPACE command completed
3146
3147 Example 4:
3148
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.
3152
3153 C: A001 NAMESPACE
3154 S: * NAMESPACE (("" "/")) (("~" "/")) (("#shared/" "/")
3155 ("#public/" "/")("#ftp/" "/")("#news." "."))
3156 S: A001 OK NAMESPACE command completed
3157
3158 The prefix string allows a client to do things such as automatically
3159 create personal mailboxes or LIST all available mailboxes within a
3160 namespace.
3161
3162 Example 5:
3163
3164 A server that supports only the Personal Namespace, with a leading
3165 prefix of INBOX to personal mailboxes and a hierarchy delimiter of
3166 ".".
3167
3168 C: A001 NAMESPACE
3169 S: * NAMESPACE (("INBOX." ".")) NIL NIL
3170 S: A001 OK NAMESPACE command completed
3171
3172 Automatically create a mailbox to store sent items.
3173
3174 C: A002 CREATE "INBOX.Sent Mail"
3175 S: A002 OK CREATE command completed
3176
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
3185 Namespace.
3186
3187 Example 6:
3188
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.
3193
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.
3203
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.
3207
3208 C: A001 NAMESPACE
3209 S: * NAMESPACE (("" "/")("#mh/" "/" "X-PARAM"
3210 ("FLAG1" "FLAG2"))) NIL NIL
3211 S: A001 OK NAMESPACE command completed
3212
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
3220
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
3228
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.
3233
3234 C: A004 CREATE "Sent Mail"
3235 S: A004 OK CREATE command completed
3236
3237 The client is designed so that it keeps two 'Deleted Items'
3238 mailboxes, one for each namespace.
3239
3240 C: A005 CREATE "Delete Items"
3241 S: A005 OK CREATE command completed
3242
3243 C: A006 CREATE "#mh/Deleted Items"
3244 S: A006 OK CREATE command completed
3245
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.
3249
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.
3253
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
3256 user in question.
3257
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.
3260
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.
3264
3265 Example 7:
3266
3267 A server that supports providing a list of other user's mailboxes
3268 that are accessible to the currently logged on user.
3269
3270 C: A001 NAMESPACE
3271 S: * NAMESPACE (("" "/")) (("Other Users/" "/")) NIL
3272 S: A001 OK NAMESPACE command completed
3273
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
3280
3281 Example 8:
3282
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.
3287
3288 C: A001 NAMESPACE
3289 S: * NAMESPACE (("" "/")) (("#Users/" "/")) NIL
3290 S: A001 OK NAMESPACE command completed
3291
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.
3298
3299 C: A002 LIST "" "#Users/%"
3300 S: A002 NO The requested item could not be found.
3301
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.
3306
3307 A prefix string might not contain a hierarchy delimiter, because in
3308 some cases, it is not needed as part of the prefix.
3309
3310 Example 9:
3311
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
3315 command.
3316
3317 C: A001 NAMESPACE
3318 S: * NAMESPACE (("" "/")) (("~" "/")) NIL
3319 S: A001 OK NAMESPACE command completed
3320
3321 List the mailboxes for user mark
3322
3323 C: A002 LIST "" "~mark/%"
3324 S: * LIST () "/" "~mark/INBOX"
3325 S: * LIST () "/" "~mark/foo"
3326 S: A002 OK LIST command completed
3327
33286.3.11. STATUS Command
3329
3330 Arguments: mailbox name
3331
3332 status data item names
3333
3334 Responses: REQUIRED untagged responses: STATUS
3335
3336 Result: OK - status completed
3337 NO - status failure: no status for that name
3338 BAD - command unknown or arguments invalid
3339
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.
3343
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.
3348
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.
3355
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
3364 LIST command.)
3365
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
3369 checking).
3370
3371 STATUS SIZE (see below) can take a significant amount of time,
3372 depending upon server implementation. Clients should use STATUS
3373 SIZE cautiously.
3374
3375 The currently defined status data items that can be requested are:
3376
3377 MESSAGES
3378 The number of messages in the mailbox.
3379
3380 UIDNEXT
3381 The next unique identifier value of the mailbox. Refer to
3382 Section 2.3.1.1 for more information.
3383
3384 UIDVALIDITY
3385 The unique identifier validity value of the mailbox. Refer to
3386 Section 2.3.1.1 for more information.
3387
3388 UNSEEN
3389 The number of messages that do not have the \Seen flag set.
3390
3391 DELETED
3392 The number of messages that have the \Deleted flag set.
3393
3394 SIZE
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.
3399
3400 Example:
3401
3402 C: A042 STATUS blurdybloop (UIDNEXT MESSAGES)
3403 S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
3404 S: A042 OK STATUS completed
3405
34066.3.12. APPEND Command
3407
3408 Arguments: mailbox name
3409
3410 OPTIONAL flag parenthesized list
3411
3412 OPTIONAL date/time string
3413
3414 message literal
3415
3416 Responses: OPTIONAL untagged response: LIST
3417
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
3422
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.
3430
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.
3435
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.
3439
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.
3443
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
3447 permitted.
3448
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
3455 successful.
3456
3457 On successful completion of an APPEND, the server returns an
3458 APPENDUID response code (see Section 7.1), unless otherwise specified
3459 below.
3460
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.
3465
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
3468 is not meaningful.
3469
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
3474 commands.
3475
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
3480 for more details.)
3481
3482 Example:
3483
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
3493 C:
3494 C: Hello Joe, do you think we can meet at 3:30 tomorrow?
3495 C:
3496 S: A003 OK APPEND completed
3497
3498 Example:
3499
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
3508 C:
3509 C: Hello Joe, do you think we can meet at 3:30 tomorrow?
3510 C:
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
3517 S: A006 OK Done
3518 C: A007 SELECT funny
3519 S: * 1 EXISTS
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
3527
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.
3537
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.
3541
35426.3.13. IDLE Command
3543
3544 Arguments: none
3545
3546 Responses: continuation data will be requested; the client sends
3547 the continuation data "DONE" to end the command
3548
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
3553
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.
3560
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.
3569
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.
3580
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.
3588
3589 Example:
3590
3591 C: A001 SELECT INBOX
3592 S: * FLAGS (\Deleted \Seen \Flagged)
3593 S: * OK [PERMANENTFLAGS (\Deleted \Seen \Flagged)] Limited
3594 S: * 3 EXISTS
3595 S: * OK [UIDVALIDITY 1]
3596 S: * OK [UIDNEXT 1]
3597 S: * LIST () "/" INBOX
3598 S: A001 OK [READ-WRITE] SELECT completed
3599 C: A002 IDLE
3600 S: + idling
3601 ...time passes; new mail arrives...
3602 S: * 4 EXISTS
3603 C: DONE
3604 S: A002 OK IDLE terminated
3605 ...another client expunges message 2 now...
3606 C: A003 FETCH 4 ALL
3607 S: * 4 FETCH (...)
3608 S: A003 OK FETCH completed
3609 C: A004 IDLE
3610 S: * 2 EXPUNGE
3611 S: * 3 EXISTS
3612 S: + idling
3613 ...time passes; another client expunges message 3...
3614 S: * 3 EXPUNGE
3615 S: * 2 EXISTS
3616 ...time passes; new mail arrives...
3617 S: * 3 EXISTS
3618 C: DONE
3619 S: A004 OK IDLE terminated
3620 C: A005 FETCH 3 ALL
3621 S: * 3 FETCH (...)
3622 S: A005 OK FETCH completed
3623 C: A006 IDLE
3624
36256.4. Client Commands - Selected State
3626
3627 In the selected state, commands that manipulate messages in a mailbox
3628 are permitted.
3629
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.
3635
36366.4.1. CLOSE Command
3637
3638 Arguments: none
3639
3640 Responses: no specific responses for this command
3641
3642 Result: OK - close completed, now in authenticated state
3643 BAD - command unknown or arguments invalid
3644
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.
3649
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.
3652
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
3660 ignore) are sent.
3661
3662 Example:
3663
3664 C: A341 CLOSE
3665 S: A341 OK CLOSE completed
3666
36676.4.2. UNSELECT Command
3668
3669 Arguments: none
3670
3671 Responses: no specific responses for this command
3672
3673 Result: OK - unselect completed, now in authenticated state
3674 BAD - no mailbox selected, or argument supplied but
3675 none permitted
3676
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.
3681
3682 Example:
3683
3684 C: A342 UNSELECT
3685 S: A342 OK Unselect completed
3686
36876.4.3. EXPUNGE Command
3688
3689 Arguments: none
3690
3691 Responses: untagged responses: EXPUNGE
3692
3693 Result: OK - expunge completed
3694 NO - expunge failure: can't expunge (e.g., permission
3695 denied)
3696 BAD - command unknown or arguments invalid
3697
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.
3702
3703 Example:
3704
3705 C: A202 EXPUNGE
3706 S: * 3 EXPUNGE
3707 S: * 3 EXPUNGE
3708 S: * 5 EXPUNGE
3709 S: * 8 EXPUNGE
3710 S: A202 OK EXPUNGE completed
3711
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.
3715
37166.4.4. SEARCH Command
3717
3718 Arguments: OPTIONAL result specifier
3719
3720 OPTIONAL [CHARSET] specification
3721
3722 searching criteria (one or more)
3723
3724 Responses: OPTIONAL untagged response: ESEARCH
3725
3726 Result: OK - search completed
3727 NO - search error: can't search that [CHARSET] or
3728 criteria
3729 BAD - command unknown or arguments invalid
3730
3731 The SEARCH command searches the mailbox for messages that match the
3732 given searching criteria.
3733
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
3737 option is specified or empty list of options is specified as "()",
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
3745 order. Any options not defined by extensions that the server
3746 supports MUST be rejected with a BAD response.
3747
3748 Note that IMAP4rev1 used SEARCH responses [RFC3501] instead of
3749 ESEARCH responses. Clients that support only IMAP4rev2 MUST ignore
3750 SEARCH responses.
3751
3752 This document specifies the following result options:
3753
3754 MIN
3755 Return the lowest message number/UID that satisfies the SEARCH
3756 criteria.
3757
3758 If the SEARCH results in no matches, the server MUST NOT include
3759 the MIN result option in the ESEARCH response; however, it still
3760 MUST send the ESEARCH response.
3761
3762 MAX
3763 Return the highest message number/UID that satisfies the SEARCH
3764 criteria.
3765
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.
3769
3770 ALL
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.
3774
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.
3778
3779 COUNT
3780 Return the number of messages that satisfy the SEARCH criteria.
3781 This result option MUST always be included in the ESEARCH
3782 response.
3783
3784 SAVE
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.
3799
3800 In absence of any other SEARCH result option, the SAVE result
3801 option also suppresses any ESEARCH response that would have been
3802 otherwise returned by the SEARCH command.
3803
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.
3811
3812 Searching criteria consist of one or more search keys.
3813
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).
3820
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.
3824
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.
3835
3836 If the server does not support the specified [CHARSET], it MUST
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.
3840
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.
3848
3849 The defined search keys are as follows. Refer to "Formal Syntax"
3850 (Section 9) for the precise syntactic definitions of the arguments.
3851
3852 <sequence set>
3853 Messages with message sequence numbers corresponding to the
3854 specified message sequence number set.
3855
3856 ALL
3857 All messages in the mailbox; the default initial key for ANDing.
3858
3859 ANSWERED
3860 Messages with the \Answered flag set.
3861
3862 BCC <string>
3863 Messages that contain the specified string in the envelope
3864 structure's Blind Carbon Copy (BCC) field.
3865
3866 BEFORE <date>
3867 Messages whose internal date (disregarding time and timezone) is
3868 earlier than the specified date.
3869
3870 BODY <string>
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").
3877
3878 CC <string>
3879 Messages that contain the specified string in the envelope
3880 structure's CC field.
3881
3882 DELETED
3883 Messages with the \Deleted flag set.
3884
3885 DRAFT
3886 Messages with the \Draft flag set.
3887
3888 FLAGGED
3889 Messages with the \Flagged flag set.
3890
3891 FROM <string>
3892 Messages that contain the specified string in the envelope
3893 structure's FROM field.
3894
3895 HEADER <field-name> <string>
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.
3907
3908 KEYWORD <flag>
3909 Messages with the specified keyword flag set.
3910
3911 LARGER <n>
3912 Messages with an RFC822.SIZE larger than the specified number of
3913 octets.
3914
3915 NOT <search-key>
3916 Messages that do not match the specified search key.
3917
3918 ON <date>
3919 Messages whose internal date (disregarding time and timezone) is
3920 within the specified date.
3921
3922 OR <search-key1> <search-key2>
3923 Messages that match either search key.
3924
3925 SEEN
3926 Messages that have the \Seen flag set.
3927
3928 SENTBEFORE <date>
3929 Messages whose [RFC5322] Date: header field (disregarding time and
3930 timezone) is earlier than the specified date.
3931
3932 SENTON <date>
3933 Messages whose [RFC5322] Date: header field (disregarding time and
3934 timezone) is within the specified date.
3935
3936 SENTSINCE <date>
3937 Messages whose [RFC5322] Date: header field (disregarding time and
3938 timezone) is within or later than the specified date.
3939
3940 SINCE <date>
3941 Messages whose internal date (disregarding time and timezone) is
3942 within or later than the specified date.
3943
3944 SMALLER <n>
3945 Messages with an RFC822.SIZE smaller than the specified number of
3946 octets.
3947
3948 SUBJECT <string>
3949 Messages that contain the specified string in the envelope
3950 structure's SUBJECT field.
3951
3952 TEXT <string>
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").
3959
3960 TO <string>
3961 Messages that contain the specified string in the envelope
3962 structure's TO field.
3963
3964 UID <sequence set>
3965 Messages with unique identifiers corresponding to the specified
3966 unique identifier set. Sequence-set ranges are permitted.
3967
3968 UNANSWERED
3969 Messages that do not have the \Answered flag set.
3970
3971 UNDELETED
3972 Messages that do not have the \Deleted flag set.
3973
3974 UNDRAFT
3975 Messages that do not have the \Draft flag set.
3976
3977 UNFLAGGED
3978 Messages that do not have the \Flagged flag set.
3979
3980 UNKEYWORD <flag>
3981 Messages that do not have the specified keyword flag set.
3982
3983 UNSEEN
3984 Messages that do not have the \Seen flag set.
3985
3986 Example:
3987
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
3992
3993 Example:
3994
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
3999
4000 Example:
4001
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
4007 C: отпуск
4008 S: * ESEARCH (TAG "A285") ALL 43
4009 S: A285 OK SEARCH completed
4010
4011
4012 The following example demonstrates finding the first unseen message
4013 in the mailbox:
4014
4015 Example:
4016
4017 C: A284 SEARCH RETURN (MIN) UNSEEN
4018 S: * ESEARCH (TAG "A284") MIN 4
4019 S: A284 OK SEARCH completed
4020
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.
4024
4025 Example:
4026
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
4030
4031 The following example demonstrates returning the number of deleted
4032 messages:
4033
4034 Example:
4035
4036 C: A286 SEARCH RETURN (COUNT) DELETED
4037 S: * ESEARCH (TAG "A286") COUNT 15
4038 S: A286 OK SEARCH completed
4039
40406.4.4.1. SAVE Result Option and SEARCH Result Variable
4041
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.
4045
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.
4050
4051 Any of the following SEARCH commands MUST NOT change the search
4052 result variable:
4053
4054 a SEARCH command that caused the server to return the BAD tagged
4055 response,
4056
4057 a SEARCH command with no SAVE result option that caused the server
4058 to return NO tagged response, and
4059
4060 a successful SEARCH command with no SAVE result option.
4061
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.
4065
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.
4071
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
4074 the empty sequence.
4075
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.
4081
4082 The SAVE result option doesn't change whether the server would return
4083 items corresponding to MIN, MAX, ALL, or COUNT result options.
4084
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.
4090
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.
4095
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.
4099
4100 The following table summarizes the additional requirement on ESEARCH
4101 server implementations described in this section.
4102
4103 +==============================+====================+
4104 | Combination of Result Option | "$" Marker Value |
4105 +==============================+====================+
4106 | SAVE MIN | MIN |
4107 +------------------------------+--------------------+
4108 | SAVE MAX | MAX |
4109 +------------------------------+--------------------+
4110 | SAVE MIN MAX | MIN & MAX |
4111 +------------------------------+--------------------+
4112 | SAVE * [m] | all found messages |
4113 +------------------------------+--------------------+
4114
4115 Table 4
4116
4117 where '*' means "ALL" and/or "COUNT", and '[m]' means optional "MIN"
4118 and/or "MAX"
4119
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.
4130
41316.4.4.2. Multiple Commands in Progress
4132
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.
4137
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.
4142
41436.4.4.3. Refusing to Save Search Results
4144
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.
4150
41516.4.4.4. Examples Showing Use of the SAVE Result Option
4152
4153 Only in this section: explanatory comments in examples that start
4154 with // are not part of the protocol.
4155
4156 1. The following example demonstrates how the client can use the
4157 result of a SEARCH command to FETCH headers of interesting
4158 messages:
4159
4160 Example 1:
4161
4162 C: A282 SEARCH RETURN (SAVE) FLAGGED SINCE 1-Feb-1994
4163 NOT FROM "Smith"
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
4170
4171 The client can also pipeline the two commands:
4172
4173 Example 2:
4174
4175 C: A282 SEARCH RETURN (SAVE) FLAGGED SINCE 1-Feb-1994
4176 NOT FROM "Smith"
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
4183
4184 2. The following example demonstrates that the result of one SEARCH
4185 command can be used as input to another SEARCH command:
4186
4187 Example 3:
4188
4189 C: A300 SEARCH RETURN (SAVE) SINCE 1-Jan-2004
4190 NOT FROM "Smith"
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
4195
4196 Note that the second command in Example 3 can be replaced with:
4197
4198 C: A301 UID SEARCH $ SMALLER 4096
4199
4200 and the result of the command would be the same.
4201
4202 3. The following example shows that the "$" marker can be combined
4203 with other message numbers using the OR SEARCH criterion.
4204
4205 Example 4:
4206
4207 C: P282 SEARCH RETURN (SAVE) SINCE 1-Feb-1994
4208 NOT FROM "Smith"
4209 S: P282 OK SEARCH completed
4210 C: P283 SEARCH CHARSET UTF-8 (OR $ 1,3000:3021) TEXT {8+}
4211 C: мать
4212 S: * ESEARCH (TAG "P283") ALL 882,1102,3003,3005:3006
4213 S: P283 OK completed
4214
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.
4218
4219 Example 5:
4220
4221 C: B282 SEARCH RETURN (SAVE) SINCE 1-Feb-1994
4222 NOT FROM "Smith"
4223 S: B282 OK SEARCH completed
4224 C: B283 SEARCH RETURN (SAVE) CHARSET KOI8-R
4225 (OR $ 1,3000:3021) TEXT {4}
4226 C: XXXX
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
4237 //instead.
4238
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
4242 actual transaction.
4243
4244 5. The following example demonstrates that it is not an error to use
4245 the "$" marker when it contains no messages.
4246
4247 Example 6:
4248
4249 C: E282 SEARCH RETURN (SAVE) SINCE 28-Oct-2006
4250 NOT FROM "Eric"
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
4255
4256 Example 7:
4257
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
4264
4265 Example 8:
4266
4267 C: G282 SEARCH RETURN (SAVE) KEYWORD $Junk
4268 C: G283 SEARCH RETURN (ALL) SINCE 28-Oct-2006
4269 FROM "Eric"
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
4276
4277 The following example demonstrates that the result of the second
4278 SEARCH RETURN (SAVE) always overrides the result of the first.
4279
4280 Example 9:
4281
4282 C: H282 SEARCH RETURN (SAVE) KEYWORD $Junk
4283 C: H283 SEARCH RETURN (SAVE) SINCE 28-Oct-2006
4284 FROM "Eric"
4285 S: H282 OK SEARCH completed
4286 S: H283 OK SEARCH completed
4287 // At this point "$" would contain results of H283
4288
4289 The following example demonstrates behavioral difference for
4290 different combinations of ESEARCH result options.
4291
4292 Example 10:
4293
4294 C: C282 SEARCH RETURN (ALL) SINCE 12-Feb-2006
4295 NOT FROM "Smith"
4296 S: * ESEARCH (TAG "C283") ALL 2,10:15,21
4297 //$ value hasn't changed
4298 S: C282 OK SEARCH completed
4299
4300 C: C283 SEARCH RETURN (ALL SAVE) SINCE 12-Feb-2006
4301 NOT FROM "Smith"
4302 S: * ESEARCH (TAG "C283") ALL 2,10:15,21
4303 //$ value is 2,10:15,21
4304 S: C283 OK SEARCH completed
4305
4306 C: C284 SEARCH RETURN (SAVE MIN) SINCE 12-Feb-2006
4307 NOT FROM "Smith"
4308 S: * ESEARCH (TAG "C284") MIN 2
4309 //$ value is 2
4310 S: C284 OK SEARCH completed
4311
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
4315 //$ value is 2,21
4316 S: C285 OK SEARCH completed
4317
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
4323
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
4329
43306.4.5. FETCH Command
4331
4332 Arguments: sequence set
4333
4334 message data item names or macro
4335
4336 Responses: untagged responses: FETCH
4337
4338 Result: OK - fetch completed
4339 NO - fetch error: can't fetch that data
4340 BAD - command unknown or arguments invalid
4341
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.
4345
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.
4351
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.
4355
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.
4359
4360 ALL
4361 Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)
4362
4363 FAST
4364 Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE)
4365
4366 FULL
4367 Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE
4368 BODY)
4369
4370 Several data items reference "section" or "section-binary". See
4371 Section 6.4.5.1 for their detailed definition.
4372
4373 The currently defined data items that can be fetched are:
4374
4375 BINARY[<section-binary>]<<partial>>
4376 Requests that the specified section be transmitted after
4377 performing decoding of the section's Content-Transfer-Encoding.
4378
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
4383 section data.
4384
4385 Note that this data item can only be requested for leaf body
4386 parts: those that have media types other than multipart/*,
4387 message/rfc822, or message/global.
4388
4389 BINARY.PEEK[<section-binary>]<<partial>>
4390 An alternate form of BINARY[<section-binary>] that does not
4391 implicitly set the \Seen flag.
4392
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).
4396
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.
4401
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.
4405
4406 BODY
4407 Non-extensible form of BODYSTRUCTURE.
4408
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.
4413
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
4418 specifier. If the starting octet is beyond the end of the text,
4419 an empty string is returned.
4420
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
4424 happened.
4425
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[].
4428
4429 Note: A substring fetch of a HEADER.FIELDS or HEADER.FIELDS.NOT
4430 part specifier is calculated after subsetting the header.
4431
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.
4434
4435 BODY.PEEK[<section>]<<partial>>
4436 An alternate form of BODY[<section>] that does not implicitly set
4437 the \Seen flag.
4438
4439 BODYSTRUCTURE
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
4443 more details.
4444
4445 ENVELOPE
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
4449 more details.
4450
4451 FLAGS
4452 The flags that are set for this message.
4453
4454 INTERNALDATE
4455 The internal date of the message.
4456
4457 RFC822.SIZE
4458 The size of the message, as defined in Section 2.3.4.
4459
4460 UID
4461 The unique identifier for the message.
4462
4463 Example:
4464
4465 C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)])
4466 S: * 2 FETCH ....
4467 S: * 3 FETCH ....
4468 S: * 4 FETCH ....
4469 S: A654 OK FETCH completed
4470
44716.4.5.1. FETCH Section Specification
4472
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.
4480
4481 Every message has at least one part number. Messages that do not use
4482 MIME, and MIME messages that are not multipart and have no
4483 encapsulated message within them, only have a part 1.
4484
4485 Multipart messages are assigned consecutive part numbers, as they
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.
4489
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.
4492
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.
4497 The MIME part specifier MUST be prefixed by one or more numeric part
4498 specifiers.
4499
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.
4513
4514 The MIME part specifier refers to the [MIME-IMB] header for this
4515 part.
4516
4517 The TEXT part specifier refers to the text body of the message,
4518 omitting the [RFC5322] header.
4519
4520 Here is an example of a complex message with some of its part
4521 specifiers:
4522
4523 HEADER ([RFC5322] header of the message)
4524 TEXT ([RFC5322] text body of the message) MULTIPART/MIXED
4525 1 TEXT/PLAIN
4526 2 APPLICATION/OCTET-STREAM
4527 3 MESSAGE/RFC822
4528 3.HEADER ([RFC5322] header of the message)
4529 3.TEXT ([RFC5322] text body of the message) MULTIPART/MIXED
4530 3.1 TEXT/PLAIN
4531 3.2 APPLICATION/OCTET-STREAM
4532 4 MULTIPART/MIXED
4533 4.1 IMAGE/GIF
4534 4.1.MIME ([MIME-IMB] header for the IMAGE/GIF)
4535 4.2 MESSAGE/RFC822
4536 4.2.HEADER ([RFC5322] header of the message)
4537 4.2.TEXT ([RFC5322] text body of the message) MULTIPART/MIXED
4538 4.2.1 TEXT/PLAIN
4539 4.2.2 MULTIPART/ALTERNATIVE
4540 4.2.2.1 TEXT/PLAIN
4541 4.2.2.2 TEXT/RICHTEXT
4542
45436.4.6. STORE Command
4544
4545 Arguments: sequence set
4546
4547 message data item name
4548
4549 value for message data item
4550
4551 Responses: untagged responses: FETCH
4552
4553 Result: OK - store completed
4554 NO - store error: can't store that data
4555 BAD - command unknown or arguments invalid
4556
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.
4563
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
4568 condition.
4569
4570 The currently defined data items that can be stored are:
4571
4572 FLAGS <flag list>
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
4575 done.
4576
4577 FLAGS.SILENT <flag list>
4578 Equivalent to FLAGS, but without returning a new value.
4579
4580 +FLAGS <flag list>
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.
4583
4584 +FLAGS.SILENT <flag list>
4585 Equivalent to +FLAGS, but without returning a new value.
4586
4587 -FLAGS <flag list>
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.
4590
4591 -FLAGS.SILENT <flag list>
4592 Equivalent to -FLAGS, but without returning a new value.
4593
4594 Example:
4595
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
4601
46026.4.7. COPY Command
4603
4604 Arguments: sequence set
4605
4606 mailbox name
4607
4608 Responses: no specific responses for this command
4609
4610 Result: OK - copy completed
4611 NO - copy error: can't copy those messages or to that
4612 name
4613 BAD - command unknown or arguments invalid
4614
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.
4618
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
4625 successful.
4626
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.
4631
4632 On successful completion of a COPY, the server returns a COPYUID
4633 response code (see Section 7.1). Two exceptions to this requirement
4634 are listed below.
4635
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.
4640
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
4643 not meaningful.
4644
4645 Example:
4646
4647 C: A003 COPY 2:4 MEETING
4648 S: A003 OK [COPYUID 38505 304,319:320 3956:3958] COPY completed
4649
46506.4.8. MOVE Command
4651
4652 Arguments: sequence set
4653
4654 mailbox name
4655
4656 Responses: no specific responses for this command
4657
4658 Result: OK - move completed
4659 NO - move error: can't move those messages or to that
4660 name
4661 BAD - command unknown or arguments invalid
4662
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.
4666
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:
4671
4672 1. [UID] COPY
4673
4674 2. [UID] STORE +FLAGS.SILENT \DELETED
4675
4676 3. UID EXPUNGE
4677
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.
4684
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.
4694
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
4701 successful.
4702
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
4706 indicated for COPY.
4707
4708 Servers send COPYUID in response to a MOVE or a UID MOVE (see
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.
4712
4713 Servers are also REQUIRED to send the COPYUID response code in an
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.)
4719
4720 An example:
4721
4722 C: a UID MOVE 42:69 foo
4723 S: * OK [COPYUID 432432 42:69 1202:1229]
4724 S: * 22 EXPUNGE
4725 ...More EXPUNGE responses from the server...
4726 S: a OK Done
4727
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
4730 IMAP operation.
4731
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
4735 allowed.
4736
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.
4740
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.
4750
47516.4.9. UID Command
4752
4753 Arguments: command name
4754
4755 command arguments
4756
4757 Responses: untagged responses: FETCH, ESEARCH, EXPUNGE
4758
4759 Result: OK - UID command completed
4760 NO - UID command error
4761 BAD - command unknown or arguments invalid
4762
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.
4769
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.
4774
4775 In the second form, the UID command takes an EXPUNGE command with an
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.
4782
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.
4789
4790 Example:
4791
4792 C: A003 UID EXPUNGE 3000:3002
4793 S: * 3 EXPUNGE
4794 S: * 3 EXPUNGE
4795 S: * 3 EXPUNGE
4796 S: A003 OK UID EXPUNGE completed
4797
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.
4807
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.
4813
4814 Also note that a UID range of 559:* always includes the UID of the
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
4820 mailbox is empty.
4821
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.
4828
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
4834 commands as well.
4835
4836 Example:
4837
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
4843
48446.5. Client Commands - Experimental/Expansion
4845
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.)
4849
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).
4854
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
4859 be the same.)
4860
4861 Example:
4862
4863 C: a441 CAPABILITY
4864 S: * CAPABILITY IMAP4rev2 XPIG-LATIN
4865 S: a441 OK CAPABILITY completed
4866 C: A442 XPIG-LATIN
4867 S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay
4868 S: A442 OK XPIG-LATIN ompleted-cay
4869
48707. Server Responses
4871
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"
4877 (Section 9).
4878
4879 The client MUST be prepared to accept any response at all times.
4880
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.
4884
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
4892 "unsolicited".
4893
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).
4899
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.
4904
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
4915 messages.
4916
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
4920 the command.
4921
49227.1. Server Responses - Generic Status Responses
4923
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.
4926
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
4933 information.
4934
4935 The currently defined response codes are:
4936
4937 ALERT
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.
4947
4948 ALREADYEXISTS
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.
4952
4953 C: o356 RENAME this that
4954 S: o356 NO [ALREADYEXISTS] Mailbox "that" already exists
4955
4956 APPENDUID
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.
4961
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
4967 the symbol "*".
4968
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.
4974
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.
4978
4979 This response code is returned in a tagged OK response to the
4980 APPEND command.
4981
4982 AUTHENTICATIONFAILED
4983 Authentication failed for some reason on which the server is
4984 unwilling to elaborate. Typically, this includes "unknown user"
4985 and "bad password".
4986
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.
4991
4992 C: b LOGIN "fred" "foo"
4993 S: b NO [AUTHENTICATIONFAILED] Authentication failed
4994
4995 AUTHORIZATIONFAILED
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
5000 are different.
5001
5002 C: c1 AUTHENTICATE PLAIN
5003 [...]
5004 S: c1 NO [AUTHORIZATIONFAILED] No such authorization-ID
5005
5006 C: c2 AUTHENTICATE PLAIN
5007 [...]
5008 S: c2 NO [AUTHORIZATIONFAILED] Authenticator is not an admin
5009
5010 BADCHARSET
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.
5015
5016 CANNOT
5017 This operation violates some invariant of the server and can never
5018 succeed.
5019
5020 C: l create "///////"
5021 S: l NO [CANNOT] Adjacent slashes are not supported
5022
5023 CAPABILITY
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.
5031
5032 CLIENTBUG
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.
5035
5036 C: k1 select "/archive/projects/experiment-iv"
5037 [...]
5038 S: k1 OK [READ-ONLY] Done
5039 C: k2 status "/archive/projects/experiment-iv" (messages)
5040 [...]
5041 S: k2 OK [CLIENTBUG] Done
5042
5043 CLOSED
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.
5052
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
5056 one.
5057
5058 CONTACTADMIN
5059 The user should contact the system administrator or support desk.
5060
5061 C: e login "fred" "foo"
5062 S: e NO [CONTACTADMIN]
5063
5064 COPYUID
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).
5071
5072 The source UID set is in the order the message(s) was copied; the
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 "*".
5076
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.
5080
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
5083 UID MOVE command.
5084
5085 CORRUPTION
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
5089 logfiles.
5090
5091 C: i select "/archive/projects/experiment-iv"
5092 S: i NO [CORRUPTION] Cannot open mailbox
5093
5094 EXPIRED
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.
5098
5099 C: d login "fred" "foo"
5100 S: d NO [EXPIRED] That password isn't valid any more
5101
5102 EXPUNGEISSUED
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.
5106
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
5110
5111 HASCHILDREN
5112 The mailbox delete operation failed because the mailbox has one or
5113 more children, and the server doesn't allow deletion of mailboxes
5114 with children.
5115
5116 C: m356 DELETE Notes
5117 S: o356 NO [HASCHILDREN] Mailbox "Notes" has children
5118 that need to be deleted first
5119
5120 INUSE
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.
5126
5127 The operation may succeed if the client tries again later.
5128
5129 C: g delete "/archive/projects/experiment-iv"
5130 S: g NO [INUSE] Mailbox in use
5131
5132 LIMIT
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.
5136
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
5139
5140 NONEXISTENT
5141 The operation attempts to delete something that does not exist.
5142 Similar to ALREADYEXISTS.
5143
5144 C: p RENAME this that
5145 S: p NO [NONEXISTENT] No such mailbox
5146
5147 NOPERM
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
5150 creating a mailbox.
5151
5152 C: f select "/archive/projects/experiment-iv"
5153 S: f NO [NOPERM] Access denied
5154
5155 OVERQUOTA
5156 The user would be over quota after the operation. (The user may
5157 or may not be over quota already.)
5158
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.
5162
5163 C: n1 uid copy 1:* oldmail
5164 S: n1 NO [OVERQUOTA] Sorry
5165
5166 C: n2 uid copy 1:* oldmail
5167 S: n2 OK [OVERQUOTA] You are now over your soft quota
5168
5169 PARSE
5170 The human-readable text represents an error in parsing the
5171 [RFC5322] header or [MIME-IMB] headers of a message in the
5172 mailbox.
5173
5174 PERMANENTFLAGS
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
5184 session only.
5185
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
5192 flag \*.
5193
5194 PRIVACYREQUIRED
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.
5199
5200 C: d login "fred" "foo"
5201 S: d NO [PRIVACYREQUIRED] Connection offers no privacy
5202
5203 C: d select inbox
5204 S: d NO [PRIVACYREQUIRED] Connection offers no privacy
5205
5206 READ-ONLY
5207 The mailbox is selected as read-only, or its access while selected
5208 has changed from read-write to read-only.
5209
5210 READ-WRITE
5211 The mailbox is selected as read-write, or its access while
5212 selected has changed from read-only to read-write.
5213
5214 SERVERBUG
5215 The server encountered a bug in itself or violated one of its own
5216 invariants.
5217
5218 C: j select "/archive/projects/experiment-iv"
5219 S: j NO [SERVERBUG] This should not happen
5220
5221 TRYCREATE
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.
5226
5227 UIDNEXT
5228 Followed by a decimal number and indicates the next unique
5229 identifier value. Refer to Section 2.3.1.1 for more information.
5230
5231 UIDNOTSTICKY
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
5236 code.
5237
5238 This response code is returned in an untagged NO response to the
5239 SELECT command.
5240
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.
5245
5246 UIDVALIDITY
5247 Followed by a decimal number and indicates the unique identifier
5248 validity value. Refer to Section 2.3.1.1 for more information.
5249
5250 UNAVAILABLE
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.
5255
5256 C: a LOGIN "fred" "foo"
5257 S: a NO [UNAVAILABLE] User's backend down for maintenance
5258
5259 UNKNOWN-CTE
5260 The server does not know how to decode the section's Content-
5261 Transfer-Encoding.
5262
5263 Client implementations MUST ignore response codes that they do not
5264 recognize.
5265
52667.1.1. OK Response
5267
5268 Contents:
5269 OPTIONAL response code
5270 human-readable text
5271
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
5277 code.
5278
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.
5282
5283 Example:
5284
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
5289
52907.1.2. NO Response
5291
5292 Contents:
5293 OPTIONAL response code
5294 human-readable text
5295
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.
5301
5302 Example:
5303
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
5311
53127.1.3. BAD Response
5313
5314 Contents:
5315 OPTIONAL response code
5316 human-readable text
5317
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.
5324
5325 Example:
5326
5327 C: ...very long command line...
5328 S: * BAD Command line too long
5329 C: ...empty line...
5330 S: * BAD Empty command line
5331 C: A443 EXPUNGE
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
5335
53367.1.4. PREAUTH Response
5337
5338 Contents:
5339 OPTIONAL response code
5340 human-readable text
5341
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.
5346
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.
5355
5356 Example:
5357
5358 S: * PREAUTH IMAP4rev2 server logged in as Smith
5359
53607.1.5. BYE Response
5361
5362 Contents:
5363 OPTIONAL response code
5364 human-readable text
5365
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:
5370
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
5373 command.
5374
5375 2. as a panic shutdown announcement. The server closes the
5376 connection immediately.
5377
5378 3. as an announcement of an inactivity autologout. The server
5379 closes the connection immediately.
5380
5381 4. as one of three possible greetings at connection startup,
5382 indicating that the server is not willing to accept a connection
5383 from this client. The server closes the connection immediately.
5384
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
5391 read and processed.
5392
5393 Example:
5394
5395 S: * BYE Autologout; idle for too long
5396
53977.2. Server Responses - Server Status
5398
5399 These responses are always untagged. This is how server status data
5400 are transmitted from the server to the client.
5401
54027.2.1. ENABLED Response
5403
5404 Contents: capability listing
5405
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.
5411
5412 Example:
5413
5414 S: * ENABLED CONDSTORE QRESYNC
5415
54167.2.2. CAPABILITY Response
5417
5418 Contents: capability listing
5419
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
5425 significance.
5426
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
5431 these capabilities.
5432
5433 A capability name that begins with "AUTH=" indicates that the server
5434 supports that particular authentication mechanism [SASL].
5435
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.
5442
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.)
5452
5453 Capability names SHOULD be registered with IANA using the RFC
5454 Required policy [RFC8126]. A server SHOULD NOT offer unregistered
5455 capability names.
5456
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
5460 capability names.
5461
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.
5469
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).
5475
5476 Example:
5477
5478 S: * CAPABILITY STARTTLS AUTH=GSSAPI IMAP4rev2 LOGINDISABLED
5479 XPIG-LATIN
5480
5481 Note that in the above example, XPIG-LATIN is a fictitious capability
5482 name.
5483
54847.3. Server Responses - Mailbox Status
5485
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.
5489
54907.3.1. LIST Response
5491
5492 Contents:
5493 name attributes
5494 hierarchy delimiter
5495 name
5496 OPTIONAL extension data
5497
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.
5501
5502 The following base mailbox name attributes are defined:
5503
5504 \NonExistent
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:
5510
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).
5514
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.
5518
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.
5522
5523 The "\NonExistent" attribute implies "\NoSelect".
5524
5525 \Noinferiors
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
5528 in the future.
5529
5530 \Noselect
5531 It is not possible to use this name as a selectable mailbox.
5532
5533 \HasChildren
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
5547 to list them.
5548
5549 \HasNoChildren
5550 The presence of this attribute indicates that the mailbox has NO
5551 child mailboxes that are accessible to the currently authenticated
5552 user.
5553
5554 \Marked
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.
5558
5559 \Unmarked
5560 The mailbox does not contain any additional messages since the
5561 last time the mailbox was selected.
5562
5563 \Subscribed
5564 The mailbox name was subscribed to using the SUBSCRIBE command.
5565
5566 \Remote
5567 The mailbox is a remote mailbox.
5568
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
5573 response.
5574
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.
5578
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
5583 of these.
5584
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.
5593
5594 \All
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.
5599
5600 \Archive
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.
5605
5606 \Drafts
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.
5613
5614 \Flagged
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.
5619
5620 \Junk
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
5624 filter.
5625
5626 \Sent
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.
5631
5632 \Trash
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.
5641
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.
5648
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.
5652
5653 Other mailbox name attributes can be found in the "IMAP Mailbox Name
5654 Attributes" registry [IMAP-MAILBOX-NAME-ATTRS-REG].
5655
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.
5662
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.
5667
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.
5681
5682 Example:
5683
5684 S: * LIST (\Noselect) "/" ~/Mail/foo
5685
5686 Example:
5687
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"))
5692
56937.3.2. NAMESPACE Response
5694
5695 Contents: the prefix and hierarchy delimiter to the server's
5696 Personal Namespace(s), Other Users' Namespace(s), and
5697 Shared Namespace(s)
5698
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.
5706
5707 Example:
5708
5709 S: * NAMESPACE (("" "/")) (("~" "/")) NIL
5710
57117.3.3. STATUS Response
5712
5713 Contents:
5714 name
5715 status parenthesized list
5716
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.
5720
5721 Example:
5722
5723 S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
5724
57257.3.4. ESEARCH Response
5726
5727 Contents: one or more search-return-data pairs
5728
5729 The ESEARCH response occurs as a result of a SEARCH or UID SEARCH
5730 command.
5731
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.
5736
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.
5740
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.
5746
5747 This document specifies the following return item names:
5748
5749 MIN
5750 Returns the lowest message number/UID that satisfies the SEARCH
5751 criteria.
5752
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.
5756
5757 MAX
5758 Returns the highest message number/UID that satisfies the SEARCH
5759 criteria.
5760
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.
5764
5765 ALL
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.
5772
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.
5776
5777 COUNT
5778 Returns the number of messages that satisfy the SEARCH criteria.
5779 This return item MUST always be included in the ESEARCH response.
5780
5781 Example:
5782
5783 S: * ESEARCH UID COUNT 17 ALL 4:18,21,28
5784
5785 Example:
5786
5787 S: * ESEARCH (TAG "a567") UID COUNT 17 ALL 4:18,21,28
5788
5789 Example:
5790
5791 S: * ESEARCH COUNT 18 ALL 1:17,21
5792
57937.3.5. FLAGS Response
5794
5795 Contents: flag parenthesized list
5796
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
5801 implementation.
5802
5803 The update from the FLAGS response MUST be remembered by the client.
5804
5805 Example:
5806
5807 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
5808
58097.4. Server Responses - Mailbox Size
5810
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
5814 message count.
5815
58167.4.1. EXISTS Response
5817
5818 Contents: none
5819
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).
5823
5824 The update from the EXISTS response MUST be remembered by the client.
5825
5826 Example:
5827
5828 S: * 23 EXISTS
5829
58307.5. Server Responses - Message Status
5831
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.
5836
58377.5.1. EXPUNGE Response
5838
5839 Contents: none
5840
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).
5847
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
5850 value.
5851
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.
5861
5862 An EXPUNGE response MUST NOT be sent when no command is in progress,
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
5868 continuation.
5869
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.
5873
5874 The update from the EXPUNGE response MUST be remembered by the
5875 client.
5876
5877 Example:
5878
5879 S: * 44 EXPUNGE
5880
58817.5.2. FETCH Response
5882
5883 Contents: message data
5884
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
5889 updates).
5890
5891 The current data items are:
5892
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.
5898
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.
5904
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.
5912
5913 If the server does not know how to decode the section's Content-
5914 Transfer-Encoding, it MUST fail the request and issue a "NO"
5915 response that contains the "UNKNOWN-CTE" response code.
5916
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.
5922
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.
5926
5927 BODY
5928 A form of BODYSTRUCTURE without extension data.
5929
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.
5934
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
5938 truncated.
5939
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.
5943
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.
5952
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.
5957
5958 BODYSTRUCTURE
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.
5962
5963 For example, a simple text message of 48 lines and 2279 octets can
5964 have a body structure of:
5965
5966 ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 2279 48)
5967
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.).
5973
5974 For example, a two-part message consisting of a text and a
5975 base64-encoded text attachment can have a body structure of:
5976
5977
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")
5982
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:
5988
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*".
6001
6002 body disposition
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].
6007
6008 body language
6009 A string or parenthesized list giving the body language value as
6010 defined in [LANGUAGE-TAGS].
6011
6012 body location
6013 A string giving the body content URI as defined in [LOCATION].
6014
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.
6022
6023 The basic fields of a non-multipart body part are in the following
6024 order:
6025
6026 body type
6027 A string giving the content media-type name as defined in
6028 [MIME-IMB].
6029
6030 body subtype
6031 A string giving the content subtype name as defined in [MIME-IMB].
6032
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].
6037
6038 body id
6039 A string giving the Content-ID header field value as defined in
6040 Section 7 of [MIME-IMB].
6041
6042 body description
6043 A string giving the Content-Description header field value as
6044 defined in Section 8 of [MIME-IMB].
6045
6046 body encoding
6047 A string giving the content transfer encoding as defined in
6048 Section 6 of [MIME-IMB].
6049
6050 body size
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.
6054
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.
6058
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.
6063
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.
6068
6069 The extension data of a non-multipart body part are in the
6070 following order:
6071
6072 body MD5
6073 A string giving the body MD5 value as defined in [MD5].
6074
6075 body disposition
6076 A parenthesized list with the same content and function as the
6077 body disposition for a multipart body part.
6078
6079 body language
6080 A string or parenthesized list giving the body language value as
6081 defined in [LANGUAGE-TAGS].
6082
6083 body location
6084 A string giving the body content URI as defined in [LOCATION].
6085
6086 Any following extension data are not yet defined in this version
6087 of the protocol and would be as described above under multipart
6088 extension data.
6089
6090 ENVELOPE
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
6094 necessary.
6095
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.
6101
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
6107 hostname.
6108
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
6114 group name phrase.
6115
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.
6120
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.
6124
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.
6129
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.
6135
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.
6139
6140 If the Sender or Reply-To header fields are absent in the
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).
6144
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.
6149
6150 FLAGS
6151 A parenthesized list of flags that are set for this message.
6152
6153 INTERNALDATE
6154 A string representing the internal date of the message.
6155
6156 RFC822.SIZE
6157 A number expressing the size of a message, as described in
6158 Section 2.3.4.
6159
6160 UID
6161 A number expressing the unique identifier of the message.
6162
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].
6166
6167 Example:
6168
6169 S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827 UID 447)
6170
61717.6. Server Responses - Command Continuation Request
6172
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.
6177
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
6181 literal.
6182
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.
6190
6191 Example:
6192
6193 C: A001 LOGIN {11}
6194 S: + Ready for additional command text
6195 C: FRED FOOBAR {7}
6196 S: + Ready for additional command text
6197 C: fat man
6198 S: A001 OK LOGIN completed
6199 C: A044 BLURDYBLOOP {102856}
6200 S: A044 BAD No such command as "BLURDYBLOOP"
6201
62028. Sample IMAP4rev2 Connection
6203
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.
6206
6207 S: * OK [CAPABILITY STARTTLS AUTH=SCRAM-SHA-256 LOGINDISABLED
6208 IMAP4rev2] IMAP4rev2 Service Ready
6209 C: a000 starttls
6210 S: a000 OK Proceed with TLS negotiation
6211 <TLS negotiation>
6212 C: A001 AUTHENTICATE SCRAM-SHA-256
6213 biwsbj11c2VyLHI9ck9wck5HZndFYmVSV2diTkVrcU8=
6214 S: + cj1yT3ByTkdmd0ViZVJXZ2JORWtxTyVodllEcFdVYTJSYVRDQWZ1eEZJbGopaE
6215 5sRiRrMCxzPVcyMlphSjBTTlk3c29Fc1VFamI2Z1E9PSxpPTQwOTY=
6216 C: Yz1iaXdzLHI9ck9wck5HZndFYmVSV2diTkVrcU8laHZZRHBXVWEyUmFUQ0FmdXhG
6217 SWxqKWhObEYkazAscD1kSHpiWmFwV0lrNGpVaE4rVXRlOXl0YWc5empmTUhnc3Ft
6218 bWl6N0FuZFZRPQ==
6219 S: + dj02cnJpVFJCaTIzV3BSUi93dHVwK21NaFVaVW4vZEI1bkxUSlJzamw5NUc0
6220 PQ==
6221 C:
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
6227 S: * 18 EXISTS
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"
6245 3028 92))
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
6257 S:
6258 S: )
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
6263 C: a006 logout
6264 S: * BYE IMAP4rev2 server terminating connection
6265 S: a006 OK LOGOUT completed
6266
62679. Formal Syntax
6268
6269 The following syntax specification uses the Augmented Backus-Naur
6270 Form (ABNF) notation as specified in [ABNF].
6271
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
6277 noted below.
6278
6279 Note: [ABNF] rules MUST be followed strictly; in particular:
6280
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
6285 fashion.
6286
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
6290 (LWSP).
6291
6292 3. The ASCII NUL character, %x00, MUST NOT be used anywhere, with
6293 the exception of the OCTET production.
6294
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>
6302
6303 address = "(" addr-name SP addr-adl SP addr-mailbox SP
6304 addr-host ")"
6305
6306 addr-adl = nstring
6307 ; Holds route from [RFC5322] obs-route if
6308 ; non-NIL
6309
6310 addr-host = nstring
6311 ; NIL indicates [RFC5322] group syntax.
6312 ; Otherwise, holds [RFC5322] domain name
6313
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
6320
6321 addr-name = nstring
6322 ; If non-NIL, holds phrase from [RFC5322]
6323 ; mailbox after removing [RFC5322] quoting
6324
6325 append = "APPEND" SP mailbox [SP flag-list] [SP date-time]
6326 SP literal
6327
6328 append-uid = uniqueid
6329
6330 astring = 1*ASTRING-CHAR / string
6331
6332 ASTRING-CHAR = ATOM-CHAR / resp-specials
6333
6334 atom = 1*ATOM-CHAR
6335
6336 ATOM-CHAR = <any CHAR except atom-specials>
6337
6338 atom-specials = "(" / ")" / "{" / SP / CTL / list-wildcards /
6339 quoted-specials / resp-specials
6340
6341 authenticate = "AUTHENTICATE" SP auth-type [SP initial-resp]
6342 *(CRLF base64)
6343
6344 auth-type = atom
6345 ; Authentication mechanism name, as defined by
6346 ; [SASL], Section 7.1
6347
6348 base64 = *(4base64-char) [base64-terminal]
6349
6350 base64-char = ALPHA / DIGIT / "+" / "/"
6351 ; Case sensitive
6352
6353 base64-terminal = (2base64-char "==") / (3base64-char "=")
6354
6355 body = "(" (body-type-1part / body-type-mpart) ")"
6356
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.
6365
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
6369 ; "BODY" fetch
6370
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
6374 ; "BODY" fetch
6375
6376 body-fields = body-fld-param SP body-fld-id SP body-fld-desc SP
6377 body-fld-enc SP body-fld-octets
6378
6379 body-fld-desc = nstring
6380
6381 body-fld-dsp = "(" string SP body-fld-param ")" / nil
6382
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.
6388
6389 body-fld-id = nstring
6390
6391 body-fld-lang = nstring / "(" string *(SP string) ")"
6392
6393 body-fld-loc = nstring
6394
6395 body-fld-lines = number64
6396
6397 body-fld-md5 = nstring
6398
6399 body-fld-octets = number
6400
6401 body-fld-param = "(" string SP string *(SP string SP string) ")" /
6402 nil
6403
6404 body-type-1part = (body-type-basic / body-type-msg / body-type-text)
6405 [SP body-ext-1part]
6406
6407 body-type-basic = media-basic SP body-fields
6408 ; MESSAGE subtype MUST NOT be "RFC822" or
6409 ; "GLOBAL"
6410
6411 body-type-mpart = 1*body SP media-subtype
6412 [SP body-ext-mpart]
6413 ; MULTIPART body part
6414
6415 body-type-msg = media-message SP body-fields SP envelope
6416 SP body SP body-fld-lines
6417
6418 body-type-text = media-text SP body-fields SP body-fld-lines
6419
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.
6426
6427 capability-data = "CAPABILITY" *(SP capability) SP "IMAP4rev2"
6428 *(SP capability)
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.
6435
6436 CHAR = <defined in [ABNF]>
6437
6438 CHAR8 = %x01-ff
6439 ; any OCTET except NUL, %x00
6440
6441 charset = atom / quoted
6442
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.
6455
6456 child-mbox-flag = "\HasChildren" / "\HasNoChildren"
6457 ; attributes for the CHILDREN return option, at most
6458 ; one possible per LIST response
6459
6460 command = tag SP (command-any / command-auth /
6461 command-nonauth / command-select) CRLF
6462 ; Modal based on state
6463
6464 command-any = "CAPABILITY" / "LOGOUT" / "NOOP"
6465 ; Valid in all states
6466
6467 command-auth = append / create / delete / enable / examine /
6468 list / namespace-command / rename /
6469 select / status / subscribe / unsubscribe /
6470 idle
6471 ; Valid only in Authenticated or Selected state
6472
6473 command-nonauth = login / authenticate / "STARTTLS"
6474 ; Valid only when in Not Authenticated state
6475
6476 command-select = "CLOSE" / "UNSELECT" / "EXPUNGE" / copy /
6477 move / fetch / store / search / uid
6478 ; Valid only when in Selected state
6479
6480 continue-req = "+" SP (resp-text / base64) CRLF
6481
6482 copy = "COPY" SP sequence-set SP mailbox
6483
6484 create = "CREATE" SP mailbox
6485 ; Use of INBOX gives a NO error
6486
6487 date = date-text / DQUOTE date-text DQUOTE
6488
6489 date-day = 1*2DIGIT
6490 ; Day of month
6491
6492 date-day-fixed = (SP DIGIT) / 2DIGIT
6493 ; Fixed-format version of date-day
6494
6495 date-month = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" /
6496 "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"
6497
6498 date-text = date-day "-" date-month "-" date-year
6499
6500 date-year = 4DIGIT
6501
6502 date-time = DQUOTE date-day-fixed "-" date-month "-" date-year
6503 SP time SP zone DQUOTE
6504
6505 delete = "DELETE" SP mailbox
6506 ; Use of INBOX gives a NO error
6507
6508 digit-nz = %x31-39
6509 ; 1-9
6510
6511 eitem-standard-tag = atom
6512 ; a tag for LIST extended data item defined in a Standard
6513 ; Track or Experimental RFC.
6514
6515 eitem-vendor-tag = vendor-token "-" atom
6516 ; a vendor-specific tag for LIST extended data item
6517
6518 enable = "ENABLE" 1*(SP capability)
6519
6520 enable-data = "ENABLED" *(SP capability)
6521
6522 envelope = "(" env-date SP env-subject SP env-from SP
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 ")"
6525
6526 env-bcc = "(" 1*address ")" / nil
6527
6528 env-cc = "(" 1*address ")" / nil
6529
6530 env-date = nstring
6531
6532 env-from = "(" 1*address ")" / nil
6533
6534 env-in-reply-to = nstring
6535
6536 env-message-id = nstring
6537
6538 env-reply-to = "(" 1*address ")" / nil
6539
6540 env-sender = "(" 1*address ")" / nil
6541
6542 env-subject = nstring
6543
6544 env-to = "(" 1*address ")" / nil
6545
6546 esearch-response = "ESEARCH" [search-correlator] [SP "UID"]
6547 *(SP search-return-data)
6548 ; ESEARCH response replaces SEARCH response
6549 ; from IMAP4rev1.
6550
6551 examine = "EXAMINE" SP mailbox
6552
6553 fetch = "FETCH" SP sequence-set SP (
6554 "ALL" / "FULL" / "FAST" /
6555 fetch-att / "(" fetch-att *(SP fetch-att) ")")
6556
6557 fetch-att = "ENVELOPE" / "FLAGS" / "INTERNALDATE" /
6558 "RFC822.SIZE" /
6559 "BODY" ["STRUCTURE"] / "UID" /
6560 "BODY" section [partial] /
6561 "BODY.PEEK" section [partial] /
6562 "BINARY" [".PEEK"] section-binary [partial] /
6563 "BINARY.SIZE" section-binary
6564
6565 flag = "\Answered" / "\Flagged" / "\Deleted" /
6566 "\Seen" / "\Draft" / flag-keyword / flag-extension
6567 ; Does not include "\Recent"
6568
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.
6578
6579 flag-fetch = flag / obsolete-flag-recent
6580
6581 flag-keyword = "$MDNSent" / "$Forwarded" / "$Junk" /
6582 "$NotJunk" / "$Phishing" / atom
6583
6584 flag-list = "(" [flag *(SP flag)] ")"
6585
6586 flag-perm = flag / "\*"
6587
6588 greeting = "*" SP (resp-cond-auth / resp-cond-bye) CRLF
6589
6590 header-fld-name = astring
6591
6592 header-list = "(" header-fld-name *(SP header-fld-name) ")"
6593
6594 idle = "IDLE" CRLF "DONE"
6595
6596 initial-resp = (base64 / "=")
6597 ; "initial response" defined in
6598 ; Section 4 of [SASL]
6599
6600 list = "LIST" [SP list-select-opts] SP
6601 mailbox SP mbox-or-pat
6602 [SP list-return-opts]
6603
6604
6605 list-mailbox = 1*list-char / string
6606
6607 list-char = ATOM-CHAR / list-wildcards / resp-specials
6608
6609 list-return-opt = return-option
6610 ; Note that return-option is the ABNF
6611 ; non-terminal used by RFC 5258
6612
6613 list-return-opts = "RETURN" SP
6614 "(" [list-return-opt *(SP list-return-opt)] ")"
6615 ; list return options, e.g., CHILDREN
6616
6617 list-select-base-opt = "SUBSCRIBED" / option-extension
6618 ; options that can be used by themselves
6619
6620 list-select-base-opt-quoted = DQUOTE list-select-base-opt DQUOTE
6621
6622 list-select-independent-opt = "REMOTE" / option-extension
6623 ; options that do not syntactically interact with
6624 ; other options
6625
6626 list-select-mod-opt = "RECURSIVEMATCH" / option-extension
6627 ; options that require a list-select-base-opt
6628 ; to also be present
6629
6630 list-select-opt = list-select-base-opt / list-select-independent-opt
6631 / list-select-mod-opt
6632
6633 list-select-opts = "(" [
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))
6638 ] ")"
6639 ; Any number of options may be in any order.
6640 ; If a list-select-mod-opt appears, then a
6641 ; list-select-base-opt must also appear.
6642 ; This allows these:
6643 ; ()
6644 ; (REMOTE)
6645 ; (SUBSCRIBED)
6646 ; (SUBSCRIBED REMOTE)
6647 ; (SUBSCRIBED RECURSIVEMATCH)
6648 ; (SUBSCRIBED REMOTE RECURSIVEMATCH)
6649 ; But does NOT allow these:
6650 ; (RECURSIVEMATCH)
6651 ; (REMOTE RECURSIVEMATCH)
6652
6653 list-wildcards = "%" / "*"
6654
6655 literal = "{" number64 ["+"] "}" CRLF *CHAR8
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.
6662
6663 literal8 = "~{" number64 "}" CRLF *OCTET
6664 ; <number64> represents the number of OCTETs
6665 ; in the response string.
6666
6667 login = "LOGIN" SP userid SP password
6668
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.
6678
6679 mailbox-data = "FLAGS" SP flag-list / "LIST" SP mailbox-list /
6680 esearch-response /
6681 "STATUS" SP mailbox SP "(" [status-att-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
6688 ; and IMAPrev2.
6689
6690 mailbox-list = "(" [mbx-list-flags] ")" SP
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
6695
6696 mbox-list-extended = "(" [mbox-list-extended-item
6697 *(SP mbox-list-extended-item)] ")"
6698
6699 mbox-list-extended-item = mbox-list-extended-item-tag SP
6700 tagged-ext-val
6701
6702 mbox-list-extended-item-tag = astring
6703 ; The content MUST conform to either
6704 ; "eitem-vendor-tag" or "eitem-standard-tag"
6705 ; ABNF productions.
6706
6707 mbox-or-pat = list-mailbox / patterns
6708
6709 mbx-list-flags = *(mbx-list-oflag SP) mbx-list-sflag
6710 *(SP mbx-list-oflag) /
6711 mbx-list-oflag *(SP mbx-list-oflag)
6712
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
6718
6719 mbx-list-sflag = "\NonExistent" / "\Noselect" / "\Marked" /
6720 "\Unmarked"
6721 ; Selectability flags; only one per LIST response
6722
6723 media-basic = ((DQUOTE ("APPLICATION" / "AUDIO" / "IMAGE" /
6724 "FONT" / "MESSAGE" / "MODEL" / "VIDEO" ) DQUOTE)
6725 / string)
6726 SP media-subtype
6727 ; FONT defined in [RFC8081].
6728 ; MODEL defined in [RFC2077].
6729 ; Other top-level media types
6730 ; are defined in [MIME-IMT].
6731
6732 media-message = DQUOTE "MESSAGE" DQUOTE SP
6733 DQUOTE ("RFC822" / "GLOBAL") DQUOTE
6734 ; Defined in [MIME-IMT]
6735
6736 media-subtype = string
6737 ; Defined in [MIME-IMT]
6738
6739 media-text = DQUOTE "TEXT" DQUOTE SP media-subtype
6740 ; Defined in [MIME-IMT]
6741
6742 message-data = nz-number SP ("EXPUNGE" / ("FETCH" SP msg-att))
6743
6744 move = "MOVE" SP sequence-set SP mailbox
6745
6746 msg-att = "(" (msg-att-dynamic / msg-att-static)
6747 *(SP (msg-att-dynamic / msg-att-static)) ")"
6748
6749 msg-att-dynamic = "FLAGS" SP "(" [flag-fetch *(SP flag-fetch)] ")"
6750 ; MAY change for a message
6751
6752 msg-att-static = "ENVELOPE" SP envelope /
6753 "INTERNALDATE" SP date-time /
6754 "RFC822.SIZE" SP number64 /
6755 "BODY" ["STRUCTURE"] SP body /
6756 "BODY" section ["<" number ">"] SP nstring /
6757 "BINARY" section-binary SP (nstring / literal8) /
6758 "BINARY.SIZE" section-binary SP number /
6759 "UID" SP uniqueid
6760 ; MUST NOT change for a message
6761
6762 name-component = 1*UTF8-CHAR
6763 ; MUST NOT contain ".", "/", "%", or "*"
6764
6765 namespace = nil / "(" 1*namespace-descr ")"
6766
6767 namespace-command = "NAMESPACE"
6768
6769 namespace-descr = "(" string SP
6770 (DQUOTE QUOTED-CHAR DQUOTE / nil)
6771 [namespace-response-extensions] ")"
6772
6773 namespace-response-extensions = *namespace-response-extension
6774
6775 namespace-response-extension = SP string SP
6776 "(" string *(SP string) ")"
6777
6778 namespace-response = "NAMESPACE" SP namespace
6779 SP namespace SP namespace
6780 ; The first Namespace is the Personal Namespace(s).
6781 ; The second Namespace is the Other Users'
6782 ; Namespace(s).
6783 ; The third Namespace is the Shared Namespace(s).
6784
6785 nil = "NIL"
6786
6787 nstring = string / nil
6788
6789 number = 1*DIGIT
6790 ; Unsigned 32-bit integer
6791 ; (0 <= n < 4,294,967,296)
6792
6793 number64 = 1*DIGIT
6794 ; Unsigned 63-bit integer
6795 ; (0 <= n <= 9,223,372,036,854,775,807)
6796
6797 nz-number = digit-nz *DIGIT
6798 ; Non-zero unsigned 32-bit integer
6799 ; (0 < n < 4,294,967,296)
6800
6801 nz-number64 = digit-nz *DIGIT
6802 ; Unsigned 63-bit integer
6803 ; (0 < n <= 9,223,372,036,854,775,807)
6804
6805 obsolete-flag-recent = "\Recent"
6806
6807 obsolete-recent-response = number SP "RECENT"
6808
6809 obsolete-search-response = "SEARCH" *(SP nz-number)
6810
6811 oldname-extended-item = "OLDNAME" SP "(" mailbox ")"
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
6816 ; name.
6817 ; Note 1: the OLDNAME tag can be returned
6818 ; with or without surrounding quotes, as per
6819 ; mbox-list-extended-item-tag production.
6820
6821 option-extension = (option-standard-tag / option-vendor-tag)
6822 [SP option-value]
6823
6824 option-standard-tag = atom
6825 ; an option defined in a Standards Track or
6826 ; Experimental RFC
6827
6828 option-val-comp = astring /
6829 option-val-comp *(SP option-val-comp) /
6830 "(" option-val-comp ")"
6831
6832 option-value = "(" option-val-comp ")"
6833
6834 option-vendor-tag = vendor-token "-" atom
6835 ; a vendor-specific option, non-standard
6836
6837 partial-range = number64 ["." nz-number64]
6838 ; Copied from RFC 5092 (IMAP URL)
6839 ; and updated to support 64-bit sizes.
6840
6841 partial = "<" number64 "." nz-number64 ">"
6842 ; Partial FETCH request. 0-based offset of
6843 ; the first octet, followed by the number of
6844 ; octets in the fragment.
6845
6846 password = astring
6847
6848 patterns = "(" list-mailbox ")"
6849 ; [RFC5258] supports multiple patterns,
6850 ; but this document only requires one
6851 ; to be supported.
6852 ; If the server is also implementing
6853 ; [RFC5258], the "patterns" syntax from
6854 ; that document must be followed.
6855
6856 quoted = DQUOTE *QUOTED-CHAR DQUOTE
6857
6858 QUOTED-CHAR = <any TEXT-CHAR except quoted-specials> /
6859 "\" quoted-specials / UTF8-2 / UTF8-3 / UTF8-4
6860
6861 quoted-specials = DQUOTE / "\"
6862
6863 rename = "RENAME" SP mailbox SP mailbox
6864 ; Use of INBOX as a destination gives a NO error
6865
6866 response = *(continue-req / response-data) response-done
6867
6868 response-data = "*" SP (resp-cond-state / resp-cond-bye /
6869 mailbox-data / message-data / capability-data /
6870 enable-data) CRLF
6871
6872 response-done = response-tagged / response-fatal
6873
6874 response-fatal = "*" SP resp-cond-bye CRLF
6875 ; Server closes connection immediately
6876
6877 response-tagged = tag SP resp-cond-state CRLF
6878
6879 resp-code-apnd = "APPENDUID" SP nz-number SP append-uid
6880
6881 resp-code-copy = "COPYUID" SP nz-number SP uid-set SP uid-set
6882
6883 resp-cond-auth = ("OK" / "PREAUTH") SP resp-text
6884 ; Authentication condition
6885
6886 resp-cond-bye = "BYE" SP resp-text
6887
6888 resp-cond-state = ("OK" / "NO" / "BAD") SP resp-text
6889 ; Status condition
6890
6891 resp-specials = "]"
6892
6893 resp-text = ["[" resp-text-code "]" SP] [text]
6894
6895 resp-text-code = "ALERT" /
6896 "BADCHARSET" [SP "(" charset *(SP charset) ")" ] /
6897 capability-data / "PARSE" /
6898 "PERMANENTFLAGS" SP
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" /
6911 "CLOSED" /
6912 "UNKNOWN-CTE" /
6913 atom [SP 1*<any TEXT-CHAR except "]">]
6914
6915 return-option = "SUBSCRIBED" / "CHILDREN" / status-option /
6916 option-extension
6917
6918 search = "SEARCH" [search-return-opts]
6919 SP search-program
6920
6921 search-correlator = SP "(" "TAG" SP tag-string ")"
6922
6923 search-key = "ALL" / "ANSWERED" / "BCC" SP astring /
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) ")"
6940
6941 search-modifier-name = tagged-ext-label
6942
6943 search-mod-params = tagged-ext-val
6944 ; This non-terminal shows recommended syntax
6945 ; for future extensions.
6946
6947 search-program = ["CHARSET" SP charset SP]
6948 search-key *(SP search-key)
6949 ; CHARSET argument to SEARCH MUST be
6950 ; registered with IANA.
6951
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.
6956
6957 search-return-data = "MIN" SP nz-number /
6958 "MAX" SP nz-number /
6959 "ALL" SP sequence-set /
6960 "COUNT" SP number /
6961 search-ret-data-ext
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.
6966
6967 search-return-opts = SP "RETURN" SP "(" [search-return-opt
6968 *(SP search-return-opt)] ")"
6969
6970 search-return-opt = "MIN" / "MAX" / "ALL" / "COUNT" /
6971 "SAVE" /
6972 search-ret-opt-ext
6973 ; conforms to generic search-ret-opt-ext
6974 ; syntax
6975
6976 search-ret-opt-ext = search-modifier-name [SP search-mod-params]
6977
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.
6984
6985 section = "[" [section-spec] "]"
6986
6987 section-binary = "[" [section-part] "]"
6988
6989 section-msgtext = "HEADER" /
6990 "HEADER.FIELDS" [".NOT"] SP header-list /
6991 "TEXT"
6992 ; top-level or MESSAGE/RFC822 or
6993 ; MESSAGE/GLOBAL part
6994
6995 section-part = nz-number *("." nz-number)
6996 ; body part reference.
6997 ; Allows for accessing nested body parts.
6998
6999 section-spec = section-msgtext / (section-part ["." section-text])
7000
7001 section-text = section-msgtext / "MIME"
7002 ; text other than actual body part (headers,
7003 ; etc.)
7004
7005 select = "SELECT" SP mailbox
7006
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.
7018 ; The server should respond with a tagged BAD
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.
7023
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
7032 ; 3291.
7033
7034 sequence-set = (seq-number / seq-range) ["," sequence-set]
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
7045 ; 4,5,6,7,8,9,10.
7046
7047 sequence-set =/ seq-last-command
7048 ; Allow for "result of the last command"
7049 ; indicator.
7050
7051 seq-last-command = "$"
7052
7053 status = "STATUS" SP mailbox SP
7054 "(" status-att *(SP status-att) ")"
7055
7056 status-att = "MESSAGES" / "UIDNEXT" / "UIDVALIDITY" /
7057 "UNSEEN" / "DELETED" / "SIZE"
7058
7059 status-att-val = ("MESSAGES" SP number) /
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.
7069
7070 status-att-list = status-att-val *(SP status-att-val)
7071
7072 status-option = "STATUS" SP "(" status-att *(SP status-att) ")"
7073 ; This ABNF production complies with
7074 ; <option-extension> syntax.
7075
7076 store = "STORE" SP sequence-set SP store-att-flags
7077
7078 store-att-flags = (["+" / "-"] "FLAGS" [".SILENT"]) SP
7079 (flag-list / (flag *(SP flag)))
7080
7081 string = quoted / literal
7082
7083 subscribe = "SUBSCRIBE" SP mailbox
7084
7085 tag = 1*<any ASTRING-CHAR except "+">
7086
7087 tag-string = astring
7088 ; <tag> represented as <astring>
7089
7090 tagged-ext-label = tagged-label-fchar *tagged-label-char
7091 ; Is a valid RFC 3501 "atom".
7092
7093 tagged-label-fchar = ALPHA / "-" / "_" / "."
7094
7095 tagged-label-char = tagged-label-fchar / DIGIT / ":"
7096
7097 tagged-ext-comp = astring /
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
7103 ; of the extension.
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.
7108
7109 tagged-ext-simple = sequence-set / number / number64
7110
7111 tagged-ext-val = tagged-ext-simple /
7112 "(" [tagged-ext-comp] ")"
7113
7114 text = 1*(TEXT-CHAR / UTF8-2 / UTF8-3 / UTF8-4)
7115 ; Non-ASCII text can only be returned
7116 ; after ENABLE IMAP4rev2 command
7117
7118 TEXT-CHAR = <any CHAR except CR and LF>
7119
7120 time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
7121 ; Hours minutes seconds
7122
7123 uid = "UID" SP
7124 (copy / move / fetch / search / store /
7125 uid-expunge)
7126 ; Unique identifiers used instead of message
7127 ; sequence numbers
7128
7129 uid-expunge = "EXPUNGE" SP sequence-set
7130 ; Unique identifiers used instead of message
7131 ; sequence numbers
7132
7133 uid-set = (uniqueid / uid-range) *("," uid-set)
7134
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.
7139
7140 uniqueid = nz-number
7141 ; Strictly ascending
7142
7143 unsubscribe = "UNSUBSCRIBE" SP mailbox
7144
7145 userid = astring
7146
7147 UTF8-CHAR = <Defined in Section 4 of RFC 3629>
7148
7149 UTF8-2 = <Defined in Section 4 of RFC 3629>
7150
7151 UTF8-3 = <Defined in Section 4 of RFC 3629>
7152
7153 UTF8-4 = <Defined in Section 4 of RFC 3629>
7154
7155 vendor-token = "vendor." name-component
7156 ; Definition copied from RFC 2244.
7157 ; MUST be registered with IANA
7158
7159 zone = ("+" / "-") 4DIGIT
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".
7166
716710. Author's Note
7168
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
7172 [RFC1064].
7173
717411. Security Considerations
7175
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.
7182
718311.1. TLS-Related Security Considerations
7184
7185 This section applies to use of both the STARTTLS command and the
7186 Implicit TLS port.
7187
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.
7193
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].
7206
7207 The list of mandatory-to-implement TLS 1.3 cipher suites is described
7208 in Section 9.1 of [TLS-1.3].
7209
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].
7215
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.
7219
722011.2. STARTTLS Command versus Use of Implicit TLS Port
7221
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.
7225
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
7229 command on it.
7230
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
7237 [RFC8305].
7238
723911.3. Client Handling of Unsolicited Responses Not Suitable for the
7240 Current Connection State
7241
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.
7248
7249 * See Section 7.1.4 for special security considerations related to
7250 the PREAUTH response.
7251
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.
7269
727011.4. COPYUID and APPENDUID Response Codes
7271
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.
7276
7277 Consequently, these response codes SHOULD NOT be issued if the client
7278 does not have access to SELECT or EXAMINE the mailbox.
7279
728011.5. LIST Command and Other Users' Namespace
7281
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
7288 accounts to attack.
7289
729011.6. Use of MD5
7291
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].
7303
730411.7. Other Security Considerations
7305
7306 A server error message for an AUTHENTICATE command that fails due to
7307 invalid credentials SHOULD NOT detail why the credentials are
7308 invalid.
7309
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.
7314
7315 A server implementation MUST implement a configuration that, at the
7316 time of authentication, requires:
7317
7318 1. The STARTTLS command has been negotiated or TLS negotiated on an
7319 Implicit TLS port
7320 OR
7321 2. Some other mechanism that protects the session from password
7322 snooping has been provided
7323 OR
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.
7328 AND
7329 b) The LOGIN command returns an error even if the password is
7330 correct
7331 AND
7332 c) The AUTHENTICATE command returns an error with all [SASL]
7333 mechanisms that use plaintext passwords, even if the password
7334 is correct.
7335
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.
7338
7339 A server SHOULD have mechanisms in place to limit or delay failed
7340 AUTHENTICATE/LOGIN attempts.
7341
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
7348 SHOULD be accepted.
7349
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).
7353
735412. IANA Considerations
7355
7356 IANA has updated the "Service Names and Transport Protocol Port
7357 Numbers" registry as follows:
7358
7359 1. Registration for TCP port 143 and the corresponding "imap"
7360 service name have been updated to point to this document and
7361 [RFC3501].
7362
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].
7366
7367 3. UDP ports 143 and 993 have both been marked as "Reserved" in the
7368 registry.
7369
7370 Additional IANA actions are specified in the subsections that follow.
7371
737212.1. Updates to IMAP Capabilities Registry
7373
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/
7377 imap4-capabilities>
7378
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].
7382
738312.2. GSSAPI/SASL Service Name
7384
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-
7388 service-names>
7389
7390 IANA has updated the "imap" service name previously registered in
7391 [RFC3501] to point to both this document and [RFC3501].
7392
739312.3. LIST Selection Options, LIST Return Options, and LIST Extended
7394 Data Items
7395
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
7404 [RFC5258]).
7405
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].
7409
741012.4. IMAP Mailbox Name Attributes and IMAP Response Codes
7411
7412 IANA has updated the "IMAP Mailbox Name Attributes" registry to point
7413 to this document in addition to [RFC3501].
7414
7415 IANA has updated the "IMAP Response Codes" registry to point to this
7416 document in addition to [RFC3501].
7417
741813. References
7419
742013.1. Normative References
7421
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>.
7426
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.
7430
7431 <https://www.rfc-editor.org/info/bcp178>
7432
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>.
7436
7437 [DISPOSITION]
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>.
7443
7444 [I18N-HDRS]
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>.
7448
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>.
7453
7454 [IMAP-MULTIACCESS]
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>.
7458
7459 [LANGUAGE-TAGS]
7460 Alvestrand, H., "Content Language Headers", RFC 3282,
7461 DOI 10.17487/RFC3282, May 2002,
7462 <https://www.rfc-editor.org/info/rfc3282>.
7463
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>.
7468
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>.
7472
7473 [MIME-HDRS]
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>.
7478
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>.
7483
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>.
7488
7489 [MULTIAPPEND]
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>.
7493
7494 [NET-UNICODE]
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>.
7498
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>.
7503
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>.
7508
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>.
7513
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>.
7518
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>.
7523
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>.
7527
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>.
7532
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>.
7537
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>.
7541
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>.
7545
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>.
7551
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>.
7556
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>.
7560
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>.
7564
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>.
7568
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>.
7573
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>.
7578
7579 [SCRAM-SHA-256]
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>.
7584
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>.
7589
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>.
7593
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>.
7598
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>.
7602
760313.2. Informative References
7604
760513.2.1. Related Protocols
7606
7607 [ANONYMOUS]
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>.
7612
7613 [CERT-555316]
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>.
7618
7619 [CHARSET-REG]
7620 IANA, "Character Set Registrations",
7621 <https://www.iana.org/assignments/charset-reg/>.
7622
7623 [IMAP-DISC]
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>.
7628
7629 [IMAP-I18N]
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>.
7634
7635 [IMAP-KEYWORDS-REG]
7636 IANA, "IMAP and JMAP Keywords",
7637 <https://www.iana.org/assignments/imap-jmap-keywords/>.
7638
7639 [IMAP-MAILBOX-NAME-ATTRS-REG]
7640 IANA, "IMAP Mailbox Name Attributes",
7641 <https://www.iana.org/assignments/imap-mailbox-name-
7642 attributes/>.
7643
7644 [IMAP-MODEL]
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>.
7648
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>.
7652
7653 [IMAP-UTF-8]
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>.
7657
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-
7661 spraying-attacks>.
7662
7663 [RFC2087] Myers, J., "IMAP4 QUOTA extension", RFC 2087,
7664 DOI 10.17487/RFC2087, January 1997,
7665 <https://www.rfc-editor.org/info/rfc2087>.
7666
7667 [RFC2177] Leiba, B., "IMAP4 IDLE command", RFC 2177,
7668 DOI 10.17487/RFC2177, June 1997,
7669 <https://www.rfc-editor.org/info/rfc2177>.
7670
7671 [RFC2193] Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193,
7672 DOI 10.17487/RFC2193, September 1997,
7673 <https://www.rfc-editor.org/info/rfc2193>.
7674
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>.
7678
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>.
7683
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>.
7687
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>.
7691
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>.
7695
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>.
7699
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>.
7703
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>.
7708
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>.
7713
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>.
7717
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>.
7721
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>.
7726
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>.
7730
7731 [RFC5530] Gulbrandsen, A., "IMAP Response Codes", RFC 5530,
7732 DOI 10.17487/RFC5530, May 2009,
7733 <https://www.rfc-editor.org/info/rfc5530>.
7734
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>.
7739
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>.
7744
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>.
7748
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>.
7753
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>.
7758
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>.
7762
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>.
7767
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>.
7773
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>.
7777
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>.
7782
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>.
7787
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>.
7791
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>.
7795
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>.
7800
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>.
7805
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>.
7809
781013.2.2. Historical Aspects of IMAP and Related Protocols
7811
7812 [IMAP-COMPAT]
7813 Crispin, M., "IMAP4 Compatibility with IMAP2bis",
7814 RFC 2061, DOI 10.17487/RFC2061, December 1996,
7815 <https://www.rfc-editor.org/info/rfc2061>.
7816
7817 [IMAP-HISTORICAL]
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>.
7821
7822 [IMAP-OBSOLETE]
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>.
7826
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>.
7830
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>.
7834
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-
7839 imap2bis-02>.
7840
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>.
7844
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>.
7848
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>.
7852
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>.
7856
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>.
7860
7861Appendix A. Backward Compatibility with IMAP4rev1
7862
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.
7869
7870 If both IMAP4rev1 and IMAP4rev2 are advertised, an IMAP client that
7871 wants to use IMAP4rev2 MUST issue an "ENABLE IMAP4rev2" command.
7872
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.
7879
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.
7884
7885 Servers advertising both IMAP4rev1 and IMAP4rev2, and clients
7886 intending to be compatible with IMAP4rev1 servers, MUST be compatible
7887 with the Mailbox International Naming Convention described in
7888 Appendix A.1.
7889
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.
7893
7894A.1. Mailbox International Naming Convention for Compatibility with
7895 IMAP4rev1
7896
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
7900 implementations.
7901
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.
7906
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 "&-".
7911
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.
7918
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 "-".
7925
7926 The purpose of these modifications is to correct the following
7927 problems with UTF-7:
7928
7929 1. UTF-7 uses the "+" character for shifting; this conflicts with
7930 the common use of "+" in mailbox names, in particular USENET
7931 newsgroup names.
7932
7933 2. UTF-7's encoding is base64, which uses the "/" character; this
7934 conflicts with the use of "/" as a popular hierarchy delimiter.
7935
7936 3. UTF-7 prohibits the unencoded usage of "\"; this conflicts with
7937 the use of "\" as a popular hierarchy delimiter.
7938
7939 4. UTF-7 prohibits the unencoded usage of "~"; this conflicts with
7940 the use of "~" in some servers as a home directory indicator.
7941
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.
7945
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.
7952
7953 Server implementations SHOULD verify that any mailbox name with an
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.
7961
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
7965 UTF-7.
7966
7967 For example, here is a mailbox name that mixes English, Chinese,
7968 and Japanese text: ~peter/mail/&U,BTFw-/&ZeVnLIqe-
7969
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-".
7975
7976Appendix B. Backward Compatibility with BINARY Extension
7977
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.
7984
7985Appendix C. Backward Compatibility with LIST-EXTENDED Extension
7986
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 /
7991 response code.
7992
7993Appendix D. 63-Bit Body Part and Message Sizes
7994
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.
7999
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.
8008
8009Appendix E. Changes from RFC 3501 / IMAP4rev1
8010
8011 Below is the summary of changes since RFC 3501:
8012
8013 1. Support for 64-bit message and body part sizes.
8014
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].
8023
8024 3. Added STATUS SIZE [RFC8438] and STATUS DELETED.
8025
8026 4. SEARCH command now requires to return the ESEARCH response
8027 (SEARCH response is now deprecated).
8028
8029 5. Clarified which SEARCH keys have to use substring match and
8030 which don't.
8031
8032 6. Clarified that the server should decode parameter value
8033 continuations as described in [RFC2231]. This requirement was
8034 hidden in [RFC2231] itself.
8035
8036 7. Clarified that the COPYUID response code is returned for both
8037 MOVE and UID MOVE.
8038
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
8042 created.
8043
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.
8047
8048 10. SELECT/EXAMINE are now required to return an untagged LIST
8049 response.
8050
8051 11. UNSEEN response code on SELECT/EXAMINE is now deprecated.
8052
8053 12. RECENT response on SELECT/EXAMINE, \Recent flag, RECENT STATUS,
8054 and SEARCH NEW items are now deprecated.
8055
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.
8059
8060 14. For future extensibility, extended ABNF for tagged-ext-simple to
8061 allow for bare number64.
8062
8063 15. Added SHOULD level requirement on IMAP servers to support
8064 $MDNSent, $Forwarded, $Junk, $NonJunk, and $Phishing keywords.
8065
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.
8069
8070 17. Removed the CHECK command. Clients should use NOOP instead.
8071
8072 18. RFC822, RFC822.HEADER, and RFC822.TEXT FETCH data items were
8073 deprecated. Clients should use the corresponding BODY[]
8074 variants instead.
8075
8076 19. LSUB command was deprecated. Clients should use LIST
8077 (SUBSCRIBED) instead.
8078
8079 20. IDLE command can now return updates not related to the currently
8080 selected mailbox state.
8081
8082 21. All unsolicited FETCH updates are required to include UID.
8083
8084 22. Clarified that client implementations MUST ignore response codes
8085 that they do not recognize. (Changed from a SHOULD to a MUST.)
8086
8087 23. resp-text ABNF non-terminal was updated to allow for empty text.
8088
8089 24. After ENABLE, IMAP4rev2 human-readable response text can include
8090 non-ASCII encoded in UTF-8.
8091
8092 25. Updated to use modern TLS-related recommendations as per
8093 [RFC7525], [RFC7817], and [RFC8314].
8094
8095 26. Added warnings about use of ALERT response codes and PREAUTH
8096 response.
8097
8098 27. Replaced DIGEST-MD5 SASL mechanism with SCRAM-SHA-256. DIGEST-
8099 MD5 was deprecated.
8100
8101 28. Clarified that any command received from the client resets
8102 server autologout timer.
8103
8104 29. Revised IANA registration procedure for IMAP extensions and
8105 removed "X" convention in accordance with [BCP178].
8106
8107 30. Loosened requirements on servers when closing connections to be
8108 more aligned with existing practices.
8109
8110Appendix F. Other Recommended IMAP Extensions
8111
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.
8119
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
8123 state.
8124
8125 2. OBJECTID extension [RFC8474] helps with preserving the IMAP
8126 client cache when messages are moved/copied or mailboxes are
8127 renamed.
8128
8129Acknowledgements
8130
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.
8134
8135 Chris Newman has contributed text on I18N and use of UTF-8 in
8136 messages and mailbox names.
8137
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.
8142
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.
8153
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
8157 [RFC3348].
8158
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.
8164
8165Index
8166
8167 $ + - \ A B C D E F H I K L M N O P R S T U
8168
8169 $
8170
8171 $Forwarded (predefined flag)
8172 Section 2.3.2
8173 $Junk (predefined flag)
8174 Section 2.3.2
8175 $MDNSent (predefined flag)
8176 Section 2.3.2
8177 $NotJunk (predefined flag)
8178 Section 2.3.2
8179 $Phishing (predefined flag)
8180 Section 2.3.2, Paragraph 6.10.1
8181
8182 +
8183
8184 +FLAGS <flag list>
8185 Section 6.4.6
8186 +FLAGS.SILENT <flag list>
8187 Section 6.4.6
8188
8189 -
8190
8191 -FLAGS <flag list>
8192 Section 6.4.6
8193 -FLAGS.SILENT <flag list>
8194 Section 6.4.6
8195
8196 \
8197
8198 \All (mailbox name attribute)
8199 Section 7.3.1
8200 \Answered (system flag)
8201 Section 2.3.2
8202 \Archive (mailbox name attribute)
8203 Section 7.3.1
8204 \Deleted (system flag)
8205 Section 2.3.2
8206 \Draft (system flag)
8207 Section 2.3.2
8208 \Drafts (mailbox name attribute)
8209 Section 7.3.1
8210 \Flagged (mailbox name attribute)
8211 Section 7.3.1
8212 \Flagged (system flag)
8213 Section 2.3.2
8214 \HasChildren (mailbox name attribute)
8215 Section 7.3.1
8216 \HasNoChildren (mailbox name attribute)
8217 Section 7.3.1
8218 \Junk (mailbox name attribute)
8219 Section 7.3.1
8220 \Marked (mailbox name attribute)
8221 Section 7.3.1
8222 \Noinferiors (mailbox name attribute)
8223 Section 7.3.1
8224 \NonExistent (mailbox name attribute)
8225 Section 7.3.1, Paragraph 4.2.1
8226 \Noselect (mailbox name attribute)
8227 Section 7.3.1
8228 \Recent (system flag)
8229 Section 2.3.2
8230 \Remote (mailbox name attribute)
8231 Section 7.3.1
8232 \Seen (system flag)
8233 Section 2.3.2
8234 \Sent (mailbox name attribute)
8235 Section 7.3.1
8236 \Subscribed (mailbox name attribute)
8237 Section 7.3.1
8238 \Trash (mailbox name attribute)
8239 Section 7.3.1
8240 \Unmarked (mailbox name attribute)
8241 Section 7.3.1
8242
8243 A
8244
8245 ALERT (response code)
8246 Section 7.1
8247 ALL (fetch item)
8248 Section 6.4.5
8249 ALL (search key)
8250 Section 6.4.4
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)
8258 Section 6.4.4
8259 APPEND (command)
8260 Section 6.3.12
8261 APPENDUID (response code)
8262 Section 7.1, Paragraph 4.6.1
8263 AUTHENTICATE (command)
8264 Section 6.2.2
8265 AUTHENTICATIONFAILED (response code)
8266 Section 7.1, Paragraph 4.8.1
8267 AUTHORIZATIONFAILED (response code)
8268 Section 7.1, Paragraph 4.10.1
8269
8270 B
8271
8272 BAD (response)
8273 Section 7.1.3
8274 BADCHARSET (response code)
8275 Section 7.1
8276 BCC <string> (search key)
8277 Section 6.4.4
8278 BEFORE <date> (search key)
8279 Section 6.4.4
8280 BINARY.PEEK[<section-binary>]<<partial>> (fetch item)
8281 Section 6.4.5
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
8290 BODY (fetch item)
8291 Section 6.4.5
8292 BODY (fetch result)
8293 Section 7.5.2
8294 BODY <string> (search key)
8295 Section 6.4.4
8296 BODY.PEEK[<section>]<<partial>> (fetch item)
8297 Section 6.4.5
8298 BODYSTRUCTURE (fetch item)
8299 Section 6.4.5
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
8306 BYE (response)
8307 Section 7.1.5
8308 Body Structure (message attribute)
8309 Section 2.3.6
8310
8311 C
8312
8313 CANNOT (response code)
8314 Section 7.1, Paragraph 4.14.1
8315 CAPABILITY (command)
8316 Section 6.1.1
8317 CAPABILITY (response code)
8318 Section 7.1
8319 CAPABILITY (response)
8320 Section 7.2.2
8321 CC <string> (search key)
8322 Section 6.4.4
8323 CLIENTBUG (response code)
8324 Section 7.1, Paragraph 4.18.1
8325 CLOSE (command)
8326 Section 6.4.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
8331 COPY (command)
8332 Section 6.4.7
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)
8338 Section 6.4.4
8339 COUNT (search return item name)
8340 Section 7.3.4
8341 CREATE (command)
8342 Section 6.3.4
8343
8344 D
8345
8346 DELETE (command)
8347 Section 6.3.5
8348 DELETED (search key)
8349 Section 6.4.4
8350 DELETED (status item)
8351 Section 6.3.11
8352 DRAFT (search key)
8353 Section 6.4.4
8354
8355 E
8356
8357 ENABLE (command)
8358 Section 6.3.1
8359 ENVELOPE (fetch item)
8360 Section 6.4.5
8361 ENVELOPE (fetch result)
8362 Section 7.5.2, Paragraph 4.42.1
8363 ESEARCH (response)
8364 Section 7.3.4
8365 EXAMINE (command)
8366 Section 6.3.3
8367 EXPIRED (response code)
8368 Section 7.1, Paragraph 4.28.1
8369 EXPUNGE (command)
8370 Section 6.4.3
8371 EXPUNGE (response)
8372 Section 7.5.1
8373 EXPUNGEISSUED (response code)
8374 Section 7.1, Paragraph 4.30.1
8375 Envelope Structure (message attribute)
8376 Section 2.3.5
8377
8378 F
8379
8380 FAST (fetch item)
8381 Section 6.4.5
8382 FETCH (command)
8383 Section 6.4.5
8384 FETCH (response)
8385 Section 7.5.2
8386 FLAGGED (search key)
8387 Section 6.4.4
8388 FLAGS (fetch item)
8389 Section 6.4.5
8390 FLAGS (fetch result)
8391 Section 7.5.2
8392 FLAGS (response)
8393 Section 7.3.5
8394 FLAGS <flag list> (store command data item)
8395 Section 6.4.6
8396 FLAGS.SILENT <flag list> (store command data item)
8397 Section 6.4.6
8398 FROM <string> (search key)
8399 Section 6.4.4
8400 FULL (fetch item)
8401 Section 6.4.5
8402 Flags (message attribute)
8403 Section 2.3.2
8404
8405 H
8406
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)
8412 Section 6.4.4
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
8417
8418 I
8419
8420 IDLE (command)
8421 Section 6.3.13
8422 INTERNALDATE ( fetch item)
8423 Section 6.4.5
8424 INTERNALDATE (fetch result)
8425 Section 7.5.2
8426 INUSE (response code)
8427 Section 7.1, Paragraph 4.34.1
8428 Internal Date (message attribute)
8429 Section 2.3.3
8430
8431 K
8432
8433 KEYWORD <flag> (search key)
8434 Section 6.4.4
8435 Keyword (type of flag)
8436 Section 2.3.2, Paragraph 4
8437
8438 L
8439
8440 LARGER <n> (search key)
8441 Section 6.4.4
8442 LIMIT (response code)
8443 Section 7.1, Paragraph 4.36.1
8444 LIST (command)
8445 Section 6.3.9
8446 LIST (response)
8447 Section 7.3.1
8448 LOGOUT (command)
8449 Section 6.1.3
8450
8451 M
8452
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)
8458 Section 1.2
8459 MESSAGES (status item)
8460 Section 6.3.11
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
8467 MOVE (command)
8468 Section 6.4.8
8469 MUST (specification requirement term)
8470 Section 1.2
8471 MUST NOT (specification requirement term)
8472 Section 1.2
8473 Message Sequence Number (message attribute)
8474 Section 2.3.1.2
8475
8476 N
8477
8478 NAMESPACE (command)
8479 Section 6.3.10
8480 NAMESPACE (response)
8481 Section 7.3.2
8482 NO (response)
8483 Section 7.1.2
8484 NONEXISTENT (response code)
8485 Section 7.1, Paragraph 4.38.1
8486 NOOP (command)
8487 Section 6.1.2
8488 NOPERM (response code)
8489 Section 7.1, Paragraph 4.40.1
8490 NOT <search-key> (search key)
8491 Section 6.4.4
8492 NOT RECOMMENDED (specification requirement term)
8493 Section 1.2
8494
8495 O
8496
8497 OK (response)
8498 Section 7.1.1
8499 ON <date> (search key)
8500 Section 6.4.4
8501 OPTIONAL (specification requirement term)
8502 Section 1.2; Section 1.2
8503 OR <search-key1> <search-key2> (search key)
8504 Section 6.4.4
8505 OVERQUOTA (response code)
8506 Section 7.1, Paragraph 4.42.1
8507
8508 P
8509
8510 PARSE (response code)
8511 Section 7.1
8512 PERMANENTFLAGS (response code)
8513 Section 7.1, Paragraph 4.46.1
8514 PREAUTH (response)
8515 Section 7.1.4
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
8520 Predefined keywords
8521 Section 2.3.2, Paragraph 5
8522
8523 R
8524
8525 READ-ONLY (response code)
8526 Section 7.1
8527 READ-WRITE (response code)
8528 Section 7.1
8529 RECOMMENDED (specification requirement term)
8530 Section 1.2
8531 RENAME (command)
8532 Section 6.3.6
8533 REQUIRED (specification requirement term)
8534 Section 1.2
8535 RFC822.SIZE (fetch item)
8536 Section 6.4.5
8537 RFC822.SIZE (fetch result)
8538 Section 7.5.2
8539 RFC822.SIZE (message attribute)
8540 Section 2.3.4
8541
8542 S
8543
8544 SAVE (search result option)
8545 Section 6.4.4, Paragraph 6.10.1
8546 SEARCH (command)
8547 Section 6.4.4
8548 SEEN (search key)
8549 Section 6.4.4
8550 SELECT (command)
8551 Section 6.3.2
8552 SENTBEFORE <date> (search key)
8553 Section 6.4.4
8554 SENTON <date> (search key)
8555 Section 6.4.4
8556 SENTSINCE <date> (search key)
8557 Section 6.4.4
8558 SERVERBUG (response code)
8559 Section 7.1, Paragraph 4.54.1
8560 SHOULD (specification requirement term)
8561 Section 1.2
8562 SHOULD NOT (specification requirement term)
8563 Section 1.2
8564 SINCE <date> (search key)
8565 Section 6.4.4
8566 SIZE (status item)
8567 Section 6.3.11
8568 SMALLER <n> (search key)
8569 Section 6.4.4
8570 STARTTLS (command)
8571 Section 6.2.1
8572 STATUS (command)
8573 Section 6.3.11
8574 STATUS (response)
8575 Section 7.3.3
8576 STORE (command)
8577 Section 6.4.6
8578 SUBJECT <string> (search key)
8579 Section 6.4.4
8580 SUBSCRIBE (command)
8581 Section 6.3.7
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
8586
8587 T
8588
8589 TEXT (part specifier)
8590 Section 6.4.5.1, Paragraph 5
8591 TEXT <string> (search key)
8592 Section 6.4.4
8593 TO <string> (search key)
8594 Section 6.4.4
8595 TRYCREATE (response code)
8596 Section 7.1
8597
8598 U
8599
8600 UID (command)
8601 Section 6.4.9
8602 UID (fetch item)
8603 Section 6.4.5
8604 UID (fetch result)
8605 Section 7.5.2
8606 UID <sequence set> (search key)
8607 Section 6.4.4
8608 UIDNEXT (response code)
8609 Section 7.1
8610 UIDNEXT (status item)
8611 Section 6.3.11
8612 UIDNOTSTICKY (response code)
8613 Section 7.1, Paragraph 4.60.1
8614 UIDVALIDITY (response code)
8615 Section 7.1
8616 UIDVALIDITY (status item)
8617 Section 6.3.11
8618 UNANSWERED (search key)
8619 Section 6.4.4
8620 UNAVAILABLE (response code)
8621 Section 7.1, Paragraph 4.64.1
8622 UNDELETED (search key)
8623 Section 6.4.4
8624 UNDRAFT (search key)
8625 Section 6.4.4
8626 UNFLAGGED (search key)
8627 Section 6.4.4
8628 UNKEYWORD <flag> (search key)
8629 Section 6.4.4
8630 UNKNOWN-CTE (response code)
8631 Section 7.1
8632 UNSEEN (search key)
8633 Section 6.4.4
8634 UNSEEN (status item)
8635 Section 6.3.11
8636 UNSELECT (command)
8637 Section 6.4.2
8638 UNSUBSCRIBE (command)
8639 Section 6.3.8
8640 Unique Identifier (UID) (message attribute)
8641 Section 2.3.1.1
8642
8643Authors' Addresses
8644
8645 Alexey Melnikov (editor)
8646 Isode Ltd
8647 14 Castle Mews
8648 Hampton, Middlesex
8649 TW12 2NP
8650 United Kingdom
8651
8652 Email: Alexey.Melnikov@isode.com
8653
8654
8655 Barry Leiba (editor)
8656 Futurewei Technologies
8657
8658 Email: barryleiba@computer.org
8659 URI: http://internetmessagingtechnology.org/