MBOX-Line: From jkt at flaska.net  Sun Jun 10 11:45:31 2012
To: imap-protocol@u.washington.edu
From: =?UTF-8?B?SmFuIEt1bmRyw6F0?= <jkt@flaska.net>
Date: Fri Jun  8 12:34:48 2018
Subject: [Imap-protocol] QRESYNC and new arrivals which get deleted
	immediately through VANISHED
In-Reply-To: <4FD221F9.8090601@flaska.net>
References: <4FD221F9.8090601@flaska.net>
Message-ID: <4FD4EB4B.7050000@flaska.net>

I'm afraid I've found another possible issue with QRESYNC. The RFC5162
is pretty clear that servers SHOULD inform only about those UIDs which
are expunged "right now" through the VANISHED response. Unless I'm
terribly mistaken, it means that a client has to handle VANISHED
responses which refer to UIDs which were expunged a long time ago, and
servers *can* send them and still be called compliant.

I believe that this brings a few issues in the following scenario (where
mailbox contains one message with UID 5; UIDNEXT is 11, everything is
synced):

S: * 3 EXISTS
S: * VANISHED 12:20

The server is telling me that any UIDs between 12 and 20 are gone. The
problem is that I don't know whether any message has got this UID, ie.
whether the messages #2 and #3 (the first and second arrivals) fall into
that range. What shall a compliant IMAP client do at this point? Shall I
remove any messages upon receiving the VANISHED response? Shall I send a
UID SEARCH command to find out what new messages are really there?
That'd complicate my code quite a lot, unfortunately.

Even more entertaining would be an interaction where the server
occasionally sent a regular EXPUNGED instead of VANISHED (it's allowed
to do so per RFC 5162); that'd lead to an interesting mix of unknowns
about a mailbox' state...

I'm looking forward to answers about this matter.

With kind regards,
Jan

-- 
Trojita, a fast e-mail client -- http://trojita.flaska.net/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 270 bytes
Desc: OpenPGP digital signature
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20120610/3a8d4dd1/attachment.sig>
