Open Bug 531088 Opened 15 years ago Updated 7 years ago

Need warning and UI for destructive POP3 default setting "Leave messages on server for at most [14] days" or "until I delete them"

Categories

(Thunderbird :: Account Manager, defect)

Product:
Thunderbird
Component:
Account Manager
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(blocking-thunderbird3.1 -, blocking-thunderbird3.0 -)

Tracking Flags:
Tracking Status
blocking-thunderbird3.1 --- -
blocking-thunderbird3.0 --- -

People

(Reporter: thomas8, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: dataloss, uiwanted, Whiteboard: [has l10n impact][gs])

Attachments

(2 files)

screenshot of the patch
20.68 KB, image/png
Details
patch to add POP delete settings to account central
3.19 KB, patch
Details | Diff | Splinter Review
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091121 Thunderbird/3.0 rc1 build 3 STR 1 default install of tb 3rc1, set up pop3 account using autoconfig 2 download loads of mail from pop3 server 3 be glad that we're better than tb2 and the messages aren't deleted from server 4 after 15 days, look at your server again Actual results - bang your head against wall because after 14 days, TB silently deleted all your messages from server without ever telling you about it (and it will be very hard to get them back there, not least due to some other bugs) Expected results - we need to communicate these destructive settings to the user during autoconfig (UIneeded, l10n impact) - we should also let the user change these during setup
Keywords: dataloss, uiwanted
Whiteboard: [has l10n impact]
Blocks: 531092
I have notice of this behavior also in some italian thunderbird forum.
dataloss = sev:critical (and helps bug get better attention) bug 531092 comment 1 indicates we are not worse than version 2 here (and even consistent with other mail SW), however, I'm not sure this behavior helps our image :)
Severity: normal → critical
blocking-thunderbird3.0: --- → ?
In reply to comment #2 which added me to the CC. I'm not sure what the default is for a new account but I would expect "Do not leave mail on server", because: - If you read mail on only one client (e.g. your home is your office) then normal POP client behaviour is "download & delete", i.e., after you fetch your mail from the post office, said office doesn't keep a copy. (Reminder: POP is not IMAP: POP is like a post office box from which you fetch your mail to read it at home; IMAP is like a public library booth where you leave your books while not reading them.) - If you have more than one client (e.g. one at work and one at home) then "download & delete" still applies to work mail read at work and home mail read at home (assuming of course that the accounts -the email addresses- are different). - I only expect "leave on server" for work mail read at home or home mail read at work. How long to leave it there (waiting for the other client to take care of it) may depend on circumstances. However, in this case I would expect "forever" unless the user sets it to some other value. If the user *does* intentionally change the setting, I would expect that he knows what he's doing, and an "Are you sure?" popup would only be an annoyance. IOW I don't agree with comment #0 point 3 "Be glad": for me leaving it on server if I don't explicitly say the opposite is not "better" but "worse" behaviour (for a POP, not IMAP, account).
Unfortunately, comment 3 does not help to find a solution for this bug, apart from pointing out the obvious: different people = different needs. That's the equation that calls for customization UI, or transparency at least. And can we please refrain from that noise about POP3 not being the right protocol to leave mails on server, taking longer etc. While technically true, from a user's POV that's completely irrelevant. Millions of users have no idea about the technical difference, and millions of users deliberately DO keep their mail in their pop inbox, and not just 14 days. Also, there seem to be misunderstandings in comment 3 about what this bug is about. It's NOT about an "Are you sure?" warning when the user deliberately changes "leave on server" setting. It might also help to know the default settings before adversely commenting on a bug that is based on default settings. Furthermore, in view of the tons of discussion where people complained about dataloss in TB2, I don't understand how anyone could NOT be glad that we at least no longer destroy messages *immediately* after account setup (now only after a 14 days delay). Finally, arguments starting with "if" followed by a condition that doesn't apply to a potentially large no of users are'nt useful for supporting problematic default settings. FTR: POP3 default settings for quick account setup are: [x] Leave messages on server [x] for at most 14 days [x] until I delete them These settings are destructive (on purpose), and we don't communicate them in any way during the setup. And, we don't warn the first time we automatically delete messages from server after 14 days. The perfect recipe for dataloss. No wise talk in the world will make this problem go away.
Right, I think we all can understand that either default isn't going to be the correct choice for every user. However the previous choice caused a lot of users who were "just trying" Thunderbird to lose all of their emails on the server. We had the option of trying to ask those users in their first couple minutes of use if they "want to delete messages from the server" or going this better route where we don't delete messages initially but work on a notification that after a certain period of time we will start helping them with account maintenance. We've chosen this, the better route than the previous destructive route or the question that many users can't quite grasp during our first couple minutes of use. I think we could start simply with a notification that appears on any account view that shows messages from the POP server we are attempting to clean. I'm not sure how that would affect multi-account saved searches; I suppose we would have to handle that as well when a message from such an account is shown. Then until the user clears the notification bar by choosing an option like "Clean up (XX) messages from the server" or "Don't delete anything" / cancel or "Preferences". Likely if a user chose to cancel this we'll have to pop up another message further down the road to remind them that if they have a small account limit Thunderbird won't know and their emails will be getting bounced. There might be some other tricks we could do to examine the messages we've downloaded for size such that we can present the amount of messages which are taking space on the server. Also to note that I believe we have another bug filed elsewhere which asks the ISPDB to include this kind of POP user storage as a component to account creation such that we would have an idea of how much POP space should be available.
As a side note, I don't remember seeing that bug, so if you find it (or create a new one), please assign it to the Mozilla Messaging product, ispdb component, since that's where we're keeping track of ISPDB bugs. Thanks, Blake.
Blocks: 534628
Blocks: 231541
(In reply to comment #5) > Also to note that I believe we have another bug filed elsewhere which asks > the ISPDB to include this kind of POP user storage as a component to account > creation such that we would have an idea of how much POP space should be > available. It's just a comment in this bug's well-known parent: bug 231541, comment 112 by David A. (In reply to comment #6) > As a side note, I don't remember seeing that bug, so if you find it (or create > a new one), please assign it to the Mozilla Messaging product, ispdb > component, since that's where we're keeping track of ISPDB bugs. Thanks Blake for the reminder. I created the following bugs for this: - Bug 534629 - Add server quota information to ISPDB (account setup config database) - Bug 534628 - Implement intelligent "leave messages on server" default settings for POP3 accounts, based on storage quota size on server
I don't think this blocks a 3.0.x release, especially as most things in-product would actually require UI changes. I could see some documentation being done for the support website, but I don't think there's much else we're going to be able to do in 3.0.
blocking-thunderbird3.0: ? → -
As per our Get Satisfaction Triage meeting of March 8, 2010, nominating as blocking 3.1 We don't need the ultimate solution in 3.1, here's some brainstorming thoughts after discussion with Bryan Clark: 1. On first use, warn user that email will be deleted on POP sever after 14 days and link to SuMoMo article (please file a bug for the SuMo article and CC :rolandtanglao) 2. Subsequently the user can change it with a hidden pref 3. RelNote the hidden pref and link SUMOMO article in release notes for people who are upgrading to 3.1 and may not realize their POP email is being deleted on their POP server after 14 days
URL: http://gsfn.us/t/rpod
blocking-thunderbird3.1: --- → ?
Whiteboard: [has l10n impact] → [has l10n impact][gs]
Here's how I was thinking we could make this dialog work. $DAYS currently == 14 At ($DAYS - 4) days *and* before the POP server delete can be performed. i.e. if TB is opened at ($DAYS + 1) days this dialog blocks POP access, blocking the delete. The goal of the dialog is to inform the person what we will be deleting messages if they don't change their email settings. I'm using an OK button instead of a close button because if feels like you need to confirm this. I don't think this dialog is the right place to disable or change the settings since there are so many options available, so it's best to take people directly to the settings page. I think we want to use this kind of danger icon /!\ in the dialog as this is a data loss issue. Here's my first pass: $account_name +------------------------------------------+ | | | For space saving reasons Thunderbird is | | currently configured to delete messages | | older than $DAYS days from your account, | | $account. <a>Read more information</a> | | | | ( Open Disk Space Settings ) ( OK ) | | | +------------------------------------------+ I have a question for Mark or Bienvenu. Is it possible to block the POP delete operation with a dialog like this? Given that if the person selects Open Disk Space Settings we'll need to continue to block until they make changes. We could try changing the interaction such that clicking the button in the dialog disables deleting and then opens up the disk settings page.
blocking-thunderbird3.1: ? → ---
Its not clear if Bryan meant to clear the blocking-thunderbird3.1 nomination, so I'm re-nominating.
blocking-thunderbird3.1: --- → ?
Some thoughts... (in reply to comment 10) We'll only want to prevent the deletion, not to block pop access altogether, right? When I press OK, messages will be deleted from server on next pop access? If yes, then OK is too harmless a caption. Pls change to something more obvious, like "Delete Messages from Server" If user doesn't choose "Delete Messages from Server" but clicks to modify Settings, we CANNOT delete until we have explicit consent. That means, a) we either have to change the settings before opening settings dialogue (as indicated by Bryan), or b) we have to ignore the settings until some other way of explicit consent (e.g. same warning dialogue again at next pop). Both a) and b) will be confusing. a) User (me) has just been informed about TB's apetite for deletion; but when I actually get to settings, deletion has already been disabled. What now? Confused user might even involuntarily switch deletion back on thinking that he needs to change sth to avoid announced deletion. Otherwise, he'll be confused why TB claims intentions to delete, but deletion is off. b) leave deletion settings intact and ignore them until explicit confirmation isn't much better (esp. for those who WANT the deletion). It's not as confusing as a), but we need to ask the user about deletion again, probably with same warning dialogue. The confusing part is that deletion-type user might actually expect to "confirm" the deletion settings from settings dialogue, but we must ignore that confirmation because the preserve-type user has NOT confirmed our warning dialogue, so we can't be sure if deletion is actually wanted or not. Finally, in spite of claims to the contrary I can't help the impression that whatever after-the-fact solution or explanation this will get, it's all way more complex, confusing and intruding than informing and asking the user about the server retention settings upfront when he is spending time to set up the account, anyway. Moreover, I think the UX of the undisclosed default setting is very much misleading for everyone: - For those who want their mail to *stay* on server, for two weeks, we're making them believe mails WILL stay on server. After two weeks where everything seems fine, out of the blue, we ask about deletion. - For those who want their mails *deleted* from server, we're not deleting for the first 14 days (without explaining that we will, after 14 days), so they'll have to double-check and find the settings dialogue if they want to be sure before day 14. Maybe this isn't a one-for-all solution, but a none-for-all solution. I'm aware that finding the right (easy) wording and least complex UI for informing/asking upfront (with account creation) might be non-trivial, but I'm sure it can be done, and it might be way more plausible and consistent than what we're trying now.
didn't mean to remove that, got mid-air-colided (In reply to comment #12) > Some thoughts... > (in reply to comment 10) > We'll only want to prevent the deletion, not to block pop access altogether, > right? True, I'm assuming we have to block all of POP access to prevent deleting the messages; which might not be true. If we can just prevent deleting without blocking download then that would be best. > When I press OK, messages will be deleted from server on next pop access? > If yes, then OK is too harmless a caption. Pls change to something more > obvious, like "Delete Messages from Server" Yeah, we probably need something more explicit but still more targeted toward the messages we'll be deleting. I wonder if we can have the count of messages that will be deleted and maybe even the date of the oldest message... I'm also wondering if the dialog tone should be asking if "Would you like Thunderbird to turn on scheduled cleanup of your POP mail." And perhaps we should just turn off the auto-delete default but have this dialog which reminds people to turn on the setting instead. > Finally, in spite of claims to the contrary I can't help the impression that > whatever after-the-fact solution or explanation this will get, it's all way > more complex, confusing and intruding than informing and asking the user about > the server retention settings upfront when he is spending time to set up the > account, anyway. I don't think this is an either or scenario. It might make sense to offer an option at the beginning of setting up your POP account. However asking too many questions at the beginning gets tiresome for users and we lose people from signing up. > Moreover, I think the UX of the undisclosed default setting is very much > misleading for everyone: > - For those who want their mail to *stay* on server, for two weeks, we're > making them believe mails WILL stay on server. After two weeks where everything > seems fine, out of the blue, we ask about deletion. > - For those who want their mails *deleted* from server, we're not deleting for > the first 14 days (without explaining that we will, after 14 days), so they'll > have to double-check and find the settings dialogue if they want to be sure > before day 14. Right, which is why I'm wondering if we should be removing the default but adding a reminder to clean your POP account instead. That's a bit of a change of direction but seems like it would really help.
Since this has strings, we're going to need it for b2 in two weeks. philor, would you be up for taking a run at it?
blocking-thunderbird3.1: ? → beta2+
If you want it in two weeks, or in any sort of scheduled time, then I'm not your man.
nsPop3Protocol::LoadUrl applies the age retention settings, before we start getting new mail, so we could put up a prompt there (though we may run the risk of the server timing out while the prompt is up, and we may be running an automatic check for new mail, in which case, we don't have a msg window to prompt with). The code that actually sends the DELE to the server gets called in several situations, e.g., when the user deletes a message, by default, we will try to delete that message from the server. We can't tell the difference between that, and aging, by the time we get to send the dele command. You might be better off warning the user at account setup time, though I'm not sure how many users are really going to understand the warning.
Perhaps we can see how other mail apps that default to aging messages off the server handle this.
We had a significant amount of discussion about this in the driver meeting today. We came to a couple of conclusions: * There a lot of UX and expectation constraints in play here, meaning that whatever choice we make comes with non-trivial bad consequences. * Given the current feedback we've received, our belief is that for the vast majority of people, the existing default is the right one, and the UI is tolerable, though certainly not ideal. For this reason, we believe that this isn't truly a blocker for 3.1, so marking as wanted+ instead. If we start seeing evidence on GetSatisfication or elsewhere that that judgment is wrong because significant numbers of people are running into this, we can certainly reconsider. As part of that discussion, someone (Bryan, maybe?) came up with the idea that a good way to keep the user apprised of what is likely to happen to his or her messages is to add something that describes the expiration policy to the account summary page.
blocking-thunderbird3.1: beta2+ → -
Flags: wanted-thunderbird+
No longer depends on: 533680
See my comment in bug 534628 (comment 2) where I propose a more general solution. "I agree with you that "for at most 14 days" is a dangerous option (data loss) and should be avoided. I personally use this option with 999 days as a free network backup for my incoming mail and erase the messages on server after my local backup of mail. This is not the only option that I don't like, all this problems may have a simple (to implement) and hopefully fool-proof solution : at the end of the present creation process, propose 3 choices : 1) review your account setting with a message saying that default values may not correspond to your planned use. This will branch to the existing procedure that show the account setting. 2) receive your mails. As presently implemented but giving the advice to send test messages from from your other accounts before disclosing the new address to your contacts. 3) exit for the account creation procedure. There is room for improving my proposed procedure : 1) ... 2) for all options : use 2 levels of defaults : first general database, second a sort of profile for creation of new accounts user defined but once."
Summary: Need warning and autoconfig UI for destructive POP3 default setting "Leave messages on server for at most [14] days" or "until I delete them" → Need warning and UI for destructive POP3 default setting "Leave messages on server for at most [14] days" or "until I delete them"
Just wanted to make a note here that 14 days is the standard for POP3 desktop mail clients. When choosing this new value (from not keeping mail at all before) we looked over the major mail clients and 14 days was equal to or higher than what other clients choose as their defaults. Obviously there is always still room to improve but this is a much more standard value. I want to take off the table the idea of a UI where we ask people to "review their settings" as this is always prone to error and expansion. This is the wrong type of interface for a number of reasons which aren't up for discussion. Instead lets focus on what we can do to find and remind people of the default value chosen and help them change it. This is where our efforts would be most valuable.
Attached image screenshot of the patch —
here's a screenshot of a quick (took me 45 min) patch that makes this important server setting available from the Account Central view.
The text is clickable and takes you to the server settings page
Thanks for looking into this! Proposal (single line -> less visual burden, clearer text): Deleting messages after 14 days (_Change..._) OR Deleting messages after 14 days (_Change Settings..._) Thoughts: - attachment 446908 [details] adds 2 lines to account central (AC) to show/change the settings; server retention settings are 3 lines altogether (couldn't we just show them all? Or could we show single line with in-place-expander to see all three?) - two lines is a lot of permanent visual burden in AC for a setting that will usually be changed only once - the wording is ambiguous: in spite of equal grammar, the two lines mean different things: leaving messages on server = go to the settings (NOT: TB is currently leaving messages on server) deleting messages from server after 14 days = setting status information (TB is currently deleting...) - "leaving messages on server" does neither sound like a command to do so (which should be "leave messages on server"), nor does it sound like you could change the settings here (which should be "change settings...") - What are we showing as server retention status information on account central when only "until I delete them" is checked in the settings, but NOT "for at most ... days"? Perhaps we could show "Deleting messages from server when you delete them in Thunderbird" IOW, "deleting messages after 14 days" is only half of the status information to describe current deletion policy...
(In reply to comment #23) > Proposal (single line -> less visual burden, clearer text): > Deleting messages after 14 days (_Change..._) OR > Deleting messages after 14 days (_Change Settings..._) grrr... obviously, what I meant was Deleting messages *from server* after 14 days (_Change..._) OR Deleting messages *from server* after 14 days (_Change Settings..._) I like Bryan's general idea of combining upfront server retention status information with direct access to the settings. Bryan, if we could combine the account central change you proposed with a warning before the first actual deletion takes place (as you proposed before), that would be quite nice a solution.
Current default setting is an compromise for following paradox. - If "Leave Messages on Server" is not defaulted, recent big mbox users will loose many old mails once he accessed POP3 server. This is not real mail data loss, unless downloaded mails are deleted and folder is compacted, but there is no way to recover many mail data in mbox on POP3 server. "Leave Messages on Server"=ON was defaulted for this kind of users. - If "Leave Messages on Server" is defaulted, majority of users, small mbox users, will loose new mails because of mbox full. This is real mail data loss, because rejected mail is not kept at any where. "For at most 14 days" was defaulted for this kind of users. How about "dialog before automatic deletion by age" which is similar to current "dialog before auto compact"? [ x ] Leave Messages on Server [ x ] For at most NN days [ x ] Ask me before purging from POP3 server (Dialog) According to Leave Messages on Server/For at most NN days for pop3.abc.def, already downloaded XXX mails are being deleted from POP3 server, and I'm asking you according to "Ask me before purging from POP3 server". Can I delete mails from POP3 server? [ Yes/OK ] [ No/Cancel ] Note: If you want to change above setting, change seetings at Server Settings, please. - User who needs Leave Messages on Server=OFF, but is unfortunately forced ON by protectection of other users from unwanted mbox data clear: He can disable the option by dialog. - User who needs Leave Messages on Server=ON but never wants automatic deletion by age, or trial user who doesn't want mbox clear during trial use: He can disable automatic deletion by dialog. - User who needs Leave Messages on Server=ON and does want automatic deletion by age with default value: Dialog is merely annoyance for this kind of user, but I think number of this kind of users is not so large. He also can change settings after he see dilog.
In reply to comment 25 " - If "Leave Messages on Server" is defaulted, majority of users, small mbox users, will loose new mails because of mbox full. This is real mail data loss, because rejected mail is not kept at any where. "For at most 14 days" was defaulted for this kind of users." " With the Webmail interface the percentage of the quota used is often shown but with TB I have no clue : a part of the mailbox full risk comes from this. I have read RFC 1939 protocol for POP3. My understanding is that, if TB send the LIST command without parameter, the server should give the total size of the messages in the first line of its response. So TB can parse this value and if it also know from database the quota it may compute the percentage of quota used and give a warning message above 75% (or any better value) advising the user to do some cleaning, percentage may also be shown transiently in the status bar (bottom of screen) during reception process. This may alleviate the risk of mailbox full. In case of mailbox full the data is not completely lost in all cases : an error message is sent back by the POP server to the sender of the message, if he is clever he send a new short message (that may fit in the mailbox) to the addressee asking to clean mailbox then later the big original message... If the mailbox is too small, in the 10 to 20 MO range (old accounts), and 2 or 3 big (5 to 15 MO.) messages with image attachments are received the same day the "leave message on server x days policy" has no valid solution. I think that we should give to the user the advice to shift to a bigger account or at least create a big new account (Gmail ?) and instruct his contacts to send to it their big messages (I have done this, it works with most contacts and has the side advantage that receiving in other accounts is no more delayed by big messages !)
I agree with jist of this ticket, especially re: fresh installs. I installed TB 3.1 fresh to TRY IT OUT and was VERY ANNOYED TO FIND IT HAD SUCKED THOUSANDS OF EMAILS, __PERMANENTLY__, OUT OF MY yahoo account while I was looking the other way. It should certainly NOT do this without a warning, at least on web-mail accounts. Users may think TB has 'trapped' them into using TB forever. This is EXACERBATED by the fact that the install-time 'change my server options' screen DOES NOT SEEM TO STOP BACKGROUND FETCHES FROM OCCURRING. (I had got to the 'setup my server' part of the install, LEFT DETAILED SETUP DIALOGUE ON THE SCREEN, went away to do something else, and when I came back the damage was done. WTF? It DL'd before I was finished setting up???) So I am NOT HAPPY with my first experience with TB - It did DANGEROUS, unexpected, irreversible things WITHOUT WARNING. It should be more careful when the outcome is essentially irreversible. If anyone has any ideas to get my emails BACK onto the Yahoo servers, let me know. Grrrr. Very unhappy trial user...
We don't delete messages from the pop3 server immediately; we leave them on the pop3 server for 14 days. Perhaps yahoo pop3 does not support leave on server correctly...
(In reply to comment #28) > We don't delete messages from the pop3 server immediately; we leave them on the > pop3 server for 14 days. Perhaps yahoo pop3 does not support leave on server > correctly... You missed my point. I had about 10 __YEARS__ of email in my web-mail account. I was JUST TRYING TB OUT to see what it was like, and it ruined my life like a drag on a crack pipe might. Maybe that's an exaggeration... ;-) But it has seriously screwed up 10 years of my email history that's for sure. TB should NOT assume that I want to move all my emails into TB JUST BECAUSE I INSTALLED IT, ESPECIALLY FOR WEB-MAIL ACCOUNTS WHERE ANOTHER METHOD OF ACCESS IS COMMONLY DESIRED IN PARALLEL. i.e. It should not do anything so potentially destructive without warning. This is really a bad look. Do you not get it? I can see that someone who uses TB day-in and day-out might not see the problem, but put yourself in the shoes of a new user trying it out, please... Then you should be able to see that this 'use case' is a disaster.
we don't remove mail that's 14 days old or older; we only remove mail 14 days after we first downloaded from the server.
(In reply to comment #30) > we don't remove mail that's 14 days old or older; we only remove mail 14 days > after we first downloaded from the server. OK, you got me thinking... I went back and checked. With VERY MUCH A RED FACE I must admit I got it wrong. I have a habit of looking at the 'Unread Messages' in my Inbox, and I usually have a bunch lying around 'Unread'. After a TB fetch there were zero there. I thought they had got deleted. - But it is these "Unread messages" that I thought 'disappeared'. - But they didn't get deleted, they became "'read' messages" after the fetch by TB. So they were still there all along... Just now marked as read. Oops. MUCH APOLOGIES for the rant and confusion. I suppose that means I have 14 days to change the setting before it starts to delete? That's probably a reasonable compromise. (A warning somewhere along the line, possibly at install time, might be nice though...) Sorry, and thanks again.
(In reply to comment #31) > I suppose that means I have 14 days to change the setting before it starts to > delete? That's correct. > That's probably a reasonable compromise. (A warning somewhere along the line, > possibly at install time, might be nice though...) Yes, I think a warning at account setup time would be reasonable as well. I'm glad your mail is still on the yahoo server.
New TB 3.1.1 POP profiles default to https://bug580607.bugzilla.mozilla.org/attachment.cgi?id=458991 This has caused many users to lose alarming quantities of mail. Please remove the following ticks from default settings; 1 - For at most 2 - Until I delete them Also remove the 14 and keep the box empty. Eudora used to do something similar but it was much easier (for those who knew about it) to change the settings before any damage was done. The existing defaults have been upsetting large numbers of prospective TB users.
Neville Hillyer, I don't understand the problem. We default to IMAP, where available. For POP3, it has always been the default to fetch and delete from server at the same time. In fact, that's how POP3 is supposed to work, and always did. The fact that we now wait 14 days until we delete is new. As bienvenu said before, POP3 will not work efficiently when the mails are never deleted from the server, it's just not made for that. That's why we have this bug: To warn users and make them aware of what will happen.
These unfortunate defaults have destroyed too much user data to allow them to continue - see comment 29. My understanding is that it does not wait 14 days but immediately deletes everything more than 14 days old. Many POP servers are reasonably efficient with 10,000 messages stored on the server. Some users may use a combination of POP, IMAP and web-mail clients with the same server. They do not want their large web or IMAP inboxes reduced by a POP access. I am POP only and access via two different computers. My normal leave on server setting is 122 days (4 months). As long as I use each computer at least every 4 months one acts as a backup of the other. The replication is completed by an automatic bcc to myself of every outgoing message.
(In reply to comment #36) > My understanding is that it does not wait 14 days but immediately deletes > everything more than 14 days old. That's completely false.
(In reply to comment #36) > These unfortunate defaults have destroyed too much user data to allow them to > continue - see comment 29. See also comment 31. The issue wasn't dataloss but rather just confusion about what happened (the messages were marked as read and so no longer showed up under "unread message").
Thanks Jim - I had missed that. However I have had difficulties with this setting before with some servers. Where is the operation defined? Leave on server for 14 days from when? I would still prefer TB to be more POP friendly both for account setup and safety of defaults. I was once told that TB defaults were selected on the basis of 'do no harm'.
(In reply to comment #39) > Thanks Jim - I had missed that. > Leave on server for 14 days from when? From when Thunderbird first downloads the message. If we deleted a message right after we saw it, I don't think that could be described as leaving it on the server at all.
(In reply to comment #39) [...] > I would still prefer TB to be more POP friendly both for account setup and > safety of defaults. I was once told that TB defaults were selected on the basis > of 'do no harm'. Neville, there is no single default policy which no one will ever regard as harmful. Peter G. (of comment #31) had ten years of mail left sitting on a POP server and complained when they disappeared. Me, I get all my mail by POP, and yesterday I kept my computer off the Internet for less than one day (maybe fourteen hours or so) in order to install the new openSUSE Linux release 11.3. When the upgrade was done and I started my mailer again, I found out that more than 120 messages were already waiting for me on the POP server. I can't even imagine what would have happened if I had gone ten years rather than just fourteen hours without removing the waiting messages. Most of them would have been refused for "mailbox full", most probably, which would mean I would have lost them forever; and some of my contacts (including mailing lists etc.), noticing that I was apparently not reading my mail anymore (since they were getting bounces saying the mailbox was full) might even have taken me off their address books entirely. Thunderbird is already making people a favour by leaving their mail on the POP server for 14 days by default rather than zero which is the norm. Remember, an account on a POP server is supposed to be like a mailbox: it is just a maildrop, it has a finite volume, you fetch your mail from there to the inside of your home to read it, and you never bring it back to the box for safekeeping. On the other hand, an IMAP account (or in most cases a webmail account) is like a desk (or a cubicle nowadays ;-) ) at the office: you read your mail there, dump some of it (e.g. crackpot letters) into the trash there, classify the rest into several drawers or folders right at the office (= on the server), and only rarely if ever bring any of that mail home.
Life has moved on since the original POP3 RFC. I have used POP for about 20 years and have always left mail on the server for long periods - although recently only 122 days. I only noticed it was slow when I had over 20,000 messages about 10 years ago. I don't expect to ever fill a mailbox and am surprised that others use servers or OSs where this can happen. There are far less harmful defaults which TB could use and I will continue to press for these. Would mail be lost by the default delete from server if, as often happens, duplicates are downloaded and then deleted? What happens when multiple POP clients, with different leave on server times, access the same server? Can anybody point me to a full accurate description of the interactions between clients and server in this situation? Has anybody investigated using TB code to produce a slim, friendly, safer POP only client?
> Life has moved on since the original POP3 RFC. But the POP3 protocol has not. But the IMAP protocol has been created. If you use an ISP that doesn't offer IMAP, that's not our fault. Chose a different ISP. Simple. You argument for a different default is offtopic here. You are in violation of the bugzilla etiquette <https://bugzilla.mozilla.org/page.cgi?id=etiquette.html>, section 1. Please stop or you may be sanctioned.
Please do not mark bugs that ask for a different default as dups of this bug. We'll get things like comment 34-43 here. Just WONTFIX them.
(In reply to comment #43 and comment #45) What is the reason for the rudeness here? As a convinced IMAP user I'm neutral to the topic of discussion, but since you are citing bugzilla rules, I think that neither Ludo nor yourself are technically in the position to WONTFIX a bug, this power is reserved for module owners and their peers. While Neville might have been off-topic here and shouldn't have re-filed his original bug, it appears to me that bug 580607 was incorrectly closed. There are enough authorized people here in the cc list to verify and decide on that, but IMHO review and ownership rules in general have become rather fuzzy lately. And, sorry for being off-topic myself. :-)
rsx, I don't see where I was rude, in fact my comments were entirely rational.
Sorry for comment 43 - at that time, I didn't realize that the other bugs with a different request were DUPed here, which caused the offtopic comments.
This was prompted by the "in violation of" hammer. And yes, the bug was duped before it was won't-fixed, so that discussion in question was inbetween.
Could all the discussion here on the default not be short circuited simply by opening the server settings pane at the conclusion of the new account wizard? The valid complaint is that the user does not know. By leaving them in the server settings they will have to make a conscious decision to close the pane. Whilst people are more than capable of not seeing what is staring them in the face, (I am guilty), from a user support perspective at least we can say we tried to bring it to their attention. Leaving them in account settings would have the added bonus that they might look at some of the other settings in there.
What about showing a non-modal notification notifying the user X messages are older than Y days and are schedulded to be deleted with Delete and Edit Settings buttons?
I am hopeful that the following principles will eventually prevail: 1 - Do no damage 2 - Retain maximum flexibility by refraining from unnecessary hard coding Recently proposed patches by Yarny and myself provide more flexibility for POP account creation for recent versions of TB - see: https://bugzilla.mozilla.org/show_bug.cgi?id=798932#c28 I have difficulty seeing how to best provide ultra safe defaults (I prefer never delete from server and do not login at start-up) and at the same time give inexperienced users a satisfactory instantly working client.
"dataloss" key word?
(In reply to Worcester12345 from comment #55) > "dataloss" key word? Nevermind. Sorry.
Can anybody tell me if there is likely to be any progress with this bug? My mail provider has IMAP, POP3 and web access but I prefer to use POP3 for all my email.
(In reply to Neville Hillyer from comment #57) > Can anybody tell me if there is likely to be any progress with this bug? Past history is pretty much your only predictor. Always subject to change. There are more issues to fix than there are people with time available to fix them. So it effectively depends on whether someone with the skills simply takes an interest and invests the time
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: