On 20.5.2005, at 18:43, Hauke Fath wrote:
Well - after updating Dovecot to 1.0-stable of 2005-05-17, I've seen the following disturbing behaviour:
With Eudora 6.2.1 on MacOS X (one window per mail), I was reading a mail, when a new mail came in. At the same moment, the window was closed. Suspecting evil things, I looked into the trash, and there was the mail I just had been reading - without me even touching the computer!
Well, first it would be useful to know if the trash is a real folder on server or if it's a virtual folder created by Eudora. Also, is Eudora using one or more IMAP connections? Are there any other IMAP clients accessing the server? (check how many imap processes there are)
Sounds pretty strange anyway. Hmm. If it's a problem internal to Dovecot, pretty much the only possibility for that is that it somehow confuses one message's flags with another, but I can't really think of how that could happen. I can think of two external reasons though:
The sent message had X-Status header with D-flag. This causes Dovecot to assume the message is deleted.
Eudora filtering rules or some other IMAP client (eg. spam checker) notices the new mail, mail matches its filtering and it sets it deleted.
You sure it's not either of these?
For Dovecot debugging it would be helpful if you turned on rawlogging, and when it again happens check the logs what actually happened: Did some client send \Deleted flag update? If not, what happened between the new mail being seen and its flag being changed to \Deleted?
Also, how is Eudora fetching the message from server? Using FETCH BODY[] or BODY.PEEK[] or RFC822.TEXT? The non-peek version updates \Seen flag immediately, so that could theoretically cause something which could get \Deleted flag to be changed and returned..