[Imap-protocol] Courier bug(?)
Michael M Slusarz <[email protected]>
| Newsgroups | gmane.mail.imap.general |
|---|---|
| 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
_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol