7 Network Working Group M. Crispin
8 Request for Comments: 1176 Washington
9 Obsoletes: RFC 1064 August 1990
12 INTERACTIVE MAIL ACCESS PROTOCOL - VERSION 2
17 This RFC suggests a method for personal computers and workstations to
18 dynamically access mail from a mailbox server ("repository"). It
19 obosoletes RFC 1064. This RFC specifies an Experimental Protocol for
20 the Internet community. Discussion and suggestions for improvement
21 are requested. Please refer to the current edition of the "IAB
22 Official Protocol Standards" for the standardization state and status
23 of this protocol. Distribution of this memo is unlimited.
27 The intent of the Interactive Mail Access Protocol, Version 2 (IMAP2)
28 is to allow a workstation, personal computer, or similar small
29 machine to access electronic mail from a mailbox server. Since the
30 distinction between personal computers and workstations is blurring
31 over time, it is desirable to have a single solution that addresses
32 the need in a general fashion. IMAP2 is the "glue" of a distributed
33 electronic mail system consisting of a family of client and server
34 implementations on a wide variety of platforms, from small single-
35 tasking personal computing engines to complex multi-user timesharing
38 Although different in many ways from the Post Office Protocols (POP2
39 and POP3, hereafter referred to collectively as "POP") described in
40 RFC 937 and RFC 1081, IMAP2 may be thought of as a functional
41 superset of these. RFC 937 was used as a model for this RFC. There
42 was a cognizant reason for this; POP deals with a similar problem,
43 albeit with a less comprehensive solution, and it was desirable to
44 offer a basis for comparison.
46 Like POP, IMAP2 specifies a means of accessing stored mail and not of
47 posting mail; this function is handled by a mail transfer protocol
48 such as SMTP (RFC 821).
50 This protocol assumes a reliable data stream such as provided by TCP
51 or any similar protocol. When TCP is used, the IMAP2 server listens
60 RFC 1176 IMAP2 August 1990
63 System Model and Philosophy
65 Electronic mail is a primary means of communication for the widely
66 spread Internet community. The advent of distributed personal
67 computers and workstations has forced a significant rethinking of the
68 mechanisms employed to manage electronic mail. With mainframes, each
69 user tends to receive and process mail at the computer he uses most
70 of the time, his "primary host". The first inclination of many users
71 when an independent workstation is placed in front of them is to
72 begin receiving mail at the workstation, and many vendors have
73 implemented facilities to do this. However, this approach has
74 several disadvantages:
76 (1) Personal computers and many workstations have a software
77 design that gives full control of all aspects of the system to the
78 user at the console. As a result, background tasks such as
79 receiving mail may not run for long periods of time; either
80 because the user is asking to use all the machine's resources, or
81 because the user has (perhaps accidentally) manipulated the
82 environment in such a way that it prevents mail reception. In
83 many personal computers, the operating system is single-tasking
84 and this is the only mode of operation. Any of these conditions
85 could lead to repeated failed delivery attempts by outside agents.
87 (2) The hardware failure of a single machine can keep its user
88 "off the air" for a considerable time, since repair of individual
89 units may be delayed. Given the growing number of personal
90 computers and workstations spread throughout office environments,
91 quick repair of such systems is not assured. On the other hand, a
92 central mainframe is generally repaired soon after failure.
94 (3) Personal computers and workstations are often not backed up
95 with as much diligence as a central mainframe, if at all.
97 (4) It is more difficult to keep track of mailing addresses when
98 each person is associated with a distinct machine. Consider the
99 difficulty in keeping track of many postal addresses or phone
100 numbers, particularly if there was no single address or phone
101 number for an organization through which you could reach any
102 person in that organization. Traditionally, electronic mail on
103 the ARPANET involved remembering a name and one of several "hosts"
104 (machines) whose name reflected the organization in which the
105 individual worked. This was suitable at a time when most
106 organizations had only one central host. It is less satisfactory
107 today unless the concept of a host is changed to refer to an
108 organizational entity and not a particular machine.
110 (5) It is difficult to keep a multitude of heterogeneous machines
116 RFC 1176 IMAP2 August 1990
119 working properly with complex mailing protocols, making it
120 difficult to move forward as progress is made in electronic
121 communication and as new standards emerge. Each system has to
122 worry about receiving incoming mail, routing and delivering
123 outgoing mail, formatting, storing, and providing for the
124 stability of mailboxes over a variety of possible filing and
127 Consequently, while a personal computer or workstation may be viewed
128 as an Internet host in the sense that it implements TCP/IP, it should
129 not be viewed as the entity that contains the user's mailbox.
130 Instead, a mail server machine ("server", sometimes called a
131 "repository") should hold the mailbox, and the personal computer or
132 workstation (hereafter referred to as a "client") should access the
133 mailbox via mail transactions.
135 Because the mail server machine is isolated from direct user
136 manipulation, it should achieve high software reliability easily,
137 and, as a shared resource, it should also achieve high hardware
138 reliability, perhaps through redundancy. The mail server may be
139 accessed from arbitrary locations, allowing users to read mail across
140 campus, town, or country using commonly available clients.
141 Furthermore, the same user may access his mailbox from different
142 clients at different times, and multiple users may access the same
143 mailbox simultaneously.
145 The mail server acts an an interface among users, data storage, and
146 other mailers. A mail access protocol retrieves messages, accesss
147 and changes properties of messages, and otherwise manages mailboxes.
148 This differs from some approaches (e.g., Unix mail via NFS) in that
149 the mail access protocol is used for all message manipulations,
150 isolating the user and the client from all knowledge of how the data
151 storage is used. This means that the mail server can use the data
152 storage in whatever way is most efficient to organize the mail in
153 that particular environment, without having to worry about storage
154 representation compatibility across different machines.
156 A mail access protocol further differs in that it transmits
157 information only on demand. A well-designed mail access protocol
158 requires considerably less network traffic than Unix mail via NFS,
159 particularly when the mail file is large. The result is that a mail
160 access protocol can scale well to situations of large mailboxes or
161 networks with high latency or low speed.
163 In defining a mail access protocol, it is important to keep in mind
164 that the client and server form a macrosystem, in which it should be
165 possible to exploit the strong points of both while compensating for
166 each other's weaknesses. Furthermore, it is desirable to allow for a
172 RFC 1176 IMAP2 August 1990
175 growth path beyond the hoary text-only RFC 822 protocol, specifically
176 in the area of attachments and multi-media mail, to ease the eventual
177 transition to ISO solutions.
179 Unlike POP, IMAP2 has extensive features for remote searching and
180 parsing of messages on the server. A free text search (optionally
181 with other searching) can be made in the entire mailbox by the server
182 and the results made available to the client without the client
183 having to transfer the entire mailbox and searching itself. Since
184 remote parsing of a message into a structured (and standard format)
185 "envelope" is available, a client can display envelope information
186 and implement commands such as REPLY without having any understanding
187 of how to parse RFC 822, etc. headers. The effect of this is
188 twofold: it further improves the ability to scale well in instances
189 where network traffic must be reduced, and it reduces the complexity
190 of the client program.
192 Additionally, IMAP2 offers several facilities for managing individual
193 message state and the mailbox as a whole beyond the simple "delete
194 message" functionality of POP. Another benefit of IMAP2 is the use
195 of tagged responses to reduce the possibility of synchronization
196 errors and the concept of state on the client (a "local cache") that
197 the server may update without explicit request by the client. These
198 concepts and how they are used are explained under "Implementation
201 In spite of this functional richness, IMAP2 is a small protocol.
202 Although servers should implement the full set of IMAP2 functions, a
203 simple client can be written that uses IMAP2 in much the way as a POP
206 A related protocol to POP and IMAP2 is the DMSP protocol of PCMAIL
207 (RFC 1056). IMAP2 differs from DMSP more fundamentally, reflecting a
208 differing architecture from PCMAIL. PCMAIL is either an online
209 ("interactive mode"), or offline ("batch mode") system with long-term
210 shared state. Some POP based systems are also offline; in such
211 systems, since there is no long-term shared state POP is little more
212 than a download mechanism of the "mail file" to the client. IMAP2-
213 based software is primarily an online system in which real-time and
214 simultaneous mail access were considered important.
216 In PCMAIL, there is a long-term client/server relationship in which
217 some mailbox state is preserved on the client. There is a
218 registration of clients used by a particular user, and the client
219 keeps a set of "descriptors" for each message that summarize the
220 message. The server and client synchronize their states when the
221 DMSP connection starts up, and, if a client has not accessed the
222 server for a while, the client does a complete reset (reload) of its
228 RFC 1176 IMAP2 August 1990
231 state from the server.
233 In IMAP2-based software, the client/server relationship lasts only
234 for the duration of the TCP connection. All mailbox state is
235 maintained on the server. There is no registration of clients. The
236 function of a descriptor is handled by a structured representation of
237 the message "envelope" as noted above. There is no client/server
238 synchronization since the client does not remember state between
239 IMAP2 connections. This is not a problem since in general the client
240 never needs the entire state of the mailbox in a single session,
241 therefore there isn't much overhead in fetching the state information
242 that is needed as it is needed.
244 There are also some functional differences between IMAP2 and DMSP.
245 DMSP has functions for sending messages, printing messages, listing
246 mailboxes, and changing passwords; these are done outside IMAP2.
247 DMSP has 16 binary flags of which 8 are defined by the system. IMAP2
248 has flag names; there are currently 5 defined system flag names and a
249 facility for some number (30 in the current implementations) of user
250 flag names. IMAP2 has a sophisticated message search facility in the
251 server to identify interesting messages based on dates, addresses,
252 flag status, or textual contents without compelling the client to
253 fetch this data for every message.
255 It was felt that maintaining state on the client is advantageous only
256 in those cases where the client is only used by a single user, or if
257 there is some means on the client to restrict access to another
258 user's data. It can be a serious disadvantage in an environment in
259 which multiple users routinely use the same client, the same user
260 routinely uses different clients, and where there are no access
261 restrictions on the client. It was also observed that most user mail
262 access is to a small set of "interesting" messages, which were either
263 new mail or mail based on some user-selected criteria. Consequently,
264 IMAP2 was designed to easily identify those "interesting" messages so
265 that the client could fetch the state of those messages and not those
266 that were not "interesting".
270 The IMAP2 protocol consists of a sequence of client commands and
271 server responses, with server data interspersed between the
272 responses. Unlike most Internet protocols, commands and responses
273 are tagged. That is, a command begins with a unique identifier
274 (typically a short alphanumeric sequence such as a Lisp "gensym"
275 function would generate e.g., A0001, A0002, etc.), called a tag. The
276 response to this command is given the same tag from the server.
277 Additionally, the server may send an arbitrary amount of "unsolicited
278 data", which is identified by the special reserved tag of "*". There
284 RFC 1176 IMAP2 August 1990
287 is another special reserved tag, "+", discussed below.
289 The server must be listening for a connection. When a connection is
290 opened the server sends an unsolicited OK response as a greeting
291 message and then waits for commands.
293 The client opens a connection and waits for the greeting. The client
294 must not send any commands until it has received the greeting from
297 Once the greeting has been received, the client may begin sending
298 commands and is not under any obligation to wait for a server
299 response to this command before sending another command, within the
300 constraints of TCP flow control. When commands are received the
301 server acts on them and responds with command responses, often
302 interspersed with data. The effect of a command can not be
303 considered complete until a command response with a tag matching the
304 command is received from the server.
306 Although all known IMAP2 servers at the time of this writing process
307 commands to completion before processing the next command, it is not
308 required that a server do so. However, many commands can affect the
309 results of other commands, creating processing-order dependencies
310 (or, for SEARCH and FIND, ambiguities about which data is associated
311 with which command). All implementations that operate in a non-
312 lockstep fashion must recognize such dependencies and defer or
313 synchronize execution as necessary. In general, such multi-
314 processing is limited to consecutive FETCH commands.
316 Generally, the first command from the client is a LOGIN command with
317 user name and password arguments to establish identity and access
318 authorization, unless this has already been accomplished through
319 other means, e.g. Kerberos. Until identity and access authorization
320 have been established, no operations other than LOGIN or LOGOUT are
323 Once identity and authorization have been established, the client
324 must send a SELECT command to access the desired mailbox; no mailbox
325 is selected by default. SELECT's argument is implementation-
326 dependent; however the word "INBOX" must be implemented to mean the
327 primary or default mailbox for this user, independent of any other
328 server semantics. On a successful SELECT, the server will send a
329 list of valid flags, number of messages, and number of messages
330 arrived since last access for this mailbox as unsolicited data,
331 followed by an OK response. The client may terminate access to this
332 mailbox and access a different one with another SELECT command.
334 The client reads mailbox information with FETCH commands. The actual
340 RFC 1176 IMAP2 August 1990
343 data is transmitted via the unsolicited data mechanism (that is,
344 FETCH should be viewed as instructing the server to include the
345 desired data along with any other data it wishes to transmit to the
346 client). There are three major categories of data that may be
349 The first category is data that is associated with a message as an
350 entity in the mailbox. There are now three such items of data: the
351 "internal date", the "RFC 822 size", and the "flags". The internal
352 date is the date and time that the message was placed in the mailbox.
353 The RFC 822 size is subject to deletion in the future; it is the size
354 in bytes of the message, expressed as an RFC 822 text string.
355 Current clients only use it as part of a status display line. The
356 flags are a list of status flags associated with the message (see
357 below). All the first category data can be fetched by using the
358 macro-fetch word "FAST"; that is, "FAST" expands to "(FLAGS
359 INTERNALDATE RFC822.SIZE)".
361 The second category is that data that describes the composition and
362 delivery information of a message; that is, information such as the
363 message sender, recipient lists, message-ID, subject, etc. This is
364 the information that is stored in the message header in RFC 822
365 format message and is traditionally called the "envelope". [Note:
366 this should not be confused with the SMTP (RFC 821) envelope, which
367 is strictly limited to delivery information.] IMAP2 defines a
368 structured and unambiguous representation for the envelope that is
369 particularly suited for Lisp-based parsers. A client can use the
370 envelope for operations such as replying and not worry about RFC 822
371 at all. Envelopes are discussed in more detail below. The first two
372 categories of data can be fetched together by using the macro-fetch
373 word "ALL"; that is, "ALL" expands to "(FLAGS INTERNALDATE
374 RFC822.SIZE ENVELOPE)".
376 The third category is that data that is intended for direct human
377 viewing. The present RFC 822 based IMAP2 defines three such items:
378 RFC822.HEADER, RFC822.TEXT, and RFC822 (the latter being the two
379 former appended together in a single text string). RFC822.HEADER is
380 the "raw", unprocessed RFC 822 format header of the message.
381 Fetching "RFC822" is equivalent to fetching the RFC 822
382 representation of the message as stored on the mailbox without any
383 filtering or processing.
385 An intelligent client will "FETCH ALL" for some (or all) of the
386 messages in the mailbox for use as a presentation menu, and when the
387 user wishes to read a particular message will "FETCH RFC822.TEXT" to
388 get the message body. A more primitive client could, of course,
389 simply "FETCH RFC822" a`la POP-type functionality.
396 RFC 1176 IMAP2 August 1990
399 The client can alter certain data (currently only the flags) by a
400 STORE command. As an example, a message is deleted from a mailbox by
401 a STORE command that includes the \DELETED flag as a flag being set.
403 Other client operations include copying a message to another mailbox
404 (COPY command), permanently removing deleted messages (EXPUNGE
405 command), checking for new messages (CHECK command), and searching
406 for messages that match certain criteria (SEARCH command).
408 The client terminates the session with the LOGOUT command. The
409 server returns a "BYE" followed by an "OK".
415 {Wait for Connection}
416 {Open Connection} -->
417 <-- * OK IMAP2 Server Ready
419 A001 LOGIN Fred Secret -->
420 <-- A001 OK User Fred logged in
422 A002 SELECT INBOX -->
423 <-- * FLAGS (Meeting Notice \Answered
424 \Flagged \Deleted \Seen)
427 <-- A0002 OK Select complete
429 A003 FETCH 1:19 ALL -->
430 <-- * 1 Fetch (......)
432 <-- * 18 Fetch (......)
433 <-- * 19 Fetch (......)
434 <-- A003 OK Fetch complete
436 A004 FETCH 8 RFC822.TEXT -->
437 <-- * 8 Fetch (RFC822.TEXT {893}
438 ...893 characters of text...
440 <-- A004 OK Fetch complete
452 RFC 1176 IMAP2 August 1990
455 A005 STORE 8 +Flags \Deleted -->
456 <-- * 8 Store (Flags (\Deleted
458 <-- A005 OK Store complete
464 <-- A006 Expunge complete
467 <-- * BYE IMAP2 server quitting
468 <-- A007 OK Logout complete
469 {Close Connection} --><-- {Close connection}
473 The following terms are used in a meta-sense in the syntax
476 An ASCII-STRING is a sequence of arbitrary ASCII characters.
478 An ATOM is a sequence of ASCII characters delimited by SP or CRLF.
480 A CHARACTER is any ASCII character except """", "{", CR, LF, "%",
483 A CRLF is an ASCII carriage-return character followed immediately
484 by an ASCII linefeed character.
486 A NUMBER is a sequence of the ASCII characters that represent
487 decimal numerals ("0" through "9"), delimited by SP, CRLF, ",", or
490 A SP is the ASCII space character.
492 A TEXT_LINE is a human-readable sequence of ASCII characters up to
493 but not including a terminating CRLF.
495 A common field in the IMAP2 protocol is a STRING, which may be an
496 ATOM, QUOTED-STRING (a sequence of CHARACTERs inside double-quotes),
497 or a LITERAL. A literal consists of an open brace ("{"), a number, a
498 close brace ("}"), a CRLF, and then an ASCII-STRING of n characters,
499 where n is the value of the number inside the brace. In general, a
500 string should be represented as an ATOM or QUOTED-STRING if at all
501 possible. The semantics for QUOTED-STRING or LITERAL are checked
502 before those for ATOM; therefore an ATOM used in a STRING may only
508 RFC 1176 IMAP2 August 1990
511 contain CHARACTERs. Literals are most often sent from the server to
512 the client; in the rare case of a client to server literal there is a
513 special consideration (see the "+ text" response below).
515 Another important field is the SEQUENCE, which identifies a set of
516 messages by consecutive numbers from 1 to n where n is the number of
517 messages in the mailbox. A sequence may consist of a single number,
518 a pair of numbers delimited by colon (equivalent to all numbers
519 between those two numbers), or a list of single numbers or number
520 pairs. For example, the sequence 2,4:7,9,12:15 is equivalent to
521 2,4,5,6,7,9,12,13,14,15 and identifies all those messages.
523 Definitions of Commands and Responses
525 Summary of Commands and Responses
527 Commands || Responses
529 tag NOOP || tag OK text
530 tag LOGIN user password || tag NO text
531 tag LOGOUT || tag BAD text
532 tag SELECT mailbox || * number message_data
533 tag BBOARD bulletin_board || * FLAGS flag_list
534 tag FIND MAILBOXES pattern || * SEARCH sequence
535 tag FIND BBOARDS pattern || * BBOARD string
536 tag CHECK || * MAILBOX string
537 tag EXPUNGE || * BYE text
538 tag COPY sequence mailbox || * OK text
539 tag FETCH sequence data || * NO text
540 tag STORE sequence data value || * BAD text
541 tag SEARCH search_program || + text
547 The NOOP command returns an OK to the client. By itself, it does
548 nothing, but certain things may happen as side effects. For
549 example, server implementations that implicitly check the mailbox
550 for new mail may do so as a result of this command. The primary
551 use of this command is to for the client to see if the server is
552 still alive (and notify the server that the client is still alive,
553 for those servers that have inactivity autologout timers).
555 tag LOGIN user password
557 The LOGIN command identifies the user to the server and carries
558 the password authenticating this user. This information is used
564 RFC 1176 IMAP2 August 1990
567 by the server to control access to the mailboxes.
569 EXAMPLE: A001 LOGIN SMITH SESAME
570 logs in as user SMITH with password SESAME.
574 The LOGOUT command informs the server that the client is done with
575 the session. The server should send an unsolicited BYE response
576 before the (tagged) OK response, and then close the network
581 The SELECT command selects a particular mailbox. The server must
582 check that the user is permitted read access to this mailbox.
583 Before returning an OK to the client, the server must send the
584 following unsolicited data to the client:
585 FLAGS mailbox's defined flags
586 <n> EXISTS the number of messages in the mailbox
587 <n> RECENT the number of new messages in the mailbox
588 in order to define the initial state of the mailbox at the client.
590 Multiple SELECT commands are permitted in a session, in which case
591 the previous mailbox is automatically deselected when a new SELECT
594 The default mailbox for the SELECT command is INBOX, which is a
595 special name reserved to mean "the primary mailbox for this user
596 on this server". The format of other mailbox names is operating
597 system dependent (as of this writing, it reflects the filename
598 path of the mailbox file on the current servers).
600 It is customary, although not required, for the text of an OK
601 response to the SELECT command to begin with either "[READ-ONLY]"
602 or "[READ-WRITE]" to show the mailbox's access status.
604 EXAMPLE: A002 SELECT INBOX
605 selects the default mailbox.
607 tag BBOARD bulletin_board
609 The BBOARD command is equivalent to SELECT, and returns the same
610 output. However, it differs from SELECT in that its argument is a
611 shared mailbox (bulletin board) name instead of an ordinary
612 mailbox. The format of a bulletin name is implementation
613 specific, although it is strongly encouraged to use something that
614 resembles a name in a generic sense and not a file or mailbox name
620 RFC 1176 IMAP2 August 1990
623 on the particular system. There is no requirement that a bulletin
624 board name be a mailbox name or a file name (in particular, Unix
625 netnews has a completely different namespace from mailbox or file
628 Support for BBOARD is optional.
630 tag FIND MAILBOXES pattern
632 The FIND MAILBOXES command accepts as an argument a pattern
633 (including wildcards) that specifies some set of mailbox names
634 that are usable by the SELECT command. The format of mailboxes is
635 implementation dependent. The special mailbox name INBOX is not
636 included in the output.
638 Two wildcard characters are defined; "*" specifies any number
639 (including zero) characters may match at this position and "%"
640 specifies a single character may match at this position. For
641 example, FOO*BAR will match FOOBAR, FOOD.ON.THE.BAR and FOO.BAR,
642 whereas FOO%BAR will match only FOO.BAR. "*" will match all
645 The FIND MAILBOXES command will return some set of unsolicited
646 MAILBOX replies that have as their value a single mailbox name.
648 EXAMPLE: A002 FIND MAILBOXES *
653 Although the use of explicit file or path names for mailboxes is
654 discouraged by this standard, it may be unavoidable. It is
655 important that the value returned in the MAILBOX unsolicited reply
656 be usable in the SELECT command without remembering any path
657 specification that may have been used in the FIND MAILBOXES
660 Support for FIND MAILBOXES is optional. If a client's attempt
661 returns BAD as a response then the client can make no assumptions
662 about what mailboxes exist on the server other than INBOX.
664 tag FIND BBOARDS pattern
666 The FIND BBOARDS command accepts as an argument a pattern that
667 specifies some set of bulletin board names that are usable by the
668 BBOARD command. Wildcards are permitted as in FIND MAILBOXES.
670 The FIND BBOARDS command will return some set of unsolicited
676 RFC 1176 IMAP2 August 1990
679 BBOARD replies that have as their value a single bulletin board
682 EXAMPLE: A002 FIND BBOARDS *
687 Support for FIND BBOARDS is optional. If a client's attempt
688 returns BAD as a response then the client can make no assumptions
689 about what bulletin boards exist on the server, or that they exist
694 The CHECK command forces a check for new messages and a rescan of
695 the mailbox for internal change for those implementations that
696 allow multiple simultaneous read/write access to the same mailbox.
697 It is recommend that periodic implicit checks for new mail be done
698 by servers as well. The server should send unsolicited EXISTS and
699 RECENT responses with the current status before returning an OK to
704 The EXPUNGE command permanently removes all messages with the
705 \DELETED flag set in its flags from the mailbox. Before returning
706 an OK to the client, for each message that is removed, an
707 unsolicited EXPUNGE response is sent. The message number for each
708 successive message in the mailbox is immediately decremented by 1;
709 this means that if the last 5 messages in a 9-message mail file
710 are expunged you will receive 5 unsolicited EXPUNGE responses for
711 message 5. To ensure mailbox integrity and server/client
712 synchronization, it is recommended that the server do an implicit
713 check before commencing the expunge and again when the expunge is
714 completed. Furthermore, if the server allows multiple
715 simultaneous access to the same mail file the server must lock the
716 mail file for exclusive access while an expunge is taking place.
718 EXPUNGE is not allowed if the user does not have write access to
721 tag COPY sequence mailbox
723 The COPY command copies the specified message(s) to the specified
724 destination mailbox. If the destination mailbox does not exist,
725 the server should create it. Before returning an OK to the
726 client, the server should return an unsolicited <n> COPY response
732 RFC 1176 IMAP2 August 1990
735 for each message copied. A copy should set the \SEEN flag for all
736 messages that were successfully copied (provided, of course, that
737 the user has write access to this mailbox).
739 EXAMPLE: A003 COPY 2:4 MEETING
740 copies messages 2, 3, and 4 to mailbox "MEETING".
742 COPY is not allowed if the user does not have write access to the
745 tag FETCH sequence data
747 The FETCH command retrieves data associated with a message in the
748 mailbox. The data items to be fetched may be either a single atom
749 or an S-expression list. The currently defined data items that
752 ALL Macro equivalent to:
753 (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)
755 ENVELOPE The envelope of the message. The envelope is
756 computed by the server by parsing the RFC 822
757 header into the component parts, defaulting
758 various fields as necessary.
760 FAST Macro equivalent to:
761 (FLAGS INTERNALDATE RFC822.SIZE)
763 FLAGS The flags that are set for this message.
764 This may include the following system flags:
766 \RECENT Message arrived since the
767 previous time this mailbox
769 \SEEN Message has been read
770 \ANSWERED Message has been answered
771 \FLAGGED Message is "flagged" for
772 urgent/special attention
773 \DELETED Message is "deleted" for
774 removal by later EXPUNGE
776 INTERNALDATE The date and time the message was written to
788 RFC 1176 IMAP2 August 1990
791 RFC822 The message in RFC 822 format. The \SEEN
792 flag is implicitly set; if this causes the
793 flags to change they should be included as
794 part of the fetch results. This is the
795 concatenation of RFC822.HEADER and RFC822.TEXT.
797 RFC822.HEADER The "raw" RFC 822 format header of the message
798 as stored on the server.
800 RFC822.SIZE The number of characters in the message as
801 expressed in RFC 822 format.
803 RFC822.TEXT The text body of the message, omitting the
804 RFC 822 header. The \SEEN flag is implicitly
805 set as with RFC822 above.
810 fetches the flags, internal date, RFC 822 size, and envelope
811 for messages 2, 3, and 4.
814 fetches the RFC 822 representation for message 3.
816 A005 FETCH 4 (FLAGS RFC822.HEADER)
817 fetches the flags and RFC 822 format header for message 4.
819 Note: An attempt to FETCH already-transmitted data may have no
820 result. See the Implementation Discussion below.
822 tag STORE sequence data value
824 The STORE command alters data associated with a message in the
825 mailbox. The currently defined data items that can be stored are:
827 FLAGS Replace the flags for the message with the
828 argument (in flag list format).
830 +FLAGS Add the flags in the argument to the
833 -FLAGS Remove the flags in the argument from the
836 STORE is not allowed if the user does not have write access to
844 RFC 1176 IMAP2 August 1990
847 EXAMPLE: A003 STORE 2:4 +FLAGS (\DELETED)
848 marks messages 2, 3, and 4 for deletion.
850 tag SEARCH search_criteria
852 The SEARCH command searches the mailbox for messages that match
853 the given set of criteria. The unsolicited SEARCH <1#number>
854 response from the server is a list of messages that express the
855 intersection (AND function) of all the messages which match that
856 criteria. For example,
857 A003 SEARCH DELETED FROM "SMITH" SINCE 1-OCT-87
858 returns the message numbers for all deleted messages from Smith
859 that were placed in the mail file since October 1, 1987.
861 In all search criteria which use strings, a message matches the
862 criteria if the string is a case-independent substring of that
863 field. The currently defined criteria are:
865 ALL All messages in the mailbox; the default
866 initial criterion for ANDing.
868 ANSWERED Messages with the \ANSWERED flag set.
870 BCC string Messages which contain the specified string
871 in the envelope's BCC field.
873 BEFORE date Messages whose internal date is earlier than
876 BODY string Messages which contain the specified string
877 in the body of the message.
879 CC string Messages which contain the specified string
880 in the envelope's CC field.
882 DELETED Messages with the \DELETED flag set.
884 FLAGGED Messages with the \FLAGGED flag set.
886 FROM string Messages which contain the specified string
887 in the envelope's FROM field.
889 KEYWORD flag Messages with the specified flag set.
891 NEW Messages which have the \RECENT flag set but
892 not the \SEEN flag. This is functionally
893 equivalent to "RECENT UNSEEN".
900 RFC 1176 IMAP2 August 1990
903 OLD Messages which do not have the \RECENT flag
906 ON date Messages whose internal date is the same as
909 RECENT Messages which have the \RECENT flag set.
911 SEEN Messages which have the \SEEN flag set.
913 SINCE date Messages whose internal date is later than
916 SUBJECT string Messages which contain the specified string
917 in the envelope's SUBJECT field.
919 TEXT string Messages which contain the specified string.
921 TO string Messages which contain the specified string in
922 the envelope's TO field.
924 UNANSWERED Messages which do not have the \ANSWERED flag
927 UNDELETED Messages which do not have the \DELETED flag
930 UNFLAGGED Messages which do not have the \FLAGGED flag
933 UNKEYWORD flag Messages which do not have the specified flag
936 UNSEEN Messages which do not have the \SEEN flag set.
956 RFC 1176 IMAP2 August 1990
963 This response identifies successful completion of the command with
964 that tag. The text is a line of human-readable text that may be
965 useful in a protocol telemetry log for debugging purposes.
969 This response identifies unsuccessful completion of the command
970 with that tag. The text is a line of human-readable text that
971 probably should be displayed to the user in an error report by the
976 This response identifies faulty protocol received from the client;
977 The text is a line of human-readable text that should be recorded
978 in any telemetry as part of a bug report to the maintainer of the
981 * number message_data
983 This response occurs as a result of several different commands.
984 The message_data is one of the following:
986 EXISTS The specified number of messages exists in the mailbox.
988 RECENT The specified number of messages have arrived since the
989 previous time this mailbox was read.
991 EXPUNGE The specified message number has been permanently
992 removed from the mailbox, and the next message in the
993 mailbox (if any) becomes that message number.
996 Obsolete and functionally equivalent to FETCH.
999 This is the principle means by which data about a
1000 message is returned to the client. The data is in a
1001 Lisp-like S-expression property list form. The current
1004 ENVELOPE An S-expression format list that describes the
1005 envelope of a message. The envelope is computed
1006 by the server by parsing the RFC 822 header into
1012 RFC 1176 IMAP2 August 1990
1015 the component parts, defaulting various fields
1018 The fields of the envelope are in the following
1019 order: date, subject, from, sender, reply-to, to,
1020 cc, bcc, in-reply-to, and message-id. The date,
1021 subject, in-reply-to, and message-id fields are
1022 strings. The from, sender, reply-to, to, cc,
1023 and bcc fields are lists of addresses.
1025 An address is an S-expression format list that
1026 describes an electronic mail address. The fields
1027 of an address are in the following order:
1028 personal name, source-route (a.k.a. the
1029 at-domain-list in SMTP), mailbox name, and
1032 Any field of an envelope or address that is
1033 not applicable is presented as the atom NIL.
1034 Note that the server must default the reply-to
1035 and sender fields from the from field; a client is
1036 not expected to know to do this.
1038 FLAGS An S-expression format list of flags that are set
1039 for this message. This may include the following
1042 \RECENT Message arrived since the
1043 previous time this mailbox
1045 \SEEN Message has been read
1046 \ANSWERED Message has been answered
1047 \FLAGGED Message is "flagged" for
1048 urgent/special attention
1049 \DELETED Message is "deleted" for
1050 removal by later EXPUNGE
1052 INTERNALDATE A string containing the date and time the
1053 message was written to the mailbox.
1055 RFC822 A string expressing the message in RFC 822
1058 RFC822.HEADER A string expressing the RFC 822 format
1059 header of the message
1061 RFC822.SIZE A number indicating the number of
1062 characters in the message as expressed
1068 RFC 1176 IMAP2 August 1990
1073 RFC822.TEXT A string expressing the text body of the
1074 message, omitting the RFC 822 header.
1078 This response occurs as a result of a SELECT command. The flag
1079 list are the list of flags (at a minimum, the system-defined
1080 flags) that are applicable for this mailbox. Flags other than the
1081 system flags are a function of the server implementation.
1085 This response occurs as a result of a SEARCH command. The
1086 number(s) refer to those messages that match the search criteria.
1087 Each number is delimited by a space, e.g., "SEARCH 2 3 6".
1091 This response occurs as a result of a FIND BBOARDS command. The
1092 string is a bulletin board name that matches the pattern in the
1097 This response occurs as a result of a FIND MAILBOXES command. The
1098 string is a mailbox name that matches the pattern in the command.
1102 This response identifies that the server is about to close the
1103 connection. The text is a line of human-readable text that should
1104 be displayed to the user in a status report by the client. This
1105 may be sent as part of a normal logout sequence, or as a panic
1106 shutdown announcement by the server. It is also used by some
1107 servers as an announcement of an inactivity autologout.
1111 This response identifies normal operation on the server. No
1112 special action by the client is called for, however, the text
1113 should be displayed to the user in some fashion. This is
1114 currently only used by servers at startup as a greeting message to
1115 show they are ready to accept the first command.
1124 RFC 1176 IMAP2 August 1990
1129 This response identifies a warning from the server that does not
1130 affect the overall results of any particular request. The text is
1131 a line of human-readable text that should be presented to the user
1132 as a warning of improper operation.
1136 This response identifies a serious error at the server; it may
1137 also indicate faulty protocol from the client in which a tag could
1138 not be parsed. The text is a line of human-readable text that
1139 should be presented to the user as a serious or possibly fatal
1140 error. It should also be recorded in any telemetry as part of a
1141 bug report to the maintainer of the client and server.
1145 This response identifies that the server is ready to accept the
1146 text of a literal from the client. Normally, a command from the
1147 client is a single text line. If the server detects an error in
1148 the command, it can simply discard the remainder of the line. It
1149 cannot do this for commands that contain literals, since a literal
1150 can be an arbitrarily long amount of text, and the server may not
1151 even be expecting a literal. This mechanism is provided so the
1152 client knows not to send a literal until the server expects it,
1153 preserving client/server synchronization.
1155 In practice, this condition is rarely encountered. In the current
1156 protocol, the only client command likely to contain a literal is
1157 the LOGIN command. Consider a server that validates the user
1158 before checking the password. If the password contains "funny"
1159 characters and hence is sent as a literal, then if the user is
1160 invalid an error would occur before the password is parsed.
1162 No such synchronization protection is provided for literals sent
1163 from the server to the client, for performance reasons. Any
1164 synchronization problems in this direction would be caused by a
1165 bug in the client or server.
1180 RFC 1176 IMAP2 August 1990
1183 Sample IMAP2 session
1185 The following is a transcript of an IMAP2 session. Server output is
1186 identified by "S:" and client output by "U:". In cases where lines
1187 are too long to fit within the boundaries of this document, the line
1188 is continued on the next line.
1190 S: * OK SUMEX-AIM.Stanford.EDU Interim Mail Access Protocol II Service
1191 6.1(349) at Thu, 9 Jun 88 14:58:30 PDT
1192 U: a001 login crispin secret
1193 S: a002 OK User CRISPIN logged in at Thu, 9 Jun 88 14:58:42 PDT, job 76
1194 U: a002 select inbox
1195 S: * FLAGS (Bugs SF Party Skating Meeting Flames Request AI Question
1196 Note \XXXX \YYYY \Answered \Flagged \Deleted \Seen)
1199 S: a002 OK Select complete
1200 U: a003 fetch 16 all
1201 S: * 16 Fetch (Flags (\Seen) InternalDate " 9-Jun-88 12:55:44 PDT"
1202 RFC822.Size 637 Envelope ("Sat, 4 Jun 88 13:27:11 PDT"
1203 "INFO-MAC Mail Message" (("Larry Fagan" NIL "FAGAN"
1204 "SUMEX-AIM.Stanford.EDU")) (("Larry Fagan" NIL "FAGAN"
1205 "SUMEX-AIM.Stanford.EDU")) (("Larry Fagan" NIL "FAGAN"
1206 "SUMEX-AIM.Stanford.EDU")) ((NIL NIL "rindflEISCH"
1207 "SUMEX-AIM.Stanford.EDU")) NIL NIL NIL
1208 "<12403828905.13.FAGAN@SUMEX-AIM.Stanford.EDU>"))
1209 S: a003 OK Fetch completed
1210 U: a004 fetch 16 rfc822
1211 S: * 16 Fetch (RFC822 {637}
1212 S: Mail-From: RINDFLEISCH created at 9-Jun-88 12:55:43
1213 S: Mail-From: FAGAN created at 4-Jun-88 13:27:12
1214 S: Date: Sat, 4 Jun 88 13:27:11 PDT
1215 S: From: Larry Fagan <FAGAN@SUMEX-AIM.Stanford.EDU>
1216 S: To: rindflEISCH@SUMEX-AIM.Stanford.EDU
1217 S: Subject: INFO-MAC Mail Message
1218 S: Message-ID: <12403828905.13.FAGAN@SUMEX-AIM.Stanford.EDU>
1219 S: ReSent-Date: Thu, 9 Jun 88 12:55:43 PDT
1220 S: ReSent-From: TC Rindfleisch <Rindfleisch@SUMEX-AIM.Stanford.EDU>
1221 S: ReSent-To: Yeager@SUMEX-AIM.Stanford.EDU,
1222 Crispin@SUMEX-AIM.Stanford.EDU
1223 S: ReSent-Message-ID:
1224 <12405133897.80.RINDFLEISCH@SUMEX-AIM.Stanford.EDU>
1226 S: The file is <info-mac>usenetv4-55.arc ...
1230 S: a004 OK Fetch completed
1236 RFC 1176 IMAP2 August 1990
1240 S: * BYE DEC-20 IMAP II server terminating connection
1241 S: a005 OK SUMEX-AIM.Stanford.EDU Interim Mail Access Protocol
1292 RFC 1176 IMAP2 August 1990
1295 Implementation Discussion
1297 There are several advantages to the scheme of tags and unsolicited
1298 responses. First, the infamous synchronization problems of SMTP and
1299 similar protocols do not happen with tagged commands; a command is
1300 not considered satisfied until a response with the same tag is seen.
1301 Tagging allows an arbitrary amount of other responses ("unsolicited"
1302 data) to be sent by the server with no possibility of the client
1303 losing synchronization. Compare this with the problems that FTP or
1304 SMTP clients have with continuation, partial completion, and
1305 commentary reply codes.
1307 Another advantage is that a non-lockstep client implementation is
1308 possible. The client could send a command, and entrust the handling
1309 of the server responses to a different process that would signal the
1310 client when the tagged response comes in. Under certain
1311 circumstances, the client may have more than one command outstanding.
1313 It was observed that synchronization problems can occur with literals
1314 if the literal is not recognized as such. Fortunately, the cases in
1315 which this can happen are rare; a mechanism (the special "+" tag
1316 response) was introduced to handle those few cases. The proper way
1317 to address this problem is probably to move towards a record-oriented
1318 architecture instead of the text stream model provided by TCP.
1320 An IMAP2 client must maintain a local cache of data from the mailbox.
1321 This cache is an incomplete model of the mailbox, and at startup is
1322 empty. A listener processes all unsolicited data, and updates the
1323 cache based on this data. If a tagged response arrives, the listener
1324 unblocks the process that sent the tagged request.
1326 Unsolicited data needs some discussion. Unlike most protocols, in
1327 which the server merely does the client's bidding, an IMAP2 server
1328 has a semi-autonomous role. By sending "unsolicited data", the
1329 server is in effect sending a command to the client -- to update or
1330 extend the client's cache with new information from the server. In
1331 other words, a "fetch" command is merely a request to the server to
1332 ensure that the client's cache has the most up-to-date version of the
1333 requested information. A server acknowledgement to the "fetch" is a
1334 statement that all the requested data has been sent.
1336 Although no current server does this, a server is not obliged by the
1337 protocol to send data that it has already sent and is unchanged. An
1338 exception to this is the actual message text fetching operations
1339 (RFC822, RFC822.HEADER, and RFC822.TEXT), owing to the possibly
1340 excessive resource consumption of maintaining this data in a cache.
1341 It can not be assumed that a FETCH will transmit any data; only that
1342 an OK to the FETCH means that the client's cache has the most up-to-
1348 RFC 1176 IMAP2 August 1990
1353 When a mailbox is selected, the initial unsolicited data from the
1354 server arrives. The first piece of data is the number of messages.
1355 By sending a new EXISTS unsolicited data message the server causes
1356 the client to resize its cache (this is how newly arrived mail is
1357 handled). If the client attempts to access information from the
1358 cache, it will encounter empty spots that will trigger "fetch"
1359 requests. The request would be sent, some unsolicited data including
1360 the answer to the fetch will flow back, and then the "fetch" response
1361 will unblock the client.
1363 People familiar with demand-paged virtual memory operating system
1364 design will recognize this model as being similar to page-fault
1365 handling on a demand-paged system.
1404 RFC 1176 IMAP2 August 1990
1409 The following syntax specification uses the augmented Backus-Naur
1410 Form (BNF) notation as specified in RFC 822 with one exception; the
1411 delimiter used with the "#" construct is a single space (SP) and not
1414 address ::= "(" addr_name SP addr_adl SP addr_mailbox SP
1417 addr_adl ::= nil / string
1419 addr_host ::= nil / string
1421 addr_mailbox ::= nil / string
1423 addr_name ::= nil / string
1425 bboard ::= "BBOARD" SP string
1429 copy ::= "COPY" SP sequence SP mailbox
1431 data ::= ("FLAGS" SP flag_list / "SEARCH" SP 1#number /
1432 "BYE" SP text_line / "OK" SP text_line /
1433 "NO" SP text_line / "BAD" SP text_line)
1435 date ::= string in form "dd-mmm-yy hh:mm:ss-zzz"
1437 envelope ::= "(" env_date SP env_subject SP env_from SP
1438 env_sender SP env_reply-to SP env_to SP
1439 env_cc SP env_bcc SP env_in-reply-to SP
1442 env_bcc ::= nil / "(" 1*address ")"
1444 env_cc ::= nil / "(" 1*address ")"
1448 env_from ::= nil / "(" 1*address ")"
1450 env_in-reply-to ::= nil / string
1452 env_message-id ::= nil / string
1454 env_reply-to ::= nil / "(" 1*address ")"
1460 RFC 1176 IMAP2 August 1990
1463 env_sender ::= nil / "(" 1*address ")"
1465 env_subject ::= nil / string
1467 env_to ::= nil / "(" 1*address ")"
1469 expunge ::= "EXPUNGE"
1471 fetch ::= "FETCH" SP sequence SP ("ALL" / "FAST" /
1472 fetch_att / "(" 1#fetch_att ")")
1474 fetch_att ::= "ENVELOPE" / "FLAGS" / "INTERNALDATE" /
1475 "RFC822" / "RFC822.HEADER" / "RFC822.SIZE" /
1478 find ::= "FIND" SP find_option SP string
1480 find_option ::= "MAILBOXES" / "BBOARDS"
1482 flag_list ::= ATOM / "(" 1#ATOM ")"
1484 literal ::= "{" NUMBER "}" CRLF ASCII-STRING
1486 login ::= "LOGIN" SP userid SP password
1490 mailbox ::= "INBOX" / string
1494 msg_data ::= (msg_exists / msg_recent / msg_expunge /
1495 msg_fetch / msg_copy)
1497 msg_exists ::= "EXISTS"
1499 msg_expunge ::= "EXPUNGE"
1501 msg_fetch ::= ("FETCH" / "STORE") SP "(" 1#("ENVELOPE" SP
1502 envelope / "FLAGS" SP "(" 1#(recent_flag
1503 flag_list) ")" / "INTERNALDATE" SP date /
1504 "RFC822" SP string / "RFC822.HEADER" SP string /
1505 "RFC822.SIZE" SP NUMBER / "RFC822.TEXT" SP
1508 msg_recent ::= "RECENT"
1516 RFC 1176 IMAP2 August 1990
1525 recent_flag ::= "\RECENT"
1527 ready ::= "+" SP text_line
1529 request ::= tag SP (noop / login / logout / select / check /
1530 expunge / copy / fetch / store / search / find /
1533 response ::= tag SP ("OK" / "NO" / "BAD") SP text_line CRLF
1535 search ::= "SEARCH" SP 1#("ALL" / "ANSWERED" /
1536 "BCC" SP string / "BEFORE" SP string /
1537 "BODY" SP string / "CC" SP string / "DELETED" /
1538 "FLAGGED" / "KEYWORD" SP atom / "NEW" / "OLD" /
1539 "ON" SP string / "RECENT" / "SEEN" /
1540 "SINCE" SP string / "TEXT" SP string /
1541 "TO" SP string / "UNANSWERED" / "UNDELETED" /
1542 "UNFLAGGED" / "UNKEYWORD" / "UNSEEN")
1544 select ::= "SELECT" SP mailbox
1546 sequence ::= NUMBER / (NUMBER "," sequence) / (NUMBER ":"
1549 store ::= "STORE" SP sequence SP store_att
1551 store_att ::= ("+FLAGS" SP flag_list / "-FLAGS" SP flag_list /
1552 "FLAGS" SP flag_list)
1554 string ::= atom / """" 1*character """" / literal
1556 system_flags ::= "\ANSWERED" SP "\FLAGGED" SP "\DELETED" SP
1561 unsolicited ::= "*" SP (msg_num SP msg_data / data) CRLF
1572 RFC 1176 IMAP2 August 1990
1575 Implementation Status
1577 This information is current as of this writing.
1579 The University of Washington has developed an electronic mail client
1580 library called the "C-Client". It provides complete IMAP2, SMTP, and
1581 local mailbox (both /usr/spool/mail and mail.txt formats) services in
1582 a well-defined way to a user interface main program. Using the C-
1583 Client, the University of Washington has created an operational
1584 client for BSD Unix and two operational clients (one basic, one
1585 advanced) for the NeXT.
1587 Stanford University/SUMEX has developed operational IMAP2 clients for
1588 Xerox Lisp machines, Texas Instruments Explorers, and the Apple
1589 Macintosh. The core of the Macintosh client is an early version of
1590 the C-Client. SUMEX has also developed IMAP2 servers for TOPS-20 and
1593 All of the above software is in production use, with enthusiastic
1594 local user communities. Active development continues on the
1595 Macintosh and C-Client based clients and the BSD Unix server. This
1596 software is freely available from the University of Washington and
1599 IMAP2 software exists for other platforms; for example Nippon
1600 Telephone and Telegraph (NTT) has developed an operational IMAP2
1601 client for the NTT ELIS. Several organizations are working on a PC
1604 IMAP2 can be used to access mailboxes at very remote sites, where
1605 echo delays and frequent outages make TELNET and running a local mail
1606 reader intolerable. For example, from a desktop workstation on the
1607 University of Washington local network the author routinely uses
1608 IMAP2 to read and manage mailboxes on various University of
1609 Washington local servers, at two systems at Stanford University, at a
1610 Milnet site, and at a site in Tokyo, Japan.
1612 This specification does not make any formal definition of size
1613 restrictions, but the DEC-20 server has the following limitations:
1615 . length of a mailbox: 7,077,888 characters
1616 . maximum number of messages: 18,432 messages
1617 . length of a command line: 10,000 characters
1618 . length of the local host name: 64 characters
1619 . length of a "short" argument: 39 characters
1620 . length of a "long" argument: 491,520 characters
1621 . maximum amount of data output in a single fetch:
1628 RFC 1176 IMAP2 August 1990
1631 To date, nobody has run up against any of these limitations, many of
1632 which are substantially larger than most current user mail reading
1637 Bill Yeager and Rich Acuff both contributed invaluable suggestions in
1638 the evolution of IMAP2 from the original IMAP. James Rice pointed
1639 out several ambiguities in the previous IMAP2 specification and
1640 otherwise would not allow me to leave bad enough along. Laurence
1641 Lundblade reviewed a draft of this version and made several helpful
1644 Many dedicated individuals have worked on IMAP2 software, including:
1645 Mark Crispin, Frank Gilmurray, Christopher Lane, Hiroshi Okuno,
1646 Christopher Schmidt, and Bill Yeager.
1648 Any mistakes, flaws, or sins of omission in this IMAP2 protocol
1649 specification are, however, strictly my own; and the mention of any
1650 name above does not imply an endorsement.
1652 Security Considerations
1654 Security issues are not discussed in this memo.
1661 Bainbridge Island, WA 98110-2020
1663 Phone: (206) 842-2385
1665 EMail: mrc@Tomobiki-Cho.CAC.Washington.EDU