MBOX-Line: From alexey.melnikov at isode.com  Mon Jun 11 12:08:01 2012
To: imap-protocol@u.washington.edu
From: Alexey Melnikov <alexey.melnikov@isode.com>
Date: Fri Jun  8 12:34:48 2018
Subject: [Imap-protocol] QRESYNC and new arrivals which get deleted
	immediately through VANISHED
In-Reply-To: <4FD4EB4B.7050000@flaska.net>
References: <4FD221F9.8090601@flaska.net> <4FD4EB4B.7050000@flaska.net>
Message-ID: <E96EC1B2-A6D2-4BF6-9004-8248F61015F5@isode.com>

Hi Jan,

On 10 Jun 2012, at 19:45, Jan Kundr?t <jkt@flaska.net> wrote:

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

It depends :)

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

In most cases you don't need to do anything. For example if you only cached a part of the mailbox (e.g. N most recent messages), and UIDs listed in VANISHED are below any UID you know about, then you don't really care about removed messages.

It might make a difference if you want to display the number of messages in the mailbox or use message numbers for some operations. If you cached the whole mailbox, then you know the whole msgno-to-UID map. If you only cached a part, then maybe doing something like "UID FETCH *" (or a similar SEARCH) would help.

> 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 hope no server does that (unless in different sessions, when QRESYNC is enabled in one and not another...).
> 
> I'm looking forward to answers about this matter.

Best Regards,
Alexey


