User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:22.214.171.124) Gecko/20061204 Firefox/126.96.36.199 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:188.8.131.52) Gecko/20061204 Firefox/184.108.40.206 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 220.127.116.11 (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
Possible dupe of bug 265553.
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.
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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?
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.
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).
Sorry, I can't follow you, the header is deleted without calling IncorporateComplete(). I can't see where, but not there.
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.
note: reporter may be never come back "User has exhausted allowed storage space"
Version: unspecified → 1.5
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 18.104.22.168 (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
Assignee: mscott → nobody
Component: Mail Window Front End → Networking: POP
Product: Thunderbird → Core
QA Contact: front-end → networking.pop
Version: 1.5 → unspecified
Product: Core → MailNews Core
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 265553
Cleanup *dupeme* whiteboard flag from bugs that are marked as Resolved Duplicate!
You need to log in before you can comment on or make changes to this bug.