rfc1203.txt

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

   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, IMAP3 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, IMAP3 offers several facilities for managing a mailbox
   beyond the simple "delete message" functionality of POP2.

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

   IMAP3 differs from the DMSP protocol of PCMAIL (RFC 1056) in a more
   fundamental manner, reflecting the differing architectures of IMAP
   and PCMAIL.  PCMAIL is either an online ("interactive mode"), or
   offline ("batch mode") system.  IMAP is primarily an online system in
   which real-time and simultaneous mail access were considered



Rice                                                            [Page 6]

RFC 1203                         IMAP3                     February 1991


   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 IMAP, the client/server relationship lasts only for the duration
   of the IMAP3 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 IMAP3 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 IMAP3 and DMSP.
   DMSP has functions for sending messages, printing messages, and
   changing passwords, all of which are done outside of IMAP3.  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 (29 in the current implementations) of user flag
   names.  IMAP3 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, IMAP3 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".

   One crucial philosophical difference between IMAP and other common



Rice                                                            [Page 7]

RFC 1203                         IMAP3                     February 1991


   mail protocols is that IMAP is a mailbox access protocol, not a
   protocol for manipulating mail files.  In the IMAP model, unlike
   other mail system models in which mail is stored in a linear mail
   file, no specification is made for the implementation architecture
   for mail storage.  Servers may choose to implement mailboxes as files
   but this is a detail of which the client can be totally unaware.

   What is more, in the IMAP model, mailboxes are viewed as mappings
   from keys into values.  There are broadly three types of keys,
   generic, canonical and concrete.  Generic keys are generic, mail
   protocol independent keys defined by IMAP which are meaningful across
   multiple mail encoding formats.  An example of such a generic key
   might be "TO", which would be associated with the "To:" field of an
   RFC 822 format message.

   Canonical keys represent the way in which the server can associate
   values that are generally "about" a certain key concept, possibly
   integrating several mail format specific fields, without having to
   worry the client with the particular details of any particular
   message format.  Thus, the canonical TO key (called $TO) could denote
   anything that could reasonably be construed as being directed towards
   someone.  Hence, in an RFC 822 message the server could find the
   union of the "To:", "Resent-To", "Apparently-To:" and "CC:" fields to
   be the appropriate value associated with the canonical $TO key.

   Concrete keys allow the client to gain access to certain mail format
   specific concepts, that are not pre-specified by the IMAP protocol,
   in a well defined manner.  For example, If the client asks for the
   value associated with the "APPARENTLY-TO" key then, if the message
   were to be in RFC 822 format, the server would look for a header
   field called "Apparently-To:".  If no such field is found or the
   field is not implemented or meaningful for the particular message
   format then the server will respond with the null value, called NIL,
   indicating the non-existence of the field.

   Thus, IMAP servers are at liberty to implement mailboxes as a
   relational databases if it seems convenient.  Indeed, we anticipate
   that future mail systems will tend to use database technology for the
   storage and indexing of mailboxes as a result of the pressure caused
   by the increasing size of mailboxes.

   Although for historical reasons IMAP is currently somewhat closely
   associated with RFC 822, we anticipate that future developments in
   IMAP will remove these mail format specific components and will move
   towards the generic model mentioned above.  This will allow IMAP more
   easily to incorporate such things as multi-media mail.





Rice                                                            [Page 8]

RFC 1203                         IMAP3                     February 1991


The Protocol

   The IMAP3 protocol consists of a sequence of client commands and
   server responses to those commands, with extra information from the
   server data being sent asynchronously to and independent to the
   responses to client commands.  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.

   We distinguish between data sent by the server as the result of a
   client request, which we term "SOLICITED" and data sent by the server
   not as the result of a client request, which we term "UNSOLICITED".
   The server may send unsolicited data at any time that would not
   fragment another piece of data on the same stream rendering it
   unintelligible.  The server is contractually required, however, to
   return all data that is solicited by the client before the return of
   the completion signal for that command, i.e., all solicited data must
   be returned within the temporal extent of the request/completion
   acknowledgement wrapper.  This does not, however, preclude the
   simultaneous processing of multiple requests by the client, it simply
   requires that the client be confident that it has all the requested
   data when a request finishes.  This allows the implementation of both
   synchronous and asynchronous clients.

   Solicited data is identified by the tag of the initial request by the
   client.  Unsolicited data is identified by the special reserved tag
   of "*".  There is another special reserved tag, "+", discussed below.

   Note: the tagging of SOLICITED data is only permitted for a selected
   server version other than 2.0.

   No assumptions concerning serial or monolithic processing by the
   server can be made by a correct client.  The server is at liberty to
   process multiple requests by the same client in any order.  This
   allows servers to process costly searches over mailboxes on slow
   backing storage media in the background, while still preserving
   interactive performance.  Clients can, however, assume the
   serialization of the request/data/completion behavior mentioned
   above.

   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.




Rice                                                            [Page 9]

RFC 1203                         IMAP3                     February 1991


   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 solicited data, followed by an OK response.  The client
   may terminate access to this mailbox and access a different one with
   another SELECT command.

   Because the SELECT command affects the state of the server in a
   fundamental way, the server is required to process all outstanding
   commands for any given mailbox before sending the OK tag for the
   SELECT command.  Thus, the client will always know that all responses
   before an OK SELECT response will refer to the old mailbox and all
   responses following it will apply to the new mailbox.

   Because, in the real world, local needs or experimental work will
   dictate that servers will support both supersets of the defined
   behavior and incompatible changes, servers will support a
   SELECT.VERSION command and a SELECT.FEATURES command, the purpose of
   which is to allow clients to select the overall behavior and specific
   features that they want from a server.  The default behavior of any
   server is to process commands and to have interaction syntax the same
   as is specified by IMAP2 in RFC 1064.  A server may not behave in any
   other manner unless the SELECT.VERSION or SELECT.FEATURES commands
   are used to select different behavior.

   Over time, when groups of generally useful changes to the current,
   default behavior of the server are found, these will be collected
   together and incorporated in such a way that all of the features can
   be selected simply by selecting a particular major version number of
   the protocol.  It should be noted that the version numbers (both
   major and minor) selected by the SELECT.VERSION command denote
   versions of the IMAP protocol, not versions of the server per se.
   Thus, although in general changes to the protocol specification will
   be made in such a way that they are upwards compatible, this cannot
   be guaranteed.  No client should rely on tests of the form "if
   major_version > 2 then..." being valid for all protocol versions,
   since incompatible changes might be made in the future.

   The client reads mailbox information by means of FETCH commands.  The
   actual data is transmitted via the solicited 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.



Rice                                                           [Page 10]

RFC 1203                         IMAP3                     February 1991


   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
   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