Section 7. Server Responses

Server responses are in three forms: status responses, server data,
   and command continuation requests.  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 "Formal Syntax"
   (Section 9).
   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 remembered by the client when it is
   received; this is noted in the description of that data.  Such data
   conveys critical information that affects the interpretation of all
   subsequent commands and responses (e.g., updates reflecting the
   creation or destruction of messages).
   Other server data SHOULD be remembered for later reference; if the
   client does not need to remember the data, or if remembering the data
   has no obvious purpose (e.g., a SEARCH response when no SEARCH
   command is in progress), the data can 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 an untagged EXISTS response
   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 - Generic 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 is presented
      to the user in a fashion that calls the user's attention to the
      message.  Content of ALERT response codes received on a connection
      without TLS or SASL security-layer confidentiality SHOULD be
      ignored by clients.  If displayed, such alerts MUST be clearly
      marked as potentially suspicious.  (Note that some existing
      clients are known to hyperlink returned text, which make them very
      dangerous.)  Alerts received after successful establishment of a
      TLS/SASL confidentiality layer MUST be presented to the user.
   ALREADYEXISTS
      The operation attempts to create something that already exists,
      such as when a CREATE or RENAME command attempts to create a
      mailbox and there is already one of that name.
        C: o356 RENAME this that
        S: o356 NO [ALREADYEXISTS] Mailbox "that" already exists
   APPENDUID
      Followed by the UIDVALIDITY of the destination mailbox and the UID
      assigned to the appended message in the destination mailbox, it
      indicates that the message has been appended to the destination
      mailbox with that UID.
      If the server also supports the [MULTIAPPEND] extension, and if
      multiple messages were appended in the APPEND command, then the
      second value is a UID set containing the UIDs assigned to the
      appended messages, in the order they were transmitted in the
      APPEND command.  This UID set may not contain extraneous UIDs or
      the symbol "*".
         Note: the UID set form of the APPENDUID response code MUST NOT
         be used if only a single message was appended.  In particular,
         a server MUST NOT send a range such as 123:123.  This is
         because a client that does not support [MULTIAPPEND] expects
         only a single UID and not a UID set.
      UIDs are assigned in strictly ascending order in the mailbox
      (refer to Section 2.3.1.1); note that a range of 12:10 is exactly
      equivalent to 10:12 and refers to the sequence 10,11,12.
      This response code is returned in a tagged OK response to the
      APPEND command.
   AUTHENTICATIONFAILED
      Authentication failed for some reason on which the server is
      unwilling to elaborate.  Typically, this includes "unknown user"
      and "bad password".
      This is the same as not sending any response code, except that
      when a client sees AUTHENTICATIONFAILED, it knows that the problem
      wasn't, e.g., UNAVAILABLE, so there's no point in trying the same
      login/password again later.
        C: b LOGIN "fred" "foo"
        S: b NO [AUTHENTICATIONFAILED] Authentication failed
   AUTHORIZATIONFAILED
      Authentication succeeded in using the authentication identity, but
      the server cannot or will not allow the authentication identity to
      act as the requested authorization identity.  This is only
      applicable when the authentication and authorization identities
      are different.
        C: c1 AUTHENTICATE PLAIN
        [...]
        S: c1 NO [AUTHORIZATIONFAILED] No such authorization-ID
        C: c2 AUTHENTICATE PLAIN
        [...]
        S: c2 NO [AUTHORIZATIONFAILED] Authenticator is not an admin
   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.
   CANNOT
      This operation violates some invariant of the server and can never
      succeed.
        C: l create "///////"
        S: l NO [CANNOT] Adjacent slashes are not supported
   CAPABILITY
      Followed by a list of capabilities.  This can appear in the
      initial OK or PREAUTH response to transmit an initial capabilities
      list.  It can also appear in tagged responses to LOGIN or
      AUTHENTICATE commands.  This makes it unnecessary for a client to
      send a separate CAPABILITY command if it recognizes this response
      code and there was no change to the TLS and/or authentication
      state since it was received.
   CLIENTBUG
      The server has detected a client bug.  This can accompany any of
      OK, NO, and BAD, depending on what the client bug is.
        C: k1 select "/archive/projects/experiment-iv"
        [...]
        S: k1 OK [READ-ONLY] Done
        C: k2 status "/archive/projects/experiment-iv" (messages)
        [...]
        S: k2 OK [CLIENTBUG] Done
   CLOSED
      The CLOSED response code has no parameters.  A server returns the
      CLOSED response code when the currently selected mailbox is closed
      implicitly using the SELECT or EXAMINE command on another mailbox.
      The CLOSED response code serves as a boundary between responses
      for the previously opened mailbox (which was closed) and the newly
      selected mailbox; all responses before the CLOSED response code
      relate to the mailbox that was closed, and all subsequent
      responses relate to the newly opened mailbox.
      There is no need to return the CLOSED response code on completion
      of the CLOSE or the UNSELECT command (or similar), whose purpose
      is to close the currently selected mailbox without opening a new
      one.
   CONTACTADMIN
      The user should contact the system administrator or support desk.
        C: e login "fred" "foo"
        S: e NO [CONTACTADMIN]
   COPYUID
      Followed by the UIDVALIDITY of the destination mailbox, a UID set
      containing the UIDs of the message(s) in the source mailbox that
      were copied to the destination mailbox, followed by another UID
      set containing the UIDs assigned to the copied message(s) in the
      destination mailbox, indicates that the message(s) has been copied
      to the destination mailbox with the stated UID(s).
      The source UID set is in the order the message(s) was copied; the
      destination UID set corresponds to the source UID set and is in
      the same order.  Neither of the UID sets may contain extraneous
      UIDs or the symbol "*".
      UIDs are assigned in strictly ascending order in the mailbox
      (refer to Section 2.3.1.1); note that a range of 12:10 is exactly
      equivalent to 10:12 and refers to the sequence 10,11,12.
      This response code is returned in a tagged OK response to the COPY
      or UID COPY command or in the untagged OK response to the MOVE or
      UID MOVE command.
   CORRUPTION
      The server discovered that some relevant data (e.g., the mailbox)
      are corrupt.  This response code does not include any information
      about what's corrupt, but the server can write that to its
      logfiles.
        C: i select "/archive/projects/experiment-iv"
        S: i NO [CORRUPTION] Cannot open mailbox
   EXPIRED
      Either authentication succeeded or the server no longer had the
      necessary data; either way, access is no longer permitted using
      that passphrase.  The client or user should get a new passphrase.
        C: d login "fred" "foo"
        S: d NO [EXPIRED] That password isn't valid any more
   EXPUNGEISSUED
      Someone else has issued an EXPUNGE for the same mailbox.  The
      client may want to issue NOOP soon.  [IMAP-MULTIACCESS] discusses
      this subject in depth.
        C: h search from maria@example.com
        S: * ESEARCH (TAG "h") ALL 1:3,5,8,13,21,42
        S: h OK [EXPUNGEISSUED] Search completed
   HASCHILDREN
      The mailbox delete operation failed because the mailbox has one or
      more children, and the server doesn't allow deletion of mailboxes
      with children.
        C: m356 DELETE Notes
        S: o356 NO [HASCHILDREN] Mailbox "Notes" has children
        that need to be deleted first
   INUSE
      An operation has not been carried out because it involves sawing
      off a branch someone else is sitting on.  Someone else may be
      holding an exclusive lock needed for this operation, or the
      operation may involve deleting a resource someone else is using,
      typically a mailbox.
      The operation may succeed if the client tries again later.
        C: g delete "/archive/projects/experiment-iv"
        S: g NO [INUSE] Mailbox in use
   LIMIT
      The operation ran up against an implementation limit of some kind,
      such as the number of flags on a single message or the number of
      flags used in a mailbox.
        C: m STORE 42 FLAGS f1 f2 f3 f4 f5 ... f250
        S: m NO [LIMIT] At most 32 flags in one mailbox supported
   NONEXISTENT
      The operation attempts to delete something that does not exist.
      Similar to ALREADYEXISTS.
        C: p RENAME this that
        S: p NO [NONEXISTENT] No such mailbox
   NOPERM
      The access control system (e.g., ACL; see [RFC4314]) does not
      permit this user to carry out an operation, such as selecting or
      creating a mailbox.
        C: f select "/archive/projects/experiment-iv"
        S: f NO [NOPERM] Access denied
   OVERQUOTA
      The user would be over quota after the operation.  (The user may
      or may not be over quota already.)
      Note that if the server sends OVERQUOTA but doesn't support the
      IMAP QUOTA extension defined by [RFC2087], then there is a quota,
      but the client cannot find out what the quota is.
        C: n1 uid copy 1:* oldmail
        S: n1 NO [OVERQUOTA] Sorry
        C: n2 uid copy 1:* oldmail
        S: n2 OK [OVERQUOTA] You are now over your soft quota
   PARSE
      The human-readable text represents an error in parsing the
      [RFC5322] header or [MIME-IMB] headers of a message in the
      mailbox.
   PERMANENTFLAGS
      Followed by a parenthesized list of flags and indicates which of
      the known flags the client can change permanently.  Any flags that
      are in the FLAGS untagged response, but not in the PERMANENTFLAGS
      list, cannot be set permanently.  The PERMANENTFLAGS list can also
      include the special flag \*, which indicates that it is possible
      to create new keywords by attempting to store those keywords in
      the mailbox.  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.
      There is no need for a server that included the special flag \* to
      return a new PERMANENTFLAGS response code when a new keyword was
      successfully set on a message upon client request.  However, if
      the server has a limit on the number of different keywords that
      can be stored in a mailbox and that limit is reached, the server
      MUST send a new PERMANENTFLAGS response code without the special
      flag \*.
   PRIVACYREQUIRED
      The operation is not permitted due to a lack of data
      confidentiality.  If TLS is not in use, the client could try
      STARTTLS (see Section 6.2.1) or alternatively reconnect on an
      Implicit TLS port, and then repeat the operation.
        C: d login "fred" "foo"
        S: d NO [PRIVACYREQUIRED] Connection offers no privacy
        C: d select inbox
        S: d NO [PRIVACYREQUIRED] Connection offers no privacy
   READ-ONLY
      The mailbox is selected as read-only, or its access while selected
      has changed from read-write to read-only.
   READ-WRITE
      The mailbox is selected as read-write, or its access while
      selected has changed from read-only to read-write.
   SERVERBUG
      The server encountered a bug in itself or violated one of its own
      invariants.
        C: j select "/archive/projects/experiment-iv"
        S: j NO [SERVERBUG] This should not happen
   TRYCREATE
      An APPEND, COPY, or MOVE 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 and indicates the next unique
      identifier value.  Refer to Section 2.3.1.1 for more information.
   UIDNOTSTICKY
      The selected mailbox is supported by a mail store that does not
      support persistent UIDs; that is, UIDVALIDITY will be different
      each time the mailbox is selected.  Consequently, APPEND or COPY
      to this mailbox will not return an APPENDUID or COPYUID response
      code.
      This response code is returned in an untagged NO response to the
      SELECT command.
         Note: servers SHOULD NOT have any UIDNOTSTICKY mail stores.
         This facility exists to support legacy mail stores in which it
         is technically infeasible to support persistent UIDs.  This
         should be avoided when designing new mail stores.
   UIDVALIDITY
      Followed by a decimal number and indicates the unique identifier
      validity value.  Refer to Section 2.3.1.1 for more information.
   UNAVAILABLE
      Temporary failure because a subsystem is down.  For example, an
      IMAP server that uses a Lightweight Directory Access Protocol
      (LDAP) or Radius server for authentication might use this response
      code when the LDAP/Radius server is down.
        C: a LOGIN "fred" "foo"
        S: a NO [UNAVAILABLE] User's backend down for maintenance
   UNKNOWN-CTE
      The server does not know how to decode the section's Content-
      Transfer-Encoding.
   Client implementations MUST 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 or an AUTHENTICATE command is needed.
   Example:
     S: * OK IMAP4rev2 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/
   AUTHENTICATE command is needed.
   Because PREAUTH moves the connection directly to the authenticated
   state, it effectively prevents the client from using the STARTTLS
   command (Section 6.2.1).  For this reason, the PREAUTH response
   SHOULD only be returned by servers on connections that are protected
   by TLS (such as on an Implicit TLS port [RFC8314]) or protected
   through other means such as IPsec.  Clients that require mandatory
   TLS MUST close the connection after receiving the PREAUTH response on
   a non-protected port.
   Example:
     S: * PREAUTH IMAP4rev2 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 Status
   These responses are always untagged.  This is how server status data
   are transmitted from the server to the client.
7.2.1.  ENABLED Response
   Contents:   capability listing
   The ENABLED response occurs as a result of an ENABLE command.  The
   capability listing contains a space-separated listing of capability
   names that the server supports and that were successfully enabled.
   The ENABLED response may contain no capabilities, which means that no
   extensions listed by the client were successfully enabled.
   Example:
     S: * ENABLED CONDSTORE QRESYNC
7.2.2.  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 "IMAP4rev2", but note that it doesn't have to
   be the first capability listed.  The order of capability names has no
   significance.
   Client and server implementations MUST implement the capabilities
   "AUTH=PLAIN" (described in [PLAIN]), and MUST implement "STARTTLS"
   and "LOGINDISABLED" on the cleartext port.  See the Security
   Considerations (Section 11) for important information related to
   these capabilities.
   A capability name that begins with "AUTH=" indicates that the server
   supports that particular authentication mechanism [SASL].
   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 (their validity will not be checked).  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 IMAP4rev2 protocol.  If
   IMAP4rev1 capability is not advertised, server responses MUST conform
   to this document until the client issues a command that uses an
   additional capability.  If both IMAP4rev1 and IMAP4rev2 capabilities
   are advertised, server responses MUST conform to [RFC3501] until the
   client issues a command that uses an additional capability.  (For
   example, the client can issue ENABLE IMAP4rev2 to enable
   IMAP4rev2-specific behavior.)
   Capability names SHOULD be registered with IANA using the RFC
   Required policy [RFC8126].  A server SHOULD NOT offer unregistered
   capability names.
   Client implementations SHOULD NOT require any capability name other
   than "IMAP4rev2", and possibly "STARTTLS" and "LOGINDISABLED" (on a
   cleartext port).  Client implementations 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 and there was no change to the TLS and/or authentication
   state since they were received.
   The list of capabilities returned by a server MAY change during the
   connection.  In particular, it is quite common for the server to
   change the list of capabilities after successful TLS negotiation
   (STARTTLS command) and/or after successful authentication
   (AUTHENTICATE or LOGIN commands).
   Example:
     S: * CAPABILITY STARTTLS AUTH=GSSAPI IMAP4rev2 LOGINDISABLED
      XPIG-LATIN
   Note that in the above example, XPIG-LATIN is a fictitious capability
   name.
7.3.  Server Responses - Mailbox Status
   These responses are always untagged.  This is how 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.3.1.  LIST Response
   Contents: 
               name attributes
               hierarchy delimiter
               name
               OPTIONAL extension data
   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.
   The following base mailbox name attributes are defined:
   \NonExistent
      The "\NonExistent" attribute indicates that a mailbox name does
      not refer to an existing mailbox.  Note that this attribute is not
      meaningful by itself, as mailbox names that match the canonical
      LIST pattern but don't exist must not be returned unless one of
      the two conditions listed below is also satisfied:
      1.  The mailbox name also satisfies the selection criteria (for
          example, it is subscribed and the "SUBSCRIBED" selection
          option has been specified).
      2.  "RECURSIVEMATCH" has been specified, and the mailbox name has
          at least one descendant mailbox name that does not match the
          LIST pattern and does match the selection criteria.
      In practice, this means that the "\NonExistent" attribute is
      usually returned with one or more of "\Subscribed", "\Remote",
      "\HasChildren", or the CHILDINFO extended data item.
      The "\NonExistent" attribute implies "\NoSelect".
   \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.
   \HasChildren
      The presence of this attribute indicates that the mailbox has
      child mailboxes.  A server SHOULD NOT set this attribute if there
      are child mailboxes and the user does not have permission to
      access any of them.  In this case, \HasNoChildren SHOULD be used.
      In many cases, however, a server may not be able to efficiently
      compute whether a user has access to any child mailboxes.  Note
      that even though the \HasChildren attribute for a mailbox must be
      correct at the time of processing the mailbox, a client must be
      prepared to deal with a situation when a mailbox is marked with
      the \HasChildren attribute, but no child mailbox appears in the
      response to the LIST command.  This might happen, for example, due
      to child mailboxes being deleted or made inaccessible to the user
      (using access control) by another client before the server is able
      to list them.
   \HasNoChildren
      The presence of this attribute indicates that the mailbox has NO
      child mailboxes that are accessible to the currently authenticated
      user.
   \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.
   \Subscribed
      The mailbox name was subscribed to using the SUBSCRIBE command.
   \Remote
      The mailbox is a remote mailbox.
   It is an error for the server to return both a \HasChildren and a
   \HasNoChildren attribute in the same LIST response.  A client that
   encounters a LIST response with both \HasChildren and \HasNoChildren
   attributes present should act as if both are absent in the LIST
   response.
      Note: the \HasNoChildren attribute should not be confused with the
      \NoInferiors attribute, which indicates that no child mailboxes
      exist now and none can be created in the future.
   If it is not feasible for the server to determine whether or not the
   mailbox is "interesting", the server SHOULD NOT send either \Marked
   or \Unmarked.  The server MUST NOT send more than one of \Marked,
   \Unmarked, and \Noselect for a single mailbox, and it MAY send none
   of these.
   In addition to the base mailbox name attributes defined above, an
   IMAP server MAY also include any or all of the following attributes
   that denote "role" (or "special-use") of a mailbox.  These attributes
   are included along with base attributes defined above.  A given
   mailbox may have none, one, or more than one of these attributes.  In
   some cases, a special use is advice to a client about what to put in
   that mailbox.  In other cases, it's advice to a client about what to
   expect to find there.
   \All
      This mailbox presents all messages in the user's message store.
      Implementations MAY omit some messages, such as, perhaps, those in
      \Trash and \Junk.  When this special use is supported, it is
      almost certain to represent a virtual mailbox.
   \Archive
      This mailbox is used to archive messages.  The meaning of an
      "archival" mailbox is server dependent; typically, it will be used
      to get messages out of the inbox, or otherwise keep them out of
      the user's way, while still making them accessible.
   \Drafts
      This mailbox is used to hold draft messages -- typically, messages
      that are being composed but have not yet been sent.  In some
      server implementations, this might be a virtual mailbox,
      containing messages from other mailboxes that are marked with the
      "\Draft" message flag.  Alternatively, this might just be advice
      that a client put drafts here.
   \Flagged
      This mailbox presents all messages marked in some way as
      "important".  When this special use is supported, it is likely to
      represent a virtual mailbox collecting messages (from other
      mailboxes) that are marked with the "\Flagged" message flag.
   \Junk
      This mailbox is where messages deemed to be junk mail are held.
      Some server implementations might put messages here automatically.
      Alternatively, this might just be advice to a client-side spam
      filter.
   \Sent
      This mailbox is used to hold copies of messages that have been
      sent.  Some server implementations might put messages here
      automatically.  Alternatively, this might just be advice that a
      client save sent messages here.
   \Trash
      This mailbox is used to hold messages that have been deleted or
      marked for deletion.  In some server implementations, this might
      be a virtual mailbox, containing messages from other mailboxes
      that are marked with the "\Deleted" message flag.  Alternatively,
      this might just be advice that a client that chooses not to use
      the IMAP "\Deleted" model should use as its trash location.  In
      server implementations that strictly expect the IMAP "\Deleted"
      model, this special use is likely not to be supported.
   All special-use attributes are OPTIONAL, and any given server or
   message store may support any combination of the attributes, or none
   at all.  In most cases, there will likely be at most one mailbox with
   a given attribute for a given user, but in some server or message
   store implementations, it might be possible for multiple mailboxes to
   have the same special-use attribute.
   Special-use attributes are likely to be user specific.  User Adam
   might share his \Sent mailbox with user Barb, but that mailbox is
   unlikely to also serve as Barb's \Sent mailbox.
   Other mailbox name attributes can be found in the "IMAP Mailbox Name
   Attributes" registry [IMAP-MAILBOX-NAME-ATTRS-REG].
   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 command.  Unless \Noselect or
   \NonExistent is indicated, the name MUST also be valid as an argument
   for commands, such as SELECT, that accept mailbox names.
   The name might be followed by an OPTIONAL series of extended fields,
   a parenthesized list of tagged data (also referred to as an "extended
   data item").  The first element of an extended field is a string,
   which identifies the type of data.  [RFC5258] specifies requirements
   on string registration (which are called "tags"; such tags are not to
   be confused with IMAP command tags); in particular, it states that
   "Tags MUST be registered with IANA".  This document doesn't change
   that.  See Section 9.5 of [RFC5258] for the registration template.
   The server MAY return data in the extended fields that was not
   directly solicited by the client in the corresponding LIST command.
   For example, the client can enable extra extended fields by using
   another IMAP extension that makes use of the extended LIST responses.
   The client MUST ignore all extended fields it doesn't recognize.
   Example:
     S: * LIST (\Noselect) "/" ~/Mail/foo
   Example:
     S: * LIST (\Marked) ":" Tables (tablecloth (("edge" "lacy")
         ("color" "red")) Sample "text")
     S: * LIST () ":" Tables:new (tablecloth ("edge" "lacy")
         Sample ("text" "more text"))
7.3.2.  NAMESPACE Response
   Contents:   the prefix and hierarchy delimiter to the server's
               Personal Namespace(s), Other Users' Namespace(s), and
               Shared Namespace(s)
   The NAMESPACE response occurs as a result of a NAMESPACE command.  It
   contains the prefix and hierarchy delimiter to the server's Personal
   Namespace(s), Other Users' Namespace(s), and Shared Namespace(s) that
   the server wishes to expose.  The response will contain a NIL for any
   namespace class that is not available.  The Namespace-Response-
   Extensions ABNF non-terminal is defined for extensibility and MAY be
   included in the response.
   Example:
     S: * NAMESPACE (("" "/")) (("~" "/")) NIL
7.3.3.  STATUS Response
   Contents: 
               name
               status parenthesized list
   The STATUS response occurs as a result of a 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.3.4.  ESEARCH Response
   Contents:   one or more search-return-data pairs
   The ESEARCH response occurs as a result of a SEARCH or UID SEARCH
   command.
   The ESEARCH response starts with an optional search correlator.  If
   it is missing, then the response was not caused by a particular IMAP
   command, whereas if it is present, it contains the tag of the command
   that caused the response to be returned.
   The search correlator is followed by an optional UID indicator.  If
   this indicator is present, all data in the ESEARCH response refers to
   UIDs; otherwise, all returned data refers to message numbers.
   The rest of the ESEARCH response contains one or more search data
   pairs.  Each pair starts with a unique return item name, followed by
   a space and the corresponding data.  Search data pairs may be
   returned in any order.  Unless otherwise specified by an extension,
   any return item name SHOULD appear only once in an ESEARCH response.
   This document specifies the following return item names:
   MIN
      Returns the lowest message number/UID that satisfies the SEARCH
      criteria.
      If the SEARCH results in no matches, the server MUST NOT include
      the MIN return item in the ESEARCH response; however, it still
      MUST send the ESEARCH response.
   MAX
      Returns the highest message number/UID that satisfies the SEARCH
      criteria.
      If the SEARCH results in no matches, the server MUST NOT include
      the MAX return item in the ESEARCH response; however, it still
      MUST send the ESEARCH response.
   ALL
      Returns all message numbers/UIDs that satisfy the SEARCH criteria
      using the sequence-set syntax.  Each set MUST be complete; in
      particular, a UID set is returned in an ESEARCH response only when
      each number in the range corresponds to an existing (matching)
      message.  The client MUST NOT assume that messages/UIDs will be
      listed in any particular order.
      If the SEARCH results in no matches, the server MUST NOT include
      the ALL return item in the ESEARCH response; however, it still
      MUST send the ESEARCH response.
   COUNT
      Returns the number of messages that satisfy the SEARCH criteria.
      This return item MUST always be included in the ESEARCH response.
   Example:
     S: * ESEARCH UID COUNT 17 ALL 4:18,21,28
   Example:
     S: * ESEARCH (TAG "a567") UID COUNT 17 ALL 4:18,21,28
   Example:
     S: * ESEARCH COUNT 18 ALL 1:17,21
7.3.5.  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 remembered by the client.
   Example:
     S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
7.4.  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.4.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 remembered by the client.
   Example:
     S: * 23 EXISTS
7.5.  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.5.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 remembered by the
   client.
   Example:
     S: * 44 EXPUNGE
7.5.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 are in
   parentheses.  This response occurs as the result of a FETCH or STORE
   command, as well as by a unilateral server decision (e.g., flag
   updates).
   The current data items are:
   BINARY[<section-binary>]<<number>>
      An <nstring> or <literal8> expressing the content of the specified
      section after removing any encoding specified in the corresponding
      Content-Transfer-Encoding header field.  If <number> is present,
      it refers to the offset within the DECODED section data.
      If the domain of the decoded data is "8bit" and the data does not
      contain the NUL octet, the server SHOULD return the data in a
      <string> instead of a <literal8>; this allows the client to
      determine if the "8bit" data contains the NUL octet without having
      to explicitly scan the data stream for NULs.
      Messaging clients and servers have been notoriously lax in their
      adherence to the Internet CRLF convention for terminating lines of
      textual data (text/* media types) in Internet protocols.  When
      sending data in a BINARY[...] FETCH data item, servers MUST ensure
      that textual line-oriented sections are always transmitted using
      the IMAP CRLF line termination syntax, regardless of the
      underlying storage representation of the data on the server.
      If the server does not know how to decode the section's Content-
      Transfer-Encoding, it MUST fail the request and issue a "NO"
      response that contains the "UNKNOWN-CTE" response code.
   BINARY.SIZE[<section-binary>]
      The size of the section after removing any encoding specified in
      the corresponding Content-Transfer-Encoding header field.  The
      value returned MUST match the size of the <nstring> or <literal8>
      that will be returned by the corresponding FETCH BINARY request.
      If the server does not know how to decode the section's Content-
      Transfer-Encoding, it MUST fail the request and issue a "NO"
      response that contains the "UNKNOWN-CTE" response code.
   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 or MESSAGE/GLOBAL part) MAY be in UTF-
      8.  Note also that the [RFC5322] 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 the header data, except
      in the case of a message that 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].  Servers SHOULD decode
      parameter-value continuations and parameter-value character sets
      as described in [RFC2231], for example, if the message contains
      parameters "baz*0", "baz*1", and "baz*2", the server should decode
      them per [RFC2231], concatenate, and return the resulting value as
      a parameter "baz".  Similarly, if the message contains parameters
      "foo*0*" and "foo*1*", the server should decode them per
      [RFC2231], convert to UTF-8, concatenate, and return the resulting
      value as a parameter "foo*".
   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].  Servers SHOULD decode
      parameter-value continuations as described in [RFC2231].
   body language
      A string or parenthesized list giving the body language value as
      defined in [LANGUAGE-TAGS].
   body location
      A string 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 header field value as defined in
      Section 7 of [MIME-IMB].
   body description
      A string giving the Content-Description header field value as
      defined in Section 8 of [MIME-IMB].
   body encoding
      A string giving the content transfer encoding as defined in
      Section 6 of [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 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 [RFC5322]
      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: display name, [SMTP] at-domain-list
      (source route and obs-route ABNF production from [RFC5322]),
      mailbox name (local-part ABNF production from [RFC5322]), and
      hostname.
      [RFC5322] group syntax is indicated by a special form of address
      structure in which the hostname field is NIL.  If the mailbox name
      field is also NIL, this is an end-of-group marker (semicolon in
      RFC 822 syntax).  If the mailbox name field is non-NIL, this is
      the start of a group marker, and the mailbox name field holds the
      group name phrase.
      If the Date, Subject, In-Reply-To, and Message-ID header fields
      are absent in the [RFC5322] header, the corresponding member of
      the envelope is NIL; if these header fields 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 the
         empty string as identical.
         Note: [RFC5322] requires that all messages have a valid Date
         header field.  Therefore, for a well-formed message, the date
         member in the envelope cannot be NIL or the empty string.
         However, it can be NIL for a malformed or draft message.
         Note: [RFC5322] requires that the In-Reply-To and Message-ID
         header fields, if present, have non-empty content.  Therefore,
         for a well-formed message, the in-reply-to and message-id
         members in the envelope cannot be the empty string.  However,
         they can still be the empty string for a malformed message.
      If the From, To, Cc, and Bcc header fields are absent in the
      [RFC5322] header, or are present but empty, the corresponding
      member of the envelope is NIL.
      If the Sender or Reply-To header fields are absent in the
      [RFC5322] 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 how to do this).
         Note: [RFC5322] requires that all messages have a valid From
         header field.  Therefore, for a well-formed message, the from,
         sender, and reply-to members in the envelope cannot be NIL.
         However, they can be NIL for a malformed or draft message.
   FLAGS
      A parenthesized list of flags that are set for this message.
   INTERNALDATE
      A string representing the internal date of the message.
   RFC822.SIZE
      A number expressing the size of a message, as described in
      Section 2.3.4.
   UID
      A number expressing the unique identifier of the message.
   If the server chooses to send unsolicited FETCH responses, they MUST
   include UID FETCH item.  Note that this is a new requirement when
   compared to [RFC3501].
   Example:
     S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827 UID 447)
7.6.  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 synchronizing
   literal.
   The client is not permitted to send the octets of the synchronizing
   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"