rfc1176.txt

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

   The client reads mailbox information with FETCH commands.  The actual



Crispin                                                         [Page 6]

RFC 1176                         IMAP2                       August 1990


   data is transmitted via the unsolicited data mechanism (that is,
   FETCH should be viewed as instructing 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 that may be
   fetched.

   The first category is data that is associated with a message as an
   entity in the mailbox.  There are now 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 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 that 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 that 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 that is
   particularly suited 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 two
   categories of 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 that 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).  RFC822.HEADER is
   the "raw", unprocessed RFC 822 format header of the message.
   Fetching "RFC822" is equivalent to fetching the RFC 822
   representation of the message as stored on the mailbox without any
   filtering or processing.

   An intelligent 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 POP-type functionality.




Crispin                                                         [Page 7]

RFC 1176                         IMAP2                       August 1990


   The client can alter certain data (currently only the flags) by a
   STORE command.  As an example, a message is deleted from a mailbox by
   a STORE command that includes the \DELETED flag as a flag 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 that match certain criteria (SEARCH command).

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

   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 (......)
                                   <-- A003 OK Fetch complete
                                       {Wait for command}
       A004 FETCH 8 RFC822.TEXT -->
                                   <-- * 8 Fetch (RFC822.TEXT {893}
                                           ...893 characters of text...
                                   <-- )
                                   <-- A004 OK Fetch complete
                                       {Wait for command}








Crispin                                                         [Page 8]

RFC 1176                         IMAP2                       August 1990


       A005 STORE 8 +Flags \Deleted -->
                                   <-- * 8 Store (Flags (\Deleted
                                                  \Seen))
                                   <-- A005 OK Store complete
                                       {Wait for command}
       A006 EXPUNGE             -->
                                   <-- * 19 EXISTS
                                   <-- * 8 EXPUNGE
                                   <-- * 18 EXISTS
                                   <-- A006 Expunge complete
                                       {Wait for command}
       A007 LOGOUT              -->
                                   <-- * BYE IMAP2 server quitting
                                   <-- A007 OK Logout complete
       {Close Connection}       --><-- {Close connection}
                                       {Go back to start}
Conventions

   The following terms are used in a meta-sense in the syntax
   specification below:

      An ASCII-STRING is a sequence of arbitrary ASCII characters.

      An ATOM is a sequence of ASCII characters delimited by SP or CRLF.

      A CHARACTER is any ASCII character except """", "{", CR, LF, "%",
      or "\".

      A CRLF is an ASCII carriage-return character followed immediately
      by an ASCII linefeed character.

      A NUMBER is a sequence of the ASCII characters that represent
      decimal numerals ("0" through "9"), delimited by SP, CRLF, ",", or
      ":".

      A SP is the ASCII space character.

      A TEXT_LINE is a human-readable sequence of ASCII characters up to
      but not including a terminating CRLF.

   A common field in the IMAP2 protocol is a STRING, which may be an
   ATOM, QUOTED-STRING (a sequence of CHARACTERs inside double-quotes),
   or a LITERAL.  A literal consists of an open brace ("{"), a number, a
   close brace ("}"), a CRLF, and then an ASCII-STRING of n characters,
   where n is the value of the number inside the brace.  In general, a
   string should be represented as an ATOM or QUOTED-STRING if at all
   possible.  The semantics for QUOTED-STRING or LITERAL are checked
   before those for ATOM; therefore an ATOM used in a STRING may only



Crispin                                                         [Page 9]

RFC 1176                         IMAP2                       August 1990


   contain CHARACTERs.  Literals are most often sent from the server to
   the client; in the rare case of a client to server literal there is a
   special consideration (see the "+ text" response below).

   Another important field is the SEQUENCE, which identifies a set of
   messages by consecutive numbers from 1 to n where n is the number of
   messages in the mailbox.  A sequence may consist of a single number,
   a pair of numbers delimited by colon (equivalent to all numbers
   between those two numbers), or a list of single numbers or number
   pairs.  For example, the sequence 2,4:7,9,12:15 is equivalent to
   2,4,5,6,7,9,12,13,14,15 and identifies all those messages.

Definitions of Commands and Responses

     Summary of Commands and Responses

       Commands                            ||      Responses
       --------                            ||      -------
       tag NOOP                            ||      tag OK text
       tag LOGIN user password             ||      tag NO text
       tag LOGOUT                          ||      tag BAD text
       tag SELECT mailbox                  ||      * number message_data
       tag BBOARD bulletin_board           ||      * FLAGS flag_list
       tag FIND MAILBOXES pattern          ||      * SEARCH sequence
       tag FIND BBOARDS pattern            ||      * BBOARD string
       tag CHECK                           ||      * MAILBOX string
       tag EXPUNGE                         ||      * BYE text
       tag COPY sequence mailbox           ||      * OK text
       tag FETCH sequence data             ||      * NO text
       tag STORE sequence data value       ||      * BAD text
       tag SEARCH search_program           ||      + text

Commands

   tag NOOP

      The NOOP command returns an OK to the client.  By itself, it does
      nothing, but certain things may happen as side effects.  For
      example, server implementations that implicitly check the mailbox
      for new mail may do so as a result of this command.  The primary
      use of this command is to for the client to see if the server is
      still alive (and notify the server that the client is still alive,
      for those servers that have inactivity autologout timers).

   tag LOGIN user password

      The LOGIN command identifies the user to the server and carries
      the password authenticating this user.  This information is used



Crispin                                                        [Page 10]

RFC 1176                         IMAP2                       August 1990


      by the server to control access to the mailboxes.

      EXAMPLE:  A001 LOGIN SMITH SESAME
      logs in as user SMITH with password SESAME.

   tag LOGOUT

      The LOGOUT command informs the server that the client is done with
      the session.  The server should send an unsolicited BYE response
      before the (tagged) OK response, and then close the network
      connection.

   tag SELECT mailbox

      The SELECT command selects a particular mailbox.  The server must
      check that the user is permitted read access to this mailbox.
      Before returning an OK to the client, the server must send the
      following unsolicited data to the client:
         FLAGS        mailbox's defined flags
         <n> EXISTS   the number of messages in the mailbox
         <n> RECENT   the number of new messages in the mailbox
      in order to define the initial state of the mailbox at the client.

      Multiple SELECT commands are permitted in a session, in which case
      the previous mailbox is automatically deselected when a new SELECT
      is made.

      The default mailbox for the SELECT command is INBOX, which is a
      special name reserved to mean "the primary mailbox for this user
      on this server".  The format of other mailbox names is operating
      system dependent (as of this writing, it reflects the filename
      path of the mailbox file on the current servers).

      It is customary, although not required, for the text of an OK
      response to the SELECT command to begin with either "[READ-ONLY]"
      or "[READ-WRITE]" to show the mailbox's access status.

      EXAMPLE: A002 SELECT INBOX
      selects the default mailbox.

   tag BBOARD bulletin_board

      The BBOARD command is equivalent to SELECT, and returns the same
      output.  However, it differs from SELECT in that its argument is a
      shared mailbox (bulletin board) name instead of an ordinary
      mailbox.  The format of a bulletin name is implementation
      specific, although it is strongly encouraged to use something that
      resembles a name in a generic sense and not a file or mailbox name



Crispin                                                        [Page 11]

RFC 1176                         IMAP2                       August 1990


      on the particular system.  There is no requirement that a bulletin
      board name be a mailbox name or a file name (in particular, Unix
      netnews has a completely different namespace from mailbox or file
      names).

      Support for BBOARD is optional.

   tag FIND MAILBOXES pattern

      The FIND MAILBOXES command accepts as an argument a pattern
      (including wildcards) that specifies some set of mailbox names
      that are usable by the SELECT command.  The format of mailboxes is
      implementation dependent.  The special mailbox name INBOX is not
      included in the output.

      Two wildcard characters are defined; "*" specifies any number
      (including zero) characters may match at this position and "%"
      specifies a single character may match at this position.  For
      example, FOO*BAR will match FOOBAR, FOOD.ON.THE.BAR and FOO.BAR,
      whereas FOO%BAR will match only FOO.BAR.  "*" will match all
      mailboxes.

      The FIND MAILBOXES command will return some set of unsolicited
      MAILBOX replies that have as their value a single mailbox name.

      EXAMPLE:  A002 FIND MAILBOXES *
                * MAILBOX FOOBAR
                * MAILBOX GENERAL
                A002 FIND completed

      Although the use of explicit file or path names for mailboxes is
      discouraged by this standard, it may be unavoidable.  It is
      important that the value returned in the MAILBOX unsolicited reply
      be usable in the SELECT command without remembering any path
      specification that may have been used in the FIND MAILBOXES
      pattern.

      Support for FIND MAILBOXES is optional.  If a client's attempt
      returns BAD as a response then the client can make no assumptions
      about what mailboxes exist on the server other than INBOX.

   tag FIND BBOARDS pattern

      The FIND BBOARDS command accepts as an argument a pattern that