rfc1176.txt

来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 1,665 行 · 第 1/5 页

Network Working Group                                         M. Crispin
Request for Comments: 1176                                    Washington
Obsoletes: RFC 1064                                          August 1990


              INTERACTIVE MAIL ACCESS PROTOCOL - VERSION 2


Status of this Memo

   This RFC suggests a method for personal computers and workstations to
   dynamically access mail from a mailbox server ("repository").  It
   obosoletes RFC 1064.  This RFC specifies an Experimental Protocol for
   the Internet community.  Discussion and suggestions for improvement
   are requested.  Please refer to the current edition of the "IAB
   Official Protocol Standards" for the standardization state and status
   of this protocol.  Distribution of this memo is unlimited.

Introduction

   The intent of the Interactive Mail Access Protocol, Version 2 (IMAP2)
   is to allow a workstation, personal computer, or similar small
   machine to access electronic mail from a mailbox server.  Since the
   distinction between personal computers and workstations is blurring
   over time, it is desirable to have a single solution that addresses
   the need in a general fashion.  IMAP2 is the "glue" of a distributed
   electronic mail system consisting of a family of client and server
   implementations on a wide variety of platforms, from small single-
   tasking personal computing engines to complex multi-user timesharing
   systems.

   Although different in many ways from the Post Office Protocols (POP2
   and POP3, hereafter referred to collectively as "POP") described in
   RFC 937 and RFC 1081, IMAP2 may be thought of as a functional
   superset of these.  RFC 937 was used as a model for this RFC.  There
   was a cognizant reason for this; POP deals with a similar problem,
   albeit with a less comprehensive solution, and it was desirable to
   offer a basis for comparison.

   Like POP, 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).

   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.





Crispin                                                         [Page 1]

RFC 1176                         IMAP2                       August 1990


System Model and Philosophy

   Electronic mail is a primary means of communication for the widely
   spread Internet community.  The advent of distributed personal
   computers and workstations has forced a significant rethinking of the
   mechanisms employed to manage electronic mail.  With mainframes, each
   user tends to receive and process mail at the computer he uses 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 many vendors have
   implemented facilities to do this.  However, this approach has
   several disadvantages:

      (1) Personal computers and many 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 such as
      receiving mail may not run for long periods of time; either
      because the user is asking to use all the machine's resources, or
      because the user has (perhaps accidentally) manipulated the
      environment in such a way that it prevents mail reception.  In
      many personal computers, the operating system is single-tasking
      and this is the only mode of operation.  Any of these conditions
      could lead to repeated failed delivery attempts by outside agents.

      (2) The hardware failure of a single machine can keep its user
      "off the air" for a considerable time, since repair of individual
      units may be delayed.  Given the growing number of personal
      computers and workstations spread throughout office environments,
      quick repair of such systems is not assured.  On the other hand, a
      central mainframe is generally repaired soon after failure.

      (3) Personal computers and workstations are often not backed up
      with as much diligence as a central mainframe, if at all.

      (4) 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 many 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.

      (5) It is difficult to keep a multitude of heterogeneous machines



Crispin                                                         [Page 2]

RFC 1176                         IMAP2                       August 1990


      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 a personal computer or workstation may be viewed
   as an Internet host in the sense that it implements TCP/IP, it should
   not be viewed as the entity that contains the user's mailbox.
   Instead, a mail server machine ("server", sometimes called a
   "repository") should hold the mailbox, and the personal computer or
   workstation (hereafter referred to as a "client") should access the
   mailbox via mail transactions.

   Because the mail server machine is isolated from direct user
   manipulation, it should achieve high software reliability easily,
   and, as a shared resource, it should also achieve high hardware
   reliability, perhaps through redundancy.  The mail server may be
   accessed from arbitrary locations, allowing users to read mail across
   campus, town, or country using 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.  A mail access protocol retrieves messages, accesss
   and changes properties of messages, and otherwise manages 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 use 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.

   A mail access protocol further differs in that it transmits
   information only on demand.  A well-designed mail access protocol
   requires considerably less network traffic than Unix mail via NFS,
   particularly when the mail file is large.  The result is that a mail
   access protocol can scale well to situations of large mailboxes or
   networks with high latency or low speed.

   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 is desirable to allow for a



Crispin                                                         [Page 3]

RFC 1176                         IMAP2                       August 1990


   growth path beyond the hoary text-only RFC 822 protocol, specifically
   in the area of attachments and multi-media mail, to ease the eventual
   transition to ISO solutions.

   Unlike POP, IMAP2 has extensive features for remote searching and
   parsing of messages on the server.  A free text search (optionally
   with other searching) can be made in 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.  The effect of this is
   twofold: it further improves the ability to scale well in instances
   where network traffic must be reduced, and it reduces the complexity
   of the client program.

   Additionally, IMAP2 offers several facilities for managing individual
   message state and the mailbox as a whole beyond the simple "delete
   message" functionality of POP.  Another benefit of IMAP2 is the use
   of tagged responses to reduce the possibility of synchronization
   errors and the concept of state on the client (a "local cache") that
   the server may update without explicit request by the client.  These
   concepts and how they are used are explained under "Implementation
   Discussion" below.

   In spite of this functional richness, IMAP2 is a small protocol.
   Although servers should implement the full set of IMAP2 functions, a
   simple client can be written that uses IMAP2 in much the way as a POP
   client.

   A related protocol to POP and IMAP2 is the DMSP protocol of PCMAIL
   (RFC 1056).  IMAP2 differs from DMSP more fundamentally, reflecting a
   differing architecture from PCMAIL.  PCMAIL is either an online
   ("interactive mode"), or offline ("batch mode") system with long-term
   shared state.  Some POP based systems are also offline; in such
   systems, since there is no long-term shared state POP is little more
   than a download mechanism of the "mail file" to the client.  IMAP2-
   based software 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 that 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



Crispin                                                         [Page 4]

RFC 1176                         IMAP2                       August 1990


   state from the server.

   In IMAP2-based software, the client/server relationship lasts only
   for the duration of the TCP 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" as noted above.  There is no client/server
   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 functions for sending messages, printing messages, listing
   mailboxes, and changing passwords; these are done outside IMAP2.
   DMSP has 16 binary flags of which 8 are defined by the system.  IMAP2
   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 small set of "interesting" messages, which were either
   new mail or mail based on some user-selected criteria.  Consequently,
   IMAP2 was designed to easily identify those "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



Crispin                                                         [Page 5]

RFC 1176                         IMAP2                       August 1990


   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.

   The client opens a connection and waits for the greeting.  The client
   must not send any commands until it has received the greeting from
   the server.

   Once the greeting has been received, the client may begin sending
   commands and is not under any obligation to wait for a server
   response to this command before sending another command, within the
   constraints of TCP flow control.  When commands are received the
   server acts on them and responds with command responses, often
   interspersed with data.  The effect of a command can not be
   considered complete until a command response with a tag matching the
   command is received from the server.

   Although all known IMAP2 servers at the time of this writing process
   commands to completion before processing the next command, it is not
   required that a server do so.  However, many commands can affect the
   results of other commands, creating processing-order dependencies
   (or, for SEARCH and FIND, ambiguities about which data is associated
   with which command).  All implementations that operate in a non-
   lockstep fashion must recognize such dependencies and defer or
   synchronize execution as necessary.  In general, such multi-
   processing is limited to consecutive FETCH commands.

   Generally, the first command from the client is a LOGIN command with
   user name and password arguments to establish identity and access
   authorization, unless this has already been accomplished through
   other means, e.g. Kerberos.  Until identity and access authorization
   have been established, no operations other than LOGIN or LOGOUT are
   permitted.

   Once identity and authorization have been established, the client
   must send a SELECT command to access the desired mailbox; no mailbox
   is selected by default.  SELECT's argument is implementation-
   dependent; however the word "INBOX" must be implemented to mean the
   primary or default mailbox for this user, independent of any other
   server semantics.  On a successful SELECT, the server will 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.