rfc1203.txt

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

      Thus, no message that matches the criterion:
         FROM crispin

      will match the criterion:
         ~FROM crispin

      The criteria for the search can be any generic, canonical or
      concrete key.  In addition to these, the following pre-defined
      keys are also provided:

      ALL             All messages in the mailbox; the default
                      initial criterion for ANDing.

      ANSWERED        Messages with the \ANSWERED flag set.

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

      BEFORE date     Messages whose internal date is earlier than
                      the specified date.




Rice                                                           [Page 21]

RFC 1203                         IMAP3                     February 1991


      BODY string     Messages which contain the specified string
                      in the body of the message.

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

      DELETED         Messages with the \DELETED flag set.

      FLAGGED         Messages with the \FLAGGED flag set.

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

      HEADER string   Messages which contain the specified string
                      in the message header.

      KEYWORD flag    Messages with the specified flag set.

      NEW             Messages which have the \RECENT flag set but
                      not the \SEEN flag.  This is functionally
                      equivalent to "RECENT UNSEEN".

      OLD             Messages which do not have the \RECENT flag
                      set.

      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.

         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 mailbox since October 1, 1987.

      Implementation note:  The UNANSWERED, UNDELETED, UNFLAGGED,



Rice                                                           [Page 22]

RFC 1203                         IMAP3                     February 1991


      UNKEYWORD and UNSEEN criteria, described below, are preserved in
      IMAP3 for IMAP2 compatibility.  They are, however, considered
      obsolete and new Client programs are encouraged to use the ~
      notation for the logical inverses of search criteria with a view
      to the dropping of this outmoded syntax in later versions.

      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.

   tag READONLY

      The READONLY command indicates that the client wishes to make the
      mailbox read-only.  The server is required to reply with a
      solicited READONLY or READWRITE response.

   tag READWRITE

      The READWRITE command indicates that the client wishes to make the
      mailbox read-write.  The server is required to reply with a
      solicited READONLY or READWRITE response.

   tag SUPPORTED.VERSIONS

      The SUPPORTED.VERSIONS solicits from the server a
      SUPPORTED.VERSIONS message, which encapsulates information about
      which versions and features the server supports.

   tag SELECT.VERSION (major_version minor_version)

      The SELECT.VERSION command indicates that the client wishes to
      select certain behavior on the part of the server.  The major and
      minor versions indicate the specific version of the protocol being
      selected.

      EXAMPLE: A002 SELECT.VERSION (3 0)

      A client may not request a server version that is not supported by



Rice                                                           [Page 23]

RFC 1203                         IMAP3                     February 1991


      the server, i.e., which is specifically mentioned in the response
      to a SUPPORTED.VERSIONS command.  An attempt to do so by a client
      will result in a NO response from the server.  It is an error for
      the SELECT.VERSION command to be used after a mailbox has been
      selected.  The rationale for this is that for some server
      implementations it might be necessary to spawn separate programs
      to implement widely divergent protocol versions.  Thus, the client
      cannot be allowed to expect any server state to be preserved after
      the use of the SELECT.VERSION command.  The default version of all
      servers is 2.0, i.e., IMAP2 as defined by RFC 1064.

   tag SELECT.FEATURES 1#features

      The SELECT.FEATURES command indicates that the client wishes to
      select certain specific features on the part of the server. A
      client may not request a feature that is not supported by the
      server, i.e., one that is explicitly mentioned in the set of
      features for the selected version returned by the
      SUPPORTED.VERSIONS command.  An attempt to do so by a client will
      result in a NO response from the server.

      EXAMPLE: A002 SELECT.FEATURES AUTO.SET.SEEN ~TAGGED.SOLICITED
              EIGHT.BIT.TRANSPARENT

      i.e., select the set of features called AUTO.SET.SEEN and
      EIGHT.BIT.TRANSPARENT and deselect the feature called
      TAGGED.SOLICITED.  The use of the SELECT.FEATURES command
      completely resets the set of selected features.  Note:  These are
      only example feature names and are not necessarily supported by
      any server.  See the appendix on features for more information on
      features.  Note:  Some features, when present in the server, will
      cause the upwards compatible extension of the grammar, i.e., by
      adding extra commands.  The server is at liberty not to remove
      these upwards compatible extensions to the command tables when a
      feature is disabled.  Thus, it is an error for a client to rely on
      getting a NO or BAD response in any way, for instance to determine
      the selectedness or presence of a feature.

   tag BBOARD bboard

      The BBOARD command is equivalent to SELECT, except that its
      argument is a bulletin board (BBoard) name.  The format of a
      BBoard 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 on the particular system.
      There is no requirement that a BBoard name be a mailbox name or a
      file name (in particular, Unix netnews has a completely different
      namespace from mailbox or file names).



Rice                                                           [Page 24]

RFC 1203                         IMAP3                     February 1991


      The result from the BBOARD command is identical from that of the
      SELECT command.  For example, in the TOPS-20 server
      implementation, the command
         A0002 BBOARD FOO
      is exactly equivalent to the command
         A0002 SELECT POBOX:<BBOARD>FOO.TXT
         Note: the equivalence in this example is *not* required by the
         protocol, and merely reflects the fuzzy distinction between
         mailboxes and BBoards on TOPS-20.

   tag FIND (BBOARDS / MAILBOXES) pattern

      The FIND command accepts as arguments the keywords BBOARDS or
      MAILBOXES and a pattern which specifies some set of BBoard/mailbox
      names which are usable by the BBOARD/SELECT command.  Two wildcard
      characters are defined; "*" specifies that any number (including
      zero) characters may match at this position and "%" specifies that
      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; furthermore, "*" will match all
      BBoards/mailboxes.  The following quoting convention applies to
      wildcards: "\*" is the literal "*" character, "\%" is the literal
      "%" character and "\\" is the literal "\" character.  Notes: The
      format of mailboxes is server implementation dependent.  The
      special mailbox name INBOX is not included in the output to the
      FIND MAILBOXES command.

      The FIND command solicits any number of BBOARD or MAILBOX
      responses from the server as appropriate.

      Examples:
          A0002 FIND BBOARDS *
          A0002 BBOARD FOOBAR
          A0002 BBOARD GENERAL
          A0002 OK FIND completed
      or
          A0002 FIND MAILBOXES FOO%BA*
          A0002 MAILBOX FOO.BAR
          A0002 MAILBOX FOO.BAZZAR
          A0002 OK FIND completed

      Note: 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 solicited
      reply be usable in the SELECT command without remembering any path
      specification which may have been used in the FIND MAILBOXES
      pattern.




Rice                                                           [Page 25]

RFC 1203                         IMAP3                     February 1991


   tag FLAGS

      The FLAGS command solicits a FLAGS response from the server.

   tag SET.FLAGS flag_list

      The SET.FLAGS command defines the user specifiable flags for this
      mailbox, i.e., the keywords.  If this set does not include flags
      formerly sent to the client by the server in a FLAGS message then
      this constitutes a request to delete the flag.  Any new flags
      should be created.  This command does not affect the system
      defined flags and any system flags that are included in the
      flag_list will be ignored.  The server must respond to this
      command with a solicited FLAGS message.  If the deletion of a flag
      results in the invalidation of the flag sets of any messages then
      the server is required to send solicited STORE FLAGS messages to
      the client for each modified message.

Responses:

   */tag OK text

      In its solicited form 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.

      In its unsolicited form, this response indicates simply 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 com