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.

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", "abc@yahoo.com"); (3) server (3-1) label name of account, shown at folder pane user_pref("mail.server.serverQ.name", "abc@yahoo.com"); (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", "abc@yahoo.com"); 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)

(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?

Sequence: Account was for rjesup@mozilla.com, 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 rjesup@mozilla.com 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.

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.

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.

(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?

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.)

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?

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.

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

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.

So isn't this bug 303542 as WADA describes?

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