Comment 40 for bug 297301

Your description of the "new password created behind my back" issue is correct;
that can happen ... however...

1) If Thunderbird gets a wrong password error, it should mark the account for
no future access until there is user interaction. However, it shouldn't force
the user interaction via a spoofable dialog, and it shouldn't halt processing
with a modal dialog.

2) If the user knows that multiple password errors might lock out the account,
he should leave the following proposed option checkbox unchecked: Try again
after password errors. However, users that will not be locked out would enjoy
this setting. The lockout algorithms usually only happen when there are too
many attempts in a particular time period, so even if there are lockout
possibilities, if the "check for mail" period is such that the time period is
not exceeded, the setting could be used by such users, also. The retry should
be only at the next biff interval for automatic checking, not immediately, to
aid in avoiding lockout.

Thunderbird could tell you why it asks for a new password, but isn't the reason
always that there was an error during login? So that seems uninformative. If
there are other reasons, they are bugs and should be fixed.

Thunderbird should never forget the old password. The user shouldn't be forced
to type the same one in again in the presence of errors at the server, when it
hasn't changed. Even the present, inappropriate, asynchronously appearing
modal dialog allows the user to change the password if that is appropriate...
but if the problem is due to errors at or communicating with the server, having
Thunderbird wipe out the old password and turn off the remember password
checkbox is always inappropriate.

And if the user has been notified that the password has been changed at the
server, and doesn't change it in Thunderbird, and gets locked out, why is that
Thunderbird's problem (especially if the proposed "Try again after password
errors" checkbox is implemented and checked)?

I disagree with the second paragraph of comment #38 and the last paragraph of comment #39 -- Thunderbird should never request a password via an asynchronous dialog -- see my comment #25 for why.

I agree with the moronic server behavior idea, but the way passwords are done these days, the server probably can't tell what the password used actually was: if it could tell that the same password is being used repeatedly, it should not call that an attack... that's a user that forget he changed his password, or forgot that it was changed behind his back.

I agree it never desirable to forget the old password, until the user says to forget the old password.