On Mon, 2008-05-26 at 00:18 +0200, Anders wrote:
Timo Sirainen tss@iki.fi writes:
I could yesterday also reproduce the broken INTERNALDATE pretty easily, but I can't anymore after that patch..
I can now reproduce one problem quite easily, with:
$ A=6 ; ./send_fetch_test.py user@domain.invalid pw file& sleep $A; ./send_fetch_test.py user@domain.invalid pw file
The A sleep value is the runtime of the script. If I have the mailbox open and in IDLE, 2 seems to work out. So the trick is to have the second instance expunge the mailbox just as the first instance is about to receive its message.
Oh, that's expected behavior then. If you're trying to FETCH a message that has already been expunged and Dovecot doesn't have the necessary information already in its cache file, there are only a few bad choices Dovecot can do:
a) lie about the message's contents by using "unknown" values (this is what you're seeing now)
b) Disconnect the client
c) Don't return any information and reply NO to the FETCH command. This can cause problems with some clients.
If you're using Dovecot's deliver and it already knows that INTERNALDATE and RFC822.SIZE are wanted to be cached (i.e. you didn't delete any dovecot* files between the send_fetch_test.py), deliver should have written those to the cache file and IMAP *usually* would be able to look up the values from there even after the message is expunged.