A.L.E.C wrote:
1.[24-Jul-2008 15:09:05 +0200]: [Resource id #41] C: flg STORE 7 +FLAGS (\Deleted) 2.[24-Jul-2008 15:09:06 +0200]: [Resource id #46] S: * 6 FETCH (UID 14 RFC822.SIZE 573 FLAGS (\Seen) INTERNALDATE "22-Jul-2008 11:37:42 +0200") 3.[24-Jul-2008 15:09:06 +0200]: [Resource id #46] S: fh1 OK Fetch completed. 4.[24-Jul-2008 15:09:06 +0200]: [Resource id #46] C: F1247 FETCH 6 (BODYSTRUCTURE) 5.[24-Jul-2008 15:09:06 +0200]: [Resource id #41] S: * 7 FETCH (FLAGS (\Deleted \Seen)) 6.[24-Jul-2008 15:09:06 +0200]: [Resource id #41] S: flg OK Store completed. 7.[24-Jul-2008 15:09:06 +0200]: [Resource id #46] S: * 6 FETCH (BODYSTRUCTURE (("text" "html" ("charset" "iso-8859-2") NIL NIL "7bit" 226 8 NIL NIL NIL) "alternative" ("boundary" "b1_4547603c33fa601e4b546c824b8d50be") NIL NIL)) 8.[24-Jul-2008 15:09:06 +0200]: [Resource id #46] S: * 7 FETCH (FLAGS (\Deleted \Seen)) 9.[24-Jul-2008 15:09:06 +0200]: [Resource id #46] S: F1247 OK Fetch completed.
Problem is with line no.8 which is readed by both connections #41 and #46. In #46 wthis line is joined with line no.7 and then BODYSTRUCTURE reply becomes malformed and is not properly parsed by iil_C_FetchStructureString(). I'm not sure where's the problem in PHP or in dovecot.
The "* 7 FETCH (FLAGS (\Deleted \Seen))" line is what's called an untagged response in IMAP-speak. The server may send such responses at any time to inform the client of changes to the selected mailbox.
In this case #41 is expecting the response; it confirms that the server has set the \Deleted flag on message index 7 which is what that connection just asked for.
On the other hand; #46 just issued a command to read the bodystructure of message index 6 ("F1247 FETCH 6 (BODYSTRUCTURE)") and is only getting the untagged response concerning the deletion of message index 7 because it happened to be connected to the mailbox at the time the message was deleted. It seems that iil_C_FetchStructureString() blindly concatenates everything returned from the server until it receives the tagged response. This will cause trouble when the server sends untagged responses for unrelated events.
So to answer your question; this is a bug in RC, more specifically in iil_C_FetchStructureString() in program/lib/imap.inc. Dovecot is not doing anything wrong here.
The solution is to discard unrelated untagged responses in the do {} while loop on iil_C_FetchStructureString().
Bob
List info: http://lists.roundcube.net/dev/