Re: [Imap-protocol] Courier bug(?)

Quoting Timo Sirainen <[email protected]>:

> On Mon, 2013-01-21 at 22:20 +0000, Dave Cridland wrote:
>>
>> On 21 Jan 2013 21:50, "Michael M Slusarz" <[email protected]>
>> wrote:
>> > OR... is the fact that this is a FLAGS response unattached to the
>> given UID query mean that this is OK?  In other words... since FLAGS
>> wasn't explicitly requested by the FETCH command, is this untagged
>> response legal as a unilateral flag change response sent by the
>> server, regardless of the fact that it appears during an active UID
>> command?  This doesn't seem correct, and it can be argued that the
>> BODY[HEADER] access itself "caused" the FLAGS FETCH response anyway.
>>
>> Right, this is indeed a unilaterally sent FETCH, and it wasn't really
>> caused by the other FETCH - it's just been batched until a command was
>> in progress. Or maybe it just happens to have been sent at the same
>> time.
>>
>> In practise, it's likely that the IMAP server explicitly checked flag
>> changes when it received the FETCH, but that's an implementation
>> detail.
>>
>> In any case, I don't think this is a bug.
>
> Assuming it was unilaterally sent FETCH and not a normal reply for
> setting the \Seen flag by UID FETCH BODY[], I agree. Especially when
> NOTIFY is enabled this won't even be possible to avoid.

Well... the \Seen flag response *is* caused by the UID FETCH BODY[].   
But it could be from some other previous operation as well.  From a  
client point of view there is no way of knowing what caused the flag,  
so this is not determinative as to whether the behavior is correct.

For the example I provided previously, I can safely ignore that  
non-UID FLAGS response because we aren't caching flag data for  
non-CONDSTORE servers.  But what about this:

a ENABLE QRESYNC
* ENABLED QRESYNC
a OK ENABLE completed.
b SELECT INBOX
[...]
* OK [HIGHESTMODSEQ 5] Highest
b OK [READ-WRITE] SELECT completed.
c UID FETCH 9 (BODY[HEADER])
* 1 FETCH (UID 9 BODY[HEADER] {1409}
[...headers...]
)
* 1 FETCH (MODSEQ (6) FLAGS (\Seen))
c OK FETCH completed.

Are we accepting that this is allowable?  Even if it is the  
BODY[HEADER] FETCH that is causing the \Seen flag to be set?  Looking  
at the QRESYNC docs - it appears that ONLY the FETCH untagged  
responses to the SELECT/EXAMINE are required to contain both UID &  
MODSEQ information.  All other FLAGS responses require MODSEQ but not  
UID.  This is a subtlety that I don't think I've thought about before.

michael

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