7Network Working Group M. Crispin
8Request for Comments: 1730 University of Washington
9Category: Standards Track December 1994
12 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4
18 This document specifies an Internet standards track protocol for the
19 Internet community, and requests discussion and suggestions for
20 improvements. Please refer to the current edition of the "Internet
21 Official Protocol Standards" (STD 1) for the standardization state
22 and status of this protocol. Distribution of this memo is unlimited.
27 The Internet Message Access Protocol, Version 4 (IMAP4) allows a
28 client to access and manipulate electronic mail messages on a server.
29 IMAP4 permits manipulation of remote message folders, called
30 "mailboxes", in a way that is functionally equivalent to local
31 mailboxes. IMAP4 also provides the capability for an offline client
32 to resynchronize with the server (see also [IMAP-DISC]).
34 IMAP4 includes operations for creating, deleting, and renaming
35 mailboxes; checking for new messages; permanently removing messages;
36 setting and clearing flags; RFC 822 and MIME parsing; searching; and
37 selective fetching of message attributes, texts, and portions
38 thereof. Messages in IMAP4 are accessed by the use of numbers.
39 These numbers are either message sequence numbers (relative position
40 from 1 to the number of messages in the mailbox) or unique
41 identifiers (immutable, strictly ascending values assigned to each
42 message, but which are not necessarily contiguous).
44 IMAP4 supports a single server. A mechanism for supporting multiple
45 IMAP4 servers is discussed in [IMSP].
47 IMAP4 does not specify a means of posting mail; this function is
48 handled by a mail transfer protocol such as [SMTP].
50 IMAP4 is designed to be upwards compatible from the [IMAP2] protocol.
51 Compatibility issues are discussed in [IMAP-COMPAT].
60RFC 1730 IMAP4 December 1994
70IMAP4 Protocol Specification ...................................... 1
711. Organization of this Document ............................. 1
721.1. How to Read This Document ................................. 1
731.2. Conventions Used in this Document ......................... 1
742. Protocol Overview ......................................... 1
752.1. Link Level ................................................ 1
762.2. Commands and Responses .................................... 1
772.2.1. Client Protocol Sender and Server Protocol Receiver ....... 2
782.2.2. Server Protocol Sender and Client Protocol Receiver ....... 2
793. State and Flow Diagram .................................... 4
803.1. Non-Authenticated State ................................... 4
813.2. Authenticated State ....................................... 4
823.3. Selected State ............................................ 4
833.4. Logout State .............................................. 4
844. Data Formats .............................................. 6
854.1. Atom ...................................................... 6
864.2. Number .................................................... 6
874.3. String .................................................... 6
884.3.1. 8-bit and Binary Strings .................................. 7
894.4. Parenthesized List ........................................ 7
904.5. NIL ....................................................... 7
915. Operational Considerations ................................ 8
925.1. Mailbox Naming ............................................ 8
935.2. Mailbox Size and Message Status Updates ................... 8
945.3. Response when no Command in Progress ...................... 8
955.4. Autologout Timer .......................................... 9
965.5. Multiple Commands in Progress ............................. 9
976. Client Commands ........................................... 10
986.1. Client Commands - Any State ............................... 10
996.1.1. CAPABILITY Command ........................................ 10
1006.1.2. NOOP Command .............................................. 11
1016.1.3. LOGOUT Command ............................................ 11
1026.2. Client Commands - Non-Authenticated State ................. 12
1036.2.1. AUTHENTICATE Command ...................................... 12
1046.2.2. LOGIN Command ............................................. 14
1056.3. Client Commands - Authenticated State ..................... 14
1066.3.1. SELECT Command ............................................ 15
1076.3.2. EXAMINE Command ........................................... 16
1086.3.3. CREATE Command ............................................ 17
1096.3.4. DELETE Command ............................................ 18
1106.3.5. RENAME Command ............................................ 18
116RFC 1730 IMAP4 December 1994
1196.3.6. SUBSCRIBE Command ......................................... 19
1206.3.7. UNSUBSCRIBE Command ....................................... 19
1216.3.8. LIST Command .............................................. 20
1226.3.9. LSUB Command .............................................. 22
1236.3.10. APPEND Command ............................................ 22
1246.4. Client Commands - Selected State .......................... 23
1256.4.1. CHECK Command ............................................. 23
1266.4.2. CLOSE Command ............................................. 24
1276.4.3. EXPUNGE Command ........................................... 25
1286.4.4. SEARCH Command ............................................ 25
1296.4.5. FETCH Command ............................................. 29
1306.4.6. PARTIAL Command ........................................... 32
1316.4.7. STORE Command ............................................. 33
1326.4.8. COPY Command .............................................. 34
1336.4.9. UID Command ............................................... 35
1346.5. Client Commands - Experimental/Expansion .................. 37
1356.5.1. X<atom> Command ........................................... 37
1367. Server Responses .......................................... 38
1377.1. Server Responses - Status Responses ....................... 39
1387.1.1. OK Response ............................................... 40
1397.1.2. NO Response ............................................... 40
1407.1.3. BAD Response .............................................. 41
1417.1.4. PREAUTH Response .......................................... 41
1427.1.5. BYE Response .............................................. 41
1437.2. Server Responses - Server and Mailbox Status .............. 42
1447.2.1. CAPABILITY Response ....................................... 42
1457.2.2. LIST Response ............................................. 43
1467.2.3. LSUB Response ............................................. 44
1477.2.4. SEARCH Response ........................................... 44
1487.2.5. FLAGS Response ............................................ 44
1497.3. Server Responses - Message Status ......................... 45
1507.3.1. EXISTS Response ........................................... 45
1517.3.2. RECENT Response ........................................... 45
1527.3.3. EXPUNGE Response .......................................... 45
1537.3.4. FETCH Response ............................................ 46
1547.3.5. Obsolete Responses ........................................ 51
1557.4. Server Responses - Command Continuation Request ........... 51
1568. Sample IMAP4 session ...................................... 52
1579. Formal Syntax ............................................. 53
15810. Author's Note ............................................. 64
15911. Security Considerations ................................... 64
16012. Author's Address .......................................... 64
161Appendices ........................................................ 65
162A. Obsolete Commands ......................................... 65
163A.6.3.OBS.1. FIND ALL.MAILBOXES Command ........................ 65
164A.6.3.OBS.2. FIND MAILBOXES Command ............................ 65
165A.6.3.OBS.3. SUBSCRIBE MAILBOX Command ......................... 66
166A.6.3.OBS.4. UNSUBSCRIBE MAILBOX Command ....................... 66
172RFC 1730 IMAP4 December 1994
175B. Obsolete Responses ........................................ 68
176B.7.2.OBS.1. MAILBOX Response .................................. 68
177B.7.3.OBS.1. COPY Response ..................................... 68
178B.7.3.OBS.2. STORE Response .................................... 69
179C. References ................................................ 70
180E. IMAP4 Keyword Index ....................................... 71
228RFC 1730 IMAP4 December 1994
231IMAP4 Protocol Specification
2331. Organization of this Document
2351.1. How to Read This Document
237 This document is written from the point of view of the implementor of
238 an IMAP4 client or server. Beyond the protocol overview in section
239 2, it is not optimized for someone trying to understand the operation
240 of the protocol. The material in sections 3 through 5 provides the
241 general context and definitions with which IMAP4 operates.
243 Sections 6, 7, and 9 describe the IMAP commands, responses, and
244 syntax, respectively. The relationships among these are such that it
245 is almost impossible to understand any of them separately. In
246 particular, one should not attempt to deduce command syntax from the
247 command section alone; one should instead refer to the formal syntax
2511.2. Conventions Used in this Document
253 In examples, "C:" and "S:" indicate lines sent by the client and
261 The IMAP4 protocol assumes a reliable data stream such as provided by
262 TCP. When TCP is used, an IMAP4 server listens on port 143.
2652.2. Commands and Responses
267 An IMAP4 session consists of the establishment of a client/server
268 connection, an initial greeting from the server, and client/server
269 interactions. These client/server interactions consist of a client
270 command, server data, and a server completion result response.
272 All interactions transmitted by client and server are in the form of
273 lines; that is, strings that end with a CRLF. The protocol receiver
274 of an IMAP4 client or server is either reading a line, or is reading
275 a sequence of octets with a known count followed by a line.
284RFC 1730 IMAP4 December 1994
2872.2.1. Client Protocol Sender and Server Protocol Receiver
289 The client command begins an operation. Each client command is
290 prefixed with a identifier (typically a short alphanumeric string,
291 e.g. A0001, A0002, etc.) called a "tag". A different tag is
292 generated by the client for each command.
294 There are two cases in which a line from the client does not
295 represent a complete command. In one case, a command argument is
296 quoted with an octet count (see the description of literal in String
297 under Data Formats); in the other case, the command arguments require
298 server feedback (see the AUTHENTICATE command). In either case, the
299 server sends a command continuation request response if it is ready
300 for the octets (if appropriate) and the remainder of the command.
301 This response is prefixed with the token "+".
303 Note: If, instead, the server detected an error in the
304 command, it sends a BAD completion response with tag
305 matching the command (as described below) to reject the
306 command and prevent the client from sending any more of the
309 It is also possible for the server to send a completion
310 response for some other command (if multiple commands are
311 in progress), or untagged data. In either case, the
312 command continuation request is still pending; the client
313 takes the appropriate action for the response, and reads
314 another response from the server.
316 The protocol receiver of an IMAP4 server reads a command line from
317 the client, parses the command and its arguments, and transmits
318 server data and a server command completion result response.
3212.2.2. Server Protocol Sender and Client Protocol Receiver
323 Data transmitted by the server to the client and status responses
324 that do not indicate command completion are prefixed with the token
325 "*", and are called untagged responses.
327 Server data may be sent as a result of a client command, or may be
328 sent unilaterally by the server. There is no syntactic difference
329 between server data that resulted from a specific command and server
330 data that were sent unilaterally.
332 The server completion result response indicates the success or
333 failure of the operation. It is tagged with the same tag as the
334 client command which began the operation. Thus, if more than one
340RFC 1730 IMAP4 December 1994
343 command is in progress, the tag in a server completion response
344 identifies the command to which the response applies. There are
345 three possible server completion responses: OK (indicating success),
346 NO (indicating failure), or BAD (indicating protocol error such as
347 unrecognized command or command syntax error).
349 The protocol receiver of an IMAP4 client reads a response line from
350 the server. It then takes action on the response based upon the
351 first token of the response, which may be a tag, a "*", or a "+". As
354 A client MUST be prepared to accept any server response at all times.
355 This includes server data that it may not have requested. Server
356 data SHOULD be recorded, so that the client can reference its
357 recorded copy rather than sending a command to the server to request
358 the data. In the case of certain server data, recording the data is
361 This topic is discussed in greater detail in the Server Responses
396RFC 1730 IMAP4 December 1994
3993. State and Flow Diagram
401 An IMAP4 server is in one of four states. Most commands are valid in
402 only certain states. It is a protocol error for the client to
403 attempt a command while the command is in an inappropriate state. In
404 this case, a server will respond with a BAD or NO (depending upon
405 server implementation) command completion result.
4083.1. Non-Authenticated State
410 In non-authenticated state, the user must supply authentication
411 credentials before most commands will be permitted. This state is
412 entered when a connection starts unless the connection has been
4163.2. Authenticated State
418 In authenticated state, the user is authenticated and must select a
419 mailbox to access before commands that affect messages will be
420 permitted. This state is entered when a pre-authenticated connection
421 starts, when acceptable authentication credentials have been
422 provided, or after an error in selecting a mailbox.
427 In selected state, a mailbox has been selected to access. This state
428 is entered when a mailbox has been successfully selected.
433 In logout state, the session is being terminated, and the server will
434 close the connection. This state can be entered as a result of a
435 client request or by unilateral server decision.
452RFC 1730 IMAP4 December 1994
455 +--------------------------------------+
456 |initial connection and server greeting|
457 +--------------------------------------+
460 +-----------------+ || ||
461 |non-authenticated| || ||
462 +-----------------+ || ||
465 || +----------------+ ||
466 || | authenticated |<=++ ||
467 || +----------------+ || ||
468 || || (7) || (5) || (6) ||
470 || || +--------+ || ||
471 || || |selected|==++ ||
475 +--------------------------------------+
476 | logout and close connection |
477 +--------------------------------------+
479 (1) connection without pre-authentication (OK greeting)
480 (2) pre-authenticated connection (PREAUTH greeting)
481 (3) rejected connection (BYE greeting)
482 (4) successful LOGIN or AUTHENTICATE command
483 (5) successful SELECT or EXAMINE command
484 (6) CLOSE command, or failed SELECT or EXAMINE command
485 (7) LOGOUT command, server shutdown, or connection closed
508RFC 1730 IMAP4 December 1994
513 IMAP4 uses textual commands and responses. Data in IMAP4 can be in
514 one of several forms: atom, number, string, parenthesized list, or
520 An atom consists of one or more non-special characters.
525 A number consists of one or more digit characters, and represents a
531 A string is in one of two forms: literal and quoted string. The
532 literal form is the general form of string. The quoted string form
533 is an alternative that avoids the overhead of processing a literal at
534 the cost of restrictions of what may be in a quoted string.
536 A literal is a sequence of zero or more octets (including CR and LF),
537 prefix-quoted with an octet count in the form of an open brace ("{"),
538 the number of octets, close brace ("}"), and CRLF. In the case of
539 literals transmitted from server to client, the CRLF is immediately
540 followed by the octet data. In the case of literals transmitted from
541 client to server, the client must wait to receive a command
542 continuation request (described later in this document) before
543 sending the octet data (and the remainder of the command).
545 A quoted string is a sequence of zero or more 7-bit characters,
546 excluding CR and LF, with double quote (<">) characters at each end.
548 The empty string is respresented as either "" (a quoted string with
549 zero characters between double quotes) or as {0} followed by CRLF (a
550 literal with an octet count of 0).
552 Note: Even if the octet count is 0, a client transmitting a
553 literal must wait to receive a command continuation
564RFC 1730 IMAP4 December 1994
5674.3.1. 8-bit and Binary Strings
569 8-bit textual and binary mail is supported through the use of
570 [MIME-1] encoding. IMAP4 implementations MAY transmit 8-bit or
571 multi-octet characters in literals, but should do so only when the
572 character set is identified.
574 Although a BINARY body encoding is defined, unencoded binary strings
575 are not permitted. A "binary string" is any string with NUL
576 characters. Implementations MUST encode binary data into a textual
577 form such as BASE64 before transmitting the data. A string with an
578 excessive amount of CTL characters may also be considered to be
579 binary, although this is not required.
5824.4. Parenthesized List
584 Data structures are represented as a "parenthesized list"; a sequence
585 of data items, delimited by space, and bounded at each end by
586 parentheses. A parenthesized list may itself contain other
587 parenthesized lists, using multiple levels of parentheses to indicate
590 The empty list is represented as () -- a parenthesized list with no
596 The special atom "NIL" represents the non-existence of a particular
597 data item that is represented as a string or parenthesized list, as
598 distinct from the empty string "" or the empty parenthesized list ().
620RFC 1730 IMAP4 December 1994
6235. Operational Considerations
627 The interpretation of mailbox names is implementation-dependent.
628 However, the mailbox name INBOX is a special name reserved to mean
629 "the primary mailbox for this user on this server". If it is desired
630 to export hierarchical mailbox names, mailbox names must be
631 left-to-right hierarchical using a single character to separate
632 levels of hierarchy. The same hierarchy separator character is used
633 for all levels of hierarchy within a single name.
6355.2. Mailbox Size and Message Status Updates
637 At any time, a server can send data that the client did not request.
638 Sometimes, such behavior is required. For example, agents other than
639 the server may add messages to the mailbox (e.g. new mail delivery),
640 change the flags of message in the mailbox (e.g. simultaneous access
641 to the same mailbox by multiple agents), or even remove messages from
642 the mailbox. A server MUST send mailbox size updates automatically
643 if a mailbox size change is observed during the processing of a
644 command. A server SHOULD send message flag updates automatically,
645 without requiring the client to request such updates explicitly.
646 Special rules exist for server notification of a client about the
647 removal of messages to prevent synchronization errors; see the
648 description of the EXPUNGE response for more details.
650 Regardless of what implementation decisions a client may take on
651 remembering data from the server, a client implementation MUST record
652 mailbox size updates. It MUST NOT assume that any command after
653 initial mailbox selection will return the size of the mailbox.
6565.3. Response when no Command in Progress
658 Server implementations are permitted to send an untagged response
659 (except for EXPUNGE) while there is no command in progress. Server
660 implementations that send such responses MUST deal with flow control
661 considerations. Specifically, they must either (1) verify that the
662 size of the data does not exceed the underlying transport's available
663 window size, or (2) use non-blocking writes.
676RFC 1730 IMAP4 December 1994
681 If a server has an inactivity autologout timer, that timer MUST be of
682 at least 30 minutes' duration. The receipt of ANY command from the
683 client during that interval should suffice to reset the autologout
6875.5. Multiple Commands in Progress
689 The client is not required to wait for the completion result response
690 of a command before sending another command, subject to flow control
691 constraints on the underlying data stream. Similarly, a server is
692 not required to process a command to completion before beginning
693 processing of the next command, unless an ambiguity would result
694 because of a command that would affect the results of other commands.
695 If there is such an ambiguity, the server executes commands to
696 completion in the order given by the client.
732RFC 1730 IMAP4 December 1994
737 IMAP4 commands are described in this section. Commands are organized
738 by the state in which the command is permitted. Commands which are
739 permitted in multiple states are listed in the minimum permitted
740 state (for example, commands valid in authenticated and selected
741 state are listed in the authenticated state commands).
743 Command arguments, identified by "Arguments:" in the command
744 descriptions below, are described by function, not by syntax. The
745 precise syntax of command arguments is described in the Formal Syntax
748 Some commands cause specific server data to be returned; these are
749 identified by "Data:" in the command descriptions below. See the
750 response descriptions in the Responses section for information on
751 these responses, and the Formal Syntax section for the precise syntax
752 of these responses. It is possible for server data to be transmitted
753 as a result of any command; thus, commands that do not specifically
754 require server data specify "no specific data for this command"
757 The "Result:" in the command description refers to the possible
758 tagged status responses to a command, and any special interpretation
759 of these status responses.
7626.1. Client Commands - Any State
764 The following commands are valid in any state: CAPABILITY, NOOP, and
7676.1.1. CAPABILITY Command
771 Data: mandatory untagged response: CAPABILITY
773 Result: OK - capability completed
774 BAD - command unknown or arguments invalid
776 The CAPABILITY command requests a listing of capabilities that the
777 server supports. The server MUST send a single untagged
778 CAPABILITY response with "IMAP4" as the first listed capability
779 before the (tagged) OK response. This listing of capabilities is
780 not dependent upon connection state or user. It is therefore not
781 necessary to issue a CAPABILITY command more than once in a
788RFC 1730 IMAP4 December 1994
791 Capability names other than "IMAP4" refer to extensions,
792 revisions, or amendments to this specification. See the
793 documentation of the CAPABILITY response for additional
794 information. No capabilities are enabled without explicit client
795 action to invoke the capability. See the section entitled "Client
796 Commands - Experimental/Expansion" for information about the form
797 of site or implementation-specific capabilities.
799 Example: C: abcd CAPABILITY
800 S: * CAPABILITY IMAP4
801 S: abcd OK CAPABILITY completed
808 Data: no specific data for this command (but see below)
810 Result: OK - noop completed
811 BAD - command unknown or arguments invalid
813 The NOOP command always succeeds. It does nothing.
815 Since any command can return a status update as untagged data, the
816 NOOP command can be used as a periodic poll for new messages or
817 message status updates during a period of inactivity. The NOOP
818 command can also be used to reset any inactivity autologout timer
821 Example: C: a002 NOOP
822 S: a002 OK NOOP completed
828 S: * 14 FETCH (FLAGS (\Seen \Deleted))
829 S: a047 OK NOOP completed
844RFC 1730 IMAP4 December 1994
851 Data: mandatory untagged response: BYE
853 Result: OK - logout completed
854 BAD - command unknown or arguments invalid
856 The LOGOUT command informs the server that the client is done with
857 the session. The server must send a BYE untagged response before
858 the (tagged) OK response, and then close the network connection.
860 Example: C: A023 LOGOUT
861 S: * BYE IMAP4 Server logging out
862 S: A023 OK LOGOUT completed
863 (Server and client then close the connection)
8676.2. Client Commands - Non-Authenticated State
869 In non-authenticated state, the AUTHENTICATE or LOGIN command
870 establishes authentication and enter authenticated state. The
871 AUTHENTICATE command provides a general mechanism for a variety of
872 authentication techniques, whereas the LOGIN command uses the
873 traditional user name and plaintext password pair.
875 Server implementations may allow non-authenticated access to certain
876 mailboxes. The convention is to use a LOGIN command with the userid
877 "anonymous". A password is required. It is implementation-dependent
878 what requirements, if any, are placed on the password and what access
879 restrictions are placed on anonymous users.
881 Once authenticated (including as anonymous), it is not possible to
882 re-enter non-authenticated state.
884 In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
885 the following commands are valid in non-authenticated state:
886 AUTHENTICATE and LOGIN.
900RFC 1730 IMAP4 December 1994
9036.2.1. AUTHENTICATE Command
905 Arguments: authentication mechanism name
907 Data: continuation data may be requested
909 Result: OK - authenticate completed, now in authenticated state
910 NO - authenticate failure: unsupported authentication
911 mechanism, credentials rejected
912 BAD - command unknown or arguments invalid,
913 authentication exchange cancelled
915 The AUTHENTICATE command indicates an authentication mechanism,
916 such as described in [IMAP-AUTH], to the server. If the server
917 supports the requested authentication mechanism, it performs an
918 authentication protocol exchange to authenticate and identify the
919 user. Optionally, it also negotiates a protection mechanism for
920 subsequent protocol interactions. If the requested authentication
921 mechanism is not supported, the server should reject the
922 AUTHENTICATE command by sending a tagged NO response.
924 The authentication protocol exchange consists of a series of
925 server challenges and client answers that are specific to the
926 authentication mechanism. A server challenge consists of a
927 command continuation request response with the "+" token followed
928 by a BASE64 encoded string. The client answer consists of a line
929 consisting of a BASE64 encoded string. If the client wishes to
930 cancel an authentication exchange, it should issue a line with a
931 single "*". If the server receives such an answer, it must reject
932 the AUTHENTICATE command by sending a tagged BAD response.
934 A protection mechanism provides integrity and privacy protection
935 to the protocol session. If a protection mechanism is negotiated,
936 it is applied to all subsequent data sent over the connection.
937 The protection mechanism takes effect immediately following the
938 CRLF that concludes the authentication exchange for the client,
939 and the CRLF of the tagged OK response for the server. Once the
940 protection mechanism is in effect, the stream of command and
941 response octets is processed into buffers of ciphertext. Each
942 buffer is transferred over the connection as a stream of octets
943 prepended with a four octet field in network byte order that
944 represents the length of the following data. The maximum
945 ciphertext buffer length is defined by the protection mechanism.
947 The server is not required to support any particular
948 authentication mechanism, nor are authentication mechanisms
949 required to support any protection mechanisms. If an AUTHENTICATE
950 command fails with a NO response, the client may try another
956RFC 1730 IMAP4 December 1994
959 authentication mechanism by issuing another AUTHENTICATE command,
960 or may attempt to authenticate by using the LOGIN command. In
961 other words, the client may request authentication types in
962 decreasing order of preference, with the LOGIN command as a last
965 Example: S: * OK KerberosV4 IMAP4 Server
966 C: A001 AUTHENTICATE KERBEROS_V4
968 C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
969 +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
970 WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
972 C: DiAF5A4gA+oOIALuBkAAmw==
973 S: A001 OK Kerberos V4 authentication successful
975 Note: the line breaks in the first client answer are for
976 editorial clarity and are not in real authenticators.
984 Data: no specific data for this command
986 Result: OK - login completed, now in authenticated state
987 NO - login failure: user name or password rejected
988 BAD - command unknown or arguments invalid
990 The LOGIN command identifies the user to the server and carries
991 the plaintext password authenticating this user.
993 Example: C: a001 LOGIN SMITH SESAME
994 S: a001 OK LOGIN completed
9986.3. Client Commands - Authenticated State
1000 In authenticated state, commands that manipulate mailboxes as atomic
1001 entities are permitted. Of these commands, the SELECT and EXAMINE
1002 commands will select a mailbox for access and enter selected state.
1012RFC 1730 IMAP4 December 1994
1015 In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
1016 the following commands are valid in authenticated state: SELECT,
1017 EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB,
10206.3.1. SELECT Command
1022 Arguments: mailbox name
1024 Data: mandatory untagged responses: FLAGS, EXISTS, RECENT
1025 optional OK untagged responses: UNSEEN, PERMANENTFLAGS
1027 Result: OK - select completed, now in selected state
1028 NO - select failure, now in authenticated state: no
1029 such mailbox, can't access mailbox
1030 BAD - command unknown or arguments invalid
1032 The SELECT command selects a mailbox so that messages in the
1033 mailbox can be accessed. Before returning an OK to the client,
1034 the server MUST send the following untagged data to the client:
1036 FLAGS Defined flags in the mailbox
1038 <n> EXISTS The number of messages in the mailbox
1040 <n> RECENT The number of messages added to the mailbox since
1041 the previous time this mailbox was read
1043 OK [UIDVALIDITY <n>]
1044 The unique identifier validity value. See the
1045 description of the UID command for more detail.
1047 to define the initial state of the mailbox at the client. If it
1048 is not possible to determine the messages that were added since
1049 the previous time a mailbox was read, then all messages SHOULD be
1052 The server SHOULD also send an UNSEEN response code in an OK
1053 untagged response, indicating the message sequence number of the
1054 first unseen message in the mailbox.
1056 If the client can not change the permanent state of one or more of
1057 the flags listed in the FLAGS untagged response, the server SHOULD
1058 send a PERMANENTFLAGS response code in an OK untagged response,
1059 listing the flags that the client may change permanently.
1061 Only one mailbox may be selected at a time in a session;
1062 simultaneous access to multiple mailboxes requires multiple
1068RFC 1730 IMAP4 December 1994
1071 sessions. The SELECT command automatically deselects any
1072 currently selected mailbox before attempting the new selection.
1073 Consequently, if a mailbox is selected and a SELECT command that
1074 fails is attempted, no mailbox is selected.
1076 If the user is permitted to modify the mailbox, the server SHOULD
1077 prefix the text of the tagged OK response with the "[READ-WRITE]"
1080 If the user is not permitted to modify the mailbox but is
1081 permitted read access, the mailbox is selected as read-only, and
1082 the server MUST prefix the text of the tagged OK response to
1083 SELECT with the "[READ-ONLY]" response code. Read-only access
1084 through SELECT differs from the EXAMINE command in that certain
1085 read-only mailboxes may permit the change of permanent state on a
1086 per-user (as opposed to global) basis. Netnews messages marked in
1087 a user's .newsrc file are an example of such per-user permanent
1088 state that can be modified with read-only mailboxes.
1090 Example: C: A142 SELECT INBOX
1093 S: * OK [UNSEEN 12] Message 12 is first unseen
1094 S: * OK [UIDVALIDITY 3857529045] UIDs valid
1095 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
1096 S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
1097 S: A142 OK [READ-WRITE] SELECT completed
11006.3.2. EXAMINE Command
1102 Arguments: mailbox name
1104 Data: mandatory untagged responses: FLAGS, EXISTS, RECENT
1105 optional OK untagged responses: UNSEEN, PERMANENTFLAGS
1107 Result: OK - examine completed, now in selected state
1108 NO - examine failure, now in authenticated state: no
1109 such mailbox, can't access mailbox
1110 BAD - command unknown or arguments invalid
1112 The EXAMINE command is identical to SELECT and returns the same
1113 output; however, the selected mailbox is identified as read-only.
1114 No changes to the permanent state of the mailbox, including
1115 per-user state, are permitted.
1124RFC 1730 IMAP4 December 1994
1127 The text of the tagged OK response to the EXAMINE command MUST
1128 begin with the "[READ-ONLY]" response code.
1130 Example: C: A932 EXAMINE blurdybloop
1133 S: * OK [UNSEEN 8] Message 8 is first unseen
1134 S: * OK [UIDVALIDITY 3857529045] UIDs valid
1135 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
1136 S: * OK [PERMANENTFLAGS ()] No permanent flags permitted
1137 S: A932 OK [READ-ONLY] EXAMINE completed
11406.3.3. CREATE Command
1142 Arguments: mailbox name
1144 Data: no specific data for this command
1146 Result: OK - create completed
1147 NO - create failure: can't create mailbox with that name
1148 BAD - command unknown or arguments invalid
1150 The CREATE command creates a mailbox with the given name. An OK
1151 response is returned only if a new mailbox with that name has been
1152 created. It is an error to attempt to create INBOX or a mailbox
1153 with a name that refers to an extant mailbox. Any error in
1154 creation will return a tagged NO response.
1156 If the mailbox name is suffixed with the server's hierarchy
1157 separator character (as returned from the server by a LIST
1158 command), this is a declaration that the client may, in the
1159 future, create mailbox names under this name in the hierarchy.
1160 Server implementations that do not require this declaration MUST
1163 If a new mailbox is created with the same name as a mailbox which
1164 was deleted, its unique identifiers MUST be greater than any
1165 unique identifiers used in the previous incarnation of the mailbox
1166 UNLESS the new incarnation has a different unique identifier
1167 validity value. See the description of the UID command for more
1170 Example: C: A003 CREATE owatagusiam/
1171 S: A003 OK CREATE completed
1172 C: A004 CREATE owatagusiam/blurdybloop
1173 S: A004 OK CREATE completed
1180RFC 1730 IMAP4 December 1994
1183 Note: the interpretation of this example depends on whether
1184 "/" was returned as the hierarchy separator from LIST. If
1185 "/" is the hierarchy separator, a new level of hierarchy
1186 named "owatagusiam" with a member called "blurdybloop" is
1187 created. Otherwise, two mailboxes at the same hierarchy
11916.3.4. DELETE Command
1193 Arguments: mailbox name
1195 Data: no specific data for this command
1197 Result: OK - delete completed
1198 NO - delete failure: can't delete mailbox with that name
1199 BAD - command unknown or arguments invalid
1201 The DELETE command permanently removes the mailbox with the given
1202 name. A tagged OK response is returned only if the mailbox has
1203 been deleted. It is an error to attempt to delete INBOX or a
1204 mailbox name that does not exist. Any error in deletion will
1205 return a tagged NO response.
1207 The value of the highest-used unique indentifier of the deleted
1208 mailbox MUST be preserved so that a new mailbox created with the
1209 same name will not reuse the identifiers of the former
1210 incarnation, UNLESS the new incarnation has a different unique
1211 identifier validity value. See the description of the UID command
1214 Example: C: A683 DELETE blurdybloop
1215 S: A683 OK DELETE completed
12186.3.5. RENAME Command
1220 Arguments: existing mailbox name
1223 Data: no specific data for this command
1225 Result: OK - rename completed
1226 NO - rename failure: can't rename mailbox with that name,
1227 can't rename to mailbox with that name
1228 BAD - command unknown or arguments invalid
1236RFC 1730 IMAP4 December 1994
1239 The RENAME command changes the name of a mailbox. A tagged OK
1240 response is returned only if the mailbox has been renamed. It is
1241 an error to attempt to rename from a mailbox name that does not
1242 exist or to a mailbox name that already exists. Any error in
1243 renaming will return a tagged NO response.
1245 Renaming INBOX is permitted; a new, empty INBOX is created in its
1248 Example: C: Z4S9 RENAME blurdybloop owatagusiam
1249 S: Z4S9 OK RENAME completed
12526.3.6. SUBSCRIBE Command
1256 Data: no specific data for this command
1258 Result: OK - subscribe completed
1259 NO - subscribe failure: can't subscribe to that name
1260 BAD - command unknown or arguments invalid
1262 The SUBSCRIBE command adds the specified mailbox name to the
1263 server's set of "active" or "subscribed" mailboxes as returned by
1264 the LSUB command. This command returns a tagged OK response only
1265 if the subscription is successful.
1267 Example: C: A002 SUBSCRIBE #news.comp.mail.mime
1268 S: A002 OK SUBSCRIBE completed
12716.3.7. UNSUBSCRIBE Command
1273 Arguments: mailbox name
1275 Data: no specific data for this command
1277 Result: OK - unsubscribe completed
1278 NO - unsubscribe failure: can't unsubscribe that name
1279 BAD - command unknown or arguments invalid
1281 The UNSUBSCRIBE command removes the specified mailbox name from
1282 the server's set of "active" or "subscribed" mailboxes as returned
1283 by the LSUB command. This command returns a tagged OK response
1284 only if the unsubscription is successful.
1292RFC 1730 IMAP4 December 1994
1295 Example: C: A002 UNSUBSCRIBE #news.comp.mail.mime
1296 S: A002 OK UNSUBSCRIBE completed
1301 Arguments: reference name
1302 mailbox name with possible wildcards
1304 Data: untagged responses: LIST
1306 Result: OK - list completed
1307 NO - list failure: can't list that reference or name
1308 BAD - command unknown or arguments invalid
1310 The LIST command returns a subset of names from the complete set
1311 of all names available to the user. Zero or more untagged LIST
1312 replies are returned, containing the name attributes, hierarchy
1313 delimiter, and name; see the description of the LIST reply for
1316 An empty ("" string) reference name argument indicates that the
1317 mailbox name is interpreted as by SELECT. The returned mailbox
1318 names MUST match the supplied mailbox name pattern. A non-empty
1319 reference name argument is the name of a mailbox or a level of
1320 mailbox hierarchy, and indicates a context in which the mailbox
1321 name is interpreted in an implementation-defined manner.
1323 The reference and mailbox name arguments are interpreted, in an
1324 implementation-dependent fashion, into a canonical form that
1325 represents an unambiguous left-to-right hierarchy. The returned
1326 mailbox names will be in the interpreted form.
1328 Any part of the reference argument that is included in the
1329 interpreted form SHOULD prefix the interpreted form. It should
1330 also be in the same form as the reference name argument. This
1331 rule permits the client to determine if the returned mailbox name
1332 is in the context of the reference argument, or if something about
1333 the mailbox argument overrode the reference argument. Without
1334 this rule, the client would have to have knowledge of the server's
1335 naming semantics including what characters are "breakouts" that
1336 override a naming context.
1348RFC 1730 IMAP4 December 1994
1351 For example, here are some examples of how references
1352 and mailbox names might be interpreted on a UNIX-based
1355 Reference Mailbox Name Interpretation
1356 ------------ ------------ --------------
1357 ~smith/Mail/ foo.* ~smith/Mail/foo.*
1358 archive/ % archive/%
1359 #news. comp.mail.* #news.comp.mail.*
1360 ~smith/Mail/ /usr/doc/foo /usr/doc/foo
1361 archive/ ~fred/Mail/* ~fred/Mail/*
1363 The first three examples demonstrate interpretations in
1364 the context of the reference argument. Note that
1365 "~smith/Mail" should not be transformed into something
1366 like "/u2/users/smith/Mail", or it would be impossible
1367 for the client to determine that the interpretation was
1368 in the context of the reference.
1370 The character "*" is a wildcard, and matches zero or more
1371 characters at this position. The character "%" is similar to "*",
1372 but it does not match a hierarchy delimiter. If the "%" wildcard
1373 is the last character of a mailbox name argument, matching levels
1374 of hierarchy are also returned. If these levels of hierarchy are
1375 not also selectable mailboxes, they are returned with the
1376 \Noselect mailbox name attribute (see the description of the LIST
1377 response for more detail).
1379 Server implementations are permitted to "hide" otherwise
1380 accessible mailboxes from the wildcard characters, by preventing
1381 certain characters or names from matching a wildcard in certain
1382 situations. For example, a UNIX-based server might restrict the
1383 interpretation of "*" so that an initial "/" character does not
1386 The special name INBOX is included in the output from LIST if it
1387 matches the input arguments and INBOX is supported by this server
1388 for this user. The criteria for omitting INBOX is whether SELECT
1389 INBOX will return failure; it is not relevant whether the user's
1390 real INBOX resides on this or some other server.
1392 Example: C: A002 LIST "~/Mail/" "%"
1393 S: * LIST (\Noselect) "/" ~/Mail/foo
1394 S: * LIST () "/" ~/Mail/meetings
1395 S: A002 OK LIST completed
1404RFC 1730 IMAP4 December 1994
1409 Arguments: reference name
1410 mailbox name with possible wildcards
1412 Data: untagged responses: LSUB
1414 Result: OK - lsub completed
1415 NO - lsub failure: can't list that reference or name
1416 BAD - command unknown or arguments invalid
1418 The LSUB command returns a subset of names from the set of names
1419 that the user has declared as being "active" or "subscribed".
1420 Zero or more untagged LSUB replies are returned. The arguments to
1421 LSUB are in the same form as those for LIST.
1423 Example: C: A002 LSUB "#news." "comp.mail.*"
1424 S: * LSUB () "." #news.comp.mail.mime
1425 S: * LSUB () "." #news.comp.mail.misc
1426 S: A002 OK LSUB completed
14296.3.10. APPEND Command
1431 Arguments: mailbox name
1432 optional flag parenthesized list
1433 optional date/time string
1436 Data: no specific data for this command
1438 Result: OK - append completed
1439 NO - append error: can't append to that mailbox, error
1440 in flags or date/time or message text
1441 BAD - command unknown or arguments invalid
1443 The APPEND command appends the literal argument as a new message
1444 in the specified destination mailbox. This argument is in the
1445 format of an [RFC-822] message. 8-bit characters are permitted in
1446 the message. A server implementation that is unable to preserve
1447 8-bit data properly MUST be able to reversibly convert 8-bit
1448 APPEND data to 7-bit using [MIME-1] encoding.
1450 If a flag parenthesized list or date_time are specified, that data
1451 SHOULD be set in the resulting message; otherwise, the defaults of
1452 empty flags and the current date/time are used.
1460RFC 1730 IMAP4 December 1994
1463 If the append is unsuccessful for any reason, the mailbox MUST be
1464 restored to its state before the APPEND attempt; no partial
1465 appending is permitted. If the mailbox is currently selected, the
1466 normal new mail actions should occur.
1468 If the destination mailbox does not exist, a server MUST return an
1469 error, and MUST NOT automatically create the mailbox. Unless it
1470 is certain that the destination mailbox can not be created, the
1471 server MUST send the response code "[TRYCREATE]" as the prefix of
1472 the text of the tagged NO response. This gives a hint to the
1473 client that it can attempt a CREATE command and retry the APPEND
1474 if the CREATE is successful.
1476 Example: C: A003 APPEND saved-messages (\Seen) {310}
1477 C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
1478 C: From: Fred Foobar <foobar@Blurdybloop.COM>
1479 C: Subject: afternoon meeting
1480 C: To: mooch@owatagu.siam.edu
1481 C: Message-Id: <B27397-0100000@Blurdybloop.COM>
1482 C: MIME-Version: 1.0
1483 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
1485 C: Hello Joe, do you think we can meet at 3:30 tomorrow?
1487 S: A003 OK APPEND completed
1489 Note: the APPEND command is not used for message delivery,
1490 because it does not provide a mechanism to transfer [SMTP]
1491 envelope information.
14956.4. Client Commands - Selected State
1497 In selected state, commands that manipulate messages in a mailbox are
1500 In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
1501 and the authenticated state commands (SELECT, EXAMINE, CREATE,
1502 DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, FIND
1503 ALL.MAILBOXES, FIND MAILBOXES, and APPEND), the following commands
1504 are valid in the selected state: CHECK, CLOSE, EXPUNGE, SEARCH,
1505 FETCH, PARTIAL, STORE, COPY, and UID.
1516RFC 1730 IMAP4 December 1994
1523 Data: no specific data for this command
1525 Result: OK - check completed
1526 BAD - command unknown or arguments invalid
1528 The CHECK command requests a checkpoint of the currently selected
1529 mailbox. A checkpoint refers to any implementation-dependent
1530 housekeeping associated with the mailbox (e.g. resolving the
1531 server's in-memory state of the mailbox with the state on its
1532 disk) that is not normally executed as part of each command. A
1533 checkpoint may take a non-instantaneous amount of real time to
1534 complete. If a server implementation has no such housekeeping
1535 considerations, CHECK is equivalent to NOOP.
1537 There is no guarantee that an EXISTS untagged response will happen
1538 as a result of CHECK. NOOP, not CHECK, should be used for new
1541 Example: C: FXXZ CHECK
1542 S: FXXZ OK CHECK Completed
1549 Data: no specific data for this command
1551 Result: OK - close completed, now in authenticated state
1552 NO - close failure: no mailbox selected
1553 BAD - command unknown or arguments invalid
1555 The CLOSE command permanently removes from the currently selected
1556 mailbox all messages that have the \Deleted flag set, and returns
1557 to authenticated state from selected state. No untagged EXPUNGE
1560 No messages are removed, and no error is given, if the mailbox is
1561 selected by an EXAMINE command or is otherwise selected read-only.
1563 Even when a mailbox is selected, it is not required to send a
1564 CLOSE command before a SELECT, EXAMINE, or LOGOUT command. The
1565 SELECT, EXAMINE, and LOGOUT commands implicitly close the
1566 currently selected mailbox without doing an expunge. However,
1572RFC 1730 IMAP4 December 1994
1575 when many messages are deleted, a CLOSE-LOGOUT or CLOSE-SELECT
1576 sequence is considerably faster than an EXPUNGE-LOGOUT or
1577 EXPUNGE-SELECT because no untagged EXPUNGE responses (which the
1578 client would probably ignore) are sent.
1580 Example: C: A341 CLOSE
1581 S: A341 OK CLOSE completed
15846.4.3. EXPUNGE Command
1588 Data: untagged responses: EXPUNGE
1590 Result: OK - expunge completed
1591 NO - expunge failure: can't expunge (e.g. permission
1593 BAD - command unknown or arguments invalid
1595 The EXPUNGE command permanently removes from the currently
1596 selected mailbox all messages that have the \Deleted flag set.
1597 Before returning an OK to the client, an untagged EXPUNGE response
1598 is sent for each message that is removed.
1600 Example: C: A202 EXPUNGE
1605 S: A202 OK EXPUNGE completed
1607 Note: in this example, messages 3, 4, 7, and 11 had the
1608 \Deleted flag set. See the description of the EXPUNGE
1609 response for further explanation.
1628RFC 1730 IMAP4 December 1994
16316.4.4. SEARCH Command
1633 Arguments: optional character set specification
1634 searching criteria (one or more)
1636 Data: mandatory untagged response: SEARCH
1638 Result: OK - search completed
1639 NO - search error: can't search that character set or
1641 BAD - command unknown or arguments invalid
1643 The SEARCH command searches the mailbox for messages that match
1644 the given searching criteria. Searching criteria consist of one
1645 or more search keys. The untagged SEARCH response from the server
1646 contains a listing of message sequence numbers corresponding to
1647 those messages that match the searching criteria.
1649 When multiple keys are specified, the result is the intersection
1650 (AND function) of all the messages that match those keys. For
1651 example, the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers
1652 to all deleted messages from Smith that were placed in the mailbox
1653 since February 1, 1994. A search key may also be a parenthesized
1654 list of one or more search keys (e.g. for use with the OR and NOT
1657 Server implementations MAY exclude [MIME-1] body parts with
1658 terminal content types other than TEXT and MESSAGE from
1659 consideration in SEARCH matching.
1661 The optional character set specification consists of the word
1662 "CHARSET" followed by a registered MIME character set. It
1663 indicates the character set of the strings that appear in the
1664 search criteria. [MIME-2] strings that appear in RFC 822/MIME
1665 message headers, and [MIME-1] content transfer encodings, MUST be
1666 decoded before matching. Except for US-ASCII, it is not required
1667 that any particular character set be supported. If the server
1668 does not support the specified character set, it MUST return a
1669 tagged NO response (not a BAD).
1671 In all search keys that use strings, a message matches the key if
1672 the string is a substring of the field. The matching is
1684RFC 1730 IMAP4 December 1994
1687 The defined search keys are as follows. Refer to the Formal
1688 Syntax section for the precise syntactic definitions of the
1691 <message set> Messages with message sequence numbers
1692 corresponding to the specified message sequence
1695 ALL All messages in the mailbox; the default initial
1698 ANSWERED Messages with the \Answered flag set.
1700 BCC <string> Messages that contain the specified string in the
1701 envelope structure's BCC field.
1703 BEFORE <date> Messages whose internal date is earlier than the
1706 BODY <string> Messages that contain the specified string in the
1707 body of the message.
1709 CC <string> Messages that contain the specified string in the
1710 envelope structure's CC field.
1712 DELETED Messages with the \Deleted flag set.
1714 DRAFT Messages with the \Draft flag set.
1716 FLAGGED Messages with the \Flagged flag set.
1718 FROM <string> Messages that contain the specified string in the
1719 envelope structure's FROM field.
1721 HEADER <field-name> <string>
1722 Messages that have a header with the specified
1723 field-name (as defined in [RFC-822]) and that
1724 contains the specified string in the [RFC-822]
1727 KEYWORD <flag> Messages with the specified keyword set.
1729 LARGER <n> Messages with an RFC822.SIZE larger than the
1730 specified number of octets.
1732 NEW Messages that have the \Recent flag set but not the
1733 \Seen flag. This is functionally equivalent to
1740RFC 1730 IMAP4 December 1994
1744 Messages that do not match the specified search
1747 OLD Messages that do not have the \Recent flag set.
1748 This is functionally equivalent to "NOT RECENT" (as
1749 opposed to "NOT NEW").
1751 ON <date> Messages whose internal date is within the
1754 OR <search-key1> <search-key2>
1755 Messages that match either search key.
1757 RECENT Messages that have the \Recent flag set.
1759 SEEN Messages that have the \Seen flag set.
1762 Messages whose [RFC-822] Date: header is earlier
1763 than the specified date.
1765 SENTON <date> Messages whose [RFC-822] Date: header is within the
1769 Messages whose [RFC-822] Date: header is within or
1770 later than the specified date.
1772 SINCE <date> Messages whose internal date is within or later
1773 than the specified date.
1775 SMALLER <n> Messages with an RFC822.SIZE smaller than the
1776 specified number of octets.
1779 Messages that contain the specified string in the
1780 envelope structure's SUBJECT field.
1782 TEXT <string> Messages that contain the specified string in the
1783 header or body of the message.
1785 TO <string> Messages that contain the specified string in the
1786 envelope structure's TO field.
1789 Messages with unique identifiers corresponding to
1790 the specified unique identifier set.
1796RFC 1730 IMAP4 December 1994
1799 UNANSWERED Messages that do not have the \Answered flag set.
1801 UNDELETED Messages that do not have the \Deleted flag set.
1803 UNDRAFT Messages that do not have the \Draft flag set.
1805 UNFLAGGED Messages that do not have the \Flagged flag set.
1808 Messages that do not have the specified keyword
1811 UNSEEN Messages that do not have the \Seen flag set.
1814 Example: C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith"
1815 S: * SEARCH 2 84 882
1816 S: A282 OK SEARCH completed
1821 Arguments: message set
1822 message data item names
1824 Data: untagged responses: FETCH
1826 Result: OK - fetch completed
1827 NO - fetch error: can't fetch that data
1828 BAD - command unknown or arguments invalid
1830 The FETCH command retrieves data associated with a message in the
1831 mailbox. The data items to be fetched may be either a single atom
1832 or a parenthesized list. The currently defined data items that
1835 ALL Macro equivalent to: (FLAGS INTERNALDATE
1836 RFC822.SIZE ENVELOPE)
1838 BODY Non-extensible form of BODYSTRUCTURE.
1841 The text of a particular body section. The section
1842 specification is a set of one or more part numbers
1843 delimited by periods.
1845 Single-part messages only have a part 1.
1852RFC 1730 IMAP4 December 1994
1855 Multipart messages are assigned consecutive part
1856 numbers, as they occur in the message. If a
1857 particular part is of type message or multipart,
1858 its parts must be indicated by a period followed by
1859 the part number within that nested multipart part.
1860 It is not permitted to fetch a multipart part
1861 itself, only its individual members.
1863 A part of type MESSAGE and subtype RFC822 also has
1864 nested parts. These are the parts of the MESSAGE
1865 part's body. Nested part 0 of a part of type
1866 MESSAGE and subtype RFC822 is the [RFC-822] header
1869 Every message has at least one part.
1871 Here is an example of a complex message
1872 with its associated section
1875 0 ([RFC-822] header of the message)
1878 2 APPLICATION/OCTET-STREAM
1880 3.0 ([RFC-822] header of the message)
1882 3.2 APPLICATION/OCTET-STREAM
1886 4.2.0 ([RFC-822] header of the message)
1888 MULTIPART/ALTERNATIVE
1890 4.2.2.2 TEXT/RICHTEXT
1892 Note that there is no section
1893 specification for the Multi-part parts
1894 (no section 4 or 4.2.2).
1896 The \Seen flag is implicitly set; if this causes
1897 the flags to change they should be included as part
1898 of the fetch responses.
1900 BODY.PEEK[<section>]
1901 An alternate form of BODY[section] that does not
1902 implicitly set the \Seen flag.
1908RFC 1730 IMAP4 December 1994
1911 BODYSTRUCTURE The [MIME-1] body structure of the message. This
1912 is computed by the server by parsing the [MIME-1]
1915 ENVELOPE The envelope structure of the message. This is
1916 computed by the server by parsing the [RFC-822]
1917 header into the component parts, defaulting various
1918 fields as necessary.
1920 FAST Macro equivalent to: (FLAGS INTERNALDATE
1923 FLAGS The flags that are set for this message.
1925 FULL Macro equivalent to: (FLAGS INTERNALDATE
1926 RFC822.SIZE ENVELOPE BODY)
1928 INTERNALDATE The date and time of final delivery of the message
1929 as defined by RFC 821.
1931 RFC822 The message in [RFC-822] format. The \Seen flag is
1932 implicitly set; if this causes the flags to change
1933 they should be included as part of the fetch
1934 responses. This is the concatenation of
1935 RFC822.HEADER and RFC822.TEXT.
1937 RFC822.PEEK An alternate form of RFC822 that does not
1938 implicitly set the \Seen flag.
1940 RFC822.HEADER The [RFC-822] format header of the message as
1941 stored on the server including the delimiting blank
1942 line between the header and the body.
1944 RFC822.HEADER.LINES <header_list>
1945 All header lines (including continuation lines) of
1946 the [RFC-822] format header of the message with a
1947 field-name (as defined in [RFC-822]) that matches
1948 any of the strings in header_list. The matching is
1949 case-insensitive but otherwise exact. The
1950 delimiting blank line between the header and the
1951 body is always included.
1964RFC 1730 IMAP4 December 1994
1967 RFC822.HEADER.LINES.NOT <header_list>
1968 All header lines (including continuation lines) of
1969 the [RFC-822] format header of the message with a
1970 field-name (as defined in [RFC-822]) that does not
1971 match any of the strings in header_list. The
1972 matching is case-insensitive but otherwise exact.
1973 The delimiting blank line between the header and
1974 the body is always included.
1976 RFC822.SIZE The number of octets in the message, as expressed
1977 in [RFC-822] format.
1979 RFC822.TEXT The text body of the message, omitting the
1980 [RFC-822] header. The \Seen flag is implicitly
1981 set; if this causes the flags to change they should
1982 be included as part of the fetch responses.
1985 An alternate form of RFC822.TEXT that does not
1986 implicitly set the \Seen flag.
1988 UID The unique identifier for the message.
1991 Example: C: A654 FETCH 2:4 (FLAGS RFC822.HEADER.LINES (DATE FROM))
1995 S: A003 OK FETCH completed
19986.4.6. PARTIAL Command
2000 Arguments: message sequence number
2001 message data item name
2002 position of first octet
2005 Data: untagged responses: FETCH
2007 Result: OK - partial completed
2008 NO - partial error: can't fetch that data
2009 BAD - command unknown or arguments invalid
2011 The PARTIAL command is equivalent to the associated FETCH command,
2012 with the added functionality that only the specified number of
2013 octets, beginning at the specified starting octet, are returned.
2014 Only a single message can be fetched at a time. The first octet
2020RFC 1730 IMAP4 December 1994
2023 of a message, and hence the minimum for the starting octet, is
2026 The following FETCH items are valid data for PARTIAL: RFC822,
2027 RFC822.HEADER, RFC822.TEXT, BODY[section], as well as any .PEEK
2030 Any partial fetch that attempts to read beyond the end of the text
2031 is truncated as appropriate. If the starting octet is beyond the
2032 end of the text, an empty string is returned.
2034 The data are returned with the FETCH response. There is no
2035 indication of the range of the partial data in this response. It
2036 is not possible to stream multiple PARTIAL commands of the same
2037 data item without processing and synchronizing at each step, since
2038 streamed commands may be executed out of order.
2040 There is no requirement that partial fetches follow any sequence.
2041 For example, if a partial fetch of octets 1 through 10000 breaks
2042 in an awkward place for BASE64 decoding, it is permitted to
2043 continue with a partial fetch of 9987 through 19987, etc.
2045 The handling of the \Seen flag is the same as in the associated
2048 Example: C: A005 PARTIAL 4 RFC822 1 1024
2049 S: * 1 FETCH (RFC822 {1024}
2050 S: Return-Path: <gray@cac.washington.edu>
2052 S: ......... FLAGS (\Seen))
2053 S: A005 OK PARTIAL completed
2058 Arguments: message set
2059 message data item name
2060 value for message data item
2062 Data: untagged responses: FETCH
2064 Result: OK - store completed
2065 NO - store error: can't store that data
2066 BAD - command unknown or arguments invalid
2068 The STORE command alters data associated with a message in the
2069 mailbox. Normally, STORE will return the updated value of the
2070 data with an untagged FETCH response. A suffix of ".SILENT" in
2076RFC 1730 IMAP4 December 1994
2079 the data item name prevents the untagged FETCH, and the server
2080 should assume that the client has determined the updated value
2081 itself or does not care about the updated value.
2083 The currently defined data items that can be stored are:
2086 Replace the flags for the message with the
2087 argument. The new value of the flags are returned
2088 as if a FETCH of those flags was done.
2090 FLAGS.SILENT <flag list>
2091 Equivalent to FLAGS, but without returning a new
2095 Add the argument to the flags for the message. The
2096 new value of the flags are returned as if a FETCH
2097 of those flags was done.
2099 +FLAGS.SILENT <flag list>
2100 Equivalent to +FLAGS, but without returning a new
2104 Remove the argument from the flags for the message.
2105 The new value of the flags are returned as if a
2106 FETCH of those flags was done.
2108 -FLAGS.SILENT <flag list>
2109 Equivalent to -FLAGS, but without returning a new
2113 Example: C: A003 STORE 2:4 +FLAGS (\Deleted)
2114 S: * 2 FETCH FLAGS (\Deleted \Seen)
2115 S: * 3 FETCH FLAGS (\Deleted)
2116 S: * 4 FETCH FLAGS (\Deleted \Flagged \Seen)
2117 S: A003 OK STORE completed
2132RFC 1730 IMAP4 December 1994
2137 Arguments: message set
2140 Data: no specific data for this command
2142 Result: OK - copy completed
2143 NO - copy error: can't copy those messages or to that
2145 BAD - command unknown or arguments invalid
2147 The COPY command copies the specified message(s) to the specified
2148 destination mailbox. The flags and internal date of the
2149 message(s) SHOULD be preserved in the copy.
2151 If the destination mailbox does not exist, a server SHOULD return
2152 an error. It SHOULD NOT automatically create the mailbox. Unless
2153 it is certain that the destination mailbox can not be created, the
2154 server MUST send the response code "[TRYCREATE]" as the prefix of
2155 the text of the tagged NO response. This gives a hint to the
2156 client that it can attempt a CREATE command and retry the COPY if
2157 the CREATE is successful.
2159 If the COPY command is unsuccessful for any reason, server
2160 implementations MUST restore the destination mailbox to its state
2161 before the COPY attempt.
2163 Example: C: A003 COPY 2:4 MEETING
2164 S: A003 OK COPY completed
2169 Arguments: command name
2172 Data: untagged responses: FETCH, SEARCH
2174 Result: OK - UID command completed
2175 NO - UID command error
2176 BAD - command unknown or arguments invalid
2178 The UID command has two forms. In the first form, it takes as its
2179 arguments a COPY, FETCH, or STORE command with arguments
2180 appropriate for the associated command. However, the numbers in
2181 the message set argument are unique identifiers instead of message
2188RFC 1730 IMAP4 December 1994
2191 In the second form, the UID command takes a SEARCH command with
2192 SEARCH command arguments. The interpretation of the arguments is
2193 the same as with SEARCH; however, the numbers returned in a SEARCH
2194 response for a UID SEARCH command are unique identifiers instead
2195 of message sequence numbers. For example, the command UID SEARCH
2196 1:100 UID 443:557 returns the unique identifiers corresponding to
2197 the intersection of the message sequence number set 1:100 and the
2200 A unique identifier of a message is a number, and is guaranteed
2201 not to refer to any other message in the mailbox. Unique
2202 identifiers are assigned in a strictly ascending fashion for each
2203 message added to the mailbox. Unlike message sequence numbers,
2204 unique identifiers persist across sessions. This permits a client
2205 to resynchronize its state from a previous session with the server
2206 (e.g. disconnected or offline access clients); this is discussed
2207 further in [IMAP-DISC].
2209 Associated with every mailbox is a unique identifier validity
2210 value, which is sent in an UIDVALIDITY response code in an OK
2211 untagged response at message selection time. If unique
2212 identifiers from an earlier session fail to persist to this
2213 session, the unique identifier validity value MUST be greater than
2214 in the earlier session.
2216 Note: An example of a good value to use for the unique
2217 identifier validity value would be a 32-bit
2218 representation of the creation date/time of the mailbox.
2219 It is alright to use a constant such as 1, but only if
2220 it guaranteed that unique identifers will never be
2221 reused, even in the case of a mailbox being deleted and
2222 a new mailbox by the same name created at some future
2226 Message set ranges are permitted; however, there is no guarantee
2227 that unique identifiers be contiguous. A non-existent unique
2228 identifier within a message set range is ignored without any error
2231 The number after the "*" in an untagged FETCH response is always a
2232 message sequence number, not a unique identifier, even for a UID
2233 command response. However, server implementations MUST implicitly
2234 include the UID message data item as part of any FETCH response
2235 caused by a UID command, regardless of whether UID was specified
2236 as a message data item to the FETCH.
2244RFC 1730 IMAP4 December 1994
2247 Example: C: A003 UID FETCH 4827313:4828442 FLAGS
2248 S: * 23 FETCH (FLAGS (\Seen) UID 4827313)
2249 S: * 24 FETCH (FLAGS (\Seen) UID 4827943)
2250 S: * 25 FETCH (FLAGS (\Seen) UID 4828442)
2251 S: A999 UID FETCH completed
22556.5. Client Commands - Experimental/Expansion
22586.5.1. X<atom> Command
2260 Arguments: implementation defined
2262 Data: implementation defined
2264 Result: OK - command completed
2266 BAD - command unknown or arguments invalid
2268 Any command prefixed with an X is an experimental command.
2269 Commands which are not part of this specification, or a standard
2270 or standards-track revision of this specification, MUST use the X
2273 Any added untagged responses issued by an experimental command
2274 MUST also be prefixed with an X. Server implementations MUST NOT
2275 send any such untagged responses, unless the client requested it
2276 by issuing the associated experimental command.
2278 Example: C: a441 CAPABILITY
2279 S: * CAPABILITY IMAP4 XPIG-LATIN
2280 S: a441 OK CAPABILITY completed
2282 S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay
2283 S: A442 OK XPIG-LATIN ompleted-cay
2300RFC 1730 IMAP4 December 1994
2305 Server responses are in three forms: status responses, server data,
2306 and command continuation request.
2308 Server response data, identified by "Data:" in the response
2309 descriptions below, are described by function, not by syntax. The
2310 precise syntax of server response data is described in the Formal
2313 The client MUST be prepared to accept any response at all times.
2315 Status responses that are tagged indicate the completion result of a
2316 client command, and have a tag matching the command.
2318 Some status responses, and all server data, are untagged. An
2319 untagged response is indicated by the token "*" instead of a tag.
2320 Untagged status responses indicate server greeting, or server status
2321 that does not indicate the completion of a command. For historical
2322 reasons, untagged server data responses are also called "unsolicited
2323 data", although strictly speaking only unilateral server data is
2324 truly "unsolicited".
2326 Certain server data MUST be recorded by the client when it is
2327 received; this is noted in the description of that data. Such data
2328 conveys critical information which affects the interpretation of all
2329 subsequent commands and responses (e.g. updates reflecting the
2330 creation or destruction of messags).
2332 Other server data SHOULD be recorded for later reference; if the
2333 client does not need to record the data, or if recording the data has
2334 no obvious purpose (e.g. a SEARCH response when no SEARCH command is
2335 in progress), the data SHOULD be ignored.
2337 An example of unilateral untagged responses occurs when the IMAP
2338 connection is in selected state. In selected state, the server
2339 checks the mailbox for new messages as part of the execution of each
2340 command. If new messages are found, the server sends untagged EXISTS
2341 and RECENT responses reflecting the new size of the mailbox. Server
2342 implementations that offer multiple simultaneous access to the same
2343 mailbox should also send appropriate unilateral untagged FETCH and
2344 EXPUNGE responses if another agent changes the state of any message
2345 flags or expunges any messages.
2347 Command continuation request responses use the token "+" instead of a
2348 tag. These responses are sent by the server to indicate acceptance
2349 of an incomplete client command and readiness for the remainder of
2356RFC 1730 IMAP4 December 1994
23597.1. Server Responses - Status Responses
2361 Status responses may include an optional response code. A response
2362 code consists of data inside square brackets in the form of an atom,
2363 possibly followed by a space and arguments. The response code
2364 contains additional information or status codes for client software
2365 beyond the OK/NO/BAD condition, and are defined when there is a
2366 specific action that a client can take based upon the additional
2369 The currently defined response codes are:
2371 ALERT The human-readable text contains a special alert
2372 that MUST be presented to the user in a fashion
2373 that calls the user's attention to the message.
2375 PARSE The human-readable text represents an error in
2376 parsing the [RFC-822] or [MIME-1] headers of a
2377 message in the mailbox.
2379 PERMANENTFLAGS Followed by a parenthesized list of flags,
2380 indicates which of the known flags that the client
2381 may change permanently. Any flags that are in the
2382 FLAGS untagged response, but not the PERMANENTFLAGS
2383 list, can not be set permanently. If the client
2384 attempts to STORE a flag that is not in the
2385 PERMANENTFLAGS list, the server will either reject
2386 it with a NO reply or store the state for the
2387 remainder of the current session only. The
2388 PERMANENTFLAGS list may also include the special
2389 flag \*, which indicates that it is possible to
2390 create new keywords by attempting to store those
2391 flags in the mailbox.
2393 READ-ONLY The mailbox is selected read-only, or its access
2394 while selected has changed from read-write to
2397 READ-WRITE The mailbox is selected read-write, or its access
2398 while selected has changed from read-only to
2401 TRYCREATE An APPEND or COPY attempt is failing because the
2402 target mailbox does not exist (as opposed to some
2403 other reason). This is a hint to the client that
2404 the operation may succeed if the mailbox is first
2405 created by the CREATE command.
2412RFC 1730 IMAP4 December 1994
2415 UIDVALIDITY Followed by a decimal number, indicates the unique
2416 identifier validity value. See the description of
2417 the UID command for more detail.
2419 UNSEEN Followed by a decimal number, indicates the number
2420 of the first message without the \Seen flag set.
2422 Additional response codes defined by particular client or server
2423 implementations should be prefixed with an "X" until they are
2424 added to a revision of this protocol. Client implementations
2425 should ignore response codes that they do not recognize.
2430 Data: optional response code
2433 The OK response indicates an information message from the server.
2434 When tagged, it indicates successful completion of the associated
2435 command. The human-readable text may be presented to the user as
2436 an information message. The untagged form indicates an
2437 information-only message; the nature of the information may be
2438 indicated by a response code.
2440 The untagged form is also used as one of three possible greetings
2441 at session startup. It indicates that the session is not yet
2442 authenticated and that a LOGIN command is needed.
2444 Example: S: * OK IMAP4 server ready
2445 C: A001 LOGIN fred blurdybloop
2446 S: * OK [ALERT] System shutdown in 10 minutes
2447 S: A001 OK LOGIN Completed
2452 Data: optional response code
2455 The NO response indicates an operational error message from the
2456 server. When tagged, it indicates unsuccessful completion of the
2457 associated command. The untagged form indicates a warning; the
2458 command may still complete successfully. The human-readable text
2459 describes the condition.
2468RFC 1730 IMAP4 December 1994
2471 Example: C: A222 COPY 1:2 owatagusiam
2472 S: * NO Disk is 98% full, please delete unnecessary data
2473 S: A222 OK COPY completed
2474 C: A222 COPY 3:200 blurdybloop
2475 S: * NO Disk is 98% full, please delete unnecessary data
2476 S: * NO Disk is 99% full, please delete unnecessary data
2477 S: A222 NO COPY failed: disk is full
2482 Data: optional response code
2485 The BAD response indicates an error message from the server. When
2486 tagged, it reports a protocol-level error in the client's command;
2487 the tag indicates the command that caused the error. The untagged
2488 form indicates a protocol-level error for which the associated
2489 command can not be determined; it may also indicate an internal
2490 server failure. The human-readable text describes the condition.
2492 Example: C: ...very long command line...
2493 S: * BAD Command line too long
2495 S: * BAD Empty command line
2497 S: * BAD Disk crash, attempting salvage to a new disk!
2498 S: * OK Salvage successful, no data lost
2499 S: A443 OK Expunge completed
25027.1.4. PREAUTH Response
2504 Data: optional response code
2507 The PREAUTH response is always untagged, and is one of three
2508 possible greetings at session startup. It indicates that the
2509 session has already been authenticated by external means and thus
2510 no LOGIN command is needed.
2512 Example: S: * PREAUTH IMAP4 server ready and logged in as Smith
2524RFC 1730 IMAP4 December 1994
2529 Data: optional response code
2532 The BYE response is always untagged, and indicates that the server
2533 is about to close the connection. The human-readable text may be
2534 displayed to the user in a status report by the client. The BYE
2535 response may be sent as part of a normal logout sequence, or as a
2536 panic shutdown announcement by the server. It is also used by
2537 some server implementations as an announcement of an inactivity
2540 This response is also used as one of three possible greetings at
2541 session startup. It indicates that the server is not willing to
2542 accept a session from this client.
2544 Example: S: * BYE Autologout; idle for too long
25487.2. Server Responses - Server and Mailbox Status
2550 These responses are always untagged. This is how server data are
2551 transmitted from the server to the client, often as a result of a
2552 command with the same name.
25547.2.1. CAPABILITY Response
2556 Data: capability listing
2558 The CAPABILITY response occurs as a result of a CAPABILITY
2559 command. The capability listing contains a space-separated
2560 listing of capability names that the server supports. The first
2561 name in the capability listing MUST be the atom "IMAP4".
2563 A capability name other than IMAP4 indicates that the server
2564 supports an extension, revision, or amendment to the IMAP4
2565 protocol. Server responses MUST conform to this document until
2566 the client issues a command that uses the associated capability.
2568 Capability names MUST either begin with "X" or be standard or
2569 standards-track IMAP4 extensions, revisions, or amendments
2570 registered with IANA. A server MUST NOT offer unregistered or
2571 non-standard capability names, unless such names are prefixed with
2580RFC 1730 IMAP4 December 1994
2583 Client implementations SHOULD NOT require any capability name
2584 other than "IMAP4", and MUST ignore any unknown capability names.
2586 Example: S: * CAPABILITY IMAP4 XPIG-LATIN
2591 Data: name attributes
2595 The LIST response occurs as a result of a LIST command. It
2596 returns a single name that matches the LIST specification. There
2597 may be multiple LIST responses for a single LIST command.
2599 Four name attributes are defined:
2601 \Noinferiors It is not possible for any child levels of
2602 hierarchy to exist under this name; no child levels
2603 exist now and none can be created in the future.
2605 \Noselect It is not possible to use this name as a selectable
2608 \Marked The mailbox has been marked "interesting" by the
2609 server; the mailbox probably contains messages that
2610 have been added since the last time the mailbox was
2613 \Unmarked The mailbox does not contain any additional
2614 messages since the last time the mailbox was
2617 If it is not feasible for the server to determine whether the
2618 mailbox is "interesting" or not, or if the name is a \Noselect
2619 name, the server should not send either \Marked or \Unmarked.
2621 The hierarchy delimiter is a character used to delimit levels of
2622 hierarchy in a mailbox name. A client may use it to create child
2623 mailboxes, and to search higher or lower levels of naming
2624 hierarchy. All children of a top-level hierarchy node must use
2625 the same separator character. A NIL hierarchy delimiter means
2626 that no hierarchy exists; the name is a "flat" name.
2636RFC 1730 IMAP4 December 1994
2639 The name represents an unambiguous left-to-right hierarchy, and
2640 MUST be valid for use as a reference in LIST and LSUB commands.
2641 Unless \Noselect is indicated, the name must also be valid as an
2642 argument for commands, such as SELECT, that accept mailbox names.
2644 Example: S: * LIST (\Noselect) "/" ~/Mail/foo
2649 Data: name attributes
2653 The LSUB response occurs as a result of an LSUB command. It
2654 returns a single name that matches the LSUB specification. There
2655 may be multiple LSUB responses for a single LSUB command. The
2656 data is identical in format to the LIST response.
2658 Example: S: * LSUB () "." #news.comp.mail.misc
26617.2.4. SEARCH Response
2663 Data: zero or more numbers
2665 The SEARCH response occurs as a result of a SEARCH or UID SEARCH
2666 command. The number(s) refer to those messages that match the
2667 search criteria. For SEARCH, these are message sequence numbers;
2668 for UID SEARCH, these are unique identifiers. Each number is
2669 delimited by a space.
2671 Example: S: * SEARCH 2 3 6
26747.2.5. FLAGS Response
2676 Data: flag parenthesized list
2678 The FLAGS response occurs as a result of a SELECT or EXAMINE
2679 command. The flag parenthesized list identifies the flags (at a
2680 minimum, the system-defined flags) that are applicable for this
2681 mailbox. Flags other than the system flags may also exist,
2682 depending on server implementation.
2684 The update from the FLAGS response MUST be recorded by the client.
2686 Example: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
2692RFC 1730 IMAP4 December 1994
26957.3. Server Responses - Message Status
2697 These responses are always untagged. This is how message data are
2698 transmitted from the server to the client, often as a result of a
2699 command with the same name. Immediately following the "*" token is a
2700 number that represents either a message sequence number or a message
27037.3.1. EXISTS Response
2707 The EXISTS response reports the number of messages in the mailbox.
2708 This response occurs as a result of a SELECT or EXAMINE command,
2709 and if the size of the mailbox changes (e.g. new mail).
2711 The update from the EXISTS response MUST be recorded by the
2714 Example: S: * 23 EXISTS
27177.3.2. RECENT Response
2721 The RECENT response reports the number of messages that have
2722 arrived since the previous time a SELECT command was done on this
2723 mailbox. This response occurs as a result of a SELECT or EXAMINE
2724 command, and if the size of the mailbox changes (e.g. new mail).
2726 The update from the RECENT response MUST be recorded by the
2729 Example: S: * 5 RECENT
27327.3.3. EXPUNGE Response
2736 The EXPUNGE response reports that the specified message sequence
2737 number has been permanently removed from the mailbox. The message
2738 sequence number for each successive message in the mailbox is
2739 immediately decremented by 1, and this decrement is reflected in
2740 message sequence numbers in subsequent responses (including other
2741 untagged EXPUNGE responses).
2748RFC 1730 IMAP4 December 1994
2751 As a result of the immediate decrement rule, message sequence
2752 numbers that appear in a set of successive EXPUNGE responses
2753 depend upon whether the messages are removed starting from lower
2754 numbers to higher numbers, or from higher numbers to lower
2755 numbers. For example, if the last 5 messages in a 9-message
2756 mailbox are expunged; a "lower to higher" server will send five
2757 untagged EXPUNGE responses for message sequence number 5, whereas
2758 a "higher to lower server" will send successive untagged EXPUNGE
2759 responses for message sequence numbers 9, 8, 7, 6, and 5.
2761 An EXPUNGE response MUST NOT be sent when no command is in
2762 progress; nor while responding to a FETCH, STORE, or SEARCH
2763 command. This rule is necessary to prevent a loss of
2764 synchronization of message sequence numbers between client and
2767 The update from the EXPUNGE response MUST be recorded by the
2770 Example: S: * 44 EXPUNGE
27737.3.4. FETCH Response
2777 The FETCH response returns data about a message to the client.
2778 The data are pairs of data item names and their values in
2779 parentheses. This response occurs as the result of a FETCH or
2780 STORE command, as well as by unilateral server decision (e.g. flag
2783 The current data items are:
2785 BODY A form of BODYSTRUCTURE without extension data.
2787 BODY[section] A string expressing the body contents of the
2788 specified section. The string should be
2789 interpreted by the client according to the content
2790 transfer encoding, body type, and subtype.
2792 8-bit textual data is permitted if a character set
2793 identifier is part of the body parameter
2794 parenthesized list for this section.
2796 Non-textual data such as binary data must be
2797 transfer encoded into a textual form such as BASE64
2798 prior to being sent to the client. To derive the
2804RFC 1730 IMAP4 December 1994
2807 original binary data, the client must decode the
2808 transfer encoded string.
2810 BODYSTRUCTURE A parenthesized list that describes the body
2811 structure of a message. This is computed by the
2812 server by parsing the [RFC-822] header and body
2813 into the component parts, defaulting various fields
2816 Multiple parts are indicated by parenthesis
2817 nesting. Instead of a body type as the first
2818 element of the parenthesized list there is a nested
2819 body. The second element of the parenthesized list
2820 is the multipart subtype (mixed, digest, parallel,
2823 Extension data follows the multipart subtype.
2824 Extension data is never returned with the BODY
2825 fetch, but may be returned with a BODYSTRUCTURE
2826 fetch. Extension data, if present, must be in the
2829 The extension data of a multipart body part are in
2830 the following order:
2832 body parameter parenthesized list
2833 A parenthesized list of attribute/value pairs
2834 [e.g. (foo bar baz rag) where "bar" is the value
2835 of "foo" and "rag" is the value of "baz"] as
2836 defined in [MIME-1].
2838 Any following extension data are not yet defined in
2839 this version of the protocol. Such extension data
2840 may consist of zero or more NILs, strings, numbers,
2841 or potentially nested parenthesized lists of such
2842 data. Client implementations that do a
2843 BODYSTRUCTURE fetch MUST be prepared to accept such
2844 extension data. Server implementations MUST NOT
2845 send such extension data until it has been defined
2846 by a revision of this protocol.
2848 The basic fields of a non-multipart body part are
2849 in the following order:
2852 A string giving the content type name as defined
2860RFC 1730 IMAP4 December 1994
2864 A string giving the content subtype name as
2865 defined in [MIME-1].
2867 body parameter parenthesized list
2868 A parenthesized list of attribute/value pairs
2869 [e.g. (foo bar baz rag) where "bar" is the value
2870 of "foo" and "rag" is the value of "baz"] as
2871 defined in [MIME-1].
2874 A string giving the content id as defined in
2878 A string giving the content description as
2879 defined in [MIME-1].
2882 A string giving the content transfer encoding as
2883 defined in [MIME-1].
2886 A number giving the size of the body in octets.
2887 Note that this size is the size in its transfer
2888 encoding and not the resulting size after any
2891 A body type of type MESSAGE and subtype RFC822
2892 contains, immediately after the basic fields, the
2893 envelope structure, body structure, and size in
2894 text lines of the encapsulated message.
2896 A body type of type TEXT contains, immediately
2897 after the basic fields, the size of the body in
2898 text lines. Note that this size is the size in its
2899 transfer encoding and not the resulting size after
2902 Extension data follows the basic fields and the
2903 type-specific fields listed above. Extension data
2904 is never returned with the BODY fetch, but may be
2905 returned with a BODYSTRUCTURE fetch. Extension
2906 data, if present, must be in the defined order.
2908 The extension data of a non-multipart body part are
2909 in the following order:
2916RFC 1730 IMAP4 December 1994
2920 A string giving the content MD5 value as defined
2923 Any following extension data are not yet defined in
2924 this version of the protocol, and would be as
2925 described above under multipart extension data.
2927 ENVELOPE A parenthesized list that describes the envelope
2928 structure of a message. This is computed by the
2929 server by parsing the [RFC-822] header into the
2930 component parts, defaulting various fields as
2933 The fields of the envelope structure are in the
2934 following order: date, subject, from, sender,
2935 reply-to, to, cc, bcc, in-reply-to, and message-id.
2936 The date, subject, in-reply-to, and message-id
2937 fields are strings. The from, sender, reply-to,
2938 to, cc, and bcc fields are parenthesized lists of
2941 An address structure is a parenthesized list that
2942 describes an electronic mail address. The fields
2943 of an address structure are in the following order:
2944 personal name, [SMTP] at-domain-list (source
2945 route), mailbox name, and host name.
2947 [RFC-822] group syntax is indicated by a special
2948 form of address structure in which the host name
2949 field is NIL. If the mailbox name field is also
2950 NIL, this is an end of group marker (semi-colon in
2951 RFC 822 syntax). If the mailbox name field is
2952 non-NIL, this is a start of group marker, and the
2953 mailbox name field holds the group name phrase.
2955 Any field of an envelope or address structure that
2956 is not applicable is presented as NIL. Note that
2957 the server must default the reply-to and sender
2958 fields from the from field; a client is not
2959 expected to know to do this.
2972RFC 1730 IMAP4 December 1994
2975 FLAGS A parenthesized list of flags that are set for this
2976 message. This may include keywords as well as the
2977 following system flags:
2979 \Seen Message has been read
2981 \Answered Message has been answered
2983 \Flagged Message is "flagged" for urgent/special
2986 \Deleted Message is "deleted" for removal by
2989 \Draft Message has not completed composition
2990 (marked as a draft).
2992 as well as the following special flag, which may be
2993 fetched but not stored:
2995 \Recent Message has arrived since the previous
2996 time this mailbox was selected.
2998 INTERNALDATE A string containing the date and time of final
2999 delivery of the message as defined by [SMTP].
3001 RFC822 A string expressing the message in [RFC-822]
3002 format. The header portion of the message must be
3003 7-bit. 8-bit characters are permitted only in the
3004 non-header portion of the message only if there are
3005 [MIME-1] data in the message that identify the
3006 character set of the message.
3008 RFC822.HEADER A string expressing the [RFC-822] format header of
3009 the message, including the delimiting blank line
3010 between the header and the body. The entire string
3011 must be 7-bit; 8-bit characters are not permitted
3012 in headers. RFC822.HEADER is used to return data
3013 for the RFC822.HEADER, RFC822.HEADER.LINES, and
3014 RFC822.HEADER.LINES.NOT FETCH data items. Note
3015 that a blank line is always included regardless of
3016 header line restrictions.
3018 RFC822.SIZE A number expressing the number of octets in the
3019 message in [RFC-822] format.
3028RFC 1730 IMAP4 December 1994
3031 RFC822.TEXT A string expressing the text body of the message,
3032 omitting the [RFC-822] header. 8-bit characters
3033 are permitted only if there are [MIME-1] data in
3034 the message that identify the character set of the
3037 UID A number expressing the unique identifier of the
3041 Example: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827)
30447.3.5. Obsolete Responses
3046 In addition to the responses listed in here, client implementations
3047 MUST accept and implement the obsolete responses described in
30527.4. Server Responses - Command Continuation Request
3054 The command completion request response is indicated by a "+" token
3055 instead of a tag. This form of response indicates that the server is
3056 ready to accept the continuation of a command from the client. The
3057 remainder of this response is a line of text.
3059 This response is used in the AUTHORIZATION command to transmit server
3060 data to the client, and request additional client data. This
3061 response is also used if an argument to any command is a literal.
3063 The client is not permitted to send the octets of the literal unless
3064 the server indicates that it expects it. This permits the server to
3065 process commands and reject errors on a line-by-line basis. The
3066 remainder of the command, including the CRLF that terminates a
3067 command, follows the octets of the literal. If there are any
3068 additional command arguments the literal octets are followed by a
3069 space and those arguments.
3071 Example: C: A001 LOGIN {11}
3072 S: + Ready for additional command text
3074 S: + Ready for additional command text
3076 S: A001 OK LOGIN completed
3077 C: A044 BLURDYBLOOP {102856}
3078 S: A044 BAD No such command as "BLURDYBLOOP"
3084RFC 1730 IMAP4 December 1994
30878. Sample IMAP4 session
3089 The following is a transcript of an IMAP4 session. A long line in
3090 this sample is broken for editorial clarity.
3092 S: * OK IMAP4 Service Ready
3093 C: a001 login mrc secret
3094 S: a001 OK LOGIN completed
3095 C: a002 select inbox
3097 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
3099 S: * OK [UNSEEN 17] Message 17 is the first unseen message
3100 S: * OK [UIDVALIDITY 3857529045] UIDs valid
3101 S: a002 OK [READ-WRITE] SELECT completed
3102 C: a003 fetch 12 full
3103 S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "14-Jul-1993 02:44:25 -0700"
3104 RFC822.SIZE 4282 ENVELOPE ("Wed, 14 Jul 1993 02:23:25 -0700 (PDT)"
3105 "IMAP4 WG mtg summary and minutes"
3106 (("Terry Gray" NIL "gray" "cac.washington.edu"))
3107 (("Terry Gray" NIL "gray" "cac.washington.edu"))
3108 (("Terry Gray" NIL "gray" "cac.washington.edu"))
3109 ((NIL NIL "imap" "cac.washington.edu"))
3110 ((NIL NIL "minutes" "CNRI.Reston.VA.US")
3111 ("John Klensin" NIL "KLENSIN" "INFOODS.MIT.EDU")) NIL NIL
3112 "<B27397-0100000@cac.washington.edu>")
3113 BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92))
3114 S: a003 OK FETCH completed
3115 C: a004 fetch 12 rfc822.header
3116 S: * 12 FETCH (RFC822.HEADER {346}
3117 S: Date: Wed, 14 Jul 1993 02:23:25 -0700 (PDT)
3118 S: From: Terry Gray <gray@cac.washington.edu>
3119 S: Subject: IMAP4 WG mtg summary and minutes
3120 S: To: imap@cac.washington.edu
3121 S: cc: minutes@CNRI.Reston.VA.US, John Klensin <KLENSIN@INFOODS.MIT.EDU>
3122 S: Message-Id: <B27397-0100000@cac.washington.edu>
3123 S: MIME-Version: 1.0
3124 S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
3127 S: a004 OK FETCH completed
3128 C: a005 store 12 +flags \deleted
3129 S: * 12 FETCH (FLAGS (\Seen \Deleted))
3130 S: a005 OK +FLAGS completed
3132 S: * BYE IMAP4 server terminating connection
3133 S: a006 OK LOGOUT completed
3140RFC 1730 IMAP4 December 1994
3145 The following syntax specification uses the augmented Backus-Naur
3146 Form (BNF) notation as specified in [RFC-822] with one exception; the
3147 delimiter used with the "#" construct is a single space (SPACE) and
3150 Except as noted otherwise, all alphabetic characters are
3151 case-insensitive. The use of upper or lower case characters to
3152 define token strings is for editorial clarity only. Implementations
3153 MUST accept these strings in a case-insensitive fashion.
3155 Syntax marked as obsolete may be encountered with implementations
3156 written for an earlier version of this protocol (e.g. IMAP2). New
3157 implementations SHOULD accept obsolete syntax as input, but MUST NOT
3158 otherwise use such syntax.
3160 address ::= "(" addr_name SPACE addr_adl SPACE addr_mailbox
3163 addr_adl ::= nstring
3165 addr_host ::= nstring
3166 ;; NIL indicates [RFC-822] group syntax
3168 addr_mailbox ::= nstring
3169 ;; NIL indicates end of [RFC-822] group; if
3170 ;; non-NIL and addr_host is NIL, holds
3171 ;; [RFC-822] group name
3173 addr_name ::= nstring
3175 alpha ::= "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" /
3176 "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" /
3177 "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" /
3179 "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" /
3180 "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" /
3181 "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" /
3185 append ::= "APPEND" SPACE mailbox [SPACE flag_list]
3186 [SPACE date_time] SPACE literal
3188 astring ::= atom / string
3196RFC 1730 IMAP4 December 1994
3199 atom ::= 1*ATOM_CHAR
3201 ATOM_CHAR ::= <any CHAR except atom_specials>
3203 atom_specials ::= "(" / ")" / "{" / SPACE / CTLs / list_wildcards /
3206 authenticate ::= "AUTHENTICATE" SPACE auth_type *(CRLF base64)
3210 base64 ::= *(4base64_char) [base64_terminal]
3212 base64_char ::= alpha / digit / "+" / "/"
3214 base64_terminal ::= (2base64_char "==") / (3base64_char "=")
3216 body ::= "(" body_type_1part / body_type_mpart ")"
3218 body_extension ::= nstring / number / "(" 1#body_extension ")"
3219 ;; Future expansion. Client implementations
3220 ;; MUST accept body_extension fields. Server
3221 ;; implementations MUST NOT generate
3222 ;; body_extension fields except as defined by
3223 ;; future standard or standards-track
3224 ;; revisions of this specification.
3226 body_ext_1part ::= body_fld_md5 [SPACE 1#body_extension]
3227 ;; MUST NOT be returned on non-extensible
3230 body_ext_mpart ::= body_fld_param [SPACE 1#body_extension]]
3231 ;; MUST NOT be returned on non-extensible
3234 body_fields ::= body_fld_param SPACE body_fld_id SPACE
3235 body_fld_desc SPACE body_fld_enc SPACE
3238 body_fld_desc ::= nstring
3240 body_fld_enc ::= (<"> ("7BIT" / "8BIT" / "BINARY" / "BASE64"/
3241 "QUOTED-PRINTABLE") <">) / string
3243 body_fld_id ::= nstring
3245 body_fld_lines ::= number
3252RFC 1730 IMAP4 December 1994
3255 body_fld_md5 ::= nstring
3257 body_fld_octets ::= number
3259 body_fld_param ::= "(" 1#(string string) ")" / nil
3261 body_fld_subtyp ::= string
3263 body_type_1part ::= (body_type_basic / body_type_msg / body_type_text)
3264 [SPACE body_ext_1part]
3266 body_type_basic ::= (<"> ("APPLICATION" / "AUDIO" / "IMAGE" /
3267 "MESSAGE" / "VIDEO") <">) / string) SPACE
3268 body_fld_subtyp SPACE body_fields
3269 ;; MESSAGE subtype MUST NOT be "RFC822"
3271 body_type_mpart ::= 1*body SPACE body_fld_subtyp
3272 [SPACE body_ext_mpart]
3274 body_type_msg ::= <"> "MESSAGE" <"> SPACE <"> "RFC822" <"> SPACE
3275 body_fields SPACE envelope SPACE body SPACE
3278 body_type_text ::= <"> "TEXT" <"> SPACE body_fld_subtyp SPACE
3279 body_fields SPACE body_fld_lines
3282 ;; Must begin with "X" or be registered with
3283 ;; IANA as standard or standards-track
3285 capability_data ::= "CAPABILITY" SPACE "IMAP4" [SPACE 1#capability]
3287 CHAR ::= <any 7-bit US-ASCII character except NUL,
3290 CHAR8 ::= <any 8-bit octet except NUL, 0x01 - 0xff>
3292 command ::= tag SPACE (command_any / command_auth /
3293 command_nonauth / command_select) CRLF
3294 ;; Modal based on state
3296 command_any ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command
3297 ;; Valid in all states
3299 command_auth ::= append / create / delete / examine / find / list /
3300 lsub / rename / select / subscribe / unsubscribe /
3301 ;; Valid only in Authenticated or Selected state
3308RFC 1730 IMAP4 December 1994
3311 command_nonauth ::= login / authenticate
3312 ;; Valid only when in Non-Authenticated state
3314 command_select ::= "CHECK" / "CLOSE" / "EXPUNGE" /
3315 copy / fetch / partial / store / uid / search
3316 ;; Valid only when in Selected state
3318 continue_req ::= "+" SPACE (resp_text / base64)
3320 copy ::= "COPY" SPACE set SPACE mailbox
3322 CR ::= <ASCII CR, carriage return, 0x0C>
3324 create ::= "CREATE" SPACE mailbox
3325 ;; Use of INBOX gives a NO error
3329 CTL ::= <any ASCII control character and DEL,
3332 date ::= date_text / <"> date_text <">
3334 date_day ::= 1*2digit
3337 date_day_fixed ::= (SPACE digit) / 2digit
3338 ;; Fixed-format version of date_day
3340 date_month ::= "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" /
3341 "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"
3343 date_text ::= date_day "-" date_month "-" (date_year /
3346 date_year ::= 4digit
3348 date_year_old ::= 2digit
3349 ;; OBSOLETE, (year - 1900)
3351 date_time ::= <"> (date_time_new / date_time_old) <">
3353 date_time_new ::= date_day_fixed "-" date_month "-" date_year
3354 SPACE time SPACE zone
3356 date_time_old ::= date_day_fixed "-" date_month "-" date_year_old
3357 SPACE time "-" zone_old
3364RFC 1730 IMAP4 December 1994
3367 delete ::= "DELETE" SPACE mailbox
3368 ;; Use of INBOX gives a NO error
3370 digit ::= "0" / digit_nz
3372 digit_nz ::= "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" /
3375 envelope ::= "(" env_date SPACE env_subject SPACE env_from
3376 SPACE env_sender SPACE env_reply-to SPACE env_to
3377 SPACE env_cc SPACE env_bcc SPACE env_in-reply-to
3378 SPACE env_message-id ")"
3380 env_bcc ::= "(" 1*address ")" / nil
3382 env_cc ::= "(" 1*address ")" / nil
3384 env_date ::= nstring
3386 env_from ::= "(" 1*address ")" / nil
3388 env_in-reply-to ::= nstring
3390 env_message-id ::= nstring
3392 env_reply-to ::= "(" 1*address ")" / nil
3394 env_sender ::= "(" 1*address ")" / nil
3396 env_subject ::= nstring
3398 env_to ::= "(" 1*address ")" / nil
3400 examine ::= "EXAMINE" SPACE mailbox
3402 fetch ::= "FETCH" SPACE set SPACE ("ALL" / "FULL" /
3403 "FAST" / fetch_att / "(" 1#fetch_att ")")
3405 fetch_att ::= "BODY" / "BODYSTRUCTURE" /
3406 "BODY" [".PEEK"] "[" section "]" / "ENVELOPE" /
3407 "FLAGS" / "INTERNALDATE" / "UID" /
3408 "RFC822" (([".TEXT"] [".PEEK"]) / ".SIZE" /
3409 (".HEADER" [".LINES" [".NOT"] SPACE header_list])
3411 find ::= "FIND" SPACE ["ALL."] "MAILBOXES" SPACE
3420RFC 1730 IMAP4 December 1994
3423 flag ::= "\Answered" / "\Flagged" / "\Deleted" /
3424 "\Seen" / "\Draft" / flag_keyword /
3427 flag_extension ::= "\" atom
3428 ;; Future expansion. Client implementations
3429 ;; MUST accept flag_extension flags. Server
3430 ;; implementations MUST NOT generate
3431 ;; flag_extension flags except as defined by
3432 ;; future standard or standards-track
3433 ;; revisions of this specification.
3435 flag_keyword ::= atom
3437 flag_list ::= "(" #flag ")"
3439 greeting ::= "*" SPACE (resp_cond_auth / resp_cond_bye) CRLF
3441 header_line ::= astring
3443 header_list ::= "(" 1#header_line ")"
3445 LF ::= <ASCII LF, line feed, 0x0A>
3447 list ::= "LIST" SPACE mailbox SPACE list_mailbox
3449 list_mailbox ::= 1*(ATOM_CHAR / list_wildcards) / string
3451 list_wildcards ::= "%" / "*"
3453 literal ::= "{" number "}" CRLF *CHAR8
3454 ;; Number represents the number of CHAR8 octets
3456 login ::= "LOGIN" SPACE userid SPACE password
3458 lsub ::= "LSUB" SPACE mailbox SPACE list_mailbox
3460 mailbox ::= "INBOX" / astring
3461 ;; INBOX is case-insensitive; other names may be
3462 ;; case-sensitive depending on implementation.
3464 mailbox_data ::= "FLAGS" SPACE flag_list /
3465 "LIST" SPACE mailbox_list /
3466 "LSUB" SPACE mailbox_list /
3467 "MAILBOX" SPACE text /
3468 "SEARCH" [SPACE 1#nz_number] /
3469 number SPACE "EXISTS" / number SPACE "RECENT"
3476RFC 1730 IMAP4 December 1994
3479 mailbox_list ::= "(" #("\Marked" / "\Noinferiors" /
3480 "\Noselect" / "\Unmarked" / flag_extension) ")"
3481 SPACE (<"> QUOTED_CHAR <"> / nil) SPACE mailbox
3483 message_data ::= nz_number SPACE ("EXPUNGE" /
3484 ("FETCH" SPACE msg_fetch) / msg_obsolete)
3486 msg_fetch ::= "(" 1#("BODY" SPACE body /
3487 "BODYSTRUCTURE" SPACE body /
3488 "BODY[" section "]" SPACE nstring /
3489 "ENVELOPE" SPACE envelope /
3490 "FLAGS" SPACE "(" #(flag / "\Recent") ")" /
3491 "INTERNALDATE" SPACE date_time /
3492 "RFC822" [".HEADER" / ".TEXT"] SPACE nstring /
3493 "RFC822.SIZE" SPACE number /
3494 "UID" SPACE uniqueid) ")"
3496 msg_obsolete ::= "COPY" / ("STORE" SPACE msg_fetch)
3497 ;; OBSOLETE untagged data responses
3501 nstring ::= string / nil
3504 ;; Unsigned 32-bit integer
3505 ;; (0 <= n < 4,294,967,296)
3507 nz_number ::= digit_nz *digit
3508 ;; Non-zero unsigned 32-bit integer
3509 ;; (0 < n < 4,294,967,296)
3511 partial ::= "PARTIAL" SPACE nz_number SPACE
3512 ("BODY" [".PEEK"] "[" section "]" /
3513 "RFC822" (([".TEXT"] [".PEEK"]) / ".HEADER")
3514 SPACE number SPACE number
3516 password ::= astring
3518 quoted ::= <"> *QUOTED_CHAR <">
3520 QUOTED_CHAR ::= <any TEXT_CHAR except quoted_specials> /
3523 quoted_specials ::= <"> / "\"
3525 rename ::= "RENAME" SPACE mailbox SPACE mailbox
3526 ;; Use of INBOX as a destination gives a NO error
3532RFC 1730 IMAP4 December 1994
3535 response ::= *response_data response_done
3537 response_data ::= "*" SPACE (resp_cond_state / resp_cond_bye /
3538 mailbox_data / message_data / capability_data)
3541 response_done ::= response_tagged / response_fatal
3543 response_fatal ::= "*" SPACE resp_cond_bye CRLF
3545 response_tagged ::= tag SPACE resp_cond_state CRLF
3547 resp_cond_auth ::= ("OK" / "PREAUTH") SPACE resp_text
3548 ;; Authentication condition
3550 resp_cond_bye ::= "BYE" SPACE resp_text
3551 ;; Server will disconnect condition
3553 resp_cond_state ::= ("OK" / "NO" / "BAD") SPACE resp_text
3556 resp_text ::= ["[" resp_text_code "]" SPACE] (text_mime2 / text)
3558 resp_text_code ::= "ALERT" / "PARSE" /
3559 "PERMANENTFLAGS" SPACE "(" #(flag / "\*") ")" /
3560 "READ-ONLY" / "READ-WRITE" / "TRYCREATE" /
3561 "UIDVALIDITY" SPACE nz_number /
3562 "UNSEEN" SPACE nz_number /
3563 atom [SPACE 1*<any TEXT_CHAR except "]">]
3565 search ::= "SEARCH" SPACE ["CHARSET" SPACE astring SPACE]
3567 ;; Character set must be registered with IANA
3568 ;; as a MIME character set
3570 search_criteria ::= 1#search_key
3572 search_key ::= search_new / search_old
3574 search_new ::= "DRAFT" /
3575 "HEADER" SPACE header_line SPACE astring /
3576 "LARGER" SPACE number / "NOT" SPACE search_key /
3577 "OR" SPACE search_key SPACE search_key /
3578 "SENTBEFORE" SPACE date / "SENTON" SPACE date /
3579 "SENTSINCE" SPACE date / "SMALLER" SPACE number /
3580 "UID" SPACE set / "UNDRAFT" / set /
3581 "(" search_criteria ")"
3588RFC 1730 IMAP4 December 1994
3591 search_old ::= "ALL" / "ANSWERED" / "BCC" SPACE astring /
3592 "BEFORE" SPACE date / "BODY" SPACE astring /
3593 "CC" SPACE astring / "DELETED" / "FLAGGED" /
3594 "FROM" SPACE astring /
3595 "KEYWORD" SPACE flag_keyword / "NEW" / "OLD" /
3596 "ON" SPACE date / "RECENT" / "SEEN" /
3597 "SINCE" SPACE date / "SUBJECT" SPACE astring /
3598 "TEXT" SPACE astring / "TO" SPACE astring /
3599 "UNANSWERED" / "UNDELETED" / "UNFLAGGED" /
3600 "UNKEYWORD" SPACE flag_keyword / "UNSEEN"
3601 ;; Defined in [IMAP2]
3603 section ::= "0" / nz_number ["." section]
3605 select ::= "SELECT" SPACE mailbox
3607 sequence_num ::= nz_number / "*"
3608 ;; * is the largest number in use. For message
3609 ;; sequence numbers, it is the number of messages
3610 ;; in the mailbox. For unique identifiers, it is
3611 ;; the unique identifier of the last message in
3614 set ::= sequence_num / (sequence_num ":" sequence_num) /
3616 ;; Identifies a set of messages. For message
3617 ;; sequence numbers, these are consecutive
3618 ;; numbers from 1 to the number of messages in
3620 ;; Comma delimits individual numbers, colon
3621 ;; delimits between two numbers inclusive.
3622 ;; Example: 2,4:7,9,12:* is 2,4,5,6,7,9,12,13,
3623 ;; 14,15 for a mailbox with 15 messages.
3625 SPACE ::= <ASCII SP, space, 0x20>
3627 store ::= "STORE" SPACE set SPACE store_att_flags
3629 store_att_flags ::= (["+" / "-"] "FLAGS" [".SILENT"]) SPACE
3632 string ::= quoted / literal
3634 subscribe ::= ("SUBSCRIBE" SPACE mailbox) / subscribe_obs
3636 subscribe_obs ::= "SUBSCRIBE" SPACE "MAILBOX" SPACE mailbox
3644RFC 1730 IMAP4 December 1994
3647 tag ::= 1*<any ATOM_CHAR except "+">
3649 text ::= 1*TEXT_CHAR
3651 text_mime2 ::= "=?" <charset> "?" <encoding> "?"
3653 ;; Syntax defined in [MIME-2]
3655 TEXT_CHAR ::= <any CHAR except CR and LF>
3657 time ::= 2digit ":" 2digit ":" 2digit
3658 ;; Hours minutes seconds
3660 uid ::= "UID" SPACE (copy / fetch / search / store)
3661 ;; Unique identifiers used instead of message
3664 uniqueid ::= nz_number
3665 ;; Strictly ascending
3667 unsubscribe ::= ("UNSUBSCRIBE" SPACE mailbox) / unsubscribe_obs
3669 unsubscribe_obs ::= "UNSUBSCRIBE" SPACE "MAILBOX" SPACE mailbox
3674 x_command ::= "X" atom <experimental command arguments>
3676 zone ::= ("+" / "-") 4digit
3677 ;; Signed four-digit value of hhmm representing
3678 ;; hours and minutes west of Greenwich (that is,
3679 ;; (the amount that the given time differs from
3680 ;; Universal Time). Subtracting the timezone
3681 ;; from the given time will give the UT form.
3682 ;; The Universal Time zone is "+0000".
3700RFC 1730 IMAP4 December 1994
3703 zone_old ::= "UT" / "GMT" / "Z" / ;; +0000
3704 "AST" / "EDT" / ;; -0400
3705 "EST" / "CDT" / ;; -0500
3706 "CST" / "MDT" / ;; -0600
3707 "MST" / "PDT" / ;; -0700
3708 "PST" / "YDT" / ;; -0800
3709 "YST" / "HDT" / ;; -0900
3710 "HST" / "BDT" / ;; -1000
3712 "A" / "B" / "C" / "D" / "E" / "F" / ;; +1 to +6
3713 "G" / "H" / "I" / "K" / "L" / "M" / ;; +7 to +12
3714 "N" / "O" / "P" / "Q" / "R" / "S" / ;; -1 to -6
3715 "T" / "U" / "V" / "W" / "X" / "Y" ;; -7 to -12
3756RFC 1730 IMAP4 December 1994
3761 This document is a revision or rewrite of earlier documents, and
3762 supercedes the protocol specification in those documents: IMAP4
3763 Internet drafts, the IMAP2bis Internet drafts, unpublished
3764 IMAP2bis.TXT document, RFC 1176, and RFC 1064.
376711. Security Considerations
3769 IMAP4 protocol transactions, including electronic mail data, are sent
3770 in the clear over the network unless the optional privacy protection
3771 is negotiated in the AUTHENTICATE command.
3773 A server error message for an AUTHENTICATE command which fails due to
3774 invalid credentials should not detail why the credentials are
3777 Use of the LOGIN command sends passwords in the clear. This can be
3778 avoided by using the AUTHENTICATE command instead.
3780 A server error message for a failing LOGIN command should not specify
3781 that the user name, as opposed to the password, is invalid.
3783 Additional security considerations are discussed in the section
3784 discussing the AUTHENTICATE and LOGIN commands.
3790 Networks and Distributed Computing, JE-30
3791 University of Washington
3794 Phone: (206) 543-5762
3796 EMail: MRC@CAC.Washington.EDU
3812RFC 1730 IMAP4 December 1994
3819 The following commands are OBSOLETE. It is NOT required to support
3820 any of these commands in new server implementations. These commands
3821 are documented here for the benefit of implementors who may wish to
3822 support them for compatibility with old client implementations.
3824 The section headings of these commands are intended to correspond
3825 with where they would be located in the main document if they were
3829A.6.3.OBS.1. FIND ALL.MAILBOXES Command
3831 Arguments: mailbox name with possible wildcards
3833 Data: untagged responses: MAILBOX
3835 Result: OK - find completed
3836 NO - find failure: can't list that name
3837 BAD - command unknown or arguments invalid
3839 The FIND ALL.MAILBOXES command returns a subset of names from the
3840 complete set of all names available to the user. It returns zero
3841 or more untagged MAILBOX replies. The mailbox argument to FIND
3842 ALL.MAILBOXES is similar to that for LIST with an empty reference,
3843 except that the characters "%" and "?" match a single character.
3845 Example: C: A002 FIND ALL.MAILBOXES *
3846 S: * MAILBOX blurdybloop
3848 S: A002 OK FIND ALL.MAILBOXES completed
3851A.6.3.OBS.2. FIND MAILBOXES Command
3853 Arguments: mailbox name with possible wildcards
3855 Data: untagged responses: MAILBOX
3857 Result: OK - find completed
3858 NO - find failure: can't list that name
3859 BAD - command unknown or arguments invalid
3861 The FIND MAILBOXES command returns a subset of names from the set
3862 of names that the user has declared as being "active" or
3868RFC 1730 IMAP4 December 1994
3871 "subscribed". It returns zero or more untagged MAILBOX replies.
3872 The mailbox argument to FIND MAILBOXES is similar to that for LSUB
3873 with an empty reference, except that the characters "%" and "?"
3874 match a single character.
3876 Example: C: A002 FIND MAILBOXES *
3877 S: * MAILBOX blurdybloop
3879 S: A002 OK FIND MAILBOXES completed
3882A.6.3.OBS.3. SUBSCRIBE MAILBOX Command
3884 Arguments: mailbox name
3886 Data: no specific data for this command
3888 Result: OK - subscribe completed
3889 NO - subscribe failure: can't subscribe to that name
3890 BAD - command unknown or arguments invalid
3892 The SUBSCRIBE MAILBOX command is identical in effect to the
3893 SUBSCRIBE command. A server which implements this command must be
3894 able to distinguish between a SUBSCRIBE MAILBOX command and a
3895 SUBSCRIBE command with a mailbox name argument of "MAILBOX".
3897 Example: C: A002 SUBSCRIBE MAILBOX #news.comp.mail.mime
3898 S: A002 OK SUBSCRIBE MAILBOX to #news.comp.mail.mime
3900 C: A003 SUBSCRIBE MAILBOX
3901 S: A003 OK SUBSCRIBE to MAILBOX completed
3904A.6.3.OBS.4. UNSUBSCRIBE MAILBOX Command
3906 Arguments: mailbox name
3908 Data: no specific data for this command
3910 Result: OK - unsubscribe completed
3911 NO - unsubscribe failure: can't unsubscribe that name
3912 BAD - command unknown or arguments invalid
3914 The UNSUBSCRIBE MAILBOX command is identical in effect to the
3915 UNSUBSCRIBE command. A server which implements this command must
3916 be able to distinguish between a UNSUBSCRIBE MAILBOX command and
3917 an UNSUBSCRIBE command with a mailbox name argument of "MAILBOX".
3924RFC 1730 IMAP4 December 1994
3927 Example: C: A002 UNSUBSCRIBE MAILBOX #news.comp.mail.mime
3928 S: A002 OK UNSUBSCRIBE MAILBOX from #news.comp.mail.mime
3930 C: A003 UNSUBSCRIBE MAILBOX
3931 S: A003 OK UNSUBSCRIBE from MAILBOX completed
3980RFC 1730 IMAP4 December 1994
3983B. Obsolete Responses
3985 The following responses are OBSOLETE. Except as noted below, these
3986 responses MUST NOT be transmitted by new server implementations.
3988 The section headings of these responses are intended to correspond
3989 with where they would be located in the main document if they were
3993B.7.2.OBS.1. MAILBOX Response
3997 The MAILBOX response MUST NOT be transmitted by server
3998 implementations except in response to the obsolete FIND MAILBOXES
3999 and FIND ALL.MAILBOXES commands. Client implementations that do
4000 not use these commands MAY ignore this response. It is documented
4001 here for the benefit of implementors who may wish to support it
4002 for compatibility with old client implementations.
4004 This response occurs as a result of the FIND MAILBOXES and FIND
4005 ALL.MAILBOXES commands. It returns a single name that matches the
4006 FIND specification. There are no attributes or hierarchy
4009 Example: S: * MAILBOX blurdybloop
4012B.7.3.OBS.1. COPY Response
4016 The COPY response MUST NOT be transmitted by new server
4017 implementations. Client implementations MUST ignore the COPY
4018 response. It is documented here for the benefit of client
4019 implementors who may encounter this response from old server
4022 In some experimental versions of this protocol, this response was
4023 returned in response to a COPY command to indicate on a
4024 per-message basis that the message was copied successfully.
4026 Example: S: * 44 COPY
4036RFC 1730 IMAP4 December 1994
4039B.7.3.OBS.2. STORE Response
4043 The STORE response MUST NOT be transmitted by new server
4044 implementations. Client implementations MUST treat the STORE
4045 response as equivalent to the FETCH response. It is documented
4046 here for the benefit of client implementors who may encounter this
4047 response from old server implementations.
4049 In some experimental versions of this protocol, this response was
4050 returned instead of FETCH in response to a STORE command to report
4051 the new value of the flags.
4053 Example: S: * 69 STORE (FLAGS (\Deleted))
4092RFC 1730 IMAP4 December 1994
4098 [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731.
4099 Carnegie-Mellon University, December 1994.
4101 [IMAP-COMPAT] Crispin, M. "IMAP4 Compatibility with IMAP2 and
4102 IMAP2bis", RFC 1732, University of Washington, December 1994.
4104 [IMAP-DISC] Austein, R. "Synchronization Operations for Disconnected
4105 IMAP4 Clients", Work in Progress.
4107 [IMAP-MODEL] Crispin, M. "Distributed Electronic Mail Models in
4108 IMAP4", RFC 1733, University of Washington, December 1994.
4110 [IMAP-NAMING] Crispin, M. "Mailbox Naming Convention in IMAP4", Work
4113 [IMAP2] Crispin, M., "Interactive Mail Access Protocol - Version 2",
4114 RFC 1176, University of Washington, August 1990.
4116 [IMSP] Myers, J. "IMSP -- Internet Message Support Protocol", Work in
4119 [MIME-1] Borenstein, N., and Freed, N., "MIME (Multipurpose Internet
4120 Mail Extensions) Part One: Mechanisms for Specifying and Describing
4121 the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft,
4124 [MIME-2] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
4125 Part Two: Message Header Extensions for Non-ASCII Text", RFC 1522,
4126 University of Tennessee, September 1993.
4128 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
4129 Messages", STD 11, RFC 822, University of Delaware, August 1982.
4131 [SMTP] Postel, Jonathan B. "Simple Mail Transfer Protocol", STD 10,
4132 RFC 821, USC/Information Sciences Institute, August 1982.
4148RFC 1730 IMAP4 December 1994
4151E. IMAP4 Keyword Index
4154 +FLAGS <flag list> (store command data item) ............... 34
4155 +FLAGS.SILENT <flag list> (store command data item) ........ 34
4156 -FLAGS <flag list> (store command data item) ............... 34
4157 -FLAGS.SILENT <flag list> (store command data item) ........ 34
4158 ALERT (response code) ...................................... 39
4159 ALL (fetch item) ........................................... 29
4160 ALL (search key) ........................................... 27
4161 ANSWERED (search key) ...................................... 27
4162 APPEND (command) ........................................... 22
4163 AUTHENTICATE (command) ..................................... 12
4164 BAD (response) ............................................. 41
4165 BCC <string> (search key) .................................. 27
4166 BEFORE <date> (search key) ................................. 27
4167 BODY (fetch item) .......................................... 29
4168 BODY (fetch result) ........................................ 46
4169 BODY <string> (search key) ................................. 27
4170 BODY.PEEK[<section>] (fetch item) .......................... 30
4171 BODYSTRUCTURE (fetch item) ................................. 31
4172 BODYSTRUCTURE (fetch result) ............................... 47
4173 BODY[<section>] (fetch item) ............................... 29
4174 BODY[section] (fetch result) ............................... 46
4175 BYE (response) ............................................. 41
4176 CAPABILITY (command) ....................................... 10
4177 CAPABILITY (response) ...................................... 42
4178 CC <string> (search key) ................................... 27
4179 CHECK (command) ............................................ 23
4180 CLOSE (command) ............................................ 24
4181 COPY (command) ............................................. 34
4182 COPY (response) ............................................ 68
4183 CREATE (command) ........................................... 17
4184 DELETE (command) ........................................... 18
4185 DELETED (search key) ....................................... 27
4186 DRAFT (search key) ......................................... 27
4187 ENVELOPE (fetch item) ...................................... 31
4188 ENVELOPE (fetch result) .................................... 49
4189 EXAMINE (command) .......................................... 16
4190 EXISTS (response) .......................................... 45
4191 EXPUNGE (command) .......................................... 25
4192 EXPUNGE (response) ......................................... 45
4193 FAST (fetch item) .......................................... 31
4194 FETCH (command) ............................................ 29
4195 FETCH (response) ........................................... 46
4196 FIND ALL.MAILBOXES (command) ............................... 65
4197 FIND MAILBOXES (command) ................................... 65
4198 FLAGGED (search key) ....................................... 27
4199 FLAGS (fetch item) ......................................... 31
4205RFC 1730 IMAP4 December 1994
4209 FLAGS (fetch result) ....................................... 50
4210 FLAGS (response) ........................................... 44
4211 FLAGS <flag list> (store command data item) ................ 34
4212 FLAGS.SILENT <flag list> (store command data item) ......... 34
4213 FROM <string> (search key) ................................. 27
4214 FULL (fetch item) .......................................... 31
4215 HEADER <field-name> <string> (search key) .................. 27
4216 INTERNALDATE (fetch item) .................................. 31
4217 INTERNALDATE (fetch result) ................................ 50
4218 KEYWORD <flag> (search key) ................................ 27
4219 LARGER <n> (search key) .................................... 27
4220 LIST (command) ............................................. 20
4221 LIST (response) ............................................ 43
4222 LOGIN (command) ............................................ 14
4223 LOGOUT (command) ........................................... 11
4224 LSUB (command) ............................................. 22
4225 LSUB (response) ............................................ 44
4226 MAILBOX (response) ......................................... 68
4227 NEW (search key) ........................................... 27
4228 NO (response) .............................................. 40
4229 NOOP (command) ............................................. 11
4230 NOT <search-key> (search key) .............................. 28
4231 OK (response) .............................................. 40
4232 OLD (search key) ........................................... 28
4233 ON <date> (search key) ..................................... 28
4234 OR <search-key1> <search-key2> (search key) ................ 28
4235 PARSE (response code) ...................................... 39
4236 PARTIAL (command) .......................................... 32
4237 PERMANENTFLAGS (response code) ............................. 39
4238 PREAUTH (response) ......................................... 41
4239 READ-ONLY (response code) .................................. 39
4240 READ-WRITE (response code) ................................. 39
4241 RECENT (response) .......................................... 45
4242 RECENT (search key) ........................................ 28
4243 RENAME (command) ........................................... 18
4244 RFC822 (fetch item) ........................................ 31
4245 RFC822 (fetch result) ...................................... 50
4246 RFC822.HEADER (fetch item) ................................. 31
4247 RFC822.HEADER (fetch result) ............................... 50
4248 RFC822.HEADER.LINES <header_list> (fetch item) ............. 31
4249 RFC822.HEADER.LINES.NOT <header_list> (fetch item) ......... 32
4250 RFC822.PEEK (fetch item) ................................... 31
4251 RFC822.SIZE (fetch item) ................................... 32
4252 RFC822.SIZE (fetch result) ................................. 50
4253 RFC822.TEXT (fetch item) ................................... 32
4254 RFC822.TEXT (fetch result) ................................. 51
4255 RFC822.TEXT.PEEK (fetch item) .............................. 32
4256 SEARCH (command) ........................................... 25
4262RFC 1730 IMAP4 December 1994
4266 SEARCH (response) .......................................... 44
4267 SEEN (search key) .......................................... 28
4268 SELECT (command) ........................................... 15
4269 SENTBEFORE <date> (search key) ............................. 28
4270 SENTON <date> (search key) ................................. 28
4271 SENTSINCE <date> (search key) .............................. 28
4272 SINCE <date> (search key) .................................. 28
4273 SMALLER <n> (search key) ................................... 28
4274 STORE (command) ............................................ 33
4275 STORE (response) ........................................... 69
4276 SUBJECT <string> (search key) .............................. 28
4277 SUBSCRIBE (command) ........................................ 19
4278 SUBSCRIBE MAILBOX (command) ................................ 66
4279 TEXT <string> (search key) ................................. 28
4280 TO <string> (search key) ................................... 28
4281 TRYCREATE (response code) .................................. 39
4282 UID (command) .............................................. 35
4283 UID (fetch item) ........................................... 32
4284 UID (fetch result) ......................................... 51
4285 UID <message set> (search key) ............................. 28
4286 UIDVALIDITY (response code) ................................ 40
4287 UNANSWERED (search key) .................................... 29
4288 UNDELETED (search key) ..................................... 29
4289 UNDRAFT (search key) ....................................... 29
4290 UNFLAGGED (search key) ..................................... 29
4291 UNKEYWORD <flag> (search key) .............................. 29
4292 UNSEEN (response code) ..................................... 40
4293 UNSEEN (search key) ........................................ 29
4294 UNSUBSCRIBE (command) ...................................... 19
4295 UNSUBSCRIBE MAILBOX (command) .............................. 66
4296 X<atom> (command) .......................................... 37
4297 \Answered (system flag) .................................... 50
4298 \Deleted (system flag) ..................................... 50
4299 \Draft (system flag) ....................................... 50
4300 \Flagged (system flag) ..................................... 50
4301 \Marked (mailbox name attribute) ........................... 43
4302 \Noinferiors (mailbox name attribute) ...................... 43
4303 \Noselect (mailbox name attribute) ......................... 43
4304 \Recent (system flag) ...................................... 50
4305 \Seen (system flag) ........................................ 50
4306 \Unmarked (mailbox name attribute) ......................... 43