Last Comment Bug 155172 - If stored SMTP password is incorrect, no prompt is made for correct one
: If stored SMTP password is incorrect, no prompt is made for correct one
Status: RESOLVED FIXED
:
Product: MailNews Core
Classification: Components
Component: Networking: SMTP (show other bugs)
: Trunk
: All All
: P2 major with 3 votes (vote)
: Thunderbird 3.0b2
Assigned To: Mark Banner (:standard8, afk until Dec)
:
:
Mentors:
: 161645 171538 391090 472336 (view as bug list)
Depends on: 433316 472811
Blocks:
  Show dependency treegraph
 
Reported: 2002-07-01 05:37 PDT by Neil Bird
Modified: 2011-11-11 13:54 PST (History)
17 users (show)
davida: blocking‑thunderbird3+
standard8: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
SMTP protocol log (15.72 KB, text/plain)
2009-01-06 10:32 PST, Dave Miller [:justdave] (justdave@bugzilla.org)
no flags Details
Unit test (6.22 KB, patch)
2009-01-09 06:48 PST, Mark Banner (:standard8, afk until Dec)
no flags Details | Diff | Splinter Review
Unit test v2 (5.96 KB, patch)
2009-01-15 13:52 PST, Mark Banner (:standard8, afk until Dec)
mozilla: review+
Details | Diff | Splinter Review

Description Neil Bird 2002-07-01 05:37:32 PDT
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.
Comment 1 David Hagood 2002-08-19 09:58:24 PDT
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.
Comment 2 Gregg Meehan 2002-08-20 14:12:56 PDT
Marking as NEW
Comment 3 Ian Neal 2002-08-22 10:43:41 PDT
*** Bug 161645 has been marked as a duplicate of this bug. ***
Comment 4 Martin Kutschker 2003-01-19 11:35:56 PST
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.
Comment 5 Neil Bird 2003-01-20 02:11:29 PST
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.
Comment 6 Russell Odom 2003-02-27 06:54:40 PST
See also bug 182362.
Comment 7 Russell Odom 2003-02-27 07:02:25 PST
*** Bug 171538 has been marked as a duplicate of this bug. ***
Comment 8 Schelstraete Bart 2003-05-02 08:58:23 PDT
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.
Comment 9 Philip Wilk 2003-05-13 13:24:56 PDT
see also Bug 154099
Comment 10 Martin Sch 2003-05-13 14:17:00 PDT
For me this is a DUP of Bug 154099.
Anyone wants to keep this one separate?
Comment 11 Tobias Herp 2005-02-24 04:30:17 PST
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.
Comment 12 Tobias Herp 2005-02-24 05:39:39 PST
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!
Comment 13 Ekhart 2006-04-21 01:16:48 PDT
Did you see this?:
http://kb.mozillazine.org/Password_not_remembered_%28Thunderbird%29
Comment 14 Dave Miller [:justdave] (justdave@bugzilla.org) 2009-01-06 09:49:25 PST
*** Bug 472336 has been marked as a duplicate of this bug. ***
Comment 15 Dave Miller [:justdave] (justdave@bugzilla.org) 2009-01-06 09:51:03 PST
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.
Comment 16 Dave Miller [:justdave] (justdave@bugzilla.org) 2009-01-06 10:32:56 PST
Created attachment 355608 [details]
SMTP protocol log

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).
Comment 17 Mark Banner (:standard8, afk until Dec) 2009-01-06 10:57:21 PST
Taking for now at least, we have various tools on trunk that should help me look at it.
Comment 18 David Ascher (:davida) 2009-01-08 11:35:52 PST
This feels like a DOS problem, so accepting as blocking until mark tells me otherwise =)
Comment 19 Mark Banner (:standard8, afk until Dec) 2009-01-08 15:09:34 PST
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.
Comment 20 Dave Miller [:justdave] (justdave@bugzilla.org) 2009-01-09 01:47:31 PST
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.
Comment 21 Mark Banner (:standard8, afk until Dec) 2009-01-09 06:48:28 PST
Created attachment 356179 [details] [diff] [review]
Unit test

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.
Comment 22 Mark Banner (:standard8, afk until Dec) 2009-01-15 13:52:21 PST
Created attachment 357230 [details] [diff] [review]
Unit test v2

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.
Comment 23 Mark Banner (:standard8, afk until Dec) 2009-01-19 02:25:14 PST
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.
Comment 24 Mark Banner (:standard8, afk until Dec) 2009-05-23 01:59:59 PDT
*** Bug 391090 has been marked as a duplicate of this bug. ***
Comment 25 Felipe Augusto van de Wiel 2010-06-01 13:01:06 PDT
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.
Comment 26 Mark Banner (:standard8, afk until Dec) 2010-06-01 14:00:23 PDT
(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).
Comment 27 Felipe Augusto van de Wiel 2010-06-02 14:04:37 PDT
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.
Comment 28 WADA 2011-11-11 13:54:14 PST
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.

Note You need to log in before you can comment on or make changes to this bug.