idnits 2.17.1 draft-crispin-imapv-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-03-28) 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 28 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([ACAP], [IMAP-HISTORICAL], [IMAP2], [SMTP], [IMAP-DISC], [IMAP-COMPAT], [IMAP-OBSOLETE], [MIME-IMB], [RFC-822]), 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 160: '... Clients MUST follow the syntax outl...' RFC 2119 keyword, line 185: '... MUST send a complete command (...' RFC 2119 keyword, line 200: '... Server data MAY be sent as a result...' RFC 2119 keyword, line 214: '... Servers SHOULD enforce the syntax o...' RFC 2119 keyword, line 217: '... SHOULD be rejected, and the client ...' (220 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 (September 1998) is 9326 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 3697 looks like a reference -- Missing reference section? 'RFC-822' on line 3859 looks like a reference -- Missing reference section? 'MIME-IMB' on line 3721 looks like a reference -- Missing reference section? 'ACAP' on line 3684 looks like a reference -- Missing reference section? 'SMTP' on line 3739 looks like a reference -- Missing reference section? 'IMAP2' on line 3709 looks like a reference -- Missing reference section? 'IMAP-OBSOLETE' on line 3706 looks like a reference -- Missing reference section? 'IMAP-COMPAT' on line 3694 looks like a reference -- Missing reference section? 'IMAP-HISTORICAL' on line 3700 looks like a reference -- Missing reference section? 'KEYWORDS' on line 3712 looks like a reference -- Missing reference section? 'MIME-IMT' on line 3725 looks like a reference -- Missing reference section? 'CHARSET' on line 3687 looks like a reference -- Missing reference section? 'UTF-7' on line 3742 looks like a reference -- Missing reference section? 'SASL' on line 3736 looks like a reference -- Missing reference section? 'UNSEEN 12' on line 1179 looks like a reference -- Missing reference section? 'UIDVALIDITY 3857529045' on line 3127 looks like a reference -- Missing reference section? 'UIDNEXT 4392' on line 1212 looks like a reference -- Missing reference section? 'UNSEEN 8' on line 1210 looks like a reference -- Missing reference section? 'MIME-HDRS' on line 3729 looks like a reference -- Missing reference section? 'HEADER' on line 3143 looks like a reference -- Missing reference section? 'TEXT' on line 3079 looks like a reference -- Missing reference section? 'DISPOSITION' on line 3690 looks like a reference -- Missing reference section? 'LANGUAGE-TAGS' on line 3715 looks like a reference -- Missing reference section? 'MD5' on line 3718 looks like a reference -- Missing reference section? 'UNSEEN 17' on line 3126 looks like a reference -- Missing reference section? 'READ-WRITE' on line 3128 looks like a reference -- Missing reference section? 'ABNF' on line 3855 looks like a reference -- Missing reference section? 'IMAP-MODEL' on line 3703 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 1 warning (==), 31 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Crispin 3 Internet Draft: IMAP4rev1 University of Washington 4 Document: internet-drafts/draft-crispin-imapv-06.txt September 1998 6 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as "work in progress." 20 To learn the current status of any Internet-Draft, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), 23 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 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 28 February 1999. Distribution of this memo is unlimited. 31 This document is a revision of RFC 2060. 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 mailboxes (remote 39 message folders) in a way that is functionally equivalent to local 40 folders. 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-IMB] parsing; 46 searching; and selective fetching of message attributes, texts, and 47 portions thereof. Messages in IMAP4rev1 are accessed by the use of 48 numbers. 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 can 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 IMAP4rev1 Protocol Specification 73 1. How to Read This Document 75 1.1. Organization of This Document 77 This document is written from the point of view of the implementor of 78 an IMAP4rev1 client or server. Beyond the protocol overview in 79 section 2, it is not optimized for someone trying to understand the 80 operation of the protocol. The material in sections 3 through 5 81 provides the general context and definitions with which IMAP4rev1 82 operates. 84 Sections 6, 7, and 9 describe the IMAP commands, responses, and 85 syntax, respectively. The relationships among these are such that it 86 is almost impossible to understand any of them separately. In 87 particular, do not attempt to deduce command syntax from the command 88 section alone; instead refer to the Formal Syntax section. 90 1.2. Conventions Used in This Document 92 "Conventions" are basic principles or procedures. Document 93 conventions are noted in this section. 95 In examples, "C:" and "S:" indicate lines sent by the client and 96 server respectively. 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to 100 be interpreted as described in [KEYWORDS]. 102 The word "can" (not "may") is used to refer to a possible 103 circumstance or situation, as opposed to an optional facility of the 104 protocol. 106 "User" is used to refer to a human user, whereas "client" refers to 107 the software being run by the user. 109 "Connection" refers to the entire sequence of client/server 110 interaction from the initial establishment of the network connection 111 until its termination. "Session" refers to the sequence of 112 client/server interaction from the time that a mailbox is selected 113 (SELECT or EXAMINE command) until the time that selection ends 114 (SELECT or EXAMINE of another mailbox, CLOSE command, or connection 115 termination). 117 Characters are 7-bit US-ASCII unless otherwise specified. Other 118 character sets are indicated using a "CHARSET", as described in 119 [MIME-IMT] and defined in [CHARSET]. CHARSETs have important 120 additional semantics in addition to defining character set; refer to 121 these documents for more detail. 123 There are several protocol conventions in IMAP. These refer to 124 aspects of the specification which are not strictly part of the IMAP 125 protocol, but which reflect generally-accepted practice. 126 Implementations need to be aware of these conventions, and avoid 127 conflicts whether or not they implement the convention. For example, 128 "&" may not be used as a hierarchy delimiter since it conflicts with 129 the Mailbox International Naming Convention, and other uses of "&" in 130 mailbox names are impacted as well. 132 2. Protocol Overview 134 2.1. Link Level 136 The IMAP4rev1 protocol assumes a reliable data stream such as 137 provided by TCP. When TCP is used, an IMAP4rev1 server listens on 138 port 143. 140 2.2. Commands and Responses 142 An IMAP4rev1 connection consists of the establishment of a 143 client/server network connection, an initial greeting from the 144 server, and client/server interactions. These client/server 145 interactions consist of a client command, server data, and a server 146 completion result response. 148 All interactions transmitted by client and server are in the form of 149 lines; that is, strings that end with a CRLF. The protocol receiver 150 of an IMAP4rev1 client or server is either reading a line, or is 151 reading a sequence of octets with a known count followed by a line. 153 2.2.1. Client Protocol Sender and Server Protocol Receiver 155 The client command begins an operation. Each client command is 156 prefixed with an identifier (typically a short alphanumeric string, 157 e.g. A0001, A0002, etc.) called a "tag". A different tag is 158 generated by the client for each command. 160 Clients MUST follow the syntax outlined in this specification 161 strictly. It is a syntax error to send a command with missing or 162 extraneous spaces or arguments. 164 There are two cases in which a line from the client does not 165 represent a complete command. In one case, a command argument is 166 quoted with an octet count (see the description of literal in String 167 under Data Formats); in the other case, the command arguments require 168 server feedback (see the AUTHENTICATE command). In either case, the 169 server sends a command continuation request response if it is ready 170 for the octets (if appropriate) and the remainder of the command. 171 This response is prefixed with the token "+". 173 Note: If, instead, the server detected an error in the 174 command, it sends a BAD completion response with tag 175 matching the command (as described below) to reject the 176 command and prevent the client from sending any more of the 177 command. 179 It is also possible for the server to send a completion 180 response for some other command (if multiple commands are 181 in progress), or untagged data. In either case, the 182 command continuation request is still pending; the client 183 takes the appropriate action for the response, and reads 184 another response from the server. In all cases, the client 185 MUST send a complete command (including receiving all 186 command continuation request responses and command 187 continuations for the command) before initiating a new 188 command. 190 The protocol receiver of an IMAP4rev1 server reads a command line 191 from the client, parses the command and its arguments, and transmits 192 server data and a server command completion result response. 194 2.2.2. Server Protocol Sender and Client Protocol Receiver 196 Data transmitted by the server to the client and status responses 197 that do not indicate command completion are prefixed with the token 198 "*", and are called untagged responses. 200 Server data MAY be sent as a result of a client command, or MAY be 201 sent unilaterally by the server. There is no syntactic difference 202 between server data that resulted from a specific command and server 203 data that were sent unilaterally. 205 The server completion result response indicates the success or 206 failure of the operation. It is tagged with the same tag as the 207 client command which began the operation. Thus, if more than one 208 command is in progress, the tag in a server completion response 209 identifies the command to which the response applies. There are 210 three possible server completion responses: OK (indicating success), 211 NO (indicating failure), or BAD (indicating protocol error such as 212 unrecognized command or command syntax error). 214 Servers SHOULD enforce the syntax outlined in this specification 215 strictly. Any client command with a protocol syntax error, including 216 (but not limited to) missing or extraneous spaces or arguments, 217 SHOULD be rejected, and the client given a BAD server completion 218 response. 220 The protocol receiver of an IMAP4rev1 client reads a response line 221 from the server. It then takes action on the response based upon the 222 first token of the response, which can be a tag, a "*", or a "+". 224 A client MUST be prepared to accept any server response at all times. 225 This includes server data that was not requested. Server data SHOULD 226 be recorded, so that the client can reference its recorded copy 227 rather than sending a command to the server to request the data. In 228 the case of certain server data, the data MUST be recorded. 230 This topic is discussed in greater detail in the Server Responses 231 section. 233 2.3. Message Attributes 235 In addition to message text, each message has several attributes 236 associated with it. These attributes can be retrieved individually 237 or in conjunction with other attributes or message texts. 239 2.3.1. Message Numbers 241 Messages in IMAP4rev1 are accessed by one of two numbers; the unique 242 identifier and the message sequence number. 244 2.3.1.1. Unique Identifier (UID) Message Attribute 246 A 32-bit value assigned to each message, which when used with the 247 unique identifier validity value (see below) forms a 64-bit value 248 that is permanently guaranteed not to refer to any other message in 249 the mailbox. Unique identifiers are assigned in a strictly ascending 250 fashion in the mailbox; as each message is added to the mailbox it is 251 assigned a higher UID than the message(s) which were added 252 previously. Unlike message sequence numbers, unique identifiers are 253 not necessarily contiguous. 255 The unique identifier of a message MUST NOT change during the 256 session, and SHOULD NOT change between sessions. Any change of 257 unique identifiers between sessions MUST be detectable using the 258 UIDVALIDITY mechanism discussed below. Persistant unique identifiers 259 are required for a client to resynchronize its state from a previous 260 session with the server (e.g. disconnected or offline access 261 clients); this is discussed further in [IMAP-DISC]. 263 Associated with every mailbox are two values which aid in unique 264 identifer handling: the next unique identifier value and the unique 265 identifier validity value. 267 The next unique identifer value is the predicted value that will be 268 assigned to a new message in the mailbox. Unless the unique 269 identifer validity also changes (see below), two characteristics of 270 the next unique identifer value are guaranteed. First, the next 271 unique identifer value will not change unless new messages are added 272 to the mailbox; and second, the next unique identifer value will 273 change whenever new messages are added to the mailbox, even if those 274 new messages are subsequently expunged. 276 Note: The next unique identifier value is intended to 277 provide a means for a client to determine whether any 278 messages have been delivered to the mailbox since the 279 previous time it checked this value. It is not intended to 280 provide any guarantee that any message will have this 281 unique identifier; a client can only assume that a new 282 message will have a UID that is greater than or equal to 283 the next unique identifier value. 285 The unique identifier validity value is sent in an UIDVALIDITY 286 response code in an OK untagged response at mailbox selection time. 287 If unique identifiers from an earlier session fail to persist to this 288 session, the unique identifier validity value MUST be greater than 289 the one used in the earlier session. 291 Note: Ideally, unique identifiers SHOULD persist at all 292 times. Although this specification recognizes that failure 293 to persist can be unavoidable in certain server 294 environments, it STRONGLY ENCOURAGES message store 295 implementation techniques that avoid this problem. For 296 example: 298 1) Unique identifiers MUST be strictly ascending in the 299 mailbox at all times. If the physical message store is 300 re-ordered by a non-IMAP agent, this requires that the 301 unique identifiers in the mailbox be regenerated, since the 302 former unique identifers are no longer strictly ascending 303 as a result of the re-ordering. 305 2) If the message store has no mechanism to store unique 306 identifiers, it must regenerate unique identifiers at each 307 session, and each session must have a unique UIDVALIDITY 308 value. 310 3) If the mailbox is deleted and a new mailbox with the 311 same name is created at a later date, the server must 312 either keep track of unique identifiers from the previous 313 instance of the mailbox, or it must assign a new 314 UIDVALIDITY value to the new instance of the mailbox. A 315 good UIDVALIDITY value to use in this case is a 32-bit 316 representation of the creation date/time of the mailbox. 317 It is alright to use a constant such as 1, but only if it 318 guaranteed that unique identifiers will never be reused, 319 even in the case of a mailbox being deleted (or renamed) 320 and a new mailbox by the same name created at some future 321 time. 323 2.3.1.2. Message Sequence Number Message Attribute 325 A relative position from 1 to the number of messages in the mailbox. 326 This position MUST be ordered by ascending unique identifier. As 327 each new message is added, it is assigned a message sequence number 328 that is 1 higher than the number of messages in the mailbox before 329 that new message was added. 331 Message sequence numbers can be reassigned during the session. For 332 example, when a message is permanently removed (expunged) from the 333 mailbox, the message sequence number for all subsequent messages is 334 decremented. Similarly, a new message can be assigned a message 335 sequence number that was once held by some other message prior to an 336 expunge. 338 In addition to accessing messages by relative position in the 339 mailbox, message sequence numbers can be used in mathematical 340 calculations. For example, if an untagged "11 EXISTS" is received, 341 and previously an untagged "8 EXISTS" was received, three new 342 messages have arrived with message sequence numbers of 9, 10, and 11. 343 Another example; if message 287 in a 523 message mailbox has UID 344 12345, there are exactly 286 messages which have lesser UIDs and 236 345 messages which have greater UIDs. 347 2.3.2. Flags Message Attribute 349 A list of zero or more named tokens associated with the message. A 350 flag is set by its addition to this list, and is cleared by its 351 removal. There are two types of flags in IMAP4rev1. A flag of 352 either type can be permanent or session-only. 354 A system flag is a flag name that is pre-defined in this 355 specification. All system flags begin with "\". Certain system 356 flags (\Deleted and \Seen) have special semantics described 357 elsewhere. The currently-defined system flags are: 359 \Seen 360 Message has been read 362 \Answered 363 Message has been answered 365 \Flagged 366 Message is "flagged" for urgent/special attention 368 \Deleted 369 Message is "deleted" for removal by later EXPUNGE 371 \Draft 372 Message has not completed composition (marked as a draft). 374 \Recent 375 Message is "recently" arrived in this mailbox. This session 376 is the first session to have been notified about this 377 message; subsequent sessions will not see \Recent set for 378 this message. This flag can not be altered by the client. 380 If it is not possible to determine whether or not this 381 session is the first session to be notified about a message, 382 then that message SHOULD be considered recent. 384 If multiple connections have the same mailbox selected 385 simultaneously, it is undefined which of these connections 386 will see newly-arrived messages with \Recent set and which 387 will see it without \Recent set. 389 A keyword is defined by the server implementation. Keywords do not 390 begin with "\". Servers MAY permit the client to define new keywords 391 in the mailbox (see the description of the PERMANENTFLAGS response 392 code for more information). 394 A flag can be permanent or session-only on a per-flag basis. 395 Permanent flags are those which the client can add or remove from the 396 message flags permanently; that is, subsequent sessions will see any 397 change in permanent flags. Changes to session flags are valid only 398 in that session. 400 Note: The \Recent system flag is a special case of a 401 session flag. \Recent can not be used as an argument in a 402 STORE command, and thus can not be changed at all. 404 2.3.3. Internal Date Message Attribute 406 The internal date and time of the message on the server. This is not 407 the date and time in the [RFC-822] header, but rather a date and time 408 which reflects when the message was received. In the case of 409 messages delivered via [SMTP], this SHOULD be the date and time of 410 final delivery of the message as defined by [SMTP]. In the case of 411 messages delivered by the IMAP4rev1 COPY command, this SHOULD be the 412 internal date and time of the source message. In the case of 413 messages delivered by the IMAP4rev1 APPEND command, this SHOULD be 414 the date and time as specified in the APPEND command description. 415 All other cases are implementation defined. 417 2.3.4. [RFC-822] Size Message Attribute 419 The number of octets in the message, as expressed in [RFC-822] 420 format. 422 2.3.5. Envelope Structure Message Attribute 424 A parsed representation of the [RFC-822] envelope information (not to 425 be confused with an [SMTP] envelope) of the message. 427 2.3.6. Body Structure Message Attribute 429 A parsed representation of the [MIME-IMB] body structure information 430 of the message. 432 2.4. Message Texts 434 In addition to being able to fetch the full [RFC-822] text of a 435 message, IMAP4rev1 permits the fetching of portions of the full 436 message text. Specifically, it is possible to fetch the [RFC-822] 437 message header, [RFC-822] message body, a [MIME-IMB] body part, or a 438 [MIME-IMB] header. 440 3. State and Flow Diagram 442 An IMAP4rev1 server is in one of four states. Most commands are 443 valid in only certain states. It is a protocol error for the client 444 to attempt a command while the command is in an inappropriate state. 445 In this case, a server will respond with a BAD or NO (depending upon 446 server implementation) command completion result. 448 3.1. Not Authenticated State 450 In not authenticated state, the client MUST supply authentication 451 credentials before most commands will be permitted. This state is 452 entered when a connection starts unless the connection has been 453 pre-authenticated. 455 3.2. Authenticated State 457 In authenticated state, the client is authenticated and MUST select a 458 mailbox to access before commands that affect messages will be 459 permitted. This state is entered when a pre-authenticated connection 460 starts, when acceptable authentication credentials have been 461 provided, or after an error in selecting a mailbox. 463 3.3. Selected State 465 In selected state, a mailbox has been selected to access. This state 466 is entered when a mailbox has been successfully selected. 468 3.4. Logout State 470 In logout state, the connection is being terminated, and the server 471 will close the connection. This state can be entered as a result of 472 a client request or by unilateral server decision. 474 +------------------+ 475 |initial connection| 476 +------------------+ 477 || 478 VV 479 +--------------------------------------+ 480 | server greeting | 481 +--------------------------------------+ 482 || (1) || (2) || (3) 483 VV || || 484 +-----------------+ || || 485 |Not Authenticated| || || 486 +-----------------+ || || 487 || (7) || (4) || || 488 || VV VV || 489 || +----------------+ || 490 || | Authenticated |<=++ || 491 || +----------------+ || || 492 || || (7) || (5) || (6) || 493 || || VV || || 494 || || +--------+ || || 495 || || |Selected|==++ || 496 || || +--------+ || 497 || || || (7) || 498 VV VV VV VV 499 +--------------------------------------+ 500 | Logout | 501 +--------------------------------------+ 502 || 503 VV 504 +----------------+ 505 |close connection| 506 +----------------+ 508 (1) connection without pre-authentication (OK greeting) 509 (2) pre-authenticated connection (PREAUTH greeting) 510 (3) rejected connection (BYE greeting) 511 (4) successful LOGIN or AUTHENTICATE command 512 (5) successful SELECT or EXAMINE command 513 (6) CLOSE command, or failed SELECT or EXAMINE command 514 (7) LOGOUT command, server shutdown, or connection closed 516 4. Data Formats 518 IMAP4rev1 uses textual commands and responses. Data in IMAP4rev1 can 519 be in one of several forms: atom, number, string, parenthesized list, 520 or NIL. 522 4.1. Atom 524 An atom consists of one or more non-special characters. 526 4.2. Number 528 A number consists of one or more digit characters, and represents a 529 numeric value. 531 4.3. String 533 A string is in one of two forms: literal and quoted string. The 534 literal form is the general form of string. The quoted string form 535 is an alternative that avoids the overhead of processing a literal at 536 the cost of limitations of characters that can be used in a quoted 537 string. 539 A literal is a sequence of zero or more octets (including CR and LF), 540 prefix-quoted with an octet count in the form of an open brace ("{"), 541 the number of octets, close brace ("}"), and CRLF. In the case of 542 literals transmitted from server to client, the CRLF is immediately 543 followed by the octet data. In the case of literals transmitted from 544 client to server, the client MUST wait to receive a command 545 continuation request (described later in this document) before 546 sending the octet data (and the remainder of the command). 548 A quoted string is a sequence of zero or more 7-bit characters, 549 excluding CR and LF, with double quote (<">) characters at each end. 551 The empty string is represented as either "" (a quoted string with 552 zero characters between double quotes) or as {0} followed by CRLF (a 553 literal with an octet count of 0). 555 Note: Even if the octet count is 0, a client transmitting a 556 literal MUST wait to receive a command continuation 557 request. 559 4.3.1. 8-bit and Binary Strings 561 8-bit textual and binary mail is supported through the use of a 562 [MIME-IMB] content transfer encoding. IMAP4rev1 implementations MAY 563 transmit 8-bit or multi-octet characters in literals, but SHOULD do 564 so only when the [CHARSET] is identified. 566 Although a BINARY body encoding is defined, unencoded binary strings 567 are not permitted. A "binary string" is any string with NUL 568 characters. Implementations MUST encode binary data into a textual 569 form such as BASE64 before transmitting the data. A string with an 570 excessive amount of CTL characters MAY also be considered to be 571 binary. 573 4.4. Parenthesized List 575 Data structures are represented as a "parenthesized list"; a sequence 576 of data items, delimited by space, and bounded at each end by 577 parentheses. A parenthesized list can contain other parenthesized 578 lists, using multiple levels of parentheses to indicate nesting. 580 The empty list is represented as () -- a parenthesized list with no 581 members. 583 4.5. NIL 585 The special atom "NIL" represents the non-existence of a particular 586 data item that is represented as a string or parenthesized list, as 587 distinct from the empty string "" or the empty parenthesized list (). 589 5. Operational Considerations 591 The following rules are listed here to ensure that all IMAP4rev1 592 implementations interoperate properly. 594 5.1. Mailbox Naming 596 Mailbox names are 7-bit. Client implementations MUST NOT attempt to 597 create 8-bit mailbox names, and SHOULD interpret any 8-bit mailbox 598 names returned by LIST or LSUB as UTF-8. Server implementations 599 SHOULD prohibit the creation of 8-bit mailbox names, and SHOULD NOT 600 return 8-bit mailbox names in LIST or LSUB. See section 5.1.3 for 601 more information on how to represent non-ASCII mailbox names. 603 Note: 8-bit mailbox names were undefined in earlier 604 versions of this protocol. Some sites used a local 8-bit 605 character set to represent non-ASCII mailbox names. Such 606 usage is not interoperable, and is now formally deprecated. 608 The case-insensitive mailbox name INBOX is a special name reserved to 609 mean "the primary mailbox for this user on this server". The 610 interpretation of all other names is implementation-dependent. 612 In particular, this specification takes no position on case 613 sensitivity in non-INBOX mailbox names. Some server implementations 614 are fully case-sensitive; others preserve case of a newly-created 615 name but otherwise are case-insensitive; and yet others coerce names 616 to a particular case. Client implementations MUST interact with any 617 of these. If a server implementation interprets non-INBOX mailbox 618 names as case-insensitive, it MUST treat names using the 619 international naming convention specially as described in section 620 5.1.3. 622 There are certain client considerations when creating a new mailbox 623 name: 625 1) Any character which is an atom-special (see the Formal Syntax) 626 will require that the mailbox name be represented as a quoted 627 string or literal. 629 2) CTL and other non-graphic characters are difficult to represent 630 in a user interface and are best avoided. 632 3) Although the list-wildcard characters ("%" and "*") are valid 633 in a mailbox name, it is difficult to use such mailbox names 634 with the LIST and LSUB commands due to the conflict with 635 wildcard interpretation. 637 4) Usually, a character (determined by the server implementation) 638 is reserved to delimit levels of hierarchy. 640 5) Two characters, "#" and "&", have meanings by convention, and 641 should be avoided except when used in that convention. 643 5.1.1. Mailbox Hierarchy Naming 645 If it is desired to export hierarchical mailbox names, mailbox names 646 MUST be left-to-right hierarchical using a single character to 647 separate levels of hierarchy. The same hierarchy separator character 648 is used for all levels of hierarchy within a single name. 650 5.1.2. Mailbox Namespace Naming Convention 652 By convention, the first hierarchical element of any mailbox name 653 which begins with "#" identifies the "namespace" of the remainder of 654 the name. This makes it possible to disambiguate between different 655 types of mailbox stores, each of which have their own namespaces. 657 For example, implementations which offer access to USENET 658 newsgroups MAY use the "#news" namespace to partition the 659 USENET newsgroup namespace from that of other mailboxes. 660 Thus, the comp.mail.misc newsgroup would have an mailbox 661 name of "#news.comp.mail.misc", and the name 662 "comp.mail.misc" can refer to a different object (e.g. a 663 user's private mailbox). 665 5.1.3. Mailbox International Naming Convention 667 By convention, international mailbox names in IMAP4rev1 are specified 668 using a modified version of the UTF-7 encoding described in [UTF-7]. 669 Modified UTF-7 may also be usable in servers which implement an 670 earlier version of this protocol. 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 and 0x7f-0xff) are 678 represented in modified BASE64, with a further modification from 679 [UTF-7] that "," is used instead of "/". Modified BASE64 MUST NOT be 680 used to represent any printing US-ASCII character which can represent 681 itself. 683 "&" is used to shift to modified BASE64 and "-" to shift back to 684 US-ASCII. There is no implicit shift from BASE64 to US-ASCII, and 685 superfluous shifts ("&-" in ASCII, and "-&" in BASE64) are not 686 permitted. However, all names start in US-ASCII, and MUST end in 687 US-ASCII; that is, a name that ends with a non-ASCII ISO-10646 688 character MUST end with a "-"). 690 Although modified UTF-7 is a convention, it establishes certain 691 requirements on server handling of any mailbox name with an embedded 692 "&" character. In particular, server implementations MUST preserve 693 the exact form of the modified BASE64 portion of a modified UTF-7 694 name and treat that text as case-sensitive, even if names are 695 otherwise case-insensitive or case-folded. 697 Server implementations SHOULD verify that any mailbox name argument 698 to CREATE with an embedded "&" character is in correct modified UTF-7 699 syntax; that there are no superfluous shifts; and that there is no 700 encoding in modified BASE64 of any printing US-ASCII character which 701 can represent itself. However, client implementations MUST NOT 702 depend upon the server doing this; and SHOULD NOT attempt to create a 703 mailbox name with an embedded "&" character unless it complies with 704 modified UTF-7 syntax. 706 Server implementations which export a mail store which does not 707 follow the modified UTF-7 convention MUST convert to modified UTF-7 708 any mailbox name that contains either non-ASCII characters or the "&" 709 character. 711 For example, here is a mailbox name which mixes English, 712 Japanese, and Chinese text: ~peter/mail/&ZeVnLIqe-/&U,BTFw- 714 For example, the string "&Jjo!" is not a valid mailbox name 715 because it does not contain a shift to US-ASCII before the 716 "!". The correct form is "&Jjo-!". The string 717 "&ZeVnLIqe-&U,BTFw-" is not permitted because it contains a 718 superfluous shift. The correct form is "&ZeVnLIqeU,BTFw-". 720 The purpose of these modifications is to correct the following 721 problems with UTF-7: 723 1) UTF-7 uses the "+" character for shifting; this conflicts with 724 the common use of "+" in mailbox names, in particular USENET 725 newsgroup names. 727 2) UTF-7's encoding is BASE64 which uses the "/" character; this 728 conflicts with the use of "/" as a popular hierarchy delimiter. 730 3) UTF-7 prohibits the unencoded usage of "\"; this conflicts with 731 the use of "\" as a popular hierarchy delimiter. 733 4) UTF-7 prohibits the unencoded usage of "~"; this conflicts with 734 the use of "~" in some servers as a home directory indicator. 736 5) UTF-7 permits multiple alternate forms to represent the same 737 string; in particular, printable US-ASCII chararacters can be 738 represented in encoded form. 740 5.2. Mailbox Size and Message Status Updates 742 At any time, a server can send data that the client did not request. 743 Sometimes, such behavior is REQUIRED. For example, agents other than 744 the server MAY add messages to the mailbox (e.g. new message 745 delivery), change the flags of message in the mailbox (e.g. 746 simultaneous access to the same mailbox by multiple agents), or even 747 remove messages from the mailbox. A server MUST send mailbox size 748 updates automatically if a mailbox size change is observed during the 749 processing of a command. A server SHOULD send message flag updates 750 automatically, without requiring the client to request such updates 751 explicitly. 753 Special rules exist for server notification of a client about the 754 removal of messages to prevent synchronization errors; see the 755 description of the EXPUNGE response for more detail. In particular, 756 it is NOT permitted to send an EXISTS response that would reduce the 757 number of messages in the mailbox; only the EXPUNGE response can do 758 this. 760 Regardless of what implementation decisions a client makes on 761 remembering data from the server, a client implementation MUST record 762 mailbox size updates. It MUST NOT assume that any command after 763 initial mailbox selection will return the size of the mailbox. 765 5.3. Response when no Command in Progress 767 Server implementations are permitted to send an untagged response 768 (except for EXPUNGE) while there is no command in progress. Server 769 implementations that send such responses MUST deal with flow control 770 considerations. Specifically, they MUST either (1) verify that the 771 size of the data does not exceed the underlying transport's available 772 window size, or (2) use non-blocking writes. 774 5.4. Autologout Timer 776 If a server has an inactivity autologout timer, that timer MUST be of 777 at least 30 minutes' duration. The receipt of ANY command from the 778 client during that interval SHOULD suffice to reset the autologout 779 timer. 781 5.5. Multiple Commands in Progress 783 The client MAY send another command without waiting for the 784 completion result response of a command, subject to ambiguity rules 785 (see below) and flow control constraints on the underlying data 786 stream. Similarly, a server MAY begin processing another command 787 before processing the current command to completion, subject to 788 ambiguity rules. However, any command continuation request responses 789 and command continuations MUST be negotiated before any subsequent 790 command is initiated. 792 The exception is if an ambiguity would result because of a command 793 that would affect the results of other commands. Clients MUST NOT 794 send multiple commands without waiting if an ambiguity would result. 795 If the server detects a possible ambiguity, it MUST execute commands 796 to completion in the order given by the client. 798 The most obvious example of ambiguity is when a command would affect 799 the results of another command; for example, a FETCH of a message's 800 flags and a STORE of that same message's flags. 802 A non-obvious ambiguity occurs with commands that permit an untagged 803 EXPUNGE response (commands other than FETCH, STORE, and SEARCH), 804 since an untagged EXPUNGE response can invalidate sequence numbers in 805 a subsequent command. This is not a problem for FETCH, STORE, or 806 SEARCH commands because servers are prohibited from sending EXPUNGE 807 responses while any of those commands are in progress. Therefore, if 808 the client sends any command other than FETCH, STORE, or SEARCH, it 809 MUST wait for a response before sending a command with message 810 sequence numbers. 812 Note: UID FETCH, UID STORE, and UID SEARCH are different 813 commands from FETCH, STORE, and SEARCH. If the client 814 sends a UID command, it must wait for a response before 815 sending a command with message sequence numbers. 817 For example, the following non-waiting command sequences are invalid: 819 FETCH + NOOP + STORE 820 STORE + COPY + FETCH 821 COPY + COPY 822 CHECK + FETCH 824 The following are examples of valid non-waiting command sequences: 826 FETCH + STORE + SEARCH + CHECK 827 STORE + COPY + EXPUNGE 829 UID SEARCH + UID SEARCH may be valid or invalid as a non-waiting 830 command sequence, depending upon whether or not the second UID 831 SEARCH contains message sequence numbers. 833 6. Client Commands 835 IMAP4rev1 commands are described in this section. Commands are 836 organized by the state in which the command is permitted. Commands 837 which are permitted in multiple states are listed in the minimum 838 permitted state (for example, commands valid in authenticated and 839 selected state are listed in the authenticated state commands). 841 Command arguments, identified by "Arguments:" in the command 842 descriptions below, are described by function, not by syntax. The 843 precise syntax of command arguments is described in the Formal Syntax 844 section. 846 Some commands cause specific server responses to be returned; these 847 are identified by "Responses:" in the command descriptions below. 848 See the response descriptions in the Responses section for 849 information on these responses, and the Formal Syntax section for the 850 precise syntax of these responses. It is possible for server data to 851 be transmitted as a result of any command; thus, commands that do not 852 specifically require server data specify "no specific responses for 853 this command" instead of "none". 855 The "Result:" in the command description refers to the possible 856 tagged status responses to a command, and any special interpretation 857 of these status responses. 859 6.1. Client Commands - Any State 861 The following commands are valid in any state: CAPABILITY, NOOP, and 862 LOGOUT. 864 6.1.1. CAPABILITY Command 866 Arguments: none 868 Responses: REQUIRED untagged response: CAPABILITY 870 Result: OK - capability completed 871 BAD - command unknown or arguments invalid 873 The CAPABILITY command requests a listing of capabilities that the 874 server supports. The server MUST send a single untagged 875 CAPABILITY response with "IMAP4rev1" as one of the listed 876 capabilities before the (tagged) OK response. This listing of 877 capabilities is not dependent upon connection state or user. It 878 is therefore not necessary to issue a CAPABILITY command more than 879 once in a connection. 881 A capability name which begins with "AUTH=" indicates that the 882 server supports that particular authentication mechanism. All 883 such names are, by definition, part of this specification. For 884 example, the authorization capability for an experimental 885 "blurdybloop" authenticator would be "AUTH=XBLURDYBLOOP" and not 886 "XAUTH=BLURDYBLOOP" or "XAUTH=XBLURDYBLOOP". 888 Other capability names refer to extensions, revisions, or 889 amendments to this specification. See the documentation of the 890 CAPABILITY response for additional information. No capabilities, 891 beyond the base IMAP4rev1 set defined in this specification, are 892 enabled without explicit client action to invoke the capability. 894 See the section entitled "Client Commands - 895 Experimental/Expansion" for information about the form of site or 896 implementation-specific capabilities. 898 Example: C: abcd CAPABILITY 899 S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI 900 S: abcd OK CAPABILITY completed 902 6.1.2. NOOP Command 904 Arguments: none 906 Responses: no specific responses for this command (but see below) 908 Result: OK - noop completed 909 BAD - command unknown or arguments invalid 911 The NOOP command always succeeds. It does nothing. 913 Since any command can return a status update as untagged data, the 914 NOOP command can be used as a periodic poll for new messages or 915 message status updates during a period of inactivity (this is the 916 preferred method to do this). The NOOP command can also be used 917 to reset any inactivity autologout timer on the server. 919 Example: C: a002 NOOP 920 S: a002 OK NOOP completed 921 . . . 922 C: a047 NOOP 923 S: * 22 EXPUNGE 924 S: * 23 EXISTS 925 S: * 3 RECENT 926 S: * 14 FETCH (FLAGS (\Seen \Deleted)) 927 S: a047 OK NOOP completed 929 6.1.3. LOGOUT Command 931 Arguments: none 933 Responses: REQUIRED untagged response: BYE 935 Result: OK - logout completed 936 BAD - command unknown or arguments invalid 938 The LOGOUT command informs the server that the client is done with 939 the connection. The server MUST send a BYE untagged response 940 before the (tagged) OK response, and then close the network 941 connection. 943 Example: C: A023 LOGOUT 944 S: * BYE IMAP4rev1 Server logging out 945 S: A023 OK LOGOUT completed 946 (Server and client then close the connection) 948 6.2. Client Commands - Not Authenticated State 950 In not authenticated state, the AUTHENTICATE or LOGIN command 951 establishes authentication and enter authenticated state. The 952 AUTHENTICATE command provides a general mechanism for a variety of 953 authentication techniques, whereas the LOGIN command uses the 954 traditional user name and plaintext password pair. 956 Server implementations MAY allow not authenticated access to certain 957 mailboxes. The convention is to use a LOGIN command with the userid 958 "anonymous". A password is REQUIRED. It is implementation-dependent 959 what requirements, if any, are placed on the password and what access 960 restrictions are placed on anonymous users. 962 Once authenticated (including as anonymous), it is not possible to 963 re-enter not authenticated state. 965 In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), 966 the following commands are valid in not authenticated state: 967 AUTHENTICATE and LOGIN. 969 6.2.1. AUTHENTICATE Command 971 Arguments: authentication mechanism name 973 Responses: continuation data can be requested 975 Result: OK - authenticate completed, now in authenticated state 976 NO - authenticate failure: unsupported authentication 977 mechanism, credentials rejected 978 BAD - command unknown or arguments invalid, 979 authentication exchange cancelled 981 The AUTHENTICATE command indicates a [SASL] authentication 982 mechanism to the server. If the server supports the requested 983 authentication mechanism, it performs an authentication protocol 984 exchange to authenticate and identify the client. It MAY also 985 negotiate an OPTIONAL security layer for subsequent protocol 986 interactions. If the requested authentication mechanism is not 987 supported, the server SHOULD reject the AUTHENTICATE command by 988 sending a tagged NO response. 990 The AUTHENTICATE command does not support the optional "initial 991 response" feature of SASL. Section 5.1 of [SASL] specifies how to 992 handle an authentication mechanism which uses an initial response. 994 The service name specified by this protocol's profile of [SASL] is 995 "imap". 997 The authentication protocol exchange consists of a series of 998 server challenges and client responses that are specific to the 999 authentication mechanism. A server challenge consists of a 1000 command continuation request response with the "+" token followed 1001 by a BASE64 encoded string. The client response consists of a 1002 single line consisting of a BASE64 encoded string. If the client 1003 wishes to cancel an authentication exchange, it issues a line 1004 consisting of a single "*". If the server receives such an 1005 response, it MUST reject the AUTHENTICATE command by sending a 1006 tagged BAD response. 1008 If a security layer is negotiated through the [SASL] 1009 authentication exchange, it takes effect immediately following the 1010 CRLF that concludes the authentication exchange for the client, 1011 and the CRLF of the tagged OK response for the server. 1013 While a server MUST implement the AUTHENTICATE command itself, the 1014 server is not required to support any authentication mechanisms 1015 and an authentication mechanism is not required to support any 1016 security layers. 1018 Servers and clients can support multiple authentication 1019 mechanisms. The server SHOULD list its supported authentication 1020 mechanisms in the response to the CAPABILITY command so that the 1021 client knows which authentication mechanisms to use. 1023 If an AUTHENTICATE command fails with a NO response, the client 1024 MAY try another authentication mechanism by issuing another 1025 AUTHENTICATE command. It MAY also attempt to authenticate by 1026 using the LOGIN command (see section 6.2.2 for more detail). In 1027 other words, the client MAY request authentication types in 1028 decreasing order of preference, with the LOGIN command as a last 1029 resort. 1031 The authorization identity passed from the client to the server 1032 during the authentication exchange is interpreted by the server as 1033 the user name whose privileges the client is requesting. 1035 Example: S: * OK IMAP4rev1 Server 1036 C: A001 AUTHENTICATE GSSAPI 1037 S: + 1038 C: YIIB+wYJKoZIhvcSAQICAQBuggHqMIIB5qADAgEFoQMCAQ6iBw 1039 MFACAAAACjggEmYYIBIjCCAR6gAwIBBaESGxB1Lndhc2hpbmd0 1040 b24uZWR1oi0wK6ADAgEDoSQwIhsEaW1hcBsac2hpdmFtcy5jYW 1041 Mud2FzaGluZ3Rvbi5lZHWjgdMwgdCgAwIBAaEDAgEDooHDBIHA 1042 cS1GSa5b+fXnPZNmXB9SjL8Ollj2SKyb+3S0iXMljen/jNkpJX 1043 AleKTz6BQPzj8duz8EtoOuNfKgweViyn/9B9bccy1uuAE2HI0y 1044 C/PHXNNU9ZrBziJ8Lm0tTNc98kUpjXnHZhsMcz5Mx2GR6dGknb 1045 I0iaGcRerMUsWOuBmKKKRmVMMdR9T3EZdpqsBd7jZCNMWotjhi 1046 vd5zovQlFqQ2Wjc2+y46vKP/iXxWIuQJuDiisyXF0Y8+5GTpAL 1047 pHDc1/pIGmMIGjoAMCAQGigZsEgZg2on5mSuxoDHEA1w9bcW9n 1048 FdFxDKpdrQhVGVRDIzcCMCTzvUboqb5KjY1NJKJsfjRQiBYBdE 1049 NKfzK+g5DlV8nrw81uOcP8NOQCLR5XkoMHC0Dr/80ziQzbNqhx 1050 O6652Npft0LQwJvenwDI13YxpwOdMXzkWZN/XrEqOWp6GCgXTB 1051 vCyLWLlWnbaUkZdEYbKHBPjd8t/1x5Yg== 1052 S: + YGgGCSqGSIb3EgECAgIAb1kwV6ADAgEFoQMCAQ+iSzBJoAMC 1053 AQGiQgRAtHTEuOP2BXb9sBYFR4SJlDZxmg39IxmRBOhXRKdDA0 1054 uHTCOT9Bq3OsUTXUlk0CsFLoa8j+gvGDlgHuqzWHPSQg== 1055 C: 1056 S: + YDMGCSqGSIb3EgECAgIBAAD/////6jcyG4GE3KkTzBeBiVHe 1057 ceP2CWY0SR0fAQAgAAQEBAQ= 1058 C: YDMGCSqGSIb3EgECAgIBAAD/////3LQBHXTpFfZgrejpLlLImP 1059 wkhbfa2QteAQAgAG1yYwE= 1060 S: A001 OK GSSAPI authentication successful 1062 Note: The line breaks in the first client response are for 1063 editorial clarity and are not in real authenticators. 1065 6.2.2. LOGIN Command 1067 Arguments: user name 1068 password 1070 Responses: no specific responses for this command 1072 Result: OK - login completed, now in authenticated state 1073 NO - login failure: user name or password rejected 1074 BAD - command unknown or arguments invalid 1076 The LOGIN command identifies the client to the server and carries 1077 the plaintext password authenticating this user. 1079 Example: C: a001 LOGIN SMITH SESAME 1080 S: a001 OK LOGIN completed 1082 Note: Use of the LOGIN command over an insecure network 1083 (such as the Internet) is a security risk, because anyone 1084 monitoring network traffic can obtain plaintext passwords. 1085 The LOGIN command SHOULD NOT be used except as a last 1086 resort, and it is recommended that client implementations 1087 have a means to disable any automatic use of the LOGIN 1088 command. 1090 6.3. Client Commands - Authenticated State 1092 In authenticated state, commands that manipulate mailboxes as atomic 1093 entities are permitted. Of these commands, the SELECT and EXAMINE 1094 commands will select a mailbox for access and enter selected state. 1096 In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), 1097 the following commands are valid in authenticated state: SELECT, 1098 EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, 1099 STATUS, and APPEND. 1101 6.3.1. SELECT Command 1103 Arguments: mailbox name 1105 Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT 1106 REQUIRED OK untagged responses: UNSEEN, PERMANENTFLAGS, 1107 UIDNEXT, UIDVALIDITY 1109 Result: OK - select completed, now in selected state 1110 NO - select failure, now in authenticated state: no 1111 such mailbox, can't access mailbox 1112 BAD - command unknown or arguments invalid 1114 The SELECT command selects a mailbox so that messages in the 1115 mailbox can be accessed. Before returning an OK to the client, 1116 the server MUST send the following untagged data to the client: 1118 FLAGS Defined flags in the mailbox. See the description 1119 of the FLAGS response for more detail. 1121 EXISTS The number of messages in the mailbox. See the 1122 description of the EXISTS response for more detail. 1124 RECENT The number of messages with the \Recent flag set. 1125 See the description of the RECENT response for more 1126 detail. 1128 The server SHOULD also send the following untagged data to the 1129 client, and these are REQUIRED in all new server implementations: 1131 OK [UNSEEN ] 1132 The message sequence number of the first unseen 1133 message in the mailbox. If this is missing, the 1134 client can not make any assumptions about the first 1135 unseen message in the mailbox, and needs to issue a 1136 SEARCH command if it wants to find it. 1138 OK [PERMANENTFLAGS ()] 1139 A list of message flags that the client can change 1140 permanently. If this is missing, the client should 1141 assume that all flags can be changed permanently. 1143 OK [UIDNEXT ] 1144 The next unique identifier value. Refer to section 1145 2.3.1.1 for more information. If this is missing, 1146 the client can not make any assumptions about the 1147 next unique identifier value. 1149 OK [UIDVALIDITY ] 1150 The unique identifier validity value. Refer to 1151 section 2.3.1.1 for more information. If this is 1152 missing, the server does not support unique 1153 identifiers. 1155 Only one mailbox can be selected at a time in a connection; 1156 simultaneous access to multiple mailboxes requires multiple 1157 connections. The SELECT command automatically deselects any 1158 currently selected mailbox before attempting the new selection. 1159 Consequently, if a mailbox is selected and a SELECT command that 1160 fails is attempted, no mailbox is selected. 1162 If the client is permitted to modify the mailbox, the server 1163 SHOULD prefix the text of the tagged OK response with the 1164 "[READ-WRITE]" response code. 1166 If the client is not permitted to modify the mailbox but is 1167 permitted read access, the mailbox is selected as read-only, and 1168 the server MUST prefix the text of the tagged OK response to 1169 SELECT with the "[READ-ONLY]" response code. Read-only access 1170 through SELECT differs from the EXAMINE command in that certain 1171 read-only mailboxes MAY permit the change of permanent state on a 1172 per-user (as opposed to global) basis. Netnews messages marked in 1173 a server-based .newsrc file are an example of such per-user 1174 permanent state that can be modified with read-only mailboxes. 1176 Example: C: A142 SELECT INBOX 1177 S: * 172 EXISTS 1178 S: * 1 RECENT 1179 S: * OK [UNSEEN 12] Message 12 is first unseen 1180 S: * OK [UIDVALIDITY 3857529045] UIDs valid 1181 S: * OK [UIDNEXT 4392] Predicted next UID 1182 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 1183 S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited 1184 S: A142 OK [READ-WRITE] SELECT completed 1186 6.3.2. EXAMINE Command 1188 Arguments: mailbox name 1190 Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT 1191 REQUIRED OK untagged responses: UNSEEN, PERMANENTFLAGS, 1192 UIDNEXT, UIDVALIDITY 1194 Result: OK - examine completed, now in selected state 1195 NO - examine failure, now in authenticated state: no 1196 such mailbox, can't access mailbox 1197 BAD - command unknown or arguments invalid 1199 The EXAMINE command is identical to SELECT and returns the same 1200 output; however, the selected mailbox is identified as read-only. 1201 No changes to the permanent state of the mailbox, including 1202 per-user state, are permitted. 1204 The text of the tagged OK response to the EXAMINE command MUST 1205 begin with the "[READ-ONLY]" response code. 1207 Example: C: A932 EXAMINE blurdybloop 1208 S: * 17 EXISTS 1209 S: * 2 RECENT 1210 S: * OK [UNSEEN 8] Message 8 is first unseen 1211 S: * OK [UIDVALIDITY 3857529045] UIDs valid 1212 S: * OK [UIDNEXT 4392] Predicted next UID 1213 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 1214 S: * OK [PERMANENTFLAGS ()] No permanent flags permitted 1215 S: A932 OK [READ-ONLY] EXAMINE completed 1217 6.3.3. CREATE Command 1219 Arguments: mailbox name 1221 Responses: no specific responses for this command 1223 Result: OK - create completed 1224 NO - create failure: can't create mailbox with that name 1225 BAD - command unknown or arguments invalid 1227 The CREATE command creates a mailbox with the given name. An OK 1228 response is returned only if a new mailbox with that name has been 1229 created. It is an error to attempt to create INBOX or a mailbox 1230 with a name that refers to an extant mailbox. Any error in 1231 creation will return a tagged NO response. 1233 If the mailbox name is suffixed with the server's hierarchy 1234 separator character (as returned from the server by a LIST 1235 command), this is a declaration that the client intends to create 1236 mailbox names under this name in the hierarchy. Server 1237 implementations that do not require this declaration MUST ignore 1238 the declaration. In any case, the name that is created is the 1239 name without the trailing hierarchy delimiter. 1241 If the server's hierarchy separator character appears elsewhere in 1242 the name, the server SHOULD create any superior hierarchical names 1243 that are needed for the CREATE command to complete successfully. 1244 In other words, an attempt to create "foo/bar/zap" on a server in 1245 which "/" is the hierarchy separator character SHOULD create foo/ 1246 and foo/bar/ if they do not already exist. 1248 If a new mailbox is created with the same name as a mailbox which 1249 was deleted, its unique identifiers MUST be greater than any 1250 unique identifiers used in the previous incarnation of the mailbox 1251 UNLESS the new incarnation has a different unique identifier 1252 validity value. See the description of the UID command for more 1253 detail. 1255 Example: C: A003 CREATE owatagusiam/ 1256 S: A003 OK CREATE completed 1257 C: A004 CREATE owatagusiam/blurdybloop 1258 S: A004 OK CREATE completed 1260 Note: The interpretation of this example depends on whether 1261 "/" was returned as the hierarchy separator from LIST. If 1262 "/" is the hierarchy separator, a new level of hierarchy 1263 named "owatagusiam" with a member called "blurdybloop" is 1264 created. Otherwise, two mailboxes at the same hierarchy 1265 level are created. 1267 6.3.4. DELETE Command 1269 Arguments: mailbox name 1271 Responses: no specific responses for this command 1273 Result: OK - delete completed 1274 NO - delete failure: can't delete mailbox with that name 1275 BAD - command unknown or arguments invalid 1277 The DELETE command permanently removes the mailbox with the given 1278 name. A tagged OK response is returned only if the mailbox has 1279 been deleted. It is an error to attempt to delete INBOX or a 1280 mailbox name that does not exist. 1282 The DELETE command MUST NOT remove inferior hierarchical names. 1283 For example, if a mailbox "foo" has an inferior "foo.bar" 1284 (assuming "." is the hierarchy delimiter character), removing 1285 "foo" MUST NOT remove "foo.bar". It is an error to attempt to 1286 delete a name that has inferior hierarchical names and also has 1287 the \Noselect mailbox name attribute (see the description of the 1288 LIST response for more details). 1290 It is permitted to delete a name that has inferior hierarchical 1291 names and does not have the \Noselect mailbox name attribute. In 1292 this case, all messages in that mailbox are removed, and the name 1293 will acquire the \Noselect mailbox name attribute. 1295 The value of the highest-used unique identifier of the deleted 1296 mailbox MUST be preserved so that a new mailbox created with the 1297 same name will not reuse the identifiers of the former 1298 incarnation, UNLESS the new incarnation has a different unique 1299 identifier validity value. See the description of the UID command 1300 for more detail. 1302 Examples: C: A682 LIST "" * 1303 S: * LIST () "/" blurdybloop 1304 S: * LIST (\Noselect) "/" foo 1305 S: * LIST () "/" foo/bar 1306 S: A682 OK LIST completed 1307 C: A683 DELETE blurdybloop 1308 S: A683 OK DELETE completed 1309 C: A684 DELETE foo 1310 S: A684 NO Name "foo" has inferior hierarchical names 1311 C: A685 DELETE foo/bar 1312 S: A685 OK DELETE Completed 1313 C: A686 LIST "" * 1314 S: * LIST (\Noselect) "/" foo 1315 S: A686 OK LIST completed 1316 C: A687 DELETE foo 1317 S: A687 OK DELETE Completed 1319 C: A82 LIST "" * 1320 S: * LIST () "." blurdybloop 1321 S: * LIST () "." foo 1322 S: * LIST () "." foo.bar 1323 S: A82 OK LIST completed 1324 C: A83 DELETE blurdybloop 1325 S: A83 OK DELETE completed 1326 C: A84 DELETE foo 1327 S: A84 OK DELETE Completed 1328 C: A85 LIST "" * 1329 S: * LIST () "." foo.bar 1330 S: A85 OK LIST completed 1331 C: A86 LIST "" % 1332 S: * LIST (\Noselect) "." foo 1333 S: A86 OK LIST completed 1335 6.3.5. RENAME Command 1337 Arguments: existing mailbox name 1338 new mailbox name 1340 Responses: no specific responses for this command 1342 Result: OK - rename completed 1343 NO - rename failure: can't rename mailbox with that name, 1344 can't rename to mailbox with that name 1345 BAD - command unknown or arguments invalid 1347 The RENAME command changes the name of a mailbox. A tagged OK 1348 response is returned only if the mailbox has been renamed. It is 1349 an error to attempt to rename from a mailbox name that does not 1350 exist or to a mailbox name that already exists. Any error in 1351 renaming will return a tagged NO response. 1353 If the name has inferior hierarchical names, then the inferior 1354 hierarchical names MUST also be renamed. For example, a rename of 1355 "foo" to "zap" will rename "foo/bar" (assuming "/" is the 1356 hierarchy delimiter character) to "zap/bar". 1358 If the server's hierarchy separator character appears in the name, 1359 the server SHOULD create any superior hierarchical names that are 1360 needed for the RENAME command to complete successfully. In other 1361 words, an attempt to rename "foo/bar/zap" to baz/rag/zowie on a 1362 server in which "/" is the hierarchy separator character SHOULD 1363 create baz/ and baz/rag/ if they do not already exist. 1365 The value of the highest-used unique identifier of the old mailbox 1366 name MUST be preserved so that a new mailbox created with the same 1367 name will not reuse the identifiers of the former incarnation, 1368 UNLESS the new incarnation has a different unique identifier 1369 validity value. See the description of the UID command for more 1370 detail. 1372 Renaming INBOX is permitted, and has special behavior. It moves 1373 all messages in INBOX to a new mailbox with the given name, 1374 leaving INBOX empty. If the server implementation supports 1375 inferior hierarchical names of INBOX, these are unaffected by a 1376 rename of INBOX. 1378 Examples: C: A682 LIST "" * 1379 S: * LIST () "/" blurdybloop 1380 S: * LIST (\Noselect) "/" foo 1381 S: * LIST () "/" foo/bar 1382 S: A682 OK LIST completed 1383 C: A683 RENAME blurdybloop sarasoop 1384 S: A683 OK RENAME completed 1385 C: A684 RENAME foo zowie 1386 S: A684 OK RENAME Completed 1387 C: A685 LIST "" * 1388 S: * LIST () "/" sarasoop 1389 S: * LIST (\Noselect) "/" zowie 1390 S: * LIST () "/" zowie/bar 1391 S: A685 OK LIST completed 1393 C: Z432 LIST "" * 1394 S: * LIST () "." INBOX 1395 S: * LIST () "." INBOX.bar 1396 S: Z432 OK LIST completed 1397 C: Z433 RENAME INBOX old-mail 1398 S: Z433 OK RENAME completed 1399 C: Z434 LIST "" * 1400 S: * LIST () "." INBOX 1401 S: * LIST () "." INBOX.bar 1402 S: * LIST () "." old-mail 1403 S: Z434 OK LIST completed 1405 6.3.6. SUBSCRIBE Command 1407 Arguments: mailbox 1409 Responses: no specific responses for this command 1411 Result: OK - subscribe completed 1412 NO - subscribe failure: can't subscribe to that name 1413 BAD - command unknown or arguments invalid 1415 The SUBSCRIBE command adds the specified mailbox name to the 1416 server's set of "active" or "subscribed" mailboxes as returned by 1417 the LSUB command. This command returns a tagged OK response only 1418 if the subscription is successful. 1420 A server MAY validate the mailbox argument to SUBSCRIBE to verify 1421 that it exists. However, it MUST NOT unilaterally remove an 1422 existing mailbox name from the subscription list even if a mailbox 1423 by that name no longer exists. 1425 Note: This requirement is because a server site can 1426 choose to routinely remove a mailbox with a well-known 1427 name (e.g. "system-alerts") after its contents expire, 1428 with the intention of recreating it when new contents 1429 are appropriate. 1431 Example: C: A002 SUBSCRIBE #news.comp.mail.mime 1432 S: A002 OK SUBSCRIBE completed 1434 6.3.7. UNSUBSCRIBE Command 1436 Arguments: mailbox name 1438 Responses: no specific responses for this command 1440 Result: OK - unsubscribe completed 1441 NO - unsubscribe failure: can't unsubscribe that name 1442 BAD - command unknown or arguments invalid 1444 The UNSUBSCRIBE command removes the specified mailbox name from 1445 the server's set of "active" or "subscribed" mailboxes as returned 1446 by the LSUB command. This command returns a tagged OK response 1447 only if the unsubscription is successful. 1449 Example: C: A002 UNSUBSCRIBE #news.comp.mail.mime 1450 S: A002 OK UNSUBSCRIBE completed 1452 6.3.8. LIST Command 1454 Arguments: reference name 1455 mailbox name with possible wildcards 1457 Responses: untagged responses: LIST 1459 Result: OK - list completed 1460 NO - list failure: can't list that reference or name 1461 BAD - command unknown or arguments invalid 1463 The LIST command returns a subset of names from the complete set 1464 of all names available to the client. Zero or more untagged LIST 1465 replies are returned, containing the name attributes, hierarchy 1466 delimiter, and name; see the description of the LIST reply for 1467 more detail. 1469 The LIST command SHOULD return its data quickly, without undue 1470 delay. For example, it SHOULD NOT go to excess trouble to 1471 calculate \Marked or \Unmarked status or perform other processing; 1472 if each name requires 1 second of processing, then a list of 1200 1473 names would take 20 minutes! 1475 An empty ("" string) reference name argument indicates that the 1476 mailbox name is interpreted as by SELECT. The returned mailbox 1477 names MUST match the supplied mailbox name pattern. A non-empty 1478 reference name argument is the name of a mailbox or a level of 1479 mailbox hierarchy, and indicates a context in which the mailbox 1480 name is interpreted in an implementation-defined manner. 1482 An empty ("" string) mailbox name argument is a special request to 1483 return the hierarchy delimiter and the root name of the name given 1484 in the reference. The value returned as the root MAY be the empty 1485 string if the reference is non-rooted or is the empty string. In 1486 all cases, a hierarchy delimiter (or NIL if there is no hierarchy) 1487 is returned. This permits a client to get the hierarchy delimiter 1488 (or find out that the mailbox names are flat) even when no 1489 mailboxes by that name currently exist. 1491 The reference and mailbox name arguments are interpreted, in an 1492 implementation-dependent fashion, into a canonical form that 1493 represents an unambiguous left-to-right hierarchy. The returned 1494 mailbox names will be in the interpreted form. 1496 Any part of the reference argument that is included in the 1497 interpreted form SHOULD prefix the interpreted form. It SHOULD 1498 also be in the same form as the reference name argument. This 1499 rule permits the client to determine if the returned mailbox name 1500 is in the context of the reference argument, or if something about 1501 the mailbox argument overrode the reference argument. Without 1502 this rule, the client would have to have knowledge of the server's 1503 naming semantics including what characters are "breakouts" that 1504 override a naming context. 1506 For example, here are some examples of how references 1507 and mailbox names might be interpreted on a UNIX-based 1508 server: 1510 Reference Mailbox Name Interpretation 1511 ------------ ------------ -------------- 1512 ~smith/Mail/ foo.* ~smith/Mail/foo.* 1513 archive/ % archive/% 1514 #news. comp.mail.* #news.comp.mail.* 1515 ~smith/Mail/ /usr/doc/foo /usr/doc/foo 1516 archive/ ~fred/Mail/* ~fred/Mail/* 1518 The first three examples demonstrate interpretations in 1519 the context of the reference argument. Note that 1520 "~smith/Mail" SHOULD NOT be transformed into something 1521 like "/u2/users/smith/Mail", or it would be impossible 1522 for the client to determine that the interpretation was 1523 in the context of the reference. 1525 The character "*" is a wildcard, and matches zero or more 1526 characters at this position. The character "%" is similar to "*", 1527 but it does not match a hierarchy delimiter. If the "%" wildcard 1528 is the last character of a mailbox name argument, matching levels 1529 of hierarchy are also returned. If these levels of hierarchy are 1530 not also selectable mailboxes, they are returned with the 1531 \Noselect mailbox name attribute (see the description of the LIST 1532 response for more details). 1534 Server implementations are permitted to "hide" otherwise 1535 accessible mailboxes from the wildcard characters, by preventing 1536 certain characters or names from matching a wildcard in certain 1537 situations. For example, a UNIX-based server might restrict the 1538 interpretation of "*" so that an initial "/" character does not 1539 match. 1541 The special name INBOX is included in the output from LIST, if 1542 INBOX is supported by this server for this user and if the 1543 uppercase string "INBOX" matches the interpreted reference and 1544 mailbox name arguments with wildcards as described above. The 1545 criteria for omitting INBOX is whether SELECT INBOX will return 1546 failure; it is not relevant whether the user's real INBOX resides 1547 on this or some other server. 1549 Example: C: A101 LIST "" "" 1550 S: * LIST (\Noselect) "/" "" 1551 S: A101 OK LIST Completed 1552 C: A102 LIST #news.comp.mail.misc "" 1553 S: * LIST (\Noselect) "." #news. 1555 S: A102 OK LIST Completed 1556 C: A103 LIST /usr/staff/jones "" 1557 S: * LIST (\Noselect) "/" / 1558 S: A103 OK LIST Completed 1559 C: A202 LIST ~/Mail/ % 1560 S: * LIST (\Noselect) "/" ~/Mail/foo 1561 S: * LIST () "/" ~/Mail/meetings 1562 S: A202 OK LIST completed 1564 6.3.9. LSUB Command 1566 Arguments: reference name 1567 mailbox name with possible wildcards 1569 Responses: untagged responses: LSUB 1571 Result: OK - lsub completed 1572 NO - lsub failure: can't list that reference or name 1573 BAD - command unknown or arguments invalid 1575 The LSUB command returns a subset of names from the set of names 1576 that the user has declared as being "active" or "subscribed". 1577 Zero or more untagged LSUB replies are returned. The arguments to 1578 LSUB are in the same form as those for LIST. 1580 The returned untagged LSUB response MAY contain different mailbox 1581 flags from a LIST untagged response. If this should happen, the 1582 flags in the untagged LIST are considered more authoritative. 1584 A server MAY validate the subscribed names to see if they still 1585 exist. If a name does not exist, it SHOULD be flagged with the 1586 \Noselect attribute in the LSUB response. The server MUST NOT 1587 unilaterally remove an existing mailbox name from the subscription 1588 list even if a mailbox by that name no longer exists. 1590 Example: C: A002 LSUB "#news." "comp.mail.*" 1591 S: * LSUB () "." #news.comp.mail.mime 1592 S: * LSUB () "." #news.comp.mail.misc 1593 S: A002 OK LSUB completed 1595 6.3.10. STATUS Command 1597 Arguments: mailbox name 1598 status data item names 1600 Responses: untagged responses: STATUS 1602 Result: OK - status completed 1603 NO - status failure: no status for that name 1604 BAD - command unknown or arguments invalid 1606 The STATUS command requests the status of the indicated mailbox. 1607 It does not change the currently selected mailbox, nor does it 1608 affect the state of any messages in the queried mailbox (in 1609 particular, STATUS MUST NOT cause messages to lose the \Recent 1610 flag). 1612 The STATUS command provides an alternative to opening a second 1613 IMAP4rev1 connection and doing an EXAMINE command on a mailbox to 1614 query that mailbox's status without deselecting the current 1615 mailbox in the first IMAP4rev1 connection. 1617 Unlike the LIST command, the STATUS command is not guaranteed to 1618 be fast in its response. Under certain circumstances, it can be 1619 quite slow. In some implementations, the server is obliged to 1620 open the mailbox read-only internally to obtain certain status 1621 information. Also unlike the LIST command, the STATUS command 1622 does not accept wildcards. 1624 Note: The STATUS command is intended to access 1625 information mailboxes other than the currently selected 1626 mailbox. Because the STATUS command can cause the 1627 mailbox to be opened internally, and because this 1628 information is available by other means on the selected 1629 mailbox, the STATUS command SHOULD NOT be used on the 1630 currently selected mailbox. 1632 The STATUS command MUST NOT be used as a "check for new 1633 messages" operation (refer to section 7, 7.3.1, and 1634 7.3.2 for more information about the proper method for 1635 new message checking). 1637 Because the STATUS command is not guaranteed to be fast 1638 in its results, clients SHOULD NOT expect to be able to 1639 issue many consecutive STATUS commands and obtain 1640 reasonable performance. 1642 The currently defined status data items that can be requested are: 1644 MESSAGES 1645 The number of messages in the mailbox. 1647 RECENT 1648 The number of messages with the \Recent flag set. 1650 UIDNEXT 1651 The next unique identifier value of the mailbox. Refer to 1652 section 2.3.1.1 for more information. 1654 UIDVALIDITY 1655 The unique identifier validity value of the mailbox. Refer to 1656 section 2.3.1.1 for more information. 1658 UNSEEN 1659 The number of messages which do not have the \Seen flag set. 1661 Example: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES) 1662 S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292) 1663 S: A042 OK STATUS completed 1665 6.3.11. APPEND Command 1667 Arguments: mailbox name 1668 OPTIONAL flag parenthesized list 1669 OPTIONAL date/time string 1670 message literal 1672 Responses: no specific responses for this command 1674 Result: OK - append completed 1675 NO - append error: can't append to that mailbox, error 1676 in flags or date/time or message text 1677 BAD - command unknown or arguments invalid 1679 The APPEND command appends the literal argument as a new message 1680 to the end of the specified destination mailbox. This argument 1681 SHOULD be in the format of an [RFC-822] message. 8-bit characters 1682 are permitted in the message. A server implementation that is 1683 unable to preserve 8-bit data properly MUST be able to reversibly 1684 convert 8-bit APPEND data to 7-bit using a [MIME-IMB] content 1685 transfer encoding. 1687 Note: There MAY be exceptions, e.g. draft messages, in 1688 which required [RFC-822] header lines are omitted in the 1689 message literal argument to APPEND. The full 1690 implications of doing so MUST be understood and 1691 carefully weighed. 1693 If a flag parenthesized list is specified, the flags SHOULD be set 1694 in the resulting message; otherwise, the flag list of the 1695 resulting message is set empty by default. 1697 If a date-time is specified, the internal date SHOULD be set in 1698 the resulting message; otherwise, the internal date of the 1699 resulting message is set to the current date and time by default. 1701 If the append is unsuccessful for any reason, the mailbox MUST be 1702 restored to its state before the APPEND attempt; no partial 1703 appending is permitted. 1705 If the destination mailbox does not exist, a server MUST return an 1706 error, and MUST NOT automatically create the mailbox. Unless it 1707 is certain that the destination mailbox can not be created, the 1708 server MUST send the response code "[TRYCREATE]" as the prefix of 1709 the text of the tagged NO response. This gives a hint to the 1710 client that it can attempt a CREATE command and retry the APPEND 1711 if the CREATE is successful. 1713 If the mailbox is currently selected, the normal new message 1714 actions SHOULD occur. Specifically, the server SHOULD notify the 1715 client immediately via an untagged EXISTS response. If the server 1716 does not do so, the client MAY issue a NOOP command (or failing 1717 that, a CHECK command) after one or more APPEND commands. 1719 Example: C: A003 APPEND saved-messages (\Seen) {310} 1720 S: + Ready for literal data 1721 C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) 1722 C: From: Fred Foobar 1723 C: Subject: afternoon meeting 1724 C: To: mooch@owatagu.siam.edu 1725 C: Message-Id: 1726 C: MIME-Version: 1.0 1727 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 1728 C: 1729 C: Hello Joe, do you think we can meet at 3:30 tomorrow? 1730 C: 1731 S: A003 OK APPEND completed 1733 Note: The APPEND command is not used for message delivery, 1734 because it does not provide a mechanism to transfer [SMTP] 1735 envelope information. 1737 6.4. Client Commands - Selected State 1739 In selected state, commands that manipulate messages in a mailbox are 1740 permitted. 1742 In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), 1743 and the authenticated state commands (SELECT, EXAMINE, CREATE, 1744 DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS, and 1745 APPEND), the following commands are valid in the selected state: 1746 CHECK, CLOSE, EXPUNGE, SEARCH, FETCH, STORE, COPY, and UID. 1748 6.4.1. CHECK Command 1750 Arguments: none 1752 Responses: no specific responses for this command 1754 Result: OK - check completed 1755 BAD - command unknown or arguments invalid 1757 The CHECK command requests a checkpoint of the currently selected 1758 mailbox. A checkpoint refers to any implementation-dependent 1759 housekeeping associated with the mailbox (e.g. resolving the 1760 server's in-memory state of the mailbox with the state on its 1761 disk) that is not normally executed as part of each command. A 1762 checkpoint MAY take a non-instantaneous amount of real time to 1763 complete. If a server implementation has no such housekeeping 1764 considerations, CHECK is equivalent to NOOP. 1766 There is no guarantee that an EXISTS untagged response will happen 1767 as a result of CHECK. NOOP, not CHECK, SHOULD be used for new 1768 message polling. 1770 Example: C: FXXZ CHECK 1771 S: FXXZ OK CHECK Completed 1773 6.4.2. CLOSE Command 1775 Arguments: none 1777 Responses: no specific responses for this command 1779 Result: OK - close completed, now in authenticated state 1780 BAD - command unknown or arguments invalid 1782 The CLOSE command permanently removes from the currently selected 1783 mailbox all messages that have the \Deleted flag set, and returns 1784 to authenticated state from selected state. No untagged EXPUNGE 1785 responses are sent. 1787 No messages are removed, and no error is given, if the mailbox is 1788 selected by an EXAMINE command or is otherwise selected read-only. 1790 Even if a mailbox is selected, a SELECT, EXAMINE, or LOGOUT 1791 command MAY be issued without previously issuing a CLOSE command. 1792 The SELECT, EXAMINE, and LOGOUT commands implicitly close the 1793 currently selected mailbox without doing an expunge. However, 1794 when many messages are deleted, a CLOSE-LOGOUT or CLOSE-SELECT 1795 sequence is considerably faster than an EXPUNGE-LOGOUT or 1796 EXPUNGE-SELECT because no untagged EXPUNGE responses (which the 1797 client would probably ignore) are sent. 1799 Example: C: A341 CLOSE 1800 S: A341 OK CLOSE completed 1802 6.4.3. EXPUNGE Command 1804 Arguments: none 1806 Responses: untagged responses: EXPUNGE 1808 Result: OK - expunge completed 1809 NO - expunge failure: can't expunge (e.g. permission 1810 denied) 1811 BAD - command unknown or arguments invalid 1813 The EXPUNGE command permanently removes from the currently 1814 selected mailbox all messages that have the \Deleted flag set. 1815 Before returning an OK to the client, an untagged EXPUNGE response 1816 is sent for each message that is removed. 1818 Example: C: A202 EXPUNGE 1819 S: * 3 EXPUNGE 1820 S: * 3 EXPUNGE 1821 S: * 5 EXPUNGE 1822 S: * 8 EXPUNGE 1823 S: A202 OK EXPUNGE completed 1825 Note: In this example, messages 3, 4, 7, and 11 had the 1826 \Deleted flag set. See the description of the EXPUNGE 1827 response for further explanation. 1829 6.4.4. SEARCH Command 1831 Arguments: OPTIONAL [CHARSET] specification 1832 searching criteria (one or more) 1834 Responses: REQUIRED untagged response: SEARCH 1836 Result: OK - search completed 1837 NO - search error: can't search that [CHARSET] or 1838 criteria 1839 BAD - command unknown or arguments invalid 1841 The SEARCH command searches the mailbox for messages that match 1842 the given searching criteria. Searching criteria consist of one 1843 or more search keys. The untagged SEARCH response from the server 1844 contains a listing of message sequence numbers corresponding to 1845 those messages that match the searching criteria. 1847 When multiple keys are specified, the result is the intersection 1848 (AND function) of all the messages that match those keys. For 1849 example, the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers 1850 to all deleted messages from Smith that were placed in the mailbox 1851 since February 1, 1994. A search key can also be a parenthesized 1852 list of one or more search keys (e.g. for use with the OR and NOT 1853 keys). 1855 Server implementations MAY exclude [MIME-IMB] body parts with 1856 terminal content media types other than TEXT and MESSAGE from 1857 consideration in SEARCH matching. 1859 The OPTIONAL [CHARSET] specification consists of the word 1860 "CHARSET" followed by a registered [CHARSET]. It indicates the 1861 [CHARSET] of the strings that appear in the search criteria. 1862 [MIME-IMB] content transfer encodings, and [MIME-HDRS] strings in 1863 [RFC-822]/[MIME-IMB] headers, MUST be decoded before comparing 1864 text in a [CHARSET] other than US-ASCII. US-ASCII MUST be 1865 supported; other [CHARSET]s MAY be supported. 1867 If the server does not support the specified [CHARSET], it MUST 1868 return a tagged NO response (not a BAD). This response SHOULD 1869 contain the BADCHARSET response code, which MAY list the 1870 [CHARSET]s supported by the server. 1872 In all search keys that use strings, a message matches the key if 1873 the string is a substring of the field. The matching is 1874 case-insensitive. 1876 The defined search keys are as follows. Refer to the Formal 1877 Syntax section for the precise syntactic definitions of the 1878 arguments. 1880 1881 Messages with message sequence numbers corresponding to the 1882 specified message sequence number set 1884 ALL 1885 All messages in the mailbox; the default initial key for 1886 ANDing. 1888 ANSWERED 1889 Messages with the \Answered flag set. 1891 BCC 1892 Messages that contain the specified string in the envelope 1893 structure's BCC field. 1895 BEFORE 1896 Messages whose internal date is earlier than the specified 1897 date. 1899 BODY 1900 Messages that contain the specified string in the body of the 1901 message. 1903 CC 1904 Messages that contain the specified string in the envelope 1905 structure's CC field. 1907 DELETED 1908 Messages with the \Deleted flag set. 1910 DRAFT 1911 Messages with the \Draft flag set. 1913 FLAGGED 1914 Messages with the \Flagged flag set. 1916 FROM 1917 Messages that contain the specified string in the envelope 1918 structure's FROM field. 1920 HEADER 1921 Messages that have a header with the specified field-name (as 1922 defined in [RFC-822]) and that contains the specified string in 1923 the [RFC-822] field-body. 1925 KEYWORD 1926 Messages with the specified keyword set. 1928 LARGER 1929 Messages with an [RFC-822] size larger than the specified 1930 number of octets. 1932 NEW 1933 Messages that have the \Recent flag set but not the \Seen flag. 1934 This is functionally equivalent to "(RECENT UNSEEN)". 1936 NOT 1937 Messages that do not match the specified search key. 1939 OLD 1940 Messages that do not have the \Recent flag set. This is 1941 functionally equivalent to "NOT RECENT" (as opposed to "NOT 1942 NEW"). 1944 ON 1945 Messages whose internal date is within the specified date. 1947 OR 1948 Messages that match either search key. 1950 RECENT 1951 Messages that have the \Recent flag set. 1953 SEEN 1954 Messages that have the \Seen flag set. 1956 SENTBEFORE 1957 Messages whose [RFC-822] Date: header is earlier than the 1958 specified date. 1960 SENTON 1961 Messages whose [RFC-822] Date: header is within the specified 1962 date. 1964 SENTSINCE 1965 Messages whose [RFC-822] Date: header is within or later than 1966 the specified date. 1968 SINCE 1969 Messages whose internal date is within or later than the 1970 specified date. 1972 SMALLER 1973 Messages with an [RFC-822] size smaller than the specified 1974 number of octets. 1976 SUBJECT 1977 Messages that contain the specified string in the envelope 1978 structure's SUBJECT field. 1980 TEXT 1981 Messages that contain the specified string in the header or 1982 body of the message. 1984 TO 1985 Messages that contain the specified string in the envelope 1986 structure's TO field. 1988 UID 1989 Messages with unique identifiers corresponding to the specified 1990 unique identifier set. Message set ranges are permitted. 1992 UNANSWERED 1993 Messages that do not have the \Answered flag set. 1995 UNDELETED 1996 Messages that do not have the \Deleted flag set. 1998 UNDRAFT 1999 Messages that do not have the \Draft flag set. 2001 UNFLAGGED 2002 Messages that do not have the \Flagged flag set. 2004 UNKEYWORD 2005 Messages that do not have the specified keyword set. 2007 UNSEEN 2008 Messages that do not have the \Seen flag set. 2010 Example: C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith" 2011 S: * SEARCH 2 84 882 2012 S: A282 OK SEARCH completed 2013 C: A283 SEARCH TEXT "string not in mailbox" 2014 S: * SEARCH 2015 S: A283 OK SEARCH completed 2017 6.4.5. FETCH Command 2019 Arguments: message set 2020 message data item names 2022 Responses: untagged responses: FETCH 2024 Result: OK - fetch completed 2025 NO - fetch error: can't fetch that data 2026 BAD - command unknown or arguments invalid 2028 The FETCH command retrieves data associated with a message in the 2029 mailbox. The data items to be fetched can be either a single atom 2030 or a parenthesized list. 2032 Most data items, identified in the formal syntax under the 2033 msg-att-static rule, are static and MUST NOT change for any 2034 particular message. Other data items, identified in the formal 2035 syntax under the msg-att-dynamic rule, MAY change, either as a 2036 result of a STORE command or due to external events. 2038 For example, if a client receives an ENVELOPE for a 2039 message when it already knows the envelope, it can 2040 safely ignore the newly transmitted envelope. 2042 The currently defined data items that can be fetched are: 2044 ALL 2045 Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE) 2047 BODY 2048 Non-extensible form of BODYSTRUCTURE. 2050 BODY[
]<> 2051 The text of a particular body section. The section 2052 specification is a set of zero or more part specifiers 2053 delimited by periods. A part specifier is either a part number 2054 or one of the following: HEADER, HEADER.FIELDS, 2055 HEADER.FIELDS.NOT, MIME, and TEXT. An empty section 2056 specification refers to the entire message, including the 2057 header. 2059 Every message has at least one part number. Non-[MIME-IMB] 2060 messages, and non-multipart [MIME-IMB] messages with no 2061 encapsulated message, only have a part 1. 2063 Multipart messages are assigned consecutive part numbers, as 2064 they occur in the message. If a particular part is of type 2065 message or multipart, its parts MUST be indicated by a period 2066 followed by the part number within that nested multipart part. 2068 A part of type MESSAGE/RFC822 also has nested part numbers, 2069 referring to parts of the MESSAGE part's body. 2071 The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, and TEXT part 2072 specifiers can be the sole part specifier or can be prefixed by 2073 one or more numeric part specifiers, provided that the numeric 2074 part specifier refers to a part of type MESSAGE/RFC822. The 2075 MIME part specifier MUST be prefixed by one or more numeric 2076 part specifiers. 2078 The HEADER, HEADER.FIELDS, and HEADER.FIELDS.NOT part 2079 specifiers refer to the [RFC-822] header of the message or of 2080 an encapsulated [MIME-IMT] MESSAGE/RFC822 message. 2081 HEADER.FIELDS and HEADER.FIELDS.NOT are followed by a list of 2082 field-name (as defined in [RFC-822]) names, and return a subset 2083 of the header. The subset returned by HEADER.FIELDS contains 2084 only those header fields with a field-name that matches one of 2085 the names in the list; similarly, the subset returned by 2086 HEADER.FIELDS.NOT contains only the header fields with a 2087 non-matching field-name. The field-matching is 2088 case-insensitive but otherwise exact. In all cases, the 2089 [RFC-822] delimiting blank line between the header and the body 2090 is always included. 2092 The MIME part specifier refers to the [MIME-IMB] header for 2093 this part. 2095 The TEXT part specifier refers to the text body of the message, 2096 omitting the [RFC-822] header. 2098 Here is an example of a complex message with some of its 2099 part specifiers: 2101 HEADER ([RFC-822] header of the message) 2102 TEXT MULTIPART/MIXED 2103 1 TEXT/PLAIN 2104 2 APPLICATION/OCTET-STREAM 2105 3 MESSAGE/RFC822 2106 3.HEADER ([RFC-822] header of the message) 2107 3.TEXT ([RFC-822] text body of the message) 2108 3.1 TEXT/PLAIN 2109 3.2 APPLICATION/OCTET-STREAM 2110 4 MULTIPART/MIXED 2111 4.1 IMAGE/GIF 2112 4.1.MIME ([MIME-IMB] header for the IMAGE/GIF) 2113 4.2 MESSAGE/RFC822 2114 4.2.HEADER ([RFC-822] header of the message) 2115 4.2.TEXT ([RFC-822] text body of the message) 2116 4.2.1 TEXT/PLAIN 2117 4.2.2 MULTIPART/ALTERNATIVE 2118 4.2.2.1 TEXT/PLAIN 2119 4.2.2.2 TEXT/RICHTEXT 2121 It is possible to fetch a substring of the designated text. 2122 This is done by appending an open angle bracket ("<"), the 2123 octet position of the first desired octet, a period, the 2124 maximum number of octets desired, and a close angle bracket 2125 (">") to the part specifier. If the starting octet is beyond 2126 the end of the text, an empty string is returned. 2128 Any partial fetch that attempts to read beyond the end of the 2129 text is truncated as appropriate. A partial fetch that starts 2130 at octet 0 is returned as a partial fetch, even if this 2131 truncation happened. 2133 Note: This means that BODY[]<0.2048> of a 1500-octet message 2134 will return BODY[]<0> with a literal of size 1500, not 2135 BODY[]. 2137 Note: A substring fetch of a HEADER.FIELDS or 2138 HEADER.FIELDS.NOT part specifier is calculated after 2139 subsetting the header. 2141 The \Seen flag is implicitly set; if this causes the flags to 2142 change they SHOULD be included as part of the FETCH responses. 2144 BODY.PEEK[
]<> 2145 An alternate form of BODY[
] that does not implicitly 2146 set the \Seen flag. 2148 BODYSTRUCTURE 2149 The [MIME-IMB] body structure of the message. This is computed 2150 by the server by parsing the [MIME-IMB] header fields in the 2151 [RFC-822] header and [MIME-IMB] headers. 2153 ENVELOPE 2154 The envelope structure of the message. This is computed by the 2155 server by parsing the [RFC-822] header into the component 2156 parts, defaulting various fields as necessary. 2158 FAST 2159 Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE) 2161 FLAGS 2162 The flags that are set for this message. 2164 FULL 2165 Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE 2166 BODY) 2168 INTERNALDATE 2169 The internal date of the message. 2171 RFC822 2172 Functionally equivalent to BODY[], differing in the syntax of 2173 the resulting untagged FETCH data (RFC822 is returned). 2175 RFC822.HEADER 2176 Functionally equivalent to BODY.PEEK[HEADER], differing in the 2177 syntax of the resulting untagged FETCH data (RFC822.HEADER is 2178 returned). 2180 RFC822.SIZE 2181 The [RFC-822] size of the message. 2183 RFC822.TEXT 2184 Functionally equivalent to BODY[TEXT], differing in the syntax 2185 of the resulting untagged FETCH data (RFC822.TEXT is returned). 2187 UID 2188 The unique identifier for the message. 2190 Example: C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)]) 2191 S: * 2 FETCH .... 2192 S: * 3 FETCH .... 2193 S: * 4 FETCH .... 2194 S: A654 OK FETCH completed 2196 6.4.6. STORE Command 2198 Arguments: message set 2199 message data item name 2200 value for message data item 2202 Responses: untagged responses: FETCH 2204 Result: OK - store completed 2205 NO - store error: can't store that data 2206 BAD - command unknown or arguments invalid 2208 The STORE command alters data associated with a message in the 2209 mailbox. Normally, STORE will return the updated value of the 2210 data with an untagged FETCH response. A suffix of ".SILENT" in 2211 the data item name prevents the untagged FETCH, and the server 2212 SHOULD assume that the client has determined the updated value 2213 itself or does not care about the updated value. 2215 Note: Regardless of whether or not the ".SILENT" suffix 2216 was used, the server SHOULD send an untagged FETCH 2217 response if a change to a message's flags from an 2218 external source is observed. The intent is that the 2219 status of the flags is determinate without a race 2220 condition. 2222 The currently defined data items that can be stored are: 2224 FLAGS 2225 Replace the flags for the message with the argument. The new 2226 value of the flags are returned as if a FETCH of those flags 2227 was done. 2229 FLAGS.SILENT 2230 Equivalent to FLAGS, but without returning a new value. 2232 +FLAGS 2233 Add the argument to the flags for the message. The new value 2234 of the flags are returned as if a FETCH of those flags was 2235 done. 2237 +FLAGS.SILENT 2238 Equivalent to +FLAGS, but without returning a new value. 2240 -FLAGS 2241 Remove the argument from the flags for the message. The new 2242 value of the flags are returned as if a FETCH of those flags 2243 was done. 2245 -FLAGS.SILENT 2246 Equivalent to -FLAGS, but without returning a new value. 2248 Example: C: A003 STORE 2:4 +FLAGS (\Deleted) 2249 S: * 2 FETCH (FLAGS (\Deleted \Seen)) 2250 S: * 3 FETCH (FLAGS (\Deleted)) 2251 S: * 4 FETCH (FLAGS (\Deleted \Flagged \Seen)) 2252 S: A003 OK STORE completed 2254 6.4.7. COPY Command 2256 Arguments: message set 2257 mailbox name 2259 Responses: no specific responses for this command 2261 Result: OK - copy completed 2262 NO - copy error: can't copy those messages or to that 2263 name 2264 BAD - command unknown or arguments invalid 2266 The COPY command copies the specified message(s) to the end of the 2267 specified destination mailbox. The flags and internal date of the 2268 message(s) SHOULD be preserved in the copy. 2270 If the destination mailbox does not exist, a server SHOULD return 2271 an error. It SHOULD NOT automatically create the mailbox. Unless 2272 it is certain that the destination mailbox can not be created, the 2273 server MUST send the response code "[TRYCREATE]" as the prefix of 2274 the text of the tagged NO response. This gives a hint to the 2275 client that it can attempt a CREATE command and retry the COPY if 2276 the CREATE is successful. 2278 If the COPY command is unsuccessful for any reason, server 2279 implementations MUST restore the destination mailbox to its state 2280 before the COPY attempt. 2282 Example: C: A003 COPY 2:4 MEETING 2283 S: A003 OK COPY completed 2285 6.4.8. UID Command 2287 Arguments: command name 2288 command arguments 2290 Responses: untagged responses: FETCH, SEARCH 2292 Result: OK - UID command completed 2293 NO - UID command error 2294 BAD - command unknown or arguments invalid 2296 The UID command has two forms. In the first form, it takes as its 2297 arguments a COPY, FETCH, or STORE command with arguments 2298 appropriate for the associated command. However, the numbers in 2299 the message set argument are unique identifiers instead of message 2300 sequence numbers. Message set ranges are permitted, however, 2301 there is no guarantee that unique identifiers be contiguous. 2303 A non-existent unique identifier is ignored without any error 2304 message generated. Thus it is possible for a UID FETCH command to 2305 return OK without any data or a UID COPY or UID STORE to return OK 2306 without performing any operations. 2308 In the second form, the UID command takes a SEARCH command with 2309 SEARCH command arguments. The interpretation of the arguments is 2310 the same as with SEARCH; however, the numbers returned in a SEARCH 2311 response for a UID SEARCH command are unique identifiers instead 2312 of message sequence numbers. For example, the command UID SEARCH 2313 1:100 UID 443:557 returns the unique identifiers corresponding to 2314 the intersection of the message sequence number set 1:100 and the 2315 UID set 443:557. 2317 Note: in the above example, the UID set range 443:557 2318 appears. The same comment about a non-existant unique 2319 identifier being ignored without any error message also 2320 applies here. 2322 The number after the "*" in an untagged FETCH response is always a 2323 message sequence number, not a unique identifier, even for a UID 2324 command response. However, server implementations MUST implicitly 2325 include the UID message data item as part of any FETCH response 2326 caused by a UID command, regardless of whether a UID was specified 2327 as a message data item to the FETCH. 2329 Example: C: A999 UID FETCH 4827313:4828442 FLAGS 2330 S: * 23 FETCH (FLAGS (\Seen) UID 4827313) 2331 S: * 24 FETCH (FLAGS (\Seen) UID 4827943) 2332 S: * 25 FETCH (FLAGS (\Seen) UID 4828442) 2333 S: A999 OK UID FETCH completed 2335 6.5. Client Commands - Experimental/Expansion 2337 6.5.1. X Command 2339 Arguments: implementation defined 2341 Responses: implementation defined 2343 Result: OK - command completed 2344 NO - failure 2345 BAD - command unknown or arguments invalid 2347 Any command prefixed with an X is an experimental command. 2348 Commands which are not part of this specification, a standard or 2349 standards-track revision of this specification, or an 2350 IESG-approved experimental protocol, MUST use the X prefix. 2352 Any added untagged responses issued by an experimental command 2353 MUST also be prefixed with an X. Server implementations MUST NOT 2354 send any such untagged responses, unless the client requested it 2355 by issuing the associated experimental command. 2357 Example: C: a441 CAPABILITY 2358 S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI XPIG-LATIN 2359 S: a441 OK CAPABILITY completed 2360 C: A442 XPIG-LATIN 2361 S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay 2362 S: A442 OK XPIG-LATIN ompleted-cay 2364 7. Server Responses 2366 Server responses are in three forms: status responses, server data, 2367 and command continuation request. The information contained in a 2368 server response, identified by "Contents:" in the response 2369 descriptions below, is described by function, not by syntax. The 2370 precise syntax of server responses is described in the Formal Syntax 2371 section. 2373 The client MUST be prepared to accept any response at all times. 2375 Status responses can be tagged or untagged. Tagged status responses 2376 indicate the completion result (OK, NO, or BAD status) of a client 2377 command, and have a tag matching the command. 2379 Some status responses, and all server data, are untagged. An 2380 untagged response is indicated by the token "*" instead of a tag. 2381 Untagged status responses indicate server greeting, or server status 2382 that does not indicate the completion of a command (for example, an 2383 impending system shutdown alert). For historical reasons, untagged 2384 server data responses are also called "unsolicited data", although 2385 strictly speaking only unilateral server data is truly "unsolicited". 2387 Certain server data MUST be recorded by the client when it is 2388 received; this is noted in the description of that data. Such data 2389 conveys critical information which affects the interpretation of all 2390 subsequent commands and responses (e.g. updates reflecting the 2391 creation or destruction of messages). 2393 Other server data SHOULD be recorded for later reference; if the 2394 client does not need to record the data, or if recording the data has 2395 no obvious purpose (e.g. a SEARCH response when no SEARCH command is 2396 in progress), the data SHOULD be ignored. 2398 An example of unilateral untagged server data occurs when the IMAP 2399 connection is in selected state. In selected state, the server 2400 checks the mailbox for new messages as part of command execution. 2401 Normally, this is part of the execution of every command; hence, a 2402 NOOP command suffices to check for new messages. If new messages are 2403 found, the server sends untagged EXISTS and RECENT responses 2404 reflecting the new size of the mailbox. Server implementations that 2405 offer multiple simultaneous access to the same mailbox SHOULD also 2406 send appropriate unilateral untagged FETCH and EXPUNGE responses if 2407 another agent changes the state of any message flags or expunges any 2408 messages. 2410 Command continuation request responses use the token "+" instead of a 2411 tag. These responses are sent by the server to indicate acceptance 2412 of an incomplete client command and readiness for the remainder of 2413 the command. 2415 7.1. Server Responses - Status Responses 2417 Status responses are OK, NO, BAD, PREAUTH and BYE. OK, NO, and BAD 2418 can be tagged or untagged. PREAUTH and BYE are always untagged. 2420 Status responses MAY include an OPTIONAL "response code". A response 2421 code consists of data inside square brackets in the form of an atom, 2422 possibly followed by a space and arguments. The response code 2423 contains additional information or status codes for client software 2424 beyond the OK/NO/BAD condition, and are defined when there is a 2425 specific action that a client can take based upon the additional 2426 information. 2428 The currently defined response codes are: 2430 ALERT 2432 The human-readable text contains a special alert that MUST be 2433 presented to the user in a fashion that calls the user's 2434 attention to the message. 2436 BADCHARSET 2438 Optionally followed by a parenthesized list of charsets. A 2439 SEARCH failed because the given charset is not supported by 2440 this implementation. If the optional list of charsets is 2441 given, this lists the charsets that are supported by this 2442 implementation. 2444 NEWNAME 2446 Followed by a mailbox name and a new mailbox name. A SELECT or 2447 EXAMINE failed because the target mailbox name (which once 2448 existed) was renamed to the new mailbox name. This is a hint 2449 to the client that the operation can succeed if the SELECT or 2450 EXAMINE is reissued with the new mailbox name. 2452 PARSE 2454 The human-readable text represents an error in parsing the 2455 [RFC-822] header or [MIME-IMB] headers of a message in the 2456 mailbox. 2458 PERMANENTFLAGS 2460 Followed by a parenthesized list of flags, indicates which of 2461 the known flags that the client can change permanently. Any 2462 flags that are in the FLAGS untagged response, but not the 2463 PERMANENTFLAGS list, can not be set permanently. If the client 2464 attempts to STORE a flag that is not in the PERMANENTFLAGS 2465 list, the server will either reject it with a NO reply or store 2466 the state for the remainder of the current session only. The 2467 PERMANENTFLAGS list can also include the special flag \*, which 2468 indicates that it is possible to create new keywords by 2469 attempting to store those flags in the mailbox. 2471 READ-ONLY 2473 The mailbox is selected read-only, or its access while selected 2474 has changed from read-write to read-only. 2476 READ-WRITE 2478 The mailbox is selected read-write, or its access while 2479 selected has changed from read-only to read-write. 2481 TRYCREATE 2483 An APPEND or COPY attempt is failing because the target mailbox 2484 does not exist (as opposed to some other reason). This is a 2485 hint to the client that the operation can succeed if the 2486 mailbox is first created by the CREATE command. 2488 UIDNEXT 2490 Followed by a decimal number, indicates the next unique 2491 identifier value. Refer to section 2.3.1.1 for more 2492 information. 2494 UIDVALIDITY 2496 Followed by a decimal number, indicates the unique identifier 2497 validity value. Refer to section 2.3.1.1 for more information. 2499 UNSEEN 2501 Followed by a decimal number, indicates the number of the first 2502 message without the \Seen flag set. 2504 Additional response codes defined by particular client or server 2505 implementations SHOULD be prefixed with an "X" until they are 2506 added to a revision of this protocol. Client implementations 2507 SHOULD ignore response codes that they do not recognize. 2509 7.1.1. OK Response 2511 Contents: OPTIONAL response code 2512 human-readable text 2514 The OK response indicates an information message from the server. 2515 When tagged, it indicates successful completion of the associated 2516 command. The human-readable text MAY be presented to the user as 2517 an information message. The untagged form indicates an 2518 information-only message; the nature of the information MAY be 2519 indicated by a response code. 2521 The untagged form is also used as one of three possible greetings 2522 at connection startup. It indicates that the connection is not 2523 yet authenticated and that a LOGIN command is needed. 2525 Example: S: * OK IMAP4rev1 server ready 2526 C: A001 LOGIN fred blurdybloop 2527 S: * OK [ALERT] System shutdown in 10 minutes 2528 S: A001 OK LOGIN Completed 2530 7.1.2. NO Response 2532 Contents: OPTIONAL response code 2533 human-readable text 2535 The NO response indicates an operational error message from the 2536 server. When tagged, it indicates unsuccessful completion of the 2537 associated command. The untagged form indicates a warning; the 2538 command can still complete successfully. The human-readable text 2539 describes the condition. 2541 Example: C: A222 COPY 1:2 owatagusiam 2542 S: * NO Disk is 98% full, please delete unnecessary data 2543 S: A222 OK COPY completed 2544 C: A223 COPY 3:200 blurdybloop 2545 S: * NO Disk is 98% full, please delete unnecessary data 2546 S: * NO Disk is 99% full, please delete unnecessary data 2547 S: A223 NO COPY failed: disk is full 2549 7.1.3. BAD Response 2551 Contents: OPTIONAL response code 2552 human-readable text 2554 The BAD response indicates an error message from the server. When 2555 tagged, it reports a protocol-level error in the client's command; 2556 the tag indicates the command that caused the error. The untagged 2557 form indicates a protocol-level error for which the associated 2558 command can not be determined; it can also indicate an internal 2559 server failure. The human-readable text describes the condition. 2561 Example: C: ...very long command line... 2562 S: * BAD Command line too long 2563 C: ...empty line... 2564 S: * BAD Empty command line 2565 C: A443 EXPUNGE 2566 S: * BAD Disk crash, attempting salvage to a new disk! 2567 S: * OK Salvage successful, no data lost 2568 S: A443 OK Expunge completed 2570 7.1.4. PREAUTH Response 2572 Contents: OPTIONAL response code 2573 human-readable text 2575 The PREAUTH response is always untagged, and is one of three 2576 possible greetings at connection startup. It indicates that the 2577 connection has already been authenticated by external means and 2578 thus no LOGIN command is needed. 2580 Example: S: * PREAUTH IMAP4rev1 server logged in as Smith 2582 7.1.5. BYE Response 2584 Contents: OPTIONAL response code 2585 human-readable text 2587 The BYE response is always untagged, and indicates that the server 2588 is about to close the connection. The human-readable text MAY be 2589 displayed to the user in a status report by the client. The BYE 2590 response is sent under one of four conditions: 2592 1) as part of a normal logout sequence. The server will close 2593 the connection after sending the tagged OK response to the 2594 LOGOUT command. 2596 2) as a panic shutdown announcement. The server closes the 2597 connection immediately. 2599 3) as an announcement of an inactivity autologout. The server 2600 closes the connection immediately. 2602 4) as one of three possible greetings at connection startup, 2603 indicating that the server is not willing to accept a 2604 connection from this client. The server closes the 2605 connection immediately. 2607 The difference between a BYE that occurs as part of a normal 2608 LOGOUT sequence (the first case) and a BYE that occurs because of 2609 a failure (the other three cases) is that the connection closes 2610 immediately in the failure case. 2612 Example: S: * BYE Autologout; idle for too long 2614 7.2. Server Responses - Server and Mailbox Status 2616 These responses are always untagged. This is how server and mailbox 2617 status data are transmitted from the server to the client. Many of 2618 these responses typically result from a command with the same name. 2620 7.2.1. CAPABILITY Response 2622 Contents: capability listing 2624 The CAPABILITY response occurs as a result of a CAPABILITY 2625 command. The capability listing contains a space-separated 2626 listing of capability names that the server supports. The 2627 capability listing MUST include the atom "IMAP4rev1". 2629 A capability name which begins with "AUTH=" indicates that the 2630 server supports that particular authentication mechanism. 2632 Other capability names indicate that the server supports an 2633 extension, revision, or amendment to the IMAP4rev1 protocol. 2634 Server responses MUST conform to this document until the client 2635 issues a command that uses the associated capability. 2637 Capability names MUST either begin with "X" or be standard or 2638 standards-track IMAP4rev1 extensions, revisions, or amendments 2639 registered with IANA. A server MUST NOT offer unregistered or 2640 non-standard capability names, unless such names are prefixed with 2641 an "X". 2643 Client implementations SHOULD NOT require any capability name 2644 other than "IMAP4rev1", and MUST ignore any unknown capability 2645 names. 2647 Example: S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI XPIG-LATIN 2649 7.2.2. LIST Response 2651 Contents: name attributes 2652 hierarchy delimiter 2653 name 2655 The LIST response occurs as a result of a LIST command. It 2656 returns a single name that matches the LIST specification. There 2657 can be multiple LIST responses for a single LIST command. 2659 Four name attributes are defined: 2661 \Noinferiors 2663 It is not possible for any child levels of hierarchy to exist 2664 under this name; no child levels exist now and none can be 2665 created in the future. 2667 \Noselect 2669 It is not possible to use this name as a selectable mailbox. 2671 \Marked 2673 The mailbox has been marked "interesting" by the server; the 2674 mailbox probably contains messages that have been added since 2675 the last time the mailbox was selected. 2677 \Unmarked 2679 The mailbox does not contain any additional messages since the 2680 last time the mailbox was selected. 2682 If it is not feasible for the server to determine whether the 2683 mailbox is "interesting" or not, or if the name is a \Noselect 2684 name, the server SHOULD NOT send either \Marked or \Unmarked. 2686 The hierarchy delimiter is a character used to delimit levels of 2687 hierarchy in a mailbox name. A client can use it to create child 2688 mailboxes, and to search higher or lower levels of naming 2689 hierarchy. All children of a top-level hierarchy node MUST use 2690 the same separator character. A NIL hierarchy delimiter means 2691 that no hierarchy exists; the name is a "flat" name. 2693 The name represents an unambiguous left-to-right hierarchy, and 2694 MUST be valid for use as a reference in LIST and LSUB commands. 2695 Unless \Noselect is indicated, the name MUST also be valid as an 2696 argument for commands, such as SELECT, that accept mailbox names. 2698 Example: S: * LIST (\Noselect) "/" ~/Mail/foo 2700 7.2.3. LSUB Response 2702 Contents: name attributes 2703 hierarchy delimiter 2704 name 2706 The LSUB response occurs as a result of an LSUB command. It 2707 returns a single name that matches the LSUB specification. There 2708 can be multiple LSUB responses for a single LSUB command. The 2709 data is identical in format to the LIST response. 2711 Example: S: * LSUB () "." #news.comp.mail.misc 2713 7.2.4 STATUS Response 2715 Contents: name 2716 status parenthesized list 2718 The STATUS response occurs as a result of an STATUS command. It 2719 returns the mailbox name that matches the STATUS specification and 2720 the requested mailbox status information. 2722 Example: S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292) 2724 7.2.5. SEARCH Response 2726 Contents: zero or more numbers 2728 The SEARCH response occurs as a result of a SEARCH or UID SEARCH 2729 command. The number(s) refer to those messages that match the 2730 search criteria. For SEARCH, these are message sequence numbers; 2731 for UID SEARCH, these are unique identifiers. Each number is 2732 delimited by a space. 2734 Example: S: * SEARCH 2 3 6 2736 7.2.6. FLAGS Response 2738 Contents: flag parenthesized list 2740 The FLAGS response occurs as a result of a SELECT or EXAMINE 2741 command. The flag parenthesized list identifies the flags (at a 2742 minimum, the system-defined flags) that are applicable for this 2743 mailbox. Flags other than the system flags can also exist, 2744 depending on server implementation. 2746 The update from the FLAGS response MUST be recorded by the client. 2748 Example: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 2750 7.3. Server Responses - Mailbox Size 2752 These responses are always untagged. This is how changes in the size 2753 of the mailbox are trasnmitted from the server to the client. 2754 Immediately following the "*" token is a number that represents a 2755 message count. 2757 7.3.1. EXISTS Response 2759 Contents: none 2761 The EXISTS response reports the number of messages in the mailbox. 2762 This response occurs as a result of a SELECT or EXAMINE command, 2763 and if the size of the mailbox changes (e.g. new messages). 2765 The update from the EXISTS response MUST be recorded by the 2766 client. 2768 Example: S: * 23 EXISTS 2770 7.3.2. RECENT Response 2772 Contents: none 2774 The RECENT response reports the number of messages with the 2775 \Recent flag set. This response occurs as a result of a SELECT or 2776 EXAMINE command, and if the size of the mailbox changes (e.g. new 2777 messages). 2779 Note: It is not guaranteed that the message sequence 2780 numbers of recent messages will be a contiguous range of 2781 the highest n messages in the mailbox (where n is the 2782 value reported by the RECENT response). Examples of 2783 situations in which this is not the case are: multiple 2784 clients having the same mailbox open (the first session 2785 to be notified will see it as recent, others will 2786 probably see it as non-recent), and when the mailbox is 2787 re-ordered by a non-IMAP agent. 2789 The only reliable way to identify recent messages is to 2790 look at message flags to see which have the \Recent flag 2791 set, or to do a SEARCH RECENT. 2793 The update from the RECENT response MUST be recorded by the 2794 client. 2796 Example: S: * 5 RECENT 2798 7.4. Server Responses - Message Status 2800 These responses are always untagged. This is how message data are 2801 transmitted from the server to the client, often as a result of a 2802 command with the same name. Immediately following the "*" token is a 2803 number that represents a message sequence number. 2805 7.4.1. EXPUNGE Response 2807 Contents: none 2809 The EXPUNGE response reports that the specified message sequence 2810 number has been permanently removed from the mailbox. The message 2811 sequence number for each successive message in the mailbox is 2812 immediately decremented by 1, and this decrement is reflected in 2813 message sequence numbers in subsequent responses (including other 2814 untagged EXPUNGE responses). 2816 As a result of the immediate decrement rule, message sequence 2817 numbers that appear in a set of successive EXPUNGE responses 2818 depend upon whether the messages are removed starting from lower 2819 numbers to higher numbers, or from higher numbers to lower 2820 numbers. For example, if the last 5 messages in a 9-message 2821 mailbox are expunged; a "lower to higher" server will send five 2822 untagged EXPUNGE responses for message sequence number 5, whereas 2823 a "higher to lower server" will send successive untagged EXPUNGE 2824 responses for message sequence numbers 9, 8, 7, 6, and 5. 2826 An EXPUNGE response MUST NOT be sent when no command is in 2827 progress; nor while responding to a FETCH, STORE, or SEARCH 2828 command. This rule is necessary to prevent a loss of 2829 synchronization of message sequence numbers between client and 2830 server. A command is not "in progress" until the complete command 2831 has been received; in particular, a command is not "in progress" 2832 during the negotiation of command continuation. 2834 Note: UID FETCH, UID STORE, and UID SEARCH are different 2835 commands from FETCH, STORE, and SEARCH. An EXPUNGE 2836 response MAY be sent during an UID command. 2838 The update from the EXPUNGE response MUST be recorded by the 2839 client. 2841 Example: S: * 44 EXPUNGE 2843 7.4.2. FETCH Response 2845 Contents: message data 2847 The FETCH response returns data about a message to the client. 2848 The data are pairs of data item names and their values in 2849 parentheses. This response occurs as the result of a FETCH or 2850 STORE command, as well as by unilateral server decision (e.g. flag 2851 updates). 2853 The current data items are: 2855 BODY 2856 A form of BODYSTRUCTURE without extension data. 2858 BODY[
]<> 2859 A string expressing the body contents of the specified section. 2860 The string SHOULD be interpreted by the client according to the 2861 content transfer encoding, body type, and subtype. 2863 If the origin octet is specified, this string is a substring of 2864 the entire body contents, starting at that origin octet. This 2865 means that BODY[]<0> MAY be truncated, but BODY[] is NEVER 2866 truncated. 2868 Note: The origin octet facility MUST NOT be used by a server 2869 in a FETCH response unless the client specifically requested 2870 it by means of a FETCH of a BODY[
]<> data 2871 item. 2873 8-bit textual data is permitted if a [CHARSET] identifier is 2874 part of the body parameter parenthesized list for this section. 2875 Note that headers (part specifiers HEADER or MIME, or the 2876 header portion of a MESSAGE/RFC822 part), MUST be 7-bit; 8-bit 2877 characters are not permitted in headers. Note also that the 2878 [RFC-822] delimiting blank line between the header and the body 2879 is always included as part of header data. 2881 Non-textual data such as binary data MUST be transfer encoded 2882 into a textual form such as BASE64 prior to being sent to the 2883 client. To derive the original binary data, the client MUST 2884 decode the transfer encoded string. 2886 BODYSTRUCTURE 2887 A parenthesized list that describes the [MIME-IMB] body 2888 structure of a message. This is computed by the server by 2889 parsing the [MIME-IMB] header fields, defaulting various fields 2890 as necessary. 2892 For example, a simple text message of 48 lines and 2279 octets 2893 can have a body structure of: ("TEXT" "PLAIN" ("CHARSET" 2894 "US-ASCII") NIL NIL "7BIT" 2279 48) 2896 Multiple parts are indicated by parenthesis nesting. Instead 2897 of a body type as the first element of the parenthesized list 2898 there is a nested body. The second element of the 2899 parenthesized list is the multipart subtype (mixed, digest, 2900 parallel, alternative, etc.). 2902 For example, a two part message consisting of a text and a 2903 BASE64-encoded text attachment can have a body structure of: 2904 (("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 2905 23)("TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" "cc.diff") 2906 "<960723163407.20117h@cac.washington.edu>" "Compiler diff" 2907 "BASE64" 4554 73) "MIXED") 2909 Extension data follows the multipart subtype. Extension data 2910 is never returned with the BODY fetch, but can be returned with 2911 a BODYSTRUCTURE fetch. Extension data, if present, MUST be in 2912 the defined order. 2914 The extension data of a multipart body part are in the 2915 following order: 2917 body parameter parenthesized list 2918 A parenthesized list of attribute/value pairs [e.g. ("foo" 2919 "bar" "baz" "rag") where "bar" is the value of "foo" and 2920 "rag" is the value of "baz"] as defined in [MIME-IMB]. 2922 body disposition 2923 A parenthesized list, consisting of a disposition type 2924 string followed by a parenthesized list of disposition 2925 attribute/value pairs as defined in [DISPOSITION]. 2927 body language 2928 A string or parenthesized list giving the body language 2929 value as defined in [LANGUAGE-TAGS]. 2931 Any following extension data are not yet defined in this 2932 version of the protocol. Such extension data can consist of 2933 zero or more NILs, strings, numbers, or potentially nested 2934 parenthesized lists of such data. Client implementations that 2935 do a BODYSTRUCTURE fetch MUST be prepared to accept such 2936 extension data. Server implementations MUST NOT send such 2937 extension data until it has been defined by a revision of this 2938 protocol. 2940 The basic fields of a non-multipart body part are in the 2941 following order: 2943 body type 2944 A string giving the content media type name as defined in 2945 [MIME-IMB]. 2947 body subtype 2948 A string giving the content subtype name as defined in 2949 [MIME-IMB]. 2951 body parameter parenthesized list 2952 A parenthesized list of attribute/value pairs [e.g. ("foo" 2953 "bar" "baz" "rag") where "bar" is the value of "foo" and 2954 "rag" is the value of "baz"] as defined in [MIME-IMB]. 2956 body id 2957 A string giving the content id as defined in [MIME-IMB]. 2959 body description 2960 A string giving the content description as defined in 2961 [MIME-IMB]. 2963 body encoding 2964 A string giving the content transfer encoding as defined in 2965 [MIME-IMB]. 2967 body size 2968 A number giving the size of the body in octets. Note that 2969 this size is the size in its transfer encoding and not the 2970 resulting size after any decoding. 2972 A body type of type MESSAGE and subtype RFC822 contains, 2973 immediately after the basic fields, the envelope structure, 2974 body structure, and size in text lines of the encapsulated 2975 message. 2977 A body type of type TEXT contains, immediately after the basic 2978 fields, the size of the body in text lines. Note that this 2979 size is the size in its content transfer encoding and not the 2980 resulting size after any decoding. 2982 Extension data follows the basic fields and the type-specific 2983 fields listed above. Extension data is never returned with the 2984 BODY fetch, but can be returned with a BODYSTRUCTURE fetch. 2985 Extension data, if present, MUST be in the defined order. 2987 The extension data of a non-multipart body part are in the 2988 following order: 2990 body MD5 2991 A string giving the body MD5 value as defined in [MD5]. 2993 body disposition 2994 A parenthesized list with the same content and function as 2995 the body disposition for a multipart body part. 2997 body language 2998 A string or parenthesized list giving the body language 2999 value as defined in [LANGUAGE-TAGS]. 3001 Any following extension data are not yet defined in this 3002 version of the protocol, and would be as described above under 3003 multipart extension data. 3005 ENVELOPE 3006 A parenthesized list that describes the envelope structure of a 3007 message. This is computed by the server by parsing the 3008 [RFC-822] header into the component parts, defaulting various 3009 fields as necessary. 3011 The fields of the envelope structure are in the following 3012 order: date, subject, from, sender, reply-to, to, cc, bcc, 3013 in-reply-to, and message-id. The date, subject, in-reply-to, 3014 and message-id fields are strings. The from, sender, reply-to, 3015 to, cc, and bcc fields are parenthesized lists of address 3016 structures. 3018 An address structure is a parenthesized list that describes an 3019 electronic mail address. The fields of an address structure 3020 are in the following order: personal name, [SMTP] 3021 at-domain-list (source route), mailbox name, and host name. 3023 [RFC-822] group syntax is indicated by a special form of 3024 address structure in which the host name field is NIL. If the 3025 mailbox name field is also NIL, this is an end of group marker 3026 (semi-colon in RFC 822 syntax). If the mailbox name field is 3027 non-NIL, this is a start of group marker, and the mailbox name 3028 field holds the group name phrase. 3030 If the Date, Subject, In-Reply-To, and Message-ID header lines 3031 are absent in the [RFC-822] header, the corresponding member of 3032 the envelope is NIL; if these header lines are present but 3033 empty the corresponding member of the envelope is the empty 3034 string. 3036 Note: some servers may return a NIL envelope member in the 3037 "present but empty" case. Clients SHOULD treat NIL and 3038 empty string as identical. 3040 Note: [RFC-822] requires that all messages have a valid Date 3041 header. Therefore, the date member in the envelope can not 3042 be NIL or the empty string. 3044 Note: [RFC-822] requires that the In-Reply-To and Message-ID 3045 headers, if present, have non-empty content. Therefore, the 3046 in-reply-to and message-id members in the envelope can not 3047 be the empty string. 3049 If the From, To, cc, and bcc header lines are absent in the 3050 [RFC-822] header, or are present but empty, the corresponding 3051 member of the envelope is NIL. 3053 If the Sender or Reply-To lines are absent in the [RFC-822] 3054 header, or are present but empty, the server sets the 3055 corresponding member of the envelope to be the same value as 3056 the from member (the client is not expected to know to do 3057 this). 3059 Note: [RFC-822] requires that all messages have a valid From 3060 header. Therefore, the from, sender, and reply-to members 3061 in the envelope can not be NIL. 3063 FLAGS 3064 A parenthesized list of flags that are set for this message. 3066 INTERNALDATE 3067 A string representing the internal date of the message. 3069 RFC822 3070 Equivalent to BODY[]. 3072 RFC822.HEADER 3073 Equivalent to BODY.PEEK[HEADER]. 3075 RFC822.SIZE 3076 A number expressing the [RFC-822] size of the message. 3078 RFC822.TEXT 3079 Equivalent to BODY[TEXT]. 3081 UID 3082 A number expressing the unique identifier of the message. 3084 Example: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827) 3086 7.5. Server Responses - Command Continuation Request 3088 The command continuation request response is indicated by a "+" token 3089 instead of a tag. This form of response indicates that the server is 3090 ready to accept the continuation of a command from the client. The 3091 remainder of this response is a line of text. 3093 This response is used in the AUTHORIZATION command to transmit server 3094 data to the client, and request additional client data. This 3095 response is also used if an argument to any command is a literal. 3097 The client is not permitted to send the octets of the literal unless 3098 the server indicates that it expects it. This permits the server to 3099 process commands and reject errors on a line-by-line basis. The 3100 remainder of the command, including the CRLF that terminates a 3101 command, follows the octets of the literal. If there are any 3102 additional command arguments the literal octets are followed by a 3103 space and those arguments. 3105 Example: C: A001 LOGIN {11} 3106 S: + Ready for additional command text 3107 C: FRED FOOBAR {7} 3108 S: + Ready for additional command text 3109 C: fat man 3110 S: A001 OK LOGIN completed 3111 C: A044 BLURDYBLOOP {102856} 3112 S: A044 BAD No such command as "BLURDYBLOOP" 3114 8. Sample IMAP4rev1 connection 3116 The following is a transcript of an IMAP4rev1 connection. A long 3117 line in this sample is broken for editorial clarity. 3119 S: * OK IMAP4rev1 Service Ready 3120 C: a001 login mrc secret 3121 S: a001 OK LOGIN completed 3122 C: a002 select inbox 3123 S: * 18 EXISTS 3124 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 3125 S: * 2 RECENT 3126 S: * OK [UNSEEN 17] Message 17 is the first unseen message 3127 S: * OK [UIDVALIDITY 3857529045] UIDs valid 3128 S: a002 OK [READ-WRITE] SELECT completed 3129 C: a003 fetch 12 full 3130 S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700" 3131 RFC822.SIZE 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)" 3132 "IMAP4rev1 WG mtg summary and minutes" 3133 (("Terry Gray" NIL "gray" "cac.washington.edu")) 3134 (("Terry Gray" NIL "gray" "cac.washington.edu")) 3135 (("Terry Gray" NIL "gray" "cac.washington.edu")) 3136 ((NIL NIL "imap" "cac.washington.edu")) 3137 ((NIL NIL "minutes" "CNRI.Reston.VA.US") 3138 ("John Klensin" NIL "KLENSIN" "INFOODS.MIT.EDU")) NIL NIL 3139 "") 3140 BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92)) 3141 S: a003 OK FETCH completed 3142 C: a004 fetch 12 body[header] 3143 S: * 12 FETCH (BODY[HEADER] {350} 3144 S: Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT) 3145 S: From: Terry Gray 3146 S: Subject: IMAP4rev1 WG mtg summary and minutes 3147 S: To: imap@cac.washington.edu 3148 S: cc: minutes@CNRI.Reston.VA.US, John Klensin 3149 S: Message-Id: 3150 S: MIME-Version: 1.0 3151 S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 3152 S: 3153 S: ) 3154 S: a004 OK FETCH completed 3155 C: a005 store 12 +flags \deleted 3156 S: * 12 FETCH (FLAGS (\Seen \Deleted)) 3157 S: a005 OK +FLAGS completed 3158 C: a006 logout 3159 S: * BYE IMAP4rev1 server terminating connection 3160 S: a006 OK LOGOUT completed 3162 9. Formal Syntax 3164 The following syntax specification uses the Augmented Backus-Naur 3165 Form (ABNF) notation as specified in [ABNF]. 3167 In the case of alternative or optional rules in which a later rule 3168 overlaps an earlier rule, the rule which is listed earlier MUST take 3169 priority. For example, "\Seen" when parsed as a flag is the \Seen 3170 flag name and not a flag-extension, even though "\Seen" can be parsed 3171 as a flag-extension. Some, but not all, instances of this rule are 3172 noted below. 3174 Note: [ABNF] rules MUST be followed strictly; in 3175 particular: 3177 (1) Except as noted otherwise, all alphabetic characters 3178 are case-insensitive. The use of upper or lower case 3179 characters to define token strings is for editorial clarity 3180 only. Implementations MUST accept these strings in a 3181 case-insensitive fashion. 3183 (2) In all cases, SP refers to exactly one space. It is 3184 NOT permitted to subsitute TAB, insert additional spaces, 3185 or otherwise treat SP as being equivalent to LWSP. 3187 (3) The ASCII NUL character, %x00, MUST NOT be used at any 3188 time. 3190 address = "(" addr-name SP addr-adl SP addr-mailbox SP 3191 addr-host ")" 3193 addr-adl = nstring 3194 ; Holds route from [RFC-822] route-addr if 3195 ; non-NIL 3197 addr-host = nstring 3198 ; NIL indicates [RFC-822] group syntax. 3199 ; Otherwise, holds [RFC-822] domain name 3201 addr-mailbox = nstring 3202 ; NIL indicates end of [RFC-822] group; if 3203 ; non-NIL and addr-host is NIL, holds 3204 ; [RFC-822] group name. 3205 ; Otherwise, holds [RFC-822] local-part 3206 ; after removing [RFC-822] quoting 3208 addr-name = nstring 3209 ; If non-NIL, holds phrase from [RFC-822] 3210 ; mailbox after removing [RFC-822] quoting 3212 append = "APPEND" SP mailbox [SP flag-list] [SP date-time] SP 3213 literal 3215 astring = atom / string 3217 atom = 1*ATOM-CHAR 3219 ATOM-CHAR = 3221 atom-specials = "(" / ")" / "{" / SP / CTL / list-wildcards / 3222 quoted-specials 3224 authenticate = "AUTHENTICATE" SP auth-type *(CRLF base64) 3226 auth-type = atom 3227 ; Defined by [SASL] 3229 base64 = *(4base64-char) [base64-terminal] 3231 base64-char = ALPHA / DIGIT / "+" / "/" 3232 ; Case-sensitive 3234 base64-terminal = (2base64-char "==") / (3base64-char "=") 3236 body = "(" body-type-1part / body-type-mpart ")" 3238 body-extension = nstring / number / 3239 "(" body-extension *(SP body-extension) ")" 3240 ; Future expansion. Client implementations 3241 ; MUST accept body-extension fields. Server 3242 ; implementations MUST NOT generate 3243 ; body-extension fields except as defined by 3244 ; future standard or standards-track 3245 ; revisions of this specification. 3247 body-ext-1part = body-fld-md5 [SP body-fld-dsp [SP body-fld-lang 3248 *(SP body-extension)]] 3249 ; MUST NOT be returned on non-extensible 3250 ; "BODY" fetch 3252 body-ext-mpart = body-fld-param [SP body-fld-dsp [SP body-fld-lang 3253 *(SP body-extension)]] 3254 ; MUST NOT be returned on non-extensible 3255 ; "BODY" fetch 3257 body-fields = body-fld-param SP body-fld-id SP body-fld-desc SP 3258 body-fld-enc SP body-fld-octets 3260 body-fld-desc = nstring 3262 body-fld-dsp = "(" string SP body-fld-param ")" / nil 3264 body-fld-enc = (DQUOTE ("7BIT" / "8BIT" / "BINARY" / "BASE64"/ 3265 "QUOTED-PRINTABLE") DQUOTE) / string 3267 body-fld-id = nstring 3269 body-fld-lang = nstring / "(" string *(SP string) ")" 3271 body-fld-lines = number 3273 body-fld-md5 = nstring 3275 body-fld-octets = number 3277 body-fld-param = "(" string SP string *(SP string SP string) ")" / nil 3279 body-type-1part = (body-type-basic / body-type-msg / body-type-text) 3280 [SP body-ext-1part] 3282 body-type-basic = media-basic SP body-fields 3283 ; MESSAGE subtype MUST NOT be "RFC822" 3285 body-type-mpart = 1*body SP media-subtype 3286 [SP body-ext-mpart] 3288 body-type-msg = media-message SP body-fields SP envelope 3289 SP body SP body-fld-lines 3291 body-type-text = media-text SP body-fields SP body-fld-lines 3293 capability = "AUTH=" auth-type / atom 3294 ; New capabilities MUST begin with "X" or be 3295 ; registered with IANA as standard or 3296 ; standards-track 3298 capability-data = "CAPABILITY" *(SP capability) SP "IMAP4rev1" 3299 *(SP capability) 3300 ; IMAP4rev1 servers which offer RFC 1730 3301 ; compatibility MUST list "IMAP4" as the first 3302 ; capability. 3304 CHAR8 = %x01-ff 3305 ; any OCTET except NUL, %x00 3307 command = tag SP (command-any / command-auth / command-nonauth / 3308 command-select) CRLF 3309 ; Modal based on state 3311 command-any = "CAPABILITY" / "LOGOUT" / "NOOP" / x-command 3312 ; Valid in all states 3314 command-auth = append / create / delete / examine / list / lsub / 3315 rename / select / status / subscribe / unsubscribe 3316 ; Valid only in Authenticated or Selected state 3318 command-nonauth = login / authenticate 3319 ; Valid only when in Not Authenticated state 3321 command-select = "CHECK" / "CLOSE" / "EXPUNGE" / copy / fetch / store / 3322 uid / search 3323 ; Valid only when in Selected state 3325 continue-req = "+" SP (resp-text / base64) CRLF 3327 copy = "COPY" SP set SP mailbox 3329 create = "CREATE" SP mailbox 3330 ; Use of INBOX gives a NO error 3332 date = date-text / DQUOTE date-text DQUOTE 3334 date-day = 1*2DIGIT 3335 ; Day of month 3337 date-day-fixed = (SP DIGIT) / 2DIGIT 3338 ; Fixed-format version of date-day 3340 date-month = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" / 3341 "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec" 3343 date-text = date-day "-" date-month "-" date-year 3345 date-year = 4DIGIT 3347 date-time = DQUOTE date-day-fixed "-" date-month "-" date-year 3348 SP time SP zone DQUOTE 3350 delete = "DELETE" SP mailbox 3351 ; Use of INBOX gives a NO error 3353 digit-nz = %x31-39 3354 ; 1-9 3356 envelope = "(" env-date SP env-subject SP env-from SP env-sender SP 3357 env-reply-to SP env-to SP env-cc SP env-bcc SP 3358 env-in-reply-to SP env-message-id ")" 3360 env-bcc = "(" 1*address ")" / nil 3362 env-cc = "(" 1*address ")" / nil 3364 env-date = nstring 3366 env-from = "(" 1*address ")" / nil 3368 env-in-reply-to = nstring 3370 env-message-id = nstring 3372 env-reply-to = "(" 1*address ")" / nil 3374 env-sender = "(" 1*address ")" / nil 3376 env-subject = nstring 3378 env-to = "(" 1*address ")" / nil 3380 examine = "EXAMINE" SP mailbox 3382 fetch = "FETCH" SP set SP ("ALL" / "FULL" / "FAST" / fetch-att / 3383 "(" fetch-att *(SP fetch-att) ")") 3385 fetch-att = "ENVELOPE" / "FLAGS" / "INTERNALDATE" / 3386 "RFC822" [".HEADER" / ".SIZE" / ".TEXT"] / 3387 "BODY" ["STRUCTURE"] / "UID" / 3388 "BODY" [".PEEK"] section ["<" number "." nz-number ">"] 3390 flag = "\Answered" / "\Flagged" / "\Deleted" / 3391 "\Seen" / "\Draft" / flag-keyword / flag-extension 3392 ; Does not include "\Recent" 3394 flag-extension = "\" atom 3395 ; Future expansion. Client implementations 3396 ; MUST accept flag-extension flags. Server 3397 ; implementations MUST NOT generate 3398 ; flag-extension flags except as defined by 3399 ; future standard or standards-track 3400 ; revisions of this specification. 3402 flag-fetch = flag / "\Recent" 3404 flag-keyword = atom 3406 flag-list = "(" [flag *(SP flag)] ")" 3408 flag-perm = flag / "\*" 3410 greeting = "*" SP (resp-cond-auth / resp-cond-bye) CRLF 3412 header-fld-name = astring 3414 header-list = "(" header-fld-name *(SP header-fld-name) ")" 3416 list = "LIST" SP mailbox SP list-mailbox 3418 list-mailbox = 1*(ATOM-CHAR / list-wildcards) / string 3420 list-wildcards = "%" / "*" 3422 literal = "{" number "}" CRLF *CHAR8 3423 ; Number represents the number of CHAR8s 3425 login = "LOGIN" SP userid SP password 3427 lsub = "LSUB" SP mailbox SP list-mailbox 3429 mailbox = "INBOX" / astring 3430 ; INBOX is case-insensitive. All case variants of 3431 ; INBOX (e.g. "iNbOx") MUST be interpreted as INBOX 3432 ; not as an astring. An astring which consists of 3433 ; the case-insensitive sequence "I" "N" "B" "O" "X" 3434 ; is considered to be INBOX and not an astring. 3435 ; Refer to section 5.1 for further 3436 ; semantic details of mailbox names. 3438 mailbox-data = "FLAGS" SP flag-list / "LIST" SP mailbox-list / 3439 "LSUB" SP mailbox-list / "SEARCH" *(SP nz-number) / 3440 "STATUS" SP mailbox SP "(" 3441 [status-att SP number *(SP status-att SP number)] ")" / 3442 number SP "EXISTS" / number SP "RECENT" 3444 mailbox-list = "(" [mbx-list-flags] ")" SP 3445 (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox 3447 mbx-list-flags = *(mbx-list-oflag SP) mbx-list-sflag 3448 *(SP mbx-list-oflag) / 3449 mbx-list-oflag *(SP mbx-list-oflag) 3451 mbx-list-oflag = "\Noinferiors" / flag-extension 3452 ; Other flags; multiple possible per LIST response 3454 mbx-list-sflag = "\Noselect" / "\Marked" / "\Unmarked" 3455 ; Selectability flags; only one per LIST response 3457 media-basic = ((DQUOTE ("APPLICATION" / "AUDIO" / "IMAGE" / "MESSAGE" / 3458 "VIDEO") DQUOTE) / string) SP media-subtype 3459 ; Defined in [MIME-IMT] 3461 media-message = DQUOTE "MESSAGE" DQUOTE SP DQUOTE "RFC822" DQUOTE 3462 ; Defined in [MIME-IMT] 3464 media-subtype = string 3465 ; Defined in [MIME-IMT] 3467 media-text = DQUOTE "TEXT" DQUOTE SP media-subtype 3468 ; Defined in [MIME-IMT] 3470 message-data = nz-number SP ("EXPUNGE" / ("FETCH" SP msg-att)) 3472 msg-att = "(" (msg-att-dynamic / msg-att-static) 3473 *(SP (msg-att-dynamic / msg-att-static)) ")" 3475 msg-att-dynamic = "FLAGS" SP "(" [flag-fetch *(SP flag-fetch)] ")" 3476 ; MAY change for a message 3478 msg-att-static = "ENVELOPE" SP envelope / "INTERNALDATE" SP date-time / 3479 "RFC822" [".HEADER" / ".TEXT"] SP nstring / 3480 "RFC822.SIZE" SP number / "BODY" ["STRUCTURE"] SP body / 3481 "BODY" section ["<" number ">"] SP nstring / 3482 "UID" SP uniqueid 3483 ; MUST NOT change for a message 3485 nil = "NIL" 3487 nstring = string / nil 3489 number = 1*DIGIT 3490 ; Unsigned 32-bit integer 3491 ; (0 <= n < 4,294,967,296) 3493 nz-number = digit-nz *DIGIT 3494 ; Non-zero unsigned 32-bit integer 3495 ; (0 < n < 4,294,967,296) 3497 password = astring 3498 quoted = DQUOTE *QUOTED-CHAR DQUOTE 3500 QUOTED-CHAR = / 3501 "\" quoted-specials 3503 quoted-specials = DQUOTE / "\" 3505 rename = "RENAME" SP mailbox SP mailbox 3506 ; Use of INBOX as a destination gives a NO error 3508 response = *(continue-req / response-data) response-done 3510 response-data = "*" SP (resp-cond-state / resp-cond-bye / 3511 mailbox-data / message-data / capability-data) CRLF 3513 response-done = response-tagged / response-fatal 3515 response-fatal = "*" SP resp-cond-bye CRLF 3516 ; Server closes connection immediately 3518 response-tagged = tag SP resp-cond-state CRLF 3520 resp-cond-auth = ("OK" / "PREAUTH") SP resp-text 3521 ; Authentication condition 3523 resp-cond-bye = "BYE" SP resp-text 3525 resp-cond-state = ("OK" / "NO" / "BAD") SP resp-text 3526 ; Status condition 3528 resp-text = ["[" resp-text-code "]" SP] text 3530 resp-text-atom = 1* 3532 resp-text-code = "ALERT" / 3533 "BADCHARSET [SP "(" astring *(SP astring) ")" ] / 3534 "NEWNAME" SP string SP string / "PARSE" / 3535 "PERMANENTFLAGS" SP "(" [flag-perm *(SP flag-perm)] ")" / 3536 "READ-ONLY" / "READ-WRITE" / "TRYCREATE" / 3537 "UIDNEXT" SP nz-number / "UIDVALIDITY" SP nz-number / 3538 "UNSEEN" SP nz-number / 3539 resp-text-atom [SP 1*] 3541 search = "SEARCH" SP ["CHARSET" SP astring] search-key 3542 *(SP search-key) 3543 ; CHARSET argument to MUST be registered with IANA 3545 search-key = "ALL" / "ANSWERED" / "BCC" SP astring / 3546 "BEFORE" SP date / "BODY" SP astring / 3547 "CC" SP astring / "DELETED" / "FLAGGED" / 3548 "FROM" SP astring / "KEYWORD" SP flag-keyword / "NEW" / 3549 "OLD" / "ON" SP date / "RECENT" / "SEEN" / 3550 "SINCE" SP date / "SUBJECT" SP astring / 3551 "TEXT" SP astring / "TO" SP astring / 3552 "UNANSWERED" / "UNDELETED" / "UNFLAGGED" / 3553 "UNKEYWORD" SP flag-keyword / "UNSEEN" / 3554 ; Above this line were in [IMAP2] 3555 "DRAFT" / "HEADER" SP header-fld-name SP astring / 3556 "LARGER" SP number / "NOT" SP search-key / 3557 "OR" SP search-key SP search-key / 3558 "SENTBEFORE" SP date / "SENTON" SP date / 3559 "SENTSINCE" SP date / "SMALLER" SP number / 3560 "UID" SP set / "UNDRAFT" / set / 3561 "(" search-key *(SP search-key) ")" 3563 section = "[" [section-spec] "]" 3565 section-msgtext = "HEADER" / "HEADER.FIELDS" [".NOT"] SP header-list / 3566 "TEXT" 3567 ; top-level or MESSAGE/RFC822 part 3569 section-part = nz-number *("." nz-number) 3570 ; body part nesting 3572 section-spec = section-msgtext / (section-part ["." section-text]) 3574 section-text = section-msgtext / "MIME" 3575 ; text other than actual body part (headers, etc.) 3577 select = "SELECT" SP mailbox 3579 sequence-num = nz-number / "*" 3580 ; * is the largest number in use. For message 3581 ; sequence numbers, it is the number of messages 3582 ; in the mailbox. For unique identifiers, it is 3583 ; the unique identifier of the last message in 3584 ; the mailbox. 3586 set = sequence-num / (sequence-num ":" sequence-num) / 3587 (set "," set) 3588 ; Identifies a set of messages. For message 3589 ; sequence numbers, these are consecutive 3590 ; numbers from 1 to the number of messages in 3591 ; the mailbox 3592 ; Comma delimits individual numbers, colon 3593 ; delimits between two numbers inclusive. 3594 ; Example: 2,4:7,9,12:* is 2,4,5,6,7,9,12,13, 3595 ; 14,15 for a mailbox with 15 messages. 3597 status = "STATUS" SP mailbox SP "(" status-att *(SP status-att) ")" 3599 status-att = "MESSAGES" / "RECENT" / "UIDNEXT" / "UIDVALIDITY" / 3600 "UNSEEN" 3602 store = "STORE" SP set SP store-att-flags 3604 store-att-flags = (["+" / "-"] "FLAGS" [".SILENT"]) SP 3605 (flag-list / (flag *(SP flag))) 3607 string = quoted / literal 3609 subscribe = "SUBSCRIBE" SP mailbox 3611 tag = 1* 3613 text = 1*TEXT-CHAR 3615 TEXT-CHAR = 3617 time = 2DIGIT ":" 2DIGIT ":" 2DIGIT 3618 ; Hours minutes seconds 3620 uid = "UID" SP (copy / fetch / search / store) 3621 ; Unique identifiers used instead of message 3622 ; sequence numbers 3624 uniqueid = nz-number 3625 ; Strictly ascending 3627 unsubscribe = "UNSUBSCRIBE" SP mailbox 3629 userid = astring 3631 x-command = "X" atom 3632 zone = ("+" / "-") 4DIGIT 3633 ; Signed four-digit value of hhmm representing 3634 ; hours and minutes west of Greenwich (that is, 3635 ; (the amount that the given time differs from 3636 ; Universal Time). Subtracting the timezone 3637 ; from the given time will give the UT form. 3638 ; The Universal Time zone is "+0000". 3640 10. Author's Note 3642 This document is a revision or rewrite of earlier documents, and 3643 supercedes the protocol specification in those documents: RFC 2060, 3644 RFC 1730, unpublished IMAP2bis.TXT document, RFC 1176, and RFC 1064. 3646 11. Security Considerations 3648 IMAP4rev1 protocol transactions, including electronic mail data, are 3649 sent in the clear over the network unless privacy protection is 3650 negotiated in the AUTHENTICATE command. 3652 A server error message for an AUTHENTICATE command which fails due to 3653 invalid credentials SHOULD NOT detail why the credentials are 3654 invalid. 3656 Use of the LOGIN command sends passwords in the clear. This can be 3657 avoided by using the AUTHENTICATE command instead. 3659 A server error message for a failing LOGIN command SHOULD NOT specify 3660 that the user name, as opposed to the password, is invalid. 3662 Additional security considerations are discussed in the section 3663 discussing the AUTHENTICATE and LOGIN commands. 3665 12. Author's Address 3667 Mark R. Crispin 3668 Networks and Distributed Computing 3669 University of Washington 3670 4545 15th Aveneue NE 3671 Seattle, WA 98105-4527 3673 Phone: (206) 543-5762 3675 EMail: MRC@CAC.Washington.EDU 3677 Appendices 3679 A. References 3681 [ABNF] Crocker, D., and Overwll, P. "Augmented BNF for Syntax 3682 Specifications: ABNF", RFC 2234, November 1997. 3684 [ACAP] Newman, C., and Myers, J. "ACAP -- Application Configuration 3685 Access Protocol", RFC 2244, November 1997. 3687 [CHARSET] Freed, N., and Postel, J. "IANA Character Set Registration 3688 Procedures", Work in Progress. 3690 [DISPOSITION] Troost, R., Dorner, S., and Moore, K., "Communicating 3691 Presentation Information in Internet Messages: The 3692 Content-Disposition Header", RFC 2183, August 1997. 3694 [IMAP-COMPAT] Crispin, M., "IMAP4 Compatibility with IMAP2bis", RFC 3695 2061, December 1996. 3697 [IMAP-DISC] Austein, R., "Synchronization Operations for Disconnected 3698 IMAP4 Clients", Work in Progress. 3700 [IMAP-HISTORICAL] Crispin, M. "IMAP4 Compatibility with IMAP2 and 3701 IMAP2bis", RFC 1732, December 1994. 3703 [IMAP-MODEL] Crispin, M., "Distributed Electronic Mail Models in 3704 IMAP4", RFC 1733, December 1994. 3706 [IMAP-OBSOLETE] Crispin, M., "Internet Message Access Protocol - 3707 Obsolete Syntax", RFC 2062, December 1996. 3709 [IMAP2] Crispin, M., "Interactive Mail Access Protocol - Version 2", 3710 RFC 1176, August 1990. 3712 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 3713 Requirement Levels", RFC 2119, Harvard University, March 1997. 3715 [LANGUAGE-TAGS] Alvestrand, H., "Tags for the Identification of 3716 Languages", RFC 1766, March 1995. 3718 [MD5] Myers, J., and Rose, M., "The Content-MD5 Header Field", RFC 3719 1864, October 1995. 3721 [MIME-IMB] Freed, N., and Borenstein, N.., "MIME (Multipurpose 3722 Internet Mail Extensions) Part One: Format of Internet Message 3723 Bodies", RFC 2045, November 1996. 3725 [MIME-IMT] Freed, N., and Borenstein, N.., "MIME (Multipurpose 3726 Internet Mail Extensions) Part Two: Media Types", RFC 2046, November 3727 1996. 3729 [MIME-HDRS] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 3730 Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 3731 November 1996. 3733 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text 3734 Messages", STD 11, RFC 822, August 1982. 3736 [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", 3737 RFC 2222, October 1997. 3739 [SMTP] Postel, J. "Simple Mail Transfer Protocol", STD 10, RFC 821, 3740 August 1982. 3742 [UTF-7] Goldsmith, D., and Davis, M., "UTF-7: A Mail-Safe 3743 Transformation Format of Unicode", RFC 2152, May 1997. 3745 B. Changes from RFC 2060 3747 1) Clarify description of unique identifiers and their semantics. 3749 2) Indicate UIDVALIDITY needed in the SELECT and EXAMINE responses. 3751 3) Added an example of a failing search 3753 4) Correct store-att-flags: "#flag" should be "1#flag". 3755 5) Made search and section rules clearer. 3757 6) Correct the STORE example. 3759 7) Correct "BASE645" misspelling. 3761 8) Remove extraneous close parenthesis in example of two-part message 3762 with text and BASE64 attachment. 3764 9) Remove obsolete "MAILBOX" response from mailbox-data. 3766 10) A spurious "<" in the rule for mailbox-data was removed. 3768 11) Add CRLF to continue-req. 3770 12) Specifically exclude "]" from the atom in resp-text-code. 3772 13) Clarify that clients and servers should adhere to the protocol 3773 syntax strictly. 3775 14) Emphasize in 5.2 that EXISTS can not be used to shrink a mailbox. 3777 15) Add NEWNAME to resp-text-code. 3779 16) Clarify that the empty string, not NIL, is used as arguments to 3780 LIST. 3782 17) Clarify that NIL can be returned as a hierarchy delimiter for the 3783 empty string mailbox name argument if the mailbox namespace is flat. 3785 18) Clarify that addr-mailbox and addr-mailbox have RFC-822 quoting 3786 removed. 3788 19) Update UTF-7 reference. 3790 20) Fix example in 6.3.11. 3792 21) Clarify that non-existant UIDs are ignored. 3794 22) Update DISPOSITION reference. 3796 23) Expand state diagram. 3798 24) Clarify that partial fetch responses is only returned in response 3799 to a partial fetch command. 3801 25) Add UIDNEXT response code. Correct UIDVALIDITY definition 3802 reference. 3804 26) Further clarification of "can" vs. "MAY". 3806 27) Reference RFC-2119. 3808 28) Clarify that superfluous shifts are not permitted in modified 3809 UTF-7. 3811 29) Clarify that there are no implicit shifts in modified UTF-7. 3813 30) Clarify that "INBOX" in a mailbox name is always INBOX, even if 3814 it is given as an string. 3816 31) Add missing open parenthesis in media-basic grammar rule. 3818 32) Correct attribute syntax in mailbox-data. 3820 33) Add UIDNEXT to EXAMINE responses 3822 34) Clarify UNSEEN, PERMANENTFLAGS, UIDVALIDITY, and UIDNEXT 3823 responses in SELECT and EXAMINE. They are required now, but weren't 3824 in older versions. 3826 35) Update references with RFC numbers. 3828 36) Flush text-mime2. 3830 37) Clarify that modified UTF-7 names must be case-sensitive and that 3831 violating the convention should be avoided. 3833 38) Correct UID FETCH example. 3835 39) Clarify UID FETCH, UID STORE, and UID SEARCH vs. untagged EXPUNGE 3836 responses. 3838 40) Clarify the use of the word "convention". 3840 41) Clarify that a command is not "in progress" until it has been 3841 fully received (specifically, that a command is not "in progress" 3842 during command continuation negotiation). 3844 42) Clarify envelope defaulting. 3846 43) Clarify that SPACE means one and only one space character. 3848 44) Forbid silly states in LIST reponse. 3850 45) Clarify that the ENVELOPE, INTERNALDATE, RFC822*, BODY*, and UID 3851 for a message is static. 3853 46) Add BADCHARSET response code. 3855 47) Update formal syntax to [ABNF] conventions. 3857 48) Clarify trailing hierarchy delimiter in CREATE semantics. 3859 49) Clarify that the "blank line" is the [RFC-822] delimiting blank 3860 line. 3862 50) Clarify that RENAME should also create hierarchy as needed for 3863 the command to complete. 3865 51) Fix body-ext-mpart to not require language if disposition 3866 present. 3868 C. Key Word Index 3870 +FLAGS (store command data item) ............... 50 3871 +FLAGS.SILENT (store command data item) ........ 50 3872 -FLAGS (store command data item) ............... 50 3873 -FLAGS.SILENT (store command data item) ........ 51 3874 ALERT (response code) ...................................... 55 3875 ALL (fetch item) ........................................... 46 3876 ALL (search key) ........................................... 43 3877 ANSWERED (search key) ...................................... 43 3878 APPEND (command) ........................................... 38 3879 AUTHENTICATE (command) ..................................... 22 3880 BAD (response) ............................................. 58 3881 BADCHARSET (response code) ................................. 55 3882 BCC (search key) .................................. 43 3883 BEFORE (search key) ................................. 43 3884 BODY (fetch item) .......................................... 46 3885 BODY (fetch result) ........................................ 64 3886 BODY (search key) ................................. 43 3887 BODY.PEEK[
]<> (fetch item) ............... 48 3888 BODYSTRUCTURE (fetch item) ................................. 48 3889 BODYSTRUCTURE (fetch result) ............................... 65 3890 BODY[
]<> (fetch result) ............. 64 3891 BODY[
]<> (fetch item) .................... 46 3892 BYE (response) ............................................. 58 3893 Body Structure (message attribute) ......................... 9 3894 CAPABILITY (command) ....................................... 20 3895 CAPABILITY (response) ...................................... 59 3896 CC (search key) ................................... 43 3897 CHECK (command) ............................................ 40 3898 CLOSE (command) ............................................ 40 3899 COPY (command) ............................................. 51 3900 CREATE (command) ........................................... 28 3901 DELETE (command) ........................................... 29 3902 DELETED (search key) ....................................... 43 3903 DRAFT (search key) ......................................... 43 3904 ENVELOPE (fetch item) ...................................... 48 3905 ENVELOPE (fetch result) .................................... 67 3906 EXAMINE (command) .......................................... 27 3907 EXISTS (response) .......................................... 62 3908 EXPUNGE (command) .......................................... 41 3909 EXPUNGE (response) ......................................... 63 3910 Envelope Structure (message attribute) ..................... 9 3911 FAST (fetch item) .......................................... 48 3912 FETCH (command) ............................................ 46 3913 FETCH (response) ........................................... 64 3914 FLAGGED (search key) ....................................... 43 3915 FLAGS (fetch item) ......................................... 49 3916 FLAGS (fetch result) ....................................... 69 3917 FLAGS (response) ........................................... 62 3918 FLAGS (store command data item) ................ 50 3919 FLAGS.SILENT (store command data item) ......... 50 3920 FROM (search key) ................................. 43 3921 FULL (fetch item) .......................................... 49 3922 Flags (message attribute) .................................. 7 3923 HEADER (part specifier) .................................... 47 3924 HEADER (search key) .................. 43 3925 HEADER.FIELDS (part specifier) ............... 47 3926 HEADER.FIELDS.NOT (part specifier) ........... 47 3927 INTERNALDATE (fetch item) .................................. 49 3928 INTERNALDATE (fetch result) ................................ 69 3929 Internal Date (message attribute) .......................... 8 3930 KEYWORD (search key) ................................ 44 3931 Keyword (type of flag) ..................................... 8 3932 LARGER (search key) .................................... 44 3933 LIST (command) ............................................. 33 3934 LIST (response) ............................................ 60 3935 LOGIN (command) ............................................ 25 3936 LOGOUT (command) ........................................... 22 3937 LSUB (command) ............................................. 36 3938 LSUB (response) ............................................ 61 3939 MAY (specification requirement term) ....................... 1 3940 MESSAGES (status item) ..................................... 38 3941 MIME (part specifier) ...................................... 47 3942 MUST (specification requirement term) ...................... 1 3943 MUST NOT (specification requirement term) .................. 1 3944 Message Sequence Number (message attribute) ................ 7 3945 NEW (search key) ........................................... 44 3946 NEWNAME (response code) .................................... 55 3947 NO (response) .............................................. 57 3948 NOOP (command) ............................................. 21 3949 NOT (search key) .............................. 44 3950 OK (response) .............................................. 57 3951 OLD (search key) ........................................... 44 3952 ON (search key) ..................................... 44 3953 OPTIONAL (specification requirement term) .................. 1 3954 OR (search key) ................ 44 3955 PARSE (response code) ...................................... 55 3956 PERMANENTFLAGS (response code) ............................. 56 3957 PREAUTH (response) ......................................... 58 3958 Permanent Flag (class of flag) ............................. 8 3959 READ-ONLY (response code) .................................. 56 3960 READ-WRITE (response code) ................................. 56 3961 RECENT (response) .......................................... 62 3962 RECENT (search key) ........................................ 44 3963 RECENT (status item) ....................................... 38 3964 RENAME (command) ........................................... 31 3965 REQUIRED (specification requirement term) .................. 1 3966 RFC822 (fetch item) ........................................ 49 3967 RFC822 (fetch result) ...................................... 69 3968 RFC822.HEADER (fetch item) ................................. 49 3969 RFC822.HEADER (fetch result) ............................... 69 3970 RFC822.SIZE (fetch item) ................................... 49 3971 RFC822.SIZE (fetch result) ................................. 69 3972 RFC822.TEXT (fetch item) ................................... 49 3973 RFC822.TEXT (fetch result) ................................. 69 3974 SEARCH (command) ........................................... 41 3975 SEARCH (response) .......................................... 61 3976 SEEN (search key) .......................................... 44 3977 SELECT (command) ........................................... 25 3978 SENTBEFORE (search key) ............................. 44 3979 SENTON (search key) ................................. 44 3980 SENTSINCE (search key) .............................. 44 3981 SHOULD (specification requirement term) .................... 1 3982 SHOULD NOT (specification requirement term) ................ 1 3983 SINCE (search key) .................................. 44 3984 SMALLER (search key) ................................... 45 3985 STATUS (command) ........................................... 36 3986 STATUS (response) .......................................... 61 3987 STORE (command) ............................................ 49 3988 SUBJECT (search key) .............................. 45 3989 SUBSCRIBE (command) ........................................ 32 3990 Session Flag (class of flag) ............................... 8 3991 System Flag (type of flag) ................................. 7 3992 TEXT (part specifier) ...................................... 47 3993 TEXT (search key) ................................. 45 3994 TO (search key) ................................... 45 3995 TRYCREATE (response code) .................................. 56 3996 UID (command) .............................................. 51 3997 UID (fetch item) ........................................... 49 3998 UID (fetch result) ......................................... 69 3999 UID (search key) ............................. 45 4000 UIDNEXT (response code) .................................... 56 4001 UIDNEXT (status item) ...................................... 38 4002 UIDVALIDITY (response code) ................................ 56 4003 UIDVALIDITY (status item) .................................. 38 4004 UNANSWERED (search key) .................................... 45 4005 UNDELETED (search key) ..................................... 45 4006 UNDRAFT (search key) ....................................... 45 4007 UNFLAGGED (search key) ..................................... 45 4008 UNKEYWORD (search key) .............................. 45 4009 UNSEEN (response code) ..................................... 56 4010 UNSEEN (search key) ........................................ 45 4011 UNSEEN (status item) ....................................... 38 4012 UNSUBSCRIBE (command) ...................................... 33 4013 Unique Identifier (UID) (message attribute) ................ 5 4014 X (command) .......................................... 53 4015 [RFC-822] Size (message attribute) ......................... 9 4016 \Answered (system flag) .................................... 7 4017 \Deleted (system flag) ..................................... 7 4018 \Draft (system flag) ....................................... 8 4019 \Flagged (system flag) ..................................... 7 4020 \Marked (mailbox name attribute) ........................... 60 4021 \Noinferiors (mailbox name attribute) ...................... 60 4022 \Noselect (mailbox name attribute) ......................... 60 4023 \Recent (system flag) ...................................... 8 4024 \Seen (system flag) ........................................ 7 4025 \Unmarked (mailbox name attribute) ......................... 60 4027 Table of Contents 4029 IMAP4rev1 Protocol Specification .................................. 1 4030 1. How to Read This Document ................................. 1 4031 1.1. Organization of This Document ............................. 1 4032 1.2. Conventions Used in This Document ......................... 1 4033 2. Protocol Overview ......................................... 2 4034 2.1. Link Level ................................................ 2 4035 2.2. Commands and Responses .................................... 2 4036 2.2.1. Client Protocol Sender and Server Protocol Receiver ....... 3 4037 2.2.2. Server Protocol Sender and Client Protocol Receiver ....... 4 4038 2.3. Message Attributes ........................................ 5 4039 2.3.1. Message Numbers ........................................... 5 4040 2.3.1.1. Unique Identifier (UID) Message Attribute ......... 5 4041 2.3.1.2. Message Sequence Number Message Attribute ......... 7 4042 2.3.2. Flags Message Attribute ................................... 7 4043 2.3.3. Internal Date Message Attribute ........................... 8 4044 2.3.4. [RFC-822] Size Message Attribute .......................... 9 4045 2.3.5. Envelope Structure Message Attribute ...................... 9 4046 2.3.6. Body Structure Message Attribute .......................... 9 4047 2.4. Message Texts ............................................. 9 4048 3. State and Flow Diagram .................................... 9 4049 3.1. Not Authenticated State ................................... 9 4050 3.2. Authenticated State ....................................... 10 4051 3.3. Selected State ............................................ 10 4052 3.4. Logout State .............................................. 10 4053 4. Data Formats .............................................. 12 4054 4.1. Atom ...................................................... 12 4055 4.2. Number .................................................... 12 4056 4.3. String .................................................... 12 4057 4.3.1. 8-bit and Binary Strings .................................. 13 4058 4.4. Parenthesized List ........................................ 13 4059 4.5. NIL ....................................................... 13 4060 5. Operational Considerations ................................ 14 4061 5.1. Mailbox Naming ............................................ 14 4062 5.1.1. Mailbox Hierarchy Naming .................................. 15 4063 5.1.2. Mailbox Namespace Naming Convention ....................... 15 4064 5.1.3. Mailbox International Naming Convention ................... 15 4065 5.2. Mailbox Size and Message Status Updates ................... 17 4066 5.3. Response when no Command in Progress ...................... 17 4067 5.4. Autologout Timer .......................................... 18 4068 5.5. Multiple Commands in Progress ............................. 18 4069 6. Client Commands ........................................... 20 4070 6.1. Client Commands - Any State ............................... 20 4071 6.1.1. CAPABILITY Command ........................................ 20 4072 6.1.2. NOOP Command .............................................. 21 4073 6.1.3. LOGOUT Command ............................................ 22 4074 6.2. Client Commands - Not Authenticated State ................. 22 4075 6.2.1. AUTHENTICATE Command ...................................... 22 4076 6.2.2. LOGIN Command ............................................. 25 4077 6.3. Client Commands - Authenticated State ..................... 25 4078 6.3.1. SELECT Command ............................................ 25 4079 6.3.2. EXAMINE Command ........................................... 27 4080 6.3.3. CREATE Command ............................................ 28 4081 6.3.4. DELETE Command ............................................ 29 4082 6.3.5. RENAME Command ............................................ 31 4083 6.3.6. SUBSCRIBE Command ......................................... 32 4084 6.3.7. UNSUBSCRIBE Command ....................................... 33 4085 6.3.8. LIST Command .............................................. 33 4086 6.3.9. LSUB Command .............................................. 36 4087 6.3.10. STATUS Command ............................................ 36 4088 6.3.11. APPEND Command ............................................ 38 4089 6.4. Client Commands - Selected State .......................... 40 4090 6.4.1. CHECK Command ............................................. 40 4091 6.4.2. CLOSE Command ............................................. 40 4092 6.4.3. EXPUNGE Command ........................................... 41 4093 6.4.4. SEARCH Command ............................................ 41 4094 6.4.5. FETCH Command ............................................. 46 4095 6.4.6. STORE Command ............................................. 49 4096 6.4.7. COPY Command .............................................. 51 4097 6.4.8. UID Command ............................................... 51 4098 6.5. Client Commands - Experimental/Expansion .................. 53 4099 6.5.1. X Command ........................................... 53 4100 7. Server Responses .......................................... 54 4101 7.1. Server Responses - Status Responses ....................... 55 4102 7.1.1. OK Response ............................................... 57 4103 7.1.2. NO Response ............................................... 57 4104 7.1.3. BAD Response .............................................. 58 4105 7.1.4. PREAUTH Response .......................................... 58 4106 7.1.5. BYE Response .............................................. 58 4107 7.2. Server Responses - Server and Mailbox Status .............. 59 4108 7.2.1. CAPABILITY Response ....................................... 59 4109 7.2.2. LIST Response ............................................. 60 4110 7.2.3. LSUB Response ............................................. 61 4111 7.2.4 STATUS Response ........................................... 61 4112 7.2.5. SEARCH Response ........................................... 61 4113 7.2.6. FLAGS Response ............................................ 62 4114 7.3. Server Responses - Mailbox Size ........................... 62 4115 7.3.1. EXISTS Response ........................................... 62 4116 7.3.2. RECENT Response ........................................... 62 4117 7.4. Server Responses - Message Status ......................... 63 4118 7.4.1. EXPUNGE Response .......................................... 63 4119 7.4.2. FETCH Response ............................................ 64 4120 7.5. Server Responses - Command Continuation Request ........... 69 4121 8. Sample IMAP4rev1 connection ............................... 71 4122 9. Formal Syntax ............................................. 72 4123 10. Author's Note ............................................. 83 4124 11. Security Considerations ................................... 83 4125 12. Author's Address .......................................... 83 4126 Appendices ........................................................ 84 4127 A. References ................................................ 84 4128 B. Changes from RFC 2060 ..................................... 85 4129 C. Key Word Index ............................................ 88