rfc5162.txt

广泛使用的邮件服务器！同时

   Example:    C: . UID EXPUNGE 3000:3002
               S: * 3 EXPUNGE
               S: * 3 EXPUNGE
               S: * 3 EXPUNGE
               S: . OK [HIGHESTMODSEQ 20010715194045319] Ok

   Note: In this example, at least messages with message numbers 3, 4,
   and 5 (UIDs 3000 to 3002) had the \Deleted flag set.  The first "* 3
   EXPUNGE" reports message # 3 as expunged.  The second "* 3 EXPUNGE"
   reports message # 4 as expunged (the message number got decremented
   due to the previous EXPUNGE response).  See the description of the
   EXPUNGE response in [RFC3501] for further explanation.

3.6.  VANISHED Response

   Contents:  an optional EARLIER tag

   list of UIDs

   The VANISHED response reports that the specified UIDs have been
   permanently removed from the mailbox.  This response is similar to
   the EXPUNGE response [RFC3501]; however, it can return information
   about multiple messages, and it returns UIDs instead of message




Melnikov, et al.            Standards Track                    [Page 12]

RFC 5162               IMAP Quick Mailbox Resync              March 2008


   numbers.  The first benefit saves bandwidth, while the second is more
   convenient for clients that only use UIDs to access the IMAP server.

   The VANISHED response has the same restrictions on when it can be
   sent as does the EXPUNGE response (see below).

   The VANISHED response has two forms.  The first form contains the
   EARLIER tag, which signifies that the response was caused by a UID
   FETCH (VANISHED) or a SELECT/EXAMINE (QRESYNC) command.  This
   response is sent if the UID set parameter to the UID FETCH (VANISHED)
   command includes UIDs of messages that are no longer in the mailbox.
   When the client sees a VANISHED EARLIER response, it MUST NOT
   decrement message sequence numbers for each successive message in the
   mailbox.

   The second form doesn't contain the EARLIER tag and is described
   below.  Once a client has issued "ENABLE QRESYNC", the server SHOULD
   use the VANISHED response without the EARLIER tag instead of the
   EXPUNGE response.  The server SHOULD continue using VANISHED in lieu
   of EXPUNGE for the duration of the connection.  In particular, this
   affects the EXPUNGE [RFC3501] and UID EXPUNGE [UIDPLUS] commands, as
   well as messages expunged in other connections.  Such a VANISHED
   response MUST NOT contain the EARLIER tag.

   A VANISHED response sent because of an EXPUNGE or UID EXPUNGE command
   or because messages were expunged in other connections (i.e., the
   VANISHED response without the EARLIER tag) also decrements the number
   of messages in the mailbox; it is not necessary for the server to
   send an EXISTS response with the new value.  It also decrements
   message sequence numbers for each successive message in the mailbox
   (see the example at the end of this section).  Note that a VANISHED
   response caused by EXPUNGE, UID EXPUNGE, or messages expunged in
   other connections SHOULD only contain UIDs for messages expunged
   since the last VANISHED/EXPUNGE response sent for the currently
   opened mailbox or since the mailbox was opened.  That is, servers
   SHOULD NOT send UIDs for previously expunged messages, unless
   explicitly requested to do so by the UID FETCH (VANISHED) command.

   Note that client implementors must take care to properly decrement
   the number of messages in the mailbox even if a server violates this
   last SHOULD or repeats the same UID multiple times in the returned
   UID set.  In general, this means that a client using this extension
   should either avoid using message numbers entirely, or have a
   complete mapping of UIDs to message sequence numbers for the selected
   mailbox.






Melnikov, et al.            Standards Track                    [Page 13]

RFC 5162               IMAP Quick Mailbox Resync              March 2008


   Because clients handle the two different forms of the VANISHED
   response differently, servers MUST NOT report UIDs resulting from a
   UID FETCH (VANISHED) or a SELECT/EXAMINE (QRESYNC) in the same
   VANISHED response as UIDs of messages expunged now (i.e., messages
   expunged in other connections).  Instead, the server MUST send
   separate VANISHED responses: one with the EARLIER tag and one
   without.

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

   Note: UID FETCH, UID STORE, and UID SEARCH are different commands
   from FETCH, STORE, and SEARCH.  A VANISHED response MAY be sent
   during a UID command.  However, the VANISHED response MUST NOT be
   sent during a UID SEARCH command that contains message numbers in the
   search criteria.

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

   Example: Let's assume that there is the following mapping between
   message numbers and UIDs in the currently selected mailbox (here "X"
   marks messages with the \Deleted flag set, and "x" represents UIDs
   which are not relevant for the example):

   Message numbers:   1    2    3    4    5  6   7  8  9 10  11
   UIDs:              x  504  505  507  508  x 510  x  x  x 625
   \Deleted messages:           X    X           X            X

   In the presence of the extension defined in this document:

   C: A202 EXPUNGE
   S: * VANISHED 505,507,510,625
   S: A202 OK EXPUNGE completed

   Without the QRESYNC extension, the same example might look like:

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




Melnikov, et al.            Standards Track                    [Page 14]

RFC 5162               IMAP Quick Mailbox Resync              March 2008


   (Continuing previous example) If subsequently messages with UIDs 504
   and 508 got marked as \Deleted:

   C: A210 EXPUNGE
   S: * VANISHED 504,508
   S: A210 OK EXPUNGE completed

   i.e., the last VANISHED response only contains UIDs of messages
   expunged since the previous VANISHED response.

3.7.  CLOSED Response Code

   The CLOSED response code has no parameters.  A server implementing
   the extension defined in this document MUST return the CLOSED
   response code when the currently selected mailbox is closed
   implicitly using the SELECT/EXAMINE command on another mailbox.  The
   CLOSED response code serves as a boundary between responses for the
   previously opened mailbox (which was closed) and the newly selected
   mailbox: all responses before the CLOSED response code relate to the
   mailbox that was closed, and all subsequent responses relate to the
   newly opened mailbox.

   There is no need to return the CLOSED response code on completion of
   the CLOSE or the UNSELECT [UNSELECT] command (or similar) whose
   purpose is to close the currently selected mailbox without opening a
   new one.

4.  Server Implementation Considerations

   This section describes a minimalist implementation, a moderate
   implementation, and an example of a full implementation.

4.1.  Server Implementations That Don't Store Extra State

   Strictly speaking, a server implementation that doesn't remember mod-
   sequences associated with expunged messages can be considered
   compliant with this specification.  Such implementations return all
   expunged messages specified in the UID set of the UID FETCH
   (VANISHED) command every time, without paying attention to the
   specified CHANGEDSINCE mod-sequence.  Such implementations are
   discouraged, as they can end up returning VANISHED responses that are
   bigger than the result of a UID SEARCH command for the same UID set.

   Clients that use the message sequence match data can reduce the scope
   of this VANISHED response substantially in the typical case where
   expunges have not happened, or happen only toward the end of the
   mailbox.




Melnikov, et al.            Standards Track                    [Page 15]

RFC 5162               IMAP Quick Mailbox Resync              March 2008


4.2.  Server Implementations Storing Minimal State

   A server that stores the HIGHESTMODSEQ value at the time of the last
   EXPUNGE can omit the VANISHED response when a client provides a
   MODSEQ value that is equal to, or higher than, the current value of
   this datum, that is, when there have been no EXPUNGEs.

   A client providing message sequence match data can reduce the scope
   as above.  In the case where there have been no expunges, the server
   can ignore this data.

4.3.  Additional State Required on the Server

   When compared to the [CONDSTORE] extension, this extension requires
   servers to store additional state associated with expunged messages.
   Note that implementations are not required to store this state in
   persistent storage; however, use of persistent storage is advisable.

   One possible way to correctly implement the extension described in
   this document is to store a queue of <UID set, mod-sequence> pairs.
   <UID set> can be represented as a sequence of <min UID, max UID>
   pairs.

   When messages are expunged, one or more entries are added to the
   queue tail.

   When the server receives a request to return messages expunged since
   a given mod-sequence, it will search the queue from the tail (i.e.,
   going from the highest expunged mod-sequence to the lowest) until it
   sees the first record with a mod-sequence less than or equal to the
   given mod-sequence or it reaches the head of the queue.

   Note that indefinitely storing information about expunged messages
   can cause storage and related problems for an implementation.  In the
   worst case, this could result in almost 64Gb of storage for each IMAP
   mailbox.  For example, consider an implementation that stores <min
   UID, max UID, mod-sequence> triples for each range of messages
   expunged at the same time.  Each triple requires 16 octets: 4 octets
   for each of the two UIDs, and 8 octets for the mod-sequence.  Assume
   that there is a mailbox containing a single message with a UID of
   2**32-1 (the maximum possible UID value), where messages had
   previously existed with UIDs starting at 1, and have been expunged
   one at a time.  For this mailbox alone, storage is required for the
   triples <1, 1, modseq1>, <2, 2, modseq2>, ..., <2**32-2, 2**32-2,
   modseq4294967294>.






Melnikov, et al.            Standards Track                    [Page 16]

RFC 5162               IMAP Quick Mailbox Resync              March 2008


   Hence, implementations are encouraged to adopt strategies to protect
   against such storage problems, such as limiting the size of the queue
   used to store mod-sequences for expunged messages and "expiring"
   older records when this limit is reached.  When the selected
   implementation-specific queue limit is reached, the oldest record(s)
   are deleted from the queue (note that such records are located at the
   queue head).  For all such "expired" records, the server needs to
   store a single mod-sequence, which is the highest mod-sequence for
   all "expired" expunged messages.

   Note that if the client provides the message sequence match data,
   this can heavily reduce the data cost of sending a complete set of
   missing UIDs; thus, reducing the problems for clients if a server is
   unable to persist much of this queue.  If the queue contains data
   back to the requested mod-sequence, this data can be ignored.

   Also, note that if the UIDVALIDITY of the mailbox changes or if the
   mailbox is deleted, then any state associated with expunged messages
   doesn't need to be preserved and SHOULD be deleted.

5.  Updated Synchronization Sequence

   This section updates the description of optimized synchronization in
   Section 6.1 of the [IMAP-DISC].

   An advanced disconnected mail client should use the QRESYNC and
   [CONDSTORE] extensions when they are supported by the server.  The
   client uses the value from the HIGHESTMODSEQ OK response code
   received on mailbox opening to determine if it needs to
   resynchronize.  Once the synchronization is complete, it MUST cache
   the received value (unless the mailbox UIDVALIDITY value has changed;
   see below).  The client MUST update its copy of the HIGHESTMODSEQ
   value whenever the server sends a subsequent HIGHESTMODSEQ OK
   response code.

   After completing a full synchronization, the client MUST also take
   note of any unsolicited MODSEQ FETCH data items received from the
   server.  Whenever the client receives a tagged response to a command,
   it calculates the highest value among all MODSEQ FETCH data items
   received since the last tagged response.  If this value is bigger
   than the client's copy of the HIGHESTMODSEQ value, then the client
   MUST use this value as its new HIGHESTMODSEQ value.

   Note: It is not safe to update the client's copy of the HIGHESTMODSEQ
   value with a MODSEQ FETCH data item value as soon as it is received
   because servers are not required to send MODSEQ FETCH data items in
   increasing modseqence order.  This can lead to the client missing
   some changes in case of connectivity loss.



Melnikov, et al.            Standards Track                    [Page 17]

RFC 5162               IMAP Quick Mailbox Resync              March 2008


   When opening the mailbox for synchronization, the client uses the
   QRESYNC parameter to the SELECT/EXAMINE command.  The QRESYNC
   parameter is followed by the UIDVALIDITY and mailbox HIGHESTMODSEQ
   values, as known to the client.  It can be optionally followed by the
   set of UIDs, for example, if the client is only interested in partial
   synchronization of the mailbox.  The client may also transmit a list
   containing its knowledge of message numbers.

   If the SELECT/EXAMINE command is successful, the client compares
   UIDVALIDITY as described in step d)1) in Section 3 of the
   [IMAP-DISC].  If the cached UIDVALIDITY value matches the one