MBOX-Line: From slusarz at curecanti.org  Mon Jan 21 13:48:22 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(?)
Message-ID: <20130121144822.Horde.kbr5Y8IKwMlD1fH1Qun9hQ1@bigworm.curecanti.org>

A user recently reported this behavior on a Courier server:

A 1 UID FETCH 9 (BODY[HEADER])
* 1 FETCH (UID 9 BODY[HEADER] {1409}
[...headers...]
)
* 1 FETCH (FLAGS (\Seen))
A OK FETCH completed.

Is this response broken?  Seems to me it MUST be either:

* 1 FETCH (UID 9 BODY[HEADER] {1409}
[...headers...]
) FLAGS (\Seen))

--or (less optimal)--

* 1 FETCH (UID 9 BODY[HEADER] {1409}
[...headers...]
)
* 1 FETCH (UID 9 FLAGS (\Seen))

...because all responses occur within an active UID command.  RFC 3501  
[6.4.8]:

       However, server implementations MUST implicitly
       include the UID message data item as part of any FETCH response
       caused by a UID command, regardless of whether a UID was specified
       as a message data item to the FETCH.

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.

michael


