rfc1176.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,616 行 · 第 1/5 页

   tag BAD text

      This response identifies faulty protocol received from the client;
      The text is a line of human-readable text that 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
              previous 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
              Obsolete and functionally equivalent to FETCH.

      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 that describes the
                      envelope of a message.  The envelope is computed
                      by the server by parsing the RFC 822 header into



Crispin                                                        [Page 18]

RFC 1176                         IMAP2                       August 1990


                      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 that
                      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 that 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 that are set
                      for this message.  This may include the following
                      system flags:

                      \RECENT       Message arrived since the
                                     previous time this mailbox
                                     was read
                      \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
                       characters in the message as expressed



Crispin                                                        [Page 19]

RFC 1176                         IMAP2                       August 1990


                       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) that 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 to those messages that match the search criteria.
      Each number is delimited by a space, e.g., "SEARCH 2 3 6".

   * BBOARD string

      This response occurs as a result of a FIND BBOARDS command.  The
      string is a bulletin board name that matches the pattern in the
      command.

   * MAILBOX string

      This response occurs as a result of a FIND MAILBOXES command.  The
      string is a mailbox name that matches the pattern in the command.

   * BYE text

      This response identifies that the server is about to close the
      connection.  The text is a line of human-readable text that 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 identifies normal operation on the server.  No
      special action by the client is called for, however, the text
      should be displayed to the user in some fashion.  This is
      currently only used by servers at startup as a greeting message to
      show they are ready to accept the first command.






Crispin                                                        [Page 20]

RFC 1176                         IMAP2                       August 1990


   * NO text

      This response identifies a warning from the server that does not
      affect the overall results of any particular request.  The text is
      a line of human-readable text that should be presented to the user
      as a warning of improper operation.

   * BAD text

      This response identifies a serious error at the server; it may
      also indicate faulty protocol from the client in which a tag could
      not be parsed.  The text is a line of human-readable text that
      should be presented to the user as a serious or possibly fatal
      error.  It should also be recorded in any telemetry as part of a
      bug report to the maintainer of the client and server.

   + text

      This response identifies 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 for commands that 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 expects it,
      preserving client/server synchronization.

      In practice, this condition is rarely encountered.  In the current
      protocol, the only client command likely to contain a literal is
      the LOGIN command.  Consider a server that 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 caused by a
      bug in the client or server.












Crispin                                                        [Page 21]

RFC 1176                         IMAP2                       August 1990


Sample IMAP2 session

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

   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:44 PDT"
         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:   -------
   S:   )
   S:   a004 OK Fetch completed



Crispin                                                        [Page 22]

RFC 1176                         IMAP2                       August 1990


   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















































Crispin                                                        [Page 23]

RFC 1176                         IMAP2                       August 1990


Implementation Discussion