Bear with me: this is similar to some seemingly fixed POP/IMAP bugs concerning stored passwords (which I can't verify ATM - q.v.), but no current report seems to cover this on SMTP so I'm raising a new bug. I'm using the 1.1a release. Up until recently there was a bug which stopped mailnews asking for a new POP password is one was stored in the password manager which became invalid. Our mail access is though a system that uses our NT a/c username/passwortd for auth.; we have to cycle our passwords regularly, and we also have a 'three strikes and you're out' rule that locks our NT a/c. When I changed my password, the stored POP passwd became wrong, but was re-used enough times to cause my a/.c to be locked out. So, I stopped remembering the passwords (POP & SMTP). Recently, these bugs seemed to have been closed, so, I heroically decided to try using the password manager for them again. It so happens that the first thing I tried to do after chaning my NT password was send a mail - the "sending" box just sat there until I aborted it, at which point my a/c had been locked out. It seems as if whetever fix was applied to the POP (& IMAP?) side of things might be required in the SMTP code as well. Unfortunately, we also have a limit (sigh) on the /frequency/ of which we can change our passwords, so I can only test this every so often :-/ Raised 'major' as, although there's a partial workaround in moz (delete passwd from pwd-mgr and restart) it still leaves an unrecoverable (directly) situation with my NT a/c unlocked.

I can confirm that this happens - if the AUTH fails, Mozilla does not ask for the password again, it just keeps retrying with the bad password.

Marking as NEW

*** Bug 161645 has been marked as a duplicate of this bug. ***

Confirming for 1.2.1. Neither do I get a warning/error message nor does anything useful happen. The send dialogues just stays open forever... BTW, it would be VERY useful to have a UI to set or at least unset/clear a password for a SMTP account.

This still happens in my just-post-1.3a Win32 snapshot install - both SMTP & IMAP (just moved to this from POP) seem to refuse to tell me my password's been thrown out and keep trying. Reply to previous post: you can delete your SMTP, etc., password using the password manager. In my case, I currently have to remember to do this & fully quit Moz. before changing my password every month.

See also bug 182362.

*** Bug 171538 has been marked as a duplicate of this bug. ***

Same annoying bug still exists in 1.4x. The same problem occurs when a mailserver is unreachable. It will popup 'Server responded....' and you can only click the 'ok' button....and Mozilla will 'loop' doing this. The only way to shut mozilla is by killing it. Is nobody looking for a solution for this, because I think this is a major one. A lot of users already complained about this one.

see also Bug 154099

For me this is a DUP of Bug 154099. Anyone wants to keep this one separate?

Just suffered with Mozilla 1.7.5: When using a wrong SMTP password, Mozilla doesn't prompt for a new one; you have to find it in Password manager and delete it there. When the password has been deleted, Mozilla first tries to login without a password, then prompts for a new one. Of course, everyone would expect Mozilla to prompt in the first case, too; once every two months, when I change my GMX passphrase, I struggle with this annoying lack of usability. Bug 154099, SMTP auth failure not recognized: Nothing happened there (either) since 2003-05-21 This should be a easy one to fix, shouldn't it? Proposing keyword "mail3", and to block 1.7.6.

Here is a short (but not necessarily complete) summary of similar bugs: Bug 121926, "VERIFIED FIXED": email does not ask for password if it has the wrong one (this is WRONG; the bug has evidently reappeared, it is present in Mozilla 1.7.5) Bug 255740, "Mail does not ask for password", was marked "RESOLVED DUPLICATE" of 121926, so neither of the two is worked on... Bug 182362, "no password dialog box after fail of PASS command (Mail: POP3 and IMAP)": Status NEW, nothing happened since 2004-08-16 Bug 255740, "Mail does not ask for password": DUPLICATE of 182362 Thus, all bug requests I found are either (by mistake) marked "VERIFIED FIXED" and therefore ignored, or duplicates of an ignored bug, or "NEW" and unconfirmed, and therefore ignored. Since the bug apparently had been fixed but re-appeared, it is a regression; additionally suggesting keyword "mail4" or "regression". Possibly related are: Bug 154099, "SMTP auth failure not recognized" (NEW) Bug 141052, "failure to notify when an authorization failure occurs" (NEW) Would please someone with sufficient rights cut the Gordian knot? Thanks!

Did you see this?: http://kb.mozillazine.org/Password_not_remembered_%28Thunderbird%29

Still reproducible in Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090106 Shredder/3.0b2pre I have an easy way to reproduce it at my disposal however. I'll get an SMTP protocol log posted shortly.

It appears from the log that Shredder just continually re-attempts over and over again until the server cuts it off for trying too many times. This sounds like a good way to get someone's account locked out requiring a password reset, too (though it hasn't happened to me yet, despite Mozilla having such a lockout policy, probably because IMAP is checking frequently enough to get a few good attempts mixed in with it).

Taking for now at least, we have various tools on trunk that should help me look at it.

This feels like a DOS problem, so accepting as blocking until mark tells me otherwise =)

The only thing I can think of at the moment that could cause this is for some reason the password manager isn't dropping the old password when it is told to. Dave, do you have any idea if you originally entered a username in the SMTP settings of the account manager dialog, or not (and hence it would have prompted you for username & password)? I realise you probably won't remember, but its worth asking. If it is related to that, then I think this may be fixed by switching to the toolkit password manager (bug 239131) but I'd still like to do some more investigation to be sure.

Pretty sure I've always entered the username from the account manager when setting the account up, since if you don't, it won't prompt you for auth at all, and will just fail with a relaying denied. It then prompts me for the password the first time I try to send mail, and I check the box to save it.

I've done some investigations. For some reason the wallet password manager (the one we currently use) isn't forgetting passwords when the username is of the form foo.bar@host. The good news is that the toolkit password manager will handle these correctly, so I've set a dependency on that bug. The patch is a unit test to cover this bug - it never finishes if Thunderbird is built with wallet (because our fake server never gives up), and passes if Thunderbird is built with the toolkit password manager patches. The patch also requires the additional changes I've put in bug 472811, that should go in soon. Once we've switched to the toolkit password manager (I'm hoping within the next few week), then that will fix this bug and we can put this unit test in as well.

Unit test for this bug (fixed by bug 239131). The only difference from the last version is removing some debugging info that is no longer necessary.

Unit test has now been pushed: http://hg.mozilla.org/comm-central/rev/73d7308184bd This bug is fixed as a result of the changes on bug 433316/bug 239131.

I'm still seeing the behavior of not asking for a new password after an SMTP authentication failure related, which happened after a password change. I did tests in Thunderbird 3.0 and 3.1rc1, Microsoft Windows XP and 7, Brazilian Portuguese language.

(In reply to comment #25) > I'm still seeing the behavior of not asking for a new password after an SMTP > authentication failure related, which happened after a password change. I did > tests in Thunderbird 3.0 and 3.1rc1, Microsoft Windows XP and 7, Brazilian > Portuguese language. Please file a new bug, including a log of the SMTP activity (https://wiki.mozilla.org/MailNews:Logging).

Thank you Mark! I'm sorry for the noisy. Actually, we could debug further and found the cause of the problem. I will just document it here so people can found it if they search for something similar. :) Our company is using qmail-ldap (qmail with LDAP patch) as SMTP server with authentication (SMTP-Auth) over TLS and we had one option called SMTP550DISCONNECT (it is an environment variable) active, this drops the connection when a 550 error occurs during the SMTP dialogue. The symptom is very similar to the one described on this bug, and once I removed the option, clients were asked to inform a new password when the authentication fails.

FYI. (In reply to Felipe Augusto van de Wiel from comment #27) > we had one option called SMTP550DISCONNECT (it is an environment variable) active, > this drops the connection when a 550 error occurs during the SMTP dialogue. >(snip) > and once I removed the option, clients were asked to inform a new password > when the authentication fails. Tb's problem is "Tb fails to detect such silent connection killing by server during authentication phase", and Bug 533006 is for the Tb side problem when such unplesant server behavior for Tb. See bugs listed in dependency tree for Bug 533006 for variants of Tb's problems after Bug 533006 happens.