User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:188.8.131.52) Gecko/20071213 Fedora/184.108.40.206-3.fc8 Firefox/220.127.116.11 Build Identifier: version 18.104.22.168 (20071031) I've got dovecot doing imap on a RHEL 4 box. Every once in a while I have a user who complains he's unable to delete email. When I remove his Trash file from his ~/.imap directory and create a new empty Trash file things start to work again. I suspect he's getting some sort of spam, or something in Chinese perhaps, that when the email goes into his Trash folder Thunderbird chokes on it somehow. Reproducible: Always Steps to Reproduce: 1. Have a file similar to the one I'm attaching as your imap Trash file. 2. Try and delete mail 3. Actual Results: Thunderbird is unable to delete mail. Expected Results: Thunderbird should function as normal and mail should go to the Trash when it's deleted.
Created attachment 297281 [details] A broken Trash file Here's a Trash file that caused the problem.
Attachment #297281 - Attachment mime type: application/octet-stream → text/plain
I'm not sure why, but my text editors all say the first testcase is a binary file - though it's text of course - and partly shown too. (Didn't try the second.)
(In reply to comment #1) > Created an attachment (id=297281) > A broken Trash file Length of first line of the file is 19393 (terminated by 0x0A=LF). First line of the file consists of > (1) long long spaces (many many 0x20's) > (2) From email@example.com Wed Dec 12 16:15:02 2007 > (3) 0x0A=LF Length of (1)+(2) is 19393. First line(looks to be Unix Mbox's mail separator line) is apparently corrupted, if it is data of Unix Mbox file. How did you obtained the data? Where was original file placed? Note: In addition to above, two spaces are placed between ".edu" and "Wed". When Unix Mbox file's mail separator by Tb or Seamonkey, it becomes "From - Wed ..." and only single space is placed at there. When error(unable to delete mail) occurs, what will happen if you do (1) shut down Tb, (2) delete Trash.msf file for the account's Trash folder, (3) restart Tb? (Tb will try to re-download all mails in Trash folder from IMAP server, because .msf file is deleted). Is there any IMAP server side error? Is your setup of Devecot proper? Did spammer(s) send the long long line to your IMAP server?
Attachment #297282 - Attachment mime type: application/octet-stream → text/plain
Attachment #297282 - Attachment mime type: text/plain → application/octet-stream
(In reply to comment #2) > Created an attachment (id=297282) > Another broken Trash file First line of the file. > (1) 8918 bytes of 0x00 > (2) From firstname.lastname@example.org Fri Jan 11 16:31:42 2008 > (3) 0x0A=LF Total length of first line : (1)+(2) = 8676 bytes. I changed mime-type to text/plain once, but I've changed back to application/octet-stream, because many 0x00 is included in data. Sorry for spam.
Correction of my comment #4. Sorry for spam. I checked both files with Open Object REXX Script. As Mignus said, first one("A broken Trash file" in comment #1) also contained "binary data". The first one had data of 0x00 too. First line of the first file consists of: > (1) 19335 bytes of 0x00 > (It was not 0x20. My text editor displayed 0x00 as an space.) > (2) From email@example.com Wed Dec 12 16:15:02 2007 > (3) 0x0A=LF > Length of first line : (1)+(2) = 19393.
This isn't a unix mbox file, if by that you mean the stuff I'd find in /var/spool/mail/. I grabbed the files out of the users home directory, inside his .imap/ directory to be exact. They were named "Trash". His home directory is on a rhel 5 machine, and my mail server is a rhel 4 machine. I can try deleting the Trash.msf file the next time this happens, as it's been happening pretty regularly. I'll let you know where that gets me. A search through my mail server logs doesn't reveal any dovecot errors. And I'm pretty sure my setup is good as the server has been chugging along just fine for a few years now. It's just this one specific user that keeps having problems with deleting files. He's Chinese so that could have something to do with it. I have no idea how the "long long line" you're talking about got there, but a spammer could certainly be the culprit.
deleted inbox files return with additional copies
can you reproduce this using version 3.0  or 3.1 ? if you no longer see the problem, please set resolution to WORKSFORME when closing the bug. otherwise, perhaps wada or someone can mark confirmed  http://www.mozillamessaging.com/en-US/thunderbird/  http://www.mozillamessaging.com/en-US/thunderbird/early_releases/ (beta 2 comes out soon)
RESOLVED INCOMPLETE due to lack of response to previous comment. If you feel this change was made in error, please respond to this bug with your reasons why.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.