Steps to reproduce:

I changed the password for my imap account 2 days ago, while Thunderbird was not running and my Mac was switched off.

Actual results:

On the first run of Thunderbird after the password change it tried the old password 6 times within a few seconds and got me locked out for 10 minutes. Logfile entries on the imap server:

May  6 06:17:03 srvvm01 auth[238025]: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=harri rhost=10.19.97.250  user=harri
May  6 06:17:03 srvvm01 auth[238037]: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=harri rhost=10.19.97.250  user=harri
May  6 06:17:03 srvvm01 auth[238037]: pam_sss(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=harri rhost=10.19.97.250 user=harri
May  6 06:17:03 srvvm01 auth[238037]: pam_sss(dovecot:auth): received for user harri: 6 (Permission denied)
May  6 06:17:03 srvvm01 auth[238025]: pam_sss(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=harri rhost=10.19.97.250 user=harri
May  6 06:17:03 srvvm01 auth[238025]: pam_sss(dovecot:auth): received for user harri: 6 (Permission denied)
May  6 06:17:09 srvvm01 auth[238025]: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=harri rhost=10.19.97.250  user=harri
May  6 06:17:09 srvvm01 auth[238025]: pam_sss(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=harri rhost=10.19.97.250 user=harri
May  6 06:17:09 srvvm01 auth[238025]: pam_sss(dovecot:auth): received for user harri: 6 (Permission denied)
May  6 06:17:13 srvvm01 auth[238025]: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=harri rhost=10.19.97.250  user=harri
May  6 06:17:13 srvvm01 auth[238025]: pam_sss(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=harri rhost=10.19.97.250 user=harri
May  6 06:17:13 srvvm01 auth[238025]: pam_sss(dovecot:auth): received for user harri: 6 (Permission denied)
May  6 06:17:17 srvvm01 auth[238037]: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=harri rhost=10.19.97.250  user=harri
May  6 06:17:17 srvvm01 auth[238037]: pam_sss(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=harri rhost=10.19.97.250 user=harri
May  6 06:17:17 srvvm01 auth[238037]: pam_sss(dovecot:auth): received for user harri: 8 (Insufficient credentials to access authentication data)
May  6 06:17:21 srvvm01 auth[238025]: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=harri rhost=10.19.97.250  user=harri
May  6 06:17:21 srvvm01 auth[238025]: pam_sss(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=harri rhost=10.19.97.250 user=harri
May  6 06:17:21 srvvm01 auth[238025]: pam_sss(dovecot:auth): received for user harri: 8 (Insufficient credentials to access authentication data)

There was a popup asking for the new password, but this did not help me to bypass the locked account. Too late. And there was no indication why I could not login.

I verified that the password entry in Thunderbird's autofil contained the new password. There were no other entries.

Expected results:

TB should try the known password once. If this fails, then the popup should be shown. Further login attempts using the bad password should not be tried.

I vaguely remember TB will try password multiple times per login attempt. I think that was many years ago. I don't remember the disposition

I tested with my local dovecot that I use only for TB test purposes. It looks like TB tries to send the password once for each supported authentication type (obtained from imap CAPABILITY response) for each connection. I see it try PLAIN password and then "old-style" login and since I've entered a bad password (in password manager) for testing, both fail.
Also, now TB starts up with two connections, one for normal Inbox access and the other for folder discovery. So a bad password results in 4 failed password attempts (which looks like what the reporter shows in the above server log).
With my default dovecot settings I was able to enter the correct password after the 4 failures, although I has 2 boxes appear to enter the correct password on top of each other and only the hidden one (after moving the box on top) accepted entries, which was a bit confusing.

That sounds like wrong a action as we have an authentication method in the account settings. This is not account setup.

This is a big issue for folk waiting for Thunderbird to prompt for a new password.

(In reply to gene smith from comment #2)

I tested with my local dovecot that I use only for TB test purposes. It looks like TB tries to send the password once for each supported authentication type (obtained from imap CAPABILITY response) for each connection. I see it try PLAIN password and then "old-style" login and since I've entered a bad password (in password manager) for testing, both fail.

If I remember correctly, this only happens with unencrypted PW transfer (PLAIN respectively LOGIN).

Also, now TB starts up with two connections, one for normal Inbox access and the other for folder discovery. So a bad password results in 4 failed password attempts (which looks like what the reporter shows in the above server log).

Here you have to distinguish whether only one folder is updated because it has the focus at startup, or whether the entire account is synchronized.
In the latter case, up to mail.server.<server-ID>.max_cached_connections/mail.imap.max_cached_connections parallel connections are established simultaneously. And of course, each one requires its own login. I don't think it makes sense to serialize them all.

Maybe we could first establish a single connection for the INBOX and only when this has been successfully established synchronize the other folders.

Helps to avoid account lock-out when`user's password has expired and multiple connections
attempting to authenticate with a bad password.

Now, due to bug 163964, the 1st URL that occurs when TB starts is discoverallboxes. After that, a select for a folder (typically Inbox) occurs. Without this patch, both occur and allocate their own connection, authenticate and run independently.
With this patch, the select URL is deferred using the existing queuing methods so that the discoverallboxes URL authenticates first and only then is the select URL pulled from queue and run in its own connection. So if there is an authentication failure on discoverallboxes it will block the select URL from attempting to login too, reducing the possibility of account lock-out as reported in comment 0.

This shouldn't slow down the access to new messages as detected by the select for users with a LOT of folders since the select is only delayed until the connection for discoverallboxes authenticates. After that, they both still run in parallel in their own connections as was enabled in bug 163964.

Pushed by alessandro@thunderbird.net:
https://hg.mozilla.org/comm-central/rev/92976db043d3
Defer subsequent URLs in a session until the 1st URL's connection is authenticated. r=BenC

Comment on attachment 9282109 [details]
Bug 1768121 - Defer subsequent URLs in a session until the 1st URL's connection is authenticated. r=benc

[Approval Request Comment]
Regression caused by (bug #):
User impact if declined: Accounts can get locked in wrong password is sent too many times
Testing completed (on c-c, etc.): On 103.0b1
Risk to taking this patch (and alternatives if risky):

Comment on attachment 9282109 [details]
Bug 1768121 - Defer subsequent URLs in a session until the 1st URL's connection is authenticated. r=benc

[Triage Comment]
Approved for esr102

Let's make sure we give the candidate build a good test

Thunderbird 102.0.1:
https://hg.mozilla.org/releases/comm-esr102/rev/53f59f98afcc

(In reply to Wayne Mery (:wsmwk) from comment #9)

Let's make sure we give the candidate build a good test

Where can I get the candidate build for testing? I need 102.0.1, right?

I'm more concerned about how do I test it without a dovecot server, how I change the password with Thunderbird not running and my computer switched off?

(In reply to WaltS48 [:walts48] from comment #12)

I'm more concerned about how do I test it without a dovecot server, how I change the password with Thunderbird not running and my computer switched off?

If your imap provider expires your password and asks you to provide a new one via non-TB means, this just causes tb to not send the old stored password as many times causing you to more likely get locked out. You put in the new one provided to you at the TB password prompt that occurs because TB still has the old password stored and it failed when it was sent.
Of course if you put in the wrong password or keep using the expired stored password too many times, you may still get locked out.

Actually, I didn't test this with the above scenario. I just tested to make sure there was only one or two authentication imap commands sent with a bad password stored at tb startup. This really has nothing to do with dovecot.

Harald, is this fixed for you in 102.0.1?

I would love to try, but how can I modify my password in Thunderbird's keyring to make it invalid? Changing my login for test purposes is not an option; too many systems are affected by this.

(In reply to Harald Dunkel from comment #15)

I would love to try, but how can I modify my password in Thunderbird's keyring to make it invalid? Changing my login for test purposes is not an option; too many systems are affected by this.

You can go to Settings | Privacy and Security | Password and click the "Saved Passwords" button. In there you can click "Show Password" and find your imap account in the list. Then double-click on the password (or use right-click context menu) and change the password stored slightly and close the "Saved logins" window. (You may want to open it again and make sure the password is really stored wrong.). Then shutdown TB completely (File | Quit) and restart. You should see the prompt to enter a correct password when TB accesses the account and tries to login with the wrong password.

Harald,
I should also mention that even with this patch and with a bad stored password, on account access TB will still make two attempts with a bad password to login. This is because your dovecot is probably configured to accept "PLAIN" password and "login" password and both will fail with the bad password sent. So if the threshold for failed login attempts is 2 you will still get locked-out.
If that's the case, the only solution is to configured dovecot to not accept "login" style passwords and only accept "PLAIN" style. The other option is to configure dovecot or whatever program does the authentication to allow at least 3 bad passwords before locking the user out.