rfc4549.txt

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

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


   4) On step d-2-II, the client also finds out about changes to the
      flags of messages that the client already has in its local cache,
      and about messages in the local cache that no longer exist on the
      server (i.e., messages that have been expunged).

   5) "Interesting" messages are those messages that the synchronization
      program thinks the human wants to have cached locally, based on
      the configuration and the data retrieved in step b.

   6) A disconnected IMAP client is a special case of an IMAP client, so
      it MUST be able to handle any "unexpected" unsolicited responses,
      like EXISTS and EXPUNGE, at any time.  The disconnected client MAY
      ignore EXPUNGE response during "client-to-server" synchronization
      phase (step c).

   The rest of this discussion will focus primarily on the
   synchronization issues for a single mailbox.

4.  Mailbox Synchronization Steps and Strategies

4.1.  Checking UID Validity

   The "UID validity" of a mailbox is a number returned in an
   UIDVALIDITY response code in an OK untagged response at mailbox
   selection time.  The UID validity value changes between sessions when
   UIDs fail to persist between sessions.

   Whenever the client selects a mailbox, the client must compare the
   returned UID validity value with the value stored in the local cache.
   If the UID validity values differ, the UIDs in the client's cache are
   no longer valid.  The client MUST then empty the local cache of that
   mailbox and remove any pending "actions" that refer to UIDs in that
   mailbox.  The client MAY also issue a warning to the human.  The
   client MUST NOT cancel any scheduled uploads (i.e., APPENDs) for the
   mailbox.

   Note that UIDVALIDITY is not only returned on a mailbox selection.
   The COPYUID and APPENDUID response codes defined in the [UIDPLUS]
   extension (see also 4.2.2) and the UIDVALIDITY STATUS response data
   item also contain a UIDVALIDITY value for some other mailbox.  The
   client SHOULD behave as described in the previous paragraph (but it
   should act on the other mailbox's cache), no matter how it obtained
   the UIDVALIDITY value.








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


4.2.  Synchronizing Local Changes with the Server

4.2.1.  Uploading Messages to the Mailbox

   Two of the most common examples of operations resulting in message
   uploads are:

   1) Saving a draft message

   2) Copying a message between remote mailboxes on two different IMAP
      servers or a local mailbox and a remote mailbox.

   Message upload is performed with the APPEND command.  A message
   scheduled to be uploaded has no UID associated with it, as all UIDs
   are assigned by the server.  The APPEND command will effectively
   associate a UID with the uploaded message that can be stored in the
   local cache for future reference.  However, [IMAP4] doesn't describe
   a simple mechanism to discover the message UID by just performing the
   APPEND command.  In order to discover the UID, the client can do one
   of the following:

   1) Remove the uploaded message from cache.  Then, use the mechanism
      described in 4.3 to fetch the information about the uploaded
      message as if it had been uploaded by some other client.

   2) Try to fetch header information as described in 4.2.2 in order to
      find a message that corresponds to the uploaded message.  One
      strategy for doing this is described in 4.2.2.

   Case 1 describes a not particularly smart client.

      C: A003 APPEND Drafts (\Seen $MDNSent) {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:
      S: A003 OK APPEND Completed

   Fortunately, there is a simpler way to discover the message UID in
   the presence of the [UIDPLUS] extension:




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


      C: A003 APPEND Drafts (\Seen $MDNSent) {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:
      S: A003 OK [APPENDUID 1022843275 77712] APPEND completed

   The UID of the appended message is the second parameter of APPENDUID
   response code.

4.2.2.  Optimizing "move" and "copy" Operations

   Practical experience with IMAP and other mailbox access protocols
   that support multiple mailboxes suggests that moving a message from
   one mailbox to another is an extremely common operation.

4.2.2.1.  Moving a Message between Two Mailboxes on the Same Server

   In IMAP4, a "move" operation between two mailboxes on the same server
   is really a combination of a COPY operation and a STORE +FLAGS
   (\Deleted) operation.  This makes good protocol sense for IMAP, but
   it leaves a simple-minded disconnected client in the silly position
   of deleting and possibly expunging its cached copy of a message, then
   fetching an identical copy via the network.

   However, the presence of the UIDPLUS extension in the server can
   help:

      C: A001 UID COPY 567,414 "Interesting Messages"
      S: A001 OK [COPYUID 1022843275 414,567 5:6] Completed

   This tells the client that the message with UID 414 in the current
   mailbox was successfully copied to the mailbox "Interesting Messages"
   and was given the UID 5, and that the message with UID 567 was given
   the UID 6.

   In the absence of UIDPLUS extension support in the server, the
   following trick can be used.  By including the Message-ID: header and
   the INTERNALDATE data item as part of the descriptor, the client can
   check the descriptor of a "new" message against messages that are
   already in its cache and avoid fetching the extra copy.  Of course,



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


   it's possible that the cost of checking to see if the message is
   already in the local cache may exceed the cost of just fetching it,
   so this technique should not be used blindly.  If the MUA implements
   a "move" command, it makes special provisions to use this technique
   when it knows that a copy/delete sequence is the result of a "move"
   command.

   Note that servers are not required (although they are strongly
   encouraged with "SHOULD language") to preserve INTERNALDATE when
   copying messages.

   Also note that since it's theoretically possible for this algorithm
   to find the wrong message (given sufficiently malignant Message-ID
   headers), implementers should provide a way to disable this
   optimization, both permanently and on a message-by-message basis.

   Example 1: Copying a message in the absence of UIDPLUS extension.

   At some point in time the client has fetched the source message and
   some information was cached:

      C: C021 UID FETCH <uids> (BODY.PEEK[] INTERNALDATE FLAGS)
      ...
      S: * 27 FETCH (UID 123 INTERNALDATE "31-May-2002 05:26:59 -0600"
          FLAGS (\Draft $MDNSent) BODY[] {1036}
      S: ...
      S: Message-Id: <20040903110856.22a127cd@chardonnay>
      S: ...
      S: ...message body...
      S: )
      ...
      S: C021 OK fetch completed

   Later on, the client decides to copy the message:

      C: C035 UID COPY 123 "Interesting Messages"
      S: C035 OK Completed

   As the server hasn't provided the COPYUID response code, the client
   tries the optimization described above:

      C: C036 SELECT "Interesting Messages"
      ...
      C: C037 UID SEARCH ON 31-May-2002 HEADER
          "Message-Id" "20040903110856.22a127cd@chardonnay"
      S: SEARCH 12368
      S: C037 OK completed




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


   Note that if the server has returned multiple UIDs in the SEARCH
   response, the client MUST NOT use any of the returned UID.

4.2.2.2.  Moving a Message from a Remote Mailbox to a Local

   Moving a message from a remote mailbox to a local is done with FETCH
   (that includes FLAGS and INTERNALDATE) followed by UID STORE <uid>
   +FLAGS.SILENT (\Deleted):

      C: A003 UID FETCH 123 (BODY.PEEK[] INTERNALDATE FLAGS)
      S: * 27 FETCH (UID 123 INTERNALDATE "31-May-2002 05:26:59 -0600"
          FLAGS (\Seen $MDNSent) BODY[]
      S: ...message body...
      S: )
      S: A003 OK UID FETCH completed
      C: A004 UID STORE <uid> +FLAGS.SILENT (\Deleted)
      S: A004 STORE completed

   Note that there is no reason to fetch the message during
   synchronization if it's already in the client's cache.  Also, the
   client SHOULD preserve delivery date in the local cache.

4.2.2.3.  Moving a Message from a Local Mailbox to a Remote

   Moving a message from a local mailbox to a remote is done with
   APPEND:

   C: A003 APPEND Drafts (\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:
   S: A003 OK [APPENDUID 1022843275 77712] completed

   The client SHOULD specify the delivery date from the local cache in
   the APPEND.

   If the [LITERAL+] extension is available, the client can save a
   round-trip*:




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


   C: A003 APPEND Drafts (\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:
   S: A003 OK [APPENDUID 1022843275 77712] completed

   * Note that there is a risk that the server will reject the message
     due to its size.  If this happens, the client will waste bandwidth
     transferring the whole message.  If the client wouldn't have used
     the LITERAL+, this could have been avoided:

   C: A003 APPEND Drafts (\Seen $MDNSent) "31-May-2004 05:26:59 -0600"
       {16777215}
   S: A003 NO Sorry, message is too big

4.2.2.4.  Moving a Message between Two Mailboxes on Different Servers

   Moving a message between two mailbox on two different servers is a
   combination of the operations described in 4.2.2.2 followed by the
   operations described in 4.2.2.3.

4.2.2.5.  Uploading Multiple Messages to a Remote Mailbox with
          MULTIAPPEND

   When there is a need to upload multiple messages to a remote mailbox
   (e.g., as per 4.2.2.3), the presence of certain IMAP extensions may
   significantly improve performance.  One of them is [MULTIAPPEND].

   For some mail stores, opening a mailbox for appending might be
   expensive.  [MULTIAPPEND] tells the server to open the mailbox once
   (instead of opening and closing it "n" times per "n" messages to be
   uploaded) and to keep it open while a group of messages is being
   uploaded to the server.

   Also, if the server supports both [MULTIAPPEND] and [LITERAL+]
   extensions, the entire upload is accomplished in a single
   command/response round-trip.