MBOX-Line: From dave at cridland.net  Mon Jan 21 14:20:11 2013
To: imap-protocol@u.washington.edu
From: Dave Cridland <dave@cridland.net>
Date: Fri Jun  8 12:34:50 2018
Subject: [Imap-protocol] Courier bug(?)
In-Reply-To: <20130121144822.Horde.kbr5Y8IKwMlD1fH1Qun9hQ1@bigworm.curecanti.org>
References: <20130121144822.Horde.kbr5Y8IKwMlD1fH1Qun9hQ1@bigworm.curecanti.org>
Message-ID: <CAKHUCzwJ8xq7O8vGDHe0D9Jviac06o-QtePMhKYV7HzwzRPMPA@mail.gmail.com>

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.

Dave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20130121/f46cc356/attachment.html>
