rfc1064.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                         M. Crispin
Request for Comments: 1064                                     SUMEX-AIM
                                                               July 1988

              INTERACTIVE MAIL ACCESS PROTOCOL - VERSION 2


Status of this Memo

   This RFC suggests a method for workstations to dynamically access
   mail from a mailbox server ("repository").  This RFC specifies a
   standard for the SUMEX-AIM community and a proposed experimental
   protocol for the Internet community.  Discussion and suggestions for
   improvement are requested.  Distribution of this memo is unlimited.

Introduction

   The intent of the Interactive Mail Access Protocol, Version 2 (IMAP2)
   is to allow a workstation or similar small machine to access
   electronic mail from a mailbox server.  IMAP2 is the protocol used by
   the SUMEX-AIM MM-D (MM Distributed) mail system.

   Although different in many ways from POP2 (RFC 937), IMAP2 may be
   thought of as a functional superset of POP2, and the POP2 RFC was
   used as a model for this RFC.  There was a cognizant reason for this;
   RFC 937 deals with an identical problem and it was desirable to offer
   a basis for comparison.

   Like POP2, IMAP2 specifies a means of accessing stored mail and not
   of posting mail; this function is handled by a mail transfer protocol
   such as SMTP (RFC 821).  A comparison with the DMSP protocol of
   PCMAIL can be found at the end of "System Model and Philosophy"
   section.

   This protocol assumes a reliable data stream such as provided by TCP
   or any similar protocol.  When TCP is used, the IMAP2 server listens
   on port 143.

System Model and Philosophy

   Electronic mail is a primary means of communication for the widely
   spread SUMEX-AIM community.  The advent of distributed workstations
   is forcing a significant rethinking of the mechanisms employed to
   manage such mail.  With mainframes, each user tends to receive and
   process mail at the computer he used most of the time, his "primary
   host".  The first inclination of many users when an independent
   workstation is placed in front of them is to begin receiving mail at
   the workstation, and, in fact, many vendors have implemented



Crispin                                                         [Page 1]

RFC 1064                         IMAP2                         July 1988


   facilities to do this.  However, this approach has several
   disadvantages:

      (1) Workstations (especially Lisp workstations) have a software
      design that gives full control of all aspects of the system to the
      user at the console.  As a result, background tasks, like
      receiving mail, could well be kept from running for long periods
      of time either because the user is asking to use all of the
      machine's resources, or because, in the course of working, the
      user has (perhaps accidentally) manipulated the environment in
      such a way as to prevent mail reception.  This could lead to
      repeated failed delivery attempts by outside agents.

      (2) The hardware failure of a single workstation could keep its
      user "off the air" for a considerable time, since repair of
      individual workstation units might be delayed.  Given the growing
      number of workstations spread throughout office environments,
      quick repair would not be assured, whereas a centralized mainframe
      is generally repaired very soon after failure.

      (3) It is more difficult to keep track of mailing addresses when
      each person is associated with a distinct machine.  Consider the
      difficulty in keeping track of a large number of postal addresses
      or phone numbers, particularly if there was no single address or
      phone number for an organization through which you could reach any
      person in that organization.  Traditionally, electronic mail on
      the ARPANET involved remembering a name and one of several "hosts"
      (machines) whose name reflected the organization in which the
      individual worked.  This was suitable at a time when most
      organizations had only one central host.  It is less satisfactory
      today unless the concept of a host is changed to refer to an
      organizational entity and not a particular machine.

      (4)  It is very difficult to keep a multitude of heterogeneous
      workstations working properly with complex mailing protocols,
      making it difficult to move forward as progress is made in
      electronic communication and as new standards emerge.  Each system
      has to worry about receiving incoming mail, routing and delivering
      outgoing mail, formatting, storing, and providing for the
      stability of mailboxes over a variety of possible filing and
      mailing protocols.

   Consequently, while the workstation may be viewed as an Internet host
   in the sense that it implements IP, it should not be viewed as the
   entity which contains the user's mailbox.  Rather, a mail server
   machine (sometimes called a "repository") should hold the mailbox,
   and the workstation (hereafter referred to as a "client") should
   access the mailbox via mail transactions.  Because the mail server



Crispin                                                         [Page 2]

RFC 1064                         IMAP2                         July 1988


   machine would be isolated from direct user manipulation, it could
   achieve high software reliability easily, and, as a shared resource,
   it could achieve high hardware reliability, perhaps through
   redundancy.  The mail server could be used from arbitrary locations,
   allowing users to read mail across campus, town, or country using
   more and more commonly available clients.  Furthermore, the same user
   may access his mailbox from different clients at different times, and
   multiple users may access the same mailbox simultaneously.

   The mail server acts an an interface among users, data storage, and
   other mailers.  The mail access protocol is used to retrieve
   messages, access and change properties of messages, and manage
   mailboxes.  This differs from some approaches (e.g., Unix mail via
   NFS) in that the mail access protocol is used for all message
   manipulations, isolating the user and the client from all knowledge
   of how the data storage is used.  This means that the mail server can
   utilize the data storage in whatever way is most efficient to
   organize the mail in that particular environment, without having to
   worry about storage representation compatibility across different
   machines.

   In defining a mail access protocol, it is important to keep in mind
   that the client and server form a macrosystem, in which it should be
   possible to exploit the strong points of both while compensating for
   each other's weaknesses.  Furthermore, it's desirable to allow for a
   growth path beyond the hoary text-only RFC 822 protocol.  Unlike
   POP2, IMAP2 has extensive features for remote searching and parsing
   of messages on the server.  For example, a free text search
   (optionally in conjunction with other searching) can be made
   throughout the entire mailbox by the server and the results made
   available to the client without the client having to transfer the
   entire mailbox and searching itself.  Since remote parsing of a
   message into a structured (and standard format) "envelope" is
   available, a client can display envelope information and implement
   commands such as REPLY without having any understanding of how to
   parse RFC 822, etc. headers.

   Additionally, IMAP2 offers several facilities for managing a mailbox
   beyond the simple "delete message" functionality of POP2.

   In spite of this, IMAP2 is a relatively simple protocol.  Although
   servers should implement the full set of IMAP2 functions, a simple
   client can be written which uses IMAP2 in much the way as a POP2
   client.

   IMAP2 differs from the DMSP protocol of PCMAIL (RFC 1056) in a more
   fundamental manner, reflecting the differing architectures of MM-D
   and PCMAIL.  PCMAIL is either an online ("interactive mode"), or



Crispin                                                         [Page 3]

RFC 1064                         IMAP2                         July 1988


   offline ("batch mode") system.  MM-D is primarily an online system in
   which real-time and simultaneous mail access were considered
   important.

   In PCMAIL, there is a long-term client/server relationship in which
   some mailbox state is preserved on the client.  There is a
   registration of clients used by a particular user, and the client
   keeps a set of "descriptors" for each message which summarize the
   message.  The server and client synchronize their states when the
   DMSP connection starts up, and, if a client has not accessed the
   server for a while, the client does a complete reset (reload) of its
   state from the server.

   In MM-D, the client/server relationship lasts only for the duration
   of the IMAP2 connection.  All mailbox state is maintained on the
   server.  There is no registration of clients.  The function of a
   descriptor is handled by a structured representation of the message
   "envelope".  This structure makes it unnecessary for a client to know
   anything about RFC 822 parsing.  There is no synchronization since
   the client does not remember state between IMAP2 connections.  This
   is not a problem since in general the client never needs the entire
   state of the mailbox in a single session, therefore there isn't much
   overhead in fetching the state information that is needed as it is
   needed.

   There are also some functional differences between IMAP2 and DMSP.
   DMSP has explicit support for bulletin boards which are only handled
   implicitly in IMAP2.  DMSP has functions for sending messages,
   printing messages, listing mailboxes, and changing passwords, all of
   which are done outside of IMAP2.  DMSP has 16 binary flags of which 8
   are defined by the system.  IMAP has flag names; there are currently
   5 defined system flag names and a facility for some number (30 in the
   current implementations) of user flag names.  IMAP2 has a
   sophisticated message search facility in the server to identify
   interesting messages based on dates, addresses, flag status, or
   textual contents without compelling the client to fetch this data for
   every message.

   It was felt that maintaining state on the client is advantageous only
   in those cases where the client is only used by a single user, or if
   there is some means on the client to restrict access to another
   user's data.  It can be a serious disadvantage in an environment in
   which multiple users routinely use the same client, the same user
   routinely uses different clients, and where there are no access
   restrictions on the client.  It was also observed that most user mail
   access is to a relatively small set of "interesting" messages, which
   were either "new" mail or mail based upon some user-selected
   criteria. Consequently, IMAP2 was designed to easily identify those



Crispin                                                         [Page 4]

RFC 1064                         IMAP2                         July 1988


   "interesting" messages so that the client could fetch the state of
   those messages and not those that were not "interesting".

The Protocol

   The IMAP2 protocol consists of a sequence of client commands and
   server responses, with server data interspersed between the
   responses.  Unlike most Internet protocols, commands and responses
   are tagged.  That is, a command begins with a unique identifier
   (typically a short alphanumeric sequence such as a Lisp "gensym"
   function would generate e.g., A0001, A0002, etc.), called a tag.  The
   response to this command is given the same tag from the server.
   Additionally, the server may send an arbitrary amount of "unsolicited
   data", which is identified by the special reserved tag of "*".  There
   is another special reserved tag, "+", discussed below.

   The server must be listening for a connection.  When a connection is
   opened the server sends an unsolicited OK response as a greeting
   message and then waits for commands.  When commands are received the
   server acts on them and responds with responses, often interspersed
   with data.

   The client opens a connection, waits for the greeting, then sends a
   LOGIN command with user name and password arguments to establish
   authorization.  Following an OK response from the server, the client
   then sends a SELECT command to access the desired mailbox.  The
   user's default mailbox has a special reserved name of "INBOX" which
   is independent of the operating system that the server is implemented
   on.  The server will generally send a list of valid flags, number of
   messages, and number of messages arrived since last access for this
   mailbox as unsolicited data, followed by an OK response.  The client
   may terminate access to this mailbox and access a different one with
   another SELECT command.

   The client reads mailbox information by means of FETCH commands.  The
   actual data is transmitted via the unsolicited data mechanism (that
   is, FETCH should be viewed as poking the server to include the
   desired data along with any other data it wishes to transmit to the
   client).  There are three major categories of data which may be
   fetched.

   The first category is that data which is associated with a message as
   an entity in the mailbox.  There are presently three such items of
   data: the "internal date", the "RFC 822 size", and the "flags".  The
   internal date is the date and time that the message was placed in the
   mailbox.  The RFC 822 size is subject to deletion in the future; it
   is the size in bytes of the message, expressed as an RFC 822 text
   string.  Current clients only use it as part of a status display



Crispin                                                         [Page 5]

RFC 1064                         IMAP2                         July 1988


   line.  The flags are a list of status flags associated with the
   message (see below).  All of the first category data can be fetched
   by using the macro-fetch word "FAST"; that is, "FAST" expands to
   "(FLAGS INTERNALDATE RFC822.SIZE)".

   The second category is that data which describes the composition and
   delivery information of a message; that is, information such as the
   message sender, recipient lists, message-ID, subject, etc.  This is
   the information which is stored in the message header in RFC 822
   format message and is traditionally called the "envelope".  [Note:
   this should not be confused with the SMTP (RFC 821) envelope, which
   is strictly limited to delivery information.]  IMAP2 defines a
   structured and unambiguous representation for the envelope which is
   particularly nice for Lisp-based parsers.  A client can use the
   envelope for operations such as replying and not worry about RFC 822
   at all.  Envelopes are discussed in more detail below.  The first and
   second category data can be fetched together by using the macro-fetch
   word "ALL"; that is, "ALL" expands to "(FLAGS INTERNALDATE
   RFC822.SIZE ENVELOPE)".

   The third category is that data which is intended for direct human
   viewing.  The present RFC 822 based IMAP2 defines three such items:
   RFC822.HEADER, RFC822.TEXT, and RFC822 (the latter being the two
   former appended together in a single text string).  Fetching "RFC822"
   is equivalent to typing the RFC 822 representation of the message as
   stored on the mailbox without any filtering or processing.

   Typically, a client will "FETCH ALL" for some or all of the messages
   in the mailbox for use as a presentation menu, and when the user
   wishes to read a particular message will "FETCH RFC822.TEXT" to get
   the message body.  A more primitive client could, of course, simply
   "FETCH RFC822" a la POP2-type functionality.

   The client can alter certain data (presently only the flags) by means
   of a STORE command.  As an example, a message is deleted from a
   mailbox by a STORE command which includes the \DELETED flag as one of
   the flags being set.

   Other client operations include copying a message to another mailbox
   (COPY command), permanently removing deleted messages (EXPUNGE
   command), checking for new messages (CHECK command), and searching
   for messages which match certain criteria (SEARCH command).

   The client terminates the session with the LOGOUT command.  The
   server returns a "BYE" followed by an "OK".






Crispin                                                         [Page 6]

RFC 1064                         IMAP2                         July 1988


   A Typical Scenario

           Client                          Server
           ------                          ------
                                       {Wait for Connection}
       {Open Connection}        -->
                                   <-- * OK IMAP2 Server Ready
                                       {Wait for command}
       A001 LOGIN Fred Secret   -->
                                   <-- A001 OK User Fred logged in
                                       {Wait for command}
       A002 SELECT INBOX        -->
                                   <-- * FLAGS (Meeting Notice \Answered
                                                \Flagged \Deleted \Seen)
                                   <-- * 19 EXISTS
                                   <-- * 2 RECENT
                                   <-- A0002 OK Select complete
                                       {Wait for command}
       A003 FETCH 1:19 ALL      -->
                                   <-- * 1 Fetch (......)
                                           ...
                                   <-- * 18 Fetch (......)
                                   <-- * 19 Fetch (......)