rfc1730.txt
上传用户:horngjaan
上传日期:2009-12-12
资源大小:2882k
文件大小:153k
源码类别:

Email服务器

开发平台:

C#

  1.       before the COPY attempt.
  2.    Example:    C: A003 COPY 2:4 MEETING
  3.                S: A003 OK COPY completed
  4. 6.4.9.  UID Command
  5.    Arguments:  command name
  6.                command arguments
  7.    Data:       untagged responses: FETCH, SEARCH
  8.    Result:     OK - UID command completed
  9.                NO - UID command error
  10.                BAD - command unknown or arguments invalid
  11.       The UID command has two forms.  In the first form, it takes as its
  12.       arguments a COPY, FETCH, or STORE command with arguments
  13.       appropriate for the associated command.  However, the numbers in
  14.       the message set argument are unique identifiers instead of message
  15.       sequence numbers.
  16. Crispin                                                        [Page 35]
  17. RFC 1730                         IMAP4                     December 1994
  18.       In the second form, the UID command takes a SEARCH command with
  19.       SEARCH command arguments.  The interpretation of the arguments is
  20.       the same as with SEARCH; however, the numbers returned in a SEARCH
  21.       response for a UID SEARCH command are unique identifiers instead
  22.       of message sequence numbers.  For example, the command UID SEARCH
  23.       1:100 UID 443:557 returns the unique identifiers corresponding to
  24.       the intersection of the message sequence number set 1:100 and the
  25.       UID set 443:557.
  26.       A unique identifier of a message is a number, and is guaranteed
  27.       not to refer to any other message in the mailbox.  Unique
  28.       identifiers are assigned in a strictly ascending fashion for each
  29.       message added to the mailbox.  Unlike message sequence numbers,
  30.       unique identifiers persist across sessions.  This permits a client
  31.       to resynchronize its state from a previous session with the server
  32.       (e.g.  disconnected or offline access clients); this is discussed
  33.       further in [IMAP-DISC].
  34.       Associated with every mailbox is a unique identifier validity
  35.       value, which is sent in an UIDVALIDITY response code in an OK
  36.       untagged response at message selection time.  If unique
  37.       identifiers from an earlier session fail to persist to this
  38.       session, the unique identifier validity value MUST be greater than
  39.       in the earlier session.
  40.            Note: An example of a good value to use for the unique
  41.            identifier validity value would be a 32-bit
  42.            representation of the creation date/time of the mailbox.
  43.            It is alright to use a constant such as 1, but only if
  44.            it guaranteed that unique identifers will never be
  45.            reused, even in the case of a mailbox being deleted and
  46.            a new mailbox by the same name created at some future
  47.            time.
  48.       Message set ranges are permitted; however, there is no guarantee
  49.       that unique identifiers be contiguous.  A non-existent unique
  50.       identifier within a message set range is ignored without any error
  51.       message generated.
  52.       The number after the "*" in an untagged FETCH response is always a
  53.       message sequence number, not a unique identifier, even for a UID
  54.       command response.  However, server implementations MUST implicitly
  55.       include the UID message data item as part of any FETCH response
  56.       caused by a UID command, regardless of whether UID was specified
  57.       as a message data item to the FETCH.
  58. Crispin                                                        [Page 36]
  59. RFC 1730                         IMAP4                     December 1994
  60.    Example:    C: A003 UID FETCH 4827313:4828442 FLAGS
  61.                S: * 23 FETCH (FLAGS (Seen) UID 4827313)
  62.                S: * 24 FETCH (FLAGS (Seen) UID 4827943)
  63.                S: * 25 FETCH (FLAGS (Seen) UID 4828442)
  64.                S: A999 UID FETCH completed
  65. 6.5.    Client Commands - Experimental/Expansion
  66. 6.5.1.  X<atom> Command
  67.    Arguments:  implementation defined
  68.    Data:       implementation defined
  69.    Result:     OK - command completed
  70.                NO - failure
  71.                BAD - command unknown or arguments invalid
  72.       Any command prefixed with an X is an experimental command.
  73.       Commands which are not part of this specification, or a standard
  74.       or standards-track revision of this specification, MUST use the X
  75.       prefix.
  76.       Any added untagged responses issued by an experimental command
  77.       MUST also be prefixed with an X.  Server implementations MUST NOT
  78.       send any such untagged responses, unless the client requested it
  79.       by issuing the associated experimental command.
  80.    Example:    C: a441 CAPABILITY
  81.                S: * CAPABILITY IMAP4 XPIG-LATIN
  82.                S: a441 OK CAPABILITY completed
  83.                C: A442 XPIG-LATIN
  84.                S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay
  85.                S: A442 OK XPIG-LATIN ompleted-cay
  86. Crispin                                                        [Page 37]
  87. RFC 1730                         IMAP4                     December 1994
  88. 7.      Server Responses
  89.    Server responses are in three forms: status responses, server data,
  90.    and command continuation request.
  91.    Server response data, identified by "Data:" in the response
  92.    descriptions below, are described by function, not by syntax.  The
  93.    precise syntax of server response data is described in the Formal
  94.    Syntax section.
  95.    The client MUST be prepared to accept any response at all times.
  96.    Status responses that are tagged indicate the completion result of a
  97.    client command, and have a tag matching the command.
  98.    Some status responses, and all server data, are untagged.  An
  99.    untagged response is indicated by the token "*" instead of a tag.
  100.    Untagged status responses indicate server greeting, or server status
  101.    that does not indicate the completion of a command.  For historical
  102.    reasons, untagged server data responses are also called "unsolicited
  103.    data", although strictly speaking only unilateral server data is
  104.    truly "unsolicited".
  105.    Certain server data MUST be recorded by the client when it is
  106.    received; this is noted in the description of that data.  Such data
  107.    conveys critical information which affects the interpretation of all
  108.    subsequent commands and responses (e.g. updates reflecting the
  109.    creation or destruction of messags).
  110.    Other server data SHOULD be recorded for later reference; if the
  111.    client does not need to record the data, or if recording the data has
  112.    no obvious purpose (e.g. a SEARCH response when no SEARCH command is
  113.    in progress), the data SHOULD be ignored.
  114.    An example of unilateral untagged responses occurs when the IMAP
  115.    connection is in selected state.  In selected state, the server
  116.    checks the mailbox for new messages as part of the execution of each
  117.    command.  If new messages are found, the server sends untagged EXISTS
  118.    and RECENT responses reflecting the new size of the mailbox.  Server
  119.    implementations that offer multiple simultaneous access to the same
  120.    mailbox should also send appropriate unilateral untagged FETCH and
  121.    EXPUNGE responses if another agent changes the state of any message
  122.    flags or expunges any messages.
  123.    Command continuation request responses use the token "+" instead of a
  124.    tag.  These responses are sent by the server to indicate acceptance
  125.    of an incomplete client command and readiness for the remainder of
  126.    the command.
  127. Crispin                                                        [Page 38]
  128. RFC 1730                         IMAP4                     December 1994
  129. 7.1.    Server Responses - Status Responses
  130.    Status responses may include an optional response code.  A response
  131.    code consists of data inside square brackets in the form of an atom,
  132.    possibly followed by a space and arguments.  The response code
  133.    contains additional information or status codes for client software
  134.    beyond the OK/NO/BAD condition, and are defined when there is a
  135.    specific action that a client can take based upon the additional
  136.    information.
  137.    The currently defined response codes are:
  138.       ALERT          The human-readable text contains a special alert
  139.                      that MUST be presented to the user in a fashion
  140.                      that calls the user's attention to the message.
  141.       PARSE          The human-readable text represents an error in
  142.                      parsing the [RFC-822] or [MIME-1] headers of a
  143.                      message in the mailbox.
  144.       PERMANENTFLAGS Followed by a parenthesized list of flags,
  145.                      indicates which of the known flags that the client
  146.                      may change permanently.  Any flags that are in the
  147.                      FLAGS untagged response, but not the PERMANENTFLAGS
  148.                      list, can not be set permanently.  If the client
  149.                      attempts to STORE a flag that is not in the
  150.                      PERMANENTFLAGS list, the server will either reject
  151.                      it with a NO reply or store the state for the
  152.                      remainder of the current session only.  The
  153.                      PERMANENTFLAGS list may also include the special
  154.                      flag *, which indicates that it is possible to
  155.                      create new keywords by attempting to store those
  156.                      flags in the mailbox.
  157.       READ-ONLY      The mailbox is selected read-only, or its access
  158.                      while selected has changed from read-write to
  159.                      read-only.
  160.       READ-WRITE     The mailbox is selected read-write, or its access
  161.                      while selected has changed from read-only to
  162.                      read-write.
  163.       TRYCREATE      An APPEND or COPY attempt is failing because the
  164.                      target mailbox does not exist (as opposed to some
  165.                      other reason).  This is a hint to the client that
  166.                      the operation may succeed if the mailbox is first
  167.                      created by the CREATE command.
  168. Crispin                                                        [Page 39]
  169. RFC 1730                         IMAP4                     December 1994
  170.       UIDVALIDITY    Followed by a decimal number, indicates the unique
  171.                      identifier validity value.  See the description of
  172.                      the UID command for more detail.
  173.       UNSEEN         Followed by a decimal number, indicates the number
  174.                      of the first message without the Seen flag set.
  175.       Additional response codes defined by particular client or server
  176.       implementations should be prefixed with an "X" until they are
  177.       added to a revision of this protocol.  Client implementations
  178.       should ignore response codes that they do not recognize.
  179. 7.1.1.  OK Response
  180.    Data:       optional response code
  181.                human-readable text
  182.       The OK response indicates an information message from the server.
  183.       When tagged, it indicates successful completion of the associated
  184.       command.  The human-readable text may be presented to the user as
  185.       an information message.  The untagged form indicates an
  186.       information-only message; the nature of the information may be
  187.       indicated by a response code.
  188.       The untagged form is also used as one of three possible greetings
  189.       at session startup.  It indicates that the session is not yet
  190.       authenticated and that a LOGIN command is needed.
  191.    Example:    S: * OK IMAP4 server ready
  192.                C: A001 LOGIN fred blurdybloop
  193.                S: * OK [ALERT] System shutdown in 10 minutes
  194.                S: A001 OK LOGIN Completed
  195. 7.1.2.  NO Response
  196.    Data:       optional response code
  197.                human-readable text
  198.       The NO response indicates an operational error message from the
  199.       server.  When tagged, it indicates unsuccessful completion of the
  200.       associated command.  The untagged form indicates a warning; the
  201.       command may still complete successfully.  The human-readable text
  202.       describes the condition.
  203. Crispin                                                        [Page 40]
  204. RFC 1730                         IMAP4                     December 1994
  205.    Example:    C: A222 COPY 1:2 owatagusiam
  206.                S: * NO Disk is 98% full, please delete unnecessary data
  207.                S: A222 OK COPY completed
  208.                C: A222 COPY 3:200 blurdybloop
  209.                S: * NO Disk is 98% full, please delete unnecessary data
  210.                S: * NO Disk is 99% full, please delete unnecessary data
  211.                S: A222 NO COPY failed: disk is full
  212. 7.1.3.  BAD Response
  213.    Data:       optional response code
  214.                human-readable text
  215.       The BAD response indicates an error message from the server.  When
  216.       tagged, it reports a protocol-level error in the client's command;
  217.       the tag indicates the command that caused the error.  The untagged
  218.       form indicates a protocol-level error for which the associated
  219.       command can not be determined; it may also indicate an internal
  220.       server failure.  The human-readable text describes the condition.
  221.    Example:    C: ...very long command line...
  222.                S: * BAD Command line too long
  223.                C: ...empty line...
  224.                S: * BAD Empty command line
  225.                C: A443 EXPUNGE
  226.                S: * BAD Disk crash, attempting salvage to a new disk!
  227.                S: * OK Salvage successful, no data lost
  228.                S: A443 OK Expunge completed
  229. 7.1.4.  PREAUTH Response
  230.    Data:       optional response code
  231.                human-readable text
  232.       The PREAUTH response is always untagged, and is one of three
  233.       possible greetings at session startup.  It indicates that the
  234.       session has already been authenticated by external means and thus
  235.       no LOGIN command is needed.
  236.    Example:    S: * PREAUTH IMAP4 server ready and logged in as Smith
  237. Crispin                                                        [Page 41]
  238. RFC 1730                         IMAP4                     December 1994
  239. 7.1.5.  BYE Response
  240.    Data:       optional response code
  241.                human-readable text
  242.       The BYE response is always untagged, and indicates that the server
  243.       is about to close the connection.  The human-readable text may be
  244.       displayed to the user in a status report by the client.  The BYE
  245.       response may be sent as part of a normal logout sequence, or as a
  246.       panic shutdown announcement by the server.  It is also used by
  247.       some server implementations as an announcement of an inactivity
  248.       autologout.
  249.       This response is also used as one of three possible greetings at
  250.       session startup.  It indicates that the server is not willing to
  251.       accept a session from this client.
  252.    Example:    S: * BYE Autologout; idle for too long
  253. 7.2.    Server Responses - Server and Mailbox Status
  254.    These responses are always untagged.  This is how server data are
  255.    transmitted from the server to the client, often as a result of a
  256.    command with the same name.
  257. 7.2.1.  CAPABILITY Response
  258.    Data:       capability listing
  259.       The CAPABILITY response occurs as a result of a CAPABILITY
  260.       command.  The capability listing contains a space-separated
  261.       listing of capability names that the server supports.  The first
  262.       name in the capability listing MUST be the atom "IMAP4".
  263.       A capability name other than IMAP4 indicates that the server
  264.       supports an extension, revision, or amendment to the IMAP4
  265.       protocol.  Server responses MUST conform to this document until
  266.       the client issues a command that uses the associated capability.
  267.       Capability names MUST either begin with "X" or be standard or
  268.       standards-track IMAP4 extensions, revisions, or amendments
  269.       registered with IANA.  A server MUST NOT offer unregistered or
  270.       non-standard capability names, unless such names are prefixed with
  271.       an "X".
  272. Crispin                                                        [Page 42]
  273. RFC 1730                         IMAP4                     December 1994
  274.       Client implementations SHOULD NOT require any capability name
  275.       other than "IMAP4", and MUST ignore any unknown capability names.
  276.    Example:    S: * CAPABILITY IMAP4 XPIG-LATIN
  277. 7.2.2.  LIST Response
  278.    Data:       name attributes
  279.                hierarchy delimiter
  280.                name
  281.       The LIST response occurs as a result of a LIST command.  It
  282.       returns a single name that matches the LIST specification.  There
  283.       may be multiple LIST responses for a single LIST command.
  284.       Four name attributes are defined:
  285.       Noinferiors   It is not possible for any child levels of
  286.                      hierarchy to exist under this name; no child levels
  287.                      exist now and none can be created in the future.
  288.       Noselect      It is not possible to use this name as a selectable
  289.                      mailbox.
  290.       Marked        The mailbox has been marked "interesting" by the
  291.                      server; the mailbox probably contains messages that
  292.                      have been added since the last time the mailbox was
  293.                      selected.
  294.       Unmarked      The mailbox does not contain any additional
  295.                      messages since the last time the mailbox was
  296.                      selected.
  297.       If it is not feasible for the server to determine whether the
  298.       mailbox is "interesting" or not, or if the name is a Noselect
  299.       name, the server should not send either Marked or Unmarked.
  300.       The hierarchy delimiter is a character used to delimit levels of
  301.       hierarchy in a mailbox name.  A client may use it to create child
  302.       mailboxes, and to search higher or lower levels of naming
  303.       hierarchy.  All children of a top-level hierarchy node must use
  304.       the same separator character.  A NIL hierarchy delimiter means
  305.       that no hierarchy exists; the name is a "flat" name.
  306. Crispin                                                        [Page 43]
  307. RFC 1730                         IMAP4                     December 1994
  308.       The name represents an unambiguous left-to-right hierarchy, and
  309.       MUST be valid for use as a reference in LIST and LSUB commands.
  310.       Unless Noselect is indicated, the name must also be valid as an
  311.       argument for commands, such as SELECT, that accept mailbox names.
  312.    Example:    S: * LIST (Noselect) "/" ~/Mail/foo
  313. 7.2.3.  LSUB Response
  314.    Data:       name attributes
  315.                hierarchy delimiter
  316.                name
  317.       The LSUB response occurs as a result of an LSUB command.  It
  318.       returns a single name that matches the LSUB specification.  There
  319.       may be multiple LSUB responses for a single LSUB command.  The
  320.       data is identical in format to the LIST response.
  321.    Example:    S: * LSUB () "." #news.comp.mail.misc
  322. 7.2.4.  SEARCH Response
  323.    Data:       zero or more numbers
  324.       The SEARCH response occurs as a result of a SEARCH or UID SEARCH
  325.       command.  The number(s) refer to those messages that match the
  326.       search criteria.  For SEARCH, these are message sequence numbers;
  327.       for UID SEARCH, these are unique identifiers.  Each number is
  328.       delimited by a space.
  329.    Example:    S: * SEARCH 2 3 6
  330. 7.2.5.  FLAGS Response
  331.    Data:       flag parenthesized list
  332.       The FLAGS response occurs as a result of a SELECT or EXAMINE
  333.       command.  The flag parenthesized list identifies the flags (at a
  334.       minimum, the system-defined flags) that are applicable for this
  335.       mailbox.  Flags other than the system flags may also exist,
  336.       depending on server implementation.
  337.       The update from the FLAGS response MUST be recorded by the client.
  338.    Example:    S: * FLAGS (Answered Flagged Deleted Seen Draft)
  339. Crispin                                                        [Page 44]
  340. RFC 1730                         IMAP4                     December 1994
  341. 7.3.    Server Responses - Message Status
  342.    These responses are always untagged.  This is how message data are
  343.    transmitted from the server to the client, often as a result of a
  344.    command with the same name.  Immediately following the "*" token is a
  345.    number that represents either a message sequence number or a message
  346.    count.
  347. 7.3.1.  EXISTS Response
  348.    Data:       none
  349.       The EXISTS response reports the number of messages in the mailbox.
  350.       This response occurs as a result of a SELECT or EXAMINE command,
  351.       and if the size of the mailbox changes (e.g. new mail).
  352.       The update from the EXISTS response MUST be recorded by the
  353.       client.
  354.    Example:    S: * 23 EXISTS
  355. 7.3.2.  RECENT Response
  356.    Data:       none
  357.       The RECENT response reports the number of messages that have
  358.       arrived since the previous time a SELECT command was done on this
  359.       mailbox.  This response occurs as a result of a SELECT or EXAMINE
  360.       command, and if the size of the mailbox changes (e.g. new mail).
  361.       The update from the RECENT response MUST be recorded by the
  362.       client.
  363.    Example:    S: * 5 RECENT
  364. 7.3.3.  EXPUNGE Response
  365.    Data:       none
  366.       The EXPUNGE response reports that the specified message sequence
  367.       number has been permanently removed from the mailbox.  The message
  368.       sequence number for each successive message in the mailbox is
  369.       immediately decremented by 1, and this decrement is reflected in
  370.       message sequence numbers in subsequent responses (including other
  371.       untagged EXPUNGE responses).
  372. Crispin                                                        [Page 45]
  373. RFC 1730                         IMAP4                     December 1994
  374.       As a result of the immediate decrement rule, message sequence
  375.       numbers that appear in a set of successive EXPUNGE responses
  376.       depend upon whether the messages are removed starting from lower
  377.       numbers to higher numbers, or from higher numbers to lower
  378.       numbers.  For example, if the last 5 messages in a 9-message
  379.       mailbox are expunged; a "lower to higher" server will send five
  380.       untagged EXPUNGE responses for message sequence number 5, whereas
  381.       a "higher to lower server" will send successive untagged EXPUNGE
  382.       responses for message sequence numbers 9, 8, 7, 6, and 5.
  383.       An EXPUNGE response MUST NOT be sent when no command is in
  384.       progress; nor while responding to a FETCH, STORE, or SEARCH
  385.       command.  This rule is necessary to prevent a loss of
  386.       synchronization of message sequence numbers between client and
  387.       server.
  388.       The update from the EXPUNGE response MUST be recorded by the
  389.       client.
  390.    Example:    S: * 44 EXPUNGE
  391. 7.3.4.  FETCH Response
  392.    Data:       message data
  393.       The FETCH response returns data about a message to the client.
  394.       The data are pairs of data item names and their values in
  395.       parentheses.  This response occurs as the result of a FETCH or
  396.       STORE command, as well as by unilateral server decision (e.g. flag
  397.       updates).
  398.       The current data items are:
  399.       BODY           A form of BODYSTRUCTURE without extension data.
  400.       BODY[section]  A string expressing the body contents of the
  401.                      specified section.  The string should be
  402.                      interpreted by the client according to the content
  403.                      transfer encoding, body type, and subtype.
  404.                      8-bit textual data is permitted if a character set
  405.                      identifier is part of the body parameter
  406.                      parenthesized list for this section.
  407.                      Non-textual data such as binary data must be
  408.                      transfer encoded into a textual form such as BASE64
  409.                      prior to being sent to the client.  To derive the
  410. Crispin                                                        [Page 46]
  411. RFC 1730                         IMAP4                     December 1994
  412.                      original binary data, the client must decode the
  413.                      transfer encoded string.
  414.       BODYSTRUCTURE  A parenthesized list that describes the body
  415.                      structure of a message.  This is computed by the
  416.                      server by parsing the [RFC-822] header and body
  417.                      into the component parts, defaulting various fields
  418.                      as necessary.
  419.                      Multiple parts are indicated by parenthesis
  420.                      nesting.  Instead of a body type as the first
  421.                      element of the parenthesized list there is a nested
  422.                      body.  The second element of the parenthesized list
  423.                      is the multipart subtype (mixed, digest, parallel,
  424.                      alternative, etc.).
  425.                      Extension data follows the multipart subtype.
  426.                      Extension data is never returned with the BODY
  427.                      fetch, but may be returned with a BODYSTRUCTURE
  428.                      fetch.  Extension data, if present, must be in the
  429.                      defined order.
  430.                      The extension data of a multipart body part are in
  431.                      the following order:
  432.                      body parameter parenthesized list
  433.                         A parenthesized list of attribute/value pairs
  434.                         [e.g. (foo bar baz rag) where "bar" is the value
  435.                         of "foo" and "rag" is the value of "baz"] as
  436.                         defined in [MIME-1].
  437.                      Any following extension data are not yet defined in
  438.                      this version of the protocol.  Such extension data
  439.                      may consist of zero or more NILs, strings, numbers,
  440.                      or potentially nested parenthesized lists of such
  441.                      data.  Client implementations that do a
  442.                      BODYSTRUCTURE fetch MUST be prepared to accept such
  443.                      extension data.  Server implementations MUST NOT
  444.                      send such extension data until it has been defined
  445.                      by a revision of this protocol.
  446.                      The basic fields of a non-multipart body part are
  447.                      in the following order:
  448.                      body type
  449.                         A string giving the content type name as defined
  450.                         in [MIME-1].
  451. Crispin                                                        [Page 47]
  452. RFC 1730                         IMAP4                     December 1994
  453.                      body subtype
  454.                         A string giving the content subtype name as
  455.                         defined in [MIME-1].
  456.                      body parameter parenthesized list
  457.                         A parenthesized list of attribute/value pairs
  458.                         [e.g. (foo bar baz rag) where "bar" is the value
  459.                         of "foo" and "rag" is the value of "baz"] as
  460.                         defined in [MIME-1].
  461.                      body id
  462.                         A string giving the content id as defined in
  463.                         [MIME-1].
  464.                      body description
  465.                         A string giving the content description as
  466.                         defined in [MIME-1].
  467.                      body encoding
  468.                         A string giving the content transfer encoding as
  469.                         defined in [MIME-1].
  470.                      body size
  471.                         A number giving the size of the body in octets.
  472.                         Note that this size is the size in its transfer
  473.                         encoding and not the resulting size after any
  474.                         decoding.
  475.                      A body type of type MESSAGE and subtype RFC822
  476.                      contains, immediately after the basic fields, the
  477.                      envelope structure, body structure, and size in
  478.                      text lines of the encapsulated message.
  479.                      A body type of type TEXT contains, immediately
  480.                      after the basic fields, the size of the body in
  481.                      text lines.  Note that this size is the size in its
  482.                      transfer encoding and not the resulting size after
  483.                      any decoding.
  484.                      Extension data follows the basic fields and the
  485.                      type-specific fields listed above.  Extension data
  486.                      is never returned with the BODY fetch, but may be
  487.                      returned with a BODYSTRUCTURE fetch.  Extension
  488.                      data, if present, must be in the defined order.
  489.                      The extension data of a non-multipart body part are
  490.                      in the following order:
  491. Crispin                                                        [Page 48]
  492. RFC 1730                         IMAP4                     December 1994
  493.                      body MD5
  494.                         A string giving the content MD5 value as defined
  495.                         in [MIME-1].
  496.                      Any following extension data are not yet defined in
  497.                      this version of the protocol, and would be as
  498.                      described above under multipart extension data.
  499.       ENVELOPE       A parenthesized list that describes the envelope
  500.                      structure of a message.  This is computed by the
  501.                      server by parsing the [RFC-822] header into the
  502.                      component parts, defaulting various fields as
  503.                      necessary.
  504.                      The fields of the envelope structure are in the
  505.                      following order: date, subject, from, sender,
  506.                      reply-to, to, cc, bcc, in-reply-to, and message-id.
  507.                      The date, subject, in-reply-to, and message-id
  508.                      fields are strings.  The from, sender, reply-to,
  509.                      to, cc, and bcc fields are parenthesized lists of
  510.                      address structures.
  511.                      An address structure is a parenthesized list that
  512.                      describes an electronic mail address.  The fields
  513.                      of an address structure are in the following order:
  514.                      personal name, [SMTP] at-domain-list (source
  515.                      route), mailbox name, and host name.
  516.                      [RFC-822] group syntax is indicated by a special
  517.                      form of address structure in which the host name
  518.                      field is NIL.  If the mailbox name field is also
  519.                      NIL, this is an end of group marker (semi-colon in
  520.                      RFC 822 syntax).  If the mailbox name field is
  521.                      non-NIL, this is a start of group marker, and the
  522.                      mailbox name field holds the group name phrase.
  523.                      Any field of an envelope or address structure that
  524.                      is not applicable is presented as NIL.  Note that
  525.                      the server must default the reply-to and sender
  526.                      fields from the from field; a client is not
  527.                      expected to know to do this.
  528. Crispin                                                        [Page 49]
  529. RFC 1730                         IMAP4                     December 1994
  530.       FLAGS          A parenthesized list of flags that are set for this
  531.                      message.  This may include keywords as well as the
  532.                      following system flags:
  533.                      Seen       Message has been read
  534.                      Answered   Message has been answered
  535.                      Flagged    Message is "flagged" for urgent/special
  536.                                  attention
  537.                      Deleted    Message is "deleted" for removal by
  538.                                  later EXPUNGE
  539.                      Draft      Message has not completed composition
  540.                                  (marked as a draft).
  541.                      as well as the following special flag, which may be
  542.                      fetched but not stored:
  543.                      Recent     Message has arrived since the previous
  544.                                  time this mailbox was selected.
  545.       INTERNALDATE   A string containing the date and time of final
  546.                      delivery of the message as defined by [SMTP].
  547.       RFC822         A string expressing the message in [RFC-822]
  548.                      format.  The header portion of the message must be
  549.                      7-bit.  8-bit characters are permitted only in the
  550.                      non-header portion of the message only if there are
  551.                      [MIME-1] data in the message that identify the
  552.                      character set of the message.
  553.       RFC822.HEADER  A string expressing the [RFC-822] format header of
  554.                      the message, including the delimiting blank line
  555.                      between the header and the body.  The entire string
  556.                      must be 7-bit; 8-bit characters are not permitted
  557.                      in headers.  RFC822.HEADER is used to return data
  558.                      for the RFC822.HEADER, RFC822.HEADER.LINES, and
  559.                      RFC822.HEADER.LINES.NOT FETCH data items.  Note
  560.                      that a blank line is always included regardless of
  561.                      header line restrictions.
  562.       RFC822.SIZE    A number expressing the number of octets in the
  563.                      message in [RFC-822] format.
  564. Crispin                                                        [Page 50]
  565. RFC 1730                         IMAP4                     December 1994
  566.       RFC822.TEXT    A string expressing the text body of the message,
  567.                      omitting the [RFC-822] header.  8-bit characters
  568.                      are permitted only if there are [MIME-1] data in
  569.                      the message that identify the character set of the
  570.                      message.
  571.       UID            A number expressing the unique identifier of the
  572.                      message.
  573.    Example:    S: * 23 FETCH (FLAGS (Seen) RFC822.SIZE 44827)
  574. 7.3.5.  Obsolete Responses
  575.    In addition to the responses listed in here, client implementations
  576.    MUST accept and implement the obsolete responses described in
  577.    Appendix B.
  578. 7.4.    Server Responses - Command Continuation Request
  579.    The command completion request response is indicated by a "+" token
  580.    instead of a tag.  This form of response indicates that the server is
  581.    ready to accept the continuation of a command from the client.  The
  582.    remainder of this response is a line of text.
  583.    This response is used in the AUTHORIZATION command to transmit server
  584.    data to the client, and request additional client data.  This
  585.    response is also used if an argument to any command is a literal.
  586.    The client is not permitted to send the octets of the literal unless
  587.    the server indicates that it expects it.  This permits the server to
  588.    process commands and reject errors on a line-by-line basis.  The
  589.    remainder of the command, including the CRLF that terminates a
  590.    command, follows the octets of the literal.  If there are any
  591.    additional command arguments the literal octets are followed by a
  592.    space and those arguments.
  593.    Example:    C: A001 LOGIN {11}
  594.                S: + Ready for additional command text
  595.                C: FRED FOOBAR {7}
  596.                S: + Ready for additional command text
  597.                C: fat man
  598.                S: A001 OK LOGIN completed
  599.                C: A044 BLURDYBLOOP {102856}
  600.                S: A044 BAD No such command as "BLURDYBLOOP"
  601. Crispin                                                        [Page 51]
  602. RFC 1730                         IMAP4                     December 1994
  603. 8.      Sample IMAP4 session
  604.    The following is a transcript of an IMAP4 session.  A long line in
  605.    this sample is broken for editorial clarity.
  606.    S:   * OK IMAP4 Service Ready
  607.    C:   a001 login mrc secret
  608.    S:   a001 OK LOGIN completed
  609.    C:   a002 select inbox
  610.    S:   * 18 EXISTS
  611.    S:   * FLAGS (Answered Flagged Deleted Seen Draft)
  612.    S:   * 2 RECENT
  613.    S:   * OK [UNSEEN 17] Message 17 is the first unseen message
  614.    S:   * OK [UIDVALIDITY 3857529045] UIDs valid
  615.    S:   a002 OK [READ-WRITE] SELECT completed
  616.    C:   a003 fetch 12 full
  617.    S:   * 12 FETCH (FLAGS (Seen) INTERNALDATE "14-Jul-1993 02:44:25 -0700"
  618.          RFC822.SIZE 4282 ENVELOPE ("Wed, 14 Jul 1993 02:23:25 -0700 (PDT)"
  619.          "IMAP4 WG mtg summary and minutes"
  620.          (("Terry Gray" NIL "gray" "cac.washington.edu"))
  621.          (("Terry Gray" NIL "gray" "cac.washington.edu"))
  622.          (("Terry Gray" NIL "gray" "cac.washington.edu"))
  623.          ((NIL NIL "imap" "cac.washington.edu"))
  624.          ((NIL NIL "minutes" "CNRI.Reston.VA.US")
  625.          ("John Klensin" NIL "KLENSIN" "INFOODS.MIT.EDU")) NIL NIL
  626.          "<B27397-0100000@cac.washington.edu>")
  627.           BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92))
  628.    S:    a003 OK FETCH completed
  629.    C:    a004 fetch 12 rfc822.header
  630.    S:    * 12 FETCH (RFC822.HEADER {346}
  631.    S:    Date: Wed, 14 Jul 1993 02:23:25 -0700 (PDT)
  632.    S:    From: Terry Gray <gray@cac.washington.edu>
  633.    S:    Subject: IMAP4 WG mtg summary and minutes
  634.    S:    To: imap@cac.washington.edu
  635.    S:    cc: minutes@CNRI.Reston.VA.US, John Klensin <KLENSIN@INFOODS.MIT.EDU>
  636.    S:    Message-Id: <B27397-0100000@cac.washington.edu>
  637.    S:    MIME-Version: 1.0
  638.    S:    Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
  639.    S:
  640.    S:    )
  641.    S:    a004 OK FETCH completed
  642.    C:    a005 store 12 +flags deleted
  643.    S:    * 12 FETCH (FLAGS (Seen Deleted))
  644.    S:    a005 OK +FLAGS completed
  645.    C:    a006 logout
  646.    S:    * BYE IMAP4 server terminating connection
  647.    S:    a006 OK LOGOUT completed
  648. Crispin                                                        [Page 52]
  649. RFC 1730                         IMAP4                     December 1994
  650. 9.      Formal Syntax
  651.    The following syntax specification uses the augmented Backus-Naur
  652.    Form (BNF) notation as specified in [RFC-822] with one exception; the
  653.    delimiter used with the "#" construct is a single space (SPACE) and
  654.    not a comma.
  655.    Except as noted otherwise, all alphabetic characters are
  656.    case-insensitive.  The use of upper or lower case characters to
  657.    define token strings is for editorial clarity only.  Implementations
  658.    MUST accept these strings in a case-insensitive fashion.
  659.    Syntax marked as obsolete may be encountered with implementations
  660.    written for an earlier version of this protocol (e.g. IMAP2).  New
  661.    implementations SHOULD accept obsolete syntax as input, but MUST NOT
  662.    otherwise use such syntax.
  663.    address         ::= "(" addr_name SPACE addr_adl SPACE addr_mailbox
  664.                        SPACE addr_host ")"
  665.    addr_adl        ::= nstring
  666.    addr_host       ::= nstring
  667.                        ;; NIL indicates [RFC-822] group syntax
  668.    addr_mailbox    ::= nstring
  669.                        ;; NIL indicates end of [RFC-822] group; if
  670.                        ;; non-NIL and addr_host is NIL, holds
  671.                        ;; [RFC-822] group name
  672.    addr_name       ::= nstring
  673.    alpha           ::= "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" /
  674.                        "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" /
  675.                        "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" /
  676.                        "Y" / "Z" /
  677.                        "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" /
  678.                        "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" /
  679.                        "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" /
  680.                        "y" / "z" /
  681.                        ;; Case-sensitive
  682.    append          ::= "APPEND" SPACE mailbox [SPACE flag_list]
  683.                        [SPACE date_time] SPACE literal
  684.    astring         ::= atom / string
  685. Crispin                                                        [Page 53]
  686. RFC 1730                         IMAP4                     December 1994
  687.    atom            ::= 1*ATOM_CHAR
  688.    ATOM_CHAR       ::= <any CHAR except atom_specials>
  689.    atom_specials   ::= "(" / ")" / "{" / SPACE / CTLs / list_wildcards /
  690.                        quoted_specials
  691.    authenticate    ::= "AUTHENTICATE" SPACE auth_type *(CRLF base64)
  692.    auth_type       ::= atom
  693.    base64          ::= *(4base64_char) [base64_terminal]
  694.    base64_char     ::= alpha / digit / "+" / "/"
  695.    base64_terminal ::= (2base64_char "==") / (3base64_char "=")
  696.    body            ::= "(" body_type_1part / body_type_mpart ")"
  697.    body_extension  ::= nstring / number / "(" 1#body_extension ")"
  698.                        ;; Future expansion.  Client implementations
  699.                        ;; MUST accept body_extension fields.  Server
  700.                        ;; implementations MUST NOT generate
  701.                        ;; body_extension fields except as defined by
  702.                        ;; future standard or standards-track
  703.                        ;; revisions of this specification.
  704.    body_ext_1part  ::= body_fld_md5 [SPACE 1#body_extension]
  705.                        ;; MUST NOT be returned on non-extensible
  706.                        ;; "BODY" fetch
  707.    body_ext_mpart  ::= body_fld_param [SPACE 1#body_extension]]
  708.                        ;; MUST NOT be returned on non-extensible
  709.                        ;; "BODY" fetch
  710.    body_fields     ::= body_fld_param SPACE body_fld_id SPACE
  711.                        body_fld_desc SPACE body_fld_enc SPACE
  712.                        body_fld_octets
  713.    body_fld_desc   ::= nstring
  714.    body_fld_enc    ::= (<"> ("7BIT" / "8BIT" / "BINARY" / "BASE64"/
  715.                        "QUOTED-PRINTABLE") <">) / string
  716.    body_fld_id     ::= nstring
  717.    body_fld_lines  ::= number
  718. Crispin                                                        [Page 54]
  719. RFC 1730                         IMAP4                     December 1994
  720.    body_fld_md5    ::= nstring
  721.    body_fld_octets ::= number
  722.    body_fld_param  ::= "(" 1#(string string) ")" / nil
  723.    body_fld_subtyp ::= string
  724.    body_type_1part ::= (body_type_basic / body_type_msg / body_type_text)
  725.                        [SPACE body_ext_1part]
  726.    body_type_basic ::= (<"> ("APPLICATION" / "AUDIO" / "IMAGE" /
  727.                        "MESSAGE" / "VIDEO") <">) / string) SPACE
  728.                        body_fld_subtyp SPACE body_fields
  729.                        ;; MESSAGE subtype MUST NOT be "RFC822"
  730.    body_type_mpart ::= 1*body SPACE body_fld_subtyp
  731.                        [SPACE body_ext_mpart]
  732.    body_type_msg   ::= <"> "MESSAGE" <"> SPACE <"> "RFC822" <"> SPACE
  733.                        body_fields SPACE envelope SPACE body SPACE
  734.                        body_fld_lines
  735.    body_type_text  ::= <"> "TEXT" <"> SPACE body_fld_subtyp SPACE
  736.                         body_fields SPACE body_fld_lines
  737.    capability      ::= atom
  738.                        ;; Must begin with "X" or be registered with
  739.                        ;; IANA as standard or standards-track
  740.    capability_data ::= "CAPABILITY" SPACE "IMAP4" [SPACE 1#capability]
  741.    CHAR            ::= <any 7-bit US-ASCII character except NUL,
  742.                         0x01 - 0x7f>
  743.    CHAR8           ::= <any 8-bit octet except NUL, 0x01 - 0xff>
  744.    command         ::= tag SPACE (command_any / command_auth /
  745.                        command_nonauth / command_select) CRLF
  746.                        ;; Modal based on state
  747.    command_any     ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command
  748.                        ;; Valid in all states
  749.    command_auth    ::= append / create / delete / examine / find / list /
  750.                        lsub / rename / select / subscribe / unsubscribe /
  751.                        ;; Valid only in Authenticated or Selected state
  752. Crispin                                                        [Page 55]
  753. RFC 1730                         IMAP4                     December 1994
  754.    command_nonauth ::= login / authenticate
  755.                        ;; Valid only when in Non-Authenticated state
  756.    command_select  ::= "CHECK" / "CLOSE" / "EXPUNGE" /
  757.                         copy / fetch / partial / store / uid / search
  758.                        ;; Valid only when in Selected state
  759.    continue_req    ::= "+" SPACE (resp_text / base64)
  760.    copy            ::= "COPY" SPACE set SPACE mailbox
  761.    CR              ::= <ASCII CR, carriage return, 0x0C>
  762.    create          ::= "CREATE" SPACE mailbox
  763.                        ;; Use of INBOX gives a NO error
  764.    CRLF            ::= CR LF
  765.    CTL             ::= <any ASCII control character and DEL,
  766.                         0x00 - 0x1f, 0x7f>
  767.    date            ::= date_text / <"> date_text <">
  768.    date_day        ::= 1*2digit
  769.                        ;; Day of month
  770.    date_day_fixed  ::= (SPACE digit) / 2digit
  771.                        ;; Fixed-format version of date_day
  772.    date_month      ::= "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" /
  773.                        "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"
  774.    date_text       ::= date_day "-" date_month "-" (date_year /
  775.                        date_year_old)
  776.    date_year       ::= 4digit
  777.    date_year_old   ::= 2digit
  778.                        ;; OBSOLETE, (year - 1900)
  779.    date_time       ::= <"> (date_time_new / date_time_old) <">
  780.    date_time_new   ::= date_day_fixed "-" date_month "-" date_year
  781.                        SPACE time SPACE zone
  782.    date_time_old   ::= date_day_fixed "-" date_month "-" date_year_old
  783.                        SPACE time "-" zone_old
  784.                        ;; OBSOLETE
  785. Crispin                                                        [Page 56]
  786. RFC 1730                         IMAP4                     December 1994
  787.    delete          ::= "DELETE" SPACE mailbox
  788.                        ;; Use of INBOX gives a NO error
  789.    digit           ::= "0" / digit_nz
  790.    digit_nz        ::= "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" /
  791.                        "9"
  792.    envelope        ::= "(" env_date SPACE env_subject SPACE env_from
  793.                        SPACE env_sender SPACE env_reply-to SPACE env_to
  794.                        SPACE env_cc SPACE env_bcc SPACE env_in-reply-to
  795.                        SPACE env_message-id ")"
  796.    env_bcc         ::= "(" 1*address ")" / nil
  797.    env_cc          ::= "(" 1*address ")" / nil
  798.    env_date        ::= nstring
  799.    env_from        ::= "(" 1*address ")" / nil
  800.    env_in-reply-to ::= nstring
  801.    env_message-id  ::= nstring
  802.    env_reply-to    ::= "(" 1*address ")" / nil
  803.    env_sender      ::= "(" 1*address ")" / nil
  804.    env_subject     ::= nstring
  805.    env_to          ::= "(" 1*address ")" / nil
  806.    examine         ::= "EXAMINE" SPACE mailbox
  807.    fetch           ::= "FETCH" SPACE set SPACE ("ALL" / "FULL" /
  808.                        "FAST" / fetch_att / "(" 1#fetch_att ")")
  809.    fetch_att       ::= "BODY" / "BODYSTRUCTURE" /
  810.                        "BODY" [".PEEK"] "[" section "]" / "ENVELOPE" /
  811.                        "FLAGS" / "INTERNALDATE" / "UID" /
  812.                        "RFC822" (([".TEXT"] [".PEEK"]) / ".SIZE" /
  813.                        (".HEADER" [".LINES" [".NOT"] SPACE header_list])
  814.    find            ::= "FIND" SPACE ["ALL."] "MAILBOXES" SPACE
  815.                        list_mailbox
  816.                        ;; OBSOLETE
  817. Crispin                                                        [Page 57]
  818. RFC 1730                         IMAP4                     December 1994
  819.    flag            ::= "Answered" / "Flagged" / "Deleted" /
  820.                        "Seen" / "Draft" / flag_keyword  /
  821.                        flag_extension
  822.    flag_extension  ::= "" atom
  823.                        ;; Future expansion.  Client implementations
  824.                        ;; MUST accept flag_extension flags.  Server
  825.                        ;; implementations MUST NOT generate
  826.                        ;; flag_extension flags except as defined by
  827.                        ;; future standard or standards-track
  828.                        ;; revisions of this specification.
  829.    flag_keyword    ::= atom
  830.    flag_list       ::= "(" #flag ")"
  831.    greeting        ::= "*" SPACE (resp_cond_auth / resp_cond_bye) CRLF
  832.    header_line     ::= astring
  833.    header_list     ::= "(" 1#header_line ")"
  834.    LF              ::= <ASCII LF, line feed, 0x0A>
  835.    list            ::= "LIST" SPACE mailbox SPACE list_mailbox
  836.    list_mailbox    ::= 1*(ATOM_CHAR / list_wildcards) / string
  837.    list_wildcards  ::= "%" / "*"
  838.    literal         ::= "{" number "}" CRLF *CHAR8
  839.                        ;; Number represents the number of CHAR8 octets
  840.    login           ::= "LOGIN" SPACE userid SPACE password
  841.    lsub            ::= "LSUB" SPACE mailbox SPACE list_mailbox
  842.    mailbox         ::= "INBOX" / astring
  843.                        ;; INBOX is case-insensitive; other names may be
  844.                        ;; case-sensitive depending on implementation.
  845.    mailbox_data    ::=  "FLAGS" SPACE flag_list /
  846.                         "LIST" SPACE mailbox_list /
  847.                         "LSUB" SPACE mailbox_list /
  848.                         "MAILBOX" SPACE text /
  849.                         "SEARCH" [SPACE 1#nz_number] /
  850.                         number SPACE "EXISTS" / number SPACE "RECENT"
  851. Crispin                                                        [Page 58]
  852. RFC 1730                         IMAP4                     December 1994
  853.    mailbox_list    ::= "(" #("Marked" / "Noinferiors" /
  854.                        "Noselect" / "Unmarked" / flag_extension) ")"
  855.                        SPACE (<"> QUOTED_CHAR <"> / nil) SPACE mailbox
  856.    message_data    ::= nz_number SPACE ("EXPUNGE" /
  857.                        ("FETCH" SPACE msg_fetch) / msg_obsolete)
  858.    msg_fetch       ::= "(" 1#("BODY" SPACE body /
  859.                        "BODYSTRUCTURE" SPACE body /
  860.                        "BODY[" section "]" SPACE nstring /
  861.                        "ENVELOPE" SPACE envelope /
  862.                        "FLAGS" SPACE "(" #(flag / "Recent") ")" /
  863.                        "INTERNALDATE" SPACE date_time /
  864.                        "RFC822" [".HEADER" / ".TEXT"] SPACE nstring /
  865.                        "RFC822.SIZE" SPACE number /
  866.                        "UID" SPACE uniqueid) ")"
  867.    msg_obsolete    ::= "COPY" / ("STORE" SPACE msg_fetch)
  868.                        ;; OBSOLETE untagged data responses
  869.    nil             ::= "NIL"
  870.    nstring         ::= string / nil
  871.    number          ::= 1*digit
  872.                        ;; Unsigned 32-bit integer
  873.                        ;; (0 <= n < 4,294,967,296)
  874.    nz_number       ::= digit_nz *digit
  875.                        ;; Non-zero unsigned 32-bit integer
  876.                        ;; (0 < n < 4,294,967,296)
  877.    partial         ::= "PARTIAL" SPACE nz_number SPACE
  878.                        ("BODY" [".PEEK"] "[" section "]" /
  879.                        "RFC822" (([".TEXT"] [".PEEK"]) / ".HEADER")
  880.                        SPACE number SPACE number
  881.    password        ::= astring
  882.    quoted          ::= <"> *QUOTED_CHAR <">
  883.    QUOTED_CHAR     ::= <any TEXT_CHAR except quoted_specials> /
  884.                        "" quoted_specials
  885.    quoted_specials ::= <"> / ""
  886.    rename          ::= "RENAME" SPACE mailbox SPACE mailbox
  887.                        ;; Use of INBOX as a destination gives a NO error
  888. Crispin                                                        [Page 59]
  889. RFC 1730                         IMAP4                     December 1994
  890.    response        ::= *response_data response_done
  891.    response_data   ::= "*" SPACE (resp_cond_state / resp_cond_bye /
  892.                        mailbox_data / message_data / capability_data)
  893.                        CRLF
  894.    response_done   ::= response_tagged / response_fatal
  895.    response_fatal  ::= "*" SPACE resp_cond_bye CRLF
  896.    response_tagged ::= tag SPACE resp_cond_state CRLF
  897.    resp_cond_auth  ::= ("OK" / "PREAUTH") SPACE resp_text
  898.                        ;; Authentication condition
  899.    resp_cond_bye   ::= "BYE" SPACE resp_text
  900.                        ;; Server will disconnect condition
  901.    resp_cond_state ::= ("OK" / "NO" / "BAD") SPACE resp_text
  902.                        ;; Status condition
  903.    resp_text       ::= ["[" resp_text_code "]" SPACE] (text_mime2 / text)
  904.    resp_text_code  ::= "ALERT" / "PARSE" /
  905.                        "PERMANENTFLAGS" SPACE "(" #(flag / "*") ")" /
  906.                        "READ-ONLY" / "READ-WRITE" / "TRYCREATE" /
  907.                        "UIDVALIDITY" SPACE nz_number /
  908.                        "UNSEEN" SPACE nz_number /
  909.                        atom [SPACE 1*<any TEXT_CHAR except "]">]
  910.    search          ::= "SEARCH" SPACE ["CHARSET" SPACE astring SPACE]
  911.                        search_criteria
  912.                        ;; Character set must be registered with IANA
  913.                        ;; as a MIME character set
  914.    search_criteria ::= 1#search_key
  915.    search_key      ::= search_new / search_old
  916.    search_new      ::= "DRAFT" /
  917.                        "HEADER" SPACE header_line SPACE astring /
  918.                        "LARGER" SPACE number / "NOT" SPACE search_key /
  919.                        "OR" SPACE search_key SPACE search_key /
  920.                        "SENTBEFORE" SPACE date / "SENTON" SPACE date /
  921.                        "SENTSINCE" SPACE date / "SMALLER" SPACE number /
  922.                        "UID" SPACE set / "UNDRAFT" / set /
  923.                        "(" search_criteria ")"
  924.                        ;; New in IMAP4
  925. Crispin                                                        [Page 60]
  926. RFC 1730                         IMAP4                     December 1994
  927.    search_old      ::= "ALL" / "ANSWERED" / "BCC" SPACE astring /
  928.                        "BEFORE" SPACE date / "BODY" SPACE astring /
  929.                        "CC" SPACE astring / "DELETED" / "FLAGGED" /
  930.                        "FROM" SPACE astring /
  931.                        "KEYWORD" SPACE flag_keyword / "NEW" / "OLD" /
  932.                        "ON" SPACE date / "RECENT" / "SEEN" /
  933.                        "SINCE" SPACE date / "SUBJECT" SPACE astring /
  934.                        "TEXT" SPACE astring / "TO" SPACE astring /
  935.                        "UNANSWERED" / "UNDELETED" / "UNFLAGGED" /
  936.                        "UNKEYWORD" SPACE flag_keyword / "UNSEEN"
  937.                        ;; Defined in [IMAP2]
  938.    section         ::= "0" / nz_number ["." section]
  939.    select          ::= "SELECT" SPACE mailbox
  940.    sequence_num    ::= nz_number / "*"
  941.                        ;; * is the largest number in use.  For message
  942.                        ;; sequence numbers, it is the number of messages
  943.                        ;; in the mailbox.  For unique identifiers, it is
  944.                        ;; the unique identifier of the last message in
  945.                        ;; the mailbox.
  946.    set             ::= sequence_num / (sequence_num ":" sequence_num) /
  947.                        (set "," set)
  948.                        ;; Identifies a set of messages.  For message
  949.                        ;; sequence numbers, these are consecutive
  950.                        ;; numbers from 1 to the number of messages in
  951.                        ;; the mailbox
  952.                        ;; Comma delimits individual numbers, colon
  953.                        ;; delimits between two numbers inclusive.
  954.                        ;; Example: 2,4:7,9,12:* is 2,4,5,6,7,9,12,13,
  955.                        ;; 14,15 for a mailbox with 15 messages.
  956.    SPACE           ::= <ASCII SP, space, 0x20>
  957.    store           ::= "STORE" SPACE set SPACE store_att_flags
  958.    store_att_flags ::= (["+" / "-"] "FLAGS" [".SILENT"]) SPACE
  959.                        (flag_list / #flag)
  960.    string          ::= quoted / literal
  961.    subscribe       ::= ("SUBSCRIBE" SPACE mailbox) / subscribe_obs
  962.    subscribe_obs   ::= "SUBSCRIBE" SPACE "MAILBOX" SPACE mailbox
  963.                        ;;OBSOLETE
  964. Crispin                                                        [Page 61]
  965. RFC 1730                         IMAP4                     December 1994
  966.    tag             ::= 1*<any ATOM_CHAR except "+">
  967.    text            ::= 1*TEXT_CHAR
  968.    text_mime2       ::= "=?" <charset> "?" <encoding> "?"
  969.                         <encoded-text> "?="
  970.                         ;; Syntax defined in [MIME-2]
  971.    TEXT_CHAR       ::= <any CHAR except CR and LF>
  972.    time            ::= 2digit ":" 2digit ":" 2digit
  973.                        ;; Hours minutes seconds
  974.    uid             ::= "UID" SPACE (copy / fetch / search / store)
  975.                        ;; Unique identifiers used instead of message
  976.                        ;; sequence numbers
  977.    uniqueid        ::= nz_number
  978.                        ;; Strictly ascending
  979.    unsubscribe     ::= ("UNSUBSCRIBE" SPACE mailbox) / unsubscribe_obs
  980.    unsubscribe_obs ::= "UNSUBSCRIBE" SPACE "MAILBOX" SPACE mailbox
  981.                        ;;OBSOLETE
  982.    userid          ::= astring
  983.    x_command       ::= "X" atom <experimental command arguments>
  984.    zone            ::= ("+" / "-") 4digit
  985.                        ;; Signed four-digit value of hhmm representing
  986.                        ;; hours and minutes west of Greenwich (that is,
  987.                        ;; (the amount that the given time differs from
  988.                        ;; Universal Time).  Subtracting the timezone
  989.                        ;; from the given time will give the UT form.
  990.                        ;; The Universal Time zone is "+0000".
  991. Crispin                                                        [Page 62]
  992. RFC 1730                         IMAP4                     December 1994
  993.    zone_old        ::= "UT" / "GMT" / "Z" /                ;; +0000
  994.                        "AST" / "EDT" /                     ;; -0400
  995.                        "EST" / "CDT" /                     ;; -0500
  996.                        "CST" / "MDT" /                     ;; -0600
  997.                        "MST" / "PDT" /                     ;; -0700
  998.                        "PST" / "YDT" /                     ;; -0800
  999.                        "YST" / "HDT" /                     ;; -0900
  1000.                        "HST" / "BDT" /                     ;; -1000
  1001.                        "BST" /                             ;; -1100
  1002.                        "A" / "B" / "C" / "D" / "E" / "F" / ;; +1 to +6
  1003.                        "G" / "H" / "I" / "K" / "L" / "M" / ;; +7 to +12
  1004.                        "N" / "O" / "P" / "Q" / "R" / "S" / ;; -1 to -6
  1005.                        "T" / "U" / "V" / "W" / "X" / "Y"   ;; -7 to -12
  1006.                        ;; OBSOLETE
  1007. Crispin                                                        [Page 63]
  1008. RFC 1730                         IMAP4                     December 1994
  1009. 10.     Author's Note
  1010.    This document is a revision or rewrite of earlier documents, and
  1011.    supercedes the protocol specification in those documents: IMAP4
  1012.    Internet drafts, the IMAP2bis Internet drafts, unpublished
  1013.    IMAP2bis.TXT document, RFC 1176, and RFC 1064.
  1014. 11.     Security Considerations
  1015.    IMAP4 protocol transactions, including electronic mail data, are sent
  1016.    in the clear over the network unless the optional privacy protection
  1017.    is negotiated in the AUTHENTICATE command.
  1018.    A server error message for an AUTHENTICATE command which fails due to
  1019.    invalid credentials should not detail why the credentials are
  1020.    invalid.
  1021.    Use of the LOGIN command sends passwords in the clear.  This can be
  1022.    avoided by using the AUTHENTICATE command instead.
  1023.    A server error message for a failing LOGIN command should not specify
  1024.    that the user name, as opposed to the password, is invalid.
  1025.    Additional security considerations are discussed in the section
  1026.    discussing the AUTHENTICATE and LOGIN commands.
  1027. 12.     Author's Address
  1028.    Mark R. Crispin
  1029.    Networks and Distributed Computing, JE-30
  1030.    University of Washington
  1031.    Seattle, WA  98195
  1032.    Phone: (206) 543-5762
  1033.    EMail: MRC@CAC.Washington.EDU
  1034. Crispin                                                        [Page 64]
  1035. RFC 1730                         IMAP4                     December 1994
  1036. Appendices
  1037. A.      Obsolete Commands
  1038.    The following commands are OBSOLETE.  It is NOT required to support
  1039.    any of these commands in new server implementations.  These commands
  1040.    are documented here for the benefit of implementors who may wish to
  1041.    support them for compatibility with old client implementations.
  1042.    The section headings of these commands are intended to correspond
  1043.    with where they would be located in the main document if they were
  1044.    not obsoleted.
  1045. A.6.3.OBS.1.    FIND ALL.MAILBOXES Command
  1046.    Arguments:  mailbox name with possible wildcards
  1047.    Data:       untagged responses: MAILBOX
  1048.    Result:     OK - find completed
  1049.                NO - find failure: can't list that name
  1050.                BAD - command unknown or arguments invalid
  1051.       The FIND ALL.MAILBOXES command returns a subset of names from the
  1052.       complete set of all names available to the user.  It returns zero
  1053.       or more untagged MAILBOX replies.  The mailbox argument to FIND
  1054.       ALL.MAILBOXES is similar to that for LIST with an empty reference,
  1055.       except that the characters "%" and "?" match a single character.
  1056.    Example:    C: A002 FIND ALL.MAILBOXES *
  1057.                S: * MAILBOX blurdybloop
  1058.                S: * MAILBOX INBOX
  1059.                S: A002 OK FIND ALL.MAILBOXES completed
  1060. A.6.3.OBS.2.    FIND MAILBOXES Command
  1061.    Arguments:  mailbox name with possible wildcards
  1062.    Data:       untagged responses: MAILBOX
  1063.    Result:     OK - find completed
  1064.                NO - find failure: can't list that name
  1065.                BAD - command unknown or arguments invalid
  1066.       The FIND MAILBOXES command returns a subset of names from the set
  1067.       of names that the user has declared as being "active" or
  1068. Crispin                                                        [Page 65]
  1069. RFC 1730                         IMAP4                     December 1994
  1070.       "subscribed".  It returns zero or more untagged MAILBOX replies.
  1071.       The mailbox argument to FIND MAILBOXES is similar to that for LSUB
  1072.       with an empty reference, except that the characters "%" and "?"
  1073.       match a single character.
  1074.    Example:    C: A002 FIND MAILBOXES *
  1075.                S: * MAILBOX blurdybloop
  1076.                S: * MAILBOX INBOX
  1077.                S: A002 OK FIND MAILBOXES completed
  1078. A.6.3.OBS.3.    SUBSCRIBE MAILBOX Command
  1079.    Arguments:  mailbox name
  1080.    Data:       no specific data for this command
  1081.    Result:     OK - subscribe completed
  1082.                NO - subscribe failure: can't subscribe to that name
  1083.                BAD - command unknown or arguments invalid
  1084.       The SUBSCRIBE MAILBOX command is identical in effect to the
  1085.       SUBSCRIBE command.  A server which implements this command must be
  1086.       able to distinguish between a SUBSCRIBE MAILBOX command and a
  1087.       SUBSCRIBE command with a mailbox name argument of "MAILBOX".
  1088.    Example:    C: A002 SUBSCRIBE MAILBOX #news.comp.mail.mime
  1089.                S: A002 OK SUBSCRIBE MAILBOX to #news.comp.mail.mime
  1090.                completed
  1091.                C: A003 SUBSCRIBE MAILBOX
  1092.                S: A003 OK SUBSCRIBE to MAILBOX completed
  1093. A.6.3.OBS.4.    UNSUBSCRIBE MAILBOX Command
  1094.    Arguments:  mailbox name
  1095.    Data:       no specific data for this command
  1096.    Result:     OK - unsubscribe completed
  1097.                NO - unsubscribe failure: can't unsubscribe that name
  1098.                BAD - command unknown or arguments invalid
  1099.       The UNSUBSCRIBE MAILBOX command is identical in effect to the
  1100.       UNSUBSCRIBE command.  A server which implements this command must
  1101.       be able to distinguish between a UNSUBSCRIBE MAILBOX command and
  1102.       an UNSUBSCRIBE command with a mailbox name argument of "MAILBOX".
  1103. Crispin                                                        [Page 66]
  1104. RFC 1730                         IMAP4                     December 1994
  1105.    Example:    C: A002 UNSUBSCRIBE MAILBOX #news.comp.mail.mime
  1106.                S: A002 OK UNSUBSCRIBE MAILBOX from #news.comp.mail.mime
  1107.                completed
  1108.                C: A003 UNSUBSCRIBE MAILBOX
  1109.                S: A003 OK UNSUBSCRIBE from MAILBOX completed
  1110. Crispin                                                        [Page 67]
  1111. RFC 1730                         IMAP4                     December 1994
  1112. B.      Obsolete Responses
  1113.    The following responses are OBSOLETE.  Except as noted below, these
  1114.    responses MUST NOT be transmitted by new server implementations.
  1115.    The section headings of these responses are intended to correspond
  1116.    with where they would be located in the main document if they were
  1117.    not obsoleted.
  1118. B.7.2.OBS.1.    MAILBOX Response
  1119.    Data:       name
  1120.       The MAILBOX response MUST NOT be transmitted by server
  1121.       implementations except in response to the obsolete FIND MAILBOXES
  1122.       and FIND ALL.MAILBOXES commands.  Client implementations that do
  1123.       not use these commands MAY ignore this response.  It is documented
  1124.       here for the benefit of implementors who may wish to support it
  1125.       for compatibility with old client implementations.
  1126.       This response occurs as a result of the FIND MAILBOXES and FIND
  1127.       ALL.MAILBOXES commands.  It returns a single name that matches the
  1128.       FIND specification.  There are no attributes or hierarchy
  1129.       delimiter.
  1130.    Example:    S: * MAILBOX blurdybloop
  1131. B.7.3.OBS.1.    COPY Response
  1132.    Data:       none
  1133.       The COPY response MUST NOT be transmitted by new server
  1134.       implementations.  Client implementations MUST ignore the COPY
  1135.       response.  It is documented here for the benefit of client
  1136.       implementors who may encounter this response from old server
  1137.       implementations.
  1138.       In some experimental versions of this protocol, this response was
  1139.       returned in response to a COPY command to indicate on a
  1140.       per-message basis that the message was copied successfully.
  1141.    Example:    S: * 44 COPY
  1142. Crispin                                                        [Page 68]
  1143. RFC 1730                         IMAP4                     December 1994
  1144. B.7.3.OBS.2.    STORE Response
  1145.    Data:       message data
  1146.       The STORE response MUST NOT be transmitted by new server
  1147.       implementations.  Client implementations MUST treat the STORE
  1148.       response as equivalent to the FETCH response.  It is documented
  1149.       here for the benefit of client implementors who may encounter this
  1150.       response from old server implementations.
  1151.       In some experimental versions of this protocol, this response was
  1152.       returned instead of FETCH in response to a STORE command to report
  1153.       the new value of the flags.
  1154.    Example:    S: * 69 STORE (FLAGS (Deleted))
  1155. Crispin                                                        [Page 69]
  1156. RFC 1730                         IMAP4                     December 1994
  1157. C.      References
  1158.    [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731.
  1159.    Carnegie-Mellon University, December 1994.
  1160.    [IMAP-COMPAT] Crispin, M. "IMAP4 Compatibility with IMAP2 and
  1161.    IMAP2bis", RFC 1732, University of Washington, December 1994.
  1162.    [IMAP-DISC] Austein, R. "Synchronization Operations for Disconnected
  1163.    IMAP4 Clients", Work in Progress.
  1164.    [IMAP-MODEL] Crispin, M. "Distributed Electronic Mail Models in
  1165.    IMAP4", RFC 1733, University of Washington, December 1994.
  1166.    [IMAP-NAMING] Crispin, M. "Mailbox Naming Convention in IMAP4", Work
  1167.    in Progress.
  1168.    [IMAP2] Crispin, M., "Interactive Mail Access Protocol - Version 2",
  1169.    RFC 1176, University of Washington, August 1990.
  1170.    [IMSP] Myers, J. "IMSP -- Internet Message Support Protocol", Work in
  1171.    Progress.
  1172.    [MIME-1] Borenstein, N., and Freed, N., "MIME (Multipurpose Internet
  1173.    Mail Extensions) Part One: Mechanisms for Specifying and Describing
  1174.    the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft,
  1175.    September 1993.
  1176.    [MIME-2] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
  1177.    Part Two: Message Header Extensions for Non-ASCII Text", RFC 1522,
  1178.    University of Tennessee, September 1993.
  1179.    [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
  1180.    Messages", STD 11, RFC 822, University of Delaware, August 1982.
  1181.    [SMTP] Postel, Jonathan B. "Simple Mail Transfer Protocol", STD 10,
  1182.    RFC 821, USC/Information Sciences Institute, August 1982.
  1183. Crispin                                                        [Page 70]
  1184. RFC 1730                         IMAP4                     December 1994
  1185. E.      IMAP4 Keyword Index
  1186.        +FLAGS <flag list> (store command data item) ...............   34
  1187.        +FLAGS.SILENT <flag list> (store command data item) ........   34
  1188.        -FLAGS <flag list> (store command data item) ...............   34
  1189.        -FLAGS.SILENT <flag list> (store command data item) ........   34
  1190.        ALERT (response code) ......................................   39
  1191.        ALL (fetch item) ...........................................   29
  1192.        ALL (search key) ...........................................   27
  1193.        ANSWERED (search key) ......................................   27
  1194.        APPEND (command) ...........................................   22
  1195.        AUTHENTICATE (command) .....................................   12
  1196.        BAD (response) .............................................   41
  1197.        BCC <string> (search key) ..................................   27
  1198.        BEFORE <date> (search key) .................................   27
  1199.        BODY (fetch item) ..........................................   29
  1200.        BODY (fetch result) ........................................   46
  1201.        BODY <string> (search key) .................................   27
  1202.        BODY.PEEK[<section>] (fetch item) ..........................   30
  1203.        BODYSTRUCTURE (fetch item) .................................   31
  1204.        BODYSTRUCTURE (fetch result) ...............................   47
  1205.        BODY[<section>] (fetch item) ...............................   29
  1206.        BODY[section] (fetch result) ...............................   46
  1207.        BYE (response) .............................................   41
  1208.        CAPABILITY (command) .......................................   10
  1209.        CAPABILITY (response) ......................................   42
  1210.        CC <string> (search key) ...................................   27
  1211.        CHECK (command) ............................................   23
  1212.        CLOSE (command) ............................................   24
  1213.        COPY (command) .............................................   34
  1214.        COPY (response) ............................................   68
  1215.        CREATE (command) ...........................................   17
  1216.        DELETE (command) ...........................................   18
  1217.        DELETED (search key) .......................................   27
  1218.        DRAFT (search key) .........................................   27
  1219.        ENVELOPE (fetch item) ......................................   31
  1220.        ENVELOPE (fetch result) ....................................   49
  1221.        EXAMINE (command) ..........................................   16
  1222.        EXISTS (response) ..........................................   45
  1223.        EXPUNGE (command) ..........................................   25
  1224.        EXPUNGE (response) .........................................   45
  1225.        FAST (fetch item) ..........................................   31
  1226.        FETCH (command) ............................................   29
  1227.        FETCH (response) ...........................................   46
  1228.        FIND ALL.MAILBOXES (command) ...............................   65
  1229.        FIND MAILBOXES (command) ...................................   65
  1230.        FLAGGED (search key) .......................................   27
  1231.        FLAGS (fetch item) .........................................   31
  1232. Crispin                                                        [Page 71]
  1233. RFC 1730                         IMAP4                     December 1994
  1234.        FLAGS (fetch result) .......................................   50
  1235.        FLAGS (response) ...........................................   44
  1236.        FLAGS <flag list> (store command data item) ................   34
  1237.        FLAGS.SILENT <flag list> (store command data item) .........   34
  1238.        FROM <string> (search key) .................................   27
  1239.        FULL (fetch item) ..........................................   31
  1240.        HEADER <field-name> <string> (search key) ..................   27
  1241.        INTERNALDATE (fetch item) ..................................   31
  1242.        INTERNALDATE (fetch result) ................................   50
  1243.        KEYWORD <flag> (search key) ................................   27
  1244.        LARGER <n> (search key) ....................................   27
  1245.        LIST (command) .............................................   20
  1246.        LIST (response) ............................................   43
  1247.        LOGIN (command) ............................................   14
  1248.        LOGOUT (command) ...........................................   11
  1249.        LSUB (command) .............................................   22
  1250.        LSUB (response) ............................................   44
  1251.        MAILBOX (response) .........................................   68
  1252.        NEW (search key) ...........................................   27
  1253.        NO (response) ..............................................   40
  1254.        NOOP (command) .............................................   11
  1255.        NOT <search-key> (search key) ..............................   28
  1256.        OK (response) ..............................................   40
  1257.        OLD (search key) ...........................................   28
  1258.        ON <date> (search key) .....................................   28
  1259.        OR <search-key1> <search-key2> (search key) ................   28
  1260.        PARSE (response code) ......................................   39
  1261.        PARTIAL (command) ..........................................   32
  1262.        PERMANENTFLAGS (response code) .............................   39
  1263.        PREAUTH (response) .........................................   41
  1264.        READ-ONLY (response code) ..................................   39
  1265.        READ-WRITE (response code) .................................   39
  1266.        RECENT (response) ..........................................   45
  1267.        RECENT (search key) ........................................   28
  1268.        RENAME (command) ...........................................   18
  1269.        RFC822 (fetch item) ........................................   31
  1270.        RFC822 (fetch result) ......................................   50
  1271.        RFC822.HEADER (fetch item) .................................   31
  1272.        RFC822.HEADER (fetch result) ...............................   50
  1273.        RFC822.HEADER.LINES <header_list> (fetch item) .............   31
  1274.        RFC822.HEADER.LINES.NOT <header_list> (fetch item) .........   32
  1275.        RFC822.PEEK (fetch item) ...................................   31
  1276.        RFC822.SIZE (fetch item) ...................................   32
  1277.        RFC822.SIZE (fetch result) .................................   50
  1278.        RFC822.TEXT (fetch item) ...................................   32
  1279.        RFC822.TEXT (fetch result) .................................   51
  1280.        RFC822.TEXT.PEEK (fetch item) ..............................   32
  1281.        SEARCH (command) ...........................................   25
  1282. Crispin                                                        [Page 72]
  1283. RFC 1730                         IMAP4                     December 1994
  1284.        SEARCH (response) ..........................................   44
  1285.        SEEN (search key) ..........................................   28
  1286.        SELECT (command) ...........................................   15
  1287.        SENTBEFORE <date> (search key) .............................   28
  1288.        SENTON <date> (search key) .................................   28
  1289.        SENTSINCE <date> (search key) ..............................   28
  1290.        SINCE <date> (search key) ..................................   28
  1291.        SMALLER <n> (search key) ...................................   28
  1292.        STORE (command) ............................................   33
  1293.        STORE (response) ...........................................   69
  1294.        SUBJECT <string> (search key) ..............................   28
  1295.        SUBSCRIBE (command) ........................................   19
  1296.        SUBSCRIBE MAILBOX (command) ................................   66
  1297.        TEXT <string> (search key) .................................   28
  1298.        TO <string> (search key) ...................................   28
  1299.        TRYCREATE (response code) ..................................   39
  1300.        UID (command) ..............................................   35
  1301.        UID (fetch item) ...........................................   32
  1302.        UID (fetch result) .........................................   51
  1303.        UID <message set> (search key) .............................   28
  1304.        UIDVALIDITY (response code) ................................   40
  1305.        UNANSWERED (search key) ....................................   29
  1306.        UNDELETED (search key) .....................................   29
  1307.        UNDRAFT (search key) .......................................   29
  1308.        UNFLAGGED (search key) .....................................   29
  1309.        UNKEYWORD <flag> (search key) ..............................   29
  1310.        UNSEEN (response code) .....................................   40
  1311.        UNSEEN (search key) ........................................   29
  1312.        UNSUBSCRIBE (command) ......................................   19
  1313.        UNSUBSCRIBE MAILBOX (command) ..............................   66
  1314.        X<atom> (command) ..........................................   37
  1315.        Answered (system flag) ....................................   50
  1316.        Deleted (system flag) .....................................   50
  1317.        Draft (system flag) .......................................   50
  1318.        Flagged (system flag) .....................................   50
  1319.        Marked (mailbox name attribute) ...........................   43
  1320.        Noinferiors (mailbox name attribute) ......................   43
  1321.        Noselect (mailbox name attribute) .........................   43
  1322.        Recent (system flag) ......................................   50
  1323.        Seen (system flag) ........................................   50
  1324.        Unmarked (mailbox name attribute) .........................   43
  1325. Crispin                                                        [Page 73]