534628 - Implement intelligent "leave messages on server" default settings for POP3 accounts, based on storage quota size on server

Status: NEW

(Thunderbird :: Account Manager, defect)

Description

[Thomas D. (:thomas8)]

Followup from Bug 231541 - "Leave messages on server" should be chosen by default (dataloss); related: bug 531092 and bug 531088.

In bug 231541 comment 112, David Ascher proposes to implement more intelligent default settings for "leave messages on server" with POP3 accounts, based on the available storage quota size of each ISP:

> Talking to bryan about it, something that could help mitigate some of these
> issues is to enrich the ISPDB config database to mark specific ISPs that we
> know have very large POP quotas (Yahoo, Google, etc.) as such, and to turn off
> this pref for those ISPs.  For older ISPs with small quotas, we could also
> consider enriching the ISPDB config with quota information ("this ISP provides
> 100Mb of storage"), thereby providing us out-of-band information about the
> limits of specific accounts that POP can't provide.


STR
1) set up a web.de POP3 account (12 MB server storage quota)
2) set up a googlemail.com POP3 account (7+ GB server storage quota, growing)

Actual behaviour

for 1) and 2)
- regardless of the available quota, we currently use the following default settings for POP3 accounts: 
[x] Leave messages on server
    [x] for at most 14 days
    [x] until I delete them
- but we don't communicate these settings, which can cause unexpected dataloss on server after 14 days (bug 531092 and bug 531088). Especially for servers with small quota, "leave messages on server" for good would also cause dataloss as the mailbox might fill up.

Expected behaviour

1) accounts with small quota
- use default settings as above (leave on server, delete after 14 days or if deleted)

2) accounts with large quota
- use better (less destructive) default settings (leave on server for good):
[x] Leave messages on server
    [ ] for at most 14 days
    [ ] until I delete them

We'd still need to educate the user about this, but it's less prone to unexpected dataloss.

I'll post a separate bug for the groundwork needed for this bug:
Add server quota information to ISPDB account setup config database

Comment 1

[Thomas D. (:thomas8)]

(in reply to commment 0)
> I'll post a separate bug for the groundwork needed for this bug:

Bug 534629 - Add server quota information to ISPDB account setup config database

Comment 2

[Jean-Marie COUPRIE]

An email address has a limited life due to the fact that sooner or later it become known to spammers and you abandon and replace it by a new one (unpleasant and long process for you and your contacts). Small address providers or ISP disappear also and new ones give a big quota (1 GO. or more). So addresses with small quota should not be the general case (and are not my personal case !).

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) for this particular option : if possible test, when accessing the server, the %age of quota used and give a warning above 75%.
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.