MBOX-Line: From jkt at flaska.net  Tue Jul 17 10:11:38 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: <50059CCA.6030404@flaska.net>

On 06/08/12 18:02, Jan Kundr?t wrote:
> Finally, my last question is why does QRESYNC require me to issue an
> ENABLE QRESYNC at all? I feel like the SELECT ... QRESYNC should be
> enough to tell the server that I'm really expecting the VANISHED
> responses.

I think I have found an answer to this -- if the client doesn't have any 
cached state for a particular mailbox, it cannot really SELECT QRESYNC that.

If it tried to use a HIGHESTMODSEQ = 1, it would risk an enormous amount 
of data being transferred in VANISHED EARLIER as the server would have 
to inform about each and every expunge which has happened in the mailbox 
since its creation. This is due to the known-uids ABNF item format which 
doesn't provide any way of sending "nope, I don't know about any UIDs" 
-- the list can either be missing, or contain at least one item.

If I understand everything correctly, ENABLE QRESYNC is therefore still 
required as long as one wants to receive VANISHED instead of EXPUNGE. My 
apologies for assuming that it's useless :).

Also is probably means that a QRESYNC-capable clients have to use SELECT 
... CONDSTORE when they open a mailbox for the first time.

I'd appreciate if someone could verify these assumptions -- they look 
plausible to me, but I didn't see any flaw in my previous reasoning, 
either :).

With kind regards
Jan

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


