If stored SMTP password is incorrect, no prompt is made for correct one

RESOLVED FIXED in Thunderbird 3.0b2

Status

MailNews Core
Networking: SMTP
P2
major
RESOLVED FIXED
15 years ago
6 years ago

People

(Reporter: Neil Bird, Assigned: standard8)

Tracking

Trunk
Thunderbird 3.0b2
Dependency tree / graph
Bug Flags:
blocking-thunderbird3 +
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

15 years ago
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.

Updated

15 years ago
QA Contact: sheelar → meehansqa

Comment 1

15 years ago
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

15 years ago
Marking as NEW
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 3

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

Comment 4

15 years ago
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.
(Reporter)

Comment 5

15 years ago
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

15 years ago
See also bug 182362.

Comment 7

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

Comment 8

15 years ago
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

15 years ago
see also Bug 154099

Comment 10

15 years ago
For me this is a DUP of Bug 154099.
Anyone wants to keep this one separate?
Product: MailNews → Core

Comment 11

13 years ago
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.
Flags: blocking1.7.6?

Comment 12

13 years ago
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!

Updated

13 years ago
Flags: blocking1.7.6?

Comment 13

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

Updated

9 years ago
Assignee: mscott → nobody
Duplicate of this bug: 472336
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.
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).
Flags: blocking-thunderbird3?
(Assignee)

Comment 17

9 years ago
Taking for now at least, we have various tools on trunk that should help me look at it.
Assignee: nobody → bugzilla
Priority: -- → P2
This feels like a DOS problem, so accepting as blocking until mark tells me otherwise =)
Flags: blocking-thunderbird3? → blocking-thunderbird3+
(Assignee)

Updated

9 years ago
QA Contact: meehansqa → networking.smtp
(Assignee)

Comment 19

9 years ago
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.
Status: NEW → ASSIGNED
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.
(Assignee)

Updated

9 years ago
Depends on: 472811
(Assignee)

Updated

9 years ago
Depends on: 433316
(Assignee)

Comment 21

9 years ago
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.
(Assignee)

Updated

9 years ago
Whiteboard: [fixed once bug 433316 (tk pwmgr) lands]

Updated

9 years ago
OS: Windows NT → All
Hardware: x86 → All
(Assignee)

Updated

9 years ago
Whiteboard: [fixed once bug 433316 (tk pwmgr) lands] → [fixed; need to land unit test]
Target Milestone: --- → mozilla1.9.1b3
(Assignee)

Comment 22

9 years ago
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.
Attachment #356179 - Attachment is obsolete: true
Attachment #357230 - Flags: review?(bienvenu)

Updated

9 years ago
Attachment #357230 - Flags: review?(bienvenu) → review+
(Assignee)

Comment 23

9 years ago
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [fixed; need to land unit test]
Product: Core → MailNews Core
(Assignee)

Updated

9 years ago
Target Milestone: mozilla1.9.1b3 → Thunderbird 3.0b2
(Assignee)

Updated

8 years ago
Duplicate of this bug: 391090
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.
(Assignee)

Comment 26

7 years ago
(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.
You need to log in before you can comment on or make changes to this bug.