MBOX-Line: From slusarz at curecanti.org  Wed Jan 23 20:20:37 2013
To: imap-protocol@u.washington.edu
From: Michael M Slusarz <slusarz@curecanti.org>
Date: Fri Jun  8 12:34:50 2018
Subject: [Imap-protocol] Courier bug(?)
In-Reply-To: <1358846428.12608.2.camel@hurina>
References: <20130121144822.Horde.kbr5Y8IKwMlD1fH1Qun9hQ1@bigworm.curecanti.org>
	<CAKHUCzwJ8xq7O8vGDHe0D9Jviac06o-QtePMhKYV7HzwzRPMPA@mail.gmail.com>
	<1358846428.12608.2.camel@hurina>
Message-ID: <20130123212037.Horde._IahQM6IYatHLw2AFgUPnw1@bigworm.curecanti.org>

Quoting Timo Sirainen <tss@iki.fi>:

> On Mon, 2013-01-21 at 22:20 +0000, Dave Cridland wrote:
>>
>> On 21 Jan 2013 21:50, "Michael M Slusarz" <slusarz@curecanti.org>
>> 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


