Closed Bug 240969 Opened 20 years ago Closed 18 years ago

inbox mail folder flagged as "being processed" if the retrieval process dies because of a garbled message received using POP

Categories

(MailNews Core :: Networking: POP, defect)

x86
All
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: david, Assigned: sspitzer)

Details

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 24.19.158.249
        by 69.20.9.211
        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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
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.  
Product: MailNews → Core
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.
URL: N/A
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.