6.4.    Client Commands - Selected State

   In the selected state, commands that manipulate messages in a mailbox
   are permitted.

   In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
   and the authenticated state commands (SELECT, EXAMINE, CREATE,
   DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS, and
   APPEND), the following commands are valid in the selected state:
   CHECK, CLOSE, EXPUNGE, SEARCH, FETCH, STORE, COPY, and UID.

6.4.1.  CHECK Command

   Arguments:  none

   Responses:  no specific responses for this command

   Result:     OK - check completed
               BAD - command unknown or arguments invalid

      The CHECK command requests a checkpoint of the currently selected
      mailbox.  A checkpoint refers to any implementation-dependent
      housekeeping associated with the mailbox (e.g., resolving the
      server's in-memory state of the mailbox with the state on its

      disk) that is not normally executed as part of each command.  A
      checkpoint MAY take a non-instantaneous amount of real time to
      complete.  If a server implementation has no such housekeeping
      considerations, CHECK is equivalent to NOOP.

      There is no guarantee that an EXISTS untagged response will happen
      as a result of CHECK.  NOOP, not CHECK, SHOULD be used for new
      message polling.

   Example:    C: FXXZ CHECK
               S: FXXZ OK CHECK Completed


6.4.2.  CLOSE Command

   Arguments:  none

   Responses:  no specific responses for this command

   Result:     OK - close completed, now in authenticated state
               BAD - command unknown or arguments invalid

      The CLOSE command permanently removes all messages that have the
      \Deleted flag set from the currently selected mailbox, and returns
      to the authenticated state from the selected state.  No untagged
      EXPUNGE responses are sent.

      No messages are removed, and no error is given, if the mailbox is
      selected by an EXAMINE command or is otherwise selected read-only.

      Even if a mailbox is selected, a SELECT, EXAMINE, or LOGOUT
      command MAY be issued without previously issuing a CLOSE command.
      The SELECT, EXAMINE, and LOGOUT commands implicitly close the
      currently selected mailbox without doing an expunge.  However,
      when many messages are deleted, a CLOSE-LOGOUT or CLOSE-SELECT
      sequence is considerably faster than an EXPUNGE-LOGOUT or
      EXPUNGE-SELECT because no untagged EXPUNGE responses (which the
      client would probably ignore) are sent.

   Example:    C: A341 CLOSE
               S: A341 OK CLOSE completed

6.4.3.  EXPUNGE Command

   Arguments:  none

   Responses:  untagged responses: EXPUNGE

   Result:     OK - expunge completed
               NO - expunge failure: can't expunge (e.g., permission
                    denied)
               BAD - command unknown or arguments invalid

      The EXPUNGE command permanently removes all messages that have the
      \Deleted flag set from the currently selected mailbox.  Before
      returning an OK to the client, an untagged EXPUNGE response is
      sent for each message that is removed.

   Example:    C: A202 EXPUNGE
               S: * 3 EXPUNGE
               S: * 3 EXPUNGE
               S: * 5 EXPUNGE
               S: * 8 EXPUNGE
               S: A202 OK EXPUNGE completed

        Note: In this example, messages 3, 4, 7, and 11 had the
        \Deleted flag set.  See the description of the EXPUNGE
        response for further explanation.


6.4.4.  SEARCH Command

   Arguments:  OPTIONAL [CHARSET] specification
               searching criteria (one or more)

   Responses:  REQUIRED untagged response: SEARCH

   Result:     OK - search completed
               NO - search error: can't search that [CHARSET] or
                    criteria
               BAD - command unknown or arguments invalid

      The SEARCH command searches the mailbox for messages that match
      the given searching criteria.  Searching criteria consist of one
      or more search keys.  The untagged SEARCH response from the server
      contains a listing of message sequence numbers corresponding to
      those messages that match the searching criteria.

      When multiple keys are specified, the result is the intersection
      (AND function) of all the messages that match those keys.  For
      example, the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers
      to all deleted messages from Smith that were placed in the mailbox
      since February 1, 1994.  A search key can also be a parenthesized
      list of one or more search keys (e.g., for use with the OR and NOT
      keys).

      Server implementations MAY exclude [MIME-IMB] body parts with
      terminal content media types other than TEXT and MESSAGE from
      consideration in SEARCH matching.

      The OPTIONAL [CHARSET] specification consists of the word
      "CHARSET" followed by a registered [CHARSET].  It indicates the
      [CHARSET] of the strings that appear in the search criteria.
      [MIME-IMB] content transfer encodings, and [MIME-HDRS] strings in
      [RFC-2822]/[MIME-IMB] headers, MUST be decoded before comparing
      text in a [CHARSET] other than US-ASCII.  US-ASCII MUST be
      supported; other [CHARSET]s MAY be supported.

      If the server does not support the specified [CHARSET], it MUST
      return a tagged NO response (not a BAD).  This response SHOULD
      contain the BADCHARSET response code, which MAY list the
      [CHARSET]s supported by the server.

      In all search keys that use strings, a message matches the key if
      the string is a substring of the field.  The matching is
      case-insensitive.

      The defined search keys are as follows.  Refer to the Formal
      Syntax section for the precise syntactic definitions of the
      arguments.

      <sequence set>
         Messages with message sequence numbers corresponding to the
         specified message sequence number set.

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

      ANSWERED
         Messages with the \Answered flag set.

      BCC <string>
         Messages that contain the specified string in the envelope
         structure's BCC field.

      BEFORE <date>
         Messages whose internal date (disregarding time and timezone)
         is earlier than the specified date.

      BODY <string>
         Messages that contain the specified string in the body of the
         message.

      CC <string>
         Messages that contain the specified string in the envelope
         structure's CC field.

      DELETED
         Messages with the \Deleted flag set.

      DRAFT
         Messages with the \Draft flag set.

      FLAGGED
         Messages with the \Flagged flag set.

      FROM <string>
         Messages that contain the specified string in the envelope
         structure's FROM field.

      HEADER <field-name> <string>
         Messages that have a header with the specified field-name (as
         defined in [RFC-2822]) and that contains the specified string
         in the text of the header (what comes after the colon).  If the
         string to search is zero-length, this matches all messages that
         have a header line with the specified field-name regardless of
         the contents.

      KEYWORD <flag>
         Messages with the specified keyword flag set.

      LARGER <n>
         Messages with an [RFC-2822] size larger than the specified
         number of octets.

      NEW
         Messages that have the \Recent flag set but not the \Seen flag.
         This is functionally equivalent to "(RECENT UNSEEN)".

      NOT <search-key>
         Messages that do not match the specified search key.

      OLD
         Messages that do not have the \Recent flag set.  This is
         functionally equivalent to "NOT RECENT" (as opposed to "NOT
         NEW").

      ON <date>
         Messages whose internal date (disregarding time and timezone)
         is within the specified date.

      OR <search-key1> <search-key2>
         Messages that match either search key.

      RECENT
         Messages that have the \Recent flag set.

      SEEN
         Messages that have the \Seen flag set.

      SENTBEFORE <date>
         Messages whose [RFC-2822] Date: header (disregarding time and
         timezone) is earlier than the specified date.

      SENTON <date>
         Messages whose [RFC-2822] Date: header (disregarding time and
         timezone) is within the specified date.

      SENTSINCE <date>
         Messages whose [RFC-2822] Date: header (disregarding time and
         timezone) is within or later than the specified date.

      SINCE <date>
         Messages whose internal date (disregarding time and timezone)
         is within or later than the specified date.

      SMALLER <n>
         Messages with an [RFC-2822] size smaller than the specified
         number of octets.

      SUBJECT <string>
         Messages that contain the specified string in the envelope
         structure's SUBJECT field.

      TEXT <string>
         Messages that contain the specified string in the header or
         body of the message.

      TO <string>
         Messages that contain the specified string in the envelope
         structure's TO field.

      UID <sequence set>
         Messages with unique identifiers corresponding to the specified
         unique identifier set.  Sequence set ranges are permitted.

      UNANSWERED
         Messages that do not have the \Answered flag set.

      UNDELETED
         Messages that do not have the \Deleted flag set.

      UNDRAFT
         Messages that do not have the \Draft flag set.

      UNFLAGGED
         Messages that do not have the \Flagged flag set.

      UNKEYWORD <flag>
         Messages that do not have the specified keyword flag set.

      UNSEEN
         Messages that do not have the \Seen flag set.

   Example:    C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith"
               S: * SEARCH 2 84 882
               S: A282 OK SEARCH completed
               C: A283 SEARCH TEXT "string not in mailbox"
               S: * SEARCH
               S: A283 OK SEARCH completed
               C: A284 SEARCH CHARSET UTF-8 TEXT {6}
               C: XXXXXX
               S: * SEARCH 43
               S: A284 OK SEARCH completed

        Note: Since this document is restricted to 7-bit ASCII
        text, it is not possible to show actual UTF-8 data.  The
        "XXXXXX" is a placeholder for what would be 6 octets of
        8-bit data in an actual transaction.


6.4.5.  FETCH Command

   Arguments:  sequence set
               message data item names or macro

   Responses:  untagged responses: FETCH

   Result:     OK - fetch completed
               NO - fetch error: can't fetch that data
               BAD - command unknown or arguments invalid

      The FETCH command retrieves data associated with a message in the
      mailbox.  The data items to be fetched can be either a single atom
      or a parenthesized list.

      Most data items, identified in the formal syntax under the
      msg-att-static rule, are static and MUST NOT change for any
      particular message.  Other data items, identified in the formal
      syntax under the msg-att-dynamic rule, MAY change, either as a
      result of a STORE command or due to external events.

           For example, if a client receives an ENVELOPE for a
           message when it already knows the envelope, it can
           safely ignore the newly transmitted envelope.

      There are three macros which specify commonly-used sets of data
      items, and can be used instead of data items.  A macro must be
      used by itself, and not in conjunction with other macros or data
      items.

      ALL
         Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)

      FAST
         Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE)

      FULL
         Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE
         BODY)

      The currently defined data items that can be fetched are:

      BODY
         Non-extensible form of BODYSTRUCTURE.

      BODY[<section>]<<partial>>
         The text of a particular body section.  The section
         specification is a set of zero or more part specifiers
         delimited by periods.  A part specifier is either a part number
         or one of the following: HEADER, HEADER.FIELDS,
         HEADER.FIELDS.NOT, MIME, and TEXT.  An empty section
         specification refers to the entire message, including the
         header.

         Every message has at least one part number.  Non-[MIME-IMB]
         messages, and non-multipart [MIME-IMB] messages with no
         encapsulated message, only have a part 1.

         Multipart messages are assigned consecutive part numbers, as
         they occur in the message.  If a particular part is of type
         message or multipart, its parts MUST be indicated by a period
         followed by the part number within that nested multipart part.

         A part of type MESSAGE/RFC822 also has nested part numbers,
         referring to parts of the MESSAGE part's body.

         The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, and TEXT part
         specifiers can be the sole part specifier or can be prefixed by
         one or more numeric part specifiers, provided that the numeric
         part specifier refers to a part of type MESSAGE/RFC822.  The
         MIME part specifier MUST be prefixed by one or more numeric
         part specifiers.

         The HEADER, HEADER.FIELDS, and HEADER.FIELDS.NOT part
         specifiers refer to the [RFC-2822] header of the message or of
         an encapsulated [MIME-IMT] MESSAGE/RFC822 message.
         HEADER.FIELDS and HEADER.FIELDS.NOT are followed by a list of
         field-name (as defined in [RFC-2822]) names, and return a

         subset of the header.  The subset returned by HEADER.FIELDS
         contains only those header fields with a field-name that
         matches one of the names in the list; similarly, the subset
         returned by HEADER.FIELDS.NOT contains only the header fields
         with a non-matching field-name.  The field-matching is
         case-insensitive but otherwise exact.  Subsetting does not
         exclude the [RFC-2822] delimiting blank line between the header
         and the body; the blank line is included in all header fetches,
         except in the case of a message which has no body and no blank
         line.

         The MIME part specifier refers to the [MIME-IMB] header for
         this part.

         The TEXT part specifier refers to the text body of the message,
         omitting the [RFC-2822] header.

            Here is an example of a complex message with some of its
            part specifiers:

       HEADER     ([RFC-2822] header of the message)
       TEXT       ([RFC-2822] text body of the message) MULTIPART/MIXED
       1          TEXT/PLAIN
       2          APPLICATION/OCTET-STREAM
       3          MESSAGE/RFC822
       3.HEADER   ([RFC-2822] header of the message)
       3.TEXT     ([RFC-2822] text body of the message) MULTIPART/MIXED
       3.1        TEXT/PLAIN
       3.2        APPLICATION/OCTET-STREAM
       4          MULTIPART/MIXED
       4.1        IMAGE/GIF
       4.1.MIME   ([MIME-IMB] header for the IMAGE/GIF)
       4.2        MESSAGE/RFC822
       4.2.HEADER ([RFC-2822] header of the message)
       4.2.TEXT   ([RFC-2822] text body of the message) MULTIPART/MIXED
       4.2.1      TEXT/PLAIN
       4.2.2      MULTIPART/ALTERNATIVE
       4.2.2.1    TEXT/PLAIN
       4.2.2.2    TEXT/RICHTEXT


         It is possible to fetch a substring of the designated text.
         This is done by appending an open angle bracket ("<"), the
         octet position of the first desired octet, a period, the
         maximum number of octets desired, and a close angle bracket
         (">") to the part specifier.  If the starting octet is beyond
         the end of the text, an empty string is returned.

         Any partial fetch that attempts to read beyond the end of the
         text is truncated as appropriate.  A partial fetch that starts
         at octet 0 is returned as a partial fetch, even if this
         truncation happened.

            Note: This means that BODY[]<0.2048> of a 1500-octet message
            will return BODY[]<0> with a literal of size 1500, not
            BODY[].

            Note: A substring fetch of a HEADER.FIELDS or
            HEADER.FIELDS.NOT part specifier is calculated after
            subsetting the header.

         The \Seen flag is implicitly set; if this causes the flags to
         change, they SHOULD be included as part of the FETCH responses.

      BODY.PEEK[<section>]<<partial>>
         An alternate form of BODY[<section>] that does not implicitly
         set the \Seen flag.

      BODYSTRUCTURE
         The [MIME-IMB] body structure of the message.  This is computed
         by the server by parsing the [MIME-IMB] header fields in the
         [RFC-2822] header and [MIME-IMB] headers.

      ENVELOPE
         The envelope structure of the message.  This is computed by the
         server by parsing the [RFC-2822] header into the component
         parts, defaulting various fields as necessary.

      FLAGS
         The flags that are set for this message.

      INTERNALDATE
         The internal date of the message.

      RFC822
         Functionally equivalent to BODY[], differing in the syntax of
         the resulting untagged FETCH data (RFC822 is returned).

      RFC822.HEADER
         Functionally equivalent to BODY.PEEK[HEADER], differing in the
         syntax of the resulting untagged FETCH data (RFC822.HEADER is
         returned).

      RFC822.SIZE
         The [RFC-2822] size of the message.

      RFC822.TEXT
         Functionally equivalent to BODY[TEXT], differing in the syntax
         of the resulting untagged FETCH data (RFC822.TEXT is returned).

      UID
         The unique identifier for the message.


   Example:    C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)])
               S: * 2 FETCH ....
               S: * 3 FETCH ....
               S: * 4 FETCH ....
               S: A654 OK FETCH completed


6.4.6.  STORE Command

   Arguments:  sequence set
               message data item name
               value for message data item

   Responses:  untagged responses: FETCH

   Result:     OK - store completed
               NO - store error: can't store that data
               BAD - command unknown or arguments invalid

      The STORE command alters data associated with a message in the
      mailbox.  Normally, STORE will return the updated value of the
      data with an untagged FETCH response.  A suffix of ".SILENT" in
      the data item name prevents the untagged FETCH, and the server
      SHOULD assume that the client has determined the updated value
      itself or does not care about the updated value.

           Note: Regardless of whether or not the ".SILENT" suffix
           was used, the server SHOULD send an untagged FETCH
           response if a change to a message's flags from an
           external source is observed.  The intent is that the
           status of the flags is determinate without a race
           condition.

      The currently defined data items that can be stored are:

      FLAGS <flag list>
         Replace the flags for the message (other than \Recent) with the
         argument.  The new value of the flags is returned as if a FETCH
         of those flags was done.

      FLAGS.SILENT <flag list>
         Equivalent to FLAGS, but without returning a new value.

      +FLAGS <flag list>
         Add the argument to the flags for the message.  The new value
         of the flags is returned as if a FETCH of those flags was done.

      +FLAGS.SILENT <flag list>
         Equivalent to +FLAGS, but without returning a new value.

      -FLAGS <flag list>
         Remove the argument from the flags for the message.  The new
         value of the flags is returned as if a FETCH of those flags was
         done.

      -FLAGS.SILENT <flag list>
         Equivalent to -FLAGS, but without returning a new value.


   Example:    C: A003 STORE 2:4 +FLAGS (\Deleted)
               S: * 2 FETCH (FLAGS (\Deleted \Seen))
               S: * 3 FETCH (FLAGS (\Deleted))
               S: * 4 FETCH (FLAGS (\Deleted \Flagged \Seen))
               S: A003 OK STORE completed


6.4.7.  COPY Command

   Arguments:  sequence set
               mailbox name

   Responses:  no specific responses for this command

   Result:     OK - copy completed
               NO - copy error: can't copy those messages or to that
                    name
               BAD - command unknown or arguments invalid

      The COPY command copies the specified message(s) to the end of the
      specified destination mailbox.  The flags and internal date of the
      message(s) SHOULD be preserved, and the Recent flag SHOULD be set,
      in the copy.

      If the destination mailbox does not exist, a server SHOULD return
      an error.  It SHOULD NOT automatically create the mailbox.  Unless
      it is certain that the destination mailbox can not be created, the
      server MUST send the response code "[TRYCREATE]" as the prefix of
      the text of the tagged NO response.  This gives a hint to the
      client that it can attempt a CREATE command and retry the COPY if
      the CREATE is successful.

      If the COPY command is unsuccessful for any reason, server
      implementations MUST restore the destination mailbox to its state
      before the COPY attempt.

   Example:    C: A003 COPY 2:4 MEETING
               S: A003 OK COPY completed


6.4.8.  UID Command

   Arguments:  command name
               command arguments

   Responses:  untagged responses: FETCH, SEARCH

   Result:     OK - UID command completed
               NO - UID command error
               BAD - command unknown or arguments invalid

      The UID command has two forms.  In the first form, it takes as its
      arguments a COPY, FETCH, or STORE command with arguments
      appropriate for the associated command.  However, the numbers in
      the sequence set argument are unique identifiers instead of
      message sequence numbers.  Sequence set ranges are permitted, but
      there is no guarantee that unique identifiers will be contiguous.

      A non-existent unique identifier is ignored without any error
      message generated.  Thus, it is possible for a UID FETCH command
      to return an OK without any data or a UID COPY or UID STORE to
      return an OK without performing any operations.

      In the second form, the UID command takes a SEARCH command with
      SEARCH command arguments.  The interpretation of the arguments is
      the same as with SEARCH; however, the numbers returned in a SEARCH
      response for a UID SEARCH command are unique identifiers instead

      of message sequence numbers.  For example, the command UID SEARCH
      1:100 UID 443:557 returns the unique identifiers corresponding to
      the intersection of two sequence sets, the message sequence number
      range 1:100 and the UID range 443:557.

           Note: in the above example, the UID range 443:557
           appears.  The same comment about a non-existent unique
           identifier being ignored without any error message also
           applies here.  Hence, even if neither UID 443 or 557
           exist, this range is valid and would include an existing
           UID 495.

           Also note that a UID range of 559:* always includes the
           UID of the last message in the mailbox, even if 559 is
           higher than any assigned UID value.  This is because the
           contents of a range are independent of the order of the
           range endpoints.  Thus, any UID range with * as one of
           the endpoints indicates at least one message (the
           message with the highest numbered UID), unless the
           mailbox is empty.

      The number after the "*" in an untagged FETCH response is always a
      message sequence number, not a unique identifier, even for a UID
      command response.  However, server implementations MUST implicitly
      include the UID message data item as part of any FETCH response
      caused by a UID command, regardless of whether a UID was specified
      as a message data item to the FETCH.


      Note: The rule about including the UID message data item as part
      of a FETCH response primarily applies to the UID FETCH and UID
      STORE commands, including a UID FETCH command that does not
      include UID as a message data item.  Although it is unlikely that
      the other UID commands will cause an untagged FETCH, this rule
      applies to these commands as well.

   Example:    C: A999 UID FETCH 4827313:4828442 FLAGS
               S: * 23 FETCH (FLAGS (\Seen) UID 4827313)
               S: * 24 FETCH (FLAGS (\Seen) UID 4827943)
               S: * 25 FETCH (FLAGS (\Seen) UID 4828442)
               S: A999 OK UID FETCH completed

6.5.    Client Commands - Experimental/Expansion


6.5.1.  X<atom> Command

   Arguments:  implementation defined

   Responses:  implementation defined

   Result:     OK - command completed
               NO - failure
               BAD - command unknown or arguments invalid

      Any command prefixed with an X is an experimental command.
      Commands which are not part of this specification, a standard or
      standards-track revision of this specification, or an
      IESG-approved experimental protocol, MUST use the X prefix.

      Any added untagged responses issued by an experimental command
      MUST also be prefixed with an X.  Server implementations MUST NOT
      send any such untagged responses, unless the client requested it
      by issuing the associated experimental command.

   Example:    C: a441 CAPABILITY
               S: * CAPABILITY IMAP4rev1 XPIG-LATIN
               S: a441 OK CAPABILITY completed
               C: A442 XPIG-LATIN
               S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay
               S: A442 OK XPIG-LATIN ompleted-cay

7.      Server Responses

   Server responses are in three forms: status responses, server data,
   and command continuation request.  The information contained in a
   server response, identified by "Contents:" in the response
   descriptions below, is described by function, not by syntax.  The
   precise syntax of server responses is described in the Formal Syntax
   section.

   The client MUST be prepared to accept any response at all times.

   Status responses can be tagged or untagged.  Tagged status responses
   indicate the completion result (OK, NO, or BAD status) of a client
   command, and have a tag matching the command.

   Some status responses, and all server data, are untagged.  An
   untagged response is indicated by the token "*" instead of a tag.
   Untagged status responses indicate server greeting, or server status

   that does not indicate the completion of a command (for example, an
   impending system shutdown alert).  For historical reasons, untagged
   server data responses are also called "unsolicited data", although
   strictly speaking, only unilateral server data is truly
   "unsolicited".

   Certain server data MUST be recorded by the client when it is
   received; this is noted in the description of that data.  Such data
   conveys critical information which affects the interpretation of all
   subsequent commands and responses (e.g., updates reflecting the
   creation or destruction of messages).

   Other server data SHOULD be recorded for later reference; if the
   client does not need to record the data, or if recording the data has
   no obvious purpose (e.g., a SEARCH response when no SEARCH command is
   in progress), the data SHOULD be ignored.

   An example of unilateral untagged server data occurs when the IMAP
   connection is in the selected state.  In the selected state, the
   server checks the mailbox for new messages as part of command
   execution.  Normally, this is part of the execution of every command;
   hence, a NOOP command suffices to check for new messages.  If new
   messages are found, the server sends untagged EXISTS and RECENT
   responses reflecting the new size of the mailbox.  Server
   implementations that offer multiple simultaneous access to the same
   mailbox SHOULD also send appropriate unilateral untagged FETCH and
   EXPUNGE responses if another agent changes the state of any message
   flags or expunges any messages.

   Command continuation request responses use the token "+" instead of a
   tag.  These responses are sent by the server to indicate acceptance
   of an incomplete client command and readiness for the remainder of
   the command.

7.1.    Server Responses - Status Responses

   Status responses are OK, NO, BAD, PREAUTH and BYE.  OK, NO, and BAD
   can be tagged or untagged.  PREAUTH and BYE are always untagged.

   Status responses MAY include an OPTIONAL "response code".  A response
   code consists of data inside square brackets in the form of an atom,
   possibly followed by a space and arguments.  The response code
   contains additional information or status codes for client software
   beyond the OK/NO/BAD condition, and are defined when there is a
   specific action that a client can take based upon the additional
   information.

   The currently defined response codes are:

      ALERT

         The human-readable text contains a special alert that MUST be
         presented to the user in a fashion that calls the user's
         attention to the message.

      BADCHARSET

         Optionally followed by a parenthesized list of charsets.  A
         SEARCH failed because the given charset is not supported by
         this implementation.  If the optional list of charsets is
         given, this lists the charsets that are supported by this
         implementation.

      CAPABILITY

         Followed by a list of capabilities.  This can appear in the
         initial OK or PREAUTH response to transmit an initial
         capabilities list.  This makes it unnecessary for a client to
         send a separate CAPABILITY command if it recognizes this
         response.

      PARSE

         The human-readable text represents an error in parsing the
         [RFC-2822] header or [MIME-IMB] headers of a message in the
         mailbox.

      PERMANENTFLAGS

         Followed by a parenthesized list of flags, indicates which of
         the known flags the client can change permanently.  Any flags
         that are in the FLAGS untagged response, but not the
         PERMANENTFLAGS list, can not be set permanently.  If the client
         attempts to STORE a flag that is not in the PERMANENTFLAGS
         list, the server will either ignore the change or store the
         state change for the remainder of the current session only.
         The PERMANENTFLAGS list can also include the special flag \*,
         which indicates that it is possible to create new keywords by
         attempting to store those flags in the mailbox.

      READ-ONLY

         The mailbox is selected read-only, or its access while selected
         has changed from read-write to read-only.

      READ-WRITE

         The mailbox is selected read-write, or its access while
         selected has changed from read-only to read-write.

      TRYCREATE

         An APPEND or COPY attempt is failing because the target mailbox
         does not exist (as opposed to some other reason).  This is a
         hint to the client that the operation can succeed if the
         mailbox is first created by the CREATE command.

      UIDNEXT

         Followed by a decimal number, indicates the next unique
         identifier value.  Refer to section 2.3.1.1 for more
         information.

      UIDVALIDITY

         Followed by a decimal number, indicates the unique identifier
         validity value.  Refer to section 2.3.1.1 for more information.

      UNSEEN

         Followed by a decimal number, indicates the number of the first
         message without the \Seen flag set.

      Additional response codes defined by particular client or server
      implementations SHOULD be prefixed with an "X" until they are
      added to a revision of this protocol.  Client implementations
      SHOULD ignore response codes that they do not recognize.

7.1.1.  OK Response

   Contents:   OPTIONAL response code
               human-readable text

      The OK response indicates an information message from the server.
      When tagged, it indicates successful completion of the associated
      command.  The human-readable text MAY be presented to the user as
      an information message.  The untagged form indicates an

      information-only message; the nature of the information MAY be
      indicated by a response code.

      The untagged form is also used as one of three possible greetings
      at connection startup.  It indicates that the connection is not
      yet authenticated and that a LOGIN command is needed.

   Example:    S: * OK IMAP4rev1 server ready
               C: A001 LOGIN fred blurdybloop
               S: * OK [ALERT] System shutdown in 10 minutes
               S: A001 OK LOGIN Completed


7.1.2.  NO Response

   Contents:   OPTIONAL response code
               human-readable text

      The NO response indicates an operational error message from the
      server.  When tagged, it indicates unsuccessful completion of the
      associated command.  The untagged form indicates a warning; the
      command can still complete successfully.  The human-readable text
      describes the condition.

   Example:    C: A222 COPY 1:2 owatagusiam
               S: * NO Disk is 98% full, please delete unnecessary data
               S: A222 OK COPY completed
               C: A223 COPY 3:200 blurdybloop
               S: * NO Disk is 98% full, please delete unnecessary data
               S: * NO Disk is 99% full, please delete unnecessary data
               S: A223 NO COPY failed: disk is full


7.1.3.  BAD Response

   Contents:   OPTIONAL response code
               human-readable text

      The BAD response indicates an error message from the server.  When
      tagged, it reports a protocol-level error in the client's command;
      the tag indicates the command that caused the error.  The untagged
      form indicates a protocol-level error for which the associated
      command can not be determined; it can also indicate an internal
      server failure.  The human-readable text describes the condition.

   Example:    C: ...very long command line...
               S: * BAD Command line too long
               C: ...empty line...
               S: * BAD Empty command line
               C: A443 EXPUNGE
               S: * BAD Disk crash, attempting salvage to a new disk!
               S: * OK Salvage successful, no data lost
               S: A443 OK Expunge completed


7.1.4.  PREAUTH Response

   Contents:   OPTIONAL response code
               human-readable text

      The PREAUTH response is always untagged, and is one of three
      possible greetings at connection startup.  It indicates that the
      connection has already been authenticated by external means; thus
      no LOGIN command is needed.

   Example:    S: * PREAUTH IMAP4rev1 server logged in as Smith


7.1.5.  BYE Response

   Contents:   OPTIONAL response code
               human-readable text

      The BYE response is always untagged, and indicates that the server
      is about to close the connection.  The human-readable text MAY be
      displayed to the user in a status report by the client.  The BYE
      response is sent under one of four conditions:

         1) as part of a normal logout sequence.  The server will close
            the connection after sending the tagged OK response to the
            LOGOUT command.

         2) as a panic shutdown announcement.  The server closes the
            connection immediately.

         3) as an announcement of an inactivity autologout.  The server
            closes the connection immediately.

         4) as one of three possible greetings at connection startup,
            indicating that the server is not willing to accept a
            connection from this client.  The server closes the
            connection immediately.

      The difference between a BYE that occurs as part of a normal
      LOGOUT sequence (the first case) and a BYE that occurs because of
      a failure (the other three cases) is that the connection closes
      immediately in the failure case.  In all cases the client SHOULD
      continue to read response data from the server until the
      connection is closed; this will ensure that any pending untagged
      or completion responses are read and processed.

   Example:    S: * BYE Autologout; idle for too long

7.2.    Server Responses - Server and Mailbox Status

   These responses are always untagged.  This is how server and mailbox
   status data are transmitted from the server to the client.  Many of
   these responses typically result from a command with the same name.

7.2.1.  CAPABILITY Response

   Contents:   capability listing

      The CAPABILITY response occurs as a result of a CAPABILITY
      command.  The capability listing contains a space-separated
      listing of capability names that the server supports.  The
      capability listing MUST include the atom "IMAP4rev1".

      In addition, client and server implementations MUST implement the
      STARTTLS, LOGINDISABLED, and AUTH=PLAIN (described in [IMAP-TLS])
      capabilities.  See the Security Considerations section for
      important information.

      A capability name which begins with "AUTH=" indicates that the
      server supports that particular authentication mechanism.

      The LOGINDISABLED capability indicates that the LOGIN command is
      disabled, and that the server will respond with a tagged NO
      response to any attempt to use the LOGIN command even if the user
      name and password are valid.  An IMAP client MUST NOT issue the
      LOGIN command if the server advertises the LOGINDISABLED
      capability.

      Other capability names indicate that the server supports an
      extension, revision, or amendment to the IMAP4rev1 protocol.
      Server responses MUST conform to this document until the client
      issues a command that uses the associated capability.

      Capability names MUST either begin with "X" or be standard or
      standards-track IMAP4rev1 extensions, revisions, or amendments
      registered with IANA.  A server MUST NOT offer unregistered or

      non-standard capability names, unless such names are prefixed with
      an "X".

      Client implementations SHOULD NOT require any capability name
      other than "IMAP4rev1", and MUST ignore any unknown capability
      names.

      A server MAY send capabilities automatically, by using the
      CAPABILITY response code in the initial PREAUTH or OK responses,
      and by sending an updated CAPABILITY response code in the tagged
      OK response as part of a successful authentication.  It is
      unnecessary for a client to send a separate CAPABILITY command if
      it recognizes these automatic capabilities.

   Example:    S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI XPIG-LATIN


7.2.2.  LIST Response

   Contents:   name attributes
               hierarchy delimiter
               name

      The LIST response occurs as a result of a LIST command.  It
      returns a single name that matches the LIST specification.  There
      can be multiple LIST responses for a single LIST command.

      Four name attributes are defined:

      \Noinferiors
         It is not possible for any child levels of hierarchy to exist
         under this name; no child levels exist now and none can be
         created in the future.

      \Noselect
         It is not possible to use this name as a selectable mailbox.

      \Marked
         The mailbox has been marked "interesting" by the server; the
         mailbox probably contains messages that have been added since
         the last time the mailbox was selected.

      \Unmarked
         The mailbox does not contain any additional messages since the
         last time the mailbox was selected.

      If it is not feasible for the server to determine whether or not
      the mailbox is "interesting", or if the name is a \Noselect name,
      the server SHOULD NOT send either \Marked or \Unmarked.

      The hierarchy delimiter is a character used to delimit levels of
      hierarchy in a mailbox name.  A client can use it to create child
      mailboxes, and to search higher or lower levels of naming
      hierarchy.  All children of a top-level hierarchy node MUST use
      the same separator character.  A NIL hierarchy delimiter means
      that no hierarchy exists; the name is a "flat" name.

      The name represents an unambiguous left-to-right hierarchy, and
      MUST be valid for use as a reference in LIST and LSUB commands.
      Unless \Noselect is indicated, the name MUST also be valid as an
      argument for commands, such as SELECT, that accept mailbox names.

   Example:    S: * LIST (\Noselect) "/" ~/Mail/foo


7.2.3.  LSUB Response

   Contents:   name attributes
               hierarchy delimiter
               name

      The LSUB response occurs as a result of an LSUB command.  It
      returns a single name that matches the LSUB specification.  There
      can be multiple LSUB responses for a single LSUB command.  The
      data is identical in format to the LIST response.

   Example:    S: * LSUB () "." #news.comp.mail.misc


7.2.4   STATUS Response

   Contents:   name
               status parenthesized list

      The STATUS response occurs as a result of an STATUS command.  It
      returns the mailbox name that matches the STATUS specification and
      the requested mailbox status information.

   Example:    S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)

7.2.5.  SEARCH Response

   Contents:   zero or more numbers

      The SEARCH response occurs as a result of a SEARCH or UID SEARCH
      command.  The number(s) refer to those messages that match the
      search criteria.  For SEARCH, these are message sequence numbers;
      for UID SEARCH, these are unique identifiers.  Each number is
      delimited by a space.

   Example:    S: * SEARCH 2 3 6


7.2.6.  FLAGS Response

   Contents:   flag parenthesized list

      The FLAGS response occurs as a result of a SELECT or EXAMINE
      command.  The flag parenthesized list identifies the flags (at a
      minimum, the system-defined flags) that are applicable for this
      mailbox.  Flags other than the system flags can also exist,
      depending on server implementation.

      The update from the FLAGS response MUST be recorded by the client.

   Example:    S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)


7.3.    Server Responses - Mailbox Size

   These responses are always untagged.  This is how changes in the size
   of the mailbox are transmitted from the server to the client.
   Immediately following the "*" token is a number that represents a
   message count.

7.3.1.  EXISTS Response

   Contents:   none

      The EXISTS response reports the number of messages in the mailbox.
      This response occurs as a result of a SELECT or EXAMINE command,
      and if the size of the mailbox changes (e.g., new messages).

      The update from the EXISTS response MUST be recorded by the
      client.

   Example:    S: * 23 EXISTS

7.3.2.  RECENT Response

   Contents:   none

      The RECENT response reports the number of messages with the
      \Recent flag set.  This response occurs as a result of a SELECT or
      EXAMINE command, and if the size of the mailbox changes (e.g., new
      messages).

           Note: It is not guaranteed that the message sequence
           numbers of recent messages will be a contiguous range of
           the highest n messages in the mailbox (where n is the
           value reported by the RECENT response).  Examples of
           situations in which this is not the case are: multiple
           clients having the same mailbox open (the first session
           to be notified will see it as recent, others will
           probably see it as non-recent), and when the mailbox is
           re-ordered by a non-IMAP agent.

           The only reliable way to identify recent messages is to
           look at message flags to see which have the \Recent flag
           set, or to do a SEARCH RECENT.

      The update from the RECENT response MUST be recorded by the
      client.

   Example:    S: * 5 RECENT


7.4.    Server Responses - Message Status

   These responses are always untagged.  This is how message data are
   transmitted from the server to the client, often as a result of a
   command with the same name.  Immediately following the "*" token is a
   number that represents a message sequence number.

7.4.1.  EXPUNGE Response

   Contents:   none

      The EXPUNGE response reports that the specified message sequence
      number has been permanently removed from the mailbox.  The message
      sequence number for each successive message in the mailbox is
      immediately decremented by 1, and this decrement is reflected in
      message sequence numbers in subsequent responses (including other
      untagged EXPUNGE responses).

      The EXPUNGE response also decrements the number of messages in the
      mailbox; it is not necessary to send an EXISTS response with the
      new value.

      As a result of the immediate decrement rule, message sequence
      numbers that appear in a set of successive EXPUNGE responses
      depend upon whether the messages are removed starting from lower
      numbers to higher numbers, or from higher numbers to lower
      numbers.  For example, if the last 5 messages in a 9-message
      mailbox are expunged, a "lower to higher" server will send five
      untagged EXPUNGE responses for message sequence number 5, whereas
      a "higher to lower server" will send successive untagged EXPUNGE
      responses for message sequence numbers 9, 8, 7, 6, and 5.

      An EXPUNGE response MUST NOT be sent when no command is in
      progress, nor while responding to a FETCH, STORE, or SEARCH
      command.  This rule is necessary to prevent a loss of
      synchronization of message sequence numbers between client and
      server.  A command is not "in progress" until the complete command
      has been received; in particular, a command is not "in progress"
      during the negotiation of command continuation.

           Note: UID FETCH, UID STORE, and UID SEARCH are different
           commands from FETCH, STORE, and SEARCH.  An EXPUNGE
           response MAY be sent during a UID command.

      The update from the EXPUNGE response MUST be recorded by the
      client.

   Example:    S: * 44 EXPUNGE


7.4.2.  FETCH Response

   Contents:   message data

      The FETCH response returns data about a message to the client.
      The data are pairs of data item names and their values in
      parentheses.  This response occurs as the result of a FETCH or
      STORE command, as well as by unilateral server decision (e.g.,
      flag updates).

      The current data items are:

      BODY
         A form of BODYSTRUCTURE without extension data.

      BODY[<section>]<<origin octet>>
         A string expressing the body contents of the specified section.
         The string SHOULD be interpreted by the client according to the
         content transfer encoding, body type, and subtype.

         If the origin octet is specified, this string is a substring of
         the entire body contents, starting at that origin octet.  This
         means that BODY[]<0> MAY be truncated, but BODY[] is NEVER
         truncated.

            Note: The origin octet facility MUST NOT be used by a server
            in a FETCH response unless the client specifically requested
            it by means of a FETCH of a BODY[<section>]<<partial>> data
            item.

         8-bit textual data is permitted if a [CHARSET] identifier is
         part of the body parameter parenthesized list for this section.
         Note that headers (part specifiers HEADER or MIME, or the
         header portion of a MESSAGE/RFC822 part), MUST be 7-bit; 8-bit
         characters are not permitted in headers.  Note also that the
         [RFC-2822] delimiting blank line between the header and the
         body is not affected by header line subsetting; the blank line
         is always included as part of header data, except in the case
         of a message which has no body and no blank line.

         Non-textual data such as binary data MUST be transfer encoded
         into a textual form, such as BASE64, prior to being sent to the
         client.  To derive the original binary data, the client MUST
         decode the transfer encoded string.

      BODYSTRUCTURE
         A parenthesized list that describes the [MIME-IMB] body
         structure of a message.  This is computed by the server by
         parsing the [MIME-IMB] header fields, defaulting various fields
         as necessary.

         For example, a simple text message of 48 lines and 2279 octets
         can have a body structure of: ("TEXT" "PLAIN" ("CHARSET"
         "US-ASCII") NIL NIL "7BIT" 2279 48)

         Multiple parts are indicated by parenthesis nesting.  Instead
         of a body type as the first element of the parenthesized list,
         there is a sequence of one or more nested body structures.  The
         second element of the parenthesized list is the multipart
         subtype (mixed, digest, parallel, alternative, etc.).

         For example, a two part message consisting of a text and a
         BASE64-encoded text attachment can have a body structure of:
         (("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152
         23)("TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" "cc.diff")
         "<960723163407.20117h@cac.washington.edu>" "Compiler diff"
         "BASE64" 4554 73) "MIXED")

         Extension data follows the multipart subtype.  Extension data
         is never returned with the BODY fetch, but can be returned with
         a BODYSTRUCTURE fetch.  Extension data, if present, MUST be in
         the defined order.  The extension data of a multipart body part
         are in the following order:

         body parameter parenthesized list
            A parenthesized list of attribute/value pairs [e.g., ("foo"
            "bar" "baz" "rag") where "bar" is the value of "foo", and
            "rag" is the value of "baz"] as defined in [MIME-IMB].

         body disposition
            A parenthesized list, consisting of a disposition type
            string, followed by a parenthesized list of disposition
            attribute/value pairs as defined in [DISPOSITION].

         body language
            A string or parenthesized list giving the body language
            value as defined in [LANGUAGE-TAGS].

         body location
            A string list giving the body content URI as defined in
            [LOCATION].

         Any following extension data are not yet defined in this
         version of the protocol.  Such extension data can consist of
         zero or more NILs, strings, numbers, or potentially nested
         parenthesized lists of such data.  Client implementations that
         do a BODYSTRUCTURE fetch MUST be prepared to accept such
         extension data.  Server implementations MUST NOT send such
         extension data until it has been defined by a revision of this
         protocol.

         The basic fields of a non-multipart body part are in the
         following order:

         body type
            A string giving the content media type name as defined in
            [MIME-IMB].

         body subtype
            A string giving the content subtype name as defined in
            [MIME-IMB].

         body parameter parenthesized list
            A parenthesized list of attribute/value pairs [e.g., ("foo"
            "bar" "baz" "rag") where "bar" is the value of "foo" and
            "rag" is the value of "baz"] as defined in [MIME-IMB].

         body id
            A string giving the content id as defined in [MIME-IMB].

         body description
            A string giving the content description as defined in
            [MIME-IMB].

         body encoding
            A string giving the content transfer encoding as defined in
            [MIME-IMB].

         body size
            A number giving the size of the body in octets.  Note that
            this size is the size in its transfer encoding and not the
            resulting size after any decoding.

         A body type of type MESSAGE and subtype RFC822 contains,
         immediately after the basic fields, the envelope structure,
         body structure, and size in text lines of the encapsulated
         message.

         A body type of type TEXT contains, immediately after the basic
         fields, the size of the body in text lines.  Note that this
         size is the size in its content transfer encoding and not the
         resulting size after any decoding.

         Extension data follows the basic fields and the type-specific
         fields listed above.  Extension data is never returned with the
         BODY fetch, but can be returned with a BODYSTRUCTURE fetch.
         Extension data, if present, MUST be in the defined order.

         The extension data of a non-multipart body part are in the
         following order:

         body MD5
            A string giving the body MD5 value as defined in [MD5].

         body disposition
            A parenthesized list with the same content and function as
            the body disposition for a multipart body part.

         body language
            A string or parenthesized list giving the body language
            value as defined in [LANGUAGE-TAGS].

         body location
            A string list giving the body content URI as defined in
            [LOCATION].

         Any following extension data are not yet defined in this
         version of the protocol, and would be as described above under
         multipart extension data.

      ENVELOPE
         A parenthesized list that describes the envelope structure of a
         message.  This is computed by the server by parsing the
         [RFC-2822] header into the component parts, defaulting various
         fields as necessary.

         The fields of the envelope structure 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 parenthesized lists of address
         structures.

         An address structure is a parenthesized list that describes an
         electronic mail address.  The fields of an address structure
         are in the following order: personal name, [SMTP]
         at-domain-list (source route), mailbox name, and host name.

         [RFC-2822] group syntax is indicated by a special form of
         address structure in which the host name field is NIL.  If the
         mailbox name field is also NIL, this is an end of group marker
         (semi-colon in RFC 822 syntax).  If the mailbox name field is
         non-NIL, this is a start of group marker, and the mailbox name
         field holds the group name phrase.

         If the Date, Subject, In-Reply-To, and Message-ID header lines
         are absent in the [RFC-2822] header, the corresponding member
         of the envelope is NIL; if these header lines are present but
         empty the corresponding member of the envelope is the empty
         string.

            Note: some servers may return a NIL envelope member in the
            "present but empty" case.  Clients SHOULD treat NIL and
            empty string as identical.

            Note: [RFC-2822] requires that all messages have a valid
            Date header.  Therefore, the date member in the envelope can
            not be NIL or the empty string.

            Note: [RFC-2822] requires that the In-Reply-To and
            Message-ID headers, if present, have non-empty content.
            Therefore, the in-reply-to and message-id members in the
            envelope can not be the empty string.

         If the From, To, cc, and bcc header lines are absent in the
         [RFC-2822] header, or are present but empty, the corresponding
         member of the envelope is NIL.

         If the Sender or Reply-To lines are absent in the [RFC-2822]
         header, or are present but empty, the server sets the
         corresponding member of the envelope to be the same value as
         the from member (the client is not expected to know to do
         this).

            Note: [RFC-2822] requires that all messages have a valid
            From header.  Therefore, the from, sender, and reply-to
            members in the envelope can not be NIL.

      FLAGS
         A parenthesized list of flags that are set for this message.

      INTERNALDATE
         A string representing the internal date of the message.

      RFC822
         Equivalent to BODY[].

      RFC822.HEADER
         Equivalent to BODY[HEADER].  Note that this did not result in
         \Seen being set, because RFC822.HEADER response data occurs as
         a result of a FETCH of RFC822.HEADER.  BODY[HEADER] response
         data occurs as a result of a FETCH of BODY[HEADER] (which sets
         \Seen) or BODY.PEEK[HEADER] (which does not set \Seen).

      RFC822.SIZE
         A number expressing the [RFC-2822] size of the message.

      RFC822.TEXT
         Equivalent to BODY[TEXT].

      UID
         A number expressing the unique identifier of the message.


   Example:    S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827)


7.5.    Server Responses - Command Continuation Request

   The command continuation request response is indicated by a "+" token
   instead of a tag.  This form of response indicates that the server is
   ready to accept the continuation of a command from the client.  The
   remainder of this response is a line of text.

   This response is used in the AUTHENTICATE command to transmit server
   data to the client, and request additional client data.  This
   response is also used if an argument to any command is a literal.

   The client is not permitted to send the octets of the literal unless
   the server indicates that it is expected.  This permits the server to
   process commands and reject errors on a line-by-line basis.  The
   remainder of the command, including the CRLF that terminates a
   command, follows the octets of the literal.  If there are any
   additional command arguments, the literal octets are followed by a
   space and those arguments.

   Example:    C: A001 LOGIN {11}
               S: + Ready for additional command text
               C: FRED FOOBAR {7}
               S: + Ready for additional command text
               C: fat man
               S: A001 OK LOGIN completed
               C: A044 BLURDYBLOOP {102856}
               S: A044 BAD No such command as "BLURDYBLOOP"