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