idnits 2.17.1 draft-crispin-imap-base-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 22 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([ACAP], [IMAP-HISTORICAL], [IMAP2], [SMTP], [IMAP-DISC], [IMAP-COMPAT], [IMAP-OBSOLETE]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 201: '... 1) MUST, or the adjective REQUIR...' RFC 2119 keyword, line 204: '... 2) MUST NOT that the definition ...' RFC 2119 keyword, line 207: '... 3) SHOULD means that there may e...' RFC 2119 keyword, line 209: '... implications MUST be understood an...' RFC 2119 keyword, line 212: '... 4) SHOULD NOT means that there m...' (199 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 1996) is 10055 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'IMAP-DISC' on line 3460 looks like a reference -- Missing reference section? 'ACAP' on line 3447 looks like a reference -- Missing reference section? 'SMTP' on line 3495 looks like a reference -- Missing reference section? 'IMAP2' on line 3472 looks like a reference -- Missing reference section? 'IMAP-OBSOLETE' on line 3469 looks like a reference -- Missing reference section? 'IMAP-COMPAT' on line 3457 looks like a reference -- Missing reference section? 'IMAP-HISTORICAL' on line 3463 looks like a reference -- Missing reference section? 'RFC-822' on line 3492 looks like a reference -- Missing reference section? 'MIME-IMB' on line 3481 looks like a reference -- Missing reference section? 'UTF-7' on line 3498 looks like a reference -- Missing reference section? 'IMAP-AUTH' on line 3454 looks like a reference -- Missing reference section? 'UNSEEN 12' on line 1070 looks like a reference -- Missing reference section? 'UIDVALIDITY 3857529045' on line 2900 looks like a reference -- Missing reference section? 'UNSEEN 8' on line 1099 looks like a reference -- Missing reference section? 'MIME-HDRS' on line 3488 looks like a reference -- Missing reference section? 'HEADER' on line 2916 looks like a reference -- Missing reference section? 'TEXT' on line 2852 looks like a reference -- Missing reference section? 'DISPOSITION' on line 3450 looks like a reference -- Missing reference section? 'LANGUAGE-TAGS' on line 3475 looks like a reference -- Missing reference section? 'MD5' on line 3478 looks like a reference -- Missing reference section? 'UNSEEN 17' on line 2899 looks like a reference -- Missing reference section? 'READ-WRITE' on line 2901 looks like a reference -- Missing reference section? 'MIME-IMT' on line 3485 looks like a reference -- Missing reference section? 'IMAP-MODEL' on line 3466 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 1 warning (==), 27 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Crispin 2 Internet Draft: IMAP4rev1 University of Washington 3 Document: internet-drafts/draft-crispin-imap-base-06.txt October 1996 5 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 7 Status of this Memo 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its areas, 11 and its working groups. Note that other groups may also distribute 12 working documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six months 15 and may be updated, replaced, or obsoleted by other documents at any 16 time. It is inappropriate to use Internet-Drafts as reference 17 material or to cite them other than as "work in progress." 19 To learn the current status of any Internet-Draft, please check the 20 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 21 Directories on ds.internic.net (US East Coast), nic.nordu.net 22 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 23 Rim). 25 A revised version of this draft document will be submitted to the RFC 26 editor as an Proposed Standard for the Internet Community. 27 Discussion and suggestions for improvement are requested, and should 28 be sent to imap@CAC.Washington.EDU. This document will expire before 29 30 April 1997. Distribution of this memo is unlimited. 31 This document is a revision of RFC 1730. Appendix B of this document 32 describes revisions and changes. 34 Abstract 36 The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) 37 allows a client to access and manipulate electronic mail messages on 38 a server. IMAP4rev1 permits manipulation of remote message folders, 39 called "mailboxes", in a way that is functionally equivalent to local 40 mailboxes. IMAP4rev1 also provides the capability for an offline 41 client to resynchronize with the server (see also [IMAP-DISC]). 43 IMAP4rev1 includes operations for creating, deleting, and renaming 44 mailboxes; checking for new messages; permanently removing messages; 45 setting and clearing flags; RFC 822 and MIME parsing; searching; and 46 selective fetching of message attributes, texts, and portions 47 thereof. Messages in IMAP4rev1 are accessed by the use of numbers. 48 These numbers are either message sequence numbers or unique 49 identifiers. 51 IMAP4rev1 supports a single server. A mechanism for accessing 52 configuration information to support multiple IMAP4rev1 servers is 53 discussed in [ACAP]. 55 IMAP4rev1 does not specify a means of posting mail; this function is 56 handled by a mail transfer protocol such as [SMTP]. 58 IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and 59 unpublished IMAP2bis protocols. In the course of the evolution of 60 IMAP4rev1, some aspects in the earlier protocol have become obsolete. 61 Obsolete commands, responses, and data formats which an IMAP4rev1 62 implementation may encounter when used with an earlier implementation 63 are described in [IMAP-OBSOLETE]. 65 Other compatibility issues with IMAP2bis, the most common variant of 66 the earlier protocol, are discussed in [IMAP-COMPAT]. A full 67 discussion of compatibility issues with rare (and presumed extinct) 68 variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is 69 primarily of historical interest. 71 Table of Contents 73 IMAP4rev1 Protocol Specification .................................. 1 74 1. How to Read This Document ................................. 1 75 1.1. Organization of This Document ............................. 1 76 1.2. Conventions Used in This Document ......................... 1 77 2. Protocol Overview ......................................... 2 78 2.1. Link Level ................................................ 2 79 2.2. Commands and Responses .................................... 2 80 2.2.1. Client Protocol Sender and Server Protocol Receiver ....... 2 81 2.2.2. Server Protocol Sender and Client Protocol Receiver ....... 3 82 2.3. Message Attributes ........................................ 4 83 2.3.1. Message Numbers ........................................... 4 84 2.3.1.1. Unique Identifier (UID) Message Attribute ......... 4 85 2.3.1.2. Message Sequence Number Message Attribute ......... 5 86 2.3.2. Flags Message Attribute ................................... 6 87 2.3.3. Internal Date Message Attribute ........................... 6 88 2.3.4. [RFC-822] Size Message Attribute .......................... 7 89 2.3.5. Envelope Structure Message Attribute ...................... 7 90 2.3.6. Body Structure Message Attribute .......................... 7 91 2.4. Message Texts ............................................. 7 92 3. State and Flow Diagram .................................... 7 93 3.1. Non-Authenticated State ................................... 7 94 3.2. Authenticated State ....................................... 8 95 3.3. Selected State ............................................ 8 96 3.4. Logout State .............................................. 8 97 4. Data Formats .............................................. 10 98 4.1. Atom ...................................................... 10 99 4.2. Number .................................................... 10 100 4.3. String .................................................... 10 101 4.3.1. 8-bit and Binary Strings .................................. 11 102 4.4. Parenthesized List ........................................ 11 103 4.5. NIL ....................................................... 11 104 5. Operational Considerations ................................ 11 105 5.1. Mailbox Naming ............................................ 11 106 5.1.1. Mailbox Hierarchy Naming .................................. 12 107 5.1.2. Mailbox Namespace Naming Convention ....................... 12 108 5.1.3. Mailbox International Naming Convention ................... 12 109 5.2. Mailbox Size and Message Status Updates ................... 13 110 5.3. Response when no Command in Progress ...................... 14 111 5.4. Autologout Timer .......................................... 14 112 5.5. Multiple Commands in Progress ............................. 14 113 6. Client Commands ........................................... 16 114 6.1. Client Commands - Any State ............................... 16 115 6.1.1. CAPABILITY Command ........................................ 16 116 6.1.2. NOOP Command .............................................. 17 117 6.1.3. LOGOUT Command ............................................ 18 118 6.2. Client Commands - Non-Authenticated State ................. 18 119 6.2.1. AUTHENTICATE Command ...................................... 18 120 6.2.2. LOGIN Command ............................................. 20 121 6.3. Client Commands - Authenticated State ..................... 21 122 6.3.1. SELECT Command ............................................ 21 123 6.3.2. EXAMINE Command ........................................... 22 124 6.3.3. CREATE Command ............................................ 23 125 6.3.4. DELETE Command ............................................ 24 126 6.3.5. RENAME Command ............................................ 26 127 6.3.6. SUBSCRIBE Command ......................................... 27 128 6.3.7. UNSUBSCRIBE Command ....................................... 28 129 6.3.8. LIST Command .............................................. 28 130 6.3.9. LSUB Command .............................................. 30 131 6.3.10. STATUS Command ............................................ 31 132 6.3.11. APPEND Command ............................................ 32 133 6.4. Client Commands - Selected State .......................... 34 134 6.4.1. CHECK Command ............................................. 34 135 6.4.2. CLOSE Command ............................................. 34 136 6.4.3. EXPUNGE Command ........................................... 35 137 6.4.4. SEARCH Command ............................................ 36 138 6.4.5. FETCH Command ............................................. 39 139 6.4.6. STORE Command ............................................. 43 140 6.4.7. COPY Command .............................................. 44 141 6.4.8. UID Command ............................................... 45 142 6.5. Client Commands - Experimental/Expansion .................. 46 143 6.5.1. X Command ........................................... 46 144 7. Server Responses .......................................... 47 145 7.1. Server Responses - Status Responses ....................... 48 146 7.1.1. OK Response ............................................... 49 147 7.1.2. NO Response ............................................... 50 148 7.1.3. BAD Response .............................................. 50 149 7.1.4. PREAUTH Response .......................................... 51 150 7.1.5. BYE Response .............................................. 51 151 7.2. Server Responses - Server and Mailbox Status .............. 52 152 7.2.1. CAPABILITY Response ....................................... 52 153 7.2.2. LIST Response ............................................. 52 154 7.2.3. LSUB Response ............................................. 53 155 7.2.4 STATUS Response ........................................... 54 156 7.2.5. SEARCH Response ........................................... 54 157 7.2.6. FLAGS Response ............................................ 54 158 7.3. Server Responses - Mailbox Size ........................... 55 159 7.3.1. EXISTS Response ........................................... 55 160 7.3.2. RECENT Response ........................................... 55 161 7.4. Server Responses - Message Status ......................... 56 162 7.4.1. EXPUNGE Response .......................................... 56 163 7.4.2. FETCH Response ............................................ 57 164 7.5. Server Responses - Command Continuation Request ........... 62 165 8. Sample IMAP4rev1 session .................................. 63 166 9. Formal Syntax ............................................. 64 167 10. Author's Note ............................................. 75 168 11. Security Considerations ................................... 75 169 12. Author's Address .......................................... 75 170 Appendices ........................................................ 76 171 A. References ................................................ 76 172 B. Changes from RFC 1730 ..................................... 77 173 C. Key Word Index ............................................ 80 174 IMAP4rev1 Protocol Specification 176 1. How to Read This Document 178 1.1. Organization of This Document 180 This document is written from the point of view of the implementor of 181 an IMAP4rev1 client or server. Beyond the protocol overview in 182 section 2, it is not optimized for someone trying to understand the 183 operation of the protocol. The material in sections 3 through 5 184 provides the general context and definitions with which IMAP4rev1 185 operates. 187 Sections 6, 7, and 9 describe the IMAP commands, responses, and 188 syntax, respectively. The relationships among these are such that it 189 is almost impossible to understand any of them separately. In 190 particular, do not attempt to deduce command syntax from the command 191 section alone; instead refer to the Formal Syntax section. 193 1.2. Conventions Used in This Document 195 In examples, "C:" and "S:" indicate lines sent by the client and 196 server respectively. 198 The following terms are used in this document to signify the 199 requirements of this specification. 201 1) MUST, or the adjective REQUIRED, means that the definition is 202 an absolute requirement of the specification. 204 2) MUST NOT that the definition is an absolute prohibition of the 205 specification. 207 3) SHOULD means that there may exist valid reasons in particular 208 circumstances to ignore a particular item, but the full 209 implications MUST be understood and carefully weighed before 210 choosing a different course. 212 4) SHOULD NOT means that there may exist valid reasons in 213 particular circumstances when the particular behavior is 214 acceptable or even useful, but the full implications SHOULD be 215 understood and the case carefully weighed before implementing 216 any behavior described with this label. 218 5) MAY, or the adjective OPTIONAL, means that an item is truly 219 optional. One vendor may choose to include the item because a 220 particular marketplace requires it or because the vendor feels 221 that it enhances the product while another vendor may omit the 222 same item. An implementation which does not include a 223 particular option MUST be prepared to interoperate with another 224 implementation which does include the option. 226 "Can" is used instead of "may" when referring to a possible 227 circumstance or situation, as opposed to an optional facility of 228 the protocol. 230 "User" is used to refer to a human user, whereas "client" refers 231 to the software being run by the user. 233 2. Protocol Overview 235 2.1. Link Level 237 The IMAP4rev1 protocol assumes a reliable data stream such as 238 provided by TCP. When TCP is used, an IMAP4rev1 server listens on 239 port 143. 241 2.2. Commands and Responses 243 An IMAP4rev1 session consists of the establishment of a client/server 244 connection, an initial greeting from the server, and client/server 245 interactions. These client/server interactions consist of a client 246 command, server data, and a server completion result response. 248 All interactions transmitted by client and server are in the form of 249 lines; that is, strings that end with a CRLF. The protocol receiver 250 of an IMAP4rev1 client or server is either reading a line, or is 251 reading a sequence of octets with a known count followed by a line. 253 2.2.1. Client Protocol Sender and Server Protocol Receiver 255 The client command begins an operation. Each client command is 256 prefixed with a identifier (typically a short alphanumeric string, 257 e.g. A0001, A0002, etc.) called a "tag". A different tag is 258 generated by the client for each command. 260 There are two cases in which a line from the client does not 261 represent a complete command. In one case, a command argument is 262 quoted with an octet count (see the description of literal in String 263 under Data Formats); in the other case, the command arguments require 264 server feedback (see the AUTHENTICATE command). In either case, the 265 server sends a command continuation request response if it is ready 266 for the octets (if appropriate) and the remainder of the command. 267 This response is prefixed with the token "+". 269 Note: If, instead, the server detected an error in the 270 command, it sends a BAD completion response with tag 271 matching the command (as described below) to reject the 272 command and prevent the client from sending any more of the 273 command. 275 It is also possible for the server to send a completion 276 response for some other command (if multiple commands are 277 in progress), or untagged data. In either case, the 278 command continuation request is still pending; the client 279 takes the appropriate action for the response, and reads 280 another response from the server. In all cases, the client 281 MUST send a complete command (including receiving all 282 command continuation request responses and command 283 continuations for the command) before initiating a new 284 command. 286 The protocol receiver of an IMAP4rev1 server reads a command line 287 from the client, parses the command and its arguments, and transmits 288 server data and a server command completion result response. 290 2.2.2. Server Protocol Sender and Client Protocol Receiver 292 Data transmitted by the server to the client and status responses 293 that do not indicate command completion are prefixed with the token 294 "*", and are called untagged responses. 296 Server data MAY be sent as a result of a client command, or MAY be 297 sent unilaterally by the server. There is no syntactic difference 298 between server data that resulted from a specific command and server 299 data that were sent unilaterally. 301 The server completion result response indicates the success or 302 failure of the operation. It is tagged with the same tag as the 303 client command which began the operation. Thus, if more than one 304 command is in progress, the tag in a server completion response 305 identifies the command to which the response applies. There are 306 three possible server completion responses: OK (indicating success), 307 NO (indicating failure), or BAD (indicating protocol error such as 308 unrecognized command or command syntax error). 310 The protocol receiver of an IMAP4rev1 client reads a response line 311 from the server. It then takes action on the response based upon the 312 first token of the response, which can be a tag, a "*", or a "+". 314 A client MUST be prepared to accept any server response at all times. 315 This includes server data that was not requested. Server data SHOULD 316 be recorded, so that the client can reference its recorded copy 317 rather than sending a command to the server to request the data. In 318 the case of certain server data, the data MUST be recorded. 320 This topic is discussed in greater detail in the Server Responses 321 section. 323 2.3. Message Attributes 325 In addition to message text, each message has several attributes 326 associated with it. These attributes may be retrieved individually 327 or in conjunction with other attributes or message texts. 329 2.3.1. Message Numbers 331 Messages in IMAP4rev1 are accessed by one of two numbers; the unique 332 identifier and the message sequence number. 334 2.3.1.1. Unique Identifier (UID) Message Attribute 336 A 32-bit value assigned to each message, which when used with the 337 unique identifier validity value (see below) forms a 64-bit value 338 that is permanently guaranteed not to refer to any other message in 339 the mailbox. Unique identifiers are assigned in a strictly ascending 340 fashion in the mailbox; as each message is added to the mailbox it is 341 assigned a higher UID than the message(s) which were added 342 previously. 344 Unlike message sequence numbers, unique identifiers are not 345 necessarily contiguous. Unique identifiers also persist across 346 sessions. This permits a client to resynchronize its state from a 347 previous session with the server (e.g. disconnected or offline access 348 clients); this is discussed further in [IMAP-DISC]. 350 Associated with every mailbox is a unique identifier validity value, 351 which is sent in an UIDVALIDITY response code in an OK untagged 352 response at mailbox selection time. If unique identifiers from an 353 earlier session fail to persist to this session, the unique 354 identifier validity value MUST be greater than the one used in the 355 earlier session. 357 Note: Unique identifiers MUST be strictly ascending in the 358 mailbox at all times. If the physical message store is 359 re-ordered by a non-IMAP agent, this requires that the 360 unique identifiers in the mailbox be regenerated, since the 361 former unique identifers are no longer strictly ascending 362 as a result of the re-ordering. Another instance in which 363 unique identifiers are regenerated is if the message store 364 has no mechanism to store unique identifiers. Although 365 this specification recognizes that this may be unavoidable 366 in certain server environments, it STRONGLY ENCOURAGES 367 message store implementation techniques that avoid this 368 problem. 370 Another cause of non-persistance is if the mailbox is 371 deleted and a new mailbox with the same name is created at 372 a later date, Since the name is the same, a client may not 373 know that this is a new mailbox unless the unique 374 identifier validity is different. A good value to use for 375 the unique identifier validity value is a 32-bit 376 representation of the creation date/time of the mailbox. 377 It is alright to use a constant such as 1, but only if it 378 guaranteed that unique identifiers will never be reused, 379 even in the case of a mailbox being deleted (or renamed) 380 and a new mailbox by the same name created at some future 381 time. 383 The unique identifier of a message MUST NOT change during the 384 session, and SHOULD NOT change between sessions. However, if it is 385 not possible to preserve the unique identifier of a message in a 386 subsequent session, each subsequent session MUST have a new unique 387 identifier validity value that is larger than any that was used 388 previously. 390 2.3.1.2. Message Sequence Number Message Attribute 392 A relative position from 1 to the number of messages in the mailbox. 393 This position MUST be ordered by ascending unique identifier. As 394 each new message is added, it is assigned a message sequence number 395 that is 1 higher than the number of messages in the mailbox before 396 that new message was added. 398 Message sequence numbers can be reassigned during the session. For 399 example, when a message is permanently removed (expunged) from the 400 mailbox, the message sequence number for all subsequent messages is 401 decremented. Similarly, a new message can be assigned a message 402 sequence number that was once held by some other message prior to an 403 expunge. 405 In addition to accessing messages by relative position in the 406 mailbox, message sequence numbers can be used in mathematical 407 calculations. For example, if an untagged "EXISTS 11" is received, 408 and previously an untagged "8 EXISTS" was received, three new 409 messages have arrived with message sequence numbers of 9, 10, and 11. 410 Another example; if message 287 in a 523 message mailbox has UID 411 12345, there are exactly 286 messages which have lesser UIDs and 236 412 messages which have greater UIDs. 414 2.3.2. Flags Message Attribute 416 A list of zero or more named tokens associated with the message. A 417 flag is set by its addition to this list, and is cleared by its 418 removal. 420 A flag may be permanent or session-only on a per-flag basis. 421 Permanent flags are those which the client can add or remove from the 422 message flags permanently; that is, subsequent sessions will see any 423 change in permanent flags. Changes to session flags are valid only 424 in that session. 426 Note: The \Recent flag is a special case of a session flag. 427 \Recent can not be used as an argument in a STORE command, 428 and thus can not be changed at all. 430 There are two types of flags in IMAP4rev1. A flag of either type may 431 be permanent or session-only. 433 A system flag is a flag name that is pre-defined in this 434 specification. All system flags begin with "\". Certain system 435 flags (\Deleted and \Seen) have special semantics described 436 elsewhere. 438 A keyword is defined by the server implementation. Keywords do not 439 begin with "\". Servers MAY permit the client to define new keywords 440 in the mailbox (see the description of the PERMANENTFLAGS response 441 code for more information). 443 2.3.3. Internal Date Message Attribute 445 The internal date and time of the message on the server. This is not 446 the date and time in the [RFC-822] header, but rather a date and time 447 which reflects when the message was received. In the case of 448 messages delivered via [SMTP], this SHOULD be the date and time of 449 final delivery of the message as defined by [SMTP]. In the case of 450 messages delivered by the IMAP4rev1 COPY command, this SHOULD be the 451 internal date and time of the source message. In the case of 452 messages delivered by the IMAP4rev1 APPEND command, this SHOULD be 453 the date and time as specified in the APPEND command description. 454 All other cases are implementation defined. 456 2.3.4. [RFC-822] Size Message Attribute 458 The number of octets in the message, as expressed in [RFC-822] 459 format. 461 2.3.5. Envelope Structure Message Attribute 463 A parsed representation of the [RFC-822] envelope information (not to 464 be confused with an [SMTP] envelope) of the message. 466 2.3.6. Body Structure Message Attribute 468 A parsed representation of the [MIME-IMB] body structure information 469 of the message. 471 2.4. Message Texts 473 In addition to being able to fetch the full [RFC-822] text of a 474 message, IMAP4rev1 permits the fetching of portions of the full 475 message text. Specifically, it is possible to fetch the [RFC-822] 476 message header, [RFC-822] message body, [MIME-IMB] body part or 477 [MIME-IMB] header. 479 3. State and Flow Diagram 481 An IMAP4rev1 server is in one of four states. Most commands are 482 valid in only certain states. It is a protocol error for the client 483 to attempt a command while the command is in an inappropriate state. 484 In this case, a server will respond with a BAD or NO (depending upon 485 server implementation) command completion result. 487 3.1. Non-Authenticated State 489 In non-authenticated state, the client MUST supply authentication 490 credentials before most commands will be permitted. This state is 491 entered when a connection starts unless the connection has been 492 pre-authenticated. 494 3.2. Authenticated State 496 In authenticated state, the client is authenticated and MUST select a 497 mailbox to access before commands that affect messages will be 498 permitted. This state is entered when a pre-authenticated connection 499 starts, when acceptable authentication credentials have been 500 provided, or after an error in selecting a mailbox. 502 3.3. Selected State 504 In selected state, a mailbox has been selected to access. This state 505 is entered when a mailbox has been successfully selected. 507 3.4. Logout State 509 In logout state, the session is being terminated, and the server will 510 close the connection. This state can be entered as a result of a 511 client request or by unilateral server decision. 513 +--------------------------------------+ 514 |initial connection and server greeting| 515 +--------------------------------------+ 516 || (1) || (2) || (3) 517 VV || || 518 +-----------------+ || || 519 |non-authenticated| || || 520 +-----------------+ || || 521 || (7) || (4) || || 522 || VV VV || 523 || +----------------+ || 524 || | authenticated |<=++ || 525 || +----------------+ || || 526 || || (7) || (5) || (6) || 527 || || VV || || 528 || || +--------+ || || 529 || || |selected|==++ || 530 || || +--------+ || 531 || || || (7) || 532 VV VV VV VV 533 +--------------------------------------+ 534 | logout and close connection | 535 +--------------------------------------+ 537 (1) connection without pre-authentication (OK greeting) 538 (2) pre-authenticated connection (PREAUTH greeting) 539 (3) rejected connection (BYE greeting) 540 (4) successful LOGIN or AUTHENTICATE command 541 (5) successful SELECT or EXAMINE command 542 (6) CLOSE command, or failed SELECT or EXAMINE command 543 (7) LOGOUT command, server shutdown, or connection closed 545 4. Data Formats 547 IMAP4rev1 uses textual commands and responses. Data in IMAP4rev1 can 548 be in one of several forms: atom, number, string, parenthesized list, 549 or NIL. 551 4.1. Atom 553 An atom consists of one or more non-special characters. 555 4.2. Number 557 A number consists of one or more digit characters, and represents a 558 numeric value. 560 4.3. String 562 A string is in one of two forms: literal and quoted string. The 563 literal form is the general form of string. The quoted string form 564 is an alternative that avoids the overhead of processing a literal at 565 the cost of limitations of characters that can be used in a quoted 566 string. 568 A literal is a sequence of zero or more octets (including CR and LF), 569 prefix-quoted with an octet count in the form of an open brace ("{"), 570 the number of octets, close brace ("}"), and CRLF. In the case of 571 literals transmitted from server to client, the CRLF is immediately 572 followed by the octet data. In the case of literals transmitted from 573 client to server, the client MUST wait to receive a command 574 continuation request (described later in this document) before 575 sending the octet data (and the remainder of the command). 577 A quoted string is a sequence of zero or more 7-bit characters, 578 excluding CR and LF, with double quote (<">) characters at each end. 580 The empty string is represented as either "" (a quoted string with 581 zero characters between double quotes) or as {0} followed by CRLF (a 582 literal with an octet count of 0). 584 Note: Even if the octet count is 0, a client transmitting a 585 literal MUST wait to receive a command continuation 586 request. 588 4.3.1. 8-bit and Binary Strings 590 8-bit textual and binary mail is supported through the use of a 591 [MIME-IMB] content transfer encoding. IMAP4rev1 implementations MAY 592 transmit 8-bit or multi-octet characters in literals, but SHOULD do 593 so only when the character set is identified. 595 Although a BINARY body encoding is defined, unencoded binary strings 596 are not permitted. A "binary string" is any string with NUL 597 characters. Implementations MUST encode binary data into a textual 598 form such as BASE64 before transmitting the data. A string with an 599 excessive amount of CTL characters MAY also be considered to be 600 binary. 602 4.4. Parenthesized List 604 Data structures are represented as a "parenthesized list"; a sequence 605 of data items, delimited by space, and bounded at each end by 606 parentheses. A parenthesized list can contain other parenthesized 607 lists, using multiple levels of parentheses to indicate nesting. 609 The empty list is represented as () -- a parenthesized list with no 610 members. 612 4.5. NIL 614 The special atom "NIL" represents the non-existence of a particular 615 data item that is represented as a string or parenthesized list, as 616 distinct from the empty string "" or the empty parenthesized list (). 618 5. Operational Considerations 620 5.1. Mailbox Naming 622 The interpretation of mailbox names is implementation-dependent. 623 However, the case-insensitive mailbox name INBOX is a special name 624 reserved to mean "the primary mailbox for this user on this server". 626 5.1.1. Mailbox Hierarchy Naming 628 If it is desired to export hierarchical mailbox names, mailbox names 629 MUST be left-to-right hierarchical using a single character to 630 separate levels of hierarchy. The same hierarchy separator character 631 is used for all levels of hierarchy within a single name. 633 5.1.2. Mailbox Namespace Naming Convention 635 By convention, the first hierarchical element of any mailbox name 636 which begins with "#" identifies the "namespace" of the remainder of 637 the name. This makes it possible to disambiguate between different 638 types of mailbox stores, each of which have their own namespaces. 640 For example, implementations which offer access to USENET 641 newsgroups MAY use the "#news" namespace to partition the 642 USENET newsgroup namespace from that of other mailboxes. 643 Thus, the comp.mail.misc newsgroup would have an mailbox 644 name of "#news.comp.mail.misc", and the name 645 "comp.mail.misc" could refer to a different object (e.g. a 646 user's private mailbox). 648 5.1.3. Mailbox International Naming Convention 650 By convention, international mailbox names are specified using a 651 modified version of the UTF-7 encoding described in [UTF-7]. The 652 purpose of these modifications is to correct the following problems 653 with UTF-7: 655 1) UTF-7 uses the "+" character for shifting; this conflicts with 656 the common use of "+" in mailbox names, in particular USENET 657 newsgroup names. 659 2) UTF-7's encoding is BASE64 which uses the "/" character; this 660 conflicts with the use of "/" as a popular hierarchy delimiter. 662 3) UTF-7 prohibits the unencoded usage of "\"; this conflicts with 663 the use of "\" as a popular hierarchy delimiter. 665 4) UTF-7 prohibits the unencoded usage of "~"; this conflicts with 666 the use of "~" in some servers as a home directory indicator. 668 5) UTF-7 permits multiple alternate forms to represent the same 669 string; in particular, printable US-ASCII chararacters can be 670 represented in encoded form. 672 In modified UTF-7, printable US-ASCII characters except for "&" 673 represent themselves; that is, characters with octet values 0x20-0x25 674 and 0x27-0x7e. The character "&" (0x26) is represented by the 675 two-octet sequence "&-". 677 All other characters (octet values 0x00-0x1f, 0x7f-0xff, and all 678 Unicode 16-bit octets) are represented in modified BASE64, with a 679 further modification from [UTF-7] that "," is used instead of "/". 680 Modified BASE64 MUST NOT be used to represent any printing US-ASCII 681 character which can represent itself. 683 "&" is used to shift to modified BASE64 and "-" to shift back to 684 US-ASCII. All names start in US-ASCII, and MUST end in US-ASCII 685 (that is, a name that ends with a Unicode 16-bit octet MUST end with 686 a "-"). 688 For example, here is a mailbox name which mixes English, 689 Japanese, and Chinese text: ~peter/mail/&ZeVnLIqe-/&U,BTFw- 691 5.2. Mailbox Size and Message Status Updates 693 At any time, a server can send data that the client did not request. 694 Sometimes, such behavior is REQUIRED. For example, agents other than 695 the server MAY add messages to the mailbox (e.g. new mail delivery), 696 change the flags of message in the mailbox (e.g. simultaneous access 697 to the same mailbox by multiple agents), or even remove messages from 698 the mailbox. A server MUST send mailbox size updates automatically 699 if a mailbox size change is observed during the processing of a 700 command. A server SHOULD send message flag updates automatically, 701 without requiring the client to request such updates explicitly. 702 Special rules exist for server notification of a client about the 703 removal of messages to prevent synchronization errors; see the 704 description of the EXPUNGE response for more details. 706 Regardless of what implementation decisions a client makes on 707 remembering data from the server, a client implementation MUST record 708 mailbox size updates. It MUST NOT assume that any command after 709 initial mailbox selection will return the size of the mailbox. 711 5.3. Response when no Command in Progress 713 Server implementations are permitted to send an untagged response 714 (except for EXPUNGE) while there is no command in progress. Server 715 implementations that send such responses MUST deal with flow control 716 considerations. Specifically, they MUST either (1) verify that the 717 size of the data does not exceed the underlying transport's available 718 window size, or (2) use non-blocking writes. 720 5.4. Autologout Timer 722 If a server has an inactivity autologout timer, that timer MUST be of 723 at least 30 minutes' duration. The receipt of ANY command from the 724 client during that interval SHOULD suffice to reset the autologout 725 timer. 727 5.5. Multiple Commands in Progress 729 The client MAY send another command without waiting for the 730 completion result response of a command, subject to ambiguity rules 731 (see below) and flow control constraints on the underlying data 732 stream. Similarly, a server MAY begin processing another command 733 before processing the current command to completion, subject to 734 ambiguity rules. However, any command continuation request responses 735 and command continuations MUST be negotiated before any subsequent 736 command is initiated. 738 The exception is if an ambiguity would result because of a command 739 that would affect the results of other commands. Clients MUST NOT 740 send multiple commands without waiting if an ambiguity would result. 741 If the server detects a possible ambiguity, it MUST execute commands 742 to completion in the order given by the client. 744 The most obvious example of ambiguity is when a command would affect 745 the results of another command; for example, a FETCH of a message's 746 flags and a STORE of that same message's flags. 748 A non-obvious ambiguity occurs with commands that permit an untagged 749 EXPUNGE response (commands other than FETCH, STORE, and SEARCH), 750 since an untagged EXPUNGE response can invalidate sequence numbers in 751 a subsequent command. This is not a problem for FETCH, STORE, or 752 SEARCH commands because servers are prohibited from sending EXPUNGE 753 responses while any of those commands are in progress. Therefore, if 754 the client sends any command other than FETCH, STORE, or SEARCH, it 755 MUST wait for a response before sending a command with message 756 sequence numbers. 758 For example, the following non-waiting command sequences are invalid: 760 FETCH + NOOP + STORE 761 STORE + COPY + FETCH 762 COPY + COPY 763 CHECK + FETCH 765 The following are examples of valid non-waiting command sequences: 767 FETCH + STORE + SEARCH + CHECK 768 STORE + COPY + EXPUNGE 770 6. Client Commands 772 IMAP4rev1 commands are described in this section. Commands are 773 organized by the state in which the command is permitted. Commands 774 which are permitted in multiple states are listed in the minimum 775 permitted state (for example, commands valid in authenticated and 776 selected state are listed in the authenticated state commands). 778 Command arguments, identified by "Arguments:" in the command 779 descriptions below, are described by function, not by syntax. The 780 precise syntax of command arguments is described in the Formal Syntax 781 section. 783 Some commands cause specific server responses to be returned; these 784 are identified by "Responses:" in the command descriptions below. 785 See the response descriptions in the Responses section for 786 information on these responses, and the Formal Syntax section for the 787 precise syntax of these responses. It is possible for server data to 788 be transmitted as a result of any command; thus, commands that do not 789 specifically require server data specify "no specific responses for 790 this command" instead of "none". 792 The "Result:" in the command description refers to the possible 793 tagged status responses to a command, and any special interpretation 794 of these status responses. 796 6.1. Client Commands - Any State 798 The following commands are valid in any state: CAPABILITY, NOOP, and 799 LOGOUT. 801 6.1.1. CAPABILITY Command 803 Arguments: none 805 Responses: REQUIRED untagged response: CAPABILITY 807 Result: OK - capability completed 808 BAD - command unknown or arguments invalid 810 The CAPABILITY command requests a listing of capabilities that the 811 server supports. The server MUST send a single untagged 812 CAPABILITY response with "IMAP4rev1" as one of the listed 813 capabilities before the (tagged) OK response. This listing of 814 capabilities is not dependent upon connection state or user. It 815 is therefore not necessary to issue a CAPABILITY command more than 816 once in a session. 818 A capability name which begins with "AUTH=" indicates that the 819 server supports that particular authentication mechanism. All 820 such names are, by definition, part of this specification. For 821 example, the authorization capability for an experimental 822 "blurdybloop" authenticator would be "AUTH=XBLURDYBLOOP" and not 823 "XAUTH=BLURDYBLOOP" or "XAUTH=XBLURDYBLOOP". 825 Other capability names refer to extensions, revisions, or 826 amendments to this specification. See the documentation of the 827 CAPABILITY response for additional information. No capabilities, 828 beyond the base IMAP4rev1 set defined in this specification, are 829 enabled without explicit client action to invoke the capability. 831 See the section entitled "Client Commands - 832 Experimental/Expansion" for information about the form of site or 833 implementation-specific capabilities. 835 Example: C: abcd CAPABILITY 836 S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 837 S: abcd OK CAPABILITY completed 839 6.1.2. NOOP Command 841 Arguments: none 843 Responses: no specific responses for this command (but see below) 845 Result: OK - noop completed 846 BAD - command unknown or arguments invalid 848 The NOOP command always succeeds. It does nothing. 850 Since any command can return a status update as untagged data, the 851 NOOP command can be used as a periodic poll for new messages or 852 message status updates during a period of inactivity. The NOOP 853 command can also be used to reset any inactivity autologout timer 854 on the server. 856 Example: C: a002 NOOP 857 S: a002 OK NOOP completed 858 . . . 859 C: a047 NOOP 860 S: * 22 EXPUNGE 861 S: * 23 EXISTS 862 S: * 3 RECENT 863 S: * 14 FETCH (FLAGS (\Seen \Deleted)) 864 S: a047 OK NOOP completed 866 6.1.3. LOGOUT Command 868 Arguments: none 870 Responses: REQUIRED untagged response: BYE 872 Result: OK - logout completed 873 BAD - command unknown or arguments invalid 875 The LOGOUT command informs the server that the client is done with 876 the session. The server MUST send a BYE untagged response before 877 the (tagged) OK response, and then close the network connection. 879 Example: C: A023 LOGOUT 880 S: * BYE IMAP4rev1 Server logging out 881 S: A023 OK LOGOUT completed 882 (Server and client then close the connection) 884 6.2. Client Commands - Non-Authenticated State 886 In non-authenticated state, the AUTHENTICATE or LOGIN command 887 establishes authentication and enter authenticated state. The 888 AUTHENTICATE command provides a general mechanism for a variety of 889 authentication techniques, whereas the LOGIN command uses the 890 traditional user name and plaintext password pair. 892 Server implementations MAY allow non-authenticated access to certain 893 mailboxes. The convention is to use a LOGIN command with the userid 894 "anonymous". A password is REQUIRED. It is implementation-dependent 895 what requirements, if any, are placed on the password and what access 896 restrictions are placed on anonymous users. 898 Once authenticated (including as anonymous), it is not possible to 899 re-enter non-authenticated state. 901 In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), 902 the following commands are valid in non-authenticated state: 903 AUTHENTICATE and LOGIN. 905 6.2.1. AUTHENTICATE Command 907 Arguments: authentication mechanism name 909 Responses: continuation data can be requested 911 Result: OK - authenticate completed, now in authenticated state 912 NO - authenticate failure: unsupported authentication 913 mechanism, credentials rejected 914 BAD - command unknown or arguments invalid, 915 authentication exchange cancelled 917 The AUTHENTICATE command indicates an authentication mechanism, 918 such as described in [IMAP-AUTH], to the server. If the server 919 supports the requested authentication mechanism, it performs an 920 authentication protocol exchange to authenticate and identify the 921 client. It MAY also negotiate an OPTIONAL protection mechanism 922 for subsequent protocol interactions. If the requested 923 authentication mechanism is not supported, the server SHOULD 924 reject the AUTHENTICATE command by sending a tagged NO response. 926 The authentication protocol exchange consists of a series of 927 server challenges and client answers that are specific to the 928 authentication mechanism. A server challenge consists of a 929 command continuation request response with the "+" token followed 930 by a BASE64 encoded string. The client answer consists of a line 931 consisting of a BASE64 encoded string. If the client wishes to 932 cancel an authentication exchange, it issues a line with a single 933 "*". If the server receives such an answer, it MUST reject the 934 AUTHENTICATE command by sending a tagged BAD response. 936 A protection mechanism provides integrity and privacy protection 937 to the protocol session. If a protection mechanism is negotiated, 938 it is applied to all subsequent data sent over the connection. 939 The protection mechanism takes effect immediately following the 940 CRLF that concludes the authentication exchange for the client, 941 and the CRLF of the tagged OK response for the server. Once the 942 protection mechanism is in effect, the stream of command and 943 response octets is processed into buffers of ciphertext. Each 944 buffer is transferred over the connection as a stream of octets 945 prepended with a four octet field in network byte order that 946 represents the length of the following data. The maximum 947 ciphertext buffer length is defined by the protection mechanism. 949 Authentication mechanisms are OPTIONAL. Protection mechanisms are 950 also OPTIONAL; an authentication mechanism MAY be implemented 951 without any protection mechanism. If an AUTHENTICATE command 952 fails with a NO response, the client MAY try another 953 authentication mechanism by issuing another AUTHENTICATE command, 954 or MAY attempt to authenticate by using the LOGIN command. In 955 other words, the client MAY request authentication types in 956 decreasing order of preference, with the LOGIN command as a last 957 resort. 959 Example: S: * OK KerberosV4 IMAP4rev1 Server 960 C: A001 AUTHENTICATE KERBEROS_V4 961 S: + AmFYig== 962 C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT 963 +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd 964 WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh 965 S: + or//EoAADZI= 966 C: DiAF5A4gA+oOIALuBkAAmw== 967 S: A001 OK Kerberos V4 authentication successful 969 Note: the line breaks in the first client answer are for 970 editorial clarity and are not in real authenticators. 972 6.2.2. LOGIN Command 974 Arguments: user name 975 password 977 Responses: no specific responses for this command 979 Result: OK - login completed, now in authenticated state 980 NO - login failure: user name or password rejected 981 BAD - command unknown or arguments invalid 983 The LOGIN command identifies the client to the server and carries 984 the plaintext password authenticating this user. 986 Example: C: a001 LOGIN SMITH SESAME 987 S: a001 OK LOGIN completed 989 6.3. Client Commands - Authenticated State 991 In authenticated state, commands that manipulate mailboxes as atomic 992 entities are permitted. Of these commands, the SELECT and EXAMINE 993 commands will select a mailbox for access and enter selected state. 995 In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), 996 the following commands are valid in authenticated state: SELECT, 997 EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, 998 STATUS, and APPEND. 1000 6.3.1. SELECT Command 1002 Arguments: mailbox name 1004 Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT 1005 OPTIONAL OK untagged responses: UNSEEN, PERMANENTFLAGS 1007 Result: OK - select completed, now in selected state 1008 NO - select failure, now in authenticated state: no 1009 such mailbox, can't access mailbox 1010 BAD - command unknown or arguments invalid 1012 The SELECT command selects a mailbox so that messages in the 1013 mailbox can be accessed. Before returning an OK to the client, 1014 the server MUST send the following untagged data to the client: 1016 FLAGS Defined flags in the mailbox. See the description 1017 of the FLAGS response for more details. 1019 EXISTS The number of messages in the mailbox. See the 1020 description of the EXISTS response for more 1021 details. 1023 RECENT The number of messages added to the mailbox since 1024 the previous time this mailbox was selected. See 1025 the description of the RECENT response for more 1026 details. 1028 OK [UIDVALIDITY ] 1029 The unique identifier validity value. See the 1030 description of the UID command for more details. 1032 to define the initial state of the mailbox at the client. If it 1033 is not possible to determine the messages that were added since 1034 the previous time a mailbox was selected, then all messages SHOULD 1035 be considered recent. 1037 The server SHOULD also send an UNSEEN response code in an OK 1038 untagged response, indicating the message sequence number of the 1039 first unseen message in the mailbox. 1041 If the client can not change the permanent state of one or more of 1042 the flags listed in the FLAGS untagged response, the server SHOULD 1043 send a PERMANENTFLAGS response code in an OK untagged response, 1044 listing the flags that the client can change permanently. 1046 Only one mailbox can be selected at a time in a session; 1047 simultaneous access to multiple mailboxes requires multiple 1048 sessions. The SELECT command automatically deselects any 1049 currently selected mailbox before attempting the new selection. 1050 Consequently, if a mailbox is selected and a SELECT command that 1051 fails is attempted, no mailbox is selected. 1053 If the client is permitted to modify the mailbox, the server 1054 SHOULD prefix the text of the tagged OK response with the 1055 "[READ-WRITE]" response code. 1057 If the client is not permitted to modify the mailbox but is 1058 permitted read access, the mailbox is selected as read-only, and 1059 the server MUST prefix the text of the tagged OK response to 1060 SELECT with the "[READ-ONLY]" response code. Read-only access 1061 through SELECT differs from the EXAMINE command in that certain 1062 read-only mailboxes MAY permit the change of permanent state on a 1063 per-user (as opposed to global) basis. Netnews messages marked in 1064 a server-based .newsrc file are an example of such per-user 1065 permanent state that can be modified with read-only mailboxes. 1067 Example: C: A142 SELECT INBOX 1068 S: * 172 EXISTS 1069 S: * 1 RECENT 1070 S: * OK [UNSEEN 12] Message 12 is first unseen 1071 S: * OK [UIDVALIDITY 3857529045] UIDs valid 1072 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 1073 S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited 1074 S: A142 OK [READ-WRITE] SELECT completed 1076 6.3.2. EXAMINE Command 1078 Arguments: mailbox name 1080 Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT 1081 OPTIONAL OK untagged responses: UNSEEN, PERMANENTFLAGS 1083 Result: OK - examine completed, now in selected state 1084 NO - examine failure, now in authenticated state: no 1085 such mailbox, can't access mailbox 1086 BAD - command unknown or arguments invalid 1088 The EXAMINE command is identical to SELECT and returns the same 1089 output; however, the selected mailbox is identified as read-only. 1090 No changes to the permanent state of the mailbox, including 1091 per-user state, are permitted. 1093 The text of the tagged OK response to the EXAMINE command MUST 1094 begin with the "[READ-ONLY]" response code. 1096 Example: C: A932 EXAMINE blurdybloop 1097 S: * 17 EXISTS 1098 S: * 2 RECENT 1099 S: * OK [UNSEEN 8] Message 8 is first unseen 1100 S: * OK [UIDVALIDITY 3857529045] UIDs valid 1101 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 1102 S: * OK [PERMANENTFLAGS ()] No permanent flags permitted 1103 S: A932 OK [READ-ONLY] EXAMINE completed 1105 6.3.3. CREATE Command 1107 Arguments: mailbox name 1109 Responses: no specific responses for this command 1111 Result: OK - create completed 1112 NO - create failure: can't create mailbox with that name 1113 BAD - command unknown or arguments invalid 1115 The CREATE command creates a mailbox with the given name. An OK 1116 response is returned only if a new mailbox with that name has been 1117 created. It is an error to attempt to create INBOX or a mailbox 1118 with a name that refers to an extant mailbox. Any error in 1119 creation will return a tagged NO response. 1121 If the mailbox name is suffixed with the server's hierarchy 1122 separator character (as returned from the server by a LIST 1123 command), this is a declaration that the client intends to create 1124 mailbox names under this name in the hierarchy. Server 1125 implementations that do not require this declaration MUST ignore 1126 it. 1128 If the server's hierarchy separator character appears elsewhere in 1129 the name, the server SHOULD create any superior hierarchical names 1130 that are needed for the CREATE command to complete successfully. 1131 In other words, an attempt to create "foo/bar/zap" on a server in 1132 which "/" is the hierarchy separator character SHOULD create foo/ 1133 and foo/bar/ if they do not already exist. 1135 If a new mailbox is created with the same name as a mailbox which 1136 was deleted, its unique identifiers MUST be greater than any 1137 unique identifiers used in the previous incarnation of the mailbox 1138 UNLESS the new incarnation has a different unique identifier 1139 validity value. See the description of the UID command for more 1140 detail. 1142 Example: C: A003 CREATE owatagusiam/ 1143 S: A003 OK CREATE completed 1144 C: A004 CREATE owatagusiam/blurdybloop 1145 S: A004 OK CREATE completed 1147 Note: the interpretation of this example depends on whether 1148 "/" was returned as the hierarchy separator from LIST. If 1149 "/" is the hierarchy separator, a new level of hierarchy 1150 named "owatagusiam" with a member called "blurdybloop" is 1151 created. Otherwise, two mailboxes at the same hierarchy 1152 level are created. 1154 6.3.4. DELETE Command 1156 Arguments: mailbox name 1158 Responses: no specific responses for this command 1160 Result: OK - delete completed 1161 NO - delete failure: can't delete mailbox with that name 1162 BAD - command unknown or arguments invalid 1164 The DELETE command permanently removes the mailbox with the given 1165 name. A tagged OK response is returned only if the mailbox has 1166 been deleted. It is an error to attempt to delete INBOX or a 1167 mailbox name that does not exist. 1169 The DELETE command MUST NOT remove inferior hierarchical names. 1170 For example, if a mailbox "foo" has an inferior "foo.bar" 1171 (assuming "." is the hierarchy delimiter character), removing 1172 "foo" MUST NOT remove "foo.bar". It is an error to attempt to 1173 delete a name that has inferior hierarchical names and also has 1174 the \Noselect mailbox name attribute (see the description of the 1175 LIST response for more details). 1177 It is permitted to delete a name that has inferior hierarchical 1178 names and does not have the \Noselect mailbox name attribute. In 1179 this case, all messages in that mailbox are removed, and the name 1180 will acquire the \Noselect mailbox name attribute. 1182 The value of the highest-used unique identifier of the deleted 1183 mailbox MUST be preserved so that a new mailbox created with the 1184 same name will not reuse the identifiers of the former 1185 incarnation, UNLESS the new incarnation has a different unique 1186 identifier validity value. See the description of the UID command 1187 for more detail. 1189 Examples: C: A682 LIST "" * 1190 S: * LIST () "/" blurdybloop 1191 S: * LIST (\Noselect) "/" foo 1192 S: * LIST () "/" foo/bar 1193 S: A682 OK LIST completed 1194 C: A683 DELETE blurdybloop 1195 S: A683 OK DELETE completed 1196 C: A684 DELETE foo 1197 S: A684 NO Name "foo" has inferior hierarchical names 1198 C: A685 DELETE foo/bar 1199 S: A685 OK DELETE Completed 1200 C: A686 LIST "" * 1201 S: * LIST (\Noselect) "/" foo 1202 S: A686 OK LIST completed 1203 C: A687 DELETE foo 1204 S: A687 OK DELETE Completed 1206 C: A82 LIST "" * 1207 S: * LIST () "." foo 1208 S: * LIST () "." foo.bar 1209 S: A82 OK LIST completed 1210 C: A83 DELETE blurdybloop 1211 S: A83 OK DELETE completed 1212 C: A84 DELETE foo 1213 S: A84 OK DELETE Completed 1214 C: A85 LIST "" * 1215 S: * LIST () "." foo.bar 1216 S: A85 OK LIST completed 1217 C: A86 LIST "" % 1218 S: * LIST (\Noselect) "." foo 1219 S: A86 OK LIST completed 1221 6.3.5. RENAME Command 1223 Arguments: existing mailbox name 1224 new mailbox name 1226 Responses: no specific responses for this command 1228 Result: OK - rename completed 1229 NO - rename failure: can't rename mailbox with that name, 1230 can't rename to mailbox with that name 1231 BAD - command unknown or arguments invalid 1233 The RENAME command changes the name of a mailbox. A tagged OK 1234 response is returned only if the mailbox has been renamed. It is 1235 an error to attempt to rename from a mailbox name that does not 1236 exist or to a mailbox name that already exists. Any error in 1237 renaming will return a tagged NO response. 1239 If the name has inferior hierarchical names, then the inferior 1240 hierarchical names MUST also be renamed. For example, a rename of 1241 "foo" to "zap" will rename "foo/bar" (assuming "/" is the 1242 hierarchy delimiter character) to "zap/bar". 1244 The value of the highest-used unique identifier of the old mailbox 1245 name MUST be preserved so that a new mailbox created with the same 1246 name will not reuse the identifiers of the former incarnation, 1247 UNLESS the new incarnation has a different unique identifier 1248 validity value. See the description of the UID command for more 1249 detail. 1251 Renaming INBOX is permitted, and has special behavior. It moves 1252 all messages in INBOX to a new mailbox with the given name, 1253 leaving INBOX empty. If the server implementation supports 1254 inferior hierarchical names of INBOX, these are unaffected by a 1255 rename of INBOX. 1257 Examples: C: A682 LIST "" * 1258 S: * LIST () "/" blurdybloop 1259 S: * LIST (\Noselect) "/" foo 1260 S: * LIST () "/" foo/bar 1261 S: A682 OK LIST completed 1262 C: A683 RENAME blurdybloop sarasoop 1263 S: A683 OK RENAME completed 1264 C: A684 RENAME foo zowie 1265 S: A684 OK RENAME Completed 1266 C: A685 LIST "" * 1267 S: * LIST () "/" sarasoop 1268 S: * LIST (\Noselect) "/" zowie 1269 S: * LIST () "/" zowie/bar 1270 S: A685 OK LIST completed 1272 C: Z432 LIST "" * 1273 S: * LIST () "." INBOX 1274 S: * LIST () "." INBOX.bar 1275 S: Z432 OK LIST completed 1276 C: Z433 RENAME INBOX old-mail 1277 S: Z433 OK RENAME completed 1278 C: Z434 LIST "" * 1279 S: * LIST () "." INBOX 1280 S: * LIST () "." INBOX.bar 1281 S: * LIST () "." old-mail 1282 S: Z434 OK LIST completed 1284 6.3.6. SUBSCRIBE Command 1286 Arguments: mailbox 1288 Responses: no specific responses for this command 1290 Result: OK - subscribe completed 1291 NO - subscribe failure: can't subscribe to that name 1292 BAD - command unknown or arguments invalid 1294 The SUBSCRIBE command adds the specified mailbox name to the 1295 server's set of "active" or "subscribed" mailboxes as returned by 1296 the LSUB command. This command returns a tagged OK response only 1297 if the subscription is successful. 1299 A server MAY validate the mailbox argument to SUBSCRIBE to verify 1300 that it exists. However, it MUST NOT unilaterally remove an 1301 existing mailbox name from the subscription list even if a mailbox 1302 by that name no longer exists. 1304 Note: this requirement is because some server sites may 1305 routinely remove a mailbox with a well-known name (e.g. 1306 "system-alerts") after its contents expire, with the 1307 intention of recreating it when new contents are 1308 appropriate. 1310 Example: C: A002 SUBSCRIBE #news.comp.mail.mime 1311 S: A002 OK SUBSCRIBE completed 1313 6.3.7. UNSUBSCRIBE Command 1315 Arguments: mailbox name 1317 Responses: no specific responses for this command 1319 Result: OK - unsubscribe completed 1320 NO - unsubscribe failure: can't unsubscribe that name 1321 BAD - command unknown or arguments invalid 1323 The UNSUBSCRIBE command removes the specified mailbox name from 1324 the server's set of "active" or "subscribed" mailboxes as returned 1325 by the LSUB command. This command returns a tagged OK response 1326 only if the unsubscription is successful. 1328 Example: C: A002 UNSUBSCRIBE #news.comp.mail.mime 1329 S: A002 OK UNSUBSCRIBE completed 1331 6.3.8. LIST Command 1333 Arguments: reference name 1334 mailbox name with possible wildcards 1336 Responses: untagged responses: LIST 1338 Result: OK - list completed 1339 NO - list failure: can't list that reference or name 1340 BAD - command unknown or arguments invalid 1342 The LIST command returns a subset of names from the complete set 1343 of all names available to the client. Zero or more untagged LIST 1344 replies are returned, containing the name attributes, hierarchy 1345 delimiter, and name; see the description of the LIST reply for 1346 more detail. 1348 The LIST command SHOULD return its data quickly, without undue 1349 delay. For example, it SHOULD NOT go to excess trouble to 1350 calculate \Marked or \Unmarked status or perform other processing; 1351 if each name requires 1 second of processing, then a list of 1200 1352 names would take 20 minutes! 1354 An empty ("" string) reference name argument indicates that the 1355 mailbox name is interpreted as by SELECT. The returned mailbox 1356 names MUST match the supplied mailbox name pattern. A non-empty 1357 reference name argument is the name of a mailbox or a level of 1358 mailbox hierarchy, and indicates a context in which the mailbox 1359 name is interpreted in an implementation-defined manner. 1361 An empty ("" string) mailbox name argument is a special request to 1362 return the hierarchy delimiter and the root name of the name given 1363 in the reference. The value returned as the root MAY be null if 1364 the reference is non-rooted or is null. In all cases, the 1365 hierarchy delimiter is returned. This permits a client to get the 1366 hierarchy delimiter even when no mailboxes by that name currently 1367 exist. 1369 The reference and mailbox name arguments are interpreted, in an 1370 implementation-dependent fashion, into a canonical form that 1371 represents an unambiguous left-to-right hierarchy. The returned 1372 mailbox names will be in the interpreted form. 1374 Any part of the reference argument that is included in the 1375 interpreted form SHOULD prefix the interpreted form. It SHOULD 1376 also be in the same form as the reference name argument. This 1377 rule permits the client to determine if the returned mailbox name 1378 is in the context of the reference argument, or if something about 1379 the mailbox argument overrode the reference argument. Without 1380 this rule, the client would have to have knowledge of the server's 1381 naming semantics including what characters are "breakouts" that 1382 override a naming context. 1384 For example, here are some examples of how references 1385 and mailbox names might be interpreted on a UNIX-based 1386 server: 1388 Reference Mailbox Name Interpretation 1389 ------------ ------------ -------------- 1390 ~smith/Mail/ foo.* ~smith/Mail/foo.* 1391 archive/ % archive/% 1392 #news. comp.mail.* #news.comp.mail.* 1393 ~smith/Mail/ /usr/doc/foo /usr/doc/foo 1394 archive/ ~fred/Mail/* ~fred/Mail/* 1396 The first three examples demonstrate interpretations in 1397 the context of the reference argument. Note that 1398 "~smith/Mail" SHOULD NOT be transformed into something 1399 like "/u2/users/smith/Mail", or it would be impossible 1400 for the client to determine that the interpretation was 1401 in the context of the reference. 1403 The character "*" is a wildcard, and matches zero or more 1404 characters at this position. The character "%" is similar to "*", 1405 but it does not match a hierarchy delimiter. If the "%" wildcard 1406 is the last character of a mailbox name argument, matching levels 1407 of hierarchy are also returned. If these levels of hierarchy are 1408 not also selectable mailboxes, they are returned with the 1409 \Noselect mailbox name attribute (see the description of the LIST 1410 response for more details). 1412 Server implementations are permitted to "hide" otherwise 1413 accessible mailboxes from the wildcard characters, by preventing 1414 certain characters or names from matching a wildcard in certain 1415 situations. For example, a UNIX-based server might restrict the 1416 interpretation of "*" so that an initial "/" character does not 1417 match. 1419 The special name INBOX is included in the output from LIST, if 1420 INBOX is supported by this server for this user and if the 1421 uppercase string "INBOX" matches the interpreted reference and 1422 mailbox name arguments with wildcards as described above. The 1423 criteria for omitting INBOX is whether SELECT INBOX will return 1424 failure; it is not relevant whether the user's real INBOX resides 1425 on this or some other server. 1427 Example: C: A101 LIST "" "" 1428 S: * LIST (\Noselect) "/" "" 1429 S: A101 OK LIST Completed 1430 C: A102 LIST #news.comp.mail.misc "" 1431 S: * LIST (\Noselect) "." #news. 1432 S: A102 OK LIST Completed 1433 C: A103 LIST /usr/staff/jones "" 1434 S: * LIST (\Noselect) "/" / 1435 S: A103 OK LIST Completed 1436 C: A202 LIST ~/Mail/ % 1437 S: * LIST (\Noselect) "/" ~/Mail/foo 1438 S: * LIST () "/" ~/Mail/meetings 1439 S: A202 OK LIST completed 1441 6.3.9. LSUB Command 1443 Arguments: reference name 1444 mailbox name with possible wildcards 1446 Responses: untagged responses: LSUB 1448 Result: OK - lsub completed 1449 NO - lsub failure: can't list that reference or name 1450 BAD - command unknown or arguments invalid 1452 The LSUB command returns a subset of names from the set of names 1453 that the user has declared as being "active" or "subscribed". 1454 Zero or more untagged LSUB replies are returned. The arguments to 1455 LSUB are in the same form as those for LIST. 1457 A server MAY validate the subscribed names to see if they still 1458 exist. If a name does not exist, it SHOULD be flagged with the 1459 \Noselect attribute in the LSUB response. The server MUST NOT 1460 unilaterally remove an existing mailbox name from the subscription 1461 list even if a mailbox by that name no longer exists. 1463 Example: C: A002 LSUB "#news." "comp.mail.*" 1464 S: * LSUB () "." #news.comp.mail.mime 1465 S: * LSUB () "." #news.comp.mail.misc 1466 S: A002 OK LSUB completed 1468 6.3.10. STATUS Command 1470 Arguments: mailbox name 1471 status data item names 1473 Responses: untagged responses: STATUS 1475 Result: OK - status completed 1476 NO - status failure: no status for that name 1477 BAD - command unknown or arguments invalid 1479 The STATUS command requests the status of the indicated mailbox. 1480 It does not change the currently selected mailbox, nor does it 1481 affect the state of any messages in the queried mailbox (in 1482 particular, STATUS MUST NOT cause messages to lose the \Recent 1483 flag). 1485 The STATUS command provides an alternative to opening a second 1486 IMAP4rev1 connection and doing an EXAMINE command on a mailbox to 1487 query that mailbox's status without deselecting the current 1488 mailbox in the first IMAP4rev1 connection. 1490 Unlike the LIST command, the STATUS command is not guaranteed to 1491 be fast in its response. In some implementations, the server is 1492 obliged to open the mailbox read-only internally to obtain certain 1493 status information. Also unlike the LIST command, the STATUS 1494 command does not accept wildcards. 1496 The currently defined status data items that can be requested are: 1498 MESSAGES The number of messages in the mailbox. 1500 RECENT The number of messages with the \Recent flag set. 1502 UIDNEXT The next UID value that will be assigned to a new 1503 message in the mailbox. It is guaranteed that this 1504 value will not change unless new messages are added 1505 to the mailbox; and that it will change when new 1506 messages are added even if those new messages are 1507 subsequently expunged. 1509 UIDVALIDITY The unique identifier validity value of the 1510 mailbox. 1512 UNSEEN The number of messages which do not have the \Seen 1513 flag set. 1515 Example: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES) 1516 S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292) 1517 S: A042 OK STATUS completed 1519 6.3.11. APPEND Command 1521 Arguments: mailbox name 1522 OPTIONAL flag parenthesized list 1523 OPTIONAL date/time string 1524 message literal 1526 Responses: no specific responses for this command 1528 Result: OK - append completed 1529 NO - append error: can't append to that mailbox, error 1530 in flags or date/time or message text 1531 BAD - command unknown or arguments invalid 1533 The APPEND command appends the literal argument as a new message 1534 to the end of the specified destination mailbox. This argument 1535 SHOULD be in the format of an [RFC-822] message. 8-bit characters 1536 are permitted in the message. A server implementation that is 1537 unable to preserve 8-bit data properly MUST be able to reversibly 1538 convert 8-bit APPEND data to 7-bit using a [MIME-IMB] content 1539 transfer encoding. 1541 Note: There MAY be exceptions, e.g. draft messages, in 1542 which required [RFC-822] headers are omitted in the 1543 message literal argument to APPEND. The full 1544 implications of doing so MUST be understood and 1545 carefully weighed. 1547 If a flag parenthesized list is specified, the flags SHOULD be set 1548 in the resulting message; otherwise, the flag list of the 1549 resulting message is set empty by default. 1551 If a date_time is specified, the internal date SHOULD be set in 1552 the resulting message; otherwise, the internal date of the 1553 resulting message is set to the current date and time by default. 1555 If the append is unsuccessful for any reason, the mailbox MUST be 1556 restored to its state before the APPEND attempt; no partial 1557 appending is permitted. 1559 If the destination mailbox does not exist, a server MUST return an 1560 error, and MUST NOT automatically create the mailbox. Unless it 1561 is certain that the destination mailbox can not be created, the 1562 server MUST send the response code "[TRYCREATE]" as the prefix of 1563 the text of the tagged NO response. This gives a hint to the 1564 client that it can attempt a CREATE command and retry the APPEND 1565 if the CREATE is successful. 1567 If the mailbox is currently selected, the normal new mail actions 1568 SHOULD occur. Specifically, the server SHOULD notify the client 1569 immediately via an untagged EXISTS response. If the server does 1570 not do so, the client MAY issue a NOOP command (or failing that, a 1571 CHECK command) after one or more APPEND commands. 1573 Example: C: A003 APPEND saved-messages (\Seen) {310} 1574 C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) 1575 C: From: Fred Foobar 1576 C: Subject: afternoon meeting 1577 C: To: mooch@owatagu.siam.edu 1578 C: Message-Id: 1579 C: MIME-Version: 1.0 1580 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 1581 C: 1583 C: Hello Joe, do you think we can meet at 3:30 tomorrow? 1584 C: 1585 S: A003 OK APPEND completed 1587 Note: the APPEND command is not used for message delivery, 1588 because it does not provide a mechanism to transfer [SMTP] 1589 envelope information. 1591 6.4. Client Commands - Selected State 1593 In selected state, commands that manipulate messages in a mailbox are 1594 permitted. 1596 In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), 1597 and the authenticated state commands (SELECT, EXAMINE, CREATE, 1598 DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS, and 1599 APPEND), the following commands are valid in the selected state: 1600 CHECK, CLOSE, EXPUNGE, SEARCH, FETCH, STORE, COPY, and UID. 1602 6.4.1. CHECK Command 1604 Arguments: none 1606 Responses: no specific responses for this command 1608 Result: OK - check completed 1609 BAD - command unknown or arguments invalid 1611 The CHECK command requests a checkpoint of the currently selected 1612 mailbox. A checkpoint refers to any implementation-dependent 1613 housekeeping associated with the mailbox (e.g. resolving the 1614 server's in-memory state of the mailbox with the state on its 1615 disk) that is not normally executed as part of each command. A 1616 checkpoint MAY take a non-instantaneous amount of real time to 1617 complete. If a server implementation has no such housekeeping 1618 considerations, CHECK is equivalent to NOOP. 1620 There is no guarantee that an EXISTS untagged response will happen 1621 as a result of CHECK. NOOP, not CHECK, SHOULD be used for new 1622 mail polling. 1624 Example: C: FXXZ CHECK 1625 S: FXXZ OK CHECK Completed 1627 6.4.2. CLOSE Command 1629 Arguments: none 1631 Responses: no specific responses for this command 1633 Result: OK - close completed, now in authenticated state 1634 NO - close failure: no mailbox selected 1635 BAD - command unknown or arguments invalid 1637 The CLOSE command permanently removes from the currently selected 1638 mailbox all messages that have the \Deleted flag set, and returns 1639 to authenticated state from selected state. No untagged EXPUNGE 1640 responses are sent. 1642 No messages are removed, and no error is given, if the mailbox is 1643 selected by an EXAMINE command or is otherwise selected read-only. 1645 Even if a mailbox is selected, a SELECT, EXAMINE, or LOGOUT 1646 command MAY be issued without previously issuing a CLOSE command. 1647 The SELECT, EXAMINE, and LOGOUT commands implicitly close the 1648 currently selected mailbox without doing an expunge. However, 1649 when many messages are deleted, a CLOSE-LOGOUT or CLOSE-SELECT 1650 sequence is considerably faster than an EXPUNGE-LOGOUT or 1651 EXPUNGE-SELECT because no untagged EXPUNGE responses (which the 1652 client would probably ignore) are sent. 1654 Example: C: A341 CLOSE 1655 S: A341 OK CLOSE completed 1657 6.4.3. EXPUNGE Command 1659 Arguments: none 1661 Responses: untagged responses: EXPUNGE 1663 Result: OK - expunge completed 1664 NO - expunge failure: can't expunge (e.g. permission 1665 denied) 1666 BAD - command unknown or arguments invalid 1668 The EXPUNGE command permanently removes from the currently 1669 selected mailbox all messages that have the \Deleted flag set. 1670 Before returning an OK to the client, an untagged EXPUNGE response 1671 is sent for each message that is removed. 1673 Example: C: A202 EXPUNGE 1674 S: * 3 EXPUNGE 1675 S: * 3 EXPUNGE 1676 S: * 5 EXPUNGE 1677 S: * 8 EXPUNGE 1678 S: A202 OK EXPUNGE completed 1680 Note: in this example, messages 3, 4, 7, and 11 had the 1681 \Deleted flag set. See the description of the EXPUNGE 1682 response for further explanation. 1684 6.4.4. SEARCH Command 1686 Arguments: OPTIONAL character set specification 1687 searching criteria (one or more) 1689 Responses: REQUIRED untagged response: SEARCH 1691 Result: OK - search completed 1692 NO - search error: can't search that character set or 1693 criteria 1694 BAD - command unknown or arguments invalid 1696 The SEARCH command searches the mailbox for messages that match 1697 the given searching criteria. Searching criteria consist of one 1698 or more search keys. The untagged SEARCH response from the server 1699 contains a listing of message sequence numbers corresponding to 1700 those messages that match the searching criteria. 1702 When multiple keys are specified, the result is the intersection 1703 (AND function) of all the messages that match those keys. For 1704 example, the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers 1705 to all deleted messages from Smith that were placed in the mailbox 1706 since February 1, 1994. A search key can also be a parenthesized 1707 list of one or more search keys (e.g. for use with the OR and NOT 1708 keys). 1710 Server implementations MAY exclude [MIME-IMB] body parts with 1711 terminal content media types other than TEXT and MESSAGE from 1712 consideration in SEARCH matching. 1714 The OPTIONAL character set specification consists of the word 1715 "CHARSET" followed by a registered MIME character set. It 1716 indicates the character set of the strings that appear in the 1717 search criteria. [MIME-HDRS] strings that appear in RFC 822/MIME 1718 message headers, and [MIME-IMB] content transfer encodings, MUST 1719 be decoded before matching. US-ASCII MUST be supported; other 1720 character sets MAY be supported. If the server does not support 1721 the specified character set, it MUST return a tagged NO response 1722 (not a BAD). 1724 In all search keys that use strings, a message matches the key if 1725 the string is a substring of the field. The matching is 1726 case-insensitive. 1728 The defined search keys are as follows. Refer to the Formal 1729 Syntax section for the precise syntactic definitions of the 1730 arguments. 1732 Messages with message sequence numbers 1733 corresponding to the specified message sequence 1734 number set 1736 ALL All messages in the mailbox; the default initial 1737 key for ANDing. 1739 ANSWERED Messages with the \Answered flag set. 1741 BCC Messages that contain the specified string in the 1742 envelope structure's BCC field. 1744 BEFORE Messages whose internal date is earlier than the 1745 specified date. 1747 BODY Messages that contain the specified string in the 1748 body of the message. 1750 CC Messages that contain the specified string in the 1751 envelope structure's CC field. 1753 DELETED Messages with the \Deleted flag set. 1755 DRAFT Messages with the \Draft flag set. 1757 FLAGGED Messages with the \Flagged flag set. 1759 FROM Messages that contain the specified string in the 1760 envelope structure's FROM field. 1762 HEADER 1763 Messages that have a header with the specified 1764 field-name (as defined in [RFC-822]) and that 1765 contains the specified string in the [RFC-822] 1766 field-body. 1768 KEYWORD Messages with the specified keyword set. 1770 LARGER Messages with an [RFC-822] size larger than the 1771 specified number of octets. 1773 NEW Messages that have the \Recent flag set but not the 1774 \Seen flag. This is functionally equivalent to 1775 "(RECENT UNSEEN)". 1777 NOT 1778 Messages that do not match the specified search 1779 key. 1781 OLD Messages that do not have the \Recent flag set. 1782 This is functionally equivalent to "NOT RECENT" (as 1783 opposed to "NOT NEW"). 1785 ON Messages whose internal date is within the 1786 specified date. 1788 OR 1789 Messages that match either search key. 1791 RECENT Messages that have the \Recent flag set. 1793 SEEN Messages that have the \Seen flag set. 1795 SENTBEFORE 1796 Messages whose [RFC-822] Date: header is earlier 1797 than the specified date. 1799 SENTON Messages whose [RFC-822] Date: header is within the 1800 specified date. 1802 SENTSINCE 1803 Messages whose [RFC-822] Date: header is within or 1804 later than the specified date. 1806 SINCE Messages whose internal date is within or later 1807 than the specified date. 1809 SMALLER Messages with an [RFC-822] size smaller than the 1810 specified number of octets. 1812 SUBJECT 1813 Messages that contain the specified string in the 1814 envelope structure's SUBJECT field. 1816 TEXT Messages that contain the specified string in the 1817 header or body of the message. 1819 TO Messages that contain the specified string in the 1820 envelope structure's TO field. 1822 UID 1823 Messages with unique identifiers corresponding to 1824 the specified unique identifier set. 1826 UNANSWERED Messages that do not have the \Answered flag set. 1828 UNDELETED Messages that do not have the \Deleted flag set. 1830 UNDRAFT Messages that do not have the \Draft flag set. 1832 UNFLAGGED Messages that do not have the \Flagged flag set. 1834 UNKEYWORD 1835 Messages that do not have the specified keyword 1836 set. 1838 UNSEEN Messages that do not have the \Seen flag set. 1840 Example: C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith" 1841 S: * SEARCH 2 84 882 1842 S: A282 OK SEARCH completed 1844 6.4.5. FETCH Command 1846 Arguments: message set 1847 message data item names 1849 Responses: untagged responses: FETCH 1851 Result: OK - fetch completed 1852 NO - fetch error: can't fetch that data 1853 BAD - command unknown or arguments invalid 1855 The FETCH command retrieves data associated with a message in the 1856 mailbox. The data items to be fetched can be either a single atom 1857 or a parenthesized list. 1859 The currently defined data items that can be fetched are: 1861 ALL Macro equivalent to: (FLAGS INTERNALDATE 1862 RFC822.SIZE ENVELOPE) 1864 BODY Non-extensible form of BODYSTRUCTURE. 1866 BODY[
]<> 1867 The text of a particular body section. The section 1868 specification is a set of zero or more part 1869 specifiers delimited by periods. A part specifier 1870 is either a part number or one of the following: 1871 HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME, and 1872 TEXT. An empty section specification refers to the 1873 entire message, including the header. 1875 Every message has at least one part number. 1876 Non-MIME messages, and non-multipart MIME messages 1877 with no encapsulated message, only have a part 1. 1879 Multipart messages are assigned consecutive part 1880 numbers, as they occur in the message. If a 1881 particular part is of type message or multipart, 1882 its parts MUST be indicated by a period followed by 1883 the part number within that nested multipart part. 1885 A part of type MESSAGE/RFC822 also has nested part 1886 numbers, referring to parts of the MESSAGE part's 1887 body. 1889 The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, and 1890 TEXT part specifiers can be the sole part specifier 1891 or can be prefixed by one or more numeric part 1892 specifiers, provided that the numeric part 1893 specifier refers to a part of type MESSAGE/RFC822. 1894 The MIME part specifier MUST be prefixed by one or 1895 more numeric part specifiers. 1897 The HEADER, HEADER.FIELDS, and HEADER.FIELDS.NOT 1898 part specifiers refer to the [RFC-822] header of 1899 the message or of an encapsulated MIME message. 1900 HEADER.FIELDS and HEADER.FIELDS.NOT are followed by 1901 a list of field-name (as defined in [RFC-822]) 1902 names, and return a subset of the header. The 1903 subset returned by HEADER.FIELDS contains only 1904 those header fields with a field-name that matches 1905 one of the names in the list; similarly, the subset 1906 returned by HEADER.FIELDS.NOT contains only the 1907 header fields with a non-matching field-name. The 1908 field-matching is case-insensitive but otherwise 1909 exact. In all cases, the delimiting blank line 1910 between the header and the body is always included. 1912 The MIME part specifier refers to the [MIME-IMB] 1913 header for this part. 1915 The TEXT part specifier refers to the text body of 1916 the message, omitting the [RFC-822] header. 1918 Here is an example of a complex message 1919 with some of its part specifiers: 1921 HEADER ([RFC-822] header of the message) 1922 TEXT MULTIPART/MIXED 1923 1 TEXT/PLAIN 1924 2 APPLICATION/OCTET-STREAM 1925 3 MESSAGE/RFC822 1926 3.HEADER ([RFC-822] header of the message) 1927 3.TEXT ([RFC-822] text body of the message) 1928 3.1 TEXT/PLAIN 1929 3.2 APPLICATION/OCTET-STREAM 1930 4 MULTIPART/MIXED 1931 4.1 IMAGE/GIF 1932 4.1.MIME ([MIME-IMB] headers for the IMAGE/GIF) 1933 4.2 MESSAGE/RFC822 1934 4.2.HEADER ([RFC-822] header of the message) 1935 4.2.TEXT ([RFC-822] text body of the message) 1936 4.2.1 TEXT/PLAIN 1937 4.2.2 MULTIPART/ALTERNATIVE 1938 4.2.2.1 TEXT/PLAIN 1939 4.2.2.2 TEXT/RICHTEXT 1941 It is possible to fetch a substring of the 1942 designated text. This is done by appending an open 1943 angle bracket ("<"), the octet position of the 1944 first desired octet, a period, the maximum number 1945 of octets desired, and a close angle bracket (">") 1946 to the part specifier. If the starting octet is 1947 beyond the end of the text, an empty string is 1948 returned. 1950 Any partial fetch that attempts to read beyond the 1951 end of the text is truncated as appropriate. A 1952 partial fetch that starts at octet 0 is returned as 1953 a partial fetch, even if this truncation happened. 1955 Note: this means that BODY[]<0.2048> of a 1956 1500-octet message will return BODY[]<0> 1957 with a literal of size 1500, not BODY[]. 1959 Note: a substring fetch of a 1960 HEADER.FIELDS or HEADER.FIELDS.NOT part 1961 specifier is calculated after subsetting 1962 the header. 1964 The \Seen flag is implicitly set; if this causes 1965 the flags to change they SHOULD be included as part 1966 of the FETCH responses. 1968 BODY.PEEK[
]<> 1969 An alternate form of BODY[
] that does not 1970 implicitly set the \Seen flag. 1972 BODYSTRUCTURE The [MIME-IMB] body structure of the message. This 1973 is computed by the server by parsing the [MIME-IMB] 1974 header fields. 1976 ENVELOPE The envelope structure of the message. This is 1977 computed by the server by parsing the [RFC-822] 1978 header into the component parts, defaulting various 1979 fields as necessary. 1981 FAST Macro equivalent to: (FLAGS INTERNALDATE 1982 RFC822.SIZE) 1984 FLAGS The flags that are set for this message. 1986 FULL Macro equivalent to: (FLAGS INTERNALDATE 1987 RFC822.SIZE ENVELOPE BODY) 1989 INTERNALDATE The internal date of the message. 1991 RFC822 Functionally equivalent to BODY[], differing in the 1992 syntax of the resulting untagged FETCH data (RFC822 1993 is returned). 1995 RFC822.HEADER Functionally equivalent to BODY.PEEK[HEADER], 1996 differing in the syntax of the resulting untagged 1997 FETCH data (RFC822.HEADER is returned). 1999 RFC822.SIZE The [RFC-822] size of the message. 2001 RFC822.TEXT Functionally equivalent to BODY[TEXT], differing in 2002 the syntax of the resulting untagged FETCH data 2003 (RFC822.TEXT is returned). 2005 UID The unique identifier for the message. 2007 Example: C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)]) 2008 S: * 2 FETCH .... 2009 S: * 3 FETCH .... 2010 S: * 4 FETCH .... 2011 S: A654 OK FETCH completed 2013 6.4.6. STORE Command 2015 Arguments: message set 2016 message data item name 2017 value for message data item 2019 Responses: untagged responses: FETCH 2021 Result: OK - store completed 2022 NO - store error: can't store that data 2023 BAD - command unknown or arguments invalid 2025 The STORE command alters data associated with a message in the 2026 mailbox. Normally, STORE will return the updated value of the 2027 data with an untagged FETCH response. A suffix of ".SILENT" in 2028 the data item name prevents the untagged FETCH, and the server 2029 SHOULD assume that the client has determined the updated value 2030 itself or does not care about the updated value. 2032 Note: regardless of whether or not the ".SILENT" suffix 2033 was used, the server SHOULD send an untagged FETCH 2034 response if a change to a message's flags from an 2035 external source is observed. The intent is that the 2036 status of the flags is determinate without a race 2037 condition. 2039 The currently defined data items that can be stored are: 2041 FLAGS 2042 Replace the flags for the message with the 2043 argument. The new value of the flags are returned 2044 as if a FETCH of those flags was done. 2046 FLAGS.SILENT 2047 Equivalent to FLAGS, but without returning a new 2048 value. 2050 +FLAGS 2051 Add the argument to the flags for the message. The 2052 new value of the flags are returned as if a FETCH 2053 of those flags was done. 2055 +FLAGS.SILENT 2056 Equivalent to +FLAGS, but without returning a new 2057 value. 2059 -FLAGS 2060 Remove the argument from the flags for the message. 2061 The new value of the flags are returned as if a 2062 FETCH of those flags was done. 2064 -FLAGS.SILENT 2065 Equivalent to -FLAGS, but without returning a new 2066 value. 2068 Example: C: A003 STORE 2:4 +FLAGS (\Deleted) 2069 S: * 2 FETCH FLAGS (\Deleted \Seen) 2070 S: * 3 FETCH FLAGS (\Deleted) 2071 S: * 4 FETCH FLAGS (\Deleted \Flagged \Seen) 2072 S: A003 OK STORE completed 2074 6.4.7. COPY Command 2076 Arguments: message set 2077 mailbox name 2079 Responses: no specific responses for this command 2081 Result: OK - copy completed 2082 NO - copy error: can't copy those messages or to that 2083 name 2084 BAD - command unknown or arguments invalid 2086 The COPY command copies the specified message(s) to the end of the 2087 specified destination mailbox. The flags and internal date of the 2088 message(s) SHOULD be preserved in the copy. 2090 If the destination mailbox does not exist, a server SHOULD return 2091 an error. It SHOULD NOT automatically create the mailbox. Unless 2092 it is certain that the destination mailbox can not be created, the 2093 server MUST send the response code "[TRYCREATE]" as the prefix of 2094 the text of the tagged NO response. This gives a hint to the 2095 client that it can attempt a CREATE command and retry the COPY if 2096 the CREATE is successful. 2098 If the COPY command is unsuccessful for any reason, server 2099 implementations MUST restore the destination mailbox to its state 2100 before the COPY attempt. 2102 Example: C: A003 COPY 2:4 MEETING 2103 S: A003 OK COPY completed 2105 6.4.8. UID Command 2107 Arguments: command name 2108 command arguments 2110 Responses: untagged responses: FETCH, SEARCH 2112 Result: OK - UID command completed 2113 NO - UID command error 2114 BAD - command unknown or arguments invalid 2116 The UID command has two forms. In the first form, it takes as its 2117 arguments a COPY, FETCH, or STORE command with arguments 2118 appropriate for the associated command. However, the numbers in 2119 the message set argument are unique identifiers instead of message 2120 sequence numbers. 2122 In the second form, the UID command takes a SEARCH command with 2123 SEARCH command arguments. The interpretation of the arguments is 2124 the same as with SEARCH; however, the numbers returned in a SEARCH 2125 response for a UID SEARCH command are unique identifiers instead 2126 of message sequence numbers. For example, the command UID SEARCH 2127 1:100 UID 443:557 returns the unique identifiers corresponding to 2128 the intersection of the message sequence number set 1:100 and the 2129 UID set 443:557. 2131 Message set ranges are permitted; however, there is no guarantee 2132 that unique identifiers be contiguous. A non-existent unique 2133 identifier within a message set range is ignored without any error 2134 message generated. 2136 The number after the "*" in an untagged FETCH response is always a 2137 message sequence number, not a unique identifier, even for a UID 2138 command response. However, server implementations MUST implicitly 2139 include the UID message data item as part of any FETCH response 2140 caused by a UID command, regardless of whether a UID was specified 2141 as a message data item to the FETCH. 2143 Example: C: A999 UID FETCH 4827313:4828442 FLAGS 2144 S: * 23 FETCH (FLAGS (\Seen) UID 4827313) 2145 S: * 24 FETCH (FLAGS (\Seen) UID 4827943) 2146 S: * 25 FETCH (FLAGS (\Seen) UID 4828442) 2147 S: A999 UID FETCH completed 2149 6.5. Client Commands - Experimental/Expansion 2151 6.5.1. X Command 2153 Arguments: implementation defined 2155 Responses: implementation defined 2157 Result: OK - command completed 2158 NO - failure 2159 BAD - command unknown or arguments invalid 2161 Any command prefixed with an X is an experimental command. 2162 Commands which are not part of this specification, a standard or 2163 standards-track revision of this specification, or an 2164 IESG-approved experimental protocol, MUST use the X prefix. 2166 Any added untagged responses issued by an experimental command 2167 MUST also be prefixed with an X. Server implementations MUST NOT 2168 send any such untagged responses, unless the client requested it 2169 by issuing the associated experimental command. 2171 Example: C: a441 CAPABILITY 2172 S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 XPIG-LATIN 2173 S: a441 OK CAPABILITY completed 2174 C: A442 XPIG-LATIN 2175 S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay 2176 S: A442 OK XPIG-LATIN ompleted-cay 2178 7. Server Responses 2180 Server responses are in three forms: status responses, server data, 2181 and command continuation request. The information contained in a 2182 server response, identified by "Contents:" in the response 2183 descriptions below, is described by function, not by syntax. The 2184 precise syntax of server responses is described in the Formal Syntax 2185 section. 2187 The client MUST be prepared to accept any response at all times. 2189 Status responses can be tagged or untagged. Tagged status responses 2190 indicate the completion result (OK, NO, or BAD status) of a client 2191 command, and have a tag matching the command. 2193 Some status responses, and all server data, are untagged. An 2194 untagged response is indicated by the token "*" instead of a tag. 2195 Untagged status responses indicate server greeting, or server status 2196 that does not indicate the completion of a command (for example, an 2197 impending system shutdown alert). For historical reasons, untagged 2198 server data responses are also called "unsolicited data", although 2199 strictly speaking only unilateral server data is truly "unsolicited". 2201 Certain server data MUST be recorded by the client when it is 2202 received; this is noted in the description of that data. Such data 2203 conveys critical information which affects the interpretation of all 2204 subsequent commands and responses (e.g. updates reflecting the 2205 creation or destruction of messages). 2207 Other server data SHOULD be recorded for later reference; if the 2208 client does not need to record the data, or if recording the data has 2209 no obvious purpose (e.g. a SEARCH response when no SEARCH command is 2210 in progress), the data SHOULD be ignored. 2212 An example of unilateral untagged server data occurs when the IMAP 2213 connection is in selected state. In selected state, the server 2214 checks the mailbox for new messages as part of command execution. 2215 Normally, this is part of the execution of every command; hence, a 2216 NOOP command suffices to check for new messages. If new messages are 2217 found, the server sends untagged EXISTS and RECENT responses 2218 reflecting the new size of the mailbox. Server implementations that 2219 offer multiple simultaneous access to the same mailbox SHOULD also 2220 send appropriate unilateral untagged FETCH and EXPUNGE responses if 2221 another agent changes the state of any message flags or expunges any 2222 messages. 2224 Command continuation request responses use the token "+" instead of a 2225 tag. These responses are sent by the server to indicate acceptance 2226 of an incomplete client command and readiness for the remainder of 2227 the command. 2229 7.1. Server Responses - Status Responses 2231 Status responses are OK, NO, BAD, PREAUTH and BYE. OK, NO, and BAD 2232 may be tagged or untagged. PREAUTH and BYE are always untagged. 2234 Status responses MAY include an OPTIONAL "response code". A response 2235 code consists of data inside square brackets in the form of an atom, 2236 possibly followed by a space and arguments. The response code 2237 contains additional information or status codes for client software 2238 beyond the OK/NO/BAD condition, and are defined when there is a 2239 specific action that a client can take based upon the additional 2240 information. 2242 The currently defined response codes are: 2244 ALERT The human-readable text contains a special alert 2245 that MUST be presented to the user in a fashion 2246 that calls the user's attention to the message. 2248 NEWNAME Followed by a mailbox name and a new mailbox name. 2249 A SELECT or EXAMINE is failing because the target 2250 mailbox name no longer exists because it was 2251 renamed to the new mailbox name. This is a hint to 2252 the client that the operation can succeed if the 2253 SELECT or EXAMINE is reissued with the new mailbox 2254 name. 2256 PARSE The human-readable text represents an error in 2257 parsing the [RFC-822] or [MIME-IMB] headers of a 2258 message in the mailbox. 2260 PERMANENTFLAGS Followed by a parenthesized list of flags, 2261 indicates which of the known flags that the client 2262 can change permanently. Any flags that are in the 2263 FLAGS untagged response, but not the PERMANENTFLAGS 2264 list, can not be set permanently. If the client 2265 attempts to STORE a flag that is not in the 2266 PERMANENTFLAGS list, the server will either reject 2267 it with a NO reply or store the state for the 2268 remainder of the current session only. The 2269 PERMANENTFLAGS list can also include the special 2270 flag \*, which indicates that it is possible to 2271 create new keywords by attempting to store those 2272 flags in the mailbox. 2274 READ-ONLY The mailbox is selected read-only, or its access 2275 while selected has changed from read-write to 2276 read-only. 2278 READ-WRITE The mailbox is selected read-write, or its access 2279 while selected has changed from read-only to 2280 read-write. 2282 TRYCREATE An APPEND or COPY attempt is failing because the 2283 target mailbox does not exist (as opposed to some 2284 other reason). This is a hint to the client that 2285 the operation can succeed if the mailbox is first 2286 created by the CREATE command. 2288 UIDVALIDITY Followed by a decimal number, indicates the unique 2289 identifier validity value. See the description of 2290 the UID command for more detail. 2292 UNSEEN Followed by a decimal number, indicates the number 2293 of the first message without the \Seen flag set. 2295 Additional response codes defined by particular client or server 2296 implementations SHOULD be prefixed with an "X" until they are 2297 added to a revision of this protocol. Client implementations 2298 SHOULD ignore response codes that they do not recognize. 2300 7.1.1. OK Response 2302 Contents: OPTIONAL response code 2303 human-readable text 2305 The OK response indicates an information message from the server. 2306 When tagged, it indicates successful completion of the associated 2307 command. The human-readable text MAY be presented to the user as 2308 an information message. The untagged form indicates an 2309 information-only message; the nature of the information MAY be 2310 indicated by a response code. 2312 The untagged form is also used as one of three possible greetings 2313 at session startup. It indicates that the session is not yet 2314 authenticated and that a LOGIN command is needed. 2316 Example: S: * OK IMAP4rev1 server ready 2317 C: A001 LOGIN fred blurdybloop 2318 S: * OK [ALERT] System shutdown in 10 minutes 2319 S: A001 OK LOGIN Completed 2321 7.1.2. NO Response 2323 Contents: OPTIONAL response code 2324 human-readable text 2326 The NO response indicates an operational error message from the 2327 server. When tagged, it indicates unsuccessful completion of the 2328 associated command. The untagged form indicates a warning; the 2329 command can still complete successfully. The human-readable text 2330 describes the condition. 2332 Example: C: A222 COPY 1:2 owatagusiam 2333 S: * NO Disk is 98% full, please delete unnecessary data 2334 S: A222 OK COPY completed 2335 C: A223 COPY 3:200 blurdybloop 2336 S: * NO Disk is 98% full, please delete unnecessary data 2337 S: * NO Disk is 99% full, please delete unnecessary data 2338 S: A223 NO COPY failed: disk is full 2340 7.1.3. BAD Response 2342 Contents: OPTIONAL response code 2343 human-readable text 2345 The BAD response indicates an error message from the server. When 2346 tagged, it reports a protocol-level error in the client's command; 2347 the tag indicates the command that caused the error. The untagged 2348 form indicates a protocol-level error for which the associated 2349 command can not be determined; it can also indicate an internal 2350 server failure. The human-readable text describes the condition. 2352 Example: C: ...very long command line... 2353 S: * BAD Command line too long 2354 C: ...empty line... 2355 S: * BAD Empty command line 2356 C: A443 EXPUNGE 2357 S: * BAD Disk crash, attempting salvage to a new disk! 2358 S: * OK Salvage successful, no data lost 2359 S: A443 OK Expunge completed 2361 7.1.4. PREAUTH Response 2363 Contents: OPTIONAL response code 2364 human-readable text 2366 The PREAUTH response is always untagged, and is one of three 2367 possible greetings at session startup. It indicates that the 2368 session has already been authenticated by external means and thus 2369 no LOGIN command is needed. 2371 Example: S: * PREAUTH IMAP4rev1 server logged in as Smith 2373 7.1.5. BYE Response 2375 Contents: OPTIONAL response code 2376 human-readable text 2378 The BYE response is always untagged, and indicates that the server 2379 is about to close the connection. The human-readable text MAY be 2380 displayed to the user in a status report by the client. The BYE 2381 response is sent under one of four conditions: 2383 1) as part of a normal logout sequence. The server will close 2384 the connection after sending the tagged OK response to the 2385 LOGOUT command. 2387 2) as a panic shutdown announcement. The server closes the 2388 connection immediately. 2390 3) as an announcement of an inactivity autologout. The server 2391 closes the connection immediately. 2393 4) as one of three possible greetings at session startup, 2394 indicating that the server is not willing to accept a 2395 session from this client. The server closes the connection 2396 immediately. 2398 The difference between a BYE that occurs as part of a normal 2399 LOGOUT sequence (the first case) and a BYE that occurs because of 2400 a failure (the other three cases) is that the connection closes 2401 immediately in the failure case. 2403 Example: S: * BYE Autologout; idle for too long 2405 7.2. Server Responses - Server and Mailbox Status 2407 These responses are always untagged. This is how server and mailbox 2408 status data are transmitted from the server to the client. Many of 2409 these responses typically result from a command with the same name. 2411 7.2.1. CAPABILITY Response 2413 Contents: capability listing 2415 The CAPABILITY response occurs as a result of a CAPABILITY 2416 command. The capability listing contains a space-separated 2417 listing of capability names that the server supports. The 2418 capability listing MUST include the atom "IMAP4rev1". 2420 A capability name which begins with "AUTH=" indicates that the 2421 server supports that particular authentication mechanism. 2423 Other capability names indicate that the server supports an 2424 extension, revision, or amendment to the IMAP4rev1 protocol. 2425 Server responses MUST conform to this document until the client 2426 issues a command that uses the associated capability. 2428 Capability names MUST either begin with "X" or be standard or 2429 standards-track IMAP4rev1 extensions, revisions, or amendments 2430 registered with IANA. A server MUST NOT offer unregistered or 2431 non-standard capability names, unless such names are prefixed with 2432 an "X". 2434 Client implementations SHOULD NOT require any capability name 2435 other than "IMAP4rev1", and MUST ignore any unknown capability 2436 names. 2438 Example: S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 XPIG-LATIN 2440 7.2.2. LIST Response 2442 Contents: name attributes 2443 hierarchy delimiter 2444 name 2446 The LIST response occurs as a result of a LIST command. It 2447 returns a single name that matches the LIST specification. There 2448 can be multiple LIST responses for a single LIST command. 2450 Four name attributes are defined: 2452 \Noinferiors It is not possible for any child levels of 2453 hierarchy to exist under this name; no child levels 2454 exist now and none can be created in the future. 2456 \Noselect It is not possible to use this name as a selectable 2457 mailbox. 2459 \Marked The mailbox has been marked "interesting" by the 2460 server; the mailbox probably contains messages that 2461 have been added since the last time the mailbox was 2462 selected. 2464 \Unmarked The mailbox does not contain any additional 2465 messages since the last time the mailbox was 2466 selected. 2468 If it is not feasible for the server to determine whether the 2469 mailbox is "interesting" or not, or if the name is a \Noselect 2470 name, the server SHOULD NOT send either \Marked or \Unmarked. 2472 The hierarchy delimiter is a character used to delimit levels of 2473 hierarchy in a mailbox name. A client can use it to create child 2474 mailboxes, and to search higher or lower levels of naming 2475 hierarchy. All children of a top-level hierarchy node MUST use 2476 the same separator character. A NIL hierarchy delimiter means 2477 that no hierarchy exists; the name is a "flat" name. 2479 The name represents an unambiguous left-to-right hierarchy, and 2480 MUST be valid for use as a reference in LIST and LSUB commands. 2481 Unless \Noselect is indicated, the name MUST also be valid as an 2482 argument for commands, such as SELECT, that accept mailbox names. 2484 Example: S: * LIST (\Noselect) "/" ~/Mail/foo 2486 7.2.3. LSUB Response 2488 Contents: name attributes 2489 hierarchy delimiter 2490 name 2492 The LSUB response occurs as a result of an LSUB command. It 2493 returns a single name that matches the LSUB specification. There 2494 can be multiple LSUB responses for a single LSUB command. The 2495 data is identical in format to the LIST response. 2497 Example: S: * LSUB () "." #news.comp.mail.misc 2499 7.2.4 STATUS Response 2501 Contents: name 2502 status parenthesized list 2504 The STATUS response occurs as a result of an STATUS command. It 2505 returns the mailbox name that matches the STATUS specification and 2506 the requested mailbox status information. 2508 Example: S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292) 2510 7.2.5. SEARCH Response 2512 Contents: zero or more numbers 2514 The SEARCH response occurs as a result of a SEARCH or UID SEARCH 2515 command. The number(s) refer to those messages that match the 2516 search criteria. For SEARCH, these are message sequence numbers; 2517 for UID SEARCH, these are unique identifiers. Each number is 2518 delimited by a space. 2520 Example: S: * SEARCH 2 3 6 2522 7.2.6. FLAGS Response 2524 Contents: flag parenthesized list 2526 The FLAGS response occurs as a result of a SELECT or EXAMINE 2527 command. The flag parenthesized list identifies the flags (at a 2528 minimum, the system-defined flags) that are applicable for this 2529 mailbox. Flags other than the system flags can also exist, 2530 depending on server implementation. 2532 The update from the FLAGS response MUST be recorded by the client. 2534 Example: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 2536 7.3. Server Responses - Mailbox Size 2538 These responses are always untagged. This is how changes in the size 2539 of the mailbox are trasnmitted from the server to the client. 2540 Immediately following the "*" token is a number that represents a 2541 message count. 2543 7.3.1. EXISTS Response 2545 Contents: none 2547 The EXISTS response reports the number of messages in the mailbox. 2548 This response occurs as a result of a SELECT or EXAMINE command, 2549 and if the size of the mailbox changes (e.g. new mail). 2551 The update from the EXISTS response MUST be recorded by the 2552 client. 2554 Example: S: * 23 EXISTS 2556 7.3.2. RECENT Response 2558 Contents: none 2560 The RECENT response reports the number of messages that have 2561 arrived since the previous time a SELECT command was done on this 2562 mailbox. This response occurs as a result of a SELECT or EXAMINE 2563 command, and if the size of the mailbox changes (e.g. new mail). 2565 Note: It is not guaranteed that the message sequence 2566 numbers of recent messages will be a contiguous range of 2567 the highest n messages in the mailbox (where n is the 2568 value reported by the RECENT response). Examples of 2569 situations in which this is not the case are: multiple 2570 clients having the same mailbox open (only the first 2571 client to discover a new message will mark it recent), 2572 and when the mailbox is re-ordered by a non-IMAP agent. 2574 The only reliable way to identify recent messages is to 2575 look at message flags, or to do a SEARCH RECENT. See 2576 the description of the SEARCH command for more details. 2578 The update from the RECENT response MUST be recorded by the 2579 client. 2581 Example: S: * 5 RECENT 2583 7.4. Server Responses - Message Status 2585 These responses are always untagged. This is how message data are 2586 transmitted from the server to the client, often as a result of a 2587 command with the same name. Immediately following the "*" token is a 2588 number that represents a message sequence number. 2590 7.4.1. EXPUNGE Response 2592 Contents: none 2594 The EXPUNGE response reports that the specified message sequence 2595 number has been permanently removed from the mailbox. The message 2596 sequence number for each successive message in the mailbox is 2597 immediately decremented by 1, and this decrement is reflected in 2598 message sequence numbers in subsequent responses (including other 2599 untagged EXPUNGE responses). 2601 As a result of the immediate decrement rule, message sequence 2602 numbers that appear in a set of successive EXPUNGE responses 2603 depend upon whether the messages are removed starting from lower 2604 numbers to higher numbers, or from higher numbers to lower 2605 numbers. For example, if the last 5 messages in a 9-message 2606 mailbox are expunged; a "lower to higher" server will send five 2607 untagged EXPUNGE responses for message sequence number 5, whereas 2608 a "higher to lower server" will send successive untagged EXPUNGE 2609 responses for message sequence numbers 9, 8, 7, 6, and 5. 2611 An EXPUNGE response MUST NOT be sent when no command is in 2612 progress; nor while responding to a FETCH, STORE, or SEARCH 2613 command. This rule is necessary to prevent a loss of 2614 synchronization of message sequence numbers between client and 2615 server. 2617 The update from the EXPUNGE response MUST be recorded by the 2618 client. 2620 Example: S: * 44 EXPUNGE 2622 7.4.2. FETCH Response 2624 Contents: message data 2626 The FETCH response returns data about a message to the client. 2627 The data are pairs of data item names and their values in 2628 parentheses. This response occurs as the result of a FETCH or 2629 STORE command, as well as by unilateral server decision (e.g. flag 2630 updates). 2632 The current data items are: 2634 BODY A form of BODYSTRUCTURE without extension data. 2636 BODY[
]<> 2637 A string expressing the body contents of the 2638 specified section. The string SHOULD be 2639 interpreted by the client according to the content 2640 transfer encoding, body type, and subtype. 2642 If the origin octet is specified, this string is a 2643 substring of the entire body contents, starting at 2644 that origin octet. This means that BODY[]<0> MAY 2645 be truncated, but BODY[] is NEVER truncated. 2647 8-bit textual data is permitted if a [MIME-IMB] 2648 character set identifier is part of the body 2649 parameter parenthesized list for this section. 2650 Note that message headers (part specifiers HEADER 2651 or MIME, or the header part of a MESSAGE/RFC822 2652 part), MUST be 7-bit; 8-bit characters are not 2653 permitted in headers. Note also that the blank 2654 line at the end of the header is always included in 2655 header data. 2657 Non-textual data such as binary data MUST be 2658 transfer encoded into a textual form such as BASE64 2659 prior to being sent to the client. To derive the 2660 original binary data, the client MUST decode the 2661 transfer encoded string. 2663 BODYSTRUCTURE A parenthesized list that describes the body 2664 structure of a message. This is computed by the 2665 server by parsing the [RFC-822] header and body 2666 into the component parts, defaulting various fields 2667 as necessary. 2669 Multiple parts are indicated by parenthesis 2670 nesting. Instead of a body type as the first 2671 element of the parenthesized list there is a nested 2672 body. The second element of the parenthesized list 2673 is the multipart subtype (mixed, digest, parallel, 2674 alternative, etc.). 2676 Extension data follows the multipart subtype. 2677 Extension data is never returned with the BODY 2678 fetch, but can be returned with a BODYSTRUCTURE 2679 fetch. Extension data, if present, MUST be in the 2680 defined order. 2682 The extension data of a multipart body part are in 2683 the following order: 2685 body parameter parenthesized list 2686 A parenthesized list of attribute/value pairs 2687 [e.g. ("foo" "bar" "baz" "rag") where "bar" is 2688 the value of "foo" and "rag" is the value of 2689 "baz"] as defined in [MIME-IMB]. 2691 body disposition 2692 A parenthesized list, consisting of a 2693 disposition type string followed by a 2694 parenthesized list of disposition 2695 attribute/value pairs. The disposition type and 2696 attribute names will be defined in a future 2697 standards-track revision to [DISPOSITION]. 2699 body language 2700 A string or parenthesized list giving the body 2701 language value as defined in [LANGUAGE-TAGS]. 2703 Any following extension data are not yet defined in 2704 this version of the protocol. Such extension data 2705 can consist of zero or more NILs, strings, numbers, 2706 or potentially nested parenthesized lists of such 2707 data. Client implementations that do a 2708 BODYSTRUCTURE fetch MUST be prepared to accept such 2709 extension data. Server implementations MUST NOT 2710 send such extension data until it has been defined 2711 by a revision of this protocol. 2713 The basic fields of a non-multipart body part are 2714 in the following order: 2716 body type 2717 A string giving the content media type name as 2718 defined in [MIME-IMB]. 2720 body subtype 2721 A string giving the content subtype name as 2722 defined in [MIME-IMB]. 2724 body parameter parenthesized list 2725 A parenthesized list of attribute/value pairs 2726 [e.g. ("foo" "bar" "baz" "rag") where "bar" is 2727 the value of "foo" and "rag" is the value of 2728 "baz"] as defined in [MIME-IMB]. 2730 body id 2731 A string giving the content id as defined in 2732 [MIME-IMB]. 2734 body description 2735 A string giving the content description as 2736 defined in [MIME-IMB]. 2738 body encoding 2739 A string giving the content transfer encoding as 2740 defined in [MIME-IMB]. 2742 body size 2743 A number giving the size of the body in octets. 2744 Note that this size is the size in its transfer 2745 encoding and not the resulting size after any 2746 decoding. 2748 A body type of type MESSAGE and subtype RFC822 2749 contains, immediately after the basic fields, the 2750 envelope structure, body structure, and size in 2751 text lines of the encapsulated message. 2753 A body type of type TEXT contains, immediately 2754 after the basic fields, the size of the body in 2755 text lines. Note that this size is the size in its 2756 content transfer encoding and not the resulting 2757 size after any decoding. 2759 Extension data follows the basic fields and the 2760 type-specific fields listed above. Extension data 2761 is never returned with the BODY fetch, but can be 2762 returned with a BODYSTRUCTURE fetch. Extension 2763 data, if present, MUST be in the defined order. 2765 The extension data of a non-multipart body part are 2766 in the following order: 2768 body MD5 2769 A string giving the body MD5 value as defined in 2770 [MD5]. 2772 body disposition 2773 A parenthesized list with the same content and 2774 function as the body disposition for a multipart 2775 body part. 2777 body language 2778 A string or parenthesized list giving the body 2779 language value as defined in [LANGUAGE-TAGS]. 2781 Any following extension data are not yet defined in 2782 this version of the protocol, and would be as 2783 described above under multipart extension data. 2785 ENVELOPE A parenthesized list that describes the envelope 2786 structure of a message. This is computed by the 2787 server by parsing the [RFC-822] header into the 2788 component parts, defaulting various fields as 2789 necessary. 2791 The fields of the envelope structure are in the 2792 following order: date, subject, from, sender, 2793 reply-to, to, cc, bcc, in-reply-to, and message-id. 2794 The date, subject, in-reply-to, and message-id 2795 fields are strings. The from, sender, reply-to, 2796 to, cc, and bcc fields are parenthesized lists of 2797 address structures. 2799 An address structure is a parenthesized list that 2800 describes an electronic mail address. The fields 2801 of an address structure are in the following order: 2802 personal name, [SMTP] at-domain-list (source 2803 route), mailbox name, and host name. 2805 [RFC-822] group syntax is indicated by a special 2806 form of address structure in which the host name 2807 field is NIL. If the mailbox name field is also 2808 NIL, this is an end of group marker (semi-colon in 2809 RFC 822 syntax). If the mailbox name field is 2810 non-NIL, this is a start of group marker, and the 2811 mailbox name field holds the group name phrase. 2813 Any field of an envelope or address structure that 2814 is not applicable is presented as NIL. Note that 2815 the server MUST default the reply-to and sender 2816 fields from the from field; a client is not 2817 expected to know to do this. 2819 FLAGS A parenthesized list of flags that are set for this 2820 message. This can include keywords as well as the 2821 following system flags: 2823 \Seen Message has been read 2825 \Answered Message has been answered 2827 \Flagged Message is "flagged" for urgent/special 2828 attention 2830 \Deleted Message is "deleted" for removal by 2831 later EXPUNGE 2833 \Draft Message has not completed composition 2834 (marked as a draft). 2836 as well as the following special flag, which can be 2837 fetched but not stored: 2839 \Recent Message has arrived since the previous 2840 time this mailbox was selected. 2842 INTERNALDATE A string representing the internal date of the 2843 message. 2845 RFC822 Equivalent to BODY[]. 2847 RFC822.HEADER Equivalent to BODY.PEEK[HEADER]. 2849 RFC822.SIZE A number expressing the [RFC-822] size of the 2850 message. 2852 RFC822.TEXT Equivalent to BODY[TEXT]. 2854 UID A number expressing the unique identifier of the 2855 message. 2857 Example: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827) 2859 7.5. Server Responses - Command Continuation Request 2861 The command continuation request response is indicated by a "+" token 2862 instead of a tag. This form of response indicates that the server is 2863 ready to accept the continuation of a command from the client. The 2864 remainder of this response is a line of text. 2866 This response is used in the AUTHORIZATION command to transmit server 2867 data to the client, and request additional client data. This 2868 response is also used if an argument to any command is a literal. 2870 The client is not permitted to send the octets of the literal unless 2871 the server indicates that it expects it. This permits the server to 2872 process commands and reject errors on a line-by-line basis. The 2873 remainder of the command, including the CRLF that terminates a 2874 command, follows the octets of the literal. If there are any 2875 additional command arguments the literal octets are followed by a 2876 space and those arguments. 2878 Example: C: A001 LOGIN {11} 2879 S: + Ready for additional command text 2880 C: FRED FOOBAR {7} 2881 S: + Ready for additional command text 2882 C: fat man 2883 S: A001 OK LOGIN completed 2884 C: A044 BLURDYBLOOP {102856} 2885 S: A044 BAD No such command as "BLURDYBLOOP" 2887 8. Sample IMAP4rev1 session 2889 The following is a transcript of an IMAP4rev1 session. A long line 2890 in this sample is broken for editorial clarity. 2892 S: * OK IMAP4rev1 Service Ready 2893 C: a001 login mrc secret 2894 S: a001 OK LOGIN completed 2895 C: a002 select inbox 2896 S: * 18 EXISTS 2897 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 2898 S: * 2 RECENT 2899 S: * OK [UNSEEN 17] Message 17 is the first unseen message 2900 S: * OK [UIDVALIDITY 3857529045] UIDs valid 2901 S: a002 OK [READ-WRITE] SELECT completed 2902 C: a003 fetch 12 full 2903 S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700" 2904 RFC822.SIZE 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)" 2905 "IMAP4rev1 WG mtg summary and minutes" 2906 (("Terry Gray" NIL "gray" "cac.washington.edu")) 2907 (("Terry Gray" NIL "gray" "cac.washington.edu")) 2908 (("Terry Gray" NIL "gray" "cac.washington.edu")) 2909 ((NIL NIL "imap" "cac.washington.edu")) 2910 ((NIL NIL "minutes" "CNRI.Reston.VA.US") 2911 ("John Klensin" NIL "KLENSIN" "INFOODS.MIT.EDU")) NIL NIL 2912 "") 2913 BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92)) 2914 S: a003 OK FETCH completed 2915 C: a004 fetch 12 body[header] 2916 S: * 12 FETCH (BODY[HEADER] {350} 2917 S: Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT) 2918 S: From: Terry Gray 2919 S: Subject: IMAP4rev1 WG mtg summary and minutes 2920 S: To: imap@cac.washington.edu 2921 S: cc: minutes@CNRI.Reston.VA.US, John Klensin 2922 S: Message-Id: 2923 S: MIME-Version: 1.0 2924 S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 2925 S: 2926 S: ) 2927 S: a004 OK FETCH completed 2928 C: a005 store 12 +flags \deleted 2929 S: * 12 FETCH (FLAGS (\Seen \Deleted)) 2930 S: a005 OK +FLAGS completed 2931 C: a006 logout 2932 S: * BYE IMAP4rev1 server terminating connection 2933 S: a006 OK LOGOUT completed 2935 9. Formal Syntax 2937 The following syntax specification uses the augmented Backus-Naur 2938 Form (BNF) notation as specified in [RFC-822] with one exception; the 2939 delimiter used with the "#" construct is a single space (SPACE) and 2940 not one or more commas. 2942 In the case of alternative or optional rules in which a later rule 2943 overlaps an earlier rule, the rule which is listed earlier MUST take 2944 priority. For example, "\Seen" when parsed as a flag is the \Seen 2945 flag name and not a flag_extension, even though "\Seen" could be 2946 parsed as a flag_extension. Some, but not all, instances of this 2947 rule are noted below. 2949 Except as noted otherwise, all alphabetic characters are 2950 case-insensitive. The use of upper or lower case characters to 2951 define token strings is for editorial clarity only. Implementations 2952 MUST accept these strings in a case-insensitive fashion. 2954 address ::= "(" addr_name SPACE addr_adl SPACE addr_mailbox 2955 SPACE addr_host ")" 2957 addr_adl ::= nstring 2958 ;; Holds route from [RFC-822] route-addr if 2959 ;; non-NIL 2961 addr_host ::= nstring 2962 ;; NIL indicates [RFC-822] group syntax. 2963 ;; Otherwise, holds [RFC-822] domain name 2965 addr_mailbox ::= nstring 2966 ;; NIL indicates end of [RFC-822] group; if 2967 ;; non-NIL and addr_host is NIL, holds 2968 ;; [RFC-822] group name. 2969 ;; Otherwise, holds [RFC-822] local-part 2971 addr_name ::= nstring 2972 ;; Holds phrase from [RFC-822] mailbox if 2973 ;; non-NIL 2975 alpha ::= "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" / 2976 "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" / 2977 "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" / 2978 "Y" / "Z" / 2979 "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / 2980 "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" / 2981 "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" / 2982 "y" / "z" 2983 ;; Case-sensitive 2985 append ::= "APPEND" SPACE mailbox [SPACE flag_list] 2986 [SPACE date_time] SPACE literal 2988 astring ::= atom / string 2990 atom ::= 1*ATOM_CHAR 2992 ATOM_CHAR ::= 2994 atom_specials ::= "(" / ")" / "{" / SPACE / CTL / list_wildcards / 2995 quoted_specials 2997 authenticate ::= "AUTHENTICATE" SPACE auth_type *(CRLF base64) 2999 auth_type ::= atom 3000 ;; Defined by [IMAP-AUTH] 3002 base64 ::= *(4base64_char) [base64_terminal] 3004 base64_char ::= alpha / digit / "+" / "/" 3006 base64_terminal ::= (2base64_char "==") / (3base64_char "=") 3008 body ::= "(" body_type_1part / body_type_mpart ")" 3010 body_extension ::= nstring / number / "(" 1#body_extension ")" 3011 ;; Future expansion. Client implementations 3012 ;; MUST accept body_extension fields. Server 3013 ;; implementations MUST NOT generate 3014 ;; body_extension fields except as defined by 3015 ;; future standard or standards-track 3016 ;; revisions of this specification. 3018 body_ext_1part ::= body_fld_md5 [SPACE body_fld_dsp [SPACE body_fld_lang 3019 [SPACE 1#body_extension]]] 3020 ;; MUST NOT be returned on non-extensible 3021 ;; "BODY" fetch 3023 body_ext_mpart ::= body_fld_param [SPACE body_fld_dsp SPACE body_fld_lang 3024 [SPACE 1#body_extension]] 3025 ;; MUST NOT be returned on non-extensible 3026 ;; "BODY" fetch 3028 body_fields ::= body_fld_param SPACE body_fld_id SPACE 3029 body_fld_desc SPACE body_fld_enc SPACE 3030 body_fld_octets 3032 body_fld_desc ::= nstring 3034 body_fld_dsp ::= "(" string SPACE body_fld_param ")" / nil 3036 body_fld_enc ::= (<"> ("7BIT" / "8BIT" / "BINARY" / "BASE64"/ 3037 "QUOTED-PRINTABLE") <">) / string 3039 body_fld_id ::= nstring 3041 body_fld_lang ::= nstring / "(" 1#string ")" 3043 body_fld_lines ::= number 3045 body_fld_md5 ::= nstring 3047 body_fld_octets ::= number 3049 body_fld_param ::= "(" 1#(string SPACE string) ")" / nil 3051 body_type_1part ::= (body_type_basic / body_type_msg / body_type_text) 3052 [SPACE body_ext_1part] 3054 body_type_basic ::= media_basic SPACE body_fields 3055 ;; MESSAGE subtype MUST NOT be "RFC822" 3057 body_type_mpart ::= 1*body SPACE media_subtype 3058 [SPACE body_ext_mpart] 3060 body_type_msg ::= media_message SPACE body_fields SPACE envelope 3061 SPACE body SPACE body_fld_lines 3063 body_type_text ::= media_text SPACE body_fields SPACE body_fld_lines 3065 capability ::= "AUTH=" auth_type / atom 3066 ;; New capabilities MUST begin with "X" or be 3067 ;; registered with IANA as standard or 3068 ;; standards-track 3070 capability_data ::= "CAPABILITY" SPACE [1#capability SPACE] "IMAP4rev1" 3071 [SPACE 1#capability] 3072 ;; IMAP4rev1 servers which offer RFC-1730 3073 ;; compatibility MUST list "IMAP4" as the first 3074 ;; capability. 3076 CHAR ::= 3079 CHAR8 ::= 3081 command ::= tag SPACE (command_any / command_auth / 3082 command_nonauth / command_select) CRLF 3083 ;; Modal based on state 3085 command_any ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command 3086 ;; Valid in all states 3088 command_auth ::= append / create / delete / examine / list / lsub / 3089 rename / select / status / subscribe / unsubscribe 3090 ;; Valid only in Authenticated or Selected state 3092 command_nonauth ::= login / authenticate 3093 ;; Valid only when in Non-Authenticated state 3095 command_select ::= "CHECK" / "CLOSE" / "EXPUNGE" / 3096 copy / fetch / store / uid / search 3097 ;; Valid only when in Selected state 3099 continue_req ::= "+" SPACE (resp_text / base64) 3101 copy ::= "COPY" SPACE set SPACE mailbox 3103 CR ::= 3105 create ::= "CREATE" SPACE mailbox 3106 ;; Use of INBOX gives a NO error 3108 CRLF ::= CR LF 3110 CTL ::= 3113 date ::= date_text / <"> date_text <"> 3115 date_day ::= 1*2digit 3116 ;; Day of month 3118 date_day_fixed ::= (SPACE digit) / 2digit 3119 ;; Fixed-format version of date_day 3121 date_month ::= "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" / 3122 "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec" 3124 date_text ::= date_day "-" date_month "-" date_year 3126 date_year ::= 4digit 3128 date_time ::= <"> date_day_fixed "-" date_month "-" date_year 3129 SPACE time SPACE zone <"> 3131 delete ::= "DELETE" SPACE mailbox 3132 ;; Use of INBOX gives a NO error 3134 digit ::= "0" / digit_nz 3136 digit_nz ::= "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / 3137 "9" 3139 envelope ::= "(" env_date SPACE env_subject SPACE env_from 3140 SPACE env_sender SPACE env_reply_to SPACE env_to 3141 SPACE env_cc SPACE env_bcc SPACE env_in_reply_to 3142 SPACE env_message_id ")" 3144 env_bcc ::= "(" 1*address ")" / nil 3146 env_cc ::= "(" 1*address ")" / nil 3148 env_date ::= nstring 3150 env_from ::= "(" 1*address ")" / nil 3152 env_in_reply_to ::= nstring 3154 env_message_id ::= nstring 3156 env_reply_to ::= "(" 1*address ")" / nil 3158 env_sender ::= "(" 1*address ")" / nil 3160 env_subject ::= nstring 3162 env_to ::= "(" 1*address ")" / nil 3164 examine ::= "EXAMINE" SPACE mailbox 3165 fetch ::= "FETCH" SPACE set SPACE ("ALL" / "FULL" / 3166 "FAST" / fetch_att / "(" 1#fetch_att ")") 3168 fetch_att ::= "ENVELOPE" / "FLAGS" / "INTERNALDATE" / 3169 "RFC822" [".HEADER" / ".SIZE" / ".TEXT"] / 3170 "BODY" ["STRUCTURE"] / "UID" / 3171 "BODY" [".PEEK"] section ["<" number "." nz_number ">"] 3173 flag ::= "\Answered" / "\Flagged" / "\Deleted" / 3174 "\Seen" / "\Draft" / flag_keyword / flag_extension 3176 flag_extension ::= "\" atom 3177 ;; Future expansion. Client implementations 3178 ;; MUST accept flag_extension flags. Server 3179 ;; implementations MUST NOT generate 3180 ;; flag_extension flags except as defined by 3181 ;; future standard or standards-track 3182 ;; revisions of this specification. 3184 flag_keyword ::= atom 3186 flag_list ::= "(" #flag ")" 3188 greeting ::= "*" SPACE (resp_cond_auth / resp_cond_bye) CRLF 3190 header_fld_name ::= astring 3192 header_list ::= "(" 1#header_fld_name ")" 3194 LF ::= 3196 list ::= "LIST" SPACE mailbox SPACE list_mailbox 3198 list_mailbox ::= 1*(ATOM_CHAR / list_wildcards) / string 3200 list_wildcards ::= "%" / "*" 3202 literal ::= "{" number "}" CRLF *CHAR8 3203 ;; Number represents the number of CHAR8 octets 3205 login ::= "LOGIN" SPACE userid SPACE password 3207 lsub ::= "LSUB" SPACE mailbox SPACE list_mailbox 3208 mailbox ::= "INBOX" / astring 3209 ;; INBOX is case-insensitive. All case variants of 3210 ;; INBOX (e.g. "iNbOx") MUST be interpreted as INBOX 3211 ;; not as an astring. Refer to section 5.1 for 3212 ;; further semantic details of mailbox names. 3214 mailbox_data ::= "FLAGS" SPACE flag_list / 3215 "LIST" SPACE mailbox_list / 3216 "LSUB" SPACE mailbox_list / 3217 "MAILBOX" SPACE text / 3218 "SEARCH" [SPACE 1#nz_number] / 3219 "STATUS" SPACE mailbox SPACE 3220 "(" # QUOTED_CHAR <"> / nil) SPACE mailbox 3227 media_basic ::= (<"> ("APPLICATION" / "AUDIO" / "IMAGE" / "MESSAGE" / 3228 "VIDEO") <">) / string) SPACE media_subtype 3229 ;; Defined in [MIME-IMT] 3231 media_message ::= <"> "MESSAGE" <"> SPACE <"> "RFC822" <"> 3232 ;; Defined in [MIME-IMT] 3234 media_subtype ::= string 3235 ;; Defined in [MIME-IMT] 3237 media_text ::= <"> "TEXT" <"> SPACE media_subtype 3238 ;; Defined in [MIME-IMT] 3240 message_data ::= nz_number SPACE ("EXPUNGE" / ("FETCH" SPACE msg_att)) 3242 msg_att ::= "(" 1#("ENVELOPE" SPACE envelope / 3243 "FLAGS" SPACE "(" #(flag / "\Recent") ")" / 3244 "INTERNALDATE" SPACE date_time / 3245 "RFC822" [".HEADER" / ".TEXT"] SPACE nstring / 3246 "RFC822.SIZE" SPACE number / 3247 "BODY" ["STRUCTURE"] SPACE body / 3248 "BODY" section ["<" number ">"] SPACE nstring / 3249 "UID" SPACE uniqueid) ")" 3251 nil ::= "NIL" 3253 nstring ::= string / nil 3254 number ::= 1*digit 3255 ;; Unsigned 32-bit integer 3256 ;; (0 <= n < 4,294,967,296) 3258 nz_number ::= digit_nz *digit 3259 ;; Non-zero unsigned 32-bit integer 3260 ;; (0 < n < 4,294,967,296) 3262 password ::= astring 3264 quoted ::= <"> *QUOTED_CHAR <"> 3266 QUOTED_CHAR ::= / 3267 "\" quoted_specials 3269 quoted_specials ::= <"> / "\" 3271 rename ::= "RENAME" SPACE mailbox SPACE mailbox 3272 ;; Use of INBOX as a destination gives a NO error 3274 response ::= *(continue_req / response_data) response_done 3276 response_data ::= "*" SPACE (resp_cond_state / resp_cond_bye / 3277 mailbox_data / message_data / capability_data) 3278 CRLF 3280 response_done ::= response_tagged / response_fatal 3282 response_fatal ::= "*" SPACE resp_cond_bye CRLF 3283 ;; Server closes connection immediately 3285 response_tagged ::= tag SPACE resp_cond_state CRLF 3287 resp_cond_auth ::= ("OK" / "PREAUTH") SPACE resp_text 3288 ;; Authentication condition 3290 resp_cond_bye ::= "BYE" SPACE resp_text 3292 resp_cond_state ::= ("OK" / "NO" / "BAD") SPACE resp_text 3293 ;; Status condition 3295 resp_text ::= ["[" resp_text_code "]" SPACE] (text_mime2 / text) 3296 ;; text SHOULD NOT begin with "[" or "=" 3298 resp_text_code ::= "ALERT" / "PARSE" / 3299 "PERMANENTFLAGS" SPACE "(" #(flag / "\*") ")" / 3300 "READ-ONLY" / "READ-WRITE" / "TRYCREATE" / 3301 "UIDVALIDITY" SPACE nz_number / 3302 "UNSEEN" SPACE nz_number / 3303 atom [SPACE 1*] 3305 search ::= "SEARCH" SPACE ["CHARSET" SPACE astring SPACE] 3306 1#search_key 3307 ;; Character set MUST be registered with IANA 3308 ;; as a MIME character set 3310 search_key ::= "ALL" / "ANSWERED" / "BCC" SPACE astring / 3311 "BEFORE" SPACE date / "BODY" SPACE astring / 3312 "CC" SPACE astring / "DELETED" / "FLAGGED" / 3313 "FROM" SPACE astring / 3314 "KEYWORD" SPACE flag_keyword / "NEW" / "OLD" / 3315 "ON" SPACE date / "RECENT" / "SEEN" / 3316 "SINCE" SPACE date / "SUBJECT" SPACE astring / 3317 "TEXT" SPACE astring / "TO" SPACE astring / 3318 "UNANSWERED" / "UNDELETED" / "UNFLAGGED" / 3319 "UNKEYWORD" SPACE flag_keyword / "UNSEEN" / 3320 ;; Above this line were in [IMAP2] 3321 "DRAFT" / 3322 "HEADER" SPACE header_fld_name SPACE astring / 3323 "LARGER" SPACE number / "NOT" SPACE search_key / 3324 "OR" SPACE search_key SPACE search_key / 3325 "SENTBEFORE" SPACE date / "SENTON" SPACE date / 3326 "SENTSINCE" SPACE date / "SMALLER" SPACE number / 3327 "UID" SPACE set / "UNDRAFT" / set / 3328 "(" 1#search_key ")" 3330 section ::= "[" [section_text / (nz_number *["." nz_number] 3331 ["." (section_text / "MIME")])] "]" 3333 section_text ::= "HEADER" / "HEADER.FIELDS" [".NOT"] SPACE header_list / 3334 "TEXT" 3336 select ::= "SELECT" SPACE mailbox 3338 sequence_num ::= nz_number / "*" 3339 ;; * is the largest number in use. For message 3340 ;; sequence numbers, it is the number of messages 3341 ;; in the mailbox. For unique identifiers, it is 3342 ;; the unique identifier of the last message in 3343 ;; the mailbox. 3345 set ::= sequence_num / (sequence_num ":" sequence_num) / 3346 (set "," set) 3347 ;; Identifies a set of messages. For message 3348 ;; sequence numbers, these are consecutive 3349 ;; numbers from 1 to the number of messages in 3350 ;; the mailbox 3351 ;; Comma delimits individual numbers, colon 3352 ;; delimits between two numbers inclusive. 3353 ;; Example: 2,4:7,9,12:* is 2,4,5,6,7,9,12,13, 3354 ;; 14,15 for a mailbox with 15 messages. 3356 SPACE ::= 3358 status ::= "STATUS" SPACE mailbox SPACE "(" 1#status_att ")" 3360 status_att ::= "MESSAGES" / "RECENT" / "UIDNEXT" / "UIDVALIDITY" / 3361 "UNSEEN" 3363 store ::= "STORE" SPACE set SPACE store_att_flags 3365 store_att_flags ::= (["+" / "-"] "FLAGS" [".SILENT"]) SPACE 3366 (flag_list / #flag) 3368 string ::= quoted / literal 3370 subscribe ::= "SUBSCRIBE" SPACE mailbox 3372 tag ::= 1* 3374 text ::= 1*TEXT_CHAR 3376 text_mime2 ::= "=?" "?" "?" 3377 "?=" 3378 ;; Syntax defined in [MIME-HDRS] 3380 TEXT_CHAR ::= 3382 time ::= 2digit ":" 2digit ":" 2digit 3383 ;; Hours minutes seconds 3385 uid ::= "UID" SPACE (copy / fetch / search / store) 3386 ;; Unique identifiers used instead of message 3387 ;; sequence numbers 3389 uniqueid ::= nz_number 3390 ;; Strictly ascending 3392 unsubscribe ::= "UNSUBSCRIBE" SPACE mailbox 3394 userid ::= astring 3396 x_command ::= "X" atom 3398 zone ::= ("+" / "-") 4digit 3399 ;; Signed four-digit value of hhmm representing 3400 ;; hours and minutes west of Greenwich (that is, 3401 ;; (the amount that the given time differs from 3402 ;; Universal Time). Subtracting the timezone 3403 ;; from the given time will give the UT form. 3404 ;; The Universal Time zone is "+0000". 3406 10. Author's Note 3408 This document is a revision or rewrite of earlier documents, and 3409 supercedes the protocol specification in those documents: RFC 1730, 3410 unpublished IMAP2bis.TXT document, RFC 1176, and RFC 1064. 3412 11. Security Considerations 3414 IMAP4rev1 protocol transactions, including electronic mail data, are 3415 sent in the clear over the network unless privacy protection is 3416 negotiated in the AUTHENTICATE command. 3418 A server error message for an AUTHENTICATE command which fails due to 3419 invalid credentials SHOULD NOT detail why the credentials are 3420 invalid. 3422 Use of the LOGIN command sends passwords in the clear. This can be 3423 avoided by using the AUTHENTICATE command instead. 3425 A server error message for a failing LOGIN command SHOULD NOT specify 3426 that the user name, as opposed to the password, is invalid. 3428 Additional security considerations are discussed in the section 3429 discussing the AUTHENTICATE and LOGIN commands. 3431 12. Author's Address 3433 Mark R. Crispin 3434 Networks and Distributed Computing 3435 University of Washington 3436 4545 15th Aveneue NE 3437 Seattle, WA 98105-4527 3439 Phone: (206) 543-5762 3441 EMail: MRC@CAC.Washington.EDU 3443 Appendices 3445 A. References 3447 [ACAP] Myers, J. "ACAP -- Application Configuration Access Protocol", 3448 Work in Progress. 3450 [DISPOSITION] Troost, R., and Dorner, S., "Communicating Presentation 3451 Information in Internet Messages: The Content-Disposition Header", 3452 RFC 1806, June 1995. 3454 [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731. 3455 Carnegie-Mellon University, December 1994. 3457 [IMAP-COMPAT] Crispin, M., "IMAP4 Compatibility with IMAP2bis", Work 3458 in Progress. 3460 [IMAP-DISC] Austein, R., "Synchronization Operations for Disconnected 3461 IMAP4 Clients", Work in Progress. 3463 [IMAP-HISTORICAL] Crispin, M. "IMAP4 Compatibility with IMAP2 and 3464 IMAP2bis", RFC 1732, University of Washington, December 1994. 3466 [IMAP-MODEL] Crispin, M., "Distributed Electronic Mail Models in 3467 IMAP4", RFC 1733, University of Washington, December 1994. 3469 [IMAP-OBSOLETE] Crispin, M., "Internet Message Access Protocol - 3470 Obsolete Syntax", Work in Progress. 3472 [IMAP2] Crispin, M., "Interactive Mail Access Protocol - Version 2", 3473 RFC 1176, University of Washington, August 1990. 3475 [LANGUAGE-TAGS] Alvestrand, H., "Tags for the Identification of 3476 Languages", RFC 1766, March 1995. 3478 [MD5] Myers, J., and Rose, M., "The Content-MD5 Header Field", RFC 3479 1864, October 1995. 3481 [MIME-IMB] Borenstein, N.., "MIME (Multipurpose Internet Mail 3482 Extensions) Part One: Format of Internet Message Bodies", Work in 3483 Progress. 3485 [MIME-IMT] Freed, N., and Borenstein, N.., "MIME (Multipurpose 3486 Internet Mail Extensions) Part Two: Media Types", Work in Progress. 3488 [MIME-HDRS] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 3489 Part Three: Message Header Extensions for Non-ASCII Text", Work in 3490 Progress. 3492 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text 3493 Messages", STD 11, RFC 822, University of Delaware, August 1982. 3495 [SMTP] Postel, Jonathan B. "Simple Mail Transfer Protocol", STD 10, 3496 RFC 821, USC/Information Sciences Institute, August 1982. 3498 [UTF-7] Goldsmith, D., and Davis, M., "UTF-7: A Mail-Safe 3499 Transformation Format of Unicode", RFC 1642, July 1994. 3501 B. Changes from RFC 1730 3503 1) The STATUS command has been added. 3505 2) Clarify in the formal syntax that the "#" construct can never 3506 refer to multiple spaces. 3508 3) Obsolete syntax has been moved to a separate document. 3510 4) The PARTIAL command has been obsoleted. 3512 5) The RFC822.HEADER.LINES, RFC822.HEADER.LINES.NOT, RFC822.PEEK, and 3513 RFC822.TEXT.PEEK fetch attributes have been obsoleted. 3515 6) The "<" origin "." size ">" suffix for BODY text attributes has 3516 been added. 3518 7) The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME, and TEXT part 3519 specifiers have been added. 3521 8) Support for Content-Disposition and Content-Language has been 3522 added. 3524 9) The restriction on fetching nested MULTIPART parts has been 3525 removed. 3527 10) Body part number 0 has been obsoleted. 3529 11) Server-supported authenticators are now identified by 3530 capabilities. 3532 12) The capability that identifies this protocol is now called 3533 "IMAP4rev1". A server that provides backwards support for RFC 1730 3534 SHOULD emit the "IMAP4" capability in addition to "IMAP4rev1" in its 3535 CAPABILITY response. Because RFC-1730 required "IMAP4" to appear as 3536 the first capability, it MUST listed first in the response. 3538 13) A description of the mailbox name namespace convention has been 3539 added. 3541 14) A description of the international mailbox name convention has 3542 been added. 3544 15) The UID-NEXT and UID-VALIDITY status items are now called UIDNEXT 3545 and UIDVALIDITY. This is a change from the IMAP STATUS 3546 16) Add a clarification that a null mailbox name argument to the LIST 3547 command returns an untagged LIST response with the hierarchy 3548 delimiter and root of the reference argument. 3550 17) Define terms such as "MUST", "SHOULD", and "MUST NOT". 3552 18) Add a section which defines message attributes and more 3553 thoroughly details the semantics of message sequence numbers, UIDs, 3554 and flags. 3556 19) Add a clarification detailing the circumstances when a client may 3557 send multiple commands without waiting for a response, and the 3558 circumstances in which ambiguities may result. 3560 20) Add a recommendation on server behavior for DELETE and RENAME 3561 when inferior hierarchical names of the given name exist. 3563 21) Add a clarification that a mailbox name may not be unilaterally 3564 unsubscribed by the server, even if that mailbox name no longer 3565 exists. 3567 22) Add a clarification that LIST should return its results quickly 3568 without undue delay. 3570 23) Add a clarification that the date_time argument to APPEND sets 3571 the internal date of the message. 3573 24) Add a clarification on APPEND behavior when the target mailbox is 3574 the currently selected mailbox. 3576 25) Add a clarification that external changes to flags should be 3577 always announced via an untagged FETCH even if the current command is 3578 a STORE with the ".SILENT" suffix. 3580 26) Add a clarification that COPY appends to the target mailbox. 3582 27) Add the NEWNAME response code. 3584 28) Rewrite the description of the untagged BYE response to clarify 3585 its semantics. 3587 29) Change the reference for the body MD5 to refer to the proper RFC. 3589 30) Clarify that the formal syntax contains rules which may overlap, 3590 and that in the event of such an overlap the rule which occurs first 3591 takes precedence. 3593 31) Correct the definition of body_fld_param. 3595 32) More formal syntax for capability_data. 3597 33) Clarify that any case variant of "INBOX" must be interpreted as 3598 INBOX. 3600 34) Clarify that the human-readable text in resp_text should not 3601 begin with "[" or "=". 3603 35) Change MIME references to Draft Standard documents. 3605 C. Key Word Index 3607 +FLAGS (store command data item) ............... 44 3608 +FLAGS.SILENT (store command data item) ........ 44 3609 -FLAGS (store command data item) ............... 44 3610 -FLAGS.SILENT (store command data item) ........ 44 3611 ALERT (response code) ...................................... 48 3612 ALL (fetch item) ........................................... 40 3613 ALL (search key) ........................................... 37 3614 ANSWERED (search key) ...................................... 37 3615 APPEND (command) ........................................... 32 3616 AUTHENTICATE (command) ..................................... 18 3617 BAD (response) ............................................. 50 3618 BCC (search key) .................................. 37 3619 BEFORE (search key) ................................. 37 3620 BODY (fetch item) .......................................... 40 3621 BODY (fetch result) ........................................ 57 3622 BODY (search key) ................................. 37 3623 BODY.PEEK[
]<> (fetch item) ............... 42 3624 BODYSTRUCTURE (fetch item) ................................. 42 3625 BODYSTRUCTURE (fetch result) ............................... 57 3626 BODY[
]<> (fetch result) ............. 57 3627 BODY[
]<> (fetch item) .................... 40 3628 BYE (response) ............................................. 51 3629 Body Structure (message attribute) ......................... 7 3630 CAPABILITY (command) ....................................... 16 3631 CAPABILITY (response) ...................................... 52 3632 CC (search key) ................................... 37 3633 CHECK (command) ............................................ 34 3634 CLOSE (command) ............................................ 34 3635 COPY (command) ............................................. 44 3636 CREATE (command) ........................................... 23 3637 DELETE (command) ........................................... 24 3638 DELETED (search key) ....................................... 37 3639 DRAFT (search key) ......................................... 37 3640 ENVELOPE (fetch item) ...................................... 42 3641 ENVELOPE (fetch result) .................................... 60 3642 EXAMINE (command) .......................................... 22 3643 EXISTS (response) .......................................... 55 3644 EXPUNGE (command) .......................................... 35 3645 EXPUNGE (response) ......................................... 56 3646 Envelope Structure (message attribute) ..................... 7 3647 FAST (fetch item) .......................................... 42 3648 FETCH (command) ............................................ 39 3649 FETCH (response) ........................................... 57 3650 FLAGGED (search key) ....................................... 37 3651 FLAGS (fetch item) ......................................... 42 3652 FLAGS (fetch result) ....................................... 61 3653 FLAGS (response) ........................................... 54 3654 FLAGS (store command data item) ................ 43 3655 FLAGS.SILENT (store command data item) ......... 43 3656 FROM (search key) ................................. 37 3657 FULL (fetch item) .......................................... 42 3658 Flags (message attribute) .................................. 6 3659 HEADER (part specifier) .................................... 40 3660 HEADER (search key) .................. 37 3661 HEADER.FIELDS (part specifier) ............... 40 3662 HEADER.FIELDS.NOT (part specifier) ........... 40 3663 INTERNALDATE (fetch item) .................................. 42 3664 INTERNALDATE (fetch result) ................................ 61 3665 Internal Date (message attribute) .......................... 6 3666 KEYWORD (search key) ................................ 38 3667 Keyword (type of flag) ..................................... 6 3668 LARGER (search key) .................................... 38 3669 LIST (command) ............................................. 28 3670 LIST (response) ............................................ 52 3671 LOGIN (command) ............................................ 20 3672 LOGOUT (command) ........................................... 18 3673 LSUB (command) ............................................. 30 3674 LSUB (response) ............................................ 53 3675 MAY (specification requirement term) ....................... 1 3676 MESSAGES (status item) ..................................... 32 3677 MIME (part specifier) ...................................... 41 3678 MUST (specification requirement term) ...................... 1 3679 MUST NOT (specification requirement term) .................. 1 3680 Message Sequence Number (message attribute) ................ 5 3681 NEW (search key) ........................................... 38 3682 NEWNAME (response code) .................................... 48 3683 NO (response) .............................................. 50 3684 NOOP (command) ............................................. 17 3685 NOT (search key) .............................. 38 3686 OK (response) .............................................. 49 3687 OLD (search key) ........................................... 38 3688 ON (search key) ..................................... 38 3689 OPTIONAL (specification requirement term) .................. 1 3690 OR (search key) ................ 38 3691 PARSE (response code) ...................................... 48 3692 PERMANENTFLAGS (response code) ............................. 48 3693 PREAUTH (response) ......................................... 51 3694 Permanent Flag (class of flag) ............................. 6 3695 READ-ONLY (response code) .................................. 49 3696 READ-WRITE (response code) ................................. 49 3697 RECENT (response) .......................................... 55 3698 RECENT (search key) ........................................ 38 3699 RECENT (status item) ....................................... 32 3700 RENAME (command) ........................................... 26 3701 REQUIRED (specification requirement term) .................. 1 3702 RFC822 (fetch item) ........................................ 42 3703 RFC822 (fetch result) ...................................... 61 3704 RFC822.HEADER (fetch item) ................................. 42 3705 RFC822.HEADER (fetch result) ............................... 61 3706 RFC822.SIZE (fetch item) ................................... 42 3707 RFC822.SIZE (fetch result) ................................. 61 3708 RFC822.TEXT (fetch item) ................................... 42 3709 RFC822.TEXT (fetch result) ................................. 61 3710 SEARCH (command) ........................................... 36 3711 SEARCH (response) .......................................... 54 3712 SEEN (search key) .......................................... 38 3713 SELECT (command) ........................................... 21 3714 SENTBEFORE (search key) ............................. 38 3715 SENTON (search key) ................................. 38 3716 SENTSINCE (search key) .............................. 38 3717 SHOULD (specification requirement term) .................... 1 3718 SHOULD NOT (specification requirement term) ................ 1 3719 SINCE (search key) .................................. 38 3720 SMALLER (search key) ................................... 38 3721 STATUS (command) ........................................... 31 3722 STATUS (response) .......................................... 54 3723 STORE (command) ............................................ 43 3724 SUBJECT (search key) .............................. 38 3725 SUBSCRIBE (command) ........................................ 27 3726 Session Flag (class of flag) ............................... 6 3727 System Flag (type of flag) ................................. 6 3728 TEXT (part specifier) ...................................... 41 3729 TEXT (search key) ................................. 39 3730 TO (search key) ................................... 39 3731 TRYCREATE (response code) .................................. 49 3732 UID (command) .............................................. 45 3733 UID (fetch item) ........................................... 43 3734 UID (fetch result) ......................................... 61 3735 UID (search key) ............................. 39 3736 UIDNEXT (status item) ...................................... 32 3737 UIDVALIDITY (response code) ................................ 49 3738 UIDVALIDITY (status item) .................................. 32 3739 UNANSWERED (search key) .................................... 39 3740 UNDELETED (search key) ..................................... 39 3741 UNDRAFT (search key) ....................................... 39 3742 UNFLAGGED (search key) ..................................... 39 3743 UNKEYWORD (search key) .............................. 39 3744 UNSEEN (response code) ..................................... 49 3745 UNSEEN (search key) ........................................ 39 3746 UNSEEN (status item) ....................................... 32 3747 UNSUBSCRIBE (command) ...................................... 28 3748 Unique Identifier (UID) (message attribute) ................ 4 3749 X (command) .......................................... 46 3750 [RFC-822] Size (message attribute) ......................... 7 3751 \Answered (system flag) .................................... 61 3752 \Deleted (system flag) ..................................... 61 3753 \Draft (system flag) ....................................... 61 3754 \Flagged (system flag) ..................................... 61 3755 \Marked (mailbox name attribute) ........................... 53 3756 \Noinferiors (mailbox name attribute) ...................... 53 3757 \Noselect (mailbox name attribute) ......................... 53 3758 \Recent (system flag) ...................................... 61 3759 \Seen (system flag) ........................................ 61 3760 \Unmarked (mailbox name attribute) ......................... 53