Re: [Imap-protocol] QRESYNC and new arrivals which get deleted immediately through VANISHED

Hi Alexey,

On 06/11/12 21:08, Alexey Melnikov wrote:
>> 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.

I always establish full seq -> UID mapping as the very first thing when
I open a mailbox. The API through which I make the data about a mailbox
accessible to the rest of the application really wants to know how many
messages are there in a mailbox at any time; showing a total number of
messages in a mailbox is one of the use cases, but not the only one.
That's why I react to an EXISTS either by:

- doing nothing if the number is the same as my current idea of the
number of messages,
- throwing an error if the server tried to decrease the number of
messages against what I believe shall be there,
- asking for UIDs of the new arrivals immediately through UID FETCH
(FLAGS) immediately.

As soon as my idea of the "total number of messages" begins to differ
from the server's idea, I have trouble. That's an assumption on which
I've built my client; it allows me to deal with EXPUNGEs properly, etc.
My client will essentially show just a "loading..." placeholder until
the UID for a message arrives.

However, now QRESYNC seems to threaten this model because the server
reports increases in the amount of messages through EXISTS and their
removals through VANISHED. The issue is that there's a window where
VANISHED can refer to messages whose UID is unknown to the client and
that the protocol explicitly allows VANISHED to refer to UIDs which have
never existed in the mailbox -- at least according to my understanding.
I'd love to be proved wrong.

Unless I'm mistaken, the only completely safe way out of that is to
issue UID SEARCH ALL (or the ESEARCH equivalent) when a VANISHED
referencing "unknown" UIDs arrives at the time the mailbox has messages
whose UID I don't know yet.

Would you think that this will fly?

Would a proposal for adding "* ARRIVED 64,65,66" to replace EXISTS have
any real-world chance of getting accepted?

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

Agreed. It's just that now I've implemented the RFC in my client, I'm
afraid there are ways of getting it out-of-sync through "legal"
responses; I'd like to mitigate that.

With kind regards,
Jan

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

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/XVxYACgkQamXfqERyJRfz+gCeNFUkOWD5NQSmmfzw7eCiT1a5
mw8An3zEi5XA2dJSMpC+rlSF93XEev6F
=aT0I
-----END PGP SIGNATURE-----