idnits 2.17.1 draft-ietf-imap-imap2bis-02.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-24) 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 6 months document validity. ** 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 Abstract 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 96 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 7 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** 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 212: '... for this user. The name "INBOX" MUST...' RFC 2119 keyword, line 222: '...haracter. Servers MUST, at a minimum,...' RFC 2119 keyword, line 450: '...or this user, it MUST exist and be cal...' RFC 2119 keyword, line 461: '... A server SHOULD NOT attempt to...' RFC 2119 keyword, line 617: '...then all messages SHOULD be considered...' (36 more instances...) == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC1176, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC1064, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 1993) is 11149 days in the past. Is this intentional? 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? 'READ-WRITE' on line 1456 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Mark Crispin 2 Internet Draft: IMAP2bis University of Washington 3 Obsoletes: RFC 1176, 1064 October 1993 4 Document: internet-drafts/draft-ietf-imap-imap2bis-02.txt 6 INTERACTIVE MAIL ACCESS PROTOCOL - VERSION 2bis 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 16 months. Internet Drafts may be updated, replaced, or obsoleted by 17 other documents at any time. It is not appropriate to use Internet 18 Drafts as reference material or to cite them other than as a "working 19 draft" or "work in progress". Please check the I-D abstract listing 20 contained in each Internet Draft directory to learn the current 21 status of any this or any other Internet Draft. 23 This is a draft document of the IETF IMAP Working Group. It is a 24 draft specification of the IMAP2bis protocol, based upon the 25 following earlier specifications: unpublished IMAP2bis.TXT document, 26 RFC 1176, and RFC 1064. This document is not a complete or final 27 specification of the IMAP2bis protocol. 29 Only matters that are believed to be uncontroversial, or issues that 30 are believed to be resolved, appear in this document. The entirety 31 of this document is subject to change and extension. A list of open 32 issues may be found in the file mail/imap.unresolved on Internet site 33 ftp.CAC.Washington.EDU. 35 A version of this draft document will be submitted to the RFC editor 36 as a Proposed Standard for the Internet Community. Discussion and 37 suggestions for improvement are requested. This document will expire 38 before 31 March 1994. Distribution of this draft is unlimited. 39 Comments are solicited and should be sent to imap@CAC.Washington.EDU. 41 Introduction 43 The Interactive Mail Access Protocol, Version 2bis (IMAP2bis) allows 44 a client to access and manipulate electronic mail on a server. 45 IMAP2bis is designed to permit manipulations of remote mailboxes as 46 if they were local. IMAP2bis includes operations for creating, 47 deleting, and renaming mailbox folders; checking for new mail; 48 permanently removing messages; setting and clearing flags; RFC 822 49 and MIME parsing; searching; and selective fetching of message 50 attributes, texts, and portions thereof. 52 IMAP2bis does not specify a means of posting mail; this function is 53 handled by a mail transfer protocol such as SMTP (RFC 821). 55 IMAP2bis assumes a reliable data stream such as provided by TCP. 56 When TCP is used, an IMAP2bis server listens on port 143. 58 System Model and Philosophy 60 There are three fundamental models of client/server email: offline, 61 online, and disconnected use. IMAP2bis can be used in any one of 62 these three models. 64 The offline model is the most familiar form of client/server email 65 today, and is used by protocols such as POP-3 (RFC 1225) and UUCP. 66 In this model, a client application periodically connects to a 67 server. It downloads all the pending messages to the client machine 68 and deletes these from the server. Thereafter, all mail processing 69 is local to the client. This model is store-and-forward; it moves 70 mail on demand from an intermediate server (maildrop) to a single 71 destination machine. 73 The online model is most commonly used with remote filesystem 74 protocols such as NFS. In this model, a client application 75 manipulates mailbox data on a server machine. A connection to the 76 server is maintained throughout the session. No mailbox data are 77 kept on the client; the client retrieves data from the server as is 78 needed. IMAP2bis introduces a form of the online model that requires 79 considerably less network bandwidth than a remote filesystem 80 protocol, and provides the opportunity for using the server for CPU 81 or I/O intensive functions such as parsing and searching. 83 The disconnected use model is a hybrid of the offline and online 84 models, and is used by protocols such as PCMAIL (RFC 1056). In this 85 model, a client user downloads some set of messages from the server, 86 manipulates them offline, then at some later time uploads the 87 changes. The server remains the authoritative repository of the 88 messages. The problems of synchronization (particularly when 89 multiple clients are involved) are handled through the means of 90 unique identifiers for each message. 92 Each of these models have their own strengths and weaknesses: 94 Feature Offline Online Disc 95 ------- ------- ------ ---- 96 Can use multiple clients NO YES YES 97 Minimum use of server connect time YES NO YES 98 Minimum use of server resources YES NO NO 99 Minimum use of client disk resources NO YES NO 100 Multiple remote mailboxes NO YES YES 101 Fast startup NO YES NO 102 Mail processing when not online YES NO YES 104 Although IMAP2bis was originally designed to accommodate the online 105 model, it can support the other two models as well. This makes 106 possible the creation of clients that can be used in any of the three 107 models. For example, a user may wish to switch between the online 108 and disconnected models on a regular basis (e.g. owing to travel). 110 IMAP2bis is designed to transmit message data on demand, and to 111 provide the facilities necessary for a client to decide what data it 112 needs at any particular time. There is generally no need to do a 113 wholesale transfer of an entire mailbox or even of the complete text 114 of a message. This makes a difference in situations where the 115 mailbox is large, or when the link to the server is slow. 117 More specifically, IMAP2bis supports server-based RFC 822 and MIME 118 processing. With this information, it is possible for a client to 119 determine in advance whether it wishes to retrieve a particular 120 message or part of a message. For example, a user connected to an 121 IMAP2bis server via a dialup link can determine that a message has a 122 2000 byte text segment and a 40 megabyte video segment, and elect to 123 fetch only the text segment. 125 In IMAP2bis, the client/server relationship lasts only for the 126 duration of the TCP connection, and mailbox state is maintained on 127 the server. There is no registration of clients. Except for any 128 unique identifiers used in disconnected use operation, the client 129 initially has no knowledge of mailbox state and learns it from the 130 IMAP2bis server when a mailbox is selected. This initial transfer is 131 minimal; the client requests additional state data as it needs. 133 The Protocol 135 The IMAP2bis protocol consists of a sequence of client commands and 136 server responses, with server data interspersed between the 137 responses. Unlike most Internet protocols, commands and responses 138 are tagged. That is, a command begins with a unique identifier 139 (typically a short alphanumeric sequence such as a Lisp "gensym" 140 function would generate e.g., A0001, A0002, etc.) called a tag. The 141 response to the command is given the same tag from the server. 143 Additionally, the server may send an arbitrary amount of "unsolicited 144 data". Unsolicited data is identified by the special reserved tag of 145 "*". The unsolicited data mechanism transmits most data in IMAP2bis. 146 The term "unsolicited data" suggests that the data may have been 147 transmitted without any explicit request by the client for that data. 148 No distinction is made in IMAP2bis between data transmitted as a 149 result of a client command and data that are unilaterally transmitted 150 by the server. One form of unilaterally transmitted data that 151 commonly occurs is an alert of a change to the mailbox made by some 152 process other than the IMAP2bis client or server; for example, 153 changes in the size of the mailbox (new mail) or in the status of 154 individual messages. 156 There is another special reserved tag, "+", discussed below. 158 The server must be listening for a connection. When a connection is 159 opened the server sends a greeting message and then waits for 160 commands. This greeting is either a PREAUTH (meaning that the user 161 has already been identified and authenticated by an external 162 mechanism such as rsh) or OK (meaning that the user is not yet 163 authenticated) unsolicited response. The server may also send a BYE 164 unsolicited response and close the connection if it rejects the 165 connection. 167 The client opens a connection and waits for the greeting. The client 168 must not send any commands until it has received the greeting from 169 the server. 171 Once the greeting has been received, the client may begin sending 172 commands. It is not under any obligation to wait for a server 173 response to a command before sending another command, subject to the 174 constraints of underlying flow control. When commands are received 175 the server acts on them and responds with command responses, often 176 interspersed with data. 178 In general, the command responses do not themselves contain the 179 requested data. Instead, they indicate the completion status of the 180 request. There are three fundamental responses: success (OK), error 181 (NO), request faulty or not understood (BAD). The effect of a 182 command can not be considered complete until a command response with 183 a tag matching the command is received from the server. 185 It is not required that a server process a command to completion 186 before beginning processing of the next command, except when the 187 processing of the previous command may affect the results of the next 188 command by changing the state of the current mailbox. This has 189 certain other effects; for example, this implies that an EXPUNGE 190 response can not be transmitted as part of a response to a command 191 that uses sequence numbers, because EXPUNGE results in message 192 numbers being changed. 194 Client implementations should update their local cache of data with 195 any received unsolicited data, regardless of whether or not the 196 client expected that data. Unlike command completion responses, data 197 are not necessarily associated with a specific command. The tagged 198 command completion response signals that the client cache is now 199 updated with the results of the corresponding command. 201 If authentication has not yet been completed, it must now be done via 202 the LOGIN command before any access to data is permitted. The only 203 permitted commands before successful authentication are LOGIN, NOOP, 204 and LOGOUT. See the section below on authentication. 206 Once authenticated, the client must send a mailbox selection command 207 to access the desired mailbox; no mailbox is selected by default. 208 Mailbox names are implementation dependent. However, the word 209 "INBOX" must be implemented to mean the primary or default mailbox 210 for this user, independent of any other server semantics. It is 211 permitted for a server not to have an INBOX if there is no concept of 212 a primary or default mailbox for this user. The name "INBOX" MUST 213 NOT be used for any other purpose. 215 On a successful selection, the server will send a list of valid 216 flags, number of messages, and number of messages arrived since last 217 access for this mailbox as unsolicited data, followed by an OK 218 response. The client may close access to this mailbox and access a 219 different one with another selection command. 221 Several flags are predefined in IMAP2bis. All IMAP2bis flags begin 222 with a backslash ("\") character. Servers MUST, at a minimum, 223 support all the predefined flags in this specification. In addition, 224 a server may also have some implementation-defined per-mailbox flags 225 (called, for historical reasons, "keywords") that do not begin with 226 backslash. Clients should use the information from the server's 227 FLAGS response at message selection to determine what flags the 228 server supports. 230 The client requests mailbox data with FETCH commands, and receives it 231 via the unsolicited data mechanism. Three major categories of 232 mailbox data exist. 234 The first category is data that are associated with a message as an 235 entity in the mailbox. There are now four such items of data: the 236 "internal date", the "RFC 822 size", the "flags", and the "unique 237 id". The internal date is the date and time that the message was 238 placed in the mailbox. The RFC 822 size is the size in octets of the 239 message, expressed as an RFC 822 text string. The flags are a list 240 of status flags associated with the message. The unique id is an 241 identifier that is guaranteed to refer to this message and to none 242 other in the mailbox and that, unlike IMAP2bis sequence numbers, 243 persists across sessions. 245 The second category is data that describe the composition and 246 delivery information of a message; that is, information such as the 247 message sender, recipient lists, message-ID, subject, MIME structure, 248 etc. This is the information that is stored in the RFC 822 and MIME 249 headers. In IMAP2bis, the RFC 822 header information that may be 250 fetched is called the "envelope structure" (not to be confused with 251 SMTP envelopes). Similarly, the MIME header information that may be 252 fetched is called the "body structure". A client can use the parsed 253 envelope and body structures and not worry about having to do its own 254 RFC 822 or MIME parsing. 256 The third category is textual data, some of which are intended for 257 direct human viewing. IMAP2bis defines six such items: 258 RFC822.HEADER, RFC822.HEADER.LINES, RFC822.HEADER.LINES.NOT, 259 RFC822.TEXT, RFC822, and MIME body parts. It is possible to fetch an 260 individual MIME body part of a message without fetching any other 261 data associated with the message. 263 A simple client can "FETCH RFC822" to get the entire message without 264 any processing. A more advanced client might fetch some combination 265 of the first and second categories of data for use as a presentation 266 menu. Then, when the user wishes to read a particular message, it 267 will fetch the appropriate texts. 269 Data structures in IMAP2bis are represented as an S-expression list 270 similar to that used in the Lisp programming language. An S- 271 expression consists of a sequence of data items delimited by space 272 and bounded at each end by parentheses. An S-expression may itself 273 contain other S-expressions, using parentheses to indicate nesting. 274 S-expression syntax was chosen because it provides a concise and 275 precise means of expressing nested data (e.g. MIME structures). 277 The client can alter certain data with a STORE command. As an 278 example, a message is deleted from a mailbox by setting the \Deleted 279 flag with a STORE command. 281 Other client operations that can be done to a mailbox include copying 282 messages to other mailboxes, permanently removing deleted messages, 283 checking for updated mailbox state, and searching for messages that 284 match certain criteria. It is also possible to select a different 285 mailbox, create a new mailbox, rename an existing mailbox, or delete 286 an existing mailbox. 288 The client should end the session with the LOGOUT command. The 289 server returns a "BYE" followed by an "OK", at which point both the 290 client and the server close the connection. If the client closes the 291 network connection without a LOGOUT command, the server should do its 292 normal logout procedures without attempting any further interaction 293 with the client. 295 Authentication 297 Pre-authentication is only possible when the connection to the 298 IMAP2bis service is made through some link protocol that provides its 299 own authentication mechanism. It is not used with a TCP connection 300 to port 143. 302 An example of pre-authentication is the BSD "RSH" protocol, that 303 provides authentication through a "trusted host" facility. Another 304 example would be a manual invocation of an IMAP2bis server from a 305 logged-in timesharing job. 307 A pre-authenticated IMAP2bis server should recognize that 308 authentication has already happened, and enter the post-login state. 309 In its greeting message, it should use the unsolicited response 310 "PREAUTH" instead of "OK" to indicate that external authentication 311 has taken place. 313 This is an example of a pre-authentication scenario. In this and all 314 other examples in this document, S: indicates server dialog and C: 315 indicates client dialog. 317 S: * PREAUTH IMAP2bis Server pre-authenticated as user "Smith" 318 C: A001 SELECT INBOX 319 S: * FLAGS (\Answered \Flagged \Deleted \Seen) 320 S: * 19 EXISTS 321 S: * 2 RECENT 322 S: A001 OK SELECT complete 324 A connection that is not pre-authenticated is constrained to using 325 the LOGIN command for establishing authentication. Authentication 326 via the LOGIN command is with either a user name and password pair, 327 or with an user identifier and Kerberos authenticator. See the 328 description of the LOGIN command for more details. 330 Servers may allow non-authenticated access to certain mailboxes or 331 bulletin boards. The convention is to use a LOGIN command with the 332 userid "anonymous". A password is still required. It is 333 implementation-dependent what requirements, if any, are placed on the 334 password and what access restrictions are placed on anonymous users. 336 Implementations are NOT required to support pre-authentication, 337 Kerberos authentication, or the anonymous convention. 339 Definitions of Commands and Responses 341 Summary of Defined Commands and Responses 343 Commands || Responses 344 -------- || ------- 345 tag NOOP || tag OK resp_text 346 tag LOGIN user password || tag NO resp_text 347 tag LOGOUT || tag BAD resp_text 348 tag CREATE mailbox || * PREAUTH resp_text 349 tag DELETE mailbox || * OK resp_text 350 tag RENAME old_mailbox new_mailbox || * NO resp_text 351 tag FIND MAILBOXES pattern || * BAD resp_text 352 tag FIND ALL.MAILBOXES pattern || * BYE resp_text 353 tag FIND BBOARDS pattern || * MAILBOX mstring 354 tag FIND ALL.BBOARDS pattern || * BBOARD mstring 355 tag SUBSCRIBE MAILBOX mailbox || * SEARCH 1#number 356 tag UNSUBSCRIBE MAILBOX mailbox || * FLAGS flag_list 357 tag SUBSCRIBE BBOARD mailbox || * number EXISTS 358 tag UNSUBSCRIBE BBOARD mailbox || * number RECENT 359 tag SELECT mailbox || * number EXPUNGE 360 tag EXAMINE mailbox || * number FETCH data 361 tag BBOARD mailbox || * number COPY 362 tag CHECK || * number STORE data 363 tag EXPUNGE || + text 364 tag COPY sequence mailbox || 365 tag APPEND mailbox 0#flag literal || 366 tag FETCH sequence data || 367 tag PARTIAL msgno data start count || 368 tag STORE sequence data value || 369 tag UID AFTER uniqueid || 370 tag UID COPY sequence mailbox || 371 tag UID FETCH sequence data || 372 tag UID STORE sequence data value || 373 tag SEARCH search_program || 374 tag x_command arguments || 376 Note: there is no pairing between commands and responses on the same 377 line. Any command may result in any number (including none at all) 378 of any of responses beginning with "*" (referred to as "unsolicited 379 data"), followed by one tagged response. 381 Commands 383 If, during the execution of any command, the server observes that the 384 mailbox size has changed, the server should output an unsolicited 385 EXISTS and RECENT response reflecting the changed size to alert the 386 client. Similarly, any observed change in message status should 387 cause an unsolicited FETCH response with the new flag data. 389 tag NOOP 391 The NOOP command returns an OK to the client. By itself, it does 392 nothing else. However, since any command can return a status 393 update as unsolicited data, this command can be used to poll for 394 new mail or for message status updates. 396 Another possible use of this command is for the client to "ping" 397 the server so that the client and server know that each other are 398 still alive. This is useful with servers that have an inactivity 399 autologout timer. 401 tag LOGIN user password 403 The LOGIN command identifies the user to the server and carries 404 the password authenticating this user. This information is used 405 by the server to control access to the mailboxes. 407 EXAMPLE: a001 LOGIN SMITH SESAME 408 logs in as user SMITH with password SESAME. 410 If a server supports authentication via Kerberos, it may accept 411 the string "@KERBEROS:" followed by the hexadecimal representation 412 of a Kerberos authenticator. 414 EXAMPLE: The following is a Kerberos login scenario (note that the 415 line breaks in the sample authenticator are for editorial clarity 416 and are not in a real authenticator): 418 S: * OK Kerberos IMAP2bis Server 419 C: a001 LOGIN smith @KERBEROS:040700414e445245572e434d552e4544550 420 038202c868f3890b377fc8266acc1bedb96b80d3fa76489898e74cd1c952dc 421 4003ea3428f29f1c470016cf5adc22f939e6deff2747254c1815d5b0b90d4c 422 5a2cba21eb0abe32f9acbf568d751bf4cc13f5ba4e6d82c638a8b5421 423 S: a001 OK [df84a4cb8323454f] Login OK via Kerberos 425 The token in the brackets in the OK response is the Kerberos 426 authentication response, encrypted with the session key in network 427 byte order and an incremented checksum as in the usual Kerberos 428 procedure. 430 tag LOGOUT 432 The LOGOUT command informs the server that the client is done with 433 the session. The server should send an unsolicited BYE response 434 before the (tagged) OK response, and then close the network 435 connection. 437 Mailbox manipulation commands: CREATE, DELETE, RENAME 439 These commands permit the manipulation of entire mailboxes. 441 tag CREATE mailbox 443 The CREATE command creates a mailbox with the given name. This 444 command returns an OK response only if a new mailbox with that 445 name has been created. It is an error to attempt to create a 446 mailbox with a name that refers to an extant mailbox. Any 447 error in creation will return a NO response. 449 Creating INBOX is not permitted. If there is a primary or 450 default mailbox for this user, it MUST exist and be called 451 INBOX. 453 tag DELETE mailbox 455 The DELETE command deletes a mailbox with the given name. This 456 command returns an OK response only if a mailbox with that name 457 has been deleted. It is an error to attempt to delete a 458 mailbox name that does not exist. Any error in deletion will 459 return a NO response. 461 A server SHOULD NOT attempt to test that a mailbox is empty 462 before permitting deletion; this would prevent the deletion of 463 a mailbox that for some reason can not be opened or expunged, 464 leaving to possible denial of service problems. Any such 465 checking should be left to the discretion of the client. 467 Deleting INBOX is not permitted. 469 tag RENAME old_mailbox new_mailbox 471 The RENAME command changes the name of a mailbox. This command 472 returns an OK response only if a mailbox with the old name 473 exists and has been successfully renamed to the new name. It 474 is an error to attempt to rename with an old mailbox name that 475 does not exist or a new mailbox name that already exists. Any 476 error in renaming will return a NO response. 478 Renaming INBOX is permitted. A new, empty INBOX is created in 479 its place. 481 FIND commands 483 The FIND commands return some set of unsolicited MAILBOX or BBOARD 484 replies, depending on the type of FIND, that have as their value a 485 single mailbox name. 487 Three wildcard characters are defined in the pattern argument. "*" 488 specifies any number (including zero) characters may match at this 489 position. "%" and "?" specify a single character may match at this 490 position. For example, FOO*BAR will match FOOBAR, FOOD.ON.THE.BAR 491 and FOO.BAR, whereas FOO%BAR and FOO?BAR match only FOO.BAR. "*" 492 will match all mailboxes. 494 tag FIND MAILBOXES pattern 496 The FIND MAILBOXES command accepts as an argument a pattern 497 (including wildcards) that specifies some set of mailbox names 498 that the user has declared as being "active" or "subscribed". 499 The exact meaning of this is implementation-dependent, since 500 the concept of a set of "active" or "subscribed" mailboxes that 501 is preserved across sessions may not be meaningful for a 502 particular server or server implementation. If the SUBSCRIBE 503 MAILBOX and UNSUBSCRIBE MAILBOX commands are implemented then 504 this command returns the list manipulated by those commands. 506 EXAMPLE: C: A002 FIND MAILBOXES * 507 S: * MAILBOX FOOBAR 508 S: * MAILBOX GENERAL 509 S: A002 OK FIND completed 511 tag FIND ALL.MAILBOXES pattern 513 The FIND ALL.MAILBOXES command is similar to FIND MAILBOXES; 514 however, it should return a complete list of all mailboxes 515 available to the user. Data are returned as in FIND MAILBOXES. 517 The special name INBOX is included in the output from FIND 518 ALL.MAILBOXES unless INBOX is not supported by this server or 519 for this user. The criteria for omitting INBOX is whether 520 SELECT INBOX will return failure; it is not relevant whether 521 the user's real INBOX resides on this or some other server. 522 FIND MAILBOXES and SUBSCRIBE MAILBOX provide a mechanism for 523 the user to identify that this is his or her real INBOX. 525 FIND ALL.MAILBOXES must, at least, return all the mailbox names 526 that are returned by FIND MAILBOXES. 528 The exact meaning of this is implementation-dependent, since 529 the concept of a bounded or deterministic set of "mailboxes 530 available to the user" may not be meaningful for a particular 531 server or server implementation. 533 tag FIND BBOARDS pattern 535 The FIND BBOARDS command accepts as an argument a pattern that 536 specifies some set of bulletin board names that the user has 537 declared as being "active" or "subscribed". Wildcards are 538 permitted as in FIND MAILBOXES. 540 The FIND BBOARDS command will return some set of unsolicited 541 BBOARD replies that have as their value a single bulletin board 542 name. 544 EXAMPLE: C: A002 FIND BBOARDS * 545 S: * BBOARD FOOBAR 546 S: * BBOARD GENERAL 547 S: A002 OK FIND completed 549 The exact meaning of this is implementation-dependent, since 550 the concept of a set of "active" or "subscribed" bboards that 551 is preserved across sessions may not be meaningful for a 552 particular server or server implementation. If the SUBSCRIBE 553 BBOARD and UNSUBSCRIBE BBOARD commands are implemented then 554 this command returns the list manipulated by those commands. 556 tag FIND ALL.BBOARDS pattern 558 The FIND ALL.BBOARDS command is similar to FIND BBOARDS; 559 however, it should return a complete list of all bulletin 560 boards available to the user. Data are returned as in FIND 561 BBOARDS. 563 FIND ALL.BBOARDS must, at least, return all the bboard names 564 that are returned by FIND BBOARDS. 566 The exact meaning of this is implementation-dependent, since 567 the concept of a bounded or deterministic set of "bboards 568 available to the user" may not be meaningful for a particular 569 server or server implementation. 571 Subscription commands 573 These commands permit the manipulation of mailbox or bulletin board 574 subscriptions. Subscription status should be preserved between 575 sessions. 577 tag SUBSCRIBE MAILBOX mailbox 579 The SUBSCRIBE MAILBOX command adds the specified mailbox name 580 to the list of "active" or "subscribed" mailboxes as returned 581 by the FIND MAILBOXES command. This command returns an OK 582 response only if the subscription is successful. 584 tag UNSUBSCRIBE MAILBOX mailbox 586 The UNSUBSCRIBE MAILBOX command removes the specified mailbox 587 name from the list of "active" or "subscribed" mailboxes as 588 returned by the FIND MAILBOXES command. This command returns 589 an OK response only if the unsubscription is successful. 591 tag SUBSCRIBE BBOARD bboard 593 The SUBSCRIBE BBOARD command adds the specified mailbox name to 594 the list of "active" or "subscribed" bulletin boards as 595 returned by the FIND BBOARDS command. This command returns an 596 OK response only if the subscription is successful. 598 tag UNSUBSCRIBE BBOARD bboard 600 The UNSUBSCRIBE BBOARD command removes the specified mailbox 601 name from the list of "active" or "subscribed" bulletin boards 602 as returned by the FIND BBOARDS command. This command returns 603 an OK response only if the unsubscription is successful. 605 tag SELECT mailbox 607 This command selects a particular mailbox. The server must check 608 that the user is permitted read access to this mailbox. Before 609 returning an OK to the client, the server must send the following 610 unsolicited data to the client: 611 FLAGS mailbox's defined flags 612 EXISTS the number of messages in the mailbox 613 RECENT the number of messages added to the mailbox since the 614 previous time this mailbox was read 615 to define the initial state of the mailbox at the client. If it 616 can not be determined which messages were added since the previous 617 time a mailbox was read, then all messages SHOULD be considered 618 recent. An example of this is if no "last read" time information 619 is available or a read-only mailbox that does not permit a change 620 of "last read" time. 622 Multiple selection commands are permitted in a session. The 623 previous mailbox is automatically deselected when a new selection 624 is made. If concurrent access to multiple mailboxes is desired, 625 the client should open additional sessions as needed. 627 The mailbox name INBOX is a special name reserved to mean "the 628 primary mailbox for this user on this server". The format of 629 other mailbox names is implementation dependent. 631 The text of an OK response to the SELECT command should begin with 632 either "[READ-ONLY]" or "[READ-WRITE]" to show the mailbox's 633 access status. 635 tag EXAMINE mailbox 637 The EXAMINE command is similar to SELECT, and returns the same 638 output; however, the selected mailbox is identified as read-only 639 and no changes are permitted to this mailbox. EXAMINE has the 640 same mailbox namespace as SELECT. 642 tag BBOARD mailbox 644 The BBOARD command is similar to SELECT, and returns the same 645 output. Its argument is a shared mailbox (bulletin board) name 646 instead of an ordinary mailbox. There is no requirement that the 647 namespace for BBOARD be the same as that for SELECT and EXAMINE. 649 BBOARD also differs from EXAMINE in that it may allow changes 650 (e.g. marking a message as seen or deleted) to a mailbox; the 651 exact handling of this is implementation dependent. 653 tag CHECK 655 The CHECK command requests a checkpoint of the mailbox. CHECK may 656 cause an operation that may take a non-instantaneous amount of 657 real-time to complete. The exact meaning of a checkpoint is 658 implementation-dependent. Possible interpretations include 659 forcing an update of the server's disk of all changes made to the 660 selected mailbox, rescanning of the entire mailbox, etc. If an 661 implementation has no such considerations, CHECK should be 662 equivalent to NOOP. 664 CHECK should NOT be used to poll for new mail; new mail checking 665 happens implicitly as part of every command. NOOP should be used 666 for any new mail polling. CHECK should NOT be used to get the 667 current size of the mailbox; there is no guarantee that CHECK will 668 cause an EXISTS or RECENT unsolicited response. 670 tag EXPUNGE 672 The EXPUNGE command permanently removes all messages with the 673 \Deleted flag set from the currently selected mailbox. Before 674 returning an OK to the client, for each message that is removed, 675 an unsolicited EXPUNGE response is sent. The message number for 676 each successive message in the mailbox is immediately decremented 677 by 1; this means that if the last 5 messages in a 9-message mail 678 file are expunged the client will receive 5 unsolicited EXPUNGE 679 responses for message 5. 681 tag COPY sequence mailbox 683 The COPY command copies the specified message(s) to the specified 684 destination mailbox. The flags of the message(s) SHOULD be 685 preserved in the copy. 687 If the destination mailbox does not exist, a server SHOULD return 688 an error. It SHOULD NOT automatically create the mailbox. Unless 689 it is certain that the destination mailbox can not be created, the 690 server MUST send the special information token "[TRYCREATE]" as 691 the prefix of the text of the tagged NO response. This gives a 692 hint to the client that it can attempt a CREATE command and retry 693 the COPY if the CREATE is successful. 695 If the COPY command is unsuccessful for any reason, IMAP2bis 696 server implementations MUST restore the destination mailbox its 697 prior state before the COPY attempt. 699 EXAMPLE: A003 COPY 2:4 MEETING 700 copies messages 2, 3, and 4 to mailbox "MEETING". 702 tag APPEND mailbox 0#flag literal 704 The APPEND command appends the literal argument as a new message 705 in the specified destination mailbox. This argument is in the 706 format of an RFC 822 message. If any flags are specified, those 707 flags SHOULD be set in the resulting message. If the append is 708 unsuccessful for any reason the mailbox must be restored to its 709 prior state before the APPEND attempt; no partial appending is 710 permitted. If the mailbox is currently selected, the normal new 711 mail actions should occur. 713 Server implementations SHOULD return a NO response if the length 714 of the literal is zero. 716 If the destination mailbox does not exist, a server MUST return an 717 error, and MUST NOT automatically create the mailbox. Unless it 718 is certain that the destination mailbox can not be created, the 719 server MUST send the special information token "[TRYCREATE]" as 720 the prefix of the text of the tagged NO response. This gives a 721 hint to the client that it can attempt a CREATE command and retry 722 the APPEND if the CREATE is successful. 724 Note that this functionality is unsuitable for message delivery, 725 because it does not provide a mechanism to transfer RFC 821 (SMTP) 726 envelope information. 728 tag FETCH sequence data 730 The FETCH command retrieves data associated with a message in the 731 mailbox. The data items to be fetched may be either a single atom 732 or an S-expression list. The currently defined data items that 733 can be fetched are: 735 ALL Macro equivalent to: 736 (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE) 738 BODY Non-extensible form of BODYSTRUCTURE. 740 BODY[section] The text of a particular body section. The 741 section specification is a set of one or more 742 part numbers delimited by periods. 744 Single-part messages only have a part 1. 746 Multipart messages are assigned consecutive 747 part numbers, as they occur in the message. 748 If a particular part is of type message or multipart, 749 its parts must be indicated by a period followed by 750 the part number within that nested multipart part. 751 It is not permitted to fetch a multipart part 752 itself, only its individual members. 754 A part of type MESSAGE and subtype RFC822 also 755 has nested parts. These are the parts of the 756 MESSAGE part's body. Nested part 0 of a part of 757 type MESSAGE and subtype RFC822 is the RFC 822 758 header of the message. 760 Every message has at least one part. 762 EXAMPLE: Here is a complex message with its 763 associated section specifications. 764 1 TEXT/PLAIN 765 2 APPLICATION/OCTET-STREAM 766 3 MESSAGE/RFC822 767 3.0 (RFC 822 header of the message) 768 3.1 TEXT/PLAIN 769 3.2 APPLICATION/OCTET-STREAM 770 MULTIPART/MIXED 771 4.1 IMAGE/GIF 772 4.2 MESSAGE/RFC822 773 4.2.0 (RFC 822 header of the message) 774 4.2.1 TEXT/PLAIN 775 MULTIPART/ALTERNATIVE 776 4.2.2.1 TEXT/PLAIN 777 4.2.2.2 TEXT/RICHTEXT 778 Note that there is no section specification for 779 the Multi-part parts (no section 4 or 4.2.2). 781 The \Seen flag is implicitly set; if this causes 782 the flags to change they should be included as 783 part of the fetch results. 785 BODYSTRUCTURE The MIME body structure of the message. This 786 is computed by the server by parsing the MIME 787 header lines. 789 ENVELOPE The envelope structure of the message. This 790 computed by the server by parsing the RFC 822 791 header into the component parts, defaulting 792 various fields as necessary. 794 FAST Macro equivalent to: 795 (FLAGS INTERNALDATE RFC822.SIZE) 797 FLAGS The flags that are set for this message. 799 FULL Macro equivalent to: 800 (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE BODY) 802 INTERNALDATE The date and time the message was written to 803 the mailbox. 805 RFC822 The message in RFC 822 format. The \Seen 806 flag is implicitly set; if this causes the 807 flags to change they should be included as 808 part of the fetch results. This is the 809 concatenation of RFC822.HEADER and RFC822.TEXT. 811 RFC822.HEADER The RFC 822 format header of the message as 812 stored on the server including the delimiting 813 blank line between the header and the body. 815 RFC822.HEADER.LINES header_line_list 816 All header lines (including continuation lines) 817 of the RFC 822 format header of the message 818 with a field-name (as defined in RFC 822) that 819 matches any of the strings in header_line_list. 820 The matching is case-independent but otherwise 821 exact. 823 RFC822.HEADER.LINES.NOT header_line_list 824 All header lines (including continuation lines) 825 of the RFC 822 format header of the message 826 with a field-name (as defined in RFC 822) that 827 does not match any of the strings in 828 header_line_list. The matching is 829 case-independent but otherwise exact. 831 RFC822.SIZE The number of characters in the message as 832 expressed in RFC 822 format. 834 RFC822.TEXT The text body of the message, omitting the 835 RFC 822 header. The \Seen flag is implicitly 836 set; if this causes the flags to change they 837 should be included as part of the fetch results. 839 UID The unique identifier for the message. 841 EXAMPLES: 843 A003 FETCH 2:4 ALL 844 fetches the flags, internal date, RFC 822 size, and envelope 845 structure for messages 2, 3, and 4. 847 A004 FETCH 3 RFC822 848 fetches the RFC 822 representation for message 3. 850 A005 FETCH 4 (FLAGS RFC822.HEADER) 851 fetches the flags and RFC 822 format header for message 4. 853 tag PARTIAL msgno data start_octet octet_count 855 The PARTIAL command is equivalent to the associated FETCH command, 856 with the added functionality that only the specified number of 857 octets, beginning at the specified starting octet, are returned. 858 Note that only a single message can be fetched at a time. The 859 first octet of a message, and hence the minimum for the starting 860 octet, is octet 1. 862 The following FETCH items are valid data for PARTIAL: RFC822, 863 RFC822.HEADER, RFC822.TEXT, and BODY[section]. 865 Any partial fetch that attempts to read beyond the end of the text 866 is truncated as appropriate. If the starting octet is beyond the 867 end of the text, an empty string is returned. 869 The data are returned with the FETCH response. There is no 870 indication of the range of the partial data in this response; thus 871 it is generally not possible to implement caching with PARTIAL 872 data. It is also not possible to stream multiple PARTIAL commands 873 of the same data item without processing and synchronizing at each 874 step, since each PARTIAL fetch of data replaces any prior 875 (PARTIAL) FETCH of the data. 877 Note that when partial fetching it is possible to break in the 878 middle of a line or a critical sequence such as a BASE64 quadruple 879 or QUOTED-PRINTABLE shift. Implementations using partial fetching 880 should keep this in mind. There is no requirement that partial 881 fetches follow any sequence; so if it turns out that a partial 882 fetch of octets 1 through 10000 breaks in an awkward place, it is 883 permitted to continue with a partial fetch of 9987 through 19987, 884 etc. 886 The handling of the \Seen flag is the same as with the FETCH 887 command. 889 tag STORE sequence data value 891 The STORE command alters data associated with a message in the 892 mailbox. The currently defined data items that can be stored are: 894 FLAGS Replace the flags for the message with the 895 argument (in flag list format). 897 +FLAGS Add the flags in the argument to the 898 message's flag list. 900 -FLAGS Remove the flags in the argument from the 901 message's flag list. 903 EXAMPLE: A003 STORE 2:4 +FLAGS (\Deleted) 904 marks messages 2, 3, and 4 for deletion. 906 UID commands 908 These commands use unique identifiers instead of message numbers in 909 their arguments to reference a particular message or range of 910 messages. The unique identifier of a message is guaranteed not to 911 refer to any other message in the mailbox. Unlike IMAP2bis sequence 912 numbers, unique identifiers persist across sessions. 914 Sequence ranges are permitted; note however that there is no 915 guarantee that unique identifiers be contiguous. A non-existent 916 unique identifier within a sequence range is ignored without any 917 error message generated. 919 Because of the potential for ambiguity, the UID command does not 920 change responses. That is, the number after the "*" in an 921 unsolicited FETCH response is a message number, not a unique 922 identifier. However, servers MUST implicitly include UID as part of 923 any FETCH response caused by a UID command, regardless of whether UID 924 was specified. 926 EXAMPLE: C: A003 UID FETCH 4827313:4828442 FLAGS 927 S: * 23 FETCH (FLAGS (\Seen) UID 4827313) 928 S: * 24 FETCH (FLAGS (\Seen) UID 4827943) 929 S: * 25 FETCH (FLAGS (\Seen) UID 4828442) 930 S: A003 UID FETCH completed 932 tag UID AFTER uniqueid 934 The UID AFTER command determines what unique identifiers exist 935 that are greater than the specified unique identifier. It 936 returns unsolicited FETCH responses for each such message. 938 For example, if the specified unique identifier refers to 939 message 572 in a mailbox with 613 messages, the results 940 returned are equivalent to doing "FETCH 573:613 UID". 942 tag UID COPY sequence mailbox 944 The UID COPY command is identical to the COPY command, with the 945 exception that the numbers used in the sequence are unique 946 identifiers instead of message numbers. 948 tag UID FETCH sequence data 950 The UID FETCH command is identical to the FETCH command, with 951 the exception that the numbers used in the sequence are unique 952 identifiers instead of message numbers. 954 tag UID STORE sequence data value 956 The UID STORE command is identical to the STORE command, with 957 the exception that the numbers used in the sequence are unique 958 identifiers instead of message numbers. 960 tag SEARCH search_criteria 962 The SEARCH command searches the mailbox for messages that match 963 the given set of criteria. The unsolicited SEARCH <1#number> 964 response from the server is a list of messages that express the 965 intersection (AND function) of all the messages that match that 966 criteria. For example, 967 A003 SEARCH DELETED FROM "SMITH" SINCE 1-OCT-87 968 returns the message numbers for all deleted messages from Smith 969 that were placed in the mail file since October 1, 1987. 971 In all search criteria that use strings, a message matches the 972 criteria if the string is a substring of the field. The matching 973 is case-independent except as noted below. 975 The server may interpret an RFC 1522 format string to express text 976 in a character set other than US-ASCII. The criteria matches if 977 the RFC 1522 interpreted string matches an interpreted substring 978 (MIME or RFC 1522 as appropriate) of the field. 980 A server implementation may omit case-independent matching on RFC 981 1522 strings. 983 The currently defined search criteria are: 985 ALL All messages in the mailbox; the default 986 initial criterion for ANDing. 988 ANSWERED Messages with the \Answered flag set. 990 BCC istring Messages that contain the specified string 991 in the envelope structure's BCC field. 993 BEFORE date Messages whose internal date is earlier than 994 the specified date. 996 BODY istring Messages that contain the specified string 997 in the body of the message. 999 CC istring Messages that contain the specified string 1000 in the envelope structure's CC field. 1002 DELETED Messages with the \Deleted flag set. 1004 FLAGGED Messages with the \Flagged flag set. 1006 FROM istring Messages that contain the specified string 1007 in the envelope structure's FROM field. 1009 KEYWORD flag Messages with the specified flag set. 1011 NEW Messages that have the \Recent flag set but 1012 not the \Seen flag. This is functionally 1013 equivalent to "RECENT UNSEEN". 1015 OLD Messages that do not have the \Recent flag 1016 set. 1018 ON date Messages whose internal date is within the 1019 specified date. 1021 RECENT Messages that have the \Recent flag set. 1023 SEEN Messages that have the \Seen flag set. 1025 SINCE date Messages whose internal date is later than 1026 the specified date. 1028 SUBJECT istring Messages that contain the specified string 1029 in the envelope structure's SUBJECT field. 1031 TEXT istring Messages that contain the specified string. 1033 TO istring Messages that contain the specified string in 1034 the envelope structure's TO field. 1036 UIDAFTER uniqueid 1037 Messages that have a UID greater than the 1038 specified UID. 1040 UIDBEFORE uniqueid 1041 Messages that have a UID less than the 1042 specified UID. 1044 UNANSWERED Messages that do not have the \Answered flag 1045 set. 1047 UNDELETED Messages that do not have the \Deleted flag 1048 set. 1050 UNFLAGGED Messages that do not have the \Flagged flag 1051 set. 1053 UNKEYWORD flag Messages that do not have the specified flag 1054 set. 1056 UNSEEN Messages that do not have the \Seen flag set. 1058 Responses 1060 The first group of responses complete a request, and indicate whether 1061 the command was successful. The response text is a line of human 1062 readable text, optionally prefixed by an atom inside square brackets 1063 that conveys a special information token between cooperating servers 1064 and clients. 1066 The currently defined special information tokens are: 1068 PARSE An error occurred in parsing the RFC 822 or MIME 1069 headers of a message in the mailbox. 1071 READ-ONLY The mailbox is open read-only, or its access while 1072 open has changed from read-write to read-only. 1074 READ-WRITE The mailbox is open read-write, or its access while 1075 open has changed from read-only to read-write. 1077 TRYCREATE An APPEND or COPY attempt failed because the target 1078 mailbox does not exist. The server sends this as a 1079 hint to the client that the operation would probably 1080 succeed if the mailbox is first created by means of 1081 the CREATE command. 1083 UNSEEN Followed by a decimal number, indicates the number 1084 of the first unread message. This is intended to be 1085 used with certain bboard formats to assist the user 1086 in finding the first unread message in those cases 1087 where "unread" and "recent" are separate concepts. 1089 hex string A hexadecimal string is returned as a special 1090 information token to represent a Kerberos return 1091 authenticator. This only occurs in response to a 1092 LOGIN command that uses Kerberos authentication. 1094 Other special information tokens defined by particular client or 1095 server implementations should be prefixed with an "X" until they are 1096 added to a revision of this protocol. 1098 tag OK resp_text 1100 This response identifies successful completion of the command with 1101 that tag. The response text may be useful in a protocol telemetry 1102 log for debugging purposes. 1104 tag NO resp_text 1106 This response identifies unsuccessful completion of the command 1107 with that tag. The text is a line of human-readable text that 1108 probably should be displayed to the user in an error report by the 1109 client. 1111 tag BAD resp_text 1113 This response identifies faulty protocol received from the client; 1114 The text is a line of human-readable text that should be recorded 1115 in any telemetry as part of a bug report to the maintainer of the 1116 client. 1118 The second group of responses convey human-readable information. The 1119 response text is a line of human readable text, optionally prefixed 1120 by an atom inside square brackets that conveys special information 1121 between cooperating servers and clients. 1123 * PREAUTH resp_text 1125 This response is one of three possible greetings at session 1126 startup. It indicates that the session has already been 1127 authenticated by external means and thus no LOGIN command is 1128 needed. 1130 * OK resp_text 1132 This response identifies an information message from the server. 1133 It does not indicate completion of any particular request, nor is 1134 it necessarily related to any request. The text is a line of 1135 human-readable text that should be presented to the user as an 1136 information message. 1138 This response is also one of three possible greetings at session 1139 startup. It indicates that the session is not yet authenticated 1140 and that a LOGIN command is needed. 1142 * NO resp_text 1144 This response identifies a warning message from the server. It 1145 does not indicate completion of any request, nor is it necessarily 1146 related to any request. The text is a line of human-readable text 1147 that should be presented to the user as a warning of improper 1148 operation. 1150 * BAD resp_text 1152 This response identifies a serious error message from the server. 1153 It does not indicate completion of any request, nor is it 1154 necessarily related to any request. It may also indicate a faulty 1155 command from the client in which a tag could not be parsed. The 1156 text is a line of human-readable text that should be presented to 1157 the user as a serious or possibly fatal error. 1159 * BYE text 1161 This response identifies that the server is about to close the 1162 connection. The text is a line of human-readable text that should 1163 be displayed to the user in a status report by the client. This 1164 may be sent as part of a normal logout sequence, or as a panic 1165 shutdown announcement by the server. It is also used by some 1166 servers as an announcement of an inactivity autologout. 1168 This response is also one of three possible greetings at session 1169 startup. It indicates that the server is not willing to accept a 1170 session from this client. 1172 The third group of responses convey data about the mailbox or 1173 messages inside the mailbox. This is how message data are 1174 transmitted from the server to the client. 1176 * MAILBOX mstring 1178 This response occurs as a result of a FIND command for MAILBOXES 1179 and ALL.MAILBOXES. The string is a mailbox name that matches the 1180 pattern in the command. 1182 * BBOARD mstring 1184 This response occurs as a result of a FIND command for BBOARDS and 1185 ALL.BBOARDS. The string is a bulletin board name that matches the 1186 pattern in the command. 1188 * SEARCH number(s) 1190 This response occurs as a result of a SEARCH command. The 1191 number(s) refer to those messages that match the search criteria. 1192 Each number is delimited by a space, e.g., "SEARCH 2 3 6". 1194 * FLAGS flag_list 1196 This response generally occurs as a result of a selection command 1197 (SELECT, BBOARD, and EXAMINE). The flag list are the list of 1198 flags (at a minimum, the system-defined flags) that are applicable 1199 for this mailbox. Flags other than the system flags are a 1200 function of the server implementation. 1202 * number message_data 1204 This response occurs as a result of any command when a mailbox is 1205 selected. The message_data is one of the following: 1207 EXISTS The number of messages in the mailbox. 1209 RECENT The number of messages that have arrived since the 1210 previous time this mailbox was read. 1212 EXPUNGE The specified message number has been permanently 1213 removed from the mailbox, and the next message in the 1214 mailbox (if any) becomes that message number. 1216 An unsolicited EXPUNGE response MUST NOT be sent except 1217 while responding to a request other than FETCH, STORE, 1218 or SEARCH. All references to message numbers sent after 1219 an unsolicited EXPUNGE response are adjusted to reflect 1220 the effect of the expunge. 1222 Discussion: a potential ambiguity exists with 1223 the FETCH, STORE, and SEARCH requests if the 1224 server is permitted to send unsolicited EXPUNGE 1225 responses. This is because these requests can be 1226 streamed. If two successive FETCH requests are 1227 streamed, and if during the time of the processing 1228 of the first request there is an expunge response, 1229 then the sequence of the second request is no 1230 longer valid. 1232 FETCH data 1233 This is the principal means that data about a message 1234 are returned to the client. The data are in an 1235 S-expression form, and consists of a sequence of pairs 1236 of data item name and their values. The current data 1237 items are: 1239 BODY Similar to BODYSTRUCTURE, but without the extension 1240 data. 1242 BODY[section] A string expressing the body contents of the 1243 specified section. The string should be 1244 interpreted by the client according to the 1245 content transfer encoding, body type, and subtype. 1247 Note that non-textual data are transfer encoded; 1248 therefore, the string is likely to be 7-bit 1249 US-ASCII. This is NOT necessarily the byte size 1250 or character set of the interpreted result. 1252 BODYSTRUCTURE An S-expression format list that describes the body 1253 structure of a message. This is computed by the 1254 server by parsing the RFC 822 header and body into 1255 the component parts, defaulting various fields 1256 as necessary. 1258 Multiple parts are indicated by S-expression 1259 nesting. Instead of a body type as the first element 1260 of the list there is a nested body. The second 1261 element of the list is the multipart subtype (mixed, 1262 digest, parallel, alternative, etc.). 1264 Extension data follows the multipart subtype. 1265 Extension data is never returned with the older 1266 BODY fetch, but may be returned with a BODYSTRUCTURE 1267 fetch. Extension data, if present, must be in the 1268 defined order. 1270 No multipart extension data is currently defined. 1272 Any subsequent data is extension data, not yet defined 1273 in this version of the protocol. Such extension data 1274 consist of zero or more NILs, strings, numbers, 1275 and/or potentially nested lists of such data. Clients 1276 which do a BODYSTRUCTURE fetch MUST be prepared to 1277 accept such extension data. Servers MUST NOT send 1278 such extension data until it has been defined by a 1279 future version of the protocol. 1281 The basic fields of a non-multipart body part are in 1282 the following order: 1283 body type - a string giving the content type name 1284 as defined in MIME 1285 body subtype - a string giving the content subtype 1286 name as defined in MIME 1287 body parameter list - an S-expression list of 1288 attribute/value pairs [e.g. (foo bar baz rag) 1289 where "bar" is the value of "foo" and "rag" is 1290 the value of "baz"] as defined in MIME. 1291 body id - a string giving the content id as 1292 defined in MIME. 1293 body description - a string giving the content 1294 description as defined in MIME. 1295 body encoding - a string giving the content 1296 transfer encoding as defined in MIME. 1297 body size - a number giving the size of the 1298 body in octets. Note that this size is the 1299 size in its transfer encoding and not the 1300 resulting size after any decoding. 1302 A body type of type MESSAGE and subtype RFC822 1303 contains, immediately after the basic fields, 1304 the envelope structure, body structure, and 1305 size in text lines of the encapsulated message. 1307 A body type of type TEXT contains, immediately 1308 after the basic fields, the size of the body 1309 in text lines. Note that this size is the size 1310 in its transfer encoding and not the resulting 1311 size after any decoding. 1313 Extension data follows the basic fields and the 1314 type-specific fields listed above. Extension data 1315 is never returned with the older BODY fetch, but 1316 may be returned with a BODYSTRUCTURE fetch. 1317 Extension data, if present, must be in the defined 1318 order. 1320 The extension data of a non-multipart body part are 1321 in the following order: 1322 body MD5 - a string giving the content MD5 value 1323 as defined in MIME 1325 Any subsequent extension data are not yet defined 1326 in this version of the protocol, and would be in the 1327 form described above under multipart extension data. 1329 ENVELOPE An S-expression format list that describes the 1330 envelope structure of a message. This is computed 1331 by the server by parsing the RFC 822 header into 1332 the component parts, defaulting various fields 1333 as necessary. 1335 The fields of the envelope structure are in the 1336 following order: date, subject, from, sender, 1337 reply-to, to, cc, bcc, in-reply-to, and message-id. 1338 The date, subject, in-reply-to, and message-id fields 1339 are strings. The from, sender, reply-to, to, cc, 1340 and bcc fields are lists of address structures. 1342 An address structure is an S-expression format list 1343 that describes an electronic mail address. The 1344 fields of an address structure are in the following 1345 order: personal name, source-route (a.k.a. the 1346 at-domain-list in SMTP), mailbox name, and 1347 host name. 1349 RFC 822 group syntax is indicated by a special 1350 form of address structure in which the host name 1351 file is NIL. If the mailbox name field is also NIL, 1352 this is an end of group marker (semi-colon in RFC 822 1353 syntax). If the mailbox name field is non-NIL, 1354 this is a start of group marker, and the mailbox 1355 name field holds the group name phrase. 1357 Any field of an envelope or address structure that 1358 is not applicable is presented as the atom NIL. 1359 Note that the server must default the reply-to 1360 and sender fields from the from field; a client is 1361 not expected to know to do this. 1363 FLAGS An S-expression format list of flags that are set 1364 for this message. This may include the following 1365 system flags: 1367 \Seen Message has been read 1368 \Answered Message has been answered 1369 \Flagged Message is "flagged" for 1370 urgent/special attention 1371 \Deleted Message is "deleted" for 1372 removal by later EXPUNGE 1374 as well as the following special flag: 1376 \Recent Message arrived since the 1377 previous time this mailbox 1378 was read 1380 INTERNALDATE A string containing the date and time the 1381 message was written to the mailbox. 1383 RFC822 A string expressing the message in RFC 822 1384 format. 1386 RFC822.HEADER A string expressing the RFC 822 format header 1387 of the message, including the delimiting 1388 blank line between the header and the body. 1389 This is used for the FETCH data items 1390 RFC822.HEADER, RFC822.HEADER.LINES, and 1391 RFC822.HEADER.LINES.NOT (note that a blank 1392 line is always included regardless of header 1393 line restrictions). 1395 RFC822.SIZE A number indicating the number of 1396 characters in the message as expressed 1397 in RFC 822 format. 1399 RFC822.TEXT A string expressing the text body of the 1400 message, omitting the RFC 822 header. 1402 UID A number expressing the unique identifier 1403 of the message. 1405 COPY Obsolete. New server implementations MUST NOT transmit 1406 this response. Client implementations SHOULD ignore 1407 this response (not report an error). 1409 STORE data 1410 Obsolete and functionally equivalent to FETCH. New 1411 server implementations MUST NOT transmit this response. 1412 Client implementations SHOULD treat this response as 1413 equivalent to the FETCH response. 1415 The final group of responses contains a single, special purpose 1416 response. 1418 + resp_text 1420 This response identifies that the server is ready to accept the 1421 text of a literal from the client. The text of this response is a 1422 line of human-readable text of the server's choosing (it is 1423 generally never seen by a client's human user). 1425 The purpose of this command is to solve a synchronization problem 1426 that can occur if a string in a command is a literal. This may 1427 occur when logging in (if the password contains "funny" 1428 characters), and always occurs when using the APPEND command, 1429 since a message consists of multiple lines. 1431 Normally, a command from the client is a single text line. If the 1432 server detects an error in the command, it can simply discard the 1433 remainder of the line. It cannot do this for commands that 1434 contain literals, since a literal can be an arbitrarily long 1435 amount of text, and the server may not even be expecting a 1436 literal. This mechanism is provided so the client knows not to 1437 send a literal until the server expects it, preserving 1438 client/server synchronization. 1440 No such synchronization protection is provided for literals sent 1441 from the server to the client. Any synchronization problems in 1442 this direction would be caused by a bug in the client or server. 1444 Sample IMAP2bis session 1446 The following is a transcript of an IMAP2bis session. A long line in 1447 this sample is broken for editorial clarity. 1449 S: * OK IMAP2bis Service 7.2(62) at Thu, 29 Jul 1993 21:34:23 -0700 (PDT) 1450 C: a001 login mrc secret 1451 S: a001 OK LOGIN completed 1452 C: a002 select inbox 1453 S: * 18 EXISTS 1454 S: * FLAGS (\Answered \Flagged \Deleted \Seen) 1455 S: * 0 RECENT 1456 S: a002 OK [READ-WRITE] SELECT completed 1457 S: a003 fetch 12 full 1458 S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "14-Jul-1993 02:44:25 -0700" 1459 RFC822.SIZE 4282 ENVELOPE ("Wed, 14 Jul 1993 02:23:25 -0700 (PDT)" 1460 "IMAP2bis WG mtg summary and minutes" (("Terry Gray" NIL "gray" 1461 "cac.washington.edu")) ((NIL NIL "owner-imap" "cac.washington.edu")) 1462 (("Terry Gray" NIL "gray" "cac.washington.edu")) ((NIL NIL "imap" 1463 "cac.washington.edu")) ((NIL NIL "minutes" "CNRI.Reston.VA.US") 1464 ("John C Klensin" NIL "KLENSIN" "INFOODS.MIT.EDU")("Erik Huizer" 1465 NIL "Erik.Huizer" "SURFnet.nl")) NIL NIL 1466 "") 1467 BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92)) 1468 S: a003 OK FETCH completed 1469 C: a004 fetch 12 rfc822.header 1470 S: * 12 FETCH (RFC822.HEADER {485} 1471 S: Date: Wed, 14 Jul 1993 02:23:25 -0700 (PDT) 1472 S: From: Terry Gray 1473 S: Reply-To: Terry Gray 1474 S: Subject: IMAP2bis WG mtg summary and minutes 1475 S: To: imap@cac.washington.edu 1476 S: Cc: minutes@CNRI.Reston.VA.US, 1477 S: John C Klensin , 1478 S: Erik Huizer 1479 S: Message-Id: 1480 S: 1481 S: Mime-Version: 1.0 1482 S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 1483 S: 1484 S: ) 1485 S: a004 OK FETCH completed 1486 C: a005 store 12 +flags \deleted 1487 S: * 12 FETCH (FLAGS (\Seen \Deleted)) 1488 S: a005 OK +FLAGS completed 1489 C: a006 logout 1490 S: * BYE IMAP2bis server terminating connection 1491 S: a006 OK LOGOUT completed 1493 Design Discussion 1495 IMAP2bis is a textual protocol. The use of MIME encoding in IMAP2bis 1496 makes it possible to support 8-bit textual and binary mail. 1498 IMAP2bis implementations MAY transmit 8-bit or multi-octet characters 1499 in literals, but should do so only when the character set is 1500 identified. For example, 8-bit characters are specifically permitted 1501 in MIME body parts (fetching BODY[section]) of type TEXT. 8-bit 1502 characters are also permitted in the argument to APPEND. 1504 Servers MUST NOT transmit 8-bit characters in RFC822.HEADER fetch 1505 results. Servers MUST NOT transmit 8-bit characters in RFC822.TEXT 1506 (and by extension RFC822) fetch results, unless there are MIME data 1507 in the message that identify the character sets of all 8-bit data. 1509 Because 8-bit characters are permitted in the argument to APPEND, a 1510 server that is unable to preserve 8-bit data properly MUST be able to 1511 reversibly convert 8-bit APPEND data to 7-bit using MIME. 1513 Although a BINARY body encoding is defined, IMAP2bis does not permit 1514 unencoded binary strings. A "binary string" is any string with NUL 1515 characters; a string with an excessive amount of CTL characters may 1516 also be considered to be binary. The mixing of unencoded binary in 1517 the same stream as textual commands would make the protocol more 1518 vulnerable to synchronization problems. Implementations MUST encode 1519 binary data into BASE64 before transmitting it with IMAP2bis. 1521 When operating in the online model, an IMAP2bis client should 1522 maintain a local cache of data from the mailbox. This cache is an 1523 incomplete model of the mailbox, and at startup is generally empty. 1524 As the client processes all unsolicited data, it updates the cache 1525 based on this data. When a tagged response arrives, the client's 1526 cache has been updated from the associated request. 1528 Note that a server can send data that the client did not request, 1529 such as mailbox size or flag updates. A server MUST send mailbox 1530 size updates automatically while processing a command. A server 1531 SHOULD send message flag updates automatically, without requiring the 1532 client to request such updates explicitly. 1534 Regardless of what implementation decisions a client may take on 1535 caching, a client MUST record EXISTS and RECENT updates and MUST NOT 1536 assume that a CHECK or NOOP command will return EXISTS or RECENT 1537 information. 1539 Although it is permitted for a server to send an unsolicited response 1540 while there is no command in progress, this practice SHOULD NOT be 1541 followed because of flow control considerations. It can cause an 1542 incautious implementation to deadlock. A deadlock is avoided if 1543 either of the following conditions are true: (1) except for the 1544 greeting, the server never sends responses while there is no command 1545 in progress; (2) the server process is capable of reading commands 1546 while sending data. The latter condition generally requires either a 1547 multi-threading server implementation or use of a polling facility 1548 and non-blocking I/O. 1550 If a server has an inactivity autologout timer, that timer MUST be of 1551 at least 30 minutes' duration. The receipt of a NOOP command from 1552 the client during that interval should suffice to reset the 1553 autologout timer. Periodic transmission of a NOOP from the client 1554 during periods of inactivity also has the benefit of avoiding the 1555 possible deadlock noted above. 1557 It is frequently asked why there is no message posting function in 1558 IMAP2bis. Message posting is orthogonal to the scope of a mail 1559 access protocol and detracts from its primary focus. SMTP (RFC 821) 1560 provides the minimal functionality needed for message posting without 1561 losing valuable capabilities (such as blind carbon copies). Any 1562 message posting function in IMAP2bis would need, at a minimum, to 1563 provide equivalent functionality. 1565 At the time of the writing of this document, an extensive set of 1566 extensions to SMTP is in the Internet standards process. Should 1567 those extensions become an Internet Standard it would be necessary to 1568 revise IMAP2bis again to provide corresponding capabilities, were a 1569 message posting facility to be included in IMAP2bis. In other words, 1570 a duplication of effort would be required each time a change is made 1571 to message transport technology. 1573 Another undesirable aspect of message posting in IMAP2bis occurs when 1574 a remote server is used. It is unlikely that a client would support 1575 multiple means of posting a message. It adds excessive size and 1576 complexity that can not be afforded, particularly on smaller 1577 machines. It also can lead to poor performance. Consider a client 1578 connecting to an IMAP2bis server over an interactive satellite link 1579 to a foreign country. A local message posting (SMTP) server is 1580 available that uses a lower-cost batched link. Here, it would be 1581 wasteful to use the interactive link for posting. 1583 Message posting to IMAP2bis has been suggested as a means of 1584 authenticating postings. The problem is that access authentication 1585 credentials are not necessarily the same as posting authentication 1586 credentials. At some sites, the disclosure of a portion of access 1587 authentication credentials in a mail message (as a "From" or "Sender" 1588 address) may be a serious security breach of greater significance 1589 than forged mail. 1591 The Internet message transport infrastructure has no concept of 1592 authentication credentials, and neither authentication syntax nor 1593 semantics are transferred within a message. As a result, any attempt 1594 at authenticating a message via posting authentication is completely 1595 ineffective once the message leaves the authenticating server; any 1596 indication of authentication in the message can easily be reproduced 1597 further down the line. Public-key based message authentication 1598 systems such as Privacy Enhanced Mail are now under development to 1599 address this problem. 1601 IMAP2bis does not address problems with multiple IMAP2bis servers at 1602 a single site, access control lists, and mobility of client 1603 configuration and address book information. These and other issues 1604 are being considered for a companion protocol. 1606 Formal Syntax 1608 The following syntax specification uses the augmented Backus-Naur 1609 Form (BNF) notation as specified in RFC 822 with one exception; the 1610 delimiter used with the "#" construct is a single space (SPACE) and 1611 not a comma. 1613 Except as noted otherwise, all alphabetic characters in the IMAP2bis 1614 protocol are case-insensitive. For example, "LOGIN", "login" and 1615 "lOgIn" all refer to the same command, and \FLAGGED, \Flagged, and 1616 \FlAgGeD all refer to the same flag. The use of upper or lower case 1617 characters to define token strings is for editorial clarity only, 1618 although they may be construed as defining a suggested usage. 1619 Implementations MUST accept these strings in a case-insensitive 1620 fashion. 1622 Syntax marked as obsolete may be encountered with implementations 1623 written for an older version of this specification. New 1624 implementations SHOULD accept obsolete syntax as input, but MUST NOT 1625 otherwise use it. 1627 address ::= "(" addr_name SPACE addr_adl SPACE addr_mailbox 1628 SPACE addr_host ")" 1630 addr_adl ::= nstring 1632 addr_host ::= nstring 1633 ;; NIL indicates RFC 822 group syntax 1635 addr_mailbox ::= nstring 1636 ;; NIL indicates end of RFC 822 group; if non-NIL 1637 ;; and addr_host is NIL, holds RFC 822 group name 1639 addr_name ::= nstring 1641 append ::= "APPEND" SPACE mailbox [SPACE 1#flag] SPACE literal 1643 astring ::= atom / string 1645 atom ::= 1* 1647 bboard ::= "BBOARD" SPACE mailbox_bboard 1649 body ::= "(" body_structure ")" 1651 body2 ::= "(" body2_structure ")" 1652 body2_extension ::= nstring / number / "(" 1#body2_extension ")" 1653 ;; Future expansion. Clients MUST accept body2 1654 ;; extension fields. Servers MUST NOT generate 1655 ;; body2 extension fields. 1657 body2_md5 ::= nstring 1658 ;; reserved for MD5 checksum 1660 body2_multipart ::= 1*body2 SPACE body_subtype [SPACE 1#body2_extension] 1662 body2_structure ::= body2_terminal / body2_multipart 1664 body2_terminal ::= body_terminal SPACE body2_md5 [SPACE 1#body2_extension] 1666 body_basic ::= body_type_basic SPACE body_subtype SPACE body_fields 1668 body_fields ::= body_parameter SPACE body_id SPACE body_description 1669 SPACE body_encoding SPACE body_size 1671 body_description 1672 ::= nstring 1674 body_encoding ::= <"> body_enc_def <"> / body_enc_other 1676 body_enc_def ::= "7BIT" / "8BIT" / "BINARY" / "BASE64"/ 1677 "QUOTED-PRINTABLE" 1679 body_enc_other ::= string 1681 body_id ::= nstring 1683 body_msg ::= body_msg_822 / body_msg_other 1685 body_msg_822 ::= body_type_msg SPACE body_subtyp_822 SPACE body_fields 1686 SPACE envelope SPACE body SPACE body_size_lines 1688 body_msg_other ::= body_type_msg SPACE body_subtype SPACE body_fields 1689 ;; subtype MUST NOT be "RFC822" 1691 body_multipart ::= 1*body SPACE body_subtype 1693 body_parameter ::= nil / "(" 1#(string string) ")" 1695 body_section ::= number / number "." body_section 1697 body_size ::= number 1698 ;; size in octets 1700 body_size_lines ::= number 1702 body_structure ::= body_terminal / body_multipart 1704 body_subtype ::= string 1706 body_subtyp_822 ::= <"> "RFC822" <"> 1708 body_terminal ::= body_basic / body_msg / body_text 1710 body_text ::= body_type_text SPACE body_subtype SPACE body_fields 1711 SPACE body_size_lines 1713 body_type_basic ::= <"> ("APPLICATION" / "AUDIO" / "IMAGE" / "VIDEO") <"> / 1714 string 1716 body_type_msg ::= <"> "MESSAGE" <"> 1718 body_type_text ::= <"> "TEXT" <"> 1720 CHAR ::= 1722 CHAR8 ::= 1724 check ::= "CHECK" 1726 copy ::= "COPY" SPACE sequence SPACE mailbox 1728 CR ::= 1730 create ::= create_real / create_check 1732 create_check ::= "CREATE" SPACE "INBOX" 1733 ;; returns a NO response (not BAD) 1735 create_real ::= "CREATE" SPACE mailbox_other 1737 CRLF ::= CR LF 1739 CTL ::= 1742 date ::= date_text / <"> date_text <"> 1744 date_day ::= 1*2DIGIT 1745 ;; day of month 1747 date_day_fixed ::= (SPACE 1DIGIT) / 2DIGIT 1748 ;; fixed-format version of date_day 1750 date_month ::= "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" / 1751 "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec" 1753 date_text ::= date_day "-" date_month "-" (date_year / date_year_old) 1755 date_year ::= 4DIGIT 1757 date_year_old ::= 2DIGIT 1758 ;; Obsolete, (year - 1900) 1760 date_time ::= <"> (date_time_new / date_time_old) <"> 1762 date_time_new ::= date_day_fixed "-" date_month "-" date_year SPACE 1763 time SPACE zone 1765 date_time_old ::= date_day_fixed "-" date_month "-" date_year_old SPACE 1766 time "-" zone_old 1767 ;; Obsolete 1769 delete ::= "DELETE" SPACE mailbox_other 1771 DIGIT ::= 1773 DIGIT_HEX :: DIGIT / "a" / "b" / "c" / "d" / "e" / "f" 1775 envelope ::= "(" env_date SPACE env_subject SPACE env_from SPACE 1776 env_sender SPACE env_reply-to SPACE env_to SPACE 1777 env_cc SPACE env_bcc SPACE env_in-reply-to SPACE 1778 env_message-id ")" 1780 env_bcc ::= nil / "(" 1*address ")" 1782 env_cc ::= nil / "(" 1*address ")" 1784 env_date ::= nstring 1786 env_from ::= nil / "(" 1*address ")" 1788 env_in-reply-to ::= nstring 1790 env_message-id ::= nstring 1792 env_reply-to ::= nil / "(" 1*address ")" 1794 env_sender ::= nil / "(" 1*address ")" 1796 env_subject ::= nstring 1797 env_to ::= nil / "(" 1*address ")" 1799 examine ::= "EXAMINE" SPACE mailbox 1801 expunge ::= "EXPUNGE" 1803 fetch ::= "FETCH" SPACE sequence SPACE ("ALL" / "FULL" / 1804 "FAST" / fetch_att / "(" 1#fetch_att ")") 1806 fetch_att ::= fetch_att_lines / fetch_att_other / fetch_att_text 1808 fetch_att_lines ::= "RFC822.HEADER.LINES" SPACE header_line_list / 1809 "RFC822.HEADER.LINES.NOT" SPACE header_line_list / 1811 fetch_att_other ::= "BODY" / "BODYSTRUCTURE" / "ENVELOPE" / "FLAGS" / 1812 "INTERNALDATE" / "RFC822.SIZE" / "UID" 1814 fetch_att_text ::= "BODY[" body_section "]" / "RFC822" / 1815 "RFC822.HEADER" / "RFC822.TEXT" 1817 find ::= find_mailbox / find_bboard 1819 find_bboard ::= find_bboards / find_boards_all 1821 find_bboards ::= "FIND" SPACE "BBOARDS" SPACE find_pattern 1823 find_bboards_all 1824 ::= "FIND" SPACE "ALL.BBOARDS" SPACE find_pattern 1826 find_mailbox ::= find_mailboxes / find_mailboxes_all 1828 find_mailboxes ::= "FIND" SPACE "MAILBOXES" SPACE find_pattern 1830 find_mailboxes_all 1831 ::= "FIND" SPACE "ALL.MAILBOXES" SPACE find_pattern 1833 find_pattern ::= astring 1834 ;; includes find_wildcards 1836 find_wildcards ::= "%" / "?" / "*" 1838 flag ::= user_flag / system_flag 1840 flag_list ::= "(" 1#flag ")" 1842 flags ::= 1#flag / flag_list 1844 greeting ::= "*" SPACE (resp_cond_auth / resp_cond_bye) CRLF 1845 header_line ::= astring 1847 header_line_list 1848 ::= "(" 1#header_line ")" 1850 inbox ::= "INBOX" 1851 ;; case-independent, but SHOULD be upper-case 1853 istring ::= astring 1854 ;; possible RFC 1522 format data 1856 kerberos_authenticator 1857 ::= 1*DIGIT_HEX 1859 kerberos_response 1860 ::= 1*DIGIT_HEX 1862 LF ::= 1864 literal ::= "{" number "}" CRLF 1*CHAR8 1865 ;; The number represents the number of CHAR8 octets. 1867 login ::= "LOGIN" SPACE userid SPACE password 1869 logout ::= "LOGOUT" 1871 mailbox ::= inbox / mailbox_other 1873 mailbox_bboard ::= astring 1874 ;; May not be INBOX (in any case). Should not 1875 ;; include find_wildcards. May be case-dependent 1876 ;; as a function of server implementation. May 1877 ;; be a different namespace from mailbox_other. 1879 mailbox_other ::= astring 1880 ;; May not be INBOX (in any case). Should not 1881 ;; include find_wildcards. May be case-dependent 1882 ;; as a function of server implementation 1884 mailbox_data ::= "MAILBOX" SPACE mstring / "BBOARD" SPACE mstring / 1885 "SEARCH" [SPACE 1#number] / "FLAGS" SPACE flag_list 1887 message_data ::= number SPACE (msg_exists / msg_recent / msg_expunge / 1888 msg_fetch / msg_obsolete) 1890 msg_copy ::= "COPY" 1891 ;; Obsolete 1893 msg_exists ::= "EXISTS" 1895 msg_expunge ::= "EXPUNGE" 1897 msg_fetch ::= "FETCH" SPACE "(" 1#("BODY" SPACE body / 1898 "BODYSTRUCTURE" SPACE body2 / 1899 "BODY[" body_section "]" nstring / 1900 "ENVELOPE" SPACE envelope / 1901 "FLAGS" SPACE "(" 0#(recent_flag / flag) ")" / 1902 "INTERNALDATE" SPACE date_time / 1903 "RFC822" SPACE nstring / 1904 "RFC822.HEADER" SPACE nstring / 1905 "RFC822.SIZE" SPACE number / 1906 "RFC822.TEXT" SPACE nstring / 1907 "UID" SPACE uniqueid) ")" 1909 msg_obsolete ::= msg_copy / msg_store 1910 ;; Obsolete unsolicited data responses 1912 msg_recent ::= "RECENT" 1914 msg_store ::= "STORE" SPACE "(" 1#("FLAGS" SPACE 1915 "(" 0#(recent_flag / flag) "))" 1916 ;; Obsolete 1918 mstring ::= text_line 1919 ;; Represents a mailbox 1921 nil ::= "NIL" 1923 noop ::= "NOOP" 1925 nstring ::= nil / string 1927 number ::= 1*DIGIT 1929 partial ::= "PARTIAL" SPACE number SPACE fetch_att_text SPACE 1930 number SPACE number 1932 password ::= astring / "@KERBEROS:" kerberos_authenticator 1934 QCHAR ::= 1936 qspecials ::= <"> / "%" / "\" 1937 quoted_string ::= <"> *QCHAR <"> 1939 recent_flag ::= "\Recent" 1941 ready ::= "+" SPACE resp_text 1943 rename ::= "RENAME" SPACE mailbox SPACE mailbox_other 1945 request ::= tag SPACE (request_auth / request_authed / 1946 request_open) 1947 ;; modal based on state 1949 request_any ::= noop / logout 1950 ;; valid in all modes 1952 request_auth ::= request_any / login 1953 ;; valid only when in not authenticated mode 1955 request_authed ::= request_any / create / delete / rename / find / 1956 subscribe / unsubscribe / select / examine / bboard / 1957 append / x_command 1958 ;; valid only when in authenticated or mailbox open 1959 mode 1961 request_open ::= request_authed / check / expunge / copy / fetch / 1962 partial / store / uid / search / x_command 1963 ;; valid only when in mailbox open mode 1965 response ::= * response_done 1967 response_data ::= "*" SPACE (resp_cond_state / resp_cond_bye / 1968 mailbox_data / message_data) CRLF 1970 response_done ::= response_tagged / response_fatal 1972 response_fatal ::= "*" SPACE resp_cond_bye CRLF 1974 response_tagged ::= tag SPACE resp_cond_state CRLF 1976 resp_cond_auth ::= ("OK" / "PREAUTH") SPACE resp_text 1977 ;; authentication condition 1979 resp_cond_bye ::= "BYE" SPACE resp_text 1980 ;; server will disconnect condition 1982 resp_cond_state ::= ("OK" / "NO" / "BAD") SPACE resp_text 1983 ;; status condition 1985 resp_text ::= [resp_token SPACE] text_line 1986 resp_token ::= "[" resp_token_type "]" [SPACE res_token_arg] 1988 resp_token_arg ::= 1#number 1989 ;; arguments depend upon token type 1991 resp_token_type ::= "PARSE" / "READ-ONLY" / "READ-WRITE" / "TRYCREATE" / 1992 "UNSEEN" / "X" atom / kerberos_response 1994 search ::= "SEARCH" SPACE 1#("ALL" / "ANSWERED" / 1995 "BCC" SPACE istring / "BEFORE" SPACE date / 1996 "BODY" SPACE istring / "CC" SPACE istring / "DELETED" / 1997 "FLAGGED" / "FROM" space istring / 1998 "KEYWORD" SPACE user_flag / "NEW" / "OLD" / 1999 "ON" SPACE date / "RECENT" / "SEEN" / 2000 "SINCE" SPACE date / "SUBJECT" SPACE istring / 2001 "TEXT" SPACE istring / "TO" SPACE istring / 2002 "UIDBEFORE" SPACE uniqueid / "UIDAFTER" SPACE uniqueid 2003 / 2004 "UNANSWERED" / "UNDELETED" / "UNFLAGGED" / 2005 "UNKEYWORD" SPACE user_flag / "UNSEEN") 2007 select ::= "SELECT" SPACE mailbox 2009 sequence ::= number / (sequence "," sequence) / (number ":" number) 2010 ;; identifies a set of messages by consecutive numbers 2011 ;; from 1 to the number of messages in the mailbox. 2012 ;; Comma delimits individual numbers, colon delimits 2013 ;; between two numbers inclusive. 2014 ;; Example: 2,4:7,9,12:15 is 2,4,5,6,7,9,12,13,14,15 2016 SPACE ::= 2018 specials ::= "(" / ")" / "{" / qspecials 2020 store ::= "STORE" SPACE sequence SPACE store_att 2022 store_att ::= "+FLAGS" SPACE flags / "-FLAGS" SPACE flags / 2023 "FLAGS" SPACE flags 2025 string ::= quoted_string / literal 2027 subscribe ::= subscribe_mailbox / subscribe_bboard 2029 subscribe_bboard 2030 ::= "SUBSCRIBE" SPACE "BBOARD" SPACE mailbox_bboard 2032 subscribe_mailbox 2033 ::= "SUBSCRIBE" SPACE "MAILBOX" SPACE mailbox 2035 system_flag ::= "\Answered" / "\Flagged" / "\Deleted" / "\Seen" / 2036 system_flag_new 2038 system_flag_new ::= "\" atom 2039 ;; future expansion 2041 tag ::= 1* 2043 text_line ::= 1* 2045 time ::= 2DIGIT ":" 2DIGIT ":" 2DIGIT 2046 ;; hours minutes seconds 2048 uid ::= "UID" SPACE (uid_after / copy / fetch / store) 2049 ;; uniqueids used instead of message numbers 2051 uid_after ::= "AFTER" SPACE uniqueid 2053 uniqueid ::= number 2054 ;;; strictly ascending 2056 unsubscribe ::= unsubscribe_mailbox / unsubscribe_bboard 2058 unsubscribe_bboard 2059 ::= "UNSUBSCRIBE" SPACE "BBOARD" SPACE mailbox_bboard 2061 unsubscribe_mailbox 2062 ::= "UNSUBSCRIBE" SPACE "MAILBOX" SPACE mailbox_mailbox 2064 userid ::= astring 2066 user_flag ::= atom 2068 x_command ::= "X" atom 2069 ;; experimental expansion commands 2071 zone ::= ("+" / "-") 4DIGIT 2072 ;; Signed four-digit value of hhmm representing 2073 ;; hours and minutes west of Greenwich (that is, 2074 ;; (the amount that the given time differs from 2075 ;; Universal Time). Subtracting the timezone 2076 ;; from the given time will give the UT form. 2077 ;; The Universal Time zone is "+0000". 2079 zone_old ::= "UT" / "GMT" / "Z" / ;; +0000 2080 "AST" / "EST" / "CST" / "MST" / ;; -0400 to -0700 2081 "PST" / "YST" / "HST" / "BST" / ;; -0800 to -1100 2082 "ADT" / "EDT" / "CDT" / "MDT" / ;; -0300 to -0600 2083 "PDT" / "YDT" / "HDT" / "BDT" / ;; -0700 to -1000 2084 "A" / "B" / "C" / "D" / "E" / "F" / ;; +0100 to +0600 2085 "G" / "H" / "I" / "K" / "L" / "M" / ;; +0700 to +1200 2086 "N" / "O" / "P" / "Q" / "R" / "S" / ;; -0100 to -0600 2087 "T" / "U" / "V" / "W" / "X" / "Y" ;; -0700 to -1200 2088 ;; Obsolete 2090 A protocol session is as follows: 2092 Server: greeting 2093 * 2097 Server: response 2098 > 2100 Compatibility Notes 2102 This is a summary of hints and recommendations to enable an IMAP2bis 2103 implementation, written to this specification, to interoperate with 2104 implementations that conform to earlier specifications. None of 2105 these hints and recommendations are required by this specification; 2106 implementors must decide for themselves whether they want their 2107 implementation to fail if it encounters old software. 2109 IMAP2bis has been designed to be upwards compatible with earlier 2110 specifications. IMAP2bis facilities that were not in earlier 2111 specifications should be invisible to clients unless the client asks 2112 for the facility. 2114 This information may not be complete; it reflects current knowledge 2115 of server and client implementations as well as "folklore" acquired 2116 in the evolution of the protocol. 2118 IMAP2bis client interoperability with old servers 2120 In general, a client should be able to discover whether a server 2121 supports a facility by trial-and-error; if an attempt to use a 2122 facility generates a BAD response, the client can assume that the 2123 server does not support the facility. 2125 Some servers may disable certain commands as a matter of 2126 intentional site policy. For example, a bboard-only server may 2127 disable the SELECT command. Such servers should return a NO 2128 response to disabled commands instead of a BAD response. 2130 A quick way to check whether a server implementation supports this 2131 specification is to try a UID FETCH 0 UID command. An OK or NO 2132 response would indicate a server that conforms to this 2133 specification; a BAD response would indicate an older server. 2135 The CREATE, DELETE, and RENAME commands are new in IMAP2bis, 2136 and may not be present in old servers. A safe mechanism to 2137 test whether these commands are present is to try a CREATE 2138 INBOX command. If the response is NO, these commands are 2139 supported by the server. If the response is BAD, they are not. 2140 If the response is OK, the server's implementation is broken, 2141 since creating INBOX is not permitted. 2143 The FIND MAILBOXES and FIND BBOARDS commands are new in RFC 2144 1176. A BAD response to these commands indicates a server that 2145 does not support any form of FIND. It also indicates a server 2146 that does not support SUBSCRIBE and UNSUBSCRIBE. Note that the 2147 definition of the FIND MAILBOXES and FIND BBOARDS commands in 2148 RFC 1176 differs from the definition in this specification; in 2149 RFC 1176 these commands were defined as returning a list of 2150 mailboxes or bulletin boards with no clear specification of 2151 whether the returned values were "subscribed" or "all possible" 2152 names. 2154 The FIND ALL.MAILBOXES and FIND ALL.BBOARDS commands are new in 2155 IMAP2bis. A BAD response to these commands indicates a server 2156 that does not support a concept of subscriptions to a mailbox 2157 or bulletin board. The server may support FIND MAILBOXES and 2158 FIND BBOARDS using the older RFC 1176 semantics. 2160 The SUBSCRIBE and UNSUBSCRIBE commands are new in IMAP2bis. A 2161 server that supports FIND ALL.MAILBOXES and FIND ALL.BBOARDS 2162 will also support the SUBSCRIBE and UNSUBSCRIBE commands. 2164 The EXAMINE command is new in IMAP2bis. A BAD response to this 2165 command indicates a server that does not support an explicit 2166 read-only mode of access, and a SELECT command should be used 2167 instead. 2169 Older server implementations may automatically create the 2170 destination mailbox on COPY if that mailbox does not already 2171 exist. This was how a new mailbox was created in older 2172 specifications. If the server does not support the CREATE 2173 command (see above for how to test for this), it will probably 2174 create a mailbox on COPY. 2176 The APPEND command is new in IMAP2bis. A way to see if this 2177 command is implemented is to try to append a zero-length stream 2178 to a mailbox name that is known not to exist (or at least, 2179 highly unlikely to exist) on the remote system. 2181 Although IMAP2bis clients SHOULD avoid asking for the same data 2182 more than once (by having a client-based cache of data returned 2183 by the server), this is not a requirement of the protocol. 2184 However, IMAP2bis clients MUST cache data from the EXISTS and 2185 RECENT unsolicited responses. Only the SELECT command is 2186 guaranteed to return EXISTS/RECENT information. 2188 The BODY, BODY[section], and FULL fetch data items are new in 2189 IMAP2bis. A BAD response to an attempt to fetch either data 2190 item indicates a server that does not support server-based MIME 2191 parsing. 2193 The BODYSTRUCTURE fetch data item is new in IMAP2bis. A BAD 2194 response to an attempt to fetch this data item indicates a 2195 server that does not support extensible results from server- 2196 based MIME parsing. The server may be running an earlier, 2197 experimental version of IMAP2bis and support the older, non- 2198 extensible, BODY fetch data item. A client should attempt this 2199 data item before deciding that the server does not support 2200 MIME. 2202 The use of nested part 0 of a part of type MESSAGE in a BODY or 2203 BODYSTRUCTURE fetch to get only the RFC 822 header of the 2204 message is new, and is not in earlier, experimental versions of 2205 IMAP2bis. A server that returns NIL is probably running the 2206 earlier version; with such servers the only way to obtain the 2207 RFC 822 header is to fetch the entire nested message. 2209 The RFC822.HEADER.LINES and RFC822.HEADER.LINES.NOT fetch data 2210 items are new in IMAP2bis. A BAD response to an attempt to 2211 fetch this data item indicates a server that does not support 2212 selective header fetching. A client should use RFC822.HEADER 2213 and remove the unwanted information. 2215 The UID fetch data item and the UID commands are new in 2216 IMAP2bis. A BAD response to an attempt to use these indicates 2217 a server that does not support unique identifiers. 2219 The PARTIAL command is new in IMAP2bis. If this command causes 2220 a BAD response, then the client should use the appropriate 2221 FETCH command and ignore the unwanted data. 2223 IMAP2bis client implementations must accept all responses and 2224 data formats documented in this specification, including those 2225 labeled as obsolete. This includes the COPY and STORE 2226 unsolicited responses and the old format of dates and times. 2228 Older server implementations may not provide a way to set flags 2229 on APPEND. Client implementations which receive a BAD response 2230 to an APPEND command with flags should retry the command 2231 without flags. 2233 Older server implementations may not preserve flags on COPY. 2234 Some server implementations may not permit the preservation of 2235 certain flags on COPY or their setting with APPEND as site 2236 policy. Older server implementations may attempt to preserve 2237 the internal date on COPY, and may cause a mailbox to be 2238 ordered in other than strictly ascending internal date/time 2239 order. Client implementations should not depend on any of 2240 these behaviors. 2242 Older server implementations may send a TRYCREATE special 2243 information token inside a separate unsolicited OK response 2244 instead of inside the NO response. 2246 IMAP2bis server interoperability with old clients 2248 In general, there should be no interoperation problem between a 2249 server conforming to this specification and a well-written client 2250 that conforms to an earlier specification. Known problems are 2251 noted below: 2253 Clients written to use undocumented private server extensions 2254 that are not in any published specification may work poorly 2255 with server implementations that do not have those extensions. 2257 Poor wording in the description of the CHECK command in earlier 2258 specifications implied that a CHECK command is the way to get 2259 the current number of messages in the mailbox. This is 2260 incorrect. A CHECK command does not necessarily result in an 2261 EXISTS response. Clients must remember the most recent EXISTS 2262 value sent from the server, and should not generate unnecessary 2263 CHECK commands. 2265 An incompatibility exists with COPY in IMAP2bis. COPY in 2266 IMAP2bis servers does not automatically create the destination 2267 mailbox if that mailbox does not already exist. This may cause 2268 problems with old clients that expect automatic mailbox 2269 creation in COPY. 2271 The PREAUTH unsolicited response is new in IMAP2bis. It is 2272 highly unlikely that an old client would ever see this 2273 response. 2275 The COPY unsolicited response is obsolete. Old clients must 2276 not depend on receiving this response. 2278 The STORE unsolicited response is obsolete. Old clients must 2279 not object to receiving a FETCH response instead of this 2280 response. 2282 The format of dates and times has changed. Old clients should 2283 accept a four-digit year instead of a two-digit year, and a 2284 signed four-digit timezone value instead of a timezone name. 2285 In particular, client implementations must not treat a 2286 date/time as a fixed format string and assumed that the time 2287 begins at a particular octet. 2289 Acknowledgements 2291 Bill Yeager and Rich Acuff contributed invaluable suggestions in the 2292 evolution of IMAP2 from the original IMAP. James Rice pointed out 2293 several ambiguities in the previous IMAP2 specification. 2295 My colleagues on the Pine team -- Steve Hubert, Laurence Lundblade, 2296 David Miller, and Mike Seibel -- worked long and hard to create a 2297 fantastic email user agent with worldwide popularity. Without their 2298 efforts, IMAP2 would have languished in obscurity. Terry Gray, our 2299 boss, provided much-needed moral support and guidance, while refusing 2300 to let us get away with "good enough" when "great" was possible. 2302 John G. Myers and Chris Newman carefully examined the formal grammar 2303 and identified numerous mistakes and omissions in the drafts of this 2304 specification. They also provided invaluable input towards the 2305 overall architecture of the present protocol, and endured long 2306 meetings to reach the present protocol. 2308 The present protocol would not have come into existence without the 2309 assistance of the rest of the IETF IMAP2 working group, in particular 2310 Ned Freed and Adam Treister. 2312 Any mistakes, flaws, or sins of omission in this IMAP2bis protocol 2313 specification are, however, strictly my own; and the mention of any 2314 name above does not imply an endorsement. 2316 Security Considerations 2318 Security issues are discussed in this memo only as far as 2319 authentication to access a server are concerned. 2321 Author's Address 2323 Mark R. Crispin 2324 Networks and Distributed Computing, JE-30 2325 University of Washington 2326 Seattle, WA 98195 2328 Phone: (206) 543-5762 2330 EMail: MRC@CAC.Washington.EDU