idnits 2.17.1 draft-ietf-imap-imap4-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 51 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([IMAP2], [SMTP], [IMSP], [IMAP-DISC], [IMAP-COMPAT]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 278: '... A client MUST be prepared to accept...' RFC 2119 keyword, line 280: '... data SHOULD be recorded, so that th...' RFC 2119 keyword, line 407: '... [MIME-1] encoding. IMAP4 implementations MAY transmit 8-bit or...' RFC 2119 keyword, line 413: '... Implementations MUST encode binary da...' RFC 2119 keyword, line 456: '...ilbox. A server MUST send mailbox siz...' (69 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 746 has weird spacing: '...mailbox so t...' == Line 747 has weird spacing: '...mailbox can ...' == Line 754 has weird spacing: '... to the mailb...' == Line 758 has weird spacing: '... unique ident...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 1994) is 10786 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 3229 looks like a reference -- Missing reference section? 'IMSP' on line 3246 looks like a reference -- Missing reference section? 'SMTP' on line 3260 looks like a reference -- Missing reference section? 'IMAP2' on line 3243 looks like a reference -- Missing reference section? 'IMAP-COMPAT' on line 3224 looks like a reference -- Missing reference section? 'MIME-1' on line 3250 looks like a reference -- Missing reference section? 'IMAP-AUTH' on line 3220 looks like a reference -- Missing reference section? 'UNSEEN 12' on line 802 looks like a reference -- Missing reference section? 'UIDVALIDITY 3857529045' on line 2499 looks like a reference -- Missing reference section? 'UNSEEN 8' on line 834 looks like a reference -- Missing reference section? 'RFC-822' on line 3257 looks like a reference -- Missing reference section? 'MIME-2' on line 3254 looks like a reference -- Missing reference section? 'UNSEEN 17' on line 2498 looks like a reference -- Missing reference section? 'READ-WRITE' on line 2500 looks like a reference -- Missing reference section? 'IMAP-MODEL' on line 3234 looks like a reference -- Missing reference section? 'IMAP-NAMING' on line 3239 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Crispin 3 Internet Draft: IMAP4 University of Washington 4 Document: internet-drafts/draft-ietf-imap-imap4-06.txt October 1994 6 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4 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 ds.internic.net (US East Coast), nic.nordu.net 23 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 24 Rim). 26 This is a draft document of the IETF IMAP Working Group. A revised 27 version of this draft document will be submitted to the RFC editor as 28 a Proposed Standard for the Internet Community. Discussion and 29 suggestions for improvement are requested, and should be sent to 30 imap@CAC.Washington.EDU. This document will expire before 30 April 31 1995. Distribution of this draft is unlimited. 33 Abstract 35 The Internet Message Access Protocol, Version 4 (IMAP4) allows a 36 client to access and manipulate electronic mail messages on a server. 37 IMAP4 permits manipulation of remote message folders, called 38 "mailboxes", in a way that is functionally equivalent to local 39 mailboxes. IMAP4 also provides the capability for an offline client 40 to resynchronize with the server (see also [IMAP-DISC]). 42 IMAP4 includes operations for creating, deleting, and renaming 43 mailboxes; checking for new messages; permanently removing messages; 44 setting and clearing flags; RFC 822 and MIME parsing; searching; and 45 selective fetching of message attributes, texts, and portions 47 Internet DRAFT IMAP4 October 30, 1994 49 thereof. Messages in IMAP4 are accessed by the use of numbers. 50 These numbers are either message sequence numbers (relative position 51 from 1 to the number of messages in the mailbox) or unique 52 identifiers (immutable, strictly ascending values assigned to each 53 message, but which are not necessarily contiguous). 55 IMAP4 supports a single server. A mechanism for supporting multiple 56 IMAP4 servers is discussed in [IMSP]. 58 IMAP4 does not specify a means of posting mail; this function is 59 handled by a mail transfer protocol such as [SMTP]. 61 IMAP4 is designed to be upwards compatible from the [IMAP2] protocol. 62 Compatibility issues are discussed in [IMAP-COMPAT]. 64 Internet DRAFT IMAP4 October 30, 1994 66 Table of Contents 68 Status of this Memo ............................................... i 69 Abstract .......................................................... i 70 IMAP4 Protocol Specification ...................................... 1 71 1. Organization of this Document ............................. 1 72 1.1. How to Read This Document ................................. 1 73 1.2. Conventions Used in this Document ......................... 1 74 2. Protocol Overview ......................................... 1 75 2.1. Link Level ................................................ 1 76 2.2. Commands and Responses .................................... 1 77 2.2.1. Client Protocol Sender and Server Protocol Receiver ....... 2 78 2.2.2. Server Protocol Sender and Client Protocol Receiver ....... 2 79 3. State and Flow Diagram .................................... 4 80 3.1. Non-Authenticated State ................................... 4 81 3.2. Authenticated State ....................................... 4 82 3.3. Selected State ............................................ 4 83 3.4. Logout State .............................................. 4 84 4. Data Formats .............................................. 6 85 4.1. Atom ...................................................... 6 86 4.2. Number .................................................... 6 87 4.3. String .................................................... 6 88 4.3.1. 8-bit and Binary Strings .................................. 7 89 4.4. Parenthesized List ........................................ 7 90 4.5. NIL ....................................................... 7 91 5. Operational Considerations ................................ 8 92 5.1. Mailbox Naming ............................................ 8 93 5.2. Mailbox Size and Message Status Updates ................... 8 94 5.3. Response when no Command in Progress ...................... 8 95 5.4. Autologout Timer .......................................... 8 96 5.5. Multiple Commands in Progress ............................. 9 97 6. Client Commands ........................................... 10 98 6.1. Client Commands - Any State ............................... 10 99 6.1.1. CAPABILITY Command ........................................ 10 100 6.1.2. NOOP Command .............................................. 11 101 6.1.3. LOGOUT Command ............................................ 11 102 6.2. Client Commands - Non-Authenticated State ................. 12 103 6.2.1. AUTHENTICATE Command ...................................... 12 104 6.2.2. LOGIN Command ............................................. 14 105 6.3. Client Commands - Authenticated State ..................... 14 106 6.3.1. SELECT Command ............................................ 15 107 6.3.2. EXAMINE Command ........................................... 16 108 6.3.3. CREATE Command ............................................ 17 109 Internet DRAFT IMAP4 October 30, 1994 111 6.3.4. DELETE Command ............................................ 18 112 6.3.5. RENAME Command ............................................ 18 113 6.3.6. SUBSCRIBE Command ......................................... 19 114 6.3.7. UNSUBSCRIBE Command ....................................... 19 115 6.3.8. LIST Command .............................................. 20 116 6.3.9. LSUB Command .............................................. 22 117 6.3.10. APPEND Command ............................................ 22 118 6.4. Client Commands - Selected State .......................... 23 119 6.4.1. CHECK Command ............................................. 23 120 6.4.2. CLOSE Command ............................................. 24 121 6.4.3. EXPUNGE Command ........................................... 25 122 6.4.4. SEARCH Command ............................................ 25 123 6.4.5. FETCH Command ............................................. 29 124 6.4.6. PARTIAL Command ........................................... 32 125 6.4.7. STORE Command ............................................. 33 126 6.4.8. COPY Command .............................................. 34 127 6.4.9. UID Command ............................................... 35 128 6.5. Client Commands - Experimental/Expansion .................. 37 129 6.5.1. X Command ........................................... 37 130 7. Server Responses .......................................... 38 131 7.1. Server Responses - Status Responses ....................... 39 132 7.1.1. OK Response ............................................... 40 133 7.1.2. NO Response ............................................... 40 134 7.1.3. BAD Response .............................................. 41 135 7.1.4. PREAUTH Response .......................................... 41 136 7.1.5. BYE Response .............................................. 42 137 7.2. Server Responses - Server and Mailbox Status .............. 42 138 7.2.1. CAPABILITY Response ....................................... 42 139 7.2.2. LIST Response ............................................. 43 140 7.2.3. LSUB Response ............................................. 44 141 7.2.4. SEARCH Response ........................................... 44 142 7.2.5. FLAGS Response ............................................ 44 143 7.3. Server Responses - Message Status ......................... 45 144 7.3.1. EXISTS Response ........................................... 45 145 7.3.2. RECENT Response ........................................... 45 146 7.3.3. EXPUNGE Response .......................................... 45 147 7.3.4. FETCH Response ............................................ 46 148 7.3.5. Obsolete Responses ........................................ 51 149 7.4. Server Responses - Command Continuation Request ........... 51 150 8. Sample IMAP4 session ...................................... 52 151 9. Formal Syntax ............................................. 53 152 10. Author's Note ............................................. 63 153 11. Security Considerations ................................... 63 154 12. Author's Address .......................................... 63 155 Appendices ........................................................ 64 156 A. Obsolete Commands ......................................... 64 157 A.6.3.OBS.1. FIND ALL.MAILBOXES Command ........................ 64 158 A.6.3.OBS.2. FIND MAILBOXES Command ............................ 64 159 Internet DRAFT IMAP4 October 30, 1994 161 A.6.3.OBS.3. SUBSCRIBE MAILBOX Command ......................... 65 162 A.6.3.OBS.4. UNSUBSCRIBE MAILBOX Command ....................... 65 163 B. Obsolete Responses ........................................ 67 164 B.7.2.OBS.1. MAILBOX Response .................................. 67 165 B.7.3.OBS.1. COPY Response ..................................... 67 166 B.7.3.OBS.2. STORE Response .................................... 67 167 C. References ................................................ 69 168 D. Changes from Draft 05 ..................................... 70 169 E. IMAP4 Keyword Index ....................................... 71 170 Internet DRAFT IMAP4 October 30, 1994 172 IMAP4 Protocol Specification 174 1. Organization of this Document 176 1.1. How to Read This Document 178 This document is written from the point of view of the implementor of 179 an IMAP4 client or server. Beyond the protocol overview in section 180 2, it is not optimized for someone trying to understand the operation 181 of the protocol. The material in sections 3 through 5 provides the 182 general context and definitions with which IMAP4 operates. 184 Sections 6, 7, and 9 describe the IMAP commands, responses, and 185 syntax, respectively. The relationships among these are such that it 186 is almost impossible to understand any of them separately. In 187 particular, one should not attempt to deduce command syntax from the 188 command section alone; one should instead refer to the formal syntax 189 section. 191 1.2. Conventions Used in this Document 193 In examples, "C:" and "S:" indicate lines sent by the client and 194 server respectively. 196 2. Protocol Overview 198 2.1. Link Level 200 The IMAP4 protocol assumes a reliable data stream such as provided by 201 TCP. When TCP is used, an IMAP4 server listens on port 143. 203 2.2. Commands and Responses 205 An IMAP4 session consists of the establishment of a client/server 206 connection, an initial greeting from the server, and client/server 207 interactions. These client/server interactions consist of a client 208 command, server data, and a server completion result response. 210 All interactions transmitted by client and server are in the form of 211 lines; that is, strings that end with a CRLF. The protocol receiver 212 of an IMAP4 client or server is either reading a line, or is reading 213 a sequence of octets with a known count followed by a line. 215 Internet DRAFT IMAP4 October 30, 1994 217 2.2.1. Client Protocol Sender and Server Protocol Receiver 219 The client command begins an operation. Each client command is 220 prefixed with a identifier (typically a short alphanumeric string, 221 e.g. A0001, A0002, etc.) called a "tag". A different tag is 222 generated by the client for each command. 224 There are two cases in which a line from the client does not 225 represent a complete command. In one case, a command argument is 226 quoted with an octet count (see the description of literal in String 227 under Data Formats); in the other case, the command arguments require 228 server feedback (see the AUTHENTICATE command). In either case, the 229 server sends a command continuation request response if it is ready 230 for the octets (if appropriate) and the remainder of the command. 231 This response is prefixed with the token "+". 233 Note: If, instead, the server detected an error in the 234 command, it sends a BAD completion response with tag 235 matching the command (as described below) to reject the 236 command and prevent the client from sending any more of the 237 command. 239 It is also possible for the server to send a completion 240 response for some other command (if multiple commands are 241 in progress), or untagged data. In either case, the 242 command continuation request is still pending; the client 243 takes the appropriate action for the response, and reads 244 another response from the server. 246 The protocol receiver of an IMAP4 server reads a command line from 247 the client, parses the command and its arguments, and transmits 248 server data and a server command completion result response. 250 2.2.2. Server Protocol Sender and Client Protocol Receiver 252 Data transmitted by the server to the client and status responses 253 that do not indicate command completion are prefixed with the token 254 "*", and are called untagged responses. 256 Server data may be sent as a result of a client command, or may be 257 sent unilaterally by the server. There is no syntactic difference 258 between server data that resulted from a specific command and server 259 data that were sent unilaterally. 261 The server completion result response indicates the success or 262 failure of the operation. It is tagged with the same tag as the 263 client command which began the operation. Thus, if more than one 265 Internet DRAFT IMAP4 October 30, 1994 267 command is in progress, the tag in a server completion response 268 identifies the command to which the response applies. There are 269 three possible server completion responses: OK (indicating success), 270 NO (indicating failure), or BAD (indicating protocol error such as 271 unrecognized command or command syntax error). 273 The protocol receiver of an IMAP4 client reads a response line from 274 the server. It then takes action on the response based upon the 275 first token of the response, which may be a tag, a "*", or a "+". As 276 described above. 278 A client MUST be prepared to accept any server response at all times. 279 This includes server data that it may not have requested. Server 280 data SHOULD be recorded, so that the client can reference its 281 recorded copy rather than sending a command to the server to request 282 the data. In the case of certain server data, recording the data is 283 mandatory. 285 This topic is discussed in greater detail in the Server Responses 286 section. 288 Internet DRAFT IMAP4 October 30, 1994 290 3. State and Flow Diagram 292 An IMAP4 server is in one of four states. Most commands are valid in 293 only certain states. It is a protocol error for the client to 294 attempt a command while the command is in an inappropriate state. In 295 this case, a server will respond with a BAD or NO (depending upon 296 server implementation) command completion result. 298 3.1. Non-Authenticated State 300 In non-authenticated state, the user must supply authentication 301 credentials before most commands will be permitted. This state is 302 entered when a connection starts unless the connection has been 303 pre-authenticated. 305 3.2. Authenticated State 307 In authenticated state, the user is authenticated and must select a 308 mailbox to access before commands that affect messages will be 309 permitted. This state is entered when a pre-authenticated connection 310 starts, when acceptable authentication credentials have been 311 provided, or after an error in selecting a mailbox. 313 3.3. Selected State 315 In selected state, a mailbox has been selected to access. This state 316 is entered when a mailbox has been successfully selected. 318 3.4. Logout State 320 In logout state, the session is being terminated, and the server will 321 close the connection. This state can be entered as a result of a 322 client request or by unilateral server decision. 324 Internet DRAFT IMAP4 October 30, 1994 326 +--------------------------------------+ 327 |initial connection and server greeting| 328 +--------------------------------------+ 329 || (1) || (2) || (3) 330 VV || || 331 +-----------------+ || || 332 |non-authenticated| || || 333 +-----------------+ || || 334 || (7) || (4) || || 335 || VV VV || 336 || +----------------+ || 337 || | authenticated |<=++ || 338 || +----------------+ || || 339 || || (7) || (5) || (6) || 340 || || VV || || 341 || || +--------+ || || 342 || || |selected|==++ || 343 || || +--------+ || 344 || || || (7) || 345 VV VV VV VV 346 +--------------------------------------+ 347 | logout and close connection | 348 +--------------------------------------+ 350 (1) connection without pre-authentication (OK greeting) 351 (2) pre-authenticated connection (PREAUTH greeting) 352 (3) rejected connection (BYE greeting) 353 (4) successful LOGIN or AUTHENTICATE command 354 (5) successful SELECT or EXAMINE command 355 (6) CLOSE command, or failed SELECT or EXAMINE command 356 (7) LOGOUT command, server shutdown, or connection closed 358 Internet DRAFT IMAP4 October 30, 1994 360 4. Data Formats 362 IMAP4 uses textual commands and responses. Data in IMAP4 can be in 363 one of several forms: atom, number, string, parenthesized list, or 364 NIL. 366 4.1. Atom 368 An atom consists of one or more non-special characters. 370 4.2. Number 372 A number consists of one or more digit characters, and represents a 373 numeric value. 375 4.3. String 377 A string is in one of two forms: literal and quoted string. The 378 literal form is the general form of string. The quoted string form 379 is an alternative that avoids the overhead of processing a literal at 380 the cost of restrictions of what may be in a quoted string. 382 A literal is a sequence of zero or more octets (including CR and LF), 383 prefix-quoted with an octet count in the form of an open brace ("{"), 384 the number of octets, close brace ("}"), and CRLF. In the case of 385 literals transmitted from server to client, the CRLF is immediately 386 followed by the octet data. In the case of literals transmitted from 387 client to server, the client must wait to receive a command 388 continuation request (described later in this document) before 389 sending the octet data (and the remainder of the command). 391 A quoted string is a sequence of zero or more 7-bit characters, 392 excluding CR and LF, with double quote (<">) characters at each end. 394 The empty string is respresented as either "" (a quoted string with 395 zero characters between double quotes) or as {0} followed by CRLF (a 396 literal with an octet count of 0). 398 Note: Even if the octet count is 0, a client transmitting a 399 literal must wait to receive a command continuation 400 request. 402 Internet DRAFT IMAP4 October 30, 1994 404 4.3.1. 8-bit and Binary Strings 406 8-bit textual and binary mail is supported through the use of 407 [MIME-1] encoding. IMAP4 implementations MAY transmit 8-bit or 408 multi-octet characters in literals, but should do so only when the 409 character set is identified. 411 Although a BINARY body encoding is defined, unencoded binary strings 412 are not permitted. A "binary string" is any string with NUL 413 characters. Implementations MUST encode binary data into a textual 414 form such as BASE64 before transmitting the data. A string with an 415 excessive amount of CTL characters may also be considered to be 416 binary, although this is not required. 418 4.4. Parenthesized List 420 Data structures are represented as a "parenthesized list"; a sequence 421 of data items, delimited by space, and bounded at each end by 422 parentheses. A parenthesized list may itself contain other 423 parenthesized lists, using multiple levels of parentheses to indicate 424 nesting. 426 The empty list is represented as () -- a parenthesized list with no 427 members. 429 4.5. NIL 431 The special atom "NIL" represents the non-existence of a particular 432 data item that is represented as a string or parenthesized list, as 433 distinct from the empty string "" or the empty parenthesized list (). 435 Internet DRAFT IMAP4 October 30, 1994 437 5. Operational Considerations 439 5.1. Mailbox Naming 441 The interpretation of mailbox names is implementation-dependent. 442 However, the mailbox name INBOX is a special name reserved to mean 443 "the primary mailbox for this user on this server". If it is desired 444 to export hierarchical mailbox names, mailbox names must be 445 left-to-right hierarchical using a single character to separate 446 levels of hierarchy. The same hierarchy separator character is used 447 for all levels of hierarchy within a single name. 449 5.2. Mailbox Size and Message Status Updates 451 At any time, a server can send data that the client did not request. 452 Sometimes, such behavior is required. For example, agents other than 453 the server may add messages to the mailbox (e.g. new mail delivery), 454 change the flags of message in the mailbox (e.g. simultaneous access 455 to the same mailbox by multiple agents), or even remove messages from 456 the mailbox. A server MUST send mailbox size updates automatically 457 if a mailbox size change is observed during the processing of a 458 command. A server SHOULD send message flag updates automatically, 459 without requiring the client to request such updates explicitly. 460 Special rules exist for server notification of a client about the 461 removal of messages to prevent synchronization errors; see the 462 description of the EXPUNGE response for more details. 464 Regardless of what implementation decisions a client may take on 465 remembering data from the server, a client implementation MUST record 466 mailbox size updates. It MUST NOT assume that any command after 467 initial mailbox selection will return the size of the mailbox. 469 5.3. Response when no Command in Progress 471 Server implementations are permitted to send an untagged response 472 (except for EXPUNGE) while there is no command in progress. Server 473 implementations that send such responses MUST deal with flow control 474 considerations. Specifically, they must either (1) verify that the 475 size of the data does not exceed the underlying transport's available 476 window size, or (2) use non-blocking writes. 478 5.4. Autologout Timer 480 If a server has an inactivity autologout timer, that timer MUST be of 481 at least 30 minutes' duration. The receipt of ANY command from the 482 client during that interval should suffice to reset the autologout 484 Internet DRAFT IMAP4 October 30, 1994 486 timer. 488 5.5. Multiple Commands in Progress 490 The client is not required to wait for the completion result response 491 of a command before sending another command, subject to flow control 492 constraints on the underlying data stream. Similarly, a server is 493 not required to process a command to completion before beginning 494 processing of the next command, unless an ambiguity would result 495 because of a command that would affect the results of other commands. 496 If there is such an ambiguity, the server executes commands to 497 completion in the order given by the client. 499 Internet DRAFT IMAP4 October 30, 1994 501 6. Client Commands 503 IMAP4 commands are described in this section. Commands are organized 504 by the state in which the command is permitted. Commands which are 505 permitted in multiple states are listed in the minimum permitted 506 state (for example, commands valid in authenticated and selected 507 state are listed in the authenticated state commands). 509 Command arguments, identified by "Arguments:" in the command 510 descriptions below, are described by function, not by syntax. The 511 precise syntax of command arguments is described in the Formal Syntax 512 section. 514 Some commands cause specific server data to be returned; these are 515 identified by "Data:" in the command descriptions below. See the 516 response descriptions in the Responses section for information on 517 these responses, and the Formal Syntax section for the precise syntax 518 of these responses. It is possible for server data to be transmitted 519 as a result of any command; thus, commands that do not specifically 520 require server data specify "no specific data for this command" 521 instead of "none". 523 The "Result:" in the command description refers to the possible 524 tagged status responses to a command, and any special interpretation 525 of these status responses. 527 6.1. Client Commands - Any State 529 The following commands are valid in any state: CAPABILITY, NOOP, and 530 LOGOUT. 532 6.1.1. CAPABILITY Command 534 Arguments: none 536 Data: mandatory untagged response: CAPABILITY 538 Result: OK - capability completed 539 BAD - command unknown or arguments invalid 541 The CAPABILITY command requests a listing of capabilities that the 542 server supports. The server MUST send a single untagged 543 CAPABILITY response with "IMAP4" as the first listed capability 544 before the (tagged) OK response. This listing of capabilities is 545 not dependent upon connection state or user. It is therefore not 546 necessary to issue a CAPABILITY command more than once in a 547 session. 549 Internet DRAFT IMAP4 October 30, 1994 551 Capability names other than "IMAP4" refer to extensions, 552 revisions, or amendments to this specification. See the 553 documentation of the CAPABILITY response for additional 554 information. No capabilities are enabled without explicit client 555 action to invoke the capability. See the section entitled "Client 556 Commands - Experimental/Expansion" for information about the form 557 of site or implementation-specific capabilities. 559 Example: C: abcd CAPABILITY 560 S: * CAPABILITY IMAP4 561 S: abcd OK CAPABILITY completed 563 6.1.2. NOOP Command 565 Arguments: none 567 Data: no specific data for this command (but see below) 569 Result: OK - noop completed 570 BAD - command unknown or arguments invalid 572 The NOOP command always succeeds. It does nothing. 574 Since any command can return a status update as untagged data, the 575 NOOP command can be used as a periodic poll for new messages or 576 message status updates during a period of inactivity. The NOOP 577 command can also be used to reset any inactivity autologout timer 578 on the server. 580 Example: C: a002 NOOP 581 S: a002 OK NOOP completed 582 . . . 583 C: a047 NOOP 584 S: * 22 EXPUNGE 585 S: * 23 EXISTS 586 S: * 3 RECENT 587 S: * 14 FETCH (FLAGS (\Seen \Deleted)) 588 S: a047 OK NOOP completed 590 Internet DRAFT IMAP4 October 30, 1994 592 6.1.3. LOGOUT Command 594 Arguments: none 596 Data: mandatory untagged response: BYE 598 Result: OK - logout completed 599 BAD - command unknown or arguments invalid 601 The LOGOUT command informs the server that the client is done with 602 the session. The server must send a BYE untagged response before 603 the (tagged) OK response, and then close the network connection. 605 Example: C: A023 LOGOUT 606 S: * BYE IMAP4 Server logging out 607 S: A023 OK LOGOUT completed 608 (Server and client then close the connection) 610 6.2. Client Commands - Non-Authenticated State 612 In non-authenticated state, the AUTHENTICATE or LOGIN command 613 establishes authentication and enter authenticated state. The 614 AUTHENTICATE command provides a general mechanism for a variety of 615 authentication techniques, whereas the LOGIN command uses the 616 traditional user name and plaintext password pair. 618 Server implementations may allow non-authenticated access to certain 619 mailboxes. The convention is to use a LOGIN command with the userid 620 "anonymous". A password is required. It is implementation-dependent 621 what requirements, if any, are placed on the password and what access 622 restrictions are placed on anonymous users. 624 Once authenticated (including as anonymous), it is not possible to 625 re-enter non-authenticated state. 627 In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), 628 the following commands are valid in non-authenticated state: 629 AUTHENTICATE and LOGIN. 631 Internet DRAFT IMAP4 October 30, 1994 633 6.2.1. AUTHENTICATE Command 635 Arguments: authentication mechanism name 637 Data: continuation data may be requested 639 Result: OK - authenticate completed, now in authenticated state 640 NO - authenticate failure: unsupported authentication 641 mechanism, credentials rejected 642 BAD - command unknown or arguments invalid, 643 authentication exchange cancelled 645 The AUTHENTICATE command indicates an authentication mechanism, 646 such as described in [IMAP-AUTH], to the server. If the server 647 supports the requested authentication mechanism, it performs an 648 authentication protocol exchange to authenticate and identify the 649 user. Optionally, it also negotiates a protection mechanism for 650 subsequent protocol interactions. If the requested authentication 651 mechanism is not supported, the server should reject the 652 AUTHENTICATE command by sending a tagged NO response. 654 The authentication protocol exchange consists of a series of 655 server challenges and client answers that are specific to the 656 authentication mechanism. A server challenge consists of a 657 command continuation request response with the "+" token followed 658 by a BASE64 encoded string. The client answer consists of a line 659 consisting of a BASE64 encoded string. If the client wishes to 660 cancel an authentication exchange, it should issue a line with a 661 single "*". If the server receives such an answer, it must reject 662 the AUTHENTICATE command by sending a tagged BAD response. 664 A protection mechanism provides integrity and privacy protection 665 to the protocol session. If a protection mechanism is negotiated, 666 it is applied to all subsequent data sent over the connection. 667 The protection mechanism takes effect immediately following the 668 CRLF that concludes the authentication exchange for the client, 669 and the CRLF of the tagged OK response for the server. Once the 670 protection mechanism is in effect, the stream of command and 671 response octets is processed into buffers of ciphertext. Each 672 buffer is transferred over the connection as a stream of octets 673 prepended with a four octet field in network byte order that 674 represents the length of the following data. The maximum 675 ciphertext buffer length is defined by the protection mechanism. 677 The server is not required to support any particular 678 authentication mechanism, nor are authentication mechanisms 679 required to support any protection mechanisms. If an AUTHENTICATE 680 command fails with a NO response, the client may try another 682 Internet DRAFT IMAP4 October 30, 1994 684 authentication mechanism by issuing another AUTHENTICATE command, 685 or may attempt to authenticate by using the LOGIN command. In 686 other words, the client may request authentication types in 687 decreasing order of preference, with the LOGIN command as a last 688 resort. 690 Example: S: * OK KerberosV4 IMAP4 Server 691 C: A001 AUTHENTICATE KERBEROS_V4 692 S: + AmFYig== 693 C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT 694 +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd 695 WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh 696 S: + or//EoAADZI= 697 C: DiAF5A4gA+oOIALuBkAAmw== 698 S: A001 OK Kerberos V4 authentication successful 700 Note: the line breaks in the first client answer are for 701 editorial clarity and are not in real authenticators. 703 6.2.2. LOGIN Command 705 Arguments: user name 706 password 708 Data: no specific data for this command 710 Result: OK - login completed, now in authenticated state 711 NO - login failure: user name or password rejected 712 BAD - command unknown or arguments invalid 714 The LOGIN command identifies the user to the server and carries 715 the plaintext password authenticating this user. 717 Example: C: a001 LOGIN SMITH SESAME 718 S: a001 OK LOGIN completed 720 6.3. Client Commands - Authenticated State 722 In authenticated state, commands that manipulate mailboxes as atomic 723 entities are permitted. Of these commands, the SELECT and EXAMINE 724 commands will select a mailbox for access and enter selected state. 726 In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), 727 the following commands are valid in authenticated state: SELECT, 728 EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, 730 Internet DRAFT IMAP4 October 30, 1994 732 and APPEND. 734 6.3.1. SELECT Command 736 Arguments: mailbox name 738 Data: mandatory untagged responses: FLAGS, EXISTS, RECENT 739 optional OK untagged responses: UNSEEN, PERMANENTFLAGS 741 Result: OK - select completed, now in selected state 742 NO - select failure, now in authenticated state: no 743 such mailbox, can't access mailbox 744 BAD - command unknown or arguments invalid 746 The SELECT command selects a mailbox so that messages in the 747 mailbox can be accessed. Before returning an OK to the client, 748 the server MUST send the following untagged data to the client: 750 FLAGS Defined flags in the mailbox 752 EXISTS The number of messages in the mailbox 754 RECENT The number of messages added to the mailbox since 755 the previous time this mailbox was read 757 OK [UIDVALIDITY ] 758 The unique identifier validity value. See the 759 description of the UID command for more detail. 761 to define the initial state of the mailbox at the client. If it 762 is not possible to determine the messages that were added since 763 the previous time a mailbox was read, then all messages SHOULD be 764 considered recent. 766 The server SHOULD also send an UNSEEN response code in an OK 767 untagged response, indicating the message sequence number of the 768 first unseen message in the mailbox. 770 If the client can not change the permanent state of one or more of 771 the flags listed in the FLAGS untagged response, the server SHOULD 772 send a PERMANENTFLAGS response code in an OK untagged response, 773 listing the flags that the client may change permanently. 775 Only one mailbox may be selected at a time in a session; 776 simultaneous access to multiple mailboxes requires multiple 777 sessions. The SELECT command automatically deselects any 778 currently selected mailbox before attempting the new selection. 779 Consequently, if a mailbox is selected and a SELECT command that 781 Internet DRAFT IMAP4 October 30, 1994 783 fails is attempted, no mailbox is selected. 785 If the user is permitted to modify the mailbox, the server SHOULD 786 prefix the text of the OK response with the "[READ-WRITE]" 787 response code. 789 If the user is not permitted to modify the mailbox but is 790 permitted read access, the mailbox is selected as read-only, and 791 the server MUST prefix the text of the OK response to SELECT with 792 the "[READ-ONLY]" response code. Read-only access through SELECT 793 differs from the EXAMINE command in that certain read-only 794 mailboxes may permit the change of permanent state on a per-user 795 (as opposed to global) basis. Netnews messages marked in a user's 796 .newsrc file are an example of such per-user permanent state that 797 can be modified with read-only mailboxes. 799 Example: C: A142 SELECT INBOX 800 S: * 172 EXISTS 801 S: * 1 RECENT 802 S: * OK [UNSEEN 12] Message 12 is first unseen 803 S: * OK [UIDVALIDITY 3857529045] UIDs valid 804 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 805 S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited 806 S: A142 OK [READ-WRITE] SELECT completed 808 6.3.2. EXAMINE Command 810 Arguments: mailbox name 812 Data: mandatory untagged responses: FLAGS, EXISTS, RECENT 813 optional OK untagged responses: UNSEEN, PERMANENTFLAGS 815 Result: OK - examine completed, now in selected state 816 NO - examine failure, now in authenticated state: no 817 such mailbox, can't access mailbox 818 BAD - command unknown or arguments invalid 820 The EXAMINE command is identical to SELECT and returns the same 821 output; however, the selected mailbox is identified as read-only. 822 No changes to the permanent state of the mailbox, including 823 per-user state, are permitted. 825 The text of an OK response to the EXAMINE command MUST begin with 826 the "[READ-ONLY]" response code. 828 Example: C: A932 EXAMINE blurdybloop 829 S: * 17 EXISTS 831 Internet DRAFT IMAP4 October 30, 1994 833 S: * 2 RECENT 834 S: * OK [UNSEEN 8] Message 8 is first unseen 835 S: * OK [UIDVALIDITY 3857529045] UIDs valid 836 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 837 S: * OK [PERMANENTFLAGS ()] No permanent flags permitted 838 S: A932 OK [READ-ONLY] EXAMINE completed 840 6.3.3. CREATE Command 842 Arguments: mailbox name 844 Data: no specific data for this command 846 Result: OK - create completed 847 NO - create failure: can't create mailbox with that name 848 BAD - command unknown or arguments invalid 850 The CREATE command creates a mailbox with the given name. An OK 851 response is returned only if a new mailbox with that name has been 852 created. It is an error to attempt to create INBOX or a mailbox 853 with a name that refers to an extant mailbox. Any error in 854 creation will return a tagged NO response. 856 If the mailbox name is suffixed with the server's hierarchy 857 separator character (as returned from the server by a LIST 858 command), this is a declaration that the client may, in the 859 future, create mailbox names under this name in the hierarchy. 860 Server implementations that do not require this declaration MUST 861 ignore it. 863 If a new mailbox is created with the same name as a mailbox which 864 was deleted, its unique identifiers MUST be greater than any 865 unique identifiers used in the previous incarnation of the mailbox 866 UNLESS the new incarnation has a different unique identifier 867 validity value. See the description of the UID command for more 868 detail. 870 Example: C: A003 CREATE owatagusiam/ 871 S: A003 OK CREATE completed 872 C: A004 CREATE owatagusiam/blurdybloop 873 S: A004 OK CREATE completed 875 Note: the interpretation of this example depends on whether 876 "/" was returned as the hierarchy separator from LIST. If 877 "/" is the hierarchy separator, a new level of hierarchy 878 named "owatagusiam" with a member called "blurdybloop" is 879 created. Otherwise, two mailboxes at the same hierarchy 881 Internet DRAFT IMAP4 October 30, 1994 883 level are created. 885 6.3.4. DELETE Command 887 Arguments: mailbox name 889 Data: no specific data for this command 891 Result: OK - delete completed 892 NO - delete failure: can't delete mailbox with that name 893 BAD - command unknown or arguments invalid 895 The DELETE command permanently removes the mailbox with the given 896 name. An OK response is returned only if the mailbox has been 897 deleted. It is an error to attempt to delete INBOX or a mailbox 898 name that does not exist. Any error in deletion will return a 899 tagged NO response. 901 The value of the highest-used unique indentifier of the deleted 902 mailbox MUST be preserved so that a new mailbox created with the 903 same name will not reuse the identifiers of the former 904 incarnation, UNLESS the new incarnation has a different unique 905 identifier validity value. See the description of the UID command 906 for more detail. 908 Example: C: A683 DELETE blurdybloop 909 S: A683 OK DELETE completed 911 6.3.5. RENAME Command 913 Arguments: existing mailbox name 914 new mailbox name 916 Data: no specific data for this command 918 Result: OK - rename completed 919 NO - rename failure: can't rename mailbox with that name, 920 can't rename to mailbox with that name 921 BAD - command unknown or arguments invalid 923 The RENAME command changes the name of a mailbox. An OK response 924 is returned only if the mailbox has been renamed. It is an error 925 to attempt to rename from a mailbox name that does not exist or to 926 a mailbox name that already exists. Any error in renaming will 927 return a tagged NO response. 929 Internet DRAFT IMAP4 October 30, 1994 931 Renaming INBOX is permitted; a new, empty INBOX is created in its 932 place. 934 Example: C: Z4S9 RENAME blurdybloop owatagusiam 935 S: Z4S9 OK RENAME completed 937 6.3.6. SUBSCRIBE Command 939 Arguments: mailbox 941 Data: no specific data for this command 943 Result: OK - subscribe completed 944 NO - subscribe failure: can't subscribe to that name 945 BAD - command unknown or arguments invalid 947 The SUBSCRIBE command adds the specified mailbox name to the 948 server's set of "active" or "subscribed" mailboxes as returned by 949 the LSUB command. This command returns an OK response only if the 950 subscription is successful. 952 Example: C: A002 SUBSCRIBE #news.comp.mail.mime 953 S: A002 OK SUBSCRIBE completed 955 6.3.7. UNSUBSCRIBE Command 957 Arguments: mailbox name 959 Data: no specific data for this command 961 Result: OK - unsubscribe completed 962 NO - unsubscribe failure: can't unsubscribe that name 963 BAD - command unknown or arguments invalid 965 The UNSUBSCRIBE command removes the specified mailbox name from 966 the server's set of "active" or "subscribed" mailboxes as returned 967 by the LSUB command. This command returns an OK response only if 968 the unsubscription is successful. 970 Example: C: A002 UNSUBSCRIBE #news.comp.mail.mime 971 S: A002 OK UNSUBSCRIBE completed 973 Internet DRAFT IMAP4 October 30, 1994 975 6.3.8. LIST Command 977 Arguments: reference name 978 mailbox name with possible wildcards 980 Data: untagged responses: LIST 982 Result: OK - list completed 983 NO - list failure: can't list that reference or name 984 BAD - command unknown or arguments invalid 986 The LIST command returns a subset of names from the complete set 987 of all names available to the user. Zero or more untagged LIST 988 replies are returned, containing the name attributes, hierarchy 989 delimiter, and name; see the description of the LIST reply for 990 more detail. 992 An empty ("" string) reference name argument indicates that the 993 mailbox name is interpreted as by SELECT. The returned mailbox 994 names MUST match the supplied mailbox name pattern. A non-empty 995 reference name argument is the name of a mailbox or a level of 996 mailbox hierarchy, and indicates a context in which the mailbox 997 name is interpreted in an implementation-defined manner. 999 The reference and mailbox name arguments are interpreted, in an 1000 implementation-dependent fashion, into a canonical form that 1001 represents an unambiguous left-to-right hierarchy. The returned 1002 mailbox names will be in the interpreted form. 1004 Any part of the reference argument that is included in the 1005 interpreted form SHOULD prefix the interpreted form. It should 1006 also be in the same form as the reference name argument. This 1007 rule permits the client to determine if the returned mailbox name 1008 is in the context of the reference argument, or if something about 1009 the mailbox argument overrode the reference argument. Without 1010 this rule, the client would have to have knowledge of the server's 1011 naming semantics including what characters are "breakouts" that 1012 override a naming context. 1014 Internet DRAFT IMAP4 October 30, 1994 1016 For example, here are some examples of how references 1017 and mailbox names might be interpreted on a UNIX-based 1018 server: 1020 Reference Mailbox Name Interpretation 1021 ------------ ------------ -------------- 1022 ~smith/Mail/ foo.* ~smith/Mail/foo.* 1023 archive/ % archive/% 1024 #news. comp.mail.* #news.comp.mail.* 1025 ~smith/Mail/ /usr/doc/foo /usr/doc/foo 1026 archive/ ~fred/Mail/* ~fred/Mail/* 1028 The first three examples demonstrate interpretations in 1029 the context of the reference argument. Note that 1030 "~smith/Mail" should not be transformed into something 1031 like "/u2/users/smith/Mail", or it would be impossible 1032 for the client to determine that the interpretation was 1033 in the context of the reference. 1035 The character "*" is a wildcard, and matches zero or more 1036 characters at this position. The character "%" is similar to "*", 1037 but it does not match a hierarchy delimiter. If the "%" wildcard 1038 is the last character of a mailbox name argument, matching levels 1039 of hierarchy are also returned. If these levels of hierarchy are 1040 not also selectable mailboxes, they are returned with the 1041 \Noselect mailbox name attribute (see the description of the LIST 1042 response for more detail). 1044 Server implementations are permitted to "hide" otherwise 1045 accessible mailboxes from the wildcard characters, by preventing 1046 certain characters or names from matching a wildcard in certain 1047 situations. For example, a UNIX-based server might restrict the 1048 interpretation of "*" so that an initial "/" character does not 1049 match. 1051 The special name INBOX is included in the output from LIST if it 1052 matches the input arguments and INBOX is supported by this server 1053 for this user. The criteria for omitting INBOX is whether SELECT 1054 INBOX will return failure; it is not relevant whether the user's 1055 real INBOX resides on this or some other server. 1057 Example: C: A002 LIST "~/Mail/" "%" 1058 S: * LIST (\Noselect) "/" ~/Mail/foo 1059 S: * LIST () "/" ~/Mail/meetings 1060 S: A002 OK LIST completed 1062 Internet DRAFT IMAP4 October 30, 1994 1064 6.3.9. LSUB Command 1066 Arguments: reference name 1067 mailbox name with possible wildcards 1069 Data: untagged responses: LSUB 1071 Result: OK - lsub completed 1072 NO - lsub failure: can't list that reference or name 1073 BAD - command unknown or arguments invalid 1075 The LSUB command returns a subset of names from the set of names 1076 that the user has declared as being "active" or "subscribed". 1077 Zero or more untagged LSUB replies are returned. The arguments to 1078 LSUB are in the same form as those for LIST. 1080 Example: C: A002 LSUB "#news." "comp.mail.*" 1081 S: * LSUB () "." #news.comp.mail.mime 1082 S: * LSUB () "." #news.comp.mail.misc 1083 S: A002 OK LSUB completed 1085 6.3.10. APPEND Command 1087 Arguments: mailbox name 1088 optional flag parenthesized list 1089 optional date/time string 1090 message literal 1092 Data: no specific data for this command 1094 Result: OK - append completed 1095 NO - append error: can't append to that mailbox, error 1096 in flags or date/time or message text 1097 BAD - command unknown or arguments invalid 1099 The APPEND command appends the literal argument as a new message 1100 in the specified destination mailbox. This argument is in the 1101 format of an [RFC-822] message. 8-bit characters are permitted in 1102 the message. A server implementation that is unable to preserve 1103 8-bit data properly MUST be able to reversibly convert 8-bit 1104 APPEND data to 7-bit using [MIME-1] encoding. 1106 If a flag parenthesized list or date_time are specified, that data 1107 SHOULD be set in the resulting message; otherwise, the defaults of 1108 empty flags and the current date/time are used. 1110 If the append is unsuccessful for any reason, the mailbox MUST be 1112 Internet DRAFT IMAP4 October 30, 1994 1114 restored to its state before the APPEND attempt; no partial 1115 appending is permitted. If the mailbox is currently selected, the 1116 normal new mail actions should occur. 1118 If the destination mailbox does not exist, a server MUST return an 1119 error, and MUST NOT automatically create the mailbox. Unless it 1120 is certain that the destination mailbox can not be created, the 1121 server MUST send the response code "[TRYCREATE]" as the prefix of 1122 the text of the tagged NO response. This gives a hint to the 1123 client that it can attempt a CREATE command and retry the APPEND 1124 if the CREATE is successful. 1126 Example: C: A003 APPEND saved-messages (\Seen) {310} 1127 C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) 1128 C: From: Fred Foobar 1129 C: Subject: afternoon meeting 1130 C: To: mooch@owatagu.siam.edu 1131 C: Message-Id: 1132 C: MIME-Version: 1.0 1133 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 1134 C: 1135 C: Hello Joe, do you think we can meet at 3:30 tomorrow? 1136 C: 1137 S: A003 OK APPEND completed 1139 Note: the APPEND command is not used for message delivery, 1140 because it does not provide a mechanism to transfer [SMTP] 1141 envelope information. 1143 6.4. Client Commands - Selected State 1145 In selected state, commands that manipulate messages in a mailbox are 1146 permitted. 1148 In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), 1149 and the authenticated state commands (SELECT, EXAMINE, CREATE, 1150 DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, FIND 1151 ALL.MAILBOXES, FIND MAILBOXES, and APPEND), the following commands 1152 are valid in the selected state: CHECK, CLOSE, EXPUNGE, SEARCH, 1153 FETCH, PARTIAL, STORE, COPY, and UID. 1155 Internet DRAFT IMAP4 October 30, 1994 1157 6.4.1. CHECK Command 1159 Arguments: none 1161 Data: no specific data for this command 1163 Result: OK - check completed 1164 BAD - command unknown or arguments invalid 1166 The CHECK command requests a checkpoint of the currently selected 1167 mailbox. A checkpoint refers to any implementation-dependent 1168 housekeeping associated with the mailbox (e.g. resolving the 1169 server's in-memory state of the mailbox with the state on its 1170 disk) that is not normally executed as part of each command. A 1171 checkpoint may take a non-instantaneous amount of real time to 1172 complete. If a server implementation has no such housekeeping 1173 considerations, CHECK is equivalent to NOOP. 1175 There is no guarantee that an EXISTS untagged response will happen 1176 as a result of CHECK. NOOP, not CHECK, should be used for new 1177 mail polling. 1179 Example: C: FXXZ CHECK 1180 S: FXXZ OK CHECK Completed 1182 6.4.2. CLOSE Command 1184 Arguments: none 1186 Data: no specific data for this command 1188 Result: OK - close completed, now in authenticated state 1189 NO - close failure: no mailbox selected 1190 BAD - command unknown or arguments invalid 1192 The CLOSE command permanently removes from the currently selected 1193 mailbox all messages that have the \Deleted flag set, and returns 1194 to authenticated state from selected state. No untagged EXPUNGE 1195 responses are sent. 1197 No messages are removed, and no error is given, if the mailbox is 1198 selected by an EXAMINE command or is otherwise selected read-only. 1200 Even when a mailbox is selected, it is not required to send a 1201 CLOSE command before a SELECT, EXAMINE, or LOGOUT command. The 1202 SELECT, EXAMINE, and LOGOUT commands implicitly close the 1203 currently selected mailbox without doing an expunge. However, 1205 Internet DRAFT IMAP4 October 30, 1994 1207 when many messages are deleted, a CLOSE-LOGOUT or CLOSE-SELECT 1208 sequence is considerably faster than an EXPUNGE-LOGOUT or 1209 EXPUNGE-SELECT because no untagged EXPUNGE responses (which the 1210 client would probably ignore) are sent. 1212 Example: C: A341 CLOSE 1213 S: A341 OK CLOSE completed 1215 6.4.3. EXPUNGE Command 1217 Arguments: none 1219 Data: untagged responses: EXPUNGE 1221 Result: OK - expunge completed 1222 NO - expunge failure: can't expunge (e.g. permission 1223 denied) 1224 BAD - command unknown or arguments invalid 1226 The EXPUNGE command permanently removes from the currently 1227 selected mailbox all messages that have the \Deleted flag set. 1228 Before returning an OK to the client, an untagged EXPUNGE response 1229 is sent for each message that is removed. 1231 Example: C: A202 EXPUNGE 1232 S: * 3 EXPUNGE 1233 S: * 3 EXPUNGE 1234 S: * 5 EXPUNGE 1235 S: * 8 EXPUNGE 1236 S: A202 OK EXPUNGE completed 1238 Note: in this example, messages 3, 4, 7, and 11 had the 1239 \Deleted flag set. See the description of the EXPUNGE 1240 response for further explanation. 1242 Internet DRAFT IMAP4 October 30, 1994 1244 6.4.4. SEARCH Command 1246 Arguments: optional character set specification 1247 searching criteria (one or more) 1249 Data: mandatory untagged response: SEARCH 1251 Result: OK - search completed 1252 NO - search error: can't search that character set or 1253 criteria 1254 BAD - command unknown or arguments invalid 1256 The SEARCH command searches the mailbox for messages that match 1257 the given searching criteria. Searching criteria consist of one 1258 or more search keys. The untagged SEARCH response from the server 1259 contains a listing of message sequence numbers corresponding to 1260 those messages that match the searching criteria. 1262 When multiple keys are specified, the result is the intersection 1263 (AND function) of all the messages that match those keys. For 1264 example, the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers 1265 to all deleted messages from Smith that were placed in the mailbox 1266 since February 1, 1994. A search key may also be a parenthesized 1267 list of one or more search keys (e.g. for use with the OR and NOT 1268 keys). 1270 Server implementations MAY exclude [MIME-1] body parts with 1271 terminal content types other than TEXT and MESSAGE from 1272 consideration in SEARCH matching. 1274 The optional character set specification consists of the word 1275 "CHARSET" followed by a registered MIME character set. It 1276 indicates the character set of the strings that appear in the 1277 search criteria. [MIME-2] strings that appear in RFC 822/MIME 1278 message headers, and [MIME-1] content transfer encodings, MUST be 1279 decoded before matching. Except for US-ASCII, it is not required 1280 that any particular character set be supported. If the server 1281 does not support the specified character set, it MUST return a 1282 tagged NO response (not a BAD). 1284 In all search keys that use strings, a message matches the key if 1285 the string is a substring of the field. The matching is 1286 case-insensitive. 1288 The defined search keys are as follows. Refer to the Formal 1289 Syntax section for the precise syntactic definitions of the 1290 arguments. 1292 Internet DRAFT IMAP4 October 30, 1994 1294 Messages with message sequence numbers 1295 corresponding to the specified message sequence 1296 number set 1298 ALL All messages in the mailbox; the default initial 1299 key for ANDing. 1301 ANSWERED Messages with the \Answered flag set. 1303 BCC Messages that contain the specified string in the 1304 envelope structure's BCC field. 1306 BEFORE Messages whose internal date is earlier than the 1307 specified date. 1309 BODY Messages that contain the specified string in the 1310 body of the message. 1312 CC Messages that contain the specified string in the 1313 envelope structure's CC field. 1315 DELETED Messages with the \Deleted flag set. 1317 DRAFT Messages with the \Draft flag set. 1319 FLAGGED Messages with the \Flagged flag set. 1321 FROM Messages that contain the specified string in the 1322 envelope structure's FROM field. 1324 HEADER 1325 Messages that have a header with the specified 1326 field-name (as defined in [RFC-822]) and that 1327 contains the specified string in the [RFC-822] 1328 field-body. 1330 KEYWORD Messages with the specified keyword set. 1332 LARGER Messages with an RFC822.SIZE larger than the 1333 specified number of octets. 1335 NEW Messages that have the \Recent flag set but not the 1336 \Seen flag. This is functionally equivalent to 1337 "(RECENT UNSEEN)". 1339 NOT 1340 Messages that do not match the specified search 1342 Internet DRAFT IMAP4 October 30, 1994 1344 key. 1346 OLD Messages that do not have the \Recent flag set. 1347 This is functionally equivalent to "NOT RECENT" (as 1348 opposed to "NOT NEW"). 1350 ON Messages whose internal date is within the 1351 specified date. 1353 OR 1354 Messages that match either search key. 1356 RECENT Messages that have the \Recent flag set. 1358 SEEN Messages that have the \Seen flag set. 1360 SENTBEFORE 1361 Messages whose [RFC-822] Date: header is earlier 1362 than the specified date. 1364 SENTON Messages whose [RFC-822] Date: header is within the 1365 specified date. 1367 SENTSINCE 1368 Messages whose [RFC-822] Date: header is within or 1369 later than the specified date. 1371 SINCE Messages whose internal date is within or later 1372 than the specified date. 1374 SMALLER Messages with an RFC822.SIZE smaller than the 1375 specified number of octets. 1377 SUBJECT 1378 Messages that contain the specified string in the 1379 envelope structure's SUBJECT field. 1381 TEXT Messages that contain the specified string in the 1382 header or body of the message. 1384 TO Messages that contain the specified string in the 1385 envelope structure's TO field. 1387 UID 1388 Messages with unique identifiers corresponding to 1390 Internet DRAFT IMAP4 October 30, 1994 1392 the specified unique identifier set. 1394 UNANSWERED Messages that do not have the \Answered flag set. 1396 UNDELETED Messages that do not have the \Deleted flag set. 1398 UNDRAFT Messages that do not have the \Draft flag set. 1400 UNFLAGGED Messages that do not have the \Flagged flag set. 1402 UNKEYWORD 1403 Messages that do not have the specified keyword 1404 set. 1406 UNSEEN Messages that do not have the \Seen flag set. 1408 Example: C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith" 1409 S: * SEARCH 2 84 882 1410 S: A282 OK SEARCH completed 1412 6.4.5. FETCH Command 1414 Arguments: message set 1415 message data item names 1417 Data: untagged responses: FETCH 1419 Result: OK - fetch completed 1420 NO - fetch error: can't fetch that data 1421 BAD - command unknown or arguments invalid 1423 The FETCH command retrieves data associated with a message in the 1424 mailbox. The data items to be fetched may be either a single atom 1425 or a parenthesized list. The currently defined data items that 1426 can be fetched are: 1428 ALL Macro equivalent to: (FLAGS INTERNALDATE 1429 RFC822.SIZE ENVELOPE) 1431 BODY Non-extensible form of BODYSTRUCTURE. 1433 BODY[
] 1434 The text of a particular body section. The section 1435 specification is a set of one or more part numbers 1436 delimited by periods. 1438 Internet DRAFT IMAP4 October 30, 1994 1440 Single-part messages only have a part 1. 1442 Multipart messages are assigned consecutive part 1443 numbers, as they occur in the message. If a 1444 particular part is of type message or multipart, 1445 its parts must be indicated by a period followed by 1446 the part number within that nested multipart part. 1447 It is not permitted to fetch a multipart part 1448 itself, only its individual members. 1450 A part of type MESSAGE and subtype RFC822 also has 1451 nested parts. These are the parts of the MESSAGE 1452 part's body. Nested part 0 of a part of type 1453 MESSAGE and subtype RFC822 is the [RFC-822] header 1454 of the message. 1456 Every message has at least one part. 1458 Here is an example of a complex message 1459 with its associated section 1460 specifications: 1462 0 ([RFC-822] header of the message) 1463 MULTIPART/MIXED 1464 1 TEXT/PLAIN 1465 2 APPLICATION/OCTET-STREAM 1466 3 MESSAGE/RFC822 1467 3.0 ([RFC-822] header of the message) 1468 3.1 TEXT/PLAIN 1469 3.2 APPLICATION/OCTET-STREAM 1470 MULTIPART/MIXED 1471 4.1 IMAGE/GIF 1472 4.2 MESSAGE/RFC822 1473 4.2.0 ([RFC-822] header of the message) 1474 4.2.1 TEXT/PLAIN 1475 MULTIPART/ALTERNATIVE 1476 4.2.2.1 TEXT/PLAIN 1477 4.2.2.2 TEXT/RICHTEXT 1479 Note that there is no section 1480 specification for the Multi-part parts 1481 (no section 4 or 4.2.2). 1483 The \Seen flag is implicitly set; if this causes 1484 the flags to change they should be included as part 1485 of the fetch responses. 1487 Internet DRAFT IMAP4 October 30, 1994 1489 BODY.PEEK[
] 1490 An alternate form of BODY[section] that does not 1491 implicitly set the \Seen flag. 1493 BODYSTRUCTURE The [MIME-1] body structure of the message. This 1494 is computed by the server by parsing the [MIME-1] 1495 header lines. 1497 ENVELOPE The envelope structure of the message. This is 1498 computed by the server by parsing the [RFC-822] 1499 header into the component parts, defaulting various 1500 fields as necessary. 1502 FAST Macro equivalent to: (FLAGS INTERNALDATE 1503 RFC822.SIZE) 1505 FLAGS The flags that are set for this message. 1507 FULL Macro equivalent to: (FLAGS INTERNALDATE 1508 RFC822.SIZE ENVELOPE BODY) 1510 INTERNALDATE The date and time of final delivery of the message 1511 as defined by RFC 821. 1513 RFC822 The message in [RFC-822] format. The \Seen flag is 1514 implicitly set; if this causes the flags to change 1515 they should be included as part of the fetch 1516 responses. This is the concatenation of 1517 RFC822.HEADER and RFC822.TEXT. 1519 RFC822.PEEK An alternate form of RFC822 that does not 1520 implicitly set the \Seen flag. 1522 RFC822.HEADER The [RFC-822] format header of the message as 1523 stored on the server including the delimiting blank 1524 line between the header and the body. 1526 RFC822.HEADER.LINES 1527 All header lines (including continuation lines) of 1528 the [RFC-822] format header of the message with a 1529 field-name (as defined in [RFC-822]) that matches 1530 any of the strings in header_list. The matching is 1531 case-insensitive but otherwise exact. The 1532 delimiting blank line between the header and the 1533 body is always included. 1535 RFC822.HEADER.LINES.NOT 1536 All header lines (including continuation lines) of 1538 Internet DRAFT IMAP4 October 30, 1994 1540 the [RFC-822] format header of the message with a 1541 field-name (as defined in [RFC-822]) that does not 1542 match any of the strings in header_list. The 1543 matching is case-insensitive but otherwise exact. 1544 The delimiting blank line between the header and 1545 the body is always included. 1547 RFC822.SIZE The number of octets in the message, as expressed 1548 in [RFC-822] format. 1550 RFC822.TEXT The text body of the message, omitting the 1551 [RFC-822] header. The \Seen flag is implicitly 1552 set; if this causes the flags to change they should 1553 be included as part of the fetch responses. 1555 RFC822.TEXT.PEEK 1556 An alternate form of RFC822.TEXT that does not 1557 implicitly set the \Seen flag. 1559 UID The unique identifier for the message. 1561 Example: C: A654 FETCH 2:4 (FLAGS RFC822.HEADER.LINES (DATE FROM)) 1562 S: * 2 FETCH .... 1563 S: * 3 FETCH .... 1564 S: * 4 FETCH .... 1565 S: A003 OK FETCH completed 1567 6.4.6. PARTIAL Command 1569 Arguments: message sequence number 1570 message data item name 1571 position of first octet 1572 number of octets 1574 Data: untagged responses: FETCH 1576 Result: OK - partial completed 1577 NO - partial error: can't fetch that data 1578 BAD - command unknown or arguments invalid 1580 The PARTIAL command is equivalent to the associated FETCH command, 1581 with the added functionality that only the specified number of 1582 octets, beginning at the specified starting octet, are returned. 1583 Only a single message can be fetched at a time. The first octet 1584 of a message, and hence the minimum for the starting octet, is 1585 octet 1. 1587 Internet DRAFT IMAP4 October 30, 1994 1589 The following FETCH items are valid data for PARTIAL: RFC822, 1590 RFC822.HEADER, RFC822.TEXT, BODY[section], as well as any .PEEK 1591 forms of these. 1593 Any partial fetch that attempts to read beyond the end of the text 1594 is truncated as appropriate. If the starting octet is beyond the 1595 end of the text, an empty string is returned. 1597 The data are returned with the FETCH response. There is no 1598 indication of the range of the partial data in this response. It 1599 is not possible to stream multiple PARTIAL commands of the same 1600 data item without processing and synchronizing at each step, since 1601 streamed commands may be executed out of order. 1603 There is no requirement that partial fetches follow any sequence. 1604 For example, if a partial fetch of octets 1 through 10000 breaks 1605 in an awkward place for BASE64 decoding, it is permitted to 1606 continue with a partial fetch of 9987 through 19987, etc. 1608 The handling of the \Seen flag is the same as in the associated 1609 FETCH command. 1611 Example: C: A005 PARTIAL 4 RFC822 1 1024 1612 S: * 1 FETCH (RFC822 {1024} 1613 S: Return-Path: 1614 S: ... 1615 S: ......... FLAGS (\Seen)) 1616 S: A005 OK PARTIAL completed 1618 6.4.7. STORE Command 1620 Arguments: message set 1621 message data item name 1622 value for message data item 1624 Data: untagged responses: FETCH 1626 Result: OK - store completed 1627 NO - store error: can't store that data 1628 BAD - command unknown or arguments invalid 1630 The STORE command alters data associated with a message in the 1631 mailbox. Normally, STORE will return the updated value of the 1632 data with an untagged FETCH response. A suffix of ".SILENT" in 1633 the data item name prevents the untagged FETCH, and the server 1634 should assume that the client has determined the updated value 1635 itself or does not care about the updated value. 1637 Internet DRAFT IMAP4 October 30, 1994 1639 The currently defined data items that can be stored are: 1641 FLAGS 1642 Replace the flags for the message with the 1643 argument. The new value of the flags are returned 1644 as if a FETCH of those flags was done. 1646 FLAGS.SILENT 1647 Equivalent to FLAGS, but without returning a new 1648 value. 1650 +FLAGS 1651 Add the argument to the flags for the message. The 1652 new value of the flags are returned as if a FETCH 1653 of those flags was done. 1655 +FLAGS.SILENT 1656 Equivalent to +FLAGS, but without returning a new 1657 value. 1659 -FLAGS 1660 Remove the argument from the flags for the message. 1661 The new value of the flags are returned as if a 1662 FETCH of those flags was done. 1664 -FLAGS.SILENT 1665 Equivalent to -FLAGS, but without returning a new 1666 value. 1668 Example: C: A003 STORE 2:4 +FLAGS (\Deleted) 1669 S: * 2 FETCH FLAGS (\Deleted \Seen) 1670 S: * 3 FETCH FLAGS (\Deleted) 1671 S: * 4 FETCH FLAGS (\Deleted \Flagged \Seen) 1672 S: A003 OK STORE completed 1674 Internet DRAFT IMAP4 October 30, 1994 1676 6.4.8. COPY Command 1678 Arguments: message set 1679 mailbox name 1681 Data: no specific data for this command 1683 Result: OK - copy completed 1684 NO - copy error: can't copy those messages or to that 1685 name 1686 BAD - command unknown or arguments invalid 1688 The COPY command copies the specified message(s) to the specified 1689 destination mailbox. The flags and internal date of the 1690 message(s) SHOULD be preserved in the copy. 1692 If the destination mailbox does not exist, a server SHOULD return 1693 an error. It SHOULD NOT automatically create the mailbox. Unless 1694 it is certain that the destination mailbox can not be created, the 1695 server MUST send the response code "[TRYCREATE]" as the prefix of 1696 the text of the tagged NO response. This gives a hint to the 1697 client that it can attempt a CREATE command and retry the COPY if 1698 the CREATE is successful. 1700 If the COPY command is unsuccessful for any reason, server 1701 implementations MUST restore the destination mailbox to its state 1702 before the COPY attempt. 1704 Example: C: A003 COPY 2:4 MEETING 1705 S: A003 OK COPY completed 1707 6.4.9. UID Command 1709 Arguments: command name 1710 command arguments 1712 Data: untagged responses: FETCH, SEARCH 1714 Result: OK - UID command completed 1715 NO - UID command error 1716 BAD - command unknown or arguments invalid 1718 The UID command has two forms. In the first form, it takes as its 1719 arguments a COPY, FETCH, or STORE command with arguments 1720 appropriate for the associated command. However, instead of 1721 message sequence numbers, it uses unique identifiers in the 1722 message set argument to reference a particular message or range of 1724 Internet DRAFT IMAP4 October 30, 1994 1726 messages. 1728 In the second form, the UID command takes a SEARCH command with 1729 SEARCH command arguments. The interpretation of the arguments is 1730 the same as with SEARCH; however, the numbers returned in a SEARCH 1731 response for a UID SEARCH command are unique identifiers instead 1732 of message sequence numbers. For example, the command UID SEARCH 1733 1:100 UID 443:557 returns the unique identifiers corresponding to 1734 the intersection of the message sequence number set 1:100 and the 1735 UID set 443:557. 1737 A unique identifier of a message is a number, and is guaranteed 1738 not to refer to any other message in the mailbox. Unique 1739 identifiers are assigned in a strictly ascending fashion for each 1740 message added to the mailbox. Unlike message sequence numbers, 1741 unique identifiers persist across sessions. This permits a client 1742 to resynchronize its state from a previous session with the server 1743 (e.g. disconnected or offline access clients); this is discussed 1744 further in [IMAP-DISC]. 1746 Associated with every mailbox is a unique identifier validity 1747 value, which is sent in an UIDVALIDITY response code in an OK 1748 untagged response at message selection time. If unique 1749 identifiers from an earlier session fail to persist to this 1750 session, the unique identifier validity value MUST be greater than 1751 in the earlier session. 1753 Note: An example of a good value to use for the unique 1754 identifier validity value would be a 32-bit 1755 representation of the creation date/time of the mailbox. 1756 It is alright to use a constant such as 1, but only if 1757 it guaranteed that unique identifers will never be 1758 reused, even in the case of a mailbox being deleted and 1759 a new mailbox by the same name created at some future 1760 time. 1762 Message set ranges are permitted; however, there is no guarantee 1763 that unique identifiers be contiguous. A non-existent unique 1764 identifier within a message set range is ignored without any error 1765 message generated. 1767 The number after the "*" in an untagged FETCH response is always a 1768 message sequence number, not a unique identifier, even for a UID 1769 command response. However, server implementations MUST implicitly 1770 include the UID message data item as part of any FETCH response 1771 caused by a UID command, regardless of whether UID was specified 1773 Internet DRAFT IMAP4 October 30, 1994 1775 as a message data item to the FETCH. 1777 Example: C: A003 UID FETCH 4827313:4828442 FLAGS 1778 S: * 23 FETCH (FLAGS (\Seen) UID 4827313) 1779 S: * 24 FETCH (FLAGS (\Seen) UID 4827943) 1780 S: * 25 FETCH (FLAGS (\Seen) UID 4828442) 1781 S: A999 UID FETCH completed 1783 6.5. Client Commands - Experimental/Expansion 1785 6.5.1. X Command 1787 Arguments: implementation defined 1789 Data: implementation defined 1791 Result: OK - command completed 1792 NO - failure 1793 BAD - command unknown or arguments invalid 1795 Any command prefixed with an X is an experimental command. 1796 Commands which are not part of this specification, or a standard 1797 or standards-track revision of this specification, MUST use the X 1798 prefix. 1800 Any added untagged responses issued by an experimental command 1801 MUST also be prefixed with an X. Server implementations MUST NOT 1802 send any such untagged responses, unless the client requested it 1803 by issuing the associated experimental command. 1805 Example: C: a441 CAPABILITY 1806 S: * CAPABILITY IMAP4 XPIG-LATIN 1807 S: a441 OK CAPABILITY completed 1808 C: A442 XPIG-LATIN 1809 S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay 1810 S: A442 OK XPIG-LATIN ompleted-cay 1812 Internet DRAFT IMAP4 October 30, 1994 1814 7. Server Responses 1816 Server responses are in three forms: status responses, server data, 1817 and command continuation request. 1819 Server response data, identified by "Data:" in the response 1820 descriptions below, are described by function, not by syntax. The 1821 precise syntax of server response data is described in the Formal 1822 Syntax section. 1824 The client MUST be prepared to accept any response at all times. 1826 Status responses that are tagged indicate the completion result of a 1827 client command, and have a tag matching the command. 1829 Some status responses, and all server data, are untagged. An 1830 untagged response is indicated by the token "*" instead of a tag. 1831 Untagged status responses indicate server greeting, or server status 1832 that does not indicate the completion of a command. For historical 1833 reasons, untagged server data responses are also called "unsolicited 1834 data", although strictly speaking only unilateral server data is 1835 truly "unsolicited". 1837 Certain server data MUST be recorded by the client when it is 1838 received; this is noted in the description of that data. Such data 1839 conveys critical information which affects the interpretation of all 1840 subsequent commands and responses (e.g. updates reflecting the 1841 creation or destruction of messags). 1843 Other server data SHOULD be recorded for later reference; if the 1844 client does not need to record the data, or if recording the data has 1845 no obvious purpose (e.g. a SEARCH response when no SEARCH command is 1846 in progress), the data SHOULD be ignored. 1848 An example of unilateral untagged responses occurs when the IMAP 1849 connection is in selected state. In selected state, the server 1850 checks the mailbox for new messages as part of the execution of each 1851 command. If new messages are found, the server sends untagged EXISTS 1852 and RECENT responses reflecting the new size of the mailbox. Server 1853 implementations that offer multiple simultaneous access to the same 1854 mailbox should also send appropriate unilateral untagged FETCH and 1855 EXPUNGE responses if another agent changes the state of any message 1856 flags or expunges any messages. 1858 Command continuation request responses use the token "+" instead of a 1859 tag. These responses are sent by the server to indicate acceptance 1860 of an incomplete client command and readiness for the remainder of 1861 the command. 1863 Internet DRAFT IMAP4 October 30, 1994 1865 7.1. Server Responses - Status Responses 1867 Status responses may include an optional response code. A response 1868 code consists of data inside square brackets in the form of an atom, 1869 possibly followed by a space and arguments. The response code 1870 contains additional information or status codes for client software 1871 beyond the OK/NO/BAD condition, and are defined when there is a 1872 specific action that a client can take based upon the additional 1873 information. 1875 The currently defined response codes are: 1877 ALERT The human-readable text contains a special alert 1878 that MUST be presented to the user in a fashion 1879 that calls the user's attention to the message. 1881 PARSE The human-readable text represents an error in 1882 parsing the [RFC-822] or [MIME-1] headers of a 1883 message in the mailbox. 1885 PERMANENTFLAGS Followed by a parenthesized list of flags, 1886 indicates which of the known flags that the client 1887 may change permanently. Any flags that are in the 1888 FLAGS untagged response, but not the PERMANENTFLAGS 1889 list, can not be set permanently. If the client 1890 attempts to STORE a flag that is not in the 1891 PERMANENTFLAGS list, the server will either reject 1892 it with a NO reply or store the state for the 1893 remainder of the current session only. The 1894 PERMANENTFLAGS list may also include the special 1895 flag \*, which indicates that it is possible to 1896 create new keywords by attempting to store those 1897 flags in the mailbox. 1899 READ-ONLY The mailbox is selected read-only, or its access 1900 while selected has changed from read-write to 1901 read-only. 1903 READ-WRITE The mailbox is selected read-write, or its access 1904 while selected has changed from read-only to 1905 read-write. 1907 TRYCREATE An APPEND or COPY attempt is failing because the 1908 target mailbox does not exist (as opposed to some 1909 other reason). This is a hint to the client that 1910 the operation may succeed if the mailbox is first 1912 Internet DRAFT IMAP4 October 30, 1994 1914 created by the CREATE command. 1916 UIDVALIDITY Followed by a decimal number, indicates the unique 1917 identifier validity value. See the description of 1918 the UID command for more detail. 1920 UNSEEN Followed by a decimal number, indicates the number 1921 of the first message without the \Seen flag set. 1923 Additional response codes defined by particular client or server 1924 implementations should be prefixed with an "X" until they are 1925 added to a revision of this protocol. Client implementations 1926 should ignore response codes that they do not recognize. 1928 7.1.1. OK Response 1930 Data: optional response code 1931 human-readable text 1933 The OK response indicates an information message from the server. 1934 When tagged, it indicates successful completion of the associated 1935 command. The human-readable text may be presented to the user as 1936 an information message. The untagged form indicates an 1937 information-only message; the nature of the information may be 1938 indicated by a response code. 1940 The untagged form is also used as one of three possible greetings 1941 at session startup. It indicates that the session is not yet 1942 authenticated and that a LOGIN command is needed. 1944 Example: S: * OK IMAP4 server ready 1945 C: A001 LOGIN fred blurdybloop 1946 S: * OK [ALERT] System shutdown in 10 minutes 1947 S: A001 OK LOGIN Completed 1949 7.1.2. NO Response 1951 Data: optional response code 1952 human-readable text 1954 The NO response indicates an operational error message from the 1955 server. When tagged, it indicates unsuccessful completion of the 1956 associated command. The untagged form indicates a warning; the 1957 command may still complete successfully. The human-readable text 1959 Internet DRAFT IMAP4 October 30, 1994 1961 describes the condition. 1963 Example: C: A222 COPY 1:2 owatagusiam 1964 S: * NO Disk is 98% full, please delete unnecessary data 1965 S: A222 OK COPY completed 1966 C: A222 COPY 3:200 blurdybloop 1967 S: * NO Disk is 98% full, please delete unnecessary data 1968 S: * NO Disk is 99% full, please delete unnecessary data 1969 S: A222 NO COPY failed: disk is full 1971 7.1.3. BAD Response 1973 Data: optional response code 1974 human-readable text 1976 The BAD response indicates an error message from the server. When 1977 tagged, it reports a protocol-level error in the client's command; 1978 the tag indicates the command that caused the error. The untagged 1979 form indicates a protocol-level error for which the associated 1980 command can not be determined; it may also indicate an internal 1981 server failure. The human-readable text describes the condition. 1983 Example: C: ...very long command line... 1984 S: * BAD Command line too long 1985 C: ...empty line... 1986 S: * BAD Empty command line 1987 C: A443 EXPUNGE 1988 S: * BAD Disk crash, attempting salvage to a new disk! 1989 S: * OK Salvage successful, no data lost 1990 S: A443 OK Expunge completed 1992 7.1.4. PREAUTH Response 1994 Data: optional response code 1995 human-readable text 1997 The PREAUTH response is always untagged, and is one of three 1998 possible greetings at session startup. It indicates that the 1999 session has already been authenticated by external means and thus 2000 no LOGIN command is needed. 2002 Example: S: * PREAUTH IMAP4 server ready and logged in as Smith 2004 Internet DRAFT IMAP4 October 30, 1994 2006 7.1.5. BYE Response 2008 Data: optional response code 2009 human-readable text 2011 The BYE response is always untagged, and indicates that the server 2012 is about to close the connection. The human-readable text may be 2013 displayed to the user in a status report by the client. The BYE 2014 response may be sent as part of a normal logout sequence, or as a 2015 panic shutdown announcement by the server. It is also used by 2016 some server implementations as an announcement of an inactivity 2017 autologout. 2019 This response is also used as one of three possible greetings at 2020 session startup. It indicates that the server is not willing to 2021 accept a session from this client. 2023 Example: S: * BYE Autologout; idle for too long 2025 7.2. Server Responses - Server and Mailbox Status 2027 These responses are always untagged. This is how server data are 2028 transmitted from the server to the client, often as a result of a 2029 command with the same name. 2031 7.2.1. CAPABILITY Response 2033 Data: capability listing 2035 The CAPABILITY response occurs as a result of a CAPABILITY 2036 command. The capability listing contains a space-separated 2037 listing of capability names that the server supports. The first 2038 name in the capability listing MUST be the atom "IMAP4". 2040 A capability name other than IMAP4 indicates that the server 2041 supports an extension, revision, or amendment to the IMAP4 2042 protocol. Server responses MUST conform to this document until 2043 the client issues a command that uses the associated capability. 2045 Capability names MUST either begin with "X" or be standard or 2046 standards-track IMAP4 extensions, revisions, or amendments 2047 registered with IANA. A server MUST NOT offer unregistered or 2048 non-standard capability names, unless such names are prefixed with 2049 an "X". 2051 Client implementations SHOULD NOT require any capability name 2053 Internet DRAFT IMAP4 October 30, 1994 2055 other than "IMAP4", and MUST ignore any unknown capability names. 2057 Example: S: * CAPABILITY IMAP4 XPIG-LATIN 2059 7.2.2. LIST Response 2061 Data: name attributes 2062 hierarchy delimiter 2063 name 2065 The LIST response occurs as a result of a LIST command. It 2066 returns a single name that matches the LIST specification. There 2067 may be multiple LIST responses for a single LIST command. 2069 Four name attributes are defined: 2071 \Noinferiors It is not possible for any child levels of 2072 hierarchy to exist under this name; no child levels 2073 exist now and none can be created in the future. 2075 \Noselect It is not possible to use this name as a selectable 2076 mailbox. 2078 \Marked The mailbox has been marked "interesting" by the 2079 server; the mailbox probably contains messages that 2080 have been added since the last time the mailbox was 2081 selected. 2083 \Unmarked The mailbox does not contain any additional 2084 messages since the last time the mailbox was 2085 selected. 2087 If it is not feasible for the server to determine whether the 2088 mailbox is "interesting" or not, or if the name is a \Noselect 2089 name, the server should not send either \Marked or \Unmarked. 2091 The hierarchy delimiter is a character used to delimit levels of 2092 hierarchy in a mailbox name. A client may use it to create child 2093 mailboxes, and to search higher or lower levels of naming 2094 hierarchy. All children of a top-level hierarchy node must use 2095 the same separator character. A NIL hierarchy delimiter means 2096 that no hierarchy exists; the name is a "flat" name. 2098 The name represents an unambiguous left-to-right hierarchy, and 2099 MUST be valid for use as a reference in LIST and LSUB commands. 2100 Unless \Noselect is indicated, the name must also be valid as an 2101 argument for commands, such as SELECT, that accept mailbox names. 2103 Internet DRAFT IMAP4 October 30, 1994 2105 Example: S: * LIST (\Noselect) "/" ~/Mail/foo 2107 7.2.3. LSUB Response 2109 Data: name attributes 2110 hierarchy delimiter 2111 name 2113 The LSUB response occurs as a result of an LSUB command. It 2114 returns a single name that matches the LSUB specification. There 2115 may be multiple LSUB responses for a single LSUB command. The 2116 data is identical in format to the LIST response. 2118 Example: S: * LSUB () "." #news.comp.mail.misc 2120 7.2.4. SEARCH Response 2122 Data: zero or more numbers 2124 The SEARCH response occurs as a result of a SEARCH or UID SEARCH 2125 command. The number(s) refer to those messages that match the 2126 search criteria. For SEARCH, these are message sequence numbers; 2127 for UID SEARCH, these are unique identifiers. Each number is 2128 delimited by a space. 2130 Example: S: * SEARCH 2 3 6 2132 7.2.5. FLAGS Response 2134 Data: flag parenthesized list 2136 The FLAGS response occurs as a result of a SELECT or EXAMINE 2137 command. The flag parenthesized list identifies the flags (at a 2138 minimum, the system-defined flags) that are applicable for this 2139 mailbox. Flags other than the system flags may also exist, 2140 depending on server implementation. 2142 The update from the FLAGS response MUST be recorded by the client. 2144 Example: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 2146 Internet DRAFT IMAP4 October 30, 1994 2148 7.3. Server Responses - Message Status 2150 These responses are always untagged. This is how message data are 2151 transmitted from the server to the client, often as a result of a 2152 command with the same name. Immediately following the "*" token is a 2153 number that represents either a message sequence number or a message 2154 count. 2156 7.3.1. EXISTS Response 2158 Data: none 2160 The EXISTS response reports the number of messages in the mailbox. 2161 This response occurs as a result of a SELECT or EXAMINE command, 2162 and if the size of the mailbox changes (e.g. new mail). 2164 The update from the EXISTS response MUST be recorded by the 2165 client. 2167 Example: S: * 23 EXISTS 2169 7.3.2. RECENT Response 2171 Data: none 2173 The RECENT response reports the number of messages that have 2174 arrived since the previous time a SELECT command was done on this 2175 mailbox. This response occurs as a result of a SELECT or EXAMINE 2176 command, and if the size of the mailbox changes (e.g. new mail). 2178 The update from the RECENT response MUST be recorded by the 2179 client. 2181 Example: S: * 5 RECENT 2183 7.3.3. EXPUNGE Response 2185 Data: none 2187 The EXPUNGE response reports that the specified message sequence 2188 number has been permanently removed from the mailbox. The message 2189 sequence number for each successive message in the mailbox is 2190 immediately decremented by 1, and this decrement is reflected in 2191 message sequence numbers in subsequent responses (including other 2192 untagged EXPUNGE responses). 2194 Internet DRAFT IMAP4 October 30, 1994 2196 As a result of the immediate decrement rule, message sequence 2197 numbers that appear in a set of successive EXPUNGE responses 2198 depend upon whether the messages are removed starting from lower 2199 numbers to higher numbers, or from higher numbers to lower 2200 numbers. For example, if the last 5 messages in a 9-message 2201 mailbox are expunged; a "lower to higher" server will send five 2202 untagged EXPUNGE responses for message sequence number 5, whereas 2203 a "higher to lower server" will send successive untagged EXPUNGE 2204 responses for message sequence numbers 9, 8, 7, 6, and 5. 2206 An EXPUNGE response MUST NOT be sent when no command is in 2207 progress; nor while responding to a FETCH, STORE, or SEARCH 2208 command. This rule is necessary to prevent a loss of 2209 synchronization of message sequence numbers between client and 2210 server. 2212 The update from the EXPUNGE response MUST be recorded by the 2213 client. 2215 Example: S: * 44 EXPUNGE 2217 7.3.4. FETCH Response 2219 Data: message data 2221 The FETCH response returns data about a message to the client. 2222 The data are pairs of data item names and their values in 2223 parentheses. This response occurs as the result of a FETCH or 2224 STORE command, as well as by unilateral server decision (e.g. flag 2225 updates). 2227 The current data items are: 2229 BODY A form of BODYSTRUCTURE without extension data. 2231 BODY[section] A string expressing the body contents of the 2232 specified section. The string should be 2233 interpreted by the client according to the content 2234 transfer encoding, body type, and subtype. 2236 8-bit textual data is permitted if a character set 2237 identifier is part of the body parameter 2238 parenthesized list for this section. 2240 Non-textual data such as binary data must be 2241 transfer encoded into a textual form such as BASE64 2242 prior to being sent to the client. To derive the 2244 Internet DRAFT IMAP4 October 30, 1994 2246 original binary data, the client must decode the 2247 transfer encoded string. 2249 BODYSTRUCTURE A parenthesized list that describes the body 2250 structure of a message. This is computed by the 2251 server by parsing the [RFC-822] header and body 2252 into the component parts, defaulting various fields 2253 as necessary. 2255 Multiple parts are indicated by parenthesis 2256 nesting. Instead of a body type as the first 2257 element of the parenthesized list there is a nested 2258 body. The second element of the parenthesized list 2259 is the multipart subtype (mixed, digest, parallel, 2260 alternative, etc.). 2262 Extension data follows the multipart subtype. 2263 Extension data is never returned with the BODY 2264 fetch, but may be returned with a BODYSTRUCTURE 2265 fetch. Extension data, if present, must be in the 2266 defined order. 2268 The extension data of a multipart body part are in 2269 the following order: 2271 body parameter parenthesized list 2272 A parenthesized list of attribute/value pairs 2273 [e.g. (foo bar baz rag) where "bar" is the value 2274 of "foo" and "rag" is the value of "baz"] as 2275 defined in [MIME-1]. 2277 Any following extension data are not yet defined in 2278 this version of the protocol. Such extension data 2279 may consist of zero or more NILs, strings, numbers, 2280 or potentially nested parenthesized lists of such 2281 data. Client implementations that do a 2282 BODYSTRUCTURE fetch MUST be prepared to accept such 2283 extension data. Server implementations MUST NOT 2284 send such extension data until it has been defined 2285 by a revision of this protocol. 2287 The basic fields of a non-multipart body part are 2288 in the following order: 2290 body type 2291 A string giving the content type name as defined 2292 in [MIME-1]. 2294 Internet DRAFT IMAP4 October 30, 1994 2296 body subtype 2297 A string giving the content subtype name as 2298 defined in [MIME-1]. 2300 body parameter parenthesized list 2301 A parenthesized list of attribute/value pairs 2302 [e.g. (foo bar baz rag) where "bar" is the value 2303 of "foo" and "rag" is the value of "baz"] as 2304 defined in [MIME-1]. 2306 body id 2307 A string giving the content id as defined in 2308 [MIME-1]. 2310 body description 2311 A string giving the content description as 2312 defined in [MIME-1]. 2314 body encoding 2315 A string giving the content transfer encoding as 2316 defined in [MIME-1]. 2318 body size 2319 A number giving the size of the body in octets. 2320 Note that this size is the size in its transfer 2321 encoding and not the resulting size after any 2322 decoding. 2324 A body type of type MESSAGE and subtype RFC822 2325 contains, immediately after the basic fields, the 2326 envelope structure, body structure, and size in 2327 text lines of the encapsulated message. 2329 A body type of type TEXT contains, immediately 2330 after the basic fields, the size of the body in 2331 text lines. Note that this size is the size in its 2332 transfer encoding and not the resulting size after 2333 any decoding. 2335 Extension data follows the basic fields and the 2336 type-specific fields listed above. Extension data 2337 is never returned with the BODY fetch, but may be 2338 returned with a BODYSTRUCTURE fetch. Extension 2339 data, if present, must be in the defined order. 2341 The extension data of a non-multipart body part are 2342 in the following order: 2344 Internet DRAFT IMAP4 October 30, 1994 2346 body MD5 2347 A string giving the content MD5 value as defined 2348 in [MIME-1]. 2350 Any following extension data are not yet defined in 2351 this version of the protocol, and would be as 2352 described above under multipart extension data. 2354 ENVELOPE A parenthesized list that describes the envelope 2355 structure of a message. This is computed by the 2356 server by parsing the [RFC-822] header into the 2357 component parts, defaulting various fields as 2358 necessary. 2360 The fields of the envelope structure are in the 2361 following order: date, subject, from, sender, 2362 reply-to, to, cc, bcc, in-reply-to, and message-id. 2363 The date, subject, in-reply-to, and message-id 2364 fields are strings. The from, sender, reply-to, 2365 to, cc, and bcc fields are parenthesized lists of 2366 address structures. 2368 An address structure is a parenthesized list that 2369 describes an electronic mail address. The fields 2370 of an address structure are in the following order: 2371 personal name, [SMTP] at-domain-list (source 2372 route), mailbox name, and host name. 2374 [RFC-822] group syntax is indicated by a special 2375 form of address structure in which the host name 2376 field is NIL. If the mailbox name field is also 2377 NIL, this is an end of group marker (semi-colon in 2378 RFC 822 syntax). If the mailbox name field is 2379 non-NIL, this is a start of group marker, and the 2380 mailbox name field holds the group name phrase. 2382 Any field of an envelope or address structure that 2383 is not applicable is presented as NIL. Note that 2384 the server must default the reply-to and sender 2385 fields from the from field; a client is not 2386 expected to know to do this. 2388 FLAGS A parenthesized list of flags that are set for this 2389 message. This may include keywords as well as the 2390 following system flags: 2392 Internet DRAFT IMAP4 October 30, 1994 2394 \Seen Message has been read 2396 \Answered Message has been answered 2398 \Flagged Message is "flagged" for urgent/special 2399 attention 2401 \Deleted Message is "deleted" for removal by 2402 later EXPUNGE 2404 \Draft Message has not completed composition 2405 (marked as a draft). 2407 as well as the following special flag, which may be 2408 fetched but not stored: 2410 \Recent Message has arrived since the previous 2411 time this mailbox was selected. 2413 INTERNALDATE A string containing the date and time of final 2414 delivery of the message as defined by [SMTP]. 2416 RFC822 A string expressing the message in [RFC-822] 2417 format. The header portion of the message must be 2418 7-bit. 8-bit characters are permitted only in the 2419 non-header portion of the message only if there are 2420 [MIME-1] data in the message that identify the 2421 character set of the message. 2423 RFC822.HEADER A string expressing the [RFC-822] format header of 2424 the message, including the delimiting blank line 2425 between the header and the body. The entire string 2426 must be 7-bit; 8-bit characters are not permitted 2427 in headers. RFC822.HEADER is used to return data 2428 for the RFC822.HEADER, RFC822.HEADER.LINES, and 2429 RFC822.HEADER.LINES.NOT FETCH data items. Note 2430 that a blank line is always included regardless of 2431 header line restrictions. 2433 RFC822.SIZE A number expressing the number of octets in the 2434 message in [RFC-822] format. 2436 RFC822.TEXT A string expressing the text body of the message, 2437 omitting the [RFC-822] header. 8-bit characters 2438 are permitted only if there are [MIME-1] data in 2439 the message that identify the character set of the 2441 Internet DRAFT IMAP4 October 30, 1994 2443 message. 2445 UID A number expressing the unique identifier of the 2446 message. 2448 Example: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827) 2450 7.3.5. Obsolete Responses 2452 In addition to the responses listed in here, client implementations 2453 SHOULD accept the obsolete COPY and STORE responses described in 2454 Appendix B. 2456 7.4. Server Responses - Command Continuation Request 2458 The command completion request response is indicated by a "+" token 2459 instead of a tag. This form of response indicates that the server is 2460 ready to accept the continuation of a command from the client. The 2461 remainder of this response is a line of text. 2463 This response is used in the AUTHORIZATION command to transmit server 2464 data to the client, and request additional client data. This 2465 response is also used if an argument to any command is a literal. 2467 The client is not permitted to send the octets of the literal unless 2468 the server indicates that it expects it. This permits the server to 2469 process commands and reject errors on a line-by-line basis. The 2470 remainder of the command, including the CRLF that terminates a 2471 command, follows the octets of the literal. If there are any 2472 additional command arguments the literal octets are followed by a 2473 space and those arguments. 2475 Example: C: A001 LOGIN {11} 2476 S: + Ready for additional command text 2477 C: FRED FOOBAR {7} 2478 S: + Ready for additional command text 2479 C: fat man 2480 S: A001 OK LOGIN completed 2481 C: A044 BLURDYBLOOP {102856} 2482 S: A044 BAD No such command as "BLURDYBLOOP" 2484 Internet DRAFT IMAP4 October 30, 1994 2486 8. Sample IMAP4 session 2488 The following is a transcript of an IMAP4 session. A long line in 2489 this sample is broken for editorial clarity. 2491 S: * OK IMAP4 Service Ready 2492 C: a001 login mrc secret 2493 S: a001 OK LOGIN completed 2494 C: a002 select inbox 2495 S: * 18 EXISTS 2496 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 2497 S: * 2 RECENT 2498 S: * OK [UNSEEN 17] Message 17 is the first unseen message 2499 S: * OK [UIDVALIDITY 3857529045] UIDs valid 2500 S: a002 OK [READ-WRITE] SELECT completed 2501 C: a003 fetch 12 full 2502 S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "14-Jul-1993 02:44:25 -0700" 2503 RFC822.SIZE 4282 ENVELOPE ("Wed, 14 Jul 1993 02:23:25 -0700 (PDT)" 2504 "IMAP4 WG mtg summary and minutes" 2505 (("Terry Gray" NIL "gray" "cac.washington.edu")) 2506 (("Terry Gray" NIL "gray" "cac.washington.edu")) 2507 (("Terry Gray" NIL "gray" "cac.washington.edu")) 2508 ((NIL NIL "imap" "cac.washington.edu")) 2509 ((NIL NIL "minutes" "CNRI.Reston.VA.US") 2510 ("John Klensin" NIL "KLENSIN" "INFOODS.MIT.EDU")) NIL NIL 2511 "") 2512 BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92)) 2513 S: a003 OK FETCH completed 2514 C: a004 fetch 12 rfc822.header 2515 S: * 12 FETCH (RFC822.HEADER {346} 2516 S: Date: Wed, 14 Jul 1993 02:23:25 -0700 (PDT) 2517 S: From: Terry Gray 2518 S: Subject: IMAP4 WG mtg summary and minutes 2519 S: To: imap@cac.washington.edu 2520 S: cc: minutes@CNRI.Reston.VA.US, John Klensin 2521 S: Message-Id: 2522 S: MIME-Version: 1.0 2523 S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 2524 S: 2525 S: ) 2526 S: a004 OK FETCH completed 2527 C: a005 store 12 +flags \deleted 2528 S: * 12 FETCH (FLAGS (\Seen \Deleted)) 2529 S: a005 OK +FLAGS completed 2530 C: a006 logout 2531 S: * BYE IMAP4 server terminating connection 2532 S: a006 OK LOGOUT completed 2534 Internet DRAFT IMAP4 October 30, 1994 2536 9. Formal Syntax 2538 The following syntax specification uses the augmented Backus-Naur 2539 Form (BNF) notation as specified in [RFC-822] with one exception; the 2540 delimiter used with the "#" construct is a single space (SPACE) and 2541 not a comma. 2543 Except as noted otherwise, all alphabetic characters are 2544 case-insensitive. The use of upper or lower case characters to 2545 define token strings is for editorial clarity only. Implementations 2546 MUST accept these strings in a case-insensitive fashion. 2548 Syntax marked as obsolete may be encountered with implementations 2549 written for an earlier version of this protocol (e.g. IMAP2). New 2550 implementations SHOULD accept obsolete syntax as input, but MUST NOT 2551 otherwise use such syntax. 2553 address ::= "(" addr_name SPACE addr_adl SPACE addr_mailbox 2554 SPACE addr_host ")" 2556 addr_adl ::= nstring 2558 addr_host ::= nstring 2559 ;; NIL indicates [RFC-822] group syntax 2561 addr_mailbox ::= nstring 2562 ;; NIL indicates end of [RFC-822] group; if non-NIL 2563 ;; and addr_host is NIL, holds [RFC-822] group name 2565 addr_name ::= nstring 2567 alpha ::= "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" / "I" / 2568 "J" / "K" / "L" / "M" / "N" / "O" / "P" / "Q" / "R" / 2569 "S" / "T" / "U" / "V" / "W" / "X" / "Y" / "Z" / 2570 "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / "i" / 2571 "j" / "k" / "l" / "m" / "n" / "o" / "p" / "q" / "r" / 2572 "s" / "t" / "u" / "v" / "w" / "x" / "y" / "z" / 2573 ;; Case-sensitive 2575 append ::= "APPEND" SPACE mailbox [SPACE flag_list] 2576 [SPACE date_time] SPACE literal 2578 astring ::= atom / string 2580 atom ::= 1*ATOM_CHAR 2582 ATOM_CHAR ::= 2584 Internet DRAFT IMAP4 October 30, 1994 2586 atom_specials ::= "(" / ")" / "{" / SPACE / CTLs / list_wildcards / 2587 quoted_specials 2589 authenticate ::= "AUTHENTICATE" SPACE auth_type *(CRLF base64) 2591 auth_type ::= atom 2593 base64 ::= *(4base64_char) [base64_terminal] 2595 base64_char ::= alpha / digit / "+" / "/" 2597 base64_terminal ::= (2base64_char "==") / (3base64_char "=") 2599 body ::= "(" body_type_1part / body_type_mpart ")" 2601 body_extension ::= nstring / number / "(" 1#body_extension ")" 2602 ;; Future expansion. Client implementations 2603 ;; MUST accept body_extension fields. Server 2604 ;; implementations MUST NOT generate 2605 ;; body_extension fields except as defined by 2606 ;; future standard or standards-track 2607 ;; revisions of this specification. 2609 body_ext_1part ::= body_fld_md5 [SPACE 1#body_extension] 2610 ;; MUST NOT be returned on non-extensible "BODY" fetch 2612 body_ext_mpart ::= body_fld_param [SPACE 1#body_extension]] 2613 ;; MUST NOT be returned on non-extensible "BODY" fetch 2615 body_fields ::= body_fld_param SPACE body_fld_id SPACE body_fld_desc 2616 SPACE body_fld_enc SPACE body_fld_octets 2618 body_fld_desc ::= nstring 2620 body_fld_enc ::= (<"> ("7BIT" / "8BIT" / "BINARY" / "BASE64"/ 2621 "QUOTED-PRINTABLE") <">) / string 2623 body_fld_id ::= nstring 2625 body_fld_lines ::= number 2627 body_fld_md5 ::= nstring 2629 body_fld_octets ::= number 2631 body_fld_param ::= "(" 1#(string string) ")" / nil 2633 body_fld_subtyp ::= string 2635 Internet DRAFT IMAP4 October 30, 1994 2637 body_type_1part ::= (body_type_basic / body_type_msg / body_type_text) 2638 [SPACE body_ext_1part] 2640 body_type_basic ::= (<"> ("APPLICATION" / "AUDIO" / "IMAGE" / "MESSAGE" / 2641 "VIDEO") <">) / string) SPACE body_fld_subtyp SPACE 2642 body_fields 2643 ;; MESSAGE subtype MUST NOT be "RFC822" 2645 body_type_mpart ::= 1*body SPACE body_fld_subtyp [SPACE body_ext_mpart] 2647 body_type_msg ::= <"> "MESSAGE" <"> SPACE <"> "RFC822" <"> SPACE 2648 body_fields SPACE envelope SPACE body SPACE 2649 body_fld_lines 2651 body_type_text ::= <"> "TEXT" <"> SPACE body_fld_subtyp SPACE body_fields 2652 SPACE body_fld_lines 2654 capability ::= atom 2655 ;; Must begin with "X" or be registered with IANA 2656 ;; as standard or standards-track 2658 capability_data ::= "CAPABILITY" SPACE "IMAP4" [SPACE 1#capability] 2660 CHAR ::= 2662 CHAR8 ::= 2664 command ::= tag SPACE (command_any / command_auth / 2665 command_nonauth / command_select) CRLF 2666 ;; Modal based on state 2668 command_any ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command 2669 ;; Valid in all states 2671 command_auth ::= append / create / delete / examine / find / list / 2672 lsub / rename / select / subscribe / unsubscribe / 2673 ;; Valid only when in Authenticated or Selected state 2675 command_nonauth ::= login / authenticate 2676 ;; Valid only when in Non-Authenticated state 2678 command_select ::= "CHECK" / "CLOSE" / "EXPUNGE" / 2679 copy / fetch / partial / store / uid / search 2680 ;; Valid only when in Selected state 2682 continue_req ::= "+" SPACE (resp_text / base64) 2684 copy ::= "COPY" SPACE set SPACE mailbox 2686 Internet DRAFT IMAP4 October 30, 1994 2688 CR ::= 2690 create ::= "CREATE" SPACE mailbox 2691 ;; Use of INBOX gives a NO error 2693 CRLF ::= CR LF 2695 CTL ::= 2697 date ::= date_text / <"> date_text <"> 2699 date_day ::= 1*2digit 2700 ;; Day of month 2702 date_day_fixed ::= (SPACE digit) / 2digit 2703 ;; Fixed-format version of date_day 2705 date_month ::= "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" / 2706 "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec" 2708 date_text ::= date_day "-" date_month "-" (date_year / date_year_old) 2710 date_year ::= 4digit 2712 date_year_old ::= 2digit 2713 ;; OBSOLETE, (year - 1900) 2715 date_time ::= <"> (date_time_new / date_time_old) <"> 2717 date_time_new ::= date_day_fixed "-" date_month "-" date_year SPACE 2718 time SPACE zone 2720 date_time_old ::= date_day_fixed "-" date_month "-" date_year_old SPACE 2721 time "-" zone_old 2722 ;; OBSOLETE 2724 delete ::= "DELETE" SPACE mailbox 2725 ;; Use of INBOX gives a NO error 2727 digit ::= "0" / digit_nz 2729 digit_nz ::= "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" 2731 envelope ::= "(" env_date SPACE env_subject SPACE env_from SPACE 2732 env_sender SPACE env_reply-to SPACE env_to SPACE 2733 env_cc SPACE env_bcc SPACE env_in-reply-to SPACE 2734 env_message-id ")" 2736 Internet DRAFT IMAP4 October 30, 1994 2738 env_bcc ::= "(" 1*address ")" / nil 2740 env_cc ::= "(" 1*address ")" / nil 2742 env_date ::= nstring 2744 env_from ::= "(" 1*address ")" / nil 2746 env_in-reply-to ::= nstring 2748 env_message-id ::= nstring 2750 env_reply-to ::= "(" 1*address ")" / nil 2752 env_sender ::= "(" 1*address ")" / nil 2754 env_subject ::= nstring 2756 env_to ::= "(" 1*address ")" / nil 2758 examine ::= "EXAMINE" SPACE mailbox 2760 fetch ::= "FETCH" SPACE set SPACE ("ALL" / "FULL" / 2761 "FAST" / fetch_att / "(" 1#fetch_att ")") 2763 fetch_att ::= "BODY" / "BODYSTRUCTURE" / 2764 "BODY" [".PEEK"] "[" section "]" / "ENVELOPE" / 2765 "FLAGS" / "INTERNALDATE" / "UID" / 2766 "RFC822" (([".TEXT"] [".PEEK"]) / ".SIZE" / 2767 (".HEADER" [".LINES" [".NOT"] SPACE header_list]) 2769 find ::= "FIND" SPACE ["ALL."] "MAILBOXES" SPACE list_mailbox 2770 ;; OBSOLETE 2772 flag ::= "\Answered" / "\Flagged" / "\Deleted" / "\Seen" / 2773 "\Draft" / flag_keyword / flag_extension 2775 flag_extension ::= "\" atom 2776 ;; Future expansion. Client implementations 2777 ;; MUST accept flag_extension flags. Server 2778 ;; implementations MUST NOT generate 2779 ;; flag_extension flags except as defined by 2780 ;; future standard or standards-track 2781 ;; revisions of this specification. 2783 flag_keyword ::= atom 2785 flag_list ::= "(" #flag ")" 2787 Internet DRAFT IMAP4 October 30, 1994 2789 greeting ::= "*" SPACE (resp_cond_auth / resp_cond_bye) CRLF 2791 header_line ::= astring 2793 header_list ::= "(" 1#header_line ")" 2795 LF ::= 2797 list ::= "LIST" SPACE mailbox SPACE list_mailbox 2799 list_mailbox ::= 1*(ATOM_CHAR / list_wildcards) / string 2801 list_wildcards ::= "%" / "*" 2803 literal ::= "{" number "}" CRLF *CHAR8 2804 ;; The number represents the number of CHAR8 octets 2806 login ::= "LOGIN" SPACE userid SPACE password 2808 lsub ::= "LSUB" SPACE mailbox SPACE list_mailbox 2810 mailbox ::= "INBOX" / astring 2811 ;; INBOX is case-insensitive. Other names may be 2812 ;; case-sensitive depending on implementation. 2814 mailbox_data ::= "FLAGS" SPACE flag_list / "LIST" SPACE mailbox_list / 2815 "LSUB" SPACE mailbox_list / "MAILBOX" SPACE text / 2816 "SEARCH" [SPACE 1#nz_number] / 2817 number SPACE "EXISTS" / number SPACE "RECENT" 2819 mailbox_list ::= "(" #("\Marked" / "\Noinferiors" / "\Noselect" / 2820 "\Unmarked" / flag_extension) ")" SPACE 2821 (<"> QUOTED_CHAR <"> / nil) SPACE mailbox 2823 message_data ::= nz_number SPACE ("EXPUNGE" / 2824 ("FETCH" SPACE msg_fetch) / msg_obsolete) 2826 msg_fetch ::= "(" 1#("BODY" SPACE body / "BODYSTRUCTURE" SPACE body / 2827 "BODY[" section "]" SPACE nstring / 2828 "ENVELOPE" SPACE envelope / 2829 "FLAGS" SPACE "(" #(flag / "\Recent") ")" / 2830 "INTERNALDATE" SPACE date_time / 2831 "RFC822" [".HEADER" / ".TEXT"] SPACE nstring / 2832 "RFC822.SIZE" SPACE number / "UID" SPACE uniqueid) ")" 2834 msg_obsolete ::= "COPY" / ("STORE" SPACE msg_fetch) 2835 ;; OBSOLETE untagged data responses 2837 Internet DRAFT IMAP4 October 30, 1994 2839 nil ::= "NIL" 2841 nstring ::= string / nil 2843 number ::= 1*digit 2844 ;; Unsigned 32-bit integer (0 <= n < 4,294,967,296) 2846 nz_number ::= digit_nz *digit 2847 ;; Non-zero unsigned 32-bit integer 2848 ;; (0 < n < 4,294,967,296) 2850 partial ::= "PARTIAL" SPACE nz_number SPACE fetch_att_text SPACE 2851 number SPACE number 2853 password ::= astring 2855 quoted ::= <"> *QUOTED_CHAR <"> 2857 QUOTED_CHAR ::= / 2858 "\" quoted_specials 2860 quoted_specials ::= <"> / "\" 2862 rename ::= "RENAME" SPACE mailbox SPACE mailbox 2863 ;; Use of INBOX as a destination gives a NO error 2865 response ::= *response_data response_done 2867 response_data ::= "*" SPACE (resp_cond_state / resp_cond_bye / 2868 mailbox_data / message_data / capability_data) CRLF 2870 response_done ::= response_tagged / response_fatal 2872 response_fatal ::= "*" SPACE resp_cond_bye CRLF 2874 response_tagged ::= tag SPACE resp_cond_state CRLF 2876 resp_cond_auth ::= ("OK" / "PREAUTH") SPACE resp_text 2877 ;; Authentication condition 2879 resp_cond_bye ::= "BYE" SPACE resp_text 2880 ;; Server will disconnect condition 2882 resp_cond_state ::= ("OK" / "NO" / "BAD") SPACE resp_text 2883 ;; Status condition 2885 resp_text ::= ["[" resp_text_code "]" SPACE] (text_mime2 / text) 2887 Internet DRAFT IMAP4 October 30, 1994 2889 resp_text_code ::= "ALERT" / "PARSE" / 2890 "PERMANENTFLAGS" SPACE "(" #(flag / "\*") ")" / 2891 "READ-ONLY" / "READ-WRITE" / "TRYCREATE" / 2892 "UIDVALIDITY" SPACE nz_number / 2893 "UNSEEN" SPACE nz_number / 2894 atom [SPACE 1*] 2896 search ::= "SEARCH" SPACE ["CHARSET" SPACE astring SPACE] 2897 search_criteria 2898 ;; Character set must be registered with IANA 2899 ;; as a MIME character set 2901 search_criteria ::= 1#search_key 2903 search_key ::= search_new / search_old 2905 search_new ::= "DRAFT" / "HEADER" SPACE header_line SPACE astring / 2906 "LARGER" SPACE number / "NOT" SPACE search_key / 2907 "OR" SPACE search_key SPACE search_key / 2908 "SENTBEFORE" SPACE date / "SENTON" SPACE date / 2909 "SENTSINCE" SPACE date / "SMALLER" SPACE number / 2910 "UID" SPACE set / "UNDRAFT" / set / 2911 "(" search_criteria ")" 2912 ;; New in IMAP4 2914 search_old ::= "ALL" / "ANSWERED" / "BCC" SPACE astring / 2915 "BEFORE" SPACE date / "BODY" SPACE astring / 2916 "CC" SPACE astring / "DELETED" / "FLAGGED" / 2917 "FROM" SPACE astring / "KEYWORD" SPACE flag_keyword / 2918 "NEW" / "OLD" / "ON" SPACE date / "RECENT" / "SEEN" / 2919 "SINCE" SPACE date / "SUBJECT" SPACE astring / 2920 "TEXT" SPACE astring / "TO" SPACE astring / 2921 "UNANSWERED" / "UNDELETED" / "UNFLAGGED" / 2922 "UNKEYWORD" SPACE flag_keyword / "UNSEEN" 2923 ;; Defined in [IMAP2] 2925 section ::= "0" / nz_number ["." section] 2927 select ::= "SELECT" SPACE mailbox 2929 sequence_num ::= nz_number / "*" 2930 ;; * is the largest number in use. For message 2931 ;; sequence numbers, it is the number of messages 2932 ;; in the mailbox. For unique identifiers, it is 2933 ;; the unique identifier of the last message in 2934 ;; the mailbox. 2936 Internet DRAFT IMAP4 October 30, 1994 2938 set ::= sequence_num / (sequence_num ":" sequence_num) / 2939 (set "," set) 2940 ;; Identifies a set of messages. For message 2941 ;; sequence numbers, these are consecutive numbers 2942 ;; from 1 to the number of messages in the mailbox. 2943 ;; Comma delimits individual numbers, colon 2944 ;; delimits between two numbers inclusive. 2945 ;; Example: 2,4:7,9,12:* is 2,4,5,6,7,9,12,13, 2946 ;; 14,15 for a mailbox with 15 messages. 2948 SPACE ::= 2950 store ::= "STORE" SPACE set SPACE store_att_flags 2952 store_att_flags ::= (["+" / "-"] "FLAGS" [".SILENT"]) SPACE 2953 (flag_list / #flag) 2955 string ::= quoted / literal 2957 subscribe ::= ("SUBSCRIBE" SPACE mailbox) / subscribe_obs 2959 subscribe_obs ::= "SUBSCRIBE" SPACE "MAILBOX" SPACE mailbox 2960 ;;OBSOLETE 2962 tag ::= 1* 2964 text ::= 1*TEXT_CHAR 2966 text_mime2 ::= "=?" "?" "?" "?=" 2967 ;; Syntax defined in [MIME-2] 2969 TEXT_CHAR ::= 2971 time ::= 2digit ":" 2digit ":" 2digit 2972 ;; Hours minutes seconds 2974 uid ::= "UID" SPACE (copy / fetch / search / store) 2975 ;; Unique identifiers used instead of message 2976 ;; sequence numbers 2978 uniqueid ::= nz_number 2979 ;; Strictly ascending 2981 unsubscribe ::= ("UNSUBSCRIBE" SPACE mailbox) / unsubscribe_obs 2983 unsubscribe_obs ::= "UNSUBSCRIBE" SPACE "MAILBOX" SPACE mailbox 2984 ;;OBSOLETE 2986 Internet DRAFT IMAP4 October 30, 1994 2988 userid ::= astring 2990 x_command ::= "X" atom 2992 zone ::= ("+" / "-") 4digit 2993 ;; Signed four-digit value of hhmm representing 2994 ;; hours and minutes west of Greenwich (that is, 2995 ;; (the amount that the given time differs from 2996 ;; Universal Time). Subtracting the timezone 2997 ;; from the given time will give the UT form. 2998 ;; The Universal Time zone is "+0000". 3000 zone_old ::= "UT" / "GMT" / "Z" / ;; +0000 3001 "AST" / "EST" / "CST" / "MST" / ;; -0400 to -0700 3002 "PST" / "YST" / "HST" / "BST" / ;; -0800 to -1100 3003 "ADT" / "EDT" / "CDT" / "MDT" / ;; -0300 to -0600 3004 "PDT" / "YDT" / "HDT" / "BDT" / ;; -0700 to -1000 3005 "A" / "B" / "C" / "D" / "E" / "F" / ;; +0100 to +0600 3006 "G" / "H" / "I" / "K" / "L" / "M" / ;; +0700 to +1200 3007 "N" / "O" / "P" / "Q" / "R" / "S" / ;; -0100 to -0600 3008 "T" / "U" / "V" / "W" / "X" / "Y" ;; -0700 to -1200 3009 ;; OBSOLETE 3011 Internet DRAFT IMAP4 October 30, 1994 3013 10. Author's Note 3015 This document is a rewrite of earlier documents, and supercedes the 3016 protocol specification in those documents: earlier IMAP4 Internet 3017 drafts, the IMAP2bis Internet drafts, unpublished IMAP2bis.TXT 3018 document, RFC 1176, and RFC 1064. 3020 11. Security Considerations 3022 IMAP4 protocol transactions, including electronic mail data, are sent 3023 in the clear over the network unless the optional privacy protection 3024 is negotiated in the AUTHENTICATE command. 3026 A server error message for an AUTHENTICATE command which fails due to 3027 invalid credentials should not detail why the credentials are 3028 invalid. 3030 Use of the LOGIN command sends passwords in the clear. This can be 3031 avoided by using the AUTHENTICATE command instead. 3033 A server error message for a failing LOGIN command should not specify 3034 that the user name, as opposed to the password, is invalid. 3036 Additional security considerations are discussed in the section 3037 discussing the AUTHENTICATE and LOGIN commands. 3039 12. Author's Address 3041 Mark R. Crispin 3042 Networks and Distributed Computing, JE-30 3043 University of Washington 3044 Seattle, WA 98195 3046 Phone: (206) 543-5762 3048 EMail: MRC@CAC.Washington.EDU 3050 Internet DRAFT IMAP4 October 30, 1994 3052 Appendices 3054 A. Obsolete Commands 3056 The following commands are OBSOLETE. It is NOT required to support 3057 any of these commands in new server implementations. These commands 3058 are documented here for the benefit of implementors who may wish to 3059 support them for compatibility with old client implementations. 3061 The section headings of these commands are intended to correspond 3062 with where they would be located in the main document if they were 3063 not obsoleted. 3065 A.6.3.OBS.1. FIND ALL.MAILBOXES Command 3067 Arguments: mailbox name with possible wildcards 3069 Data: untagged responses: MAILBOX 3071 Result: OK - find completed 3072 NO - find failure: can't list that name 3073 BAD - command unknown or arguments invalid 3075 The FIND ALL.MAILBOXES command returns a subset of names from the 3076 complete set of all names available to the user. It returns zero 3077 or more untagged MAILBOX replies. The mailbox argument to FIND 3078 ALL.MAILBOXES is similar to that for LIST with an empty reference, 3079 except that the characters "%" and "?" match a single character. 3081 Example: C: A002 FIND ALL.MAILBOXES * 3082 S: * MAILBOX blurdybloop 3083 S: * MAILBOX INBOX 3084 S: A002 OK FIND ALL.MAILBOXES completed 3086 A.6.3.OBS.2. FIND MAILBOXES Command 3088 Arguments: mailbox name with possible wildcards 3090 Data: untagged responses: MAILBOX 3092 Result: OK - find completed 3093 NO - find failure: can't list that name 3094 BAD - command unknown or arguments invalid 3096 The FIND MAILBOXES command returns a subset of names from the set 3097 of names that the user has declared as being "active" or 3099 Internet DRAFT IMAP4 October 30, 1994 3101 "subscribed". It returns zero or more untagged MAILBOX replies. 3102 The mailbox argument to FIND MAILBOXES is similar to that for LSUB 3103 with an empty reference, except that the characters "%" and "?" 3104 match a single character. 3106 Example: C: A002 FIND MAILBOXES * 3107 S: * MAILBOX blurdybloop 3108 S: * MAILBOX INBOX 3109 S: A002 OK FIND MAILBOXES completed 3111 A.6.3.OBS.3. SUBSCRIBE MAILBOX Command 3113 Arguments: mailbox name 3115 Data: no specific data for this command 3117 Result: OK - subscribe completed 3118 NO - subscribe failure: can't subscribe to that name 3119 BAD - command unknown or arguments invalid 3121 The SUBSCRIBE MAILBOX command is identical in effect to the 3122 SUBSCRIBE command. A server which implements this command must be 3123 able to distinguish between a SUBSCRIBE MAILBOX command and a 3124 SUBSCRIBE command with a mailbox name argument of "MAILBOX". 3126 Example: C: A002 SUBSCRIBE MAILBOX #news.comp.mail.mime 3127 S: A002 OK SUBSCRIBE MAILBOX to #news.comp.mail.mime 3128 completed 3129 C: A003 SUBSCRIBE MAILBOX 3130 S: A003 OK SUBSCRIBE to MAILBOX completed 3132 A.6.3.OBS.4. UNSUBSCRIBE MAILBOX Command 3134 Arguments: mailbox name 3136 Data: no specific data for this command 3138 Result: OK - unsubscribe completed 3139 NO - unsubscribe failure: can't unsubscribe that name 3140 BAD - command unknown or arguments invalid 3142 The UNSUBSCRIBE MAILBOX command is identical in effect to the 3143 UNSUBSCRIBE command. A server which implements this command must 3144 be able to distinguish between a UNSUBSCRIBE MAILBOX command and 3146 Internet DRAFT IMAP4 October 30, 1994 3148 an UNSUBSCRIBE command with a mailbox name argument of "MAILBOX". 3150 Example: C: A002 UNSUBSCRIBE MAILBOX #news.comp.mail.mime 3151 S: A002 OK UNSUBSCRIBE MAILBOX from #news.comp.mail.mime 3152 completed 3153 C: A003 UNSUBSCRIBE MAILBOX 3154 S: A003 OK UNSUBSCRIBE from MAILBOX completed 3156 Internet DRAFT IMAP4 October 30, 1994 3158 B. Obsolete Responses 3160 The following responses are OBSOLETE. Except as noted below, these 3161 responses MUST NOT be transmitted by new server implementations. 3163 The section headings of these responses are intended to correspond 3164 with where they would be located in the main document if they were 3165 not obsoleted. 3167 B.7.2.OBS.1. MAILBOX Response 3169 Data: name 3171 The MAILBOX response MUST NOT be transmitted by new server 3172 implementations except in response to the obsolete FIND MAILBOXES 3173 and FIND ALL.MAILBOXES commands. Client implementations that do 3174 not use these commands are NOT required to support this response. 3175 It is documented here for the benefit of implementors who may wish 3176 to support it for compatibility with old client implementations. 3178 This response occurs as a result of the FIND MAILBOXES and FIND 3179 ALL.MAILBOXES commands. It returns a single name that matches the 3180 FIND specification. There are no attributes or hierarchy 3181 delimiter. 3183 Example: S: * MAILBOX blurdybloop 3185 B.7.3.OBS.1. COPY Response 3187 Data: none 3189 Client implementations MUST ignore the COPY response. It is 3190 documented here for the benefit of client implementors who may 3191 encounter this response from old server implementations. 3193 In some experimental versions of this protocol, this response was 3194 returned in response to a COPY command to indicate on a 3195 per-message basis that the message was copied successfully. 3197 Example: S: * 44 COPY 3199 B.7.3.OBS.2. STORE Response 3201 Data: message data 3203 Internet DRAFT IMAP4 October 30, 1994 3205 Client implementations MUST treat the STORE response as equivalent 3206 to the FETCH response. It is documented here for the benefit of 3207 client implementors who may encounter this response from old 3208 server implementations. 3210 In some experimental versions of this protocol, this response was 3211 returned instead of FETCH in response to a STORE command to report 3212 the new value of the flags. 3214 Example: S: * 69 STORE (FLAGS (\Deleted)) 3216 Internet DRAFT IMAP4 October 30, 1994 3218 C. References 3220 [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", Work in 3221 Process of the IETF IMAP WG, draft-ietf-imap-auth-??.txt. Check 3222 Internet Drafts listing for latest version. 3224 [IMAP-COMPAT] Crispin, M. "IMAP4 Compatibility with IMAP2 and 3225 IMAP2bis", Work in Progress of the IETF IMAP WG, 3226 draft-ietf-imap-compat-??.txt. Check Internet Drafts listing for 3227 latest version. 3229 [IMAP-DISC] Austein, R. "Synchronization Operations for Disconnected 3230 IMAP4 Clients", Work in Progress of the IETF IMAP WG, 3231 draft-ietf-imap-disc-??.txt. Check Internet Drafts listing for 3232 latest version. 3234 [IMAP-MODEL] Crispin, M. "Distributed Electronic Mail Models in 3235 IMAP4", Work in Progress of the IETF IMAP WG, 3236 draft-ietf-imap-model-??.txt. Check Internet Drafts listing for 3237 latest version. 3239 [IMAP-NAMING] Crispin, M. "Mailbox Naming Convention in IMAP4", Work 3240 in Progress of the IETF IMAP WG, draft-ietf-imap-naming-??.txt. 3241 Check Internet Drafts listing for latest version. 3243 [IMAP2] Crispin, M., "Interactive Mail Access Protocol - Version 2", 3244 RFC 1176. 3246 [IMSP] Myers, J. "IMSP -- Internet Message Support Protocol", Work in 3247 Progress of the IETF IMAP WG, draft-myers-imap-imsp-??.txt. Check 3248 Internet Drafts listing for latest version. 3250 [MIME-1] Borenstein, N., and Freed, N., "MIME (Multipurpose Internet 3251 Mail Extensions) Part One: Mechanisms for Specifying and Describing 3252 the Format of Internet Message Bodies", RFC 1521. 3254 [MIME-2] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 3255 Part Two: Message Header Extensions for Non-ASCII Text", RFC 1522. 3257 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text 3258 Messages", STD 11, RFC 822. 3260 [SMTP] Postel, Jonathan B. "Simple Mail Transfer Protocol", STD 10, 3261 RFC 821. 3263 Internet DRAFT IMAP4 October 30, 1994 3265 D. Changes from Draft 05 3267 There are only minor changes from Draft 05 to Draft 06. There are no 3268 changes to the functional intent of the protocol. 3270 The following editorial changes were made: 3272 The Internet Draft header wording is changed to correspond to the 3273 latest official statements. 3275 All usage of the verb "to canonicalize" is removed and replaced 3276 with more standard English usage. 3278 Clarification in the Formal Syntax that sequence numbers, unique 3279 identifiers, and non-terminal message section numbers can never be 3280 zero. 3282 Removed security note about doing a second CAPABILITY command 3283 after authentication. This was the remnant of an idea that was 3284 rejected by the Working Group prior to draft 05. 3286 The following changes to the protocol description were made: 3288 Clarification of the usage and semantics of \Noselect names. 3289 Draft 05 lacked necessary background information from the Working 3290 Group discusssions, thus alternate (although non-useful) 3291 interpretations were possible. 3293 Clarification that unique identifiers are unsigned, non-zero, 3294 32-bits. Draft 05 implied that unique identifiers were infinite 3295 precision and could be zero. 3297 Addition of a unique identifier validity value, to label whether 3298 or not unique identifiers from the previous session are still 3299 valid. Draft 05 lacked this capability, which is necessary if the 3300 server is not able to guarantee permanence of unique identifiers. 3302 Note: The need for the unique identifier validity value 3303 could have been eliminated if unique identifiers were 3304 defined as 64-bits. This was rejected because it would 3305 have required significantly more bandwidth for low-speed 3306 link applications, which were one of the target 3307 applications for disconnected use. 3309 Internet DRAFT IMAP4 October 30, 1994 3311 E. IMAP4 Keyword Index 3313 +FLAGS (store command data item) ............... 34 3314 +FLAGS.SILENT (store command data item) ........ 34 3315 -FLAGS (store command data item) ............... 34 3316 -FLAGS.SILENT (store command data item) ........ 34 3317 ALERT (response code) ...................................... 39 3318 ALL (fetch item) ........................................... 29 3319 ALL (search key) ........................................... 27 3320 ANSWERED (search key) ...................................... 27 3321 APPEND (command) ........................................... 22 3322 AUTHENTICATE (command) ..................................... 12 3323 BAD (response) ............................................. 41 3324 BCC (search key) .................................. 27 3325 BEFORE (search key) ................................. 27 3326 BODY (fetch item) .......................................... 29 3327 BODY (fetch result) ........................................ 46 3328 BODY (search key) ................................. 27 3329 BODY.PEEK[
] (fetch item) .......................... 31 3330 BODYSTRUCTURE (fetch item) ................................. 31 3331 BODYSTRUCTURE (fetch result) ............................... 47 3332 BODY[
] (fetch item) ............................... 29 3333 BODY[section] (fetch result) ............................... 46 3334 BYE (response) ............................................. 42 3335 CAPABILITY (command) ....................................... 10 3336 CAPABILITY (response) ...................................... 42 3337 CC (search key) ................................... 27 3338 CHECK (command) ............................................ 23 3339 CLOSE (command) ............................................ 24 3340 COPY (command) ............................................. 34 3341 COPY (response) ............................................ 67 3342 CREATE (command) ........................................... 17 3343 DELETE (command) ........................................... 18 3344 DELETED (search key) ....................................... 27 3345 DRAFT (search key) ......................................... 27 3346 ENVELOPE (fetch item) ...................................... 31 3347 ENVELOPE (fetch result) .................................... 49 3348 EXAMINE (command) .......................................... 16 3349 EXISTS (response) .......................................... 45 3350 EXPUNGE (command) .......................................... 25 3351 EXPUNGE (response) ......................................... 45 3352 FAST (fetch item) .......................................... 31 3353 FETCH (command) ............................................ 29 3354 FETCH (response) ........................................... 46 3355 FIND ALL.MAILBOXES (command) ............................... 64 3356 FIND MAILBOXES (command) ................................... 64 3357 FLAGGED (search key) ....................................... 27 3358 FLAGS (fetch item) ......................................... 31 3360 Internet DRAFT IMAP4 October 30, 1994 3362 FLAGS (fetch result) ....................................... 49 3363 FLAGS (response) ........................................... 44 3364 FLAGS (store command data item) ................ 34 3365 FLAGS.SILENT (store command data item) ......... 34 3366 FROM (search key) ................................. 27 3367 FULL (fetch item) .......................................... 31 3368 HEADER (search key) .................. 27 3369 INTERNALDATE (fetch item) .................................. 31 3370 INTERNALDATE (fetch result) ................................ 50 3371 KEYWORD (search key) ................................ 27 3372 LARGER (search key) .................................... 27 3373 LIST (command) ............................................. 20 3374 LIST (response) ............................................ 43 3375 LOGIN (command) ............................................ 14 3376 LOGOUT (command) ........................................... 11 3377 LSUB (command) ............................................. 22 3378 LSUB (response) ............................................ 44 3379 MAILBOX (response) ......................................... 67 3380 NEW (search key) ........................................... 27 3381 NO (response) .............................................. 40 3382 NOOP (command) ............................................. 11 3383 NOT (search key) .............................. 27 3384 OK (response) .............................................. 40 3385 OLD (search key) ........................................... 28 3386 ON (search key) ..................................... 28 3387 OR (search key) ................ 28 3388 PARSE (response code) ...................................... 39 3389 PARTIAL (command) .......................................... 32 3390 PERMANENTFLAGS (response code) ............................. 39 3391 PREAUTH (response) ......................................... 41 3392 READ-ONLY (response code) .................................. 39 3393 READ-WRITE (response code) ................................. 39 3394 RECENT (response) .......................................... 45 3395 RECENT (search key) ........................................ 28 3396 RENAME (command) ........................................... 18 3397 RFC822 (fetch item) ........................................ 31 3398 RFC822 (fetch result) ...................................... 50 3399 RFC822.HEADER (fetch item) ................................. 31 3400 RFC822.HEADER (fetch result) ............................... 50 3401 RFC822.HEADER.LINES (fetch item) ............. 31 3402 RFC822.HEADER.LINES.NOT (fetch item) ......... 31 3403 RFC822.PEEK (fetch item) ................................... 31 3404 RFC822.SIZE (fetch item) ................................... 32 3405 RFC822.SIZE (fetch result) ................................. 50 3406 RFC822.TEXT (fetch item) ................................... 32 3407 RFC822.TEXT (fetch result) ................................. 50 3408 RFC822.TEXT.PEEK (fetch item) .............................. 32 3409 SEARCH (command) ........................................... 25 3411 Internet DRAFT IMAP4 October 30, 1994 3413 SEARCH (response) .......................................... 44 3414 SEEN (search key) .......................................... 28 3415 SELECT (command) ........................................... 15 3416 SENTBEFORE (search key) ............................. 28 3417 SENTON (search key) ................................. 28 3418 SENTSINCE (search key) .............................. 28 3419 SINCE (search key) .................................. 28 3420 SMALLER (search key) ................................... 28 3421 STORE (command) ............................................ 33 3422 STORE (response) ........................................... 67 3423 SUBJECT (search key) .............................. 28 3424 SUBSCRIBE (command) ........................................ 19 3425 SUBSCRIBE MAILBOX (command) ................................ 65 3426 TEXT (search key) ................................. 28 3427 TO (search key) ................................... 28 3428 TRYCREATE (response code) .................................. 39 3429 UID (command) .............................................. 35 3430 UID (fetch item) ........................................... 32 3431 UID (fetch result) ......................................... 51 3432 UID (search key) ............................. 28 3433 UIDVALIDITY (response code) ................................ 40 3434 UNANSWERED (search key) .................................... 29 3435 UNDELETED (search key) ..................................... 29 3436 UNDRAFT (search key) ....................................... 29 3437 UNFLAGGED (search key) ..................................... 29 3438 UNKEYWORD (search key) .............................. 29 3439 UNSEEN (response code) ..................................... 40 3440 UNSEEN (search key) ........................................ 29 3441 UNSUBSCRIBE (command) ...................................... 19 3442 UNSUBSCRIBE MAILBOX (command) .............................. 65 3443 X (command) .......................................... 37 3444 \Answered (system flag) .................................... 50 3445 \Deleted (system flag) ..................................... 50 3446 \Draft (system flag) ....................................... 50 3447 \Flagged (system flag) ..................................... 50 3448 \Marked (mailbox name attribute) ........................... 43 3449 \Noinferiors (mailbox name attribute) ...................... 43 3450 \Noselect (mailbox name attribute) ......................... 43 3451 \Recent (system flag) ...................................... 50 3452 \Seen (system flag) ........................................ 50 3453 \Unmarked (mailbox name attribute) ......................... 43