rfc1064.txt

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


RFC 1064                         IMAP2                         July 1988


      ON date         Messages whose internal date is the same as
                      the specified date.

      RECENT          Messages which have the \RECENT flag set.

      SEEN            Messages which have the \SEEN flag set.

      SINCE date      Messages whose internal date is later than
                      the specified date.

      SUBJECT string  Messages which contain the specified string
                      in the envelope's SUBJECT field.

      TEXT string     Messages which contain the specified string.

      TO string       Messages which contain the specified string in
                      the envelope's TO field.

      UNANSWERED      Messages which do not have the \ANSWERED flag
                      set.

      UNDELETED       Messages which do not have the \DELETED flag
                      set.

      UNFLAGGED       Messages which do not have the \FLAGGED flag
                      set.

      UNKEYWORD flag  Messages which do not have the specified flag
                      set.

      UNSEEN          Messages which do not have the \SEEN flag set.

         EXAMPLE:  A003 SEARCH DELETED FROM "SMITH" SINCE 1-OCT-87
         returns the message numbers for all deleted messages from Smith
         that were placed in the mail file since October 1, 1987.
















Crispin                                                        [Page 14]

RFC 1064                         IMAP2                         July 1988


Responses

   tag OK text

      This response identifies successful completion of the command with
      the indicated tag.  The text is a line of human-readable text
      which may be useful in a protocol telemetry log for debugging
      purposes.

   tag NO text

      This response identifies unsuccessful completion of the command
      with the indicated tag.  The text is a line of human-readable text
      which probably should be displayed to the user in an error report
      by the client.

   tag BAD text

      This response indicates faulty protocol received from the client
      and indicates a bug in the client.  The text is a line of human-
      readable text which should be recorded in any telemetry as part of
      a bug report to the maintainer of the client.

   * number message_data

      This response occurs as a result of several different commands.
      The message_data is one of the following:

      EXISTS  The specified number of messages exists in the mailbox.

      RECENT  The specified number of messages have arrived since the
              last time this mailbox was read.

      EXPUNGE The specified message number has been permanently
              removed from the mailbox, and the next message in the
              mailbox (if any) becomes that message number.

      STORE data
              Functionally equivalent to FETCH, only it happens as a
              result of a STORE command.

      FETCH data
              This is the principle means by which data about a
              message is returned to the client.  The data is in a
              Lisp-like S-expression property list form.  The current
              properties are:

         ENVELOPE     An S-expression format list which describes the



Crispin                                                        [Page 15]

RFC 1064                         IMAP2                         July 1988


                      envelope of a message.  The envelope is computed
                      by the server by parsing the RFC 822 header into
                      the component parts, defaulting various fields
                      as necessary.

                      The fields of the envelope are in the following
                      order: date, subject, from, sender, reply-to, to,
                      cc, bcc, in-reply-to, and message-id.  The date,
                      subject, in-reply-to, and message-id fields are
                      strings.  The from, sender, reply-to, to, cc,
                      and bcc fields are lists of addresses.

                      An address is an S-expression format list which
                      describes an electronic mail address.  The fields
                      of an address are in the following order:
                      personal name, source-route (a.k.a. the
                      at-domain-list in SMTP), mailbox name, and
                      host name.

                      Any field of an envelope or address which is
                      not applicable is presented as the atom NIL.
                      Note that the server must default the reply-to
                      and sender fields from the from field; a client is
                      not expected to know to do this.

         FLAGS        An S-expression format list of flags which are set
                      for this message.  This may include the following
                      system flags:

                      \RECENT       Message arrived since last
                                     read of this mail file
                      \SEEN         Message has been read
                      \ANSWERED     Message has been answered
                      \FLAGGED      Message is "flagged" for
                                     urgent/special attention
                      \DELETED      Message is "deleted" for
                                     removal by later EXPUNGE

         INTERNALDATE  A string containing the date and time the
                       message was written to the mailbox.

         RFC822        A string expressing the message in RFC 822
                       format.

         RFC822.HEADER A string expressing the RFC 822 format
                       header of the message

         RFC822.SIZE   A number indicating the number of



Crispin                                                        [Page 16]

RFC 1064                         IMAP2                         July 1988


                       characters in the message as expressed
                       in RFC 822 format.

         RFC822.TEXT   A string expressing the text body of the
                       message, omitting the RFC 822 header.

   * FLAGS flag_list

      This response occurs as a result of a SELECT command.  The flag
      list are the list of flags (at a minimum, the system-defined
      flags) which are applicable for this mailbox.  Flags other than
      the system flags are a function of the server implementation.

   * SEARCH number(s)

      This response occurs as a result of a SEARCH command.  The
      number(s) refer those messages which match the search criteria.
      Each number is delimited by a space, e.g., "SEARCH 2 3 6".

   * BYE text

      This response indicates that the server is about to close the
      connection.  The text is a line of human-readable text which
      should be displayed to the user in a status report by the client.
      This may be sent as part of a normal logout sequence, or as a
      panic shutdown announcement by the server.  It is also used by
      some servers as an announcement of an inactivity autologout.

   * OK text

      This response indicates that the server is alive.  No special
      action on the part of the client is called for.  This is presently
      only used by servers at startup as a greeting message indicating
      that they are ready to accept the first command.  The text is a
      line of human-readable text which may be logged in protocol
      telemetry.

   * NO text

      This response indicates some operational error at the server which
      cannot be traced to any protocol command.  The text is a line of
      human-readable text which should be logged in protocol telemetry
      for the maintainer of the server and/or the client.  No known
      server currently outputs such a response.

   * BAD text

      This response indicates some protocol error at the server which



Crispin                                                        [Page 17]

RFC 1064                         IMAP2                         July 1988


      cannot be traced to any protocol command.  The text is a line of
      human-readable text which should be logged in protocol telemetry
      for the maintainer of the server and/or the client.  This
      generally indicates a protocol synchronization problem on the part
      of the client, and examination of the protocol telemetry is
      advised to determine the cause of the problem.

   + text

      This response indicates that the server is ready to accept the
      text of a literal from the client.  Normally, a command from the
      client is a single text line.  If the server detects an error in
      the command, it can simply discard the remainder of the line.  It
      cannot do this in the case of commands which contain literals,
      since a literal can be an arbitrarily long amount of text, and the
      server may not even be expecting a literal.  This mechanism is
      provided so the client knows not to send a literal until the
      server definitely expects it, preserving client/server
      synchronization.

      In actual practice, this situation is rarely encountered.  In the
      current protocol, the only client command likely to contain a
      literal is the LOGIN command.  Consider a situation in which a
      server validates the user before checking the password.  If the
      password contains "funny" characters and hence is sent as a
      literal, then if the user is invalid an error would occur before
      the password is parsed.

      No such synchronization protection is provided for literals sent
      from the server to the client, for performance reasons.  Any
      synchronization problems in this direction would be due to a bug
      in the client or server and not for some operational problem.



















Crispin                                                        [Page 18]

RFC 1064                         IMAP2                         July 1988


Sample IMAP2 session

   The following is a transcript of an actual IMAP2 session.  Server
   output is identified by "S:" and client output by "U:".  In cases
   where lines were too long to fit within the boundaries of this
   document, the line was continued on the next line preceded by a tab.

   S:      * OK SUMEX-AIM.Stanford.EDU Interim Mail Access Protocol II
                   Service 6.1(349) at Thu, 9 Jun 88 14:58:30 PDT
   U:      a001 login crispin secret
   S:      a002 OK User CRISPIN logged in at Thu, 9 Jun 88 14:58:42 PDT,
                   job 76
   U:      a002 select inbox
   S:      * FLAGS (Bugs SF Party Skating Meeting Flames Request AI
                   Question Note \XXXX \YYYY \Answered \Flagged \Deleted
                   \Seen)
   S:      * 16 EXISTS
   S:      * 0 RECENT
   S:      a002 OK Select complete
   U:      a003 fetch 16 all
   S:      * 16 Fetch (Flags (\Seen) InternalDate " 9-Jun-88 12:55:
               RFC822.Size 637 Envelope ("Sat, 4 Jun 88 13:27:11 PDT"
               "INFO-MAC Mail Message" (("Larry Fagan" NIL "FAGAN"
               "SUMEX-AIM.Stanford.EDU")) (("Larry Fagan" NIL "FAGAN"
               "SUMEX-AIM.Stanford.EDU")) (("Larry Fagan" NIL "FAGAN"
               "SUMEX-AIM.Stanford.EDU")) ((NIL NIL "rindflEISCH"
               "SUMEX-AIM.Stanford.EDU")) NIL NIL NIL
               "<[e-mail]>"))
   S:   a003 OK Fetch completed
   U:   a004 fetch 16 rfc822
   S:   * 16 Fetch (RFC822 {637}
   S:   Mail-From: RINDFLEISCH created at  9-Jun-88 12:55:43
   S:   Mail-From: FAGAN created at  4-Jun-88 13:27:12
   S:   Date: Sat, 4 Jun 88 13:27:11 PDT
   S:   From: Larry Fagan  <[e-mail]>
   S:   To: [e-mail]
   S:   Subject: INFO-MAC Mail Message
   S:   Message-ID: <[e-mail]>
   S:   ReSent-Date: Thu, 9 Jun 88 12:55:43 PDT
   S:   ReSent-From: TC Rindfleisch <[e-mail]>
   S:   ReSent-To: [e-mail],
                   [e-mail]
   S:   ReSent-Message-ID:
           <[e-mail]>
   S:
   S:   The file is <info-mac>usenetv4-55.arc  ...
   S:   Larry
   S:   -------



Crispin                                                        [Page 19]

RFC 1064                         IMAP2                         July 1988


   S:   )
   S:   pa004 OK Fetch completed
   U:   a005 logout
   S:   * BYE DEC-20 IMAP II server terminating connection
   S:   a005 OK SUMEX-AIM.Stanford.EDU Interim Mail Access Protocol
                   Service logout