RFC's
rfc 3501 - INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1

Network Working Group                                         M. Crispin
Request for Comments: 3501                      University of Washington
Obsoletes: 2060                                               March 2003
Category: Standards Track


            INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1)
   allows a client to access and manipulate electronic mail messages on
   a server.  IMAP4rev1 permits manipulation of mailboxes (remote
   message folders) in a way that is functionally equivalent to local
   folders.  IMAP4rev1 also provides the capability for an offline
   client to resynchronize with the server.

   IMAP4rev1 includes operations for creating, deleting, and renaming
   mailboxes, checking for new messages, permanently removing messages,
   setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching,
   and selective fetching of message attributes, texts, and portions
   thereof.  Messages in IMAP4rev1 are accessed by the use of numbers.
   These numbers are either message sequence numbers or unique
   identifiers.

   IMAP4rev1 supports a single server.  A mechanism for accessing
   configuration information to support multiple IMAP4rev1 servers is
   discussed in RFC 2244.

   IMAP4rev1 does not specify a means of posting mail; this function is
   handled by a mail transfer protocol such as RFC 2821.

 

 

 


Crispin                     Standards Track                     [Page 1]

RFC 3501                         IMAPv4                       March 2003


Table of Contents

   IMAP4rev1 Protocol Specification ................................  4
   1.      How to Read This Document ...............................  4
   1.1.    Organization of This Document ...........................  4
   1.2.    Conventions Used in This Document .......................  4
   1.3.    Special Notes to Implementors ...........................  5
   2.      Protocol Overview .......................................  6
   2.1.    Link Level ..............................................  6
   2.2.    Commands and Responses ..................................  6
   2.2.1.  Client Protocol Sender and Server Protocol Receiver .....  6
   2.2.2.  Server Protocol Sender and Client Protocol Receiver .....  7
   2.3.    Message Attributes ......................................  8
   2.3.1.  Message Numbers .........................................  8
   2.3.1.1.        Unique Identifier (UID) Message Attribute .......  8
   2.3.1.2.        Message Sequence Number Message Attribute ....... 10
   2.3.2.  Flags Message Attribute ................................. 11
   2.3.3.  Internal Date Message Attribute ......................... 12
   2.3.4.  [RFC-2822] Size Message Attribute ....................... 12
   2.3.5.  Envelope Structure Message Attribute .................... 12
   2.3.6.  Body Structure Message Attribute ........................ 12
   2.4.    Message Texts ........................................... 13
   3.      State and Flow Diagram .................................. 13
   3.1.    Not Authenticated State ................................. 13
   3.2.    Authenticated State ..................................... 13
   3.3.    Selected State .......................................... 13
   3.4.    Logout State ............................................ 14
   4.      Data Formats ............................................ 16
   4.1.    Atom .................................................... 16
   4.2.    Number .................................................. 16
   4.3.    String .................................................. 16
   4.3.1.  8-bit and Binary Strings ................................ 17
   4.4.    Parenthesized List ...................................... 17
   4.5.    NIL ..................................................... 17
   5.      Operational Considerations .............................. 18
   5.1.    Mailbox Naming .......................................... 18
   5.1.1.  Mailbox Hierarchy Naming ................................ 19
   5.1.2.  Mailbox Namespace Naming Convention ..................... 19
   5.1.3.  Mailbox International Naming Convention ................. 19
   5.2.    Mailbox Size and Message Status Updates ................. 21
   5.3.    Response when no Command in Progress .................... 21
   5.4.    Autologout Timer ........................................ 22
   5.5.    Multiple Commands in Progress ........................... 22
   6.      Client Commands ........................................  23
   6.1.    Client Commands - Any State ............................  24
   6.1.1.  CAPABILITY Command .....................................  24
   6.1.2.  NOOP Command ...........................................  25
   6.1.3.  LOGOUT Command .........................................  26

 

Crispin                     Standards Track                     [Page 2]

RFC 3501                         IMAPv4                       March 2003


   6.2.    Client Commands - Not Authenticated State ..............  26
   6.2.1.  STARTTLS Command .......................................  27
   6.2.2.  AUTHENTICATE Command ...................................  28
   6.2.3.  LOGIN Command ..........................................  30
   6.3.    Client Commands - Authenticated State ..................  31
   6.3.1.  SELECT Command .........................................  32
   6.3.2.  EXAMINE Command ........................................  34
   6.3.3.  CREATE Command .........................................  34
   6.3.4.  DELETE Command .........................................  35
   6.3.5.  RENAME Command .........................................  37
   6.3.6.  SUBSCRIBE Command ......................................  39
   6.3.7.  UNSUBSCRIBE Command ....................................  39
   6.3.8.  LIST Command ...........................................  40
   6.3.9.  LSUB Command ...........................................  43
   6.3.10. STATUS Command .........................................  44
   6.3.11. APPEND Command .........................................  46
   6.4.    Client Commands - Selected State .......................  47
   6.4.1.  CHECK Command ..........................................  47
   6.4.2.  CLOSE Command ..........................................  48
   6.4.3.  EXPUNGE Command ........................................  49
   6.4.4.  SEARCH Command .........................................  49
   6.4.5.  FETCH Command ..........................................  54
   6.4.6.  STORE Command ..........................................  58
   6.4.7.  COPY Command ...........................................  59
   6.4.8.  UID Command ............................................  60
   6.5.    Client Commands - Experimental/Expansion ...............  62
   6.5.1.  X<atom> Command ........................................  62
   7.      Server Responses .......................................  62
   7.1.    Server Responses - Status Responses ....................  63
   7.1.1.  OK Response ............................................  65
   7.1.2.  NO Response ............................................  66
   7.1.3.  BAD Response ...........................................  66
   7.1.4.  PREAUTH Response .......................................  67
   7.1.5.  BYE Response ...........................................  67
   7.2.    Server Responses - Server and Mailbox Status ...........  68
   7.2.1.  CAPABILITY Response ....................................  68
   7.2.2.  LIST Response ..........................................  69
   7.2.3.  LSUB Response ..........................................  70
   7.2.4   STATUS Response ........................................  70
   7.2.5.  SEARCH Response ........................................  71
   7.2.6.  FLAGS Response .........................................  71
   7.3.    Server Responses - Mailbox Size ........................  71
   7.3.1.  EXISTS Response ........................................  71
   7.3.2.  RECENT Response ........................................  72
   7.4.    Server Responses - Message Status ......................  72
   7.4.1.  EXPUNGE Response .......................................  72
   7.4.2.  FETCH Response .........................................  73
   7.5.    Server Responses - Command Continuation Request ........  79

 

Crispin                     Standards Track                     [Page 3]

RFC 3501                         IMAPv4                       March 2003


   8.      Sample IMAP4rev1 connection ............................  80
   9.      Formal Syntax ..........................................  81
   10.     Author's Note ..........................................  92
   11.     Security Considerations ................................  92
   11.1.   STARTTLS Security Considerations .......................  92
   11.2.   Other Security Considerations ..........................  93
   12.     IANA Considerations ....................................  94
   Appendices .....................................................  95
   A.      References .............................................  95
   B.      Changes from RFC 2060 ..................................  97
   C.      Key Word Index ......................................... 103
   Author's Address ............................................... 107
   Full Copyright Statement ....................................... 108

IMAP4rev1 Protocol Specification

1.      How to Read This Document

1.1.    Organization of This Document

   This document is written from the point of view of the implementor of
   an IMAP4rev1 client or server.  Beyond the protocol overview in
   section 2, it is not optimized for someone trying to understand the
   operation of the protocol.  The material in sections 3 through 5
   provides the general context and definitions with which IMAP4rev1
   operates.

   Sections 6, 7, and 9 describe the IMAP commands, responses, and
   syntax, respectively.  The relationships among these are such that it
   is almost impossible to understand any of them separately.  In
   particular, do not attempt to deduce command syntax from the command
   section alone; instead refer to the Formal Syntax section.

1.2.    Conventions Used in This Document

   "Conventions" are basic principles or procedures.  Document
   conventions are noted in this section.

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to
   be interpreted as described in [KEYWORDS].

   The word "can" (not "may") is used to refer to a possible
   circumstance or situation, as opposed to an optional facility of the
   protocol.

 

Crispin                     Standards Track                     [Page 4]

RFC 3501                         IMAPv4                       March 2003


   "User" is used to refer to a human user, whereas "client" refers to
   the software being run by the user.

   "Connection" refers to the entire sequence of client/server
   interaction from the initial establishment of the network connection
   until its termination.

   "Session" refers to the sequence of client/server interaction from
   the time that a mailbox is selected (SELECT or EXAMINE command) until
   the time that selection ends (SELECT or EXAMINE of another mailbox,
   CLOSE command, or connection termination).

   Characters are 7-bit US-ASCII unless otherwise specified.  Other
   character sets are indicated using a "CHARSET", as described in
   [MIME-IMT] and defined in [CHARSET].  CHARSETs have important
   additional semantics in addition to defining character set; refer to
   these documents for more detail.

   There are several protocol conventions in IMAP.  These refer to
   aspects of the specification which are not strictly part of the IMAP
   protocol, but reflect generally-accepted practice.  Implementations
   need to be aware of these conventions, and avoid conflicts whether or
   not they implement the convention.  For example, "&" may not be used
   as a hierarchy delimiter since it conflicts with the Mailbox
   International Naming Convention, and other uses of "&" in mailbox
   names are impacted as well.

1.3.    Special Notes to Implementors

   Implementors of the IMAP protocol are strongly encouraged to read the
   IMAP implementation recommendations document [IMAP-IMPLEMENTATION] in
   conjunction with this document, to help understand the intricacies of
   this protocol and how best to build an interoperable product.

   IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and
   unpublished IMAP2bis protocols.  IMAP4rev1 is largely compatible with
   the IMAP4 protocol described in RFC 1730; the exception being in
   certain facilities added in RFC 1730 that proved problematic and were
   subsequently removed.  In the course of the evolution of IMAP4rev1,
   some aspects in the earlier protocols have become obsolete.  Obsolete
   commands, responses, and data formats which an IMAP4rev1
   implementation can encounter when used with an earlier implementation
   are described in [IMAP-OBSOLETE].

   Other compatibility issues with IMAP2bis, the most common variant of
   the earlier protocol, are discussed in [IMAP-COMPAT].  A full
   discussion of compatibility issues with rare (and presumed extinct)

 


Crispin                     Standards Track                     [Page 5]

RFC 3501                         IMAPv4                       March 2003


   variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is
   primarily of historical interest.

   IMAP was originally developed for the older [RFC-822] standard, and
   as a consequence several fetch items in IMAP incorporate "RFC822" in
   their name.  With the exception of RFC822.SIZE, there are more modern
   replacements; for example, the modern version of RFC822.HEADER is
   BODY.PEEK[HEADER].  In all cases, "RFC822" should be interpreted as a
   reference to the updated [RFC-2822] standard.

2.      Protocol Overview

2.1.    Link Level

   The IMAP4rev1 protocol assumes a reliable data stream such as that
   provided by TCP.  When TCP is used, an IMAP4rev1 server listens on
   port 143.

2.2.    Commands and Responses

   An IMAP4rev1 connection consists of the establishment of a
   client/server network connection, an initial greeting from the
   server, and client/server interactions.  These client/server
   interactions consist of a client command, server data, and a server
   completion result response.

   All interactions transmitted by client and server are in the form of
   lines, that is, strings that end with a CRLF.  The protocol receiver
   of an IMAP4rev1 client or server is either reading a line, or is
   reading a sequence of octets with a known count followed by a line.

2.2.1.  Client Protocol Sender and Server Protocol Receiver

   The client command begins an operation.  Each client command is
   prefixed with an identifier (typically a short alphanumeric string,
   e.g., A0001, A0002, etc.) called a "tag".  A different tag is
   generated by the client for each command.

   Clients MUST follow the syntax outlined in this specification
   strictly.  It is a syntax error to send a command with missing or
   extraneous spaces or arguments.

   There are two cases in which a line from the client does not
   represent a complete command.  In one case, a command argument is
   quoted with an octet count (see the description of literal in String
   under Data Formats); in the other case, the command arguments require
   server feedback (see the AUTHENTICATE command).  In either case, the

 


Crispin                     Standards Track                     [Page 6]

RFC 3501                         IMAPv4                       March 2003


   server sends a command continuation request response if it is ready
   for the octets (if appropriate) and the remainder of the command.
   This response is prefixed with the token "+".

        Note: If instead, the server detected an error in the
        command, it sends a BAD completion response with a tag
        matching the command (as described below) to reject the
        command and prevent the client from sending any more of the
        command.

        It is also possible for the server to send a completion
        response for some other command (if multiple commands are
        in progress), or untagged data.  In either case, the
        command continuation request is still pending; the client
        takes the appropriate action for the response, and reads
        another response from the server.  In all cases, the client
        MUST send a complete command (including receiving all
        command continuation request responses and command
        continuations for the command) before initiating a new
        command.

   The protocol receiver of an IMAP4rev1 server reads a command line
   from the client, parses the command and its arguments, and transmits
   server data and a server command completion result response.

2.2.2.  Server Protocol Sender and Client Protocol Receiver

   Data transmitted by the server to the client and status responses
   that do not indicate command completion are prefixed with the token
   "*", and are called untagged responses.

   Server data MAY be sent as a result of a client command, or MAY be
   sent unilaterally by the server.  There is no syntactic difference
   between server data that resulted from a specific command and server
   data that were sent unilaterally.

   The server completion result response indicates the success or
   failure of the operation.  It is tagged with the same tag as the
   client command which began the operation.  Thus, if more than one
   command is in progress, the tag in a server completion response
   identifies the command to which the response applies.  There are
   three possible server completion responses: OK (indicating success),
   NO (indicating failure), or BAD (indicating a protocol error such as
   unrecognized command or command syntax error).

   Servers SHOULD enforce the syntax outlined in this specification
   strictly.  Any client command with a protocol syntax error, including
   (but not limited to) missing or extraneous spaces or arguments,

 

Crispin                     Standards Track                     [Page 7]

RFC 3501                         IMAPv4                       March 2003


   SHOULD be rejected, and the client given a BAD server completion
   response.

   The protocol receiver of an IMAP4rev1 client reads a response line
   from the server.  It then takes action on the response based upon the
   first token of the response, which can be a tag, a "*", or a "+".

   A client MUST be prepared to accept any server response at all times.
   This includes server data that was not requested.  Server data SHOULD
   be recorded, so that the client can reference its recorded copy
   rather than sending a command to the server to request the data.  In
   the case of certain server data, the data MUST be recorded.

   This topic is discussed in greater detail in the Server Responses
   section.

2.3.    Message Attributes

   In addition to message text, each message has several attributes
   associated with it.  These attributes can be retrieved individually
   or in conjunction with other attributes or message texts.

2.3.1.  Message Numbers

   Messages in IMAP4rev1 are accessed by one of two numbers; the unique
   identifier or the message sequence number.


2.3.1.1.        Unique Identifier (UID) Message Attribute

   A 32-bit value assigned to each message, which when used with the
   unique identifier validity value (see below) forms a 64-bit value
   that MUST NOT refer to any other message in the mailbox or any
   subsequent mailbox with the same name forever.  Unique identifiers
   are assigned in a strictly ascending fashion in the mailbox; as each
   message is added to the mailbox it is assigned a higher UID than the
   message(s) which were added previously.  Unlike message sequence
   numbers, unique identifiers are not necessarily contiguous.

   The unique identifier of a message MUST NOT change during the
   session, and SHOULD NOT change between sessions.  Any change of
   unique identifiers between sessions MUST be detectable using the
   UIDVALIDITY mechanism discussed below.  Persistent unique identifiers
   are required for a client to resynchronize its state from a previous
   session with the server (e.g., disconnected or offline access
   clients); this is discussed further in [IMAP-DISC].

 

 

Crispin                     Standards Track                     [Page 8]

RFC 3501                         IMAPv4                       March 2003


   Associated with every mailbox are two values which aid in unique
   identifier handling: the next unique identifier value and the unique
   identifier validity value.

   The next unique identifier value is the predicted value that will be
   assigned to a new message in the mailbox.  Unless the unique
   identifier validity also changes (see below), the next unique
   identifier value MUST have the following two characteristics.  First,
   the next unique identifier value MUST NOT change unless new messages
   are added to the mailbox; and second, the next unique identifier
   value MUST change whenever new messages are added to the mailbox,
   even if those new messages are subsequently expunged.

        Note: The next unique identifier value is intended to
        provide a means for a client to determine whether any
        messages have been delivered to the mailbox since the
        previous time it checked this value.  It is not intended to
        provide any guarantee that any message will have this
        unique identifier.  A client can only assume, at the time
        that it obtains the next unique identifier value, that
        messages arriving after that time will have a UID greater
        than or equal to that value.

   The unique identifier validity value is sent in a UIDVALIDITY
   response code in an OK untagged response at mailbox selection time.
   If unique identifiers from an earlier session fail to persist in this
   session, the unique identifier validity value MUST be greater than
   the one used in the earlier session.

        Note: Ideally, unique identifiers SHOULD persist at all
        times.  Although this specification recognizes that failure
        to persist can be unavoidable in certain server
        environments, it STRONGLY ENCOURAGES message store
        implementation techniques that avoid this problem.  For
        example:

         1) Unique identifiers MUST be strictly ascending in the
            mailbox at all times.  If the physical message store is
            re-ordered by a non-IMAP agent, this requires that the
            unique identifiers in the mailbox be regenerated, since
            the former unique identifiers are no longer strictly
            ascending as a result of the re-ordering.

         2) If the message store has no mechanism to store unique
            identifiers, it must regenerate unique identifiers at
            each session, and each session must have a unique
            UIDVALIDITY value.

 


Crispin                     Standards Track                     [Page 9]

RFC 3501                         IMAPv4                       March 2003


         3) If the mailbox is deleted and a new mailbox with the
            same name is created at a later date, the server must
            either keep track of unique identifiers from the
            previous instance of the mailbox, or it must assign a
            new UIDVALIDITY value to the new instance of the
            mailbox.  A good UIDVALIDITY value to use in this case
            is a 32-bit representation of the creation date/time of
            the mailbox.  It is alright to use a constant such as
            1, but only if it guaranteed that unique identifiers
            will never be reused, even in the case of a mailbox
            being deleted (or renamed) and a new mailbox by the
            same name created at some future time.

         4) The combination of mailbox name, UIDVALIDITY, and UID
            must refer to a single immutable message on that server
            forever.  In particular, the internal date, [RFC-2822]
            size, envelope, body structure, and message texts
            (RFC822, RFC822.HEADER, RFC822.TEXT, and all BODY[...]
            fetch data items) must never change.  This does not
            include message numbers, nor does it include attributes
            that can be set by a STORE command (e.g., FLAGS).


2.3.1.2.        Message Sequence Number Message Attribute

   A relative position from 1 to the number of messages in the mailbox.
   This position MUST be ordered by ascending unique identifier.  As
   each new message is added, it is assigned a message sequence number
   that is 1 higher than the number of messages in the mailbox before
   that new message was added.

   Message sequence numbers can be reassigned during the session.  For
   example, when a message is permanently removed (expunged) from the
   mailbox, the message sequence number for all subsequent messages is
   decremented.  The number of messages in the mailbox is also
   decremented.  Similarly, a new message can be assigned a message
   sequence number that was once held by some other message prior to an
   expunge.

   In addition to accessing messages by relative position in the
   mailbox, message sequence numbers can be used in mathematical
   calculations.  For example, if an untagged "11 EXISTS" is received,
   and previously an untagged "8 EXISTS" was received, three new
   messages have arrived with message sequence numbers of 9, 10, and 11.
   Another example, if message 287 in a 523 message mailbox has UID
   12345, there are exactly 286 messages which have lesser UIDs and 236
   messages which have greater UIDs.

 


Crispin                     Standards Track                    [Page 10]

RFC 3501                         IMAPv4                       March 2003


2.3.2.  Flags Message Attribute

   A list of zero or more named tokens associated with the message.  A
   flag is set by its addition to this list, and is cleared by its
   removal.  There are two types of flags in IMAP4rev1.  A flag of
   either type can be permanent or session-only.

   A system flag is a flag name that is pre-defined in this
   specification.  All system flags begin with "\".  Certain system
   flags (\Deleted and \Seen) have special semantics described
   elsewhere.  The currently-defined system flags are:

        \Seen
           Message has been read

        \Answered
           Message has been answered

        \Flagged
           Message is "flagged" for urgent/special attention

        \Deleted
           Message is "deleted" for removal by later EXPUNGE

        \Draft
           Message has not completed composition (marked as a draft).

        \Recent
           Message is "recently" arrived in this mailbox.  This session
           is the first session to have been notified about this
           message; if the session is read-write, subsequent sessions
           will not see \Recent set for this message.  This flag can not
           be altered by the client.

           If it is not possible to determine whether or not this
           session is the first session to be notified about a message,
           then that message SHOULD be considered recent.

           If multiple connections have the same mailbox selected
           simultaneously, it is undefined which of these connections
           will see newly-arrived messages with \Recent set and which
           will see it without \Recent set.

   A keyword is defined by the server implementation.  Keywords do not
   begin with "\".  Servers MAY permit the client to define new keywords
   in the mailbox (see the description of the PERMANENTFLAGS response
   code for more information).

 


Crispin                     Standards Track                    [Page 11]

RFC 3501                         IMAPv4                       March 2003


   A flag can be permanent or session-only on a per-flag basis.
   Permanent flags are those which the client can add or remove from the
   message flags permanently; that is, concurrent and subsequent
   sessions will see any change in permanent flags.  Changes to session
   flags are valid only in that session.

        Note: The \Recent system flag is a special case of a
        session flag.  \Recent can not be used as an argument in a
        STORE or APPEND command, and thus can not be changed at
        all.

2.3.3.  Internal Date Message Attribute

   The internal date and time of the message on the server.  This
   is not the date and time in the [RFC-2822] header, but rather a
   date and time which reflects when the message was received.  In
   the case of messages delivered via [SMTP], this SHOULD be the
   date and time of final delivery of the message as defined by
   [SMTP].  In the case of messages delivered by the IMAP4rev1 COPY
   command, this SHOULD be the internal date and time of the source
   message.  In the case of messages delivered by the IMAP4rev1
   APPEND command, this SHOULD be the date and time as specified in
   the APPEND command description.  All other cases are
   implementation defined.

2.3.4.  [RFC-2822] Size Message Attribute

   The number of octets in the message, as expressed in [RFC-2822]
   format.

2.3.5.  Envelope Structure Message Attribute

   A parsed representation of the [RFC-2822] header of the message.
   Note that the IMAP Envelope structure is not the same as an
   [SMTP] envelope.

2.3.6.  Body Structure Message Attribute

   A parsed representation of the [MIME-IMB] body structure
   information of the message.

 

 

 

 

 

Crispin                     Standards Track                    [Page 12]

RFC 3501                         IMAPv4                       March 2003


2.4.    Message Texts

   In addition to being able to fetch the full [RFC-2822] text of a
   message, IMAP4rev1 permits the fetching of portions of the full
   message text.  Specifically, it is possible to fetch the
   [RFC-2822] message header, [RFC-2822] message body, a [MIME-IMB]
   body part, or a [MIME-IMB] header.

3.      State and Flow Diagram

   Once the connection between client and server is established, an
   IMAP4rev1 connection is in one of four states.  The initial
   state is identified in the server greeting.  Most commands are
   only valid in certain states.  It is a protocol error for the
   client to attempt a command while the connection is in an
   inappropriate state, and the server will respond with a BAD or
   NO (depending upon server implementation) command completion
   result.

3.1.    Not Authenticated State

   In the not authenticated state, the client MUST supply
   authentication credentials before most commands will be
   permitted.  This state is entered when a connection starts
   unless the connection has been pre-authenticated.

3.2.    Authenticated State

   In the authenticated state, the client is authenticated and MUST
   select a mailbox to access before commands that affect messages
   will be permitted.  This state is entered when a
   pre-authenticated connection starts, when acceptable
   authentication credentials have been provided, after an error in
   selecting a mailbox, or after a successful CLOSE command.

3.3.    Selected State

   In a selected state, a mailbox has been selected to access.
   This state is entered when a mailbox has been successfully
   selected.

 

 

 

 

 

Crispin                     Standards Track                    [Page 13]

RFC 3501                         IMAPv4                       March 2003


3.4.    Logout State

   In the logout state, the connection is being terminated.  This
   state can be entered as a result of a client request (via the
   LOGOUT command) or by unilateral action on the part of either
   the client or server.

   If the client requests the logout state, the server MUST send an
   untagged BYE response and a tagged OK response to the LOGOUT
   command before the server closes the connection; and the client
   MUST read the tagged OK response to the LOGOUT command before
   the client closes the connection.

   A server MUST NOT unilaterally close the connection without
   sending an untagged BYE response that contains the reason for
   having done so.  A client SHOULD NOT unilaterally close the
   connection, and instead SHOULD issue a LOGOUT command.  If the
   server detects that the client has unilaterally closed the
   connection, the server MAY omit the untagged BYE response and
   simply close its connection.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Crispin                     Standards Track                    [Page 14]

RFC 3501                         IMAPv4                       March 2003


                   +----------------------+
                   |connection established|
                   +----------------------+
                              ||
                              \/
            +--------------------------------------+
            |          server greeting             |
            +--------------------------------------+
                      || (1)       || (2)        || (3)
                      \/           ||            ||
            +-----------------+    ||            ||
            |Not Authenticated|    ||            ||
            +-----------------+    ||            ||
             || (7)   || (4)       ||            ||
             ||       \/           \/            ||
             ||     +----------------+           ||
             ||     | Authenticated  |<=++       ||
             ||     +----------------+  ||       ||
             ||       || (7)   || (5)   || (6)   ||
             ||       ||       \/       ||       ||
             ||       ||    +--------+  ||       ||
             ||       ||    |Selected|==++       ||
             ||       ||    +--------+           ||
             ||       ||       || (7)            ||
             \/       \/       \/                \/
            +--------------------------------------+
            |               Logout                 |
            +--------------------------------------+
                              ||
                              \/
                +-------------------------------+
                |both sides close the connection|
                +-------------------------------+

         (1) connection without pre-authentication (OK greeting)
         (2) pre-authenticated connection (PREAUTH greeting)
         (3) rejected connection (BYE greeting)
         (4) successful LOGIN or AUTHENTICATE command
         (5) successful SELECT or EXAMINE command
         (6) CLOSE command, or failed SELECT or EXAMINE command
         (7) LOGOUT command, server shutdown, or connection closed

 

 

 

 


Crispin                     Standards Track                    [Page 15]

RFC 3501                         IMAPv4                       March 2003


4.      Data Formats

   IMAP4rev1 uses textual commands and responses.  Data in
   IMAP4rev1 can be in one of several forms: atom, number, string,
   parenthesized list, or NIL.  Note that a particular data item
   may take more than one form; for example, a data item defined as
   using "astring" syntax may be either an atom or a string.

4.1.    Atom

   An atom consists of one or more non-special characters.

4.2.    Number

   A number consists of one or more digit characters, and
   represents a numeric value.

4.3.    String

   A string is in one of two forms: either literal or quoted
   string.  The literal form is the general form of string.  The
   quoted string form is an alternative that avoids the overhead of
   processing a literal at the cost of limitations of characters
   which may be used.

   A literal is a sequence of zero or more octets (including CR and
   LF), prefix-quoted with an octet count in the form of an open
   brace ("{"), the number of octets, close brace ("}"), and CRLF.
   In the case of literals transmi

&lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;Network Working Group&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; M. Crispin Request for Comments: 3501&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; University of Washington Obsoletes: 2060&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; March 2003 Category: Standards Track&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt; &lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;Status of this Memo&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; This document specifies an Internet standards track protocol for the &amp;nbsp;&amp;nbsp; Internet community, and requests discussion and suggestions for &amp;nbsp;&amp;nbsp; improvements.&amp;nbsp; Please refer to the current edition of the &quot;Internet &amp;nbsp;&amp;nbsp; Official Protocol Standards&quot; (STD 1) for the standardization state &amp;nbsp;&amp;nbsp; and status of this protocol.&amp;nbsp; Distribution of this memo is unlimited.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;Copyright Notice&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; Copyright (C) The Internet Society (2003).&amp;nbsp; All Rights Reserved.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;Abstract&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) &amp;nbsp;&amp;nbsp; allows a client to access and manipulate electronic mail messages on &amp;nbsp;&amp;nbsp; a server.&amp;nbsp; IMAP4rev1 permits manipulation of mailboxes (remote &amp;nbsp;&amp;nbsp; message folders) in a way that is functionally equivalent to local &amp;nbsp;&amp;nbsp; folders.&amp;nbsp; IMAP4rev1 also provides the capability for an offline &amp;nbsp;&amp;nbsp; client to resynchronize with the server.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; IMAP4rev1 includes operations for creating, deleting, and renaming &amp;nbsp;&amp;nbsp; mailboxes, checking for new messages, permanently removing messages, &amp;nbsp;&amp;nbsp; setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching, &amp;nbsp;&amp;nbsp; and selective fetching of message attributes, texts, and portions &amp;nbsp;&amp;nbsp; thereof.&amp;nbsp; Messages in IMAP4rev1 are accessed by the use of numbers. &amp;nbsp;&amp;nbsp; These numbers are either message sequence numbers or unique &amp;nbsp;&amp;nbsp; identifiers.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; IMAP4rev1 supports a single server.&amp;nbsp; A mechanism for accessing &amp;nbsp;&amp;nbsp; configuration information to support multiple IMAP4rev1 servers is &amp;nbsp;&amp;nbsp; discussed in RFC 2244.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; IMAP4rev1 does not specify a means of posting mail; this function is &amp;nbsp;&amp;nbsp; handled by a mail transfer protocol such as RFC 2821.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt; &lt;FONT face=&quot;courier new,courier&quot;&gt;Crispin&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Standards Track&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; [Page 1] RFC 3501&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; IMAPv4&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; March 2003&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt; &lt;FONT face=&quot;courier new,courier&quot;&gt;Table of Contents&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; IMAP4rev1 Protocol Specification ................................&amp;nbsp; 4 &amp;nbsp;&amp;nbsp; 1.&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; How to Read This Document ...............................&amp;nbsp; 4 &amp;nbsp;&amp;nbsp; 1.1.&amp;nbsp;&amp;nbsp;&amp;nbsp; Organization of This Document ...........................&amp;nbsp; 4 &amp;nbsp;&amp;nbsp; 1.2.&amp;nbsp;&amp;nbsp;&amp;nbsp; Conventions Used in This Document .......................&amp;nbsp; 4 &amp;nbsp;&amp;nbsp; 1.3.&amp;nbsp;&amp;nbsp;&amp;nbsp; Special Notes to Implementors ...........................&amp;nbsp; 5 &amp;nbsp;&amp;nbsp; 2.&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Protocol Overview .......................................&amp;nbsp; 6 &amp;nbsp;&amp;nbsp; 2.1.&amp;nbsp;&amp;nbsp;&amp;nbsp; Link Level ..............................................&amp;nbsp; 6 &amp;nbsp;&amp;nbsp; 2.2.&amp;nbsp;&amp;nbsp;&amp;nbsp; Commands and Responses ..................................&amp;nbsp; 6 &amp;nbsp;&amp;nbsp; 2.2.1.&amp;nbsp; Client Protocol Sender and Server Protocol Receiver .....&amp;nbsp; 6 &amp;nbsp;&amp;nbsp; 2.2.2.&amp;nbsp; Server Protocol Sender and Client Protocol Receiver .....&amp;nbsp; 7 &amp;nbsp;&amp;nbsp; 2.3.&amp;nbsp;&amp;nbsp;&amp;nbsp; Message Attributes ......................................&amp;nbsp; 8 &amp;nbsp;&amp;nbsp; 2.3.1.&amp;nbsp; Message Numbers .........................................&amp;nbsp; 8 &amp;nbsp;&amp;nbsp; 2.3.1.1.&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Unique Identifier (UID) Message Attribute .......&amp;nbsp; 8 &amp;nbsp;&amp;nbsp; 2.3.1.2.&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Message Sequence Number Message Attribute ....... 10 &amp;nbsp;&amp;nbsp; 2.3.2.&amp;nbsp; Flags Message Attribute ................................. 11 &amp;nbsp;&amp;nbsp; 2.3.3.&amp;nbsp; Internal Date Message Attribute ......................... 12 &amp;nbsp;&amp;nbsp; 2.3.4.&amp;nbsp; [RFC-2822] Size Message Attribute ....................... 12 &amp;nbsp;&amp;nbsp; 2.3.5.&amp;nbsp; Envelope Structure Message Attribute .................... 12 &amp;nbsp;&amp;nbsp; 2.3.6.&amp;nbsp; Body Structure Message Attribute ........................ 12 &amp;nbsp;&amp;nbsp; 2.4.&amp;nbsp;&amp;nbsp;&amp;nbsp; Message Texts ........................................... 13 &amp;nbsp;&amp;nbsp; 3.&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; State and Flow Diagram .................................. 13 &amp;nbsp;&amp;nbsp; 3.1.&amp;nbsp;&amp;nbsp;&amp;nbsp; Not Authenticated State ................................. 13 &amp;nbsp;&amp;nbsp; 3.2.&amp;nbsp;&amp;nbsp;&amp;nbsp; Authenticated State ..................................... 13 &amp;nbsp;&amp;nbsp; 3.3.&amp;nbsp;&amp;nbsp;&amp;nbsp; Selected State .......................................... 13 &amp;nbsp;&amp;nbsp; 3.4.&amp;nbsp;&amp;nbsp;&amp;nbsp; Logout State ............................................ 14 &amp;nbsp;&amp;nbsp; 4.&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Data Formats ............................................ 16 &amp;nbsp;&amp;nbsp; 4.1.&amp;nbsp;&amp;nbsp;&amp;nbsp; Atom .................................................... 16 &amp;nbsp;&amp;nbsp; 4.2.&amp;nbsp;&amp;nbsp;&amp;nbsp; Number .................................................. 16 &amp;nbsp;&amp;nbsp; 4.3.&amp;nbsp;&amp;nbsp;&amp;nbsp; String .................................................. 16 &amp;nbsp;&amp;nbsp; 4.3.1.&amp;nbsp; 8-bit and Binary Strings ................................ 17 &amp;nbsp;&amp;nbsp; 4.4.&amp;nbsp;&amp;nbsp;&amp;nbsp; Parenthesized List ...................................... 17 &amp;nbsp;&amp;nbsp; 4.5.&amp;nbsp;&amp;nbsp;&amp;nbsp; NIL ..................................................... 17 &amp;nbsp;&amp;nbsp; 5.&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Operational Considerations .............................. 18 &amp;nbsp;&amp;nbsp; 5.1.&amp;nbsp;&amp;nbsp;&amp;nbsp; Mailbox Naming .......................................... 18 &amp;nbsp;&amp;nbsp; 5.1.1.&amp;nbsp; Mailbox Hierarchy Naming ................................ 19 &amp;nbsp;&amp;nbsp; 5.1.2.&amp;nbsp; Mailbox Namespace Naming Convention ..................... 19 &amp;nbsp;&amp;nbsp; 5.1.3.&amp;nbsp; Mailbox International Naming Convention ................. 19 &amp;nbsp;&amp;nbsp; 5.2.&amp;nbsp;&amp;nbsp;&amp;nbsp; Mailbox Size and Message Status Updates ................. 21 &amp;nbsp;&amp;nbsp; 5.3.&amp;nbsp;&amp;nbsp;&amp;nbsp; Response when no Command in Progress .................... 21 &amp;nbsp;&amp;nbsp; 5.4.&amp;nbsp;&amp;nbsp;&amp;nbsp; Autologout Timer ........................................ 22 &amp;nbsp;&amp;nbsp; 5.5.&amp;nbsp;&amp;nbsp;&amp;nbsp; Multiple Commands in Progress ........................... 22 &amp;nbsp;&amp;nbsp; 6.&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Client Commands ........................................&amp;nbsp; 23 &amp;nbsp;&amp;nbsp; 6.1.&amp;nbsp;&amp;nbsp;&amp;nbsp; Client Commands - Any State ............................&amp;nbsp; 24 &amp;nbsp;&amp;nbsp; 6.1.1.&amp;nbsp; CAPABILITY Command .....................................&amp;nbsp; 24 &amp;nbsp;&amp;nbsp; 6.1.2.&amp;nbsp; NOOP Command ...........................................&amp;nbsp; 25 &amp;nbsp;&amp;nbsp; 6.1.3.&amp;nbsp; LOGOUT Command .........................................&amp;nbsp; 26&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;Crispin&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Standards Track&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; [Page 2] RFC 3501&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; IMAPv4&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; March 2003&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt; &lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; 6.2.&amp;nbsp;&amp;nbsp;&amp;nbsp; Client Commands - Not Authenticated State ..............&amp;nbsp; 26 &amp;nbsp;&amp;nbsp; 6.2.1.&amp;nbsp; STARTTLS Command .......................................&amp;nbsp; 27 &amp;nbsp;&amp;nbsp; 6.2.2.&amp;nbsp; AUTHENTICATE Command ...................................&amp;nbsp; 28 &amp;nbsp;&amp;nbsp; 6.2.3.&amp;nbsp; LOGIN Command ..........................................&amp;nbsp; 30 &amp;nbsp;&amp;nbsp; 6.3.&amp;nbsp;&amp;nbsp;&amp;nbsp; Client Commands - Authenticated State ..................&amp;nbsp; 31 &amp;nbsp;&amp;nbsp; 6.3.1.&amp;nbsp; SELECT Command .........................................&amp;nbsp; 32 &amp;nbsp;&amp;nbsp; 6.3.2.&amp;nbsp; EXAMINE Command ........................................&amp;nbsp; 34 &amp;nbsp;&amp;nbsp; 6.3.3.&amp;nbsp; CREATE Command .........................................&amp;nbsp; 34 &amp;nbsp;&amp;nbsp; 6.3.4.&amp;nbsp; DELETE Command .........................................&amp;nbsp; 35 &amp;nbsp;&amp;nbsp; 6.3.5.&amp;nbsp; RENAME Command .........................................&amp;nbsp; 37 &amp;nbsp;&amp;nbsp; 6.3.6.&amp;nbsp; SUBSCRIBE Command ......................................&amp;nbsp; 39 &amp;nbsp;&amp;nbsp; 6.3.7.&amp;nbsp; UNSUBSCRIBE Command ....................................&amp;nbsp; 39 &amp;nbsp;&amp;nbsp; 6.3.8.&amp;nbsp; LIST Command ...........................................&amp;nbsp; 40 &amp;nbsp;&amp;nbsp; 6.3.9.&amp;nbsp; LSUB Command ...........................................&amp;nbsp; 43 &amp;nbsp;&amp;nbsp; 6.3.10. STATUS Command .........................................&amp;nbsp; 44 &amp;nbsp;&amp;nbsp; 6.3.11. APPEND Command .........................................&amp;nbsp; 46 &amp;nbsp;&amp;nbsp; 6.4.&amp;nbsp;&amp;nbsp;&amp;nbsp; Client Commands - Selected State .......................&amp;nbsp; 47 &amp;nbsp;&amp;nbsp; 6.4.1.&amp;nbsp; CHECK Command ..........................................&amp;nbsp; 47 &amp;nbsp;&amp;nbsp; 6.4.2.&amp;nbsp; CLOSE Command ..........................................&amp;nbsp; 48 &amp;nbsp;&amp;nbsp; 6.4.3.&amp;nbsp; EXPUNGE Command ........................................&amp;nbsp; 49 &amp;nbsp;&amp;nbsp; 6.4.4.&amp;nbsp; SEARCH Command .........................................&amp;nbsp; 49 &amp;nbsp;&amp;nbsp; 6.4.5.&amp;nbsp; FETCH Command ..........................................&amp;nbsp; 54 &amp;nbsp;&amp;nbsp; 6.4.6.&amp;nbsp; STORE Command ..........................................&amp;nbsp; 58 &amp;nbsp;&amp;nbsp; 6.4.7.&amp;nbsp; COPY Command ...........................................&amp;nbsp; 59 &amp;nbsp;&amp;nbsp; 6.4.8.&amp;nbsp; UID Command ............................................&amp;nbsp; 60 &amp;nbsp;&amp;nbsp; 6.5.&amp;nbsp;&amp;nbsp;&amp;nbsp; Client Commands - Experimental/Expansion ...............&amp;nbsp; 62 &amp;nbsp;&amp;nbsp; 6.5.1.&amp;nbsp; X&amp;lt;atom&amp;gt; Command ........................................&amp;nbsp; 62 &amp;nbsp;&amp;nbsp; 7.&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Server Responses .......................................&amp;nbsp; 62 &amp;nbsp;&amp;nbsp; 7.1.&amp;nbsp;&amp;nbsp;&amp;nbsp; Server Responses - Status Responses ....................&amp;nbsp; 63 &amp;nbsp;&amp;nbsp; 7.1.1.&amp;nbsp; OK Response ............................................&amp;nbsp; 65 &amp;nbsp;&amp;nbsp; 7.1.2.&amp;nbsp; NO Response ............................................&amp;nbsp; 66 &amp;nbsp;&amp;nbsp; 7.1.3.&amp;nbsp; BAD Response ...........................................&amp;nbsp; 66 &amp;nbsp;&amp;nbsp; 7.1.4.&amp;nbsp; PREAUTH Response .......................................&amp;nbsp; 67 &amp;nbsp;&amp;nbsp; 7.1.5.&amp;nbsp; BYE Response ...........................................&amp;nbsp; 67 &amp;nbsp;&amp;nbsp; 7.2.&amp;nbsp;&amp;nbsp;&amp;nbsp; Server Responses - Server and Mailbox Status ...........&amp;nbsp; 68 &amp;nbsp;&amp;nbsp; 7.2.1.&amp;nbsp; CAPABILITY Response ....................................&amp;nbsp; 68 &amp;nbsp;&amp;nbsp; 7.2.2.&amp;nbsp; LIST Response ..........................................&amp;nbsp; 69 &amp;nbsp;&amp;nbsp; 7.2.3.&amp;nbsp; LSUB Response ..........................................&amp;nbsp; 70 &amp;nbsp;&amp;nbsp; 7.2.4&amp;nbsp;&amp;nbsp; STATUS Response ........................................&amp;nbsp; 70 &amp;nbsp;&amp;nbsp; 7.2.5.&amp;nbsp; SEARCH Response ........................................&amp;nbsp; 71 &amp;nbsp;&amp;nbsp; 7.2.6.&amp;nbsp; FLAGS Response .........................................&amp;nbsp; 71 &amp;nbsp;&amp;nbsp; 7.3.&amp;nbsp;&amp;nbsp;&amp;nbsp; Server Responses - Mailbox Size ........................&amp;nbsp; 71 &amp;nbsp;&amp;nbsp; 7.3.1.&amp;nbsp; EXISTS Response ........................................&amp;nbsp; 71 &amp;nbsp;&amp;nbsp; 7.3.2.&amp;nbsp; RECENT Response ........................................&amp;nbsp; 72 &amp;nbsp;&amp;nbsp; 7.4.&amp;nbsp;&amp;nbsp;&amp;nbsp; Server Responses - Message Status ......................&amp;nbsp; 72 &amp;nbsp;&amp;nbsp; 7.4.1.&amp;nbsp; EXPUNGE Response .......................................&amp;nbsp; 72 &amp;nbsp;&amp;nbsp; 7.4.2.&amp;nbsp; FETCH Response .........................................&amp;nbsp; 73 &amp;nbsp;&amp;nbsp; 7.5.&amp;nbsp;&amp;nbsp;&amp;nbsp; Server Responses - Command Continuation Request ........&amp;nbsp; 79&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;Crispin&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Standards Track&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; [Page 3] RFC 3501&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; IMAPv4&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; March 2003&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt; &lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; 8.&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Sample IMAP4rev1 connection ............................&amp;nbsp; 80 &amp;nbsp;&amp;nbsp; 9.&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Formal Syntax ..........................................&amp;nbsp; 81 &amp;nbsp;&amp;nbsp; 10.&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Author&#039;s Note ..........................................&amp;nbsp; 92 &amp;nbsp;&amp;nbsp; 11.&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Security Considerations ................................&amp;nbsp; 92 &amp;nbsp;&amp;nbsp; 11.1.&amp;nbsp;&amp;nbsp; STARTTLS Security Considerations .......................&amp;nbsp; 92 &amp;nbsp;&amp;nbsp; 11.2.&amp;nbsp;&amp;nbsp; Other Security Considerations ..........................&amp;nbsp; 93 &amp;nbsp;&amp;nbsp; 12.&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; IANA Considerations ....................................&amp;nbsp; 94 &amp;nbsp;&amp;nbsp; Appendices .....................................................&amp;nbsp; 95 &amp;nbsp;&amp;nbsp; A.&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; References .............................................&amp;nbsp; 95 &amp;nbsp;&amp;nbsp; B.&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Changes from RFC 2060 ..................................&amp;nbsp; 97 &amp;nbsp;&amp;nbsp; C.&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Key Word Index ......................................... 103 &amp;nbsp;&amp;nbsp; Author&#039;s Address ............................................... 107 &amp;nbsp;&amp;nbsp; Full Copyright Statement ....................................... 108&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;IMAP4rev1 Protocol Specification&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;1.&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; How to Read This Document&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;1.1.&amp;nbsp;&amp;nbsp;&amp;nbsp; Organization of This Document&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; This document is written from the point of view of the implementor of &amp;nbsp;&amp;nbsp; an IMAP4rev1 client or server.&amp;nbsp; Beyond the protocol overview in &amp;nbsp;&amp;nbsp; section 2, it is not optimized for someone trying to understand the &amp;nbsp;&amp;nbsp; operation of the protocol.&amp;nbsp; The material in sections 3 through 5 &amp;nbsp;&amp;nbsp; provides the general context and definitions with which IMAP4rev1 &amp;nbsp;&amp;nbsp; operates.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; Sections 6, 7, and 9 describe the IMAP commands, responses, and &amp;nbsp;&amp;nbsp; syntax, respectively.&amp;nbsp; The relationships among these are such that it &amp;nbsp;&amp;nbsp; is almost impossible to understand any of them separately.&amp;nbsp; In &amp;nbsp;&amp;nbsp; particular, do not attempt to deduce command syntax from the command &amp;nbsp;&amp;nbsp; section alone; instead refer to the Formal Syntax section.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;1.2.&amp;nbsp;&amp;nbsp;&amp;nbsp; Conventions Used in This Document&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; &quot;Conventions&quot; are basic principles or procedures.&amp;nbsp; Document &amp;nbsp;&amp;nbsp; conventions are noted in this section.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; In examples, &quot;C:&quot; and &quot;S:&quot; indicate lines sent by the client and &amp;nbsp;&amp;nbsp; server respectively.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;, &amp;nbsp;&amp;nbsp; &quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;MAY&quot;, and &quot;OPTIONAL&quot; in this document are to &amp;nbsp;&amp;nbsp; be interpreted as described in [KEYWORDS].&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; The word &quot;can&quot; (not &quot;may&quot;) is used to refer to a possible &amp;nbsp;&amp;nbsp; circumstance or situation, as opposed to an optional facility of the &amp;nbsp;&amp;nbsp; protocol.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;Crispin&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Standards Track&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; [Page 4] RFC 3501&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; IMAPv4&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; March 2003&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt; &lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; &quot;User&quot; is used to refer to a human user, whereas &quot;client&quot; refers to &amp;nbsp;&amp;nbsp; the software being run by the user.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; &quot;Connection&quot; refers to the entire sequence of client/server &amp;nbsp;&amp;nbsp; interaction from the initial establishment of the network connection &amp;nbsp;&amp;nbsp; until its termination.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; &quot;Session&quot; refers to the sequence of client/server interaction from &amp;nbsp;&amp;nbsp; the time that a mailbox is selected (SELECT or EXAMINE command) until &amp;nbsp;&amp;nbsp; the time that selection ends (SELECT or EXAMINE of another mailbox, &amp;nbsp;&amp;nbsp; CLOSE command, or connection termination).&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; Characters are 7-bit US-ASCII unless otherwise specified.&amp;nbsp; Other &amp;nbsp;&amp;nbsp; character sets are indicated using a &quot;CHARSET&quot;, as described in &amp;nbsp;&amp;nbsp; [MIME-IMT] and defined in [CHARSET].&amp;nbsp; CHARSETs have important &amp;nbsp;&amp;nbsp; additional semantics in addition to defining character set; refer to &amp;nbsp;&amp;nbsp; these documents for more detail.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; There are several protocol conventions in IMAP.&amp;nbsp; These refer to &amp;nbsp;&amp;nbsp; aspects of the specification which are not strictly part of the IMAP &amp;nbsp;&amp;nbsp; protocol, but reflect generally-accepted practice.&amp;nbsp; Implementations &amp;nbsp;&amp;nbsp; need to be aware of these conventions, and avoid conflicts whether or &amp;nbsp;&amp;nbsp; not they implement the convention.&amp;nbsp; For example, &quot;&amp;amp;&quot; may not be used &amp;nbsp;&amp;nbsp; as a hierarchy delimiter since it conflicts with the Mailbox &amp;nbsp;&amp;nbsp; International Naming Convention, and other uses of &quot;&amp;amp;&quot; in mailbox &amp;nbsp;&amp;nbsp; names are impacted as well.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;1.3.&amp;nbsp;&amp;nbsp;&amp;nbsp; Special Notes to Implementors&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; Implementors of the IMAP protocol are strongly encouraged to read the &amp;nbsp;&amp;nbsp; IMAP implementation recommendations document [IMAP-IMPLEMENTATION] in &amp;nbsp;&amp;nbsp; conjunction with this document, to help understand the intricacies of &amp;nbsp;&amp;nbsp; this protocol and how best to build an interoperable product.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and &amp;nbsp;&amp;nbsp; unpublished IMAP2bis protocols.&amp;nbsp; IMAP4rev1 is largely compatible with &amp;nbsp;&amp;nbsp; the IMAP4 protocol described in RFC 1730; the exception being in &amp;nbsp;&amp;nbsp; certain facilities added in RFC 1730 that proved problematic and were &amp;nbsp;&amp;nbsp; subsequently removed.&amp;nbsp; In the course of the evolution of IMAP4rev1, &amp;nbsp;&amp;nbsp; some aspects in the earlier protocols have become obsolete.&amp;nbsp; Obsolete &amp;nbsp;&amp;nbsp; commands, responses, and data formats which an IMAP4rev1 &amp;nbsp;&amp;nbsp; implementation can encounter when used with an earlier implementation &amp;nbsp;&amp;nbsp; are described in [IMAP-OBSOLETE].&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; Other compatibility issues with IMAP2bis, the most common variant of &amp;nbsp;&amp;nbsp; the earlier protocol, are discussed in [IMAP-COMPAT].&amp;nbsp; A full &amp;nbsp;&amp;nbsp; discussion of compatibility issues with rare (and presumed extinct)&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt; &lt;FONT face=&quot;courier new,courier&quot;&gt;Crispin&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Standards Track&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; [Page 5] RFC 3501&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; IMAPv4&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; March 2003&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt; &lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is &amp;nbsp;&amp;nbsp; primarily of historical interest.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; IMAP was originally developed for the older [RFC-822] standard, and &amp;nbsp;&amp;nbsp; as a consequence several fetch items in IMAP incorporate &quot;RFC822&quot; in &amp;nbsp;&amp;nbsp; their name.&amp;nbsp; With the exception of RFC822.SIZE, there are more modern &amp;nbsp;&amp;nbsp; replacements; for example, the modern version of RFC822.HEADER is &amp;nbsp;&amp;nbsp; BODY.PEEK[HEADER].&amp;nbsp; In all cases, &quot;RFC822&quot; should be interpreted as a &amp;nbsp;&amp;nbsp; reference to the updated [RFC-2822] standard.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;2.&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Protocol Overview&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;2.1.&amp;nbsp;&amp;nbsp;&amp;nbsp; Link Level&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; The IMAP4rev1 protocol assumes a reliable data stream such as that &amp;nbsp;&amp;nbsp; provided by TCP.&amp;nbsp; When TCP is used, an IMAP4rev1 server listens on &amp;nbsp;&amp;nbsp; port 143.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;2.2.&amp;nbsp;&amp;nbsp;&amp;nbsp; Commands and Responses&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; An IMAP4rev1 connection consists of the establishment of a &amp;nbsp;&amp;nbsp; client/server network connection, an initial greeting from the &amp;nbsp;&amp;nbsp; server, and client/server interactions.&amp;nbsp; These client/server &amp;nbsp;&amp;nbsp; interactions consist of a client command, server data, and a server &amp;nbsp;&amp;nbsp; completion result response.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; All interactions transmitted by client and server are in the form of &amp;nbsp;&amp;nbsp; lines, that is, strings that end with a CRLF.&amp;nbsp; The protocol receiver &amp;nbsp;&amp;nbsp; of an IMAP4rev1 client or server is either reading a line, or is &amp;nbsp;&amp;nbsp; reading a sequence of octets with a known count followed by a line.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;2.2.1.&amp;nbsp; Client Protocol Sender and Server Protocol Receiver&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; The client command begins an operation.&amp;nbsp; Each client command is &amp;nbsp;&amp;nbsp; prefixed with an identifier (typically a short alphanumeric string, &amp;nbsp;&amp;nbsp; e.g., A0001, A0002, etc.) called a &quot;tag&quot;.&amp;nbsp; A different tag is &amp;nbsp;&amp;nbsp; generated by the client for each command.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; Clients MUST follow the syntax outlined in this specification &amp;nbsp;&amp;nbsp; strictly.&amp;nbsp; It is a syntax error to send a command with missing or &amp;nbsp;&amp;nbsp; extraneous spaces or arguments.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; There are two cases in which a line from the client does not &amp;nbsp;&amp;nbsp; represent a complete command.&amp;nbsp; In one case, a command argument is &amp;nbsp;&amp;nbsp; quoted with an octet count (see the description of literal in String &amp;nbsp;&amp;nbsp; under Data Formats); in the other case, the command arguments require &amp;nbsp;&amp;nbsp; server feedback (see the AUTHENTICATE command).&amp;nbsp; In either case, the&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt; &lt;FONT face=&quot;courier new,courier&quot;&gt;Crispin&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Standards Track&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; [Page 6] RFC 3501&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; IMAPv4&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; March 2003&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt; &lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; server sends a command continuation request response if it is ready &amp;nbsp;&amp;nbsp; for the octets (if appropriate) and the remainder of the command. &amp;nbsp;&amp;nbsp; This response is prefixed with the token &quot;+&quot;.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Note: If instead, the server detected an error in the &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; command, it sends a BAD completion response with a tag &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; matching the command (as described below) to reject the &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; command and prevent the client from sending any more of the &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; command.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; It is also possible for the server to send a completion &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; response for some other command (if multiple commands are &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; in progress), or untagged data.&amp;nbsp; In either case, the &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; command continuation request is still pending; the client &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; takes the appropriate action for the response, and reads &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; another response from the server.&amp;nbsp; In all cases, the client &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; MUST send a complete command (including receiving all &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; command continuation request responses and command &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; continuations for the command) before initiating a new &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; command.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; The protocol receiver of an IMAP4rev1 server reads a command line &amp;nbsp;&amp;nbsp; from the client, parses the command and its arguments, and transmits &amp;nbsp;&amp;nbsp; server data and a server command completion result response.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;2.2.2.&amp;nbsp; Server Protocol Sender and Client Protocol Receiver&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; Data transmitted by the server to the client and status responses &amp;nbsp;&amp;nbsp; that do not indicate command completion are prefixed with the token &amp;nbsp;&amp;nbsp; &quot;*&quot;, and are called untagged responses.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; Server data MAY be sent as a result of a client command, or MAY be &amp;nbsp;&amp;nbsp; sent unilaterally by the server.&amp;nbsp; There is no syntactic difference &amp;nbsp;&amp;nbsp; between server data that resulted from a specific command and server &amp;nbsp;&amp;nbsp; data that were sent unilaterally.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; The server completion result response indicates the success or &amp;nbsp;&amp;nbsp; failure of the operation.&amp;nbsp; It is tagged with the same tag as the &amp;nbsp;&amp;nbsp; client command which began the operation.&amp;nbsp; Thus, if more than one &amp;nbsp;&amp;nbsp; command is in progress, the tag in a server completion response &amp;nbsp;&amp;nbsp; identifies the command to which the response applies.&amp;nbsp; There are &amp;nbsp;&amp;nbsp; three possible server completion responses: OK (indicating success), &amp;nbsp;&amp;nbsp; NO (indicating failure), or BAD (indicating a protocol error such as &amp;nbsp;&amp;nbsp; unrecognized command or command syntax error).&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; Servers SHOULD enforce the syntax outlined in this specification &amp;nbsp;&amp;nbsp; strictly.&amp;nbsp; Any client command with a protocol syntax error, including &amp;nbsp;&amp;nbsp; (but not limited to) missing or extraneous spaces or arguments,&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;Crispin&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Standards Track&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; [Page 7] RFC 3501&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; IMAPv4&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; March 2003&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt; &lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; SHOULD be rejected, and the client given a BAD server completion &amp;nbsp;&amp;nbsp; response.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; The protocol receiver of an IMAP4rev1 client reads a response line &amp;nbsp;&amp;nbsp; from the server.&amp;nbsp; It then takes action on the response based upon the &amp;nbsp;&amp;nbsp; first token of the response, which can be a tag, a &quot;*&quot;, or a &quot;+&quot;.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; A client MUST be prepared to accept any server response at all times. &amp;nbsp;&amp;nbsp; This includes server data that was not requested.&amp;nbsp; Server data SHOULD &amp;nbsp;&amp;nbsp; be recorded, so that the client can reference its recorded copy &amp;nbsp;&amp;nbsp; rather than sending a command to the server to request the data.&amp;nbsp; In &amp;nbsp;&amp;nbsp; the case of certain server data, the data MUST be recorded.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; This topic is discussed in greater detail in the Server Responses &amp;nbsp;&amp;nbsp; section.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;2.3.&amp;nbsp;&amp;nbsp;&amp;nbsp; Message Attributes&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; In addition to message text, each message has several attributes &amp;nbsp;&amp;nbsp; associated with it.&amp;nbsp; These attributes can be retrieved individually &amp;nbsp;&amp;nbsp; or in conjunction with other attributes or message texts.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;2.3.1.&amp;nbsp; Message Numbers&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; Messages in IMAP4rev1 are accessed by one of two numbers; the unique &amp;nbsp;&amp;nbsp; identifier or the message sequence number.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt; &lt;FONT face=&quot;courier new,courier&quot;&gt;2.3.1.1.&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Unique Identifier (UID) Message Attribute&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; A 32-bit value assigned to each message, which when used with the &amp;nbsp;&amp;nbsp; unique identifier validity value (see below) forms a 64-bit value &amp;nbsp;&amp;nbsp; that MUST NOT refer to any other message in the mailbox or any &amp;nbsp;&amp;nbsp; subsequent mailbox with the same name forever.&amp;nbsp; Unique identifiers &amp;nbsp;&amp;nbsp; are assigned in a strictly ascending fashion in the mailbox; as each &amp;nbsp;&amp;nbsp; message is added to the mailbox it is assigned a higher UID than the &amp;nbsp;&amp;nbsp; message(s) which were added previously.&amp;nbsp; Unlike message sequence &amp;nbsp;&amp;nbsp; numbers, unique identifiers are not necessarily contiguous.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; The unique identifier of a message MUST NOT change during the &amp;nbsp;&amp;nbsp; session, and SHOULD NOT change between sessions.&amp;nbsp; Any change of &amp;nbsp;&amp;nbsp; unique identifiers between sessions MUST be detectable using the &amp;nbsp;&amp;nbsp; UIDVALIDITY mechanism discussed below.&amp;nbsp; Persistent unique identifiers &amp;nbsp;&amp;nbsp; are required for a client to resynchronize its state from a previous &amp;nbsp;&amp;nbsp; session with the server (e.g., disconnected or offline access &amp;nbsp;&amp;nbsp; clients); this is discussed further in [IMAP-DISC].&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;Crispin&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Standards Track&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; [Page 8] RFC 3501&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; IMAPv4&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; March 2003&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt; &lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; Associated with every mailbox are two values which aid in unique &amp;nbsp;&amp;nbsp; identifier handling: the next unique identifier value and the unique &amp;nbsp;&amp;nbsp; identifier validity value.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; The next unique identifier value is the predicted value that will be &amp;nbsp;&amp;nbsp; assigned to a new message in the mailbox.&amp;nbsp; Unless the unique &amp;nbsp;&amp;nbsp; identifier validity also changes (see below), the next unique &amp;nbsp;&amp;nbsp; identifier value MUST have the following two characteristics.&amp;nbsp; First, &amp;nbsp;&amp;nbsp; the next unique identifier value MUST NOT change unless new messages &amp;nbsp;&amp;nbsp; are added to the mailbox; and second, the next unique identifier &amp;nbsp;&amp;nbsp; value MUST change whenever new messages are added to the mailbox, &amp;nbsp;&amp;nbsp; even if those new messages are subsequently expunged.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Note: The next unique identifier value is intended to &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; provide a means for a client to determine whether any &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; messages have been delivered to the mailbox since the &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; previous time it checked this value.&amp;nbsp; It is not intended to &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; provide any guarantee that any message will have this &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; unique identifier.&amp;nbsp; A client can only assume, at the time &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; that it obtains the next unique identifier value, that &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; messages arriving after that time will have a UID greater &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; than or equal to that value.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; The unique identifier validity value is sent in a UIDVALIDITY &amp;nbsp;&amp;nbsp; response code in an OK untagged response at mailbox selection time. &amp;nbsp;&amp;nbsp; If unique identifiers from an earlier session fail to persist in this &amp;nbsp;&amp;nbsp; session, the unique identifier validity value MUST be greater than &amp;nbsp;&amp;nbsp; the one used in the earlier session.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Note: Ideally, unique identifiers SHOULD persist at all &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; times.&amp;nbsp; Although this specification recognizes that failure &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; to persist can be unavoidable in certain server &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; environments, it STRONGLY ENCOURAGES message store &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; implementation techniques that avoid this problem.&amp;nbsp; For &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; example:&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 1) Unique identifiers MUST be strictly ascending in the &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; mailbox at all times.&amp;nbsp; If the physical message store is &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; re-ordered by a non-IMAP agent, this requires that the &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; unique identifiers in the mailbox be regenerated, since &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; the former unique identifiers are no longer strictly &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; ascending as a result of the re-ordering.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 2) If the message store has no mechanism to store unique &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; identifiers, it must regenerate unique identifiers at &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; each session, and each session must have a unique &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; UIDVALIDITY value.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt; &lt;FONT face=&quot;courier new,courier&quot;&gt;Crispin&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Standards Track&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; [Page 9] RFC 3501&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; IMAPv4&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; March 2003&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt; &lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 3) If the mailbox is deleted and a new mailbox with the &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; same name is created at a later date, the server must &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; either keep track of unique identifiers from the &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; previous instance of the mailbox, or it must assign a &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; new UIDVALIDITY value to the new instance of the &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; mailbox.&amp;nbsp; A good UIDVALIDITY value to use in this case &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; is a 32-bit representation of the creation date/time of &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; the mailbox.&amp;nbsp; It is alright to use a constant such as &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 1, but only if it guaranteed that unique identifiers &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; will never be reused, even in the case of a mailbox &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; being deleted (or renamed) and a new mailbox by the &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; same name created at some future time.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; 4) The combination of mailbox name, UIDVALIDITY, and UID &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; must refer to a single immutable message on that server &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; forever.&amp;nbsp; In particular, the internal date, [RFC-2822] &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; size, envelope, body structure, and message texts &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; (RFC822, RFC822.HEADER, RFC822.TEXT, and all BODY[...] &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; fetch data items) must never change.&amp;nbsp; This does not &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; include message numbers, nor does it include attributes &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; that can be set by a STORE command (e.g., FLAGS).&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt; &lt;FONT face=&quot;courier new,courier&quot;&gt;2.3.1.2.&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Message Sequence Number Message Attribute&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; A relative position from 1 to the number of messages in the mailbox. &amp;nbsp;&amp;nbsp; This position MUST be ordered by ascending unique identifier.&amp;nbsp; As &amp;nbsp;&amp;nbsp; each new message is added, it is assigned a message sequence number &amp;nbsp;&amp;nbsp; that is 1 higher than the number of messages in the mailbox before &amp;nbsp;&amp;nbsp; that new message was added.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; Message sequence numbers can be reassigned during the session.&amp;nbsp; For &amp;nbsp;&amp;nbsp; example, when a message is permanently removed (expunged) from the &amp;nbsp;&amp;nbsp; mailbox, the message sequence number for all subsequent messages is &amp;nbsp;&amp;nbsp; decremented.&amp;nbsp; The number of messages in the mailbox is also &amp;nbsp;&amp;nbsp; decremented.&amp;nbsp; Similarly, a new message can be assigned a message &amp;nbsp;&amp;nbsp; sequence number that was once held by some other message prior to an &amp;nbsp;&amp;nbsp; expunge.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; In addition to accessing messages by relative position in the &amp;nbsp;&amp;nbsp; mailbox, message sequence numbers can be used in mathematical &amp;nbsp;&amp;nbsp; calculations.&amp;nbsp; For example, if an untagged &quot;11 EXISTS&quot; is received, &amp;nbsp;&amp;nbsp; and previously an untagged &quot;8 EXISTS&quot; was received, three new &amp;nbsp;&amp;nbsp; messages have arrived with message sequence numbers of 9, 10, and 11. &amp;nbsp;&amp;nbsp; Another example, if message 287 in a 523 message mailbox has UID &amp;nbsp;&amp;nbsp; 12345, there are exactly 286 messages which have lesser UIDs and 236 &amp;nbsp;&amp;nbsp; messages which have greater UIDs.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt; &lt;FONT face=&quot;courier new,courier&quot;&gt;Crispin&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Standards Track&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; [Page 10] RFC 3501&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; IMAPv4&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; March 2003&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt; &lt;FONT face=&quot;courier new,courier&quot;&gt;2.3.2.&amp;nbsp; Flags Message Attribute&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; A list of zero or more named tokens associated with the message.&amp;nbsp; A &amp;nbsp;&amp;nbsp; flag is set by its addition to this list, and is cleared by its &amp;nbsp;&amp;nbsp; removal.&amp;nbsp; There are two types of flags in IMAP4rev1.&amp;nbsp; A flag of &amp;nbsp;&amp;nbsp; either type can be permanent or session-only.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; A system flag is a flag name that is pre-defined in this &amp;nbsp;&amp;nbsp; specification.&amp;nbsp; All system flags begin with &quot;\&quot;.&amp;nbsp; Certain system &amp;nbsp;&amp;nbsp; flags (\Deleted and \Seen) have special semantics described &amp;nbsp;&amp;nbsp; elsewhere.&amp;nbsp; The currently-defined system flags are:&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; \Seen &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Message has been read&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; \Answered &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Message has been answered&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; \Flagged &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Message is &quot;flagged&quot; for urgent/special attention&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; \Deleted &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Message is &quot;deleted&quot; for removal by later EXPUNGE&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; \Draft &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Message has not completed composition (marked as a draft).&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; \Recent &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Message is &quot;recently&quot; arrived in this mailbox.&amp;nbsp; This session &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; is the first session to have been notified about this &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; message; if the session is read-write, subsequent sessions &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; will not see \Recent set for this message.&amp;nbsp; This flag can not &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; be altered by the client.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; If it is not possible to determine whether or not this &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; session is the first session to be notified about a message, &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; then that message SHOULD be considered recent.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; If multiple connections have the same mailbox selected &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; simultaneously, it is undefined which of these connections &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; will see newly-arrived messages with \Recent set and which &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; will see it without \Recent set.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; A keyword is defined by the server implementation.&amp;nbsp; Keywords do not &amp;nbsp;&amp;nbsp; begin with &quot;\&quot;.&amp;nbsp; Servers MAY permit the client to define new keywords &amp;nbsp;&amp;nbsp; in the mailbox (see the description of the PERMANENTFLAGS response &amp;nbsp;&amp;nbsp; code for more information).&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt; &lt;FONT face=&quot;courier new,courier&quot;&gt;Crispin&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Standards Track&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; [Page 11] RFC 3501&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; IMAPv4&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; March 2003&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt; &lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; A flag can be permanent or session-only on a per-flag basis. &amp;nbsp;&amp;nbsp; Permanent flags are those which the client can add or remove from the &amp;nbsp;&amp;nbsp; message flags permanently; that is, concurrent and subsequent &amp;nbsp;&amp;nbsp; sessions will see any change in permanent flags.&amp;nbsp; Changes to session &amp;nbsp;&amp;nbsp; flags are valid only in that session.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Note: The \Recent system flag is a special case of a &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; session flag.&amp;nbsp; \Recent can not be used as an argument in a &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; STORE or APPEND command, and thus can not be changed at &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; all.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;2.3.3.&amp;nbsp; Internal Date Message Attribute&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; The internal date and time of the message on the server.&amp;nbsp; This &amp;nbsp;&amp;nbsp; is not the date and time in the [RFC-2822] header, but rather a &amp;nbsp;&amp;nbsp; date and time which reflects when the message was received.&amp;nbsp; In &amp;nbsp;&amp;nbsp; the case of messages delivered via [SMTP], this SHOULD be the &amp;nbsp;&amp;nbsp; date and time of final delivery of the message as defined by &amp;nbsp;&amp;nbsp; [SMTP].&amp;nbsp; In the case of messages delivered by the IMAP4rev1 COPY &amp;nbsp;&amp;nbsp; command, this SHOULD be the internal date and time of the source &amp;nbsp;&amp;nbsp; message.&amp;nbsp; In the case of messages delivered by the IMAP4rev1 &amp;nbsp;&amp;nbsp; APPEND command, this SHOULD be the date and time as specified in &amp;nbsp;&amp;nbsp; the APPEND command description.&amp;nbsp; All other cases are &amp;nbsp;&amp;nbsp; implementation defined.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;2.3.4.&amp;nbsp; [RFC-2822] Size Message Attribute&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; The number of octets in the message, as expressed in [RFC-2822] &amp;nbsp;&amp;nbsp; format.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;2.3.5.&amp;nbsp; Envelope Structure Message Attribute&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; A parsed representation of the [RFC-2822] header of the message. &amp;nbsp;&amp;nbsp; Note that the IMAP Envelope structure is not the same as an &amp;nbsp;&amp;nbsp; [SMTP] envelope.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;2.3.6.&amp;nbsp; Body Structure Message Attribute&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; A parsed representation of the [MIME-IMB] body structure &amp;nbsp;&amp;nbsp; information of the message.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;Crispin&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Standards Track&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; [Page 12] RFC 3501&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; IMAPv4&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; March 2003&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt; &lt;FONT face=&quot;courier new,courier&quot;&gt;2.4.&amp;nbsp;&amp;nbsp;&amp;nbsp; Message Texts&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; In addition to being able to fetch the full [RFC-2822] text of a &amp;nbsp;&amp;nbsp; message, IMAP4rev1 permits the fetching of portions of the full &amp;nbsp;&amp;nbsp; message text.&amp;nbsp; Specifically, it is possible to fetch the &amp;nbsp;&amp;nbsp; [RFC-2822] message header, [RFC-2822] message body, a [MIME-IMB] &amp;nbsp;&amp;nbsp; body part, or a [MIME-IMB] header.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;3.&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; State and Flow Diagram&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; Once the connection between client and server is established, an &amp;nbsp;&amp;nbsp; IMAP4rev1 connection is in one of four states.&amp;nbsp; The initial &amp;nbsp;&amp;nbsp; state is identified in the server greeting.&amp;nbsp; Most commands are &amp;nbsp;&amp;nbsp; only valid in certain states.&amp;nbsp; It is a protocol error for the &amp;nbsp;&amp;nbsp; client to attempt a command while the connection is in an &amp;nbsp;&amp;nbsp; inappropriate state, and the server will respond with a BAD or &amp;nbsp;&amp;nbsp; NO (depending upon server implementation) command completion &amp;nbsp;&amp;nbsp; result.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;3.1.&amp;nbsp;&amp;nbsp;&amp;nbsp; Not Authenticated State&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; In the not authenticated state, the client MUST supply &amp;nbsp;&amp;nbsp; authentication credentials before most commands will be &amp;nbsp;&amp;nbsp; permitted.&amp;nbsp; This state is entered when a connection starts &amp;nbsp;&amp;nbsp; unless the connection has been pre-authenticated.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;3.2.&amp;nbsp;&amp;nbsp;&amp;nbsp; Authenticated State&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; In the authenticated state, the client is authenticated and MUST &amp;nbsp;&amp;nbsp; select a mailbox to access before commands that affect messages &amp;nbsp;&amp;nbsp; will be permitted.&amp;nbsp; This state is entered when a &amp;nbsp;&amp;nbsp; pre-authenticated connection starts, when acceptable &amp;nbsp;&amp;nbsp; authentication credentials have been provided, after an error in &amp;nbsp;&amp;nbsp; selecting a mailbox, or after a successful CLOSE command.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;3.3.&amp;nbsp;&amp;nbsp;&amp;nbsp; Selected State&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; In a selected state, a mailbox has been selected to access. &amp;nbsp;&amp;nbsp; This state is entered when a mailbox has been successfully &amp;nbsp;&amp;nbsp; selected.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;Crispin&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Standards Track&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; [Page 13] RFC 3501&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; IMAPv4&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; March 2003&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt; &lt;FONT face=&quot;courier new,courier&quot;&gt;3.4.&amp;nbsp;&amp;nbsp;&amp;nbsp; Logout State&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; In the logout state, the connection is being terminated.&amp;nbsp; This &amp;nbsp;&amp;nbsp; state can be entered as a result of a client request (via the &amp;nbsp;&amp;nbsp; LOGOUT command) or by unilateral action on the part of either &amp;nbsp;&amp;nbsp; the client or server.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; If the client requests the logout state, the server MUST send an &amp;nbsp;&amp;nbsp; untagged BYE response and a tagged OK response to the LOGOUT &amp;nbsp;&amp;nbsp; command before the server closes the connection; and the client &amp;nbsp;&amp;nbsp; MUST read the tagged OK response to the LOGOUT command before &amp;nbsp;&amp;nbsp; the client closes the connection.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp; A server MUST NOT unilaterally close the connection without &amp;nbsp;&amp;nbsp; sending an untagged BYE response that contains the reason for &amp;nbsp;&amp;nbsp; having done so.&amp;nbsp; A client SHOULD NOT unilaterally close the &amp;nbsp;&amp;nbsp; connection, and instead SHOULD issue a LOGOUT command.&amp;nbsp; If the &amp;nbsp;&amp;nbsp; server detects that the client has unilaterally closed the &amp;nbsp;&amp;nbsp; connection, the server MAY omit the untagged BYE response and &amp;nbsp;&amp;nbsp; simply close its connection.&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;Crispin&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Standards Track&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; [Page 14] RFC 3501&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; IMAPv4&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; March 2003&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt; &lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; +----------------------+ &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; |connection established| &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; +----------------------+ &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; || &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; \/ &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; +--------------------------------------+ &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; |&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; server greeting&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; | &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; +--------------------------------------+ &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; || (1)&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; || (2)&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; || (3) &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; \/&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; ||&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; || &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; +-----------------+&amp;nbsp;&amp;nbsp;&amp;nbsp; ||&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; || &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; |Not Authenticated|&amp;nbsp;&amp;nbsp;&amp;nbsp; ||&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; || &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; +-----------------+&amp;nbsp;&amp;nbsp;&amp;nbsp; ||&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; || &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; || (7)&amp;nbsp;&amp;nbsp; || (4)&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; ||&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; || &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; ||&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; \/&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; \/&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; || &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; ||&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; +----------------+&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; || &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; ||&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; | Authenticated&amp;nbsp; |&amp;lt;=++&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; || &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; ||&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; +----------------+&amp;nbsp; ||&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; || &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; ||&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; || (7)&amp;nbsp;&amp;nbsp; || (5)&amp;nbsp;&amp;nbsp; || (6)&amp;nbsp;&amp;nbsp; || &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; ||&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; ||&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; \/&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; ||&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; || &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; ||&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; ||&amp;nbsp;&amp;nbsp;&amp;nbsp; +--------+&amp;nbsp; ||&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; || &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; ||&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; ||&amp;nbsp;&amp;nbsp;&amp;nbsp; |Selected|==++&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; || &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; ||&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; ||&amp;nbsp;&amp;nbsp;&amp;nbsp; +--------+&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; || &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; ||&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; ||&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; || (7)&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; || &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; \/&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; \/&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; \/&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; \/ &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; +--------------------------------------+ &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; |&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Logout&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; | &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; +--------------------------------------+ &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; || &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; \/ &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; +-------------------------------+ &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; |both sides close the connection| &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; +-------------------------------+&lt;/FONT&gt;&lt;/P&gt; &lt;P&gt;&lt;FONT face=&quot;courier new,courier&quot;&gt;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; (1) connection without pre-authentication (OK greeting) &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; (2) pre-authenticated connection (PREAUTH greeting) &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; (3) rejected connection (BYE greeting) &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; (4) successful LOGIN or AUTHENTICATE command &amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft