531092 - Need release note warning (and improve help documentation) for destructive POP3 default setting "Leave messages on server for at most [14] days" or "until I delete them"

Status: VERIFIED WONTFIX

(Thunderbird :: Help Documentation, defect)

Description

[Thomas D. (:thomas8)]

For the problems explained in bug 531088, we really need a WARNING in the Release Notes and probably also help documentation how to change these settings according to the user's needs. We have all reason to assume that the number of users who are accessing their mail from multiple locations is growing, that most email accounts come with a lot or even unlimited space, and therefore many people will want to keep their mail in the server's inbox.

From my own experience as an advanced user, I can tell that Thunderbird Shredder 3.0 pre recently deleted hundreds of messages from my server's inbox because I forgot to change the default settings. I wasn't amused.

Please change components appropriately for the Release Notes.

> 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 tb 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

Comment 1

[David :Bienvenu]

The TB drivers decided not to release note this. Relnotes tend to be for bugs and things we intend to fix. In 2.0, we would delete everything from your inbox when you set up your pop3 account in the wizard, so 3.0 is much friendlier. Other apps behave the same way. I can see adding it to the online help documentation, but we're not going to block 3.0 on that...

Comment 2

[Michael A. Pasek]

Wholeheartedly agree with Thomas D (Description).  The effects of DELETING a user's mail from the server are significantly greater than not deleting it (i.e., filling up allocated space).  For the latter case, the user can just delete unwanted messages to free up space (after ensuring they've been locally archived where he/she wants them).  For the former, there's no way to get the messages back on the server in their original condition.

Rather than trying to come up with a one-size-fits-all "default" setting, how about attempting to educate the users who don't understand these settings, while not destroying the environments of those who do ?

Comment 3

[Tony Mechelynck [:tonymec]]

(In reply to comment #2)
> Wholeheartedly agree with Thomas D (comment #0).  [...]
I don't. See bug 531088 comment #3 for an explanation.

Comment 4

[Thomas D. (:thomas8)]

Bug 531088 comment 3 doesn't apply, because it ignores the main problem (see bug 531088 comment 4). Instead, it provides a selected and incomplete set of specific use cases, with the intention of supporting certain default settings. In fact, some of the use cases actually call for "leave messages on server for ever". But this bug is NOT about *changing* the defaults. It's about making them transparent, thus predictable and less dangerous. This bug is about preventing unexpected dataloss.

(In reply to comment #1)
> The TB drivers decided not to release note this. Relnotes tend to be for bugs
> and things we intend to fix.

As long as we have non-transparent destructive settings, there should be a relnote for this. It's a bad excuse for deliberately letting users run into dataloss. When the complaints come (they will, even if most might not make it into bmo), don't tell me I haven't told you.

In the long run, you are right: If we change the behaviour (warn, inform, provide customization etc.), a relnote will no longer be needed.

> In 2.0, we would delete everything from your inbox
> when you set up your pop3 account in the wizard, so 3.0 is much friendlier.

Not friendly enough. Delayed dataloss is still dataloss. It's a bit like saying "Aren't we friendly, now that we silently give you 14 days to run away before ambushing you without notice".

> Other apps behave the same way.
As an OSS, we should be better and more transparent than other apps.

> I can see adding it to the online help documentation
Please do!

Comment 5

[Michael A. Pasek]

Thomas' comment #4 "collided" with mine when I tried to save it; copied and pasted.

(In reply to comment #3)
> I don't. See bug 531088 comment #3 for an explanation.

See Thomas's comment #4 for a rebuttal.  Thomas is right on this one; different users have different needs, and a destructive "default" setting (DELETE from server) -- as opposed to just a potentially troublesome one (LEAVE on server, server fills up) -- is not something good software should do.

There is a fourth possibility in the list of "IF"s in comment #3 in bug 531088:  You may want to leave messages on the server that can be accessed from ANY email client, on ANY computer, then deleted from that computer without deleting from the server.

This would really be a moot point if the user had:
  a) an indication of whether the email exists on the server;
  b) a method of deleting individual emails without deleting them automatically
     or having to throw them in the trash (and then retrieving them and filing 
     them where you want them after they've been deleted from the server).

The other option, as I suggested in the last paragraph of comment #2, would be to allow the user to choose the setting in the account wizard -- with some sort of "Help" buttons (or links to external sites) to explain what the benefits/pitfalls of the possible settings are, for those who DON'T know.  

I'll be the first to acknowledge that keeping a lot of emails on a POP server is not necessarily a good idea.  I run my own server, on some OLD hardware; I once let 18,000 emails accumulate, and it took the poor server 15 minutes just to log me on!!

> Other apps behave the same way.
That's one of the reasons I still use "classic" Eudora, and am looking at (and trying to help) Thunderbird/Penelope; all the other email apps behave the same way -- they presume to know better than you what you'd like to do.

The real points, I think, are: 
  a) this should be the USER'S choice, not the developer's;
  b) if you must choose a default, choose one that is NOT destructive.

Comment 6

[Ludovic Hirlimann [:Usul]]

(In reply to comment #5)

> See Thomas's comment #4 for a rebuttal.  Thomas is right on this one; different
> users have different needs, and a destructive "default" setting (DELETE from
> server) -- as opposed to just a potentially troublesome one (LEAVE on server,
> server fills up) -- is not something good software should do.

I'll have to disagree here. If you feel up the mailbox , you get a dataloss which is worse than the one we want to avoid. If I download and delete 14 days after the download occurs, I have 14 days to download on other machines etc.
If we do not delete and the POP box goes full, the user will have a dataloss worse as he won't even get the chance to get at least a local copy of the email.

Comment 7

[Thomas D. (:thomas8)]

Ludovic, you're right. But that's not /disagreeing/ with what has been said before, that's just pointing out that there's dataloss *on both ends*. We're not primarily arguing to change the default, but what we really need is more *transparency* and *safety* for the current default. (Although as David A suggested, changing the default to "leave on server" for servers with known large quota might be another good idea, but it's still not an alternative to addressing this bug).

> I have 14 days to download on other machines etc.

No, because the user doesn't even know that we delete after 14 days, and we don't warn. So users who want to keep their mails on server will initially just see that the mails are still there, and they have no reason at all to rush into downloading on other clients. And again, that's not the point. I want *all* my messages on the server so that I can read them from *any* client, from a hotel's terminal in Prague or wherever I happen to be, and I want all the messages from this year, not just the last 14 days.

It doesn't help and it's not really possible to say which kind of dataloss is "worse". E.g. for many users the "full mail box" scenario will never occur because they have enough server quota. For those, dataloss on server after 14 days might be much worse. But let's stop discussing that sort of thing, the problems are out on the table, what we're looking for is *solutions* to improve the current state of affairs.

Solutions are:
- Relnote (until such time that we've made the behaviour more transparent)
- and help documentation
- making the behaviour more transparent (bug 531088)
   a) inform during setup and/or
   b) implement UI for changing the settings during setup and/or
   c) warn and confirm before first delete from server

Comment 8

[Michael A. Pasek]

I had a much longer comment which, once again, happened to "collide" with comment #7 -- which makes the most important point:  There are arguments for "keep" and arguments for "delete", and both are valid; the real problem is that the choice is not transparent.  

"a" and "b" of possible solutions are doable; "c", I think, would be difficult and likely to introduce more bugs than it fixes.

Comment 9

[Roland Tanglao needinfo please :rolandtanglao, :mohnkuchen, :adobo, :sinigang, :roland]

:jenzed could you please update the following SuMoMo articles to highlight that POP email on the server will be deleted after 14 days for new accounts created in Thunderbird 3:
1. http://support.mozillamessaging.com/en-US/kb/New+in+Thunderbird+3
2. http://support.mozillamessaging.com/en-US/kb/FAQ+Upgrading+Thunderbird+2+to+3

Comment 10

[jenzed]

notes added to both the sumomo pages listed in comment #9.

Comment 11

[jenzed]

The doc has been added, so, as far as the "Help Documentation" component is concerned this bug is closed. If it needs to be reopened, please assign to another component.

Comment 12

[Michael A. Pasek]

It is unlikely that many people are going to see the "Help" note in the KB _before_ their email has been deleted.  This bug should be reopened and reassigned to the appropriate "component" to do the "Need release note warning" part.  Now that the second part ("help documentation") has been done, the Release Note can link to that documentation.  The warning in the Release Notes should be in the "Known Issues" section, until Bug 531088 is RESOLVED/FIXED (if any other close code, warning should stay in Release Notes).

Jen (as the last assignee) or Thomas D (as the original reporter), will you please re-open and assign to the correct "component" ?  (I'd do it, but I have no idea which "component" is the correct one)

Comment 13

[Thomas D. (:thomas8)]

(In reply to comment #12)
> It is unlikely that many people are going to see the "Help" note in the KB
> _before_ their email has been deleted.  This bug should be reopened and
> reassigned to the appropriate "component" to do the "Need release note
> warning" part. Now that the second part ("help documentation") has been done,
> the Release Note can link to that documentation.  The warning in the Release 
> Notes should be in the "Known Issues" section, until Bug 531088 is
> RESOLVED/FIXED 

Absolutely. No normal user is going to find these warnings in time where they currently are. I agree that this should have a release note warning in the "Known issues" section. Which is still insufficient, but perhaps more likely to be read _before_ user installs. Deleting user data from server without any warning or upfront information during account setup is a dataloss issue, which is clearly an issue (even though it's intended as a feature, and even though we are doing better than before).

-> reopening for different component (General), as recommended by jenzed's comment 11 when he closed it for the "help documentation" component.
- What is the correct component for "needs release note"?

> Now that the second part ("help documentation") has been done

Jenzed, I have a few suggestions to improve the help docu about this issue:

http://support.mozillamessaging.com/en-US/kb/New+in+Thunderbird+3#Accounts

We should make it visually easier to find this important information:
- apply font-weight:bold to the topic and the important content of this paragraph (as you've done in the first paragraph about Mail Account Wizzard):
"o When *new POP accounts* are created, by default *messages on the server are deleted after 14 days*. To change this setting..."
- move this important information further up in the list, first or second position, which is also more coherent as it will go together with mail account setup wizard information, like this:

o Mail account setup wizard: new!
o New POP accounts: message deletion from server after 14 days
o IMAP accounts: offline folders now enabled by default
o Signatures: now created on Account Settings page

While I a m at it, it's strange that the menus and steps are bold, while the main topic and the main message of most of these paragraphs isn't. I'd recommend to put what I have in the bulleted list above in bold print, or dark-blue, or whatever, perhaps find some other format/color for the menu titles etc which are currently bold, but that information (how to get there?) is meaningless without knowing the topic (what is it about?).

Similarly for the other page:

http://support.mozillamessaging.com/en-US/kb/FAQ+Upgrading+Thunderbird+2+to+3
- apply formatting to make the actual topic of the paragraph more visible (all other paragraphs actually have the topic in red, because it's a link)
- move pop3-server-deletion paragraph up in the list, at least one up so that's it's paired with the paragraph about "Automatic Account Configuration"

Comment 14

[Mark Banner (:standard8)]

Removing relnote keyword from bugs that are no longer significant or not needing to be mentioned in the release notes.

Comment 15

[Matt]

I see no point pursuing this topic. Things discussed here are a decade old so user expectations are no longer what they were.

Comment 16

[Wayne Mery (:wsmwk)]

bug 531088 adequately covers the UI issue.