User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 I am developing an email server, and due to a bug in the server I received a bunch of garbled email fragments. Specifically, I believe the problem is caused by an email that ends before the headers have been completely read. For example, the POP server returns: Timestamp: Mon Apr 19 05:05:07 CDT 2004 Received: from 18.104.22.168 by 22.214.171.124 Mon Apr 19 05:05:06 CDT 2004 X-Message-Info: V[4-5 . Obviously, this is not a normal message and perhaps should be silently discarded, cause the process to end abruptly, whatever. The problem is that when the retrieval process dies, it does not unlock the folder. So whenever I try to retreive messages on the account again, I get the messagebox "This folder is being processed. Please wait until processing is complete to get messages.". At this point, I have to close Mozilla (Not just the email portion, but the entire process) in order to continue receiving mail. Hope this helps! Reproducible: Always Steps to Reproduce: 1. Make a POP server that can return the above message fragment 2. Retrieve the message Actual Results: As described above. Expected Results: Silently discard the message, retrieve the message with empty content, whatever, but not leave the inbox folder "being processed"
Well, there already are bugs on "folder beeing processed" around (bug 152675 and bug 206616). But this report is explicitly about this problem occuring after a stalled messge get. So I don't wanna mark this as dupe. In fact to have a look on this particular cause is on my todo for weeks now.
I now tested msg retrieval with your "mail", it downloaded it just normal and didn't die. But if I get the server to drop the connection (tested with a Perl script), Mozilla doesn't realize this. I think the key function to be called is ReleaseFolderLock(). Calling nsPop3Protocol::Abort() from nsPop3Protocol::OnStopRequest() does this job and losing the connection while getting mail isn't bad anymore. Deleting the nsPop3Sink object is another step that doesn't happen if the connection drops. If it would get deleted the destructor would call ReleaseFolderLock() automatically. But Abort() doesn't help here. David, though I've a backtrace from when ~nsPop3Sink gets called (via ~nsPop3URL via nsMsgMailNewsUrl::Release() via nsPop3URL::Release()) after a correct msg retrieval, I can't say how to do it when connection suddenly goes away. Any idea?
I am seeing this type of behavior as well with winXPPro, Moz 1.7final. I believe it has something to do with norton AV2003 changing the message header of files where viruses are detected, but I'm not 100% sure. I never had this issue before (I have had Norton AV2003 for quite some time) but my ISP recently upgraded to a new mail server (Icemail) and now I have this issue (only with my Mozilla client). I have seen a post on mozillazine about this happening in Thunderbird as well.
WFM per reporter "it was resolved some time ago - I forget the exact version." Please reopen if you still see the problem on a current version.