From: David Carter (no email)
Date: Wed Feb 14 2007 - 10:26:15 EST
I believe that I have found a problem with the flushseenstate code in 2.3.
RFC 3501, section 7.4.1 states:
An EXPUNGE response MUST NOT be sent when no command is in
progress, nor while responding to a FETCH, STORE, or SEARCH
command. This rule is necessary to prevent a loss of synchronization
of message sequence numbers between client and server.
Here are two IMAP sessions, labelled A and B looking at a single mailbox:
EXPUNGE response to FETCH command:
A: . expunge
A: * 30 EXPUNGE
A: * 36 EXISTS
A: * 0 RECENT
A: . OK Completed
B: . fetch 32 fast
B: * 30 EXPUNGE <-- Not allowed.
B: * 36 EXISTS
B: * 0 RECENT
B: * 32 FETCH (FLAGS () INTERNALDATE
" 6-Jul-2004 17:17:05 +0100" RFC822.SIZE 2297)
B: . OK Completed (0.000 sec)
EXPUNGE response to STORE command:
A: . expunge
A: * 30 EXPUNGE
A: * 35 EXISTS
A: * 0 RECENT
A: . OK Completed
B: . store 32 flags (fred) <-- STOREs data for new message 31
B: * 32 FETCH (FLAGS (fred))
B: * 30 EXPUNGE
B: * 35 EXISTS
B: * 0 RECENT
B: . OK Completed
B: . fetch 31:32 fast
B: * 31 FETCH (FLAGS (fred) INTERNALDATE
" 6-Jul-2004 17:17:05 +0100" RFC822.SIZE 2297)
B: * 32 FETCH (FLAGS () INTERNALDATE
" 8-Apr-2005 08:09:46 +0100" RFC822.SIZE 494)
B: . OK Completed (0.000 sec)
Here is a patch which uses a new function called index_check_existing() to
generate unsolicited responses without reopening cyrus.index. It is
effectively a half way house between the standard behaviour and the
existing flushseenstate, but seems good enough to keep Outlook happy.
-- David Carter Email: University Computing Service, Phone: (01223) 334502 New Museums Site, Pembroke Street, Fax: (01223) 334679 Cambridge UK. CB2 3QH.
|
|
|