368404 - deleted mails - pop3 with download only headers and freemailer account with time restrictions

Status: RESOLVED DUPLICATE of bug 265553

(MailNews Core :: Networking: POP, defect)

Description

[george]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1

Hello,
I have the a similar Problem as it was described in https://bugzilla.mozilla.org/show_bug.cgi?id=362361. 
I'm using TB 1.5.0.9 (german version)
Web.de account (Freemailer) Restrictions: you can only download messages every 15 Minutes. 

1.setup download only headers from the server
2.download email (you get the headers not the content)
3.try to review an 1st email clicking in it... downloading 1st email... ok
4.try to review an another email within 15 minutes clicking in it... downloading email.....opsss DISSAPEARS

I think the problem is, that TB FIRST deletes the headers BEFORE Download of
the hole Email Succeed. So with the 15-Minute Restriction of my webmailer TB
deletes first the header, tries to connect to the webmailer again and fails.
Header was deleted...email disappears. 

Is there a fix for this problem? for example that tb first downloads the hole message and after sucess delete the header or something else.

Reproducible: Always

Steps to Reproduce:
1.setup download only headers from the server
2.download email (you get the headers not the content)
3.try to review an 1st email clicking in it... downloading 1st email... ok email appears
4.try to review an another email within the 15 Minutes clicking in it... downloading email.....opsss DISSAPEARS

Actual Results:  
Message was deleted- dissapears in TB , not on the Freemail server

Comment 1

[Mike Cowperthwaite]

Possible dupe of bug 265553.

Comment 2

[Howard Chu]

One possible explanation for this problem would be in nsPop3Sink.cpp:CheckPartialMessages - it deletes the record for any message that isn't reported "Found" by the server. This check doesn't take into account communication failures with the server, or access controls on the server refusing to answer the query. So this Boolean Found result should have been tri-state - Found, Not Found, Unknown, and we should only delete the record if it is definitively Not Found.

Comment 3

[Christian Eyrich]

Howard, I don't think CheckPartialMessages() is or is the whole problem. When downloading the body of a message and the connection is closed right after sending the RETR command, the header message is removed and that's it. CheckPartialMessages() isn't even called up to that point.

Comment 4

[David :Bienvenu]

a Pop3 protocol log of a session where this happens might be interesting:

http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap

Or are you able to reproduce this easily, Christian?

Comment 5

[Christian Eyrich]

This is easily reproducible with a Perl script as server that simply cuts the connection at some point in transaction state before we have the mail. So what I meant is not that closing the connection is our fault, but if it happens we've a problem.

Comment 6

[Howard Chu]

OK, the old header is deleted automatically in pop3sink::IncorporateComplete. That appears to be called twice in nsPop3Protocol.cpp, and probably we should be using IncorporateAbort instead if we get a short message (0 bytes and the connection failed).

Comment 7

[Christian Eyrich]

Sorry, I can't follow you, the header is deleted without calling IncorporateComplete(). I can't see where, but not there.

Comment 8

[Howard Chu]

Then I guess the thing to do is set a breakpoint on DeleteHeader and look at the stack trace. There just aren't that many places where this can happen.

Comment 9

[Wayne Mery (:wsmwk)]

note: reporter may be never come back "User has exhausted allowed storage space"

Comment 10

[Paul-Gerhard Werner]

STEPS TO REPRODUCE:
- using a http://freemail.web.de freemail account (a popular freemail provider in germany)
- using the option "do not download messages larger than XX kB" (5kB is good
for reproducing) OR "download headers only"
- immediately downloading the rest of all truncated messages without waiting
for the POP3 poll time limit to expire (web.de freemail accounts: 15min) 
RESULT: DATALOSS (the first message may be retrieved correctly, but all others 
are gone / they disappear completely)

using thunderbird 2.0.0.14 (nothing changed since 1.0.3 :-( )

reproducible: always
severity: MAJOR / CRITICAL

duplicates of this bug: bug 118432, bug 225199, bug 275594, bug 322710, bug 337950, bug 362361, bug 368404, bug 265553

Comment 11

[Pierre]

Dup of https://bugzilla.mozilla.org/show_bug.cgi?id=265553 ?

Comment 13

[[:Aureliano Buendía]]

Cleanup *dupeme* whiteboard flag from bugs that are marked as Resolved Duplicate!