Subject: [lemonade] Another QRESYNC race condition

From: Timo Sirainen <[email-masked]>
Date: Sat, 03 May 2008 03:17:36 +0300

> 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.

Problem:

C1: a store 1 +flags \seen
S1: * 1 FETCH (FLAGS (\Seen) MODSEQ (1))
S1: a OK

C2: b expunge
S2: * VANISHED 1234
S2: b OK [HIGHESTMODSEQ 2]

C1: c store 1 -flags \seen
S1: * 1 FETCH (FLAGS () MODSEQ (3))
S1: c OK

If C1 disconnects here, the next resync won't show that UID 1234 was
expunged, because it uses 3 as the last seen HIGHESTMODSEQ.

Are there any solutions? The only real one that I can see is that a
client shouldn't update HIGHESTMODSEQ immediately after SEARCH, STORE,
FETCH, SORT and THREAD command replies, but should remember it until a
future "expunge-invoking" command finishes. After then the client can
update the HIGHESTMODSEQ with the previous value (or new one if there
had been more changes).

This also requires that the server MUST send pending EXPUNGE/VANISHED
replies on such expunge-invoking commands. Those commands would probably
be: NOOP, CHECK, UID <anything>, APPEND, IDLE, UNSELECT and obviously
CLOSE and EXPUNGE.

_______________________________________________
lemonade mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Timo Sirainen <[email-masked]>
Date: Sat, 3 May 2008 06:02:24 +0300

> be: NOOP, CHECK, UID <anything>, APPEND, IDLE, UNSELECT and obviously

(UID <anything> could be replaced with only UID STORE, but the rest of  
them would be required.)

Perhaps a cleaner alternative: Never update HIGHESTMODSEQ from FETCH  
MODSEQs, instead make the server return changed [HIGHESTMODSEQ n] on  
either the FETCH/STORE/etc. tagged command reply, or in some future  
tagged command reply, but only when all the pending changes up to that  
modseq have been sent to the client.