Closed Bug 284526 Opened 20 years ago Closed 12 years ago

Cancelling mail download causes TB to forget about mail already downloaded via POP, downloads again

Categories

(MailNews Core :: Networking: POP, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: avi, Assigned: Bienvenu)

References

Details

(Whiteboard: [closeme 2012-04-25][needs retest])

Thunderbird version 1.0 (20050104) If you specify "leave email on server for n days", and fail to connect, the next time the email server is successfully to, all email will be downloaded. 1. Set up a POP account, and specify "leave email on server for 7 days". 2. Use account for at least that amount of time. 3. Attempt to check mail over very bad connection. 4. Since mail check jams, cancel the email check. 5. Check email over good connection. Result: TB will forget that it already downloaded those 7 days of email, and will start downloading them all again. (No, I'm not bitter! Cleaning out 2000 emails was fun.)
I don't even need to specify "leave email on server for n days" to trigger this problem. Simply disconnect the phone line (or have it happen to you because of a bad connection) after you've "received 151 of 468 messages", and you'll get a second copy of those 151. It seems to me that whatever part of TB is talking to the POP server ought to simply issue a series of "get 1st message", then "delete 1st message" commands, rather than "get 1st", "get 2nd", ... "get 468th" followed by "delete 1st thru 468th". (Please pardon my use of pseudo-code.)
John, that's a nice idea, but it's not good enough. Check out RFC 1939 (which is the POP3 spec). Basically, when the client says "DELE n" to delete a mail message, that message is only _marked_ as deleted. However, and this is the key part, unless the client actually says "QUIT", the server's not allowed to delete the messages that were marked for deletion. Thus, during a disconnect, the mail server keeps all messages for a client who might have crashed. (This is the transaction vs update state.) The problem here is that the mail client should be smart enough to remember which messages it's seen already. And it is! Note the "keep for n days" setting. Surely TB remembers which emails it already has and is leaving on the server. My bug here is that disconnecting from a server somehow causes this list of what's already been retrieved to be lost. I experience it because my emails that were already downloaded from 7 days ago are re-downloaded because the record of what was already retrieved was lost. You experience it, but on a much smaller scale.
This is a plea for any sort of workaround for this issue. I've got (for the third time this week) about 5000 messages waiting to be re-downloaded and re-filed. Is there some way to reset the last-message-read value? I can talk POP, if that helps.
yes, this is extremely annoying...the problem is that cancelling causes us to forget what messages we just downloaded. I'm going to change the component/platform, etc, but it's pretty likely this is a dup.
Assignee: mscott → bienvenu
Component: General → Networking: POP
OS: MacOS X → All
Product: Thunderbird → Core
Hardware: Macintosh → All
Version: 1.0 → Trunk
(In reply to comment #4) > the problem is that cancelling causes us to > forget what messages we just downloaded. I'm seeing that cancelling causes us to forget what messages we _ever_ downloaded. In my case, I cancelled before downloading any messages, yet I then started getting every message that was on the server.
hmm, you could be right - I age messages off the pop3 server, so when this happens, I don't get too many messages. We must be clearing out popstate.dat when this happens. I'm pretty sure there's a bug out there that describes what's happening and why it's hard to fix. I'll go look for it.
To reduce the amount of code I have to decipher, does everyone's server support UIDL? Avi, did you cancel after sending the password but before we started retrieving messages, i.e., while we were listing the contents of your inbox on the server? That could be relevant.
(In reply to comment #7) > To reduce the amount of code I have to decipher, does everyone's server support > UIDL? I would imagine mine does (qmail). > Avi, did you cancel after sending the password but before we started retrieving > messages, i.e., while we were listing the contents of your inbox on the server? I haven't any idea. All I know is that I was retrieving messages over my cellphone connection and that I didn't get anywhere so I cancelled the download attempt. I don't know where I was (in fact, how do you tell in the current UI?). After that one time where I cleaned out 2000 emails, I switched to never leaving messages on the server, and have been using that setting since.
FYI: 1) I *think* my server supports UIDL -- it's MS Exchange (ech). Unfortunately, it requires a secure connection so I can't just telnet to 110 to find out. 2) I'm pretty sure this happens to me when the network is disconnected while it's listing the messages. That's usually a very long step in my case, since there are always thousands of messages on the server. 3) I have it set to leave mail on the server for 4 days. Thanks, Rich p.s. I did find a brute-force workaround, which is to move all Inbox messages to a temporary folder, disable all message filters, re-download the 4000 messages, delete all the duplicate messages (judging by the date of the last thing in my Inbox), re-enable the filters, run filters on Inbox, and move the temporary-Inbox messages back to Inbox.
hi guys, i here for the same bug too. Even though some 2 years have gone since this bug was reported i still am experiencing this issue. I simply can't understand what's taking so long to fix it when the solution is so simple...(post no. 1 here)...please understand that this bug is very anoying for me as i am receiving over 3k e-mails / day and i don' t like to have 12k messages in my inbox and some 3-4 copies of each message... If nobody can fix this one i'm willing to help with a patch or something. Thunderbird is an excellent e-mail client (my favorite) but bugs like this make people turn their backs on us and the open-source community
Have you tried a trunk build? I've been working on this in a different bug, and I believe I've fixed it on the trunk. It hasn't made it into an official released build because of our release cycle. ftp://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk See the last few patches in bug 240049
Haven't tried it yet but will let you know how it works Thanks
This problem still seems to exist in 3.0. A good workaround would be to allow the user to set a "batch size", where each POP session would download and delete only the first N messages, then QUIT. My phone line has been so flaky lately that I would just set N=1 and forget about it.
Product: Core → MailNews Core
QA Contact: networking.pop
John in comment #13: > This problem still seems to exist in 3.0. > > A good workaround would be to allow the user to set a "batch size", where each > POP session would download and delete only the first N messages, then QUIT. My > phone line has been so flaky lately that I would just set N=1 and forget about > it. John do you still see this?? xref bug 352998 Mail never deleted after connection loss
Whiteboard: [needs v3.1 retest]
I upgraded from dialup to DSL in Dec 2009, and have not had the kind of disconnection that would trigger the problem since, so I don't know. If someone using dialup still cares about this bug, would they please respond. Otherwise, maybe it's time to set this RESOLVED EXPIRED.
This seems rather abandoned. And Rich Feit's address is dead. If anyone still see this, please speak up.
Whiteboard: [needs v3.1 retest] → [closeme 2012-04-25][needs retest]
RESOLVED INCOMPLETE due to lack of response to previous question. If you feel this change was made in error, please respond to this bug with your reasons why.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.