Re: [Imap-protocol] Re: Courier bug(?)

Quoting Jan Kundrát <[email protected]>:

> As far as I understand all of the RFCs, there is unfortunately  
> nothing but the 5162's errata which would guarantee that unsolicited  
> FETCH responses will have UIDs in them. Based on that observation, I  
> claim that a client which wants to keep track of updates to  
> messages' flags will have to keep a full mapping of the seq->UID for  
> the relevant message ranges at all times. Remember, servers are free  
> to send the data at any time, not just when fetching body parts.

I agree with the former part of your statement.  But I think the  
latter part of your statement is overstating the issue.

While there is nothing in the specs that guarantees that FETCH  
responses will have UIDs, the actual reality, at least as it stands  
right now, is that any decent IMAP server *DOES* return this UID  
information.  E.g. both Cyrus and Dovecot are guaranteed to return  
UIDs with unsolicited FETCH responses if CONDSTORE/QRESYNC is active.   
Hopefully the Gmail folks are doing the same thing with their  
CONDSTORE/QRESYNC implementation.

IMHO, a more sensible approach for a disconnected client, rather than  
trying to keep a sequence->UID map (ugh), is to assume that these  
unsolicited FETCH responses *will* always have UID information  
associated with it, which in current practice will happen almost 100%  
of the time. A client can then have code to check for the following  
occurrence during a command:

1. At least 1 FLAGS item was returned.
2. The item in #1 cannot be correlated with a UID with the other FETCH  
data returned during the current command.
3. The highest MODSEQ value increased.

Only if these 3 items occur does a client need some other way of  
linking the flag changes with an UID.  Since this event should occur  
only extremely rarely, if at all, one appropriate way of correctly  
syncing the local cache would be to:

1. Ignore the returned FETCH information for local caching purposes.
2. Immediately reopen the mailbox.  (The client's existing  
CONDSTORE/QRESYNC will ensure that the mailbox is correctly sync'd).

michael

_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol