User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:18.104.22.168) Gecko/20060830 Firefox/22.214.171.124 (Debian-1.5.dfsg+126.96.36.199-2) Build Identifier: Thunderbird (Mail/News Client) version 1.5 (20060228) I was migrating from webmail to webmail+thunderbird due to storage restrictions on the mail server. I set up thunderbird with the two options mentioned in the summary to save on download time during routine mail checks. Then I made what turned out to be a mistake, I moved all the old mails from my inbox to a folder (named Archive). Thunderbird promptly deleted all those messages from the server without downloading their bodies, so they are permanently lost. This behavior seems quite counterintuitive, and rather lacking in realistic use cases, to me. I think this particular behavior should be fixed by downloading the message bodies when messages are to be deleted from the server because of them being moved. The same option triggers when a local message (headers only) is deleted, that should likely not result in downloading the message body (although undelete capability is lost here). Perhaps all of these behaviors should be configurable. Reproducible: Always Steps to Reproduce: 1. Enable 'fetch headers only' and 'until i delete or move them from inbox' 2. download headers 3. move emails out of inbox Actual Results: headers moved to new folder, bodies deleted from server Expected Results: bodies downloaded, whole emails moved to new folder, deleted from server
in 2.0 and trunk builds, we no longer delete from the server on a move, only on a delete...
So what you're saying is that the functionality that I was counting on, using thunderbird to archive email that wont fit on my webmail server, won't work any more in the new versions? Ranting aside, are you talking about just a delete, or a delete+compact (real delete)? If the former, then data could still be lost.
I don't really understand your question - how are we preventing you from archiving your mail locally by not deleting it from the server when you move it to an other folder? Since we're deleting mail from the server less, it's less likely to be lost. I find the option to delete mail after it's left on the server for XX days to be a useful way to leave mail on the server. If you delete a message to the trash, we will delete it from the server. You are free to move it out of the trash after that, so that's a workaround. I think, ideally, we would have a menu item/command to delete mail from the server - then you could do whatever you want.
(In reply to comment #3) > I don't really understand your question - how are we preventing you from > archiving your mail locally by not deleting it from the server when you move it > to an other folder? Since we're deleting mail from the server less, it's less > likely to be lost. > > I find the option to delete mail after it's left on the server for XX days to > be a useful way to leave mail on the server. > > If you delete a message to the trash, we will delete it from the server. You > are free to move it out of the trash after that, so that's a workaround. > > I think, ideally, we would have a menu item/command to delete mail from the > server - then you could do whatever you want. > The reason I am archiving it locally is to free up space on the server. If I can't influence which messages are kept in each place then that functionality is lost. That functionality we currently have, as long as 'fetch headers only' isnt enabled. Delete then undelete is not a workaround, it would still be subject to the original bug here, that the message bodies would be lost when I delete because they have not been downloaded.
> [...] > > Actual Results: > headers moved to new folder, bodies deleted from server > > Expected Results: > bodies downloaded, whole emails moved to new folder, deleted from server I totally agree with you. Because of this bug, thunderbird deleted over 500 Mails at once, just because the junk filter moved all of the messages (actually only their headers) into the junk folder and deleted the headers and bodies on the POP3-Server. A recovery was impossible. Either this behaviour should be corrected quickly, or there should be a warning to the user that enables both options. Moving a mail should always imply downloading the body if not already done!
1- OS Win98 and Win XP 2- Thunderbird 188.8.131.52 3- Thunderbird setup: Account Settings / Server Settings : Fetch Headers Only Checked Leave messages on server Checked Until I delete or move them from Inbox Checked 4- Operation: a) Click on Get Mail a list of mail with Subject Sender Date and Size appears in the Inbox. b) Double click on one to read and below appears: Not Downloaded Only the headers for this message were downloaded from the mail server. Click here to download the rest of the message. c) Click on "here" and download starts. d) Now if user stays on this page all will work well. Main body is downloaded and displayed. e) However, if user switches to the Inbox window or other windows; so that the window in "c)" loses focus; the downloaded message is never displayed when download is completed. f) You can repeat b) to e) many times and never see the body of e-mail; download starts everytime "again". 5- In the Inbox window there is a new entry for each item c) that completes the download AND the window is not in focus. So the same e-mail message line appears more than once in Inbox. 6- The only way to see the body is either to stay with the window that is downloading it (or get there before download is completed); or double click on the newly created lines in Inbox. "I was complaining to the senders about duplicate e-mails they sent me :) ".
My two cents for the comments on removing mail from POP server. A) I download headers for two reasons: i) One to clear the Pop Server from Junk before downloading all e-mails (in a different client setup). ii) When traveling to avoid the wait due to large attachments arriving before a needed message. Problem is "done work" has to be kept on my laptop until I reach home base and download them for my records. Any move or delete would have undesirable effect mentioned by previous commentators. B) I wish deleting from the server was not tied to any item in the Accounts Settings / Server setup. Instead another toolbar button like current "X delete" that said "Xserver" with a server icon that one could use at will to remove mail from Pop server would do. This way only LEAVE on Server could be set, the rest would be a manual and deliberate operation.
(In reply to comment #3) > If you delete a message to the trash, we will delete it from the server. You > are free to move it out of the trash after that, so that's a workaround. > > I think, ideally, we would have a menu item/command to delete mail from the > server - then you could do whatever you want. > does this need a revisit?
Severity: normal → major
OS: Linux → All
Hardware: PC → All
Component: General → Networking: POP
Product: Thunderbird → Core
QA Contact: general → networking.pop
Product: Core → MailNews Core
1) In comment #6, I have reported a method that one can download the body of the message and not be able to read it. This requires a revisit. 2) In the same comment the appearance of multiple duplicate header lines in the INBOX is mentioned. If the two are not related then that needs a revisit too. 3) If we agree to decouple the local delete from the server delete in the menu buttons; as mentioned in comment #3, then the delete issue does not need a revisit. Although the meaning of the "Leave messages on server" in setup may require a revisit.
Parkhideh, is this duplicate of bug 288465?
(In reply to Wayne Mery (:wsmwk) from comment #10) > Parkhideh, > > is this duplicate of bug 288465? No Wayne; up to comment 6 of bug 288465 we may think them similar, but comments 7 and 8 are talking about items that I have not encountered and it is not reflected here. Mind you, since we are all talking about lost e-mail body, from various angles and operations, both reports can be from the same root cause. So anyone who works on this bug should be advised to look at the reports in bug 288465 as well.
Thunderbird version 16.0.2; Windows OS A) The good news is this: After fetching the headers and clicking on it in the INBOX; a new tab opens that one has to click again to fetch the body of the e-mail. Now one cannot go to another tab before this body is fully downloaded. So, should one move to another tab in the middle of e-mail downloading, the process will abort. This is good news because the double and triple lines of the same header do NOT appear as previously reported in the INBOX. B) The bad news is that LEAVE MESSAGES ON SERVER with option UNTIL I DELETE THEM is broken.** Four Tests on four received e-mails: i) DELETEd the header without downloading the body. ii) DELETEd after read the e-mail. iii) MOVEd the header to TRASH. iv) MOVEd the read e-mail to TRASH. v) DELETEd all from trash in Thunderbird and closed Thunderbird. C) Results, using two different mail servers**: a) All four e-mails remained in the INBOX of the server. b) Items ii and iv showed that they were read. D) Please note that all works as expected if LEAVE MESSAGES ON SERVER is not selected. So the broken item must be the option UNTIL I DELETE THEM. ** This problem could be from WebMail v2 that has recently started on both ISPs; but I give it a low probability.
An addition to tests in comment 12: a) Sent four e-mails. b) Received four headers. c) Opened #1 e-mail; downloaded the body; closed it; then deleted from INBOX. d) Opened #2 e-mail; downloaded the body; then deleted from the read window. e) Opened #3 e-mail; then deleted from the read window without downloading the body. f) Deleted #4 header from the INBOX unread. Going to TRASH: z) e-mails #1 and #2 have contents that can be read. y) e-mails #3 and #4 have headers only. What should you expect if clicking on the DOWNLOAD? I expected nothing to be found on the server like in version 3.x.x of Thunderbird. Not so, the messages will be downloaded. And all four e-mails are on the server, marked as read (not new). Deleting the e-mails from TRASH makes no difference, e-mails remain on server.
You need to log in before you can comment on or make changes to this bug.