[Dovecot] Issues with VANISHED CHANGEDSINCE

[Michael J Rubinsky]

Quoting Timo Sirainen <tss at iki.fi>:

> On Mon, 2012-11-05 at 12:43 -0700, Michael M Slusarz wrote:
>> My argument is much simpler: it is blatantly breaking the RFC.  From
>> RFC 5162 [3.2]:
>>
>>     The VANISHED UID FETCH modifier instructs the server to report those
>>     messages from the UID set parameter that have been expunged and whose
>>     associated mod-sequence is larger than the specified mod-sequence.
>>     **That is, the client requests to be informed of messages from the
>>     specified set that were expunged since the specified
>> mod-sequence.** (emphasis added)
>>
>> If you are including UIDs in the FETCH return that have NOT been
>> expunged since the given mod-sequence, that directly contradicts this
>> language.  The clear intent of VANISHED UID FETCH is to provide the
>> list of messages that existed in the mailbox at mod-sequence and no
>> longer exist in the mailbox as of the current HIGHESTMODSEQ.
>
> That would require infinitely storing the modseq of when each message
> was expunged. Not very nice. Also the RFC talks a lot about this
> situation. The SELECT command has two optional parameters to optimize
> it.

The RFC *does* indicate that a server implementation could, strictly  
speaking, be considered in compliance without remembering modsequences  
for all expunged messages, but it does explicitly discourage such  
implementations. From RFC 5162 [4.1]:

    Strictly speaking, a server implementation that doesn't remember mod-
    sequences associated with expunged messages can be considered
    compliant with this specification.  Such implementations return all
    expunged messages specified in the UID set of the UID FETCH
    (VANISHED) command every time, without paying attention to the
    specified CHANGEDSINCE mod-sequence.  Such implementations are
    discouraged, as they can end up returning VANISHED responses that are
    bigger than the result of a UID SEARCH command for the same UID set.

    Clients that use the message sequence match data can reduce the scope
    of this VANISHED response substantially in the typical case where
    expunges have not happened, or happen only toward the end of the
    mailbox.

It also gives advice to avoid infinitely storing the modsequences such  
as "expiring" sequences associated with older expunged messages, but  
assigning a single modsequence value to all of the expired expunged  
messages.

-- 
mike

The Horde Project (www.horde.org)
mrubinsk at horde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6062 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://dovecot.org/pipermail/dovecot/attachments/20121105/78fdff80/attachment-0004.bin>