I created an E-mail account in Thunderbird, say for E-mail email@example.com. I set up POP3 and saved password when requested. Then, in the settings for the same account, I change the user name from "firstname.lastname@example.org" to "email@example.com" and do all other changes in settings in order to use another user name for this account. When I click "Get Mail" for this account, TB sends my old password to the POP server and I get the message "Sending of password did not succeed. Mail server pop.gmail.com responded: Password supplied for "second_email" is incorrect. When I go to the "Tools->Options->Advances->Saved Passwords" I see the line mailbox://firstname.lastname@example.org, so I should assume that TB would use this password only for "email@example.com" username. But it uses it for any username, entered in the account. There is a workaround, of course. To delete saved password for old user name. And the situation I described should not occur very frequently (nevertheless, it occured today as I helped my fried to switch mail accounts). That's why I put "minor" severiry.
I also think cause of your problem is : - Key for password manager(Username in your case) is not changed even when user changed real userName for login. (not sure but I can't imagine other causes) This is because : (when POP3 and probably IMAP too. Not applicable to SMTP) (A-1) "Site" for password manager is mail.server.serverNN.hostname. - Site = mailbox://<hostname> (A-2) "Username" for password manager is mail.server.serverNN.userName. - Username = <userName> (B-1) Real hostname used in login is mail.server.serverNN.realhostname instead of mail.server.serverNN.hostname when hostname is changed after initial account definition. (B-2) Real userName used in login is mail.server.serverNN.realuserName instead of mail.server.serverNN.userName when userName is changed after initial account definition. (C) mail.server.serverNN.hostname & mail.server.serverNN.userName will never be changed in order to keep consistency in naming of mail related resources such as internal mail folder pathname, because "hostname" & "userName" are used in their name. See your prefs.js entries and password manager entry for above. Questions on your case : Was there no chance to enter new password for the new userName when login error due to old password? Was "deletion of password manager entry" the only way to recover from the problem?
(In reply to comment #1) > Questions on your case : > Was there no chance to enter new password for the new userName when login error > due to old password? > Was "deletion of password manager entry" the only way to recover from the problem? > I've played with this bug more today. And noticed another thing that is crucial for it's reproducibility: When creating Email account, one should uncheck "Use Global Inbox" option.
(In reply to comment #2) > And noticed another thing that is crucial > When creating Email account, one should uncheck "Use Global Inbox" option. See Bug 272340 for it. Developers have to love "Global Inbox" since many many users requested ( = threatened :-) ) Mozilla/Thunderbird develoers for MS Outlook Express like behaviour.
(In reply to comment #1) > Questions on your case : > Was there no chance to enter new password for the new userName when login error > due to old password? > Was "deletion of password manager entry" the only way to recover from the problem? > Sorry, for not answering your questions directly. Here are the answers: 1. If the option "Global Inbox" is on, TB removes saved password for old user name whenever I change it. Otherwise the saved password remains. Consequently, if the "Global Inbox" is on, I am requested to enter a new password after changing the username and clicking "Get Mail" button. If "Global Inbox" is off, TB doesn't ask for new password, it just tries to use old password and display the error message "Sending of password did not succeed." 2. This is only workaround that I've found. Changing "Global Inbox" option on the existing accout doesn't solve the problem. Only deletion of the saved password.
(In reply to comment #4) > 1. > If "Global Inbox" is off, > TB doesn't ask for new password, it just tries to use old password and display > the error message "Sending of password did not succeed." Sounds same situation as Bug 263542, since your userName contains "." and saved password became wrong in your case due to userName change. There is other similar situation, Bug 205762, although cause seems to be different from your case.
Don't know if its same cause, but I had similar problems with IMAP accounts using TB 1.0. Please let me know if it's worth a new bug#. 1. Renamed username on server, 2. changed username in TB's account settings. Nevertheless TB uses the old username for login and old IMAP paths. Looking in prefs.js showed that "mail.server.server<x>.userName" still contains the old username, while "mail.server.server<x>.realuserName" has the new one. Well, there will be a reason for this handling instead of changing .userName, but obviously TB still uses .userName for login and additionally doesn't update the paths to drafts/templates/sent. Setting this paths via GUI didn't work (set paths, clicked on "OK", but no reaction), only manual correction in prefs.js (changed .userName, deleted . realuserName, fixed IMAP paths) could fix the problem. Tried with POP3 account using 20050212 nightly, .realuserName was created, . userName deleted, password updated, therefore no problems. IIRC I had similar problems with POP3 accounts in the past, but can't remember exactly.
(In reply to comment #6) > Nevertheless TB uses the old username for login and old IMAP paths. Really? (Sorry but I can't test it because I don't have IMAP account) If yes, it's new problem. Ulf Uhrmann, open separate bug, please. > Looking in prefs.js showed that "mail.server.server<x>.userName" still contains > the old username, while "mail.server.server<x>.realuserName" has the new one. > TB still uses .userName for login This bug's(reporter's) problem is; When .userName = USER1 and .realuserName = USER2 (changed user name), login used USER2, but key for password manager was still USER1. Then previously entered password was used in login. And, since his user name contains ".", password was probably not prompted correctly due to Bug 263542. This is completely different from your problem. If .userName was used instead of .realuserName for login when IMAP, this is new problem, I think. > and additionally doesn't update the paths to drafts/templates/sent. drafts/temlates/sent is saved in mail.identity.idNN.drafts_folder (stationaly_folder, fcc_folder) and value format is <username>@<servername>. ( Note: picker mode for "stationaly_folder" is "tmpl_folder_picker_mode" :-) ) In my test with dummy IMAP account, when user name was changed and .realuserName was created, this <username> value was not changed, was still value of .ueserName was used. This is same behaviour on POP3. So I think unchaged <username> field is not problem, if the <username> field doesn't have relation to real login user id for IMAP.
(In reply to comment #6) > Nevertheless TB uses the old username for login and old IMAP paths. Bug 265725 reported similar problem on both IMAP and POP3 after username change. I think POP3 problem of Bug 265725 is same problem as this bug. But I can say nothing on IMAP - whether password problem(same as this bug) or username problem('.realuserName' related). Ulf Uhrmann, can you execute re-creation test with new profile for test? If yes, see Bug 265725 and report your test result to Bug 265725, please.
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.