709442 - Account creation must block creation of accounts that will confuse the backend

Status: RESOLVED DUPLICATE of bug 303542

(Thunderbird :: Account Manager, defect)

Description

[Randell Jesup [:jesup] (needinfo me)]

Following the instructions here:
https://mana.mozilla.org/wiki/display/DESKTOP/Restoring+Email+for+IMAP
for the New Account Method (in particular for v10), even after changing the server and changing the account name, when adding a new account for your Moco email using imap, both accounts will get the same name, and both appear to share some settings (in particular imap server, which can cause neither to connect, or can cause both to connect, causing email loss on the server in this case.

Also, the first time this happened, when I exited tbird it crashed. (fri dec 9 ~5pm EST)

Initial Severity = critical because this can lead to major dataloss, and users may accidentally add a second copy of an account using the same address/server.  I even considered blocker.

Comment 1

[WADA:World Anti-bad-Duping Agency]

Accounts is roughly defined like next in prefs.js.
(1) account
user_pref("mail.account.accountA.identities", "idP");
user_pref("mail.account.accountA.server", "serverQ");
(2) identity
user_pref("mail.identity.idP.useremail", "[e-mail]");
(3) server
(3-1) label name of account, shown at folder pane
user_pref("mail.server.serverQ.name", "[e-mail]");
(3-2) server type, unable to change onece defined
user_pref("mail.server.serverQ.type", "imap");
(3-3) server name to which login is executed.
      realhostname is used for login.
      if realhostname doesn't exist, hostname is used for login.
user_pref("mail.server.serverQ.hostname", "imap.mail.yahoo.com");
user_pref("mail.server.serverQ.realhostname", "imap.mail.yahoo.com");
(3-4) used port
user_pref("mail.server.serverQ.port", 993);
(3-5) user-id for login
      realuserName is used for login.
      if realuserName doesn't exist, userName is used for login.
user_pref("mail.server.serverQ.userName", "[e-mail]");

Because user id for login == mail address in many cases, and beccause it's used for account's label name, same string of mail address appears at many places.
Please distinguish account's label name, mail address(identity), realuserName/userName (user-id used for login).

What is your account definition in prefs.js for accounts of "both appear to share some settings"?
Did you change server name and/or user name at Server Settings after initial account definition by auto-config?
(is so, realhostname and/or realuserName is created in prefs.js, and string in it is different from hostname realuserName)

Comment 2

[WADA:World Anti-bad-Duping Agency]

(In reply to Randell Jesup [:jesup] from comment #0)
> Also, the first time this happened, when I exited tbird it crashed.

Did you set same directory as "local directly" for both account at Server Settings?

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

Sequence:

Account was for [e-mail], never renamed.  Messages cached locally.  17 unread messages before mail crash.

(with imap disabled at the server):
   Change mail.mozilla.com to example.com
   Turn off the check-for-new-messages boxes

(imap is enabled on the server)
   Create new IMAP account for [e-mail]
   Notice both have the same name, select settings on old one and change the name.
   Notice the new one changed name too; look at it
   Notice it's saying example.com, change to mail.mozilla.com (I think)
   Notice both accounts are showing 17 unread
   Notice both accounts are showing new messages arriving.

   Panic.
   Look at old account, notice no messages between Oct 22 and Dec 5.

I re-created this problem a few other ways working with backup profiles when trying to get messages off (tried renaming the old account first - didn't help).

I always left the "local imap directory" set to defaults.

Comment 4

[Mark Banner (:standard8)]

The core issue here is bug 41929. The backend system that creates account uris based on servername & username is causing this limitation.

We require that the uri for accounts are based on their original URI when the account was created, so renaming the server, username, or account name doesn't actually change anything from a back-end account handling perspective.

Hence creating a second account is highly likely to get the effects seen here.

The only way a user could avoid this, is if their first account was originally a different server name or username, and they had changed it to the current values sometime before the start of the duplicating procedure.

In theory, we could get the new account wizard to handle this, though I'm not sure what error values/description we'd actually give.

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

Ok, per my comment in bug 41929, morphing bug into a account-create-should-block-this bug, and severing dependency.  We should block any account creations we know will confuse the back-end.

Leaving critical, but we really, really need a fix for this.  Mozilla people are still restoring imap accounts and in danger of losing their email, though I did warn people off the "second account" procedure if they're using tbird.

Comment 6

[WADA:World Anti-bad-Duping Agency]

(In reply to Mark Banner (:standard8) from comment #4)
> The core issue here is bug 41929. The backend system that creates account
> uris based on servername & username is causing this limitation.

Bug 41929 is for current limitaion, but it sounds for me that this bug is for problem of "creation of second copy of account", not for limitation. i.e. it sounds for me that this bug reports same problem as Bug 131176 Comment #3, Bug 303542, and Bug 539903.
Mark Banner, will these problems be processed and resolved by Bug 41929?

Comment 7

[WADA:World Anti-bad-Duping Agency]

Tb 8 looks torelant with duplication of realhostname+realuserName.
(IIRC, duplicated realhostname+realuserName produced problem in the past. It was perhaps rejection due to duplication. Current check may be hostname+userName only.)

If Tb 8, definition like next is possible(different type/hostname/port/userName, but same realhostname/realuserName).

> user_pref("mail.server.server4.name", "any name you like"); <= any can be set
> user_pref("mail.server.server4.type", "pop3");
> user_pref("mail.server.server4.port", 995);
> user_pref("mail.server.server4.hostname", "dummy.pop3.server");
> user_pref("mail.server.server4.realhostname", "correct.mail.server"); <= change after definition
> user_pref("mail.server.server4.userName", "dummy.pop3.username");
> user_pref("mail.server.server4.realuserName", "correct.mail.userid"); <= change after definition

> user_pref("mail.server.server5.name", "any name you like");  <= any can be set
> user_pref("mail.server.server5.type", "imap");
> user_pref("mail.server.server5.port", 993);
> user_pref("mail.server.server5.hostname", "dummy.imap.server")
> user_pref("mail.server.server5.realhostname", "correct.mail.server"); <= change after definition
> user_pref("mail.server.server5.userName", "dummy.imap.username");
> user_pref("mail.server.server5.realuserName", "correct.mail.userid"); <= change after definition

And, additional definition like next is also possible. 

> user_pref("mail.server.server6.name", "any name you like");  <= any can be set
> user_pref("mail.server.server6.type", "imap");
> user_pref("mail.server.server6.port", 993);
> user_pref("mail.server.server6.hostname", "second.dummy.imap.server")
> user_pref("mail.server.server6.realhostname", "correct.mail.server"); <= change after definition
> user_pref("mail.server.server6.userName", "second.dummy.imap.username");
> user_pref("mail.server.server6.realuserName", "correct.mail.userid"); <= change after definition

Above is for next.
> pop3 : type=pop3, server=realhostname=correct.mail.server, port=995,
>        userid=realuserName=correct.mail.username, local directory=dummy.pop3.server
> imap : type=imap, server=realhostname=correct.mail.server, port=993,
>        userid=realuserName=correct.mail.username, local directory=dummy.imap.server
> imap : type=imap, server=realhostname=correct.mail.server, port=993,
>        userid=realuserName=correct.mail.username, local directory=second.dummy.imap.server
By this, problem of Bug 41929 can be currently worked around.

(In reply to Randell Jesup [:jesup] from comment #3)
> Notice both have the same name, (snip)

Are you talking about phenomenon of two accounts of same account label name at folder pane and account list of Account Settings?
If so, it's "same string in multiple mail.server.serverN.name entries", isn't it?
Account name(mail.server.serverN.name) is merely a label name of of account, and no duplication check is done by Tb because it's never mandatory. Any string can be set at Account Name: field of Account Settings.

> Notice both accounts are showing 17 unread
> Notice both accounts are showing new messages arriving.

Did you define two accounts like next?
  same type, different hostname, same port, different userName,
  same realhostname, same realuserName
If so, two accounts can be defined in Tb because Tb 8 doesn't look to check duplicated realhostname+realuserName, and both accounts in Tb accesses same Mbox of same server account(userid) on same server.

Or you are talking about problem of Bug 303542?
(multiple accounts of same hostname/userName can be created, so critical problem can happen.)

Comment 8

[Carla]

Wondering if this bug is considered resolved? Also, my platform is Mac OSX (not Windows XP) and I still haven't been able to resynchronize my email yet, and so have been compelled to toggle back and forth between thunderbird and Zimbra webmail daily, a fairly suboptimal solution. So, help?

Comment 9

[Randell Jesup [:jesup] (needinfo me)]

You should ask on IRC in #desktop.  This applies to Thunderbird (and probably doesn't care if it's Mac or Windows, but a lot of people use Mail.app on Mac instead of thunderbird I think).  If you use tbird on mac, I suspect the same instructions given on the "recovery" page will work - you need to file a bug (when you're ready!!) for them to re-enable your IMAP access.

Comment 10

[Wayne Mery (:wsmwk)]

jesup, there are ~3 questions for you in comment 7

Comment 11

[Randell Jesup [:jesup] (needinfo me)]

Wayne - I can't tell you in detail; this was over a year ago....  standard8 (mbanner) is a better person to ask.  

The steps to reproduce in comment 3(using an IMAP server you control) should show the problem.

Comment 12

[:aceman]

So isn't this bug 303542 as WADA describes?

Comment 13

[Wayne Mery (:wsmwk)]

(In reply to :aceman from comment #12)
> So isn't this bug 303542 as WADA describes?

good enough I think