Open Bug 689067 Opened 13 years ago Updated 2 months ago

Ability to disable an IMAP account without losing e-mail

Categories

(Thunderbird :: Account Manager, enhancement)

Product:
Thunderbird
Component:
Account Manager
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: robrwo, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

(Whiteboard: [gs]) 

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20100101 Firefox/6.0.2 Iceweasel/6.0.2
Build ID: 20110906090041

Steps to reproduce:

I have IMAP accounts from former jobs or old accounts. Thunderbird cannot connect to the sites, and so the e-mails have been lost, even though offline copies have been enabled.


Actual results:

Enabled offline copies. Accounts have been disabled from leaving jobs, etc. Tried changing the server to a non-existent server name. 


Expected results:

There should have been an option to mark the account disabled so that TB does not try to download mail, even when clicking on the folder. And the e-mails should not disappear from the folders.
Thunderbird doesn't delete messages if it can't access the server.  So it's not clear to me that you have lost offline messages, or if you did lose some, how that happened. So you'll need to give more information.

For example, at _exactly_ what point did the messages go away?
and do you have retention settings on the folders of the account?

----
xenos, Matt, have you see anything like this on gfsn? 
I saw either another bug report like this or a topic on getsatisfaction - about wanting to be able to totally disable an account (eg stop from ever checking for new mail).
Severity: normal → enhancement
Summary: [RFE] Ability to disable an IMAP account without losing e-mail → Ability to disable an IMAP account without losing e-mail
Whiteboard: [dupeme?]
I have tagged the couple of GS topics I have been involved in the seek to disable an account (not necessarily IMAP) with this bug and updated the Bug URL to GSFN.

Regardless of the problem that spawned this bug, a simple interface to disable an account for all send receive and sync functions is long over due.  Unless someone locates an existing bug for this type of enhancement I will vote for this one. 

Robert Rothenburg:  Have the accounts been deleted from Thunderbird because the error messages were sending you nuts?
URL: http://getsatisfaction.com/mozilla_me...
(In reply to Robert Rothenberg from comment #0)
> Steps to reproduce:
> I have IMAP accounts from former jobs or old accounts. Thunderbird cannot
> connect to the sites, and so the e-mails have been lost, even though offline
> copies have been enabled.
> Actual results:
> Enabled offline copies. Accounts have been disabled from leaving jobs, etc.
> Tried changing the server to a non-existent server name. 

If all IMAP data is already sync'ed(data of all mails are downloaded into offline-store) by your "offline copies have been enabled", you can copy IMAP mail data to other local mail folder(folder of "Local Folders", real POP3 account, dummy POP3 account) without server access, if you execute copy operation while "Work Offline" mode.
Note:
If server is still accessible even after an IMAP account is dead, and if the "account is dead" is "login is still possible, but all folders are killed at server", it is same as "IMAP folder is deleted at server" for Tb. So, once server connection is established after the "account is dead", all mail header data in .msf file is cleared and all mail data in offline-store is lost.

> Expected results:
> There should have been an option to mark the account disabled so that TB
> does not try to download mail, even when clicking on the folder. 
> And the e-mails should not disappear from the folders.

If "account is dead" is "server access is impossible any more", "per account or per folder Work Offline mode" can be a solution of your case. IIRC, "per account or per folder Work Offline mode" is already requested enhancement.

To Robert Rothenberg(bug opener) and Matt:
Does "per account Work Offline mode" fulfill your requirement?
(In reply to Matt from comment #2)
> I have tagged the couple of GS topics I have been involved in the seek to
> disable an account (not necessarily IMAP) ...snip

If POP3 account, there is very simple way:
  Change server name setting to non-existent one such as xxx.yyy.zzz.
(i) by server name change to non-existent one, connecting to the dummy server is impossible, thus login of the POP3 account fails.
(ii) because login fails, automatic mail check is impossible, even if you keep settings for "automatic mail check" enabled.
Please note that Tb doesn't prohibit dummy POP3 account creation with dummy/non-existent POP3 server("Manual Setup" is already provided). So, you can have many dummy POP3 accounts as "local mail folder keeper" like "Local Folders". If POP3 account at server is dead or killed, "change POP3 account on Tb to dummy POP3 account" is usually sufficient to keep already downloaded mails.

In order to disable "POP3 server access when Get Msgs", enhancement like "an option to mark the account disabled" or "per account Work Offline mode" is needed.
"[?] Include this server when getting new mail" of Server Setting/Advanced is option only for POP3 who uses "Globol Inbox". If this option is available for ordinal POP3 account or IMAP account, it may be usable to disable "server access even when Get Msgs".

In order to disable "mail send/news post using identities(mail addr usable as From:) associated to POP3/IMAP/NNTP account", enhancement like "an option to mark the account disabled" is needed. However, I think "deletion of identity" or "change of mail addr in identity setting to non-existent one" is sufficient, if mail address assigned to killed mail/news account is not reachable any more.
didn't find a duplicate.
=> account manager, for lack of a better place
Status: UNCONFIRMED → NEW
Component: General → Account Manager
Ever confirmed: true
Whiteboard: [dupeme?]
Maybe some of the "make offline mode be per-account" bugs would be a solution for this.
Depends on: 312619
Whiteboard: [gs]
Blocks: 312619
No longer depends on: 312619
Why isn't this a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=312619 ?
And why is it blocking that bug/feature request?

It should rather be the other way round, if it's not even the same bug.

Also in bug #312619 it is requested that (IMAP) mail server access can be selectively turned on/off for single accounts. Same here. So this seems like a duplicate.

(Regarding the "lost" emails in comment #0, this indicates a misconception on how IMAP works.)
OS: Linux → All
Hardware: x86_64 → All
Hello,

Please is there any plan to implement this feature ? Having frequent pop-up windows asking the password for IMAP accounts that should be read-only is really a nuisance.

Many thanks
Why nothing gets done about this? 9 to 10 years old? Many users requesting?
As a work-around, I changed the imap server to example.com and that seems to prevent thunderbird from trying to ask for a password. Not optimal, since it seems it still tries to connect, which slows down things a bit, but at least no errors or dialogs so far.
(In reply to fscussel from comment #11)
> Why nothing gets done about this? 9 to 10 years old? Many users requesting?

Because Thunderbird is a very large app with very few part-time unpaid developers and many users reporting bugs and asking for features. The only solutions are to convince more developers to help (but how?) and hope that they will eventually fix your bug, find a way to pay developers to work on Thunderbird for a living (but who pays how much for what?), or get your hands dirty and fix it yourself (but most people don't have the time, knowledge or patience to do this).
Another user requesting the option to disable an account to prevent login information being requested, or pinging the dead server.
Fix this please.
yes, you *can* dummy up an account by editing the hostname (POP3 or IMAP) with a bogus value, but it is the sort of hack people shouldn't have to do.  It also pops up an error message that Thunderbird couldn't contact the server, and that looks more like a program failure.  Not very friendly.

In my particular case I have an email account that *used* to be POP3, but then they enabled IMAP, which I switched over to.  I didn't want to have to upload all my old emails *back* to the IMAP server, and the POP3 mail is basically an archived copy.  But I still want to keep it where it is, and don't want to move it into "Local Folders" (already have too much "archive" mail there).

It seems a simple "do not check this account" checkbox (call it "Disabled Account" or "Archived Account" would serve for both people keeping old accounts no longer accessible, as well as allowing someone to temporarily disable an account.  Two different usage scenarios handled by one addition of functionality.
I will add another voice respectfully requesting the enhancement to allow an IMAP account to be disabled and enabled, yet retain the already downloaded emails, without needing to resort to methods such as editing the js.pref via about:config or deliberately adding invalid information to server settings.

In my case, for the accounts I wish to disable temporarily (or even permanently, but retain emails), I edit the hostname in the account settings to add ".invalid" (without speech marks) to the end of the hostname, as any fully qualified domain name that terminates with the string ".invalid" is 'guaranteed not to exist', as per RFC 6761 section 6.4.1 (Users MAY assume that queries for "invalid" names will always return NXDOMAIN responses.). As a result, the hostname lookup should fail quickly and not impose unwanted loads on the network.

6.4.  Domain Name Reservation Considerations for "invalid."

   The domain "invalid." and any names falling within ".invalid." are
   special in the ways listed below.  In the text below, the term
   "invalid" is used in quotes to signify such names, as opposed to
   names that may be invalid for other reasons (e.g., being too long).

   1.  Users are free to use "invalid" names as they would any other
       domain names.  Users MAY assume that queries for "invalid" names
       will always return NXDOMAIN responses.

   2.  Application software MAY recognize "invalid" names as special or
       MAY pass them to name resolution APIs as they would for other
       domain names.

   3.  Name resolution APIs and libraries SHOULD recognize "invalid"
       names as special and SHOULD always return immediate negative
       responses.  Name resolution APIs SHOULD NOT send queries for
       "invalid" names to their configured caching DNS server(s).

   4.  Caching DNS servers SHOULD recognize "invalid" names as special
       and SHOULD NOT attempt to look up NS records for them, or
       otherwise query authoritative DNS servers in an attempt to
       resolve "invalid" names.  Instead, caching DNS servers SHOULD
       generate immediate NXDOMAIN responses for all such queries.  This
       is to avoid unnecessary load on the root name servers and other
       name servers.

   5.  Authoritative DNS servers SHOULD recognize "invalid" names as
       special and handle them as described above for caching DNS
       servers.

   6.  DNS server operators SHOULD be aware that the effective RDATA for
       "invalid" names is defined by protocol specification to be
       nonexistent and cannot be modified by local configuration.

   7.  DNS Registries/Registrars MUST NOT grant requests to register
       "invalid" names in the normal way to any person or entity.  These
       "invalid" names are defined by protocol specification to be
       nonexistent, and they fall outside the set of names available for
       allocation by registries/registrars.  Attempting to allocate a
       "invalid" name as if it were a normal DNS domain name will
       probably not work as desired, for reasons 2, 3, 4, and 5 above.

While this is an ugly hack, it retains all account information and is easily reversible.

For me, the ideal would be a toggle to turn the account on and off, such that if/when I deliberately choose to work offline, the offlining process does not need to query the servers of the disabled accounts when I opt to do a final download of mails before Thunderbird goes to offline processing. Note that the accounts should still appear in the drop-down menu of "Get Messages", and generate an informational message that the account is currently disabled if explicitly selected, and optionally give instructions on how to re-enable the account.

I realise this is not a high priority issue, but given the number of 'solutions' that turn up when searching the Internet for information about this topic relating to Thunderbird, it seems to be a relatively common request.

Unfortunately, this is not an itch I can scratch myself, so I can only hope a suitably qualified Thunderbird developer/maintainer has the interest and time to do this.

Thank-you for your time.

BVF

While the ".invalid" extension to the domain name may make the URL invalid, that does NOT make TBird stop trying to download from the email account. Not only is this a bad hack, it also doesn't work right anyway. I suppose you could look at host names when doing a mail check, and if the server name ends in ".invalid" you could just skip checking that account and move on to the next. But as it is, you still try connecting to an invalid address, and still return an error.

For that matter, if I even do something as simple as click on the 'Inbox' for an account marked with the .invalid, TBird will STILL try to check the account, and I notice it will try looking it up with the hostname WITHOUT the .invalid extension. So it isn't even handling the invalidated hostname correctly.

James,

can you confirm that you are adding '.invalid' to the end of the server name in the 'Server Name' field of the 'Server Settings' page when modifying account settings, and NOT just adding '.invalid' at the end of the account name in the 'Account Name' field on the 'Account Settings' page?

The Account Name is cosmetic. It will not affect the behaviour of the Thunderbird Client. You can set it to anything you like.
The Server Name field is what the client uses as the string to look up in DNS.

The behaviour you describe appears consistent with modifying the Account Name rather than the Server Name. I have checked with Wireshark on my system that when the server name is terminated with '.invalid', no query is sent to the DNS server for that string (although in my case it does try to look up a string terminated with '.invalid.lan', which, of course, fails.

This feature request addresses only a part of a bigger problem. The ultimate solution would be some sort of snapshots.

(In reply to bugzilla.via.forwarder from comment #20)

can you confirm that you are adding '.invalid' to the end of the server name in the 'Server Name' field of the 'Server Settings' page when modifying account settings, and NOT just adding '.invalid' at the end of the account name in the 'Account Name' field on the 'Account Settings' page?

I had thought that as well, so I had checked the IMAP hostname and confirmed it is correctly set with the .invalid extension. Still getting the popup error message.

under the "Server Settings" page for the old email account:

Server Name: imap.bestweb.net.invalid Port: 143

Now, just out of curiosity I looked at what it has in the prefs.js file. Apparently any server I have tried to disable now has two hostname entries:

user_pref("mail.server.server5.hostname", "imap.bestweb.net");
user_pref("mail.server.server5.realhostname", "imap.bestweb.net.invalid");

yet there's only one place in the settings screen to edit the hostname (which is the one showing up in prefs.js as "realhostname")

(In reply to James E. LaBarre from comment #22)

mail.server.server%.realhostname corresponds to the fully qualified domain name* of the server which hosts the account.

I was incorrect in saying the account name is cosmetic: it is the string passed to the email server to identify your account on the server, and so should not be modified. It is stored in mail.server.server%.name

mail.server.server%.hostname is used to identify the directory on your computer where mail for the associated account is stored.

If you look under SERVER settings at the 'Local directory', you will see the mail.server.server%.hostname used there. It shouldn't be changed in prefs.js

Having just checked with Wireshark, if you terminate the realhostname (which is the 'Server Name' in 'Server Settings') with '.invalid.' - that is with a final trailing dot, Thunderbird correctly does not send out a DNS query for <realhostname>.invalid.lan as the trailing dot indicates that the string is a fully qualified domain name, and not a relative domain name.

If I then move focus to a valid account and select 'Get All New Messages' from the Get Messages drop-down button, I do not get any error pop ups. If I select 'Get Messages', messages are downloaded for the account. If I move focus to disabled account and select 'Get All New messages', no error pop-ups are generated, but if I select 'Get Messages', I get an error pop-up for the account in focus.

As a result, I recommend disabling an account by adding a trailing '.invalid.' on the 'Server Name' in 'Server Settings'. Note the final dot. This stops Thunderbird sending out any DNS queries for the disabled account, and so long as the account is not in focus, for me at least, no error pop-ups are generated when I select 'Get All New Messages' at any time, or when I select 'Get Messages' when a valid account is in focus. It looks like very good practice for Thunderbird to give an error when 'Get Messages' is selected while an disabled account is in focus.

*I have not put the final dot on the FQDN of the server. It works for me without it. Having checked, it also works with the final dot that is, '.invalid.'.

Interesting theory, I thought it sounded reasonable. I tried adding the dot to the end of .invalid, and it still doesn't work right. I click on the old inbox for the retired account, and it still gives me the error popup.

So rather than continuing to do hacks that aren't working anyway, should just add a function already to mark an account as disabled, so that TB doesn't even bother looking to the server for it. It's been on the requested list for 15 years now, longer than my daughter has been alive. It's kind of like the "email scams" checker.

Someone high up the food chain has decided this is not necessary because they never needed it. It should not be hard to implement, just a checking of check this account or don't check it. In my case it is not IMAP but pop3. Only one machine needs to check most of the time, but my wife wants to refer to the old files on a more convenient main computer.

(In reply to James E. LaBarre from comment #24)

Interesting theory, I thought it sounded reasonable. I tried adding the dot to the end of .invalid, and it still doesn't work right. I click on the old inbox for the retired account, and it still gives me the error popup.

So rather than continuing to do hacks that aren't working anyway, should just add a function already to mark an account as disabled, so that TB doesn't even bother looking to the server for it. It's been on the requested list for 15 years now, longer than my daughter has been alive. It's kind of like the "email scams" checker.

Well, <it works for me>(TM). If you select the inbox of a retired account* and click on 'Get messages', it generates the error**. If you select the inbox of an active and working account and select 'Get Messages or 'Get All New Messages', I get no error pop-up. Why this is apparently different for you, I don't know. I hope you find a solution that meets your requirements.

*An account where '.invalid.' is added at the end of the domain name in the 'Server Name' field of the 'Server Settings' page of 'Account Settings'.

**It also does not generate a DNS query (as confirmed with Wireshark), which is good. So it appears that the code that Thunderbird (on Linux) uses to resolve the IP address from the server name is intelligent enough to recognise a FQDN terminating in .invalid. and behave as though an NXDOMAIN has been received. From a security POV, this is good behaviour, as using another nonexistent domain is susceptible to someone registering that domain and emulating a mail server thereby fooling your client into giving up your account name and possibly other information when your client attempts to log in to the server. The code (on Linux) never even sends out a DNS query.

(In reply to bugzilla.via.forwarder from comment #23)

I was incorrect in saying the account name is cosmetic: it is the string passed to the email server to identify your account on the server, and so should not be modified. It is stored in mail.server.server%.name

NO, account name should never be sent to any server. If you have proofs otherwise, please file a new bug.

mail.server.server%.hostname is used to identify the directory on your computer where mail for the associated account is stored.

Correct.

If you look under SERVER settings at the 'Local directory', you will see the mail.server.server%.hostname used there. >It shouldn't be changed in prefs.js

But you can change this directory to any other path and then it may not contain mail.server.server%.hostname.
mail.server.server%.hostname is used to internally reference the account/server, but is not tied permanently to the path of the local storage.

(In reply to bugzilla.via.forwarder from comment #20)
Now, just out of curiosity I looked at what it has in the prefs.js file. Apparently any server I have tried to disable now has two hostname entries:

user_pref("mail.server.server5.hostname", "imap.bestweb.net");
user_pref("mail.server.server5.realhostname", "imap.bestweb.net.invalid");

This is correct. mail.server.server5.hostname will be used as the server hostname to contact, but if mail.server.server5.realhostname exists, it will take precedence. It is when you change the server hostname after account creation when mail.server.server5.realhostname will be created and differ from mail.server.server5.hostname, which never changes.

(In reply to :aceman from comment #27)

Thank you for the clarifications, aceman. And yes, I mixed up 'Account Name' and 'User Name'. Apologies.

I have at least 10 imap and some pop accounts active for testing and development. It would be nice to be able to selectively enable/disable them just to keep the imap.log halfway readable. But I also think a regular user would also find this useful. I know that Evolution client has this feature (but not sure it works).

I also would like to see the ability to temporarily disable/enable an account (like Evolution can). It can be very useful for testing and development work as noted by another user.

(In reply to Tony Whelan from comment #30)

I also would like to see the ability to temporarily disable/enable an account (like Evolution can). It can be very useful for testing and development work as noted by another user.

I have found that in server settings, if I disable "check for new mail at startup", "check for new mail every X minutes" and "immediately notify new mail" then the account is essentially disabled (no imap comm occurs) as long as you don't click on a folder in the account. For development and testing of my profile I have found this useful.

<quote>I have found that in server settings, if I disable "check for new mail at startup", "check for new mail every X minutes" and "immediately notify new mail" then the account is essentially disabled (no imap comm occurs) as long as you don't click on a folder in the account. For development and testing of my profile I have found this useful.</quote>

Not much use to have emails you can never refer to.

It seems I have gotten over the "check every time I ask for 'Get all new messages'" by using 0.0.0.0 as the mail server, at least I haven't seen the error message pop up in a while. Which is a good thing since TB leaks SO much memory these days I have to shut it down every few hours (if it's been running overnight, I have to shut it down and restart it before I can read or check mail).

But even with the "IMAP Server" for a disabled account set to 0.0.0.0, if I click on ANY folder in that disabled account, it tries to go out and check the email on the server again. I've shut off everything that seems to be trying to connect. And I notice it's looking for the actual name of the original IMAP server, not the "0.0.0.0" that I set in the account profile.

But all of this is hackery on top of hackery, upon hackery. This should be something as simple as a checkbox to say "This is a disabled account. don't try to connect at all". Then the application would see that switch and just skip over that account. Essentially it should see it the same as it would see the "Local Folders" section, as just local files not linked to anything.

Not much use to have emails you can never refer to.

My method in comment 31 does not preclude accessing any email stored locally or on the imap server. Even new ones will come in when you click on a folder that flags new messages like Inbox.

But even with the "IMAP Server" for a disabled account set to 0.0.0.0, if I click on ANY folder in that disabled account, it tries to go out and check the email on the server again. I've shut off everything that seems to be trying to connect. And I notice it's looking for the actual name of the original IMAP server, not the "0.0.0.0" that I set in the account profile.

I guess when you change the "realhostname" to 0.0.0.0 and tb can't find anything it tries the "hostname" instead. (Real host name is what you have most recently entered while hostname is what was originally used for the account.) If it's doing this I guess I am somewhat surprised.

Essentially it should see it the same as it would see the "Local Folders" section, as just local files not linked to anything.

A problem with a account-specific switch to disable all comm with imap server: If the user only stores headers locally, you couldn't access email bodies when the account comm is disabled. An option to first download messages like for going offline would be needed.

OK, I am going on the presumption that you have fully-synced email accounts. I'll end up doing that because of habits picked up from my days of dial-up, where you would retrieve mail and then log-off. Especially going back to my days of using TapCIS and CISOP (auto-downloaders for CompuServe).

So I'm guessing maybe we'd need a "Disabling extension" that could go through a profile and switch all the hidden settings to block TB from attempting to connect (or giving it an address it won't even try)? Of course, that would mean it would need to store the original settings, in the situation where someone would want to re-activate it (in my case, these are no longer active accounts).

I'm wondering just how many of my periodic lock-ups in TB are from TB trying to re-connect to dead accounts? (yes, it does that on multiple machines and dual-boot on the same machine; I've copied the profile over, with whatever tweaking to make the Linux profile work on MSWin).

If implemented in the way I suggested in bug 1647632 comment 1, I believe it would also resolve this issue as originally described.

See Also: → 1647632
See Also: → 563334
Severity: normal → S3
Duplicate of this bug: 1694037
You need to log in before you can comment on or make changes to this bug.