277529 - After changing the user name for POP3 account, saved password for old username is used.

Status: RESOLVED EXPIRED

(Thunderbird :: Account Manager, defect)

Description

[Alexei Akhounov]

I created an E-mail account in Thunderbird, say for E-mail
[e-mail]. I set up POP3 and saved password when requested.
Then, in the settings for the same account, I change the user name from
"[e-mail]" to "[e-mail]" 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://[e-mail], so I should assume that TB
would use this password only for "[e-mail]" 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.

Comment 1

[WADA:World Anti-bad-Duping Agency]

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?

Comment 2

[Alexei Akhounov]

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

Comment 3

[WADA:World Anti-bad-Duping Agency]

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

Comment 4

[Alexei Akhounov]

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

Comment 5

[WADA:World Anti-bad-Duping Agency]

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

Comment 6

[Ulf Uhrmann]

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.

Comment 7

[WADA:World Anti-bad-Duping Agency]

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

Comment 8

[WADA:World Anti-bad-Duping Agency]

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

Comment 9

[Gervase Markham [:gerv]]

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/

Comment 10

[Gervase Markham [:gerv]]

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.