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



MailNews Core
Networking: POP
12 years ago
8 years ago


(Reporter: george, Unassigned)



Firefox Tracking Flags

(Not tracked)




12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv: Gecko/20061204 Firefox/
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv: Gecko/20061204 Firefox/

I have the a similar Problem as it was described in 
I'm using TB (german version) account (Freemailer) Restrictions: you can only download messages every 15 Minutes. 

1.setup download only headers from the server 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 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 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

11 years ago
Possible dupe of bug 265553.

Comment 2

11 years ago
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

11 years ago
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.
Ever confirmed: true

Comment 4

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

Or are you able to reproduce this easily, Christian?

Comment 5

11 years ago
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

11 years ago
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

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

Comment 8

11 years ago
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

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

Keywords: dataloss
Version: unspecified → 1.5

Comment 10

10 years ago
- using a 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 ( freemail accounts: 15min) 
RESULT: DATALOSS (the first message may be retrieved correctly, but all others 
are gone / they disappear completely)

using thunderbird (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


10 years ago
Assignee: mscott → nobody
Component: Mail Window Front End → Networking: POP
Product: Thunderbird → Core
QA Contact: front-end → networking.pop
Whiteboard: dupeme
Version: 1.5 → unspecified


10 years ago
Product: Core → MailNews Core
Last Resolved: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 265553
Cleanup *dupeme* whiteboard flag from bugs that are marked as Resolved Duplicate!
Whiteboard: dupeme
You need to log in before you can comment on or make changes to this bug.