rfc4549.txt

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

Melnikov                     Informational                     [Page 12]

RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006


   Note: Client implementers should be aware that [MULTIAPPEND] performs
   append of multiple messages atomically.  This means, for example, if
   there is not enough space to save "n"-th message (or the message has
   invalid structure and is rejected by the server) after successful
   upload of "n-1" messages, the whole upload operation fails, and no
   message will be saved in the mailbox.  Although this behavior might
   be desirable in certain situations, it might not be what you want.
   Otherwise, the client should use the regular APPEND command (Section
   4.2.2.3), possibly utilizing the [LITERAL+] extension.  See also
   Section 5.1 for discussions about error recovery.

   Note: MULTIAPPEND can be used together with the UIDPLUS extension in
   a way similar to what was described in Section 4.2.1.  [MULTIAPPEND]
   extends the syntax of the APPENDUID response code to allow for
   multiple message UIDs in the second parameter.

   Example 2:

   This example demonstrates the use of MULTIAPPEND together with
   UIDPLUS (synchronization points where the client waits for
   confirmations from the server are marked with "<--->"):

   C: A003 APPEND Jan-2002 (\Seen $MDNSent) "31-May-2002 05:26:59 -0600"
       {310}
   <--->
   S: + Ready for literal data
   C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
   C: From: Fred Foobar <[e-mail]>
   C: Subject: afternoon meeting
   C: To: [e-mail]
   C: Message-Id: <[e-mail]>
   C: MIME-Version: 1.0
   C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
   C:
   C: Hello Joe, do you think we can meet at 3:30 tomorrow?
   C:  (\Seen) " 1-Jun-2002 22:43:04 -0800" {286}
   <--->
   S: + Ready for literal data
   C: Date: Mon, 7 Feb 1994 22:43:04 -0800 (PST)
   C: From: Joe Mooch <[e-mail]>
   C: Subject: Re: afternoon meeting
   C: To: [e-mail]
   C: Message-Id: <[e-mail]>
   C: MIME-Version: 1.0
   C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
   C:
   C: 3:30 is fine with me.
   C:



Melnikov                     Informational                     [Page 13]

RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006


   S: A003 OK [APPENDUID 1022843275 77712,77713] completed

   The upload takes 3 round-trips.

   Example 3:

   In this example, Example 2 was modified for the case when the server
   supports MULTIAPPEND, LITERAL+, and UIDPLUS.  The upload takes only 1
   round-trip.

   C: A003 APPEND Jan-2002 (\Seen $MDNSent) "31-May-2002 05:26:59 -0600"
       {310+}
   C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
   C: From: Fred Foobar <[e-mail]>
   C: Subject: afternoon meeting
   C: To: [e-mail]
   C: Message-Id: <[e-mail]>
   C: MIME-Version: 1.0
   C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
   C:
   C: Hello Joe, do you think we can meet at 3:30 tomorrow?
   C:  (\Seen) " 1-Jun-2002 22:43:04 -0800" {286+}
   C: Date: Mon, 7 Feb 1994 22:43:04 -0800 (PST)
   C: From: Joe Mooch <[e-mail]>
   C: Subject: Re: afternoon meeting
   C: To: [e-mail]
   C: Message-Id: <[e-mail]>
   C: MIME-Version: 1.0
   C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
   C:
   C: 3:30 is fine with me.
   C:
   S: A003 OK [APPENDUID 1022843275 77712,77713] completed

4.2.3.  Replaying Local Flag Changes

   The disconnected client uses the STORE command to synchronize local
   flag state with the server.  The disconnected client SHOULD use
   +FLAGS.SILENT or -FLAGS.SILENT in order to set or unset flags
   modified by the user while offline.  The FLAGS form MUST NOT be used,
   as there is a risk that this will overwrite flags on the server that
   have been changed by some other client.

   Example 4:

   For the message with UID 15, the disconnected client stores the
   following flags \Seen and $Highest.  The flags were modified on the
   server by some other client: \Seen, \Answered, and $Highest.  While



Melnikov                     Informational                     [Page 14]

RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006


   offline, the user requested that the $Highest flags be removed and
   that the \Deleted flag be added.  The flag synchronization sequence
   for the message should look like:

      C: A001 UID STORE 15 +FLAGS.SILENT (\Deleted)
      S: A001 STORE completed
      C: A002 UID STORE 15 -FLAGS.SILENT ($Highest)
      S: A002 STORE completed

   If the disconnected client is able to store an additional binary
   state information (or a piece of information that can take a value
   from a predefined set of values) in the local cache of an IMAP
   mailbox or in a local mailbox (e.g., message priority), and if the
   server supports storing of arbitrary keywords, the client MUST use
   keywords to store this state on the server.

   Example 5:

   Imagine a speculative mail client that can mark a message as one of
   work-related ($Work), personal ($Personal), or spam ($Spam).  In
   order to mark a message as personal, the client issues:

      C: A001 UID STORE 15 +FLAGS.SILENT ($Personal)
      S: A001 STORE completed
      C: A002 UID STORE 15 -FLAGS.SILENT ($Work $Spam)
      S: A002 STORE completed

   In order to mark the message as not work, not personal and not spam,
   the client issues:

      C: A003 UID STORE 15 -FLAGS.SILENT ($Personal $Work $Spam)
      S: A003 STORE completed

4.2.4.  Processing Mailbox Compression (EXPUNGE) Requests

   A naive disconnected client implementation that supports compressing
   a mailbox while offline may decide to issue an EXPUNGE command to the
   server in order to expunge messages marked \Deleted.  The problem
   with this command during synchronization is that it permanently
   erases all messages with the \Deleted flag set, i.e., even those
   messages that were marked as \Deleted on the server while the user
   was offline.  Doing this might result in an unpleasant surprise for
   the user.

   Fortunately the [UIDPLUS] extension can help in this case as well.
   The extension introduces UID EXPUNGE command, that, unlike EXPUNGE,
   takes a UID set parameter, that lists UIDs of all messages that can
   be expunged.  When processing this command the server erases only



Melnikov                     Informational                     [Page 15]

RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006


   messages with \Deleted flag listed in the UID list.  Thus, messages
   not listed in the UID set will not be expunged even if they have the
   \Deleted flag set.

   Example 6:

   While the user was offline, 3 messages with UIDs 7, 27, and 65 were
   marked \Deleted when the user requested to compress the open mailbox.
   Another client marked a message \Deleted on the server (UID 34).
   During synchronization, the disconnected client issues:

      C: A001 UID EXPUNGE 7,27,65
      S: * ... EXPUNGE
      S: * ... EXPUNGE
      S: * ... EXPUNGE
      S: A001 UID EXPUNGE completed

   If another client issues UID SEARCH DELETED command (to find all
   messages with the \Deleted flag) before and after the UID EXPUNGE, it
   will get:

   Before:

      C: B001 UID SEARCH DELETED
      S: * SEARCH 65 34 27 7
      S: B001 UID SEARCH completed

   After:

      C: B002 UID SEARCH DELETED
      S: * SEARCH 34
      S: B002 UID SEARCH completed

   In the absence of the [UIDPLUS] extension, the following sequence of
   commands can be used as an approximation.  Note: It's possible for
   another client to mark additional messages as deleted while this
   sequence is being performed.  In this case, these additional messages
   will be expunged as well.

   1) Find all messages marked \Deleted on the server.

      C: A001 UID SEARCH DELETED
      S: * SEARCH 65 34 27 7
      S: A001 UID SEARCH completed

   2) Find all messages that must not be erased (for the previous
      example the list will consist of the message with UID 34).




Melnikov                     Informational                     [Page 16]

RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006


   3) Temporarily remove \Deleted flag on all messages found in step 2.

      C: A002 UID STORE 34 -FLAGS.SILENT (\Deleted)
      S: A002 UID STORE completed

   4) Expunge the mailbox.

      C: A003 EXPUNGE
      S: * 20 EXPUNGE
      S: * 7 EXPUNGE
      S: * 1 EXPUNGE
      S: A003 EXPUNGE completed

      Here, the message with UID 7 has message number 1, with UID 27 has
      message number 7, and with UID 65 has message number 20.

   5) Restore \Deleted flag on all messages found when performing step
      2.

      C: A004 UID STORE 34 +FLAGS.SILENT (\Deleted)
      S: A004 UID STORE completed

4.2.5.  Closing a Mailbox

   When the disconnected client has to close a mailbox, it should not
   use the CLOSE command, because CLOSE does a silent EXPUNGE.  (Section
   4.2.4 explains why EXPUNGE should not be used by a disconnected
   client.)  It is safe to use CLOSE only if the mailbox was opened with
   EXAMINE.

   If the mailbox was opened with SELECT, the client can use one of the
   following commands to implicitly close the mailbox and prevent the
   silent expunge:

   1) UNSELECT - This is a command described in [UNSELECT] that works as
      CLOSE, but doesn't cause the silent EXPUNGE.  This command is
      supported by the server if it reports UNSELECT in its CAPABILITY
      list.

   2) SELECT <another_mailbox> - SELECT causes implicit CLOSE without
      EXPUNGE.

   3) If the client intends to issue LOGOUT after closing the mailbox,
      it may just issue LOGOUT, because LOGOUT causes implicit CLOSE
      without EXPUNGE as well.

   4) SELECT <non_existing_mailbox> - If the client knows a mailbox that
      doesn't exist or can't be selected, it MAY SELECT it.



Melnikov                     Informational                     [Page 17]

RFC 4549        Synch Ops for Disconnected IMAP4 Clients       June 2006


   If the client opened the mailbox with SELECT and just wants to avoid
   implicit EXPUNGE without closing the mailbox, it may also use the
   following:

   5) EXAMINE <mailbox> - Reselect the same mailbox in read-only mode.

4.3.  Details of "Normal" Synchronization of a Single Mailbox

   The most common form of synchronization is where the human trusts the
   integrity of the client's copy of the state of a particular mailbox
   and simply wants to bring the client's cache up to date so that it
   accurately reflects the mailbox's current state on the server.

4.3.1.  Discovering New Messages and Changes to Old Messages

   Let <lastseenuid> represent the highest UID that the client knows
   about in this mailbox.  Since UIDs are allocated in strictly
   ascending order, this is simply the UID of the last message in the
   mailbox that the client knows about.  Let <lastseenuid+1> represent
   <lastseenuid>'s UID plus one.  Let <descriptors> represent a list
   consisting of all the FETCH data item items that the implementation
   considers part of the descriptor; at a minimum this is just the FLAGS
   data item, but it usually also includes BODYSTRUCTURE and
   RFC822.SIZE.  At this step, <descriptors> SHOULD NOT include RFC822.

   With no further information, the client can issue the following two
   commands:

      tag1 UID FETCH <lastseenuid+1>:* <descriptors>
      tag2 UID FETCH 1:<lastseenuid> FLAGS

   The first command will request some information about "new" messages
   (i.e., messages received by the server since the last
   synchronization).  It will also allow the client to build a message
   number to UID map (only for new messages).  The second command allows
   the client to

      1) update cached flags for old messages;

      2) find out which old messages got expunged; and

      3) build a mapping between message numbers and UIDs (for old
         messages).

   The order here is significant.  We want the server to start returning
   the list of new message descriptors as fast as it can, so that the
   client can start issuing more FETCH commands, so we start out by