[Dovecot] Issues with VANISHED CHANGEDSINCE

[Michael M Slusarz]

Quoting Timo Sirainen <tss at iki.fi>:

> On 8.11.2012, at 0.08, Michael M Slusarz wrote:
>
>> I'm not sure changing the defaults is a good idea.  But if someone  
>> does want to use a particular dovecot server as the backend for  
>> activesync clients, for example, it would probably make sense to  
>> allow these values to be tweaked via the config files.  (I can see  
>> an organization having a "normal" IMAP server and a "activesync"  
>> IMAP server that differ in these details, and also in things like  
>> IDLE timeouts).
>
> Well .. I hate adding more settings. :) There are way too many  
> already. Ideally Dovecot would automatically do the right thing  
> anyway. Just like it already caches only those things that are  
> needed. It could also increase these values when QRESYNC is used, or  
> even better to actually have the separate expunge log that I  
> mentioned.

Thinking about this more, this can really all be handled by proper MUA  
design.  In short, it is never a good idea to send a '1:*' UID range  
to a VANISHED CHANGEDSINCE FETCH.

It remains a reasonable MUA design decision to not send the actual  
cached UID list to the FETCH command: if this cached UID list is  
thousands of messages long, obtaining this list, (optionally) sequence  
set compressing, and sending via the command may take more  
time/resources than it saves.  But a MUA should, at a minimum, keep  
track of the minimum UID it is aware of in order to limit the possible  
response.  This is a trivial amount of extra overhead and would  
prevent a large number of spurious VANISHED UIDs to need to be  
traversed.

michael