azurIt writes:
Hi,i would like to ask about this ticket in Horde/IMP software: http://bugs.horde.org/ticket/11946Newest version of Horde/IMP stopped behave correctly when opening unseen messages. The result from investigation was that Courier IMAP version 4.8.0 is breaking RFC 3501 section 6.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. Here is the client-server communication where the violation can be seen: C: 7 UID FETCH 9 (BODY[HEADER]) S: * 1 FETCH (UID 9 BODY[HEADER] {1409} S: <<<FULL HEADERS>>> S: ) S: * 1 FETCH (FLAGS (\Seen)) S: 7 OK FETCH completed.Problematic line should be this, which is supposed to be merged with previous line:S: * 1 FETCH (FLAGS (\Seen)) Is this really a bug? If so, is it going to be fixed? Thank you!
No, it is not a bug. In your example, the first line is the server's response to the client's request, and it includes the message's UID data item, as required by RFC 3501.
The second line is not a response to the client's request. It is an unsolicited response, send unilaterally by the server, as specified in section 2.2.2 of RFC 3501:
Server data MAY be sent as a result of a client command, or MAY be sent unilaterally by the server. There is no syntactic difference between server data that resulted from a specific command and server data that were sent unilaterally.As stated here "there is no syntactic difference" that identifies the server's explicit response to a command, and a unilateral message. Section 2.2.2 of RFC 3501 makes it quite explicit that clients must be prepared to accept any server response, at any time.
A client MUST be prepared to accept any server response at all times. This includes server data that was not requested. Server data SHOULD be recorded, so that the client can reference its recorded copy rather than sending a command to the server to request the data. In the case of certain server data, the data MUST be recorded.A client cannot assume that the next message from the server it receives is always a response to a request it just sent. The client must wait until it receives the response that it's looking for, and it always must be able to process any other response from the server. In this case, section 7 of RFC 3501 even gives a description of the specific unsolicited/untagged response, in your example:
Server
implementations that offer multiple simultaneous access to the same
mailbox SHOULD also send appropriate unilateral untagged FETCH and
EXPUNGE responses if another agent changes the state of any message
flags or expunges any messages.
Courier-IMAP is doing exactly what RFC 3501 describes here: sending an
untagged FETCH response after noticing that the message's state has changed.
In this case, after processing the client's command and sending its FETCH
response, with the UID data item, the server noticed that the message's
state has changed, and, as per section 7 of RFC 3501, it sent a message to
the client accordingly.
There is no requirement in RFC 3501 to merge unsolicited/untagged messages with other messages in the same response. There would be nothing wrong with doing that, of course, but there is no requirement for the server to do so. As RFC 3501 explicitly states, the server may send unsolicited/untagged messages at any time, which implies that there are no requirements for merging them with any other messages, of any kind.
It just so happens that Courier-IMAP always checks the mailbox state after processing the client's command, and always sends unsolicited/untagged/unilateral server data after all other messages, but it could do it in the other order too, and, in the example you showed above, the second message would get sent first, followed by the actual response to the client's request, with the UID item. That would still be a valid IMAP server response, and compliant IMAP clients must be able to handle them.
A compliant IMAP client implementation must be prepared to handle an unsolicited/untagged message in response to any command, at any time – or even when there is no command pending with the server.
pgprtqdtFzVBJ.pgp
Description: PGP signature
------------------------------------------------------------------------------ Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512
_______________________________________________ Courier-imap mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap
