Last Comment Bug 249240 - Password dialog for POP/IMAP server does not reprompt when password is changed externally.
: Password dialog for POP/IMAP server does not reprompt when password is change...
Status: VERIFIED FIXED
: fixed1.8.0.8, verified1.8.1
Product: MailNews Core
Classification: Components
Component: Networking (show other bugs)
: Trunk
: All All
: -- major with 2 votes (vote)
: ---
Assigned To: David :Bienvenu
:
:
Mentors:
: 246291 246542 252044 253983 288393 290805 293106 296447 365327 365347 (view as bug list)
Depends on:
Blocks: 352722 286628
  Show dependency treegraph
 
Reported: 2004-06-30 08:55 PDT by Rich
Modified: 2010-08-06 09:17 PDT (History)
24 users (show)
mscott: blocking‑aviary1.0PR-
mscott: blocking‑aviary1.0+
mscott: blocking‑thunderbird2+
dveditz: blocking1.8.0.7-
dveditz: blocking1.8.0.8+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
proposed fix for pop3 (3.74 KB, patch)
2004-10-06 09:17 PDT, David :Bienvenu
no flags Details | Diff | Splinter Review
patch v2 (5.74 KB, patch)
2004-10-18 11:00 PDT, Christian Eyrich
mozilla: superreview+
Details | Diff | Splinter Review
patch v2.1 (6.06 KB, patch)
2004-10-19 05:00 PDT, Christian Eyrich
mozilla: review+
mscott: superreview+
Details | Diff | Splinter Review
work in progress (12.11 KB, patch)
2006-04-20 13:36 PDT, David :Bienvenu
no flags Details | Diff | Splinter Review
proposed fix (12.27 KB, patch)
2006-05-22 16:04 PDT, David :Bienvenu
mscott: superreview+
mozilla: approval‑branch‑1.8.1+
dveditz: approval1.8.0.7+
Details | Diff | Splinter Review
POP3 logfile after changing password externally (6.07 KB, text/plain)
2006-09-07 12:46 PDT, Henrik Skupin (:whimboo)
no flags Details
IMAP4 log of failed authentication (9.80 KB, text/plain)
2006-09-08 01:44 PDT, Henrik Skupin (:whimboo)
no flags Details
fix case where username contains a '.' (2.51 KB, patch)
2006-09-13 15:24 PDT, David :Bienvenu
mscott: superreview+
dveditz: approval1.8.0.8+
Details | Diff | Splinter Review
donotcare's IMAP log showing password failures (12.22 KB, application/octet-stream)
2009-12-21 09:03 PST, donotcare
no flags Details
donotcare's new log 2010-FEB-04 (using 3.1b1pre) (2.24 KB, text/plain)
2010-02-04 09:45 PST, donotcare
no flags Details

Description Rich 2004-06-30 08:55:47 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1

When both the POP and SMTP server passwords are saved in password manager the
following undersired behavior occurs when the password is changed.  When opening
Thunderbird the pop account attempts to login and fails but will not prompt for
a new password until the account is locked out.  When the SMTP password fails it
immediately prompts for a new password.  The POP password should work like the
SMTP password and immediately prompt for a new password after the first failure.

Reproducible: Always
Steps to Reproduce:
1. Change password
2. Open Thunderbird
3. Attempt to get mail

Actual Results:  
Login failed repeatedly, after account lockout, then prompts for new password.

Expected Results:  
Thunderbird should have prompted for a new pop password immediately following
the first failure.

I realize a user could go to the password manager and delete the password. 
However in this workgroup environment passwords changes are frequently required.
 Having users delete passwords out of password manager would be like pulling my
own teeth.
Comment 1 Rich 2004-06-30 10:04:21 PDT
applies to version 0.7 and 0.7.1
Comment 2 Christian Eyrich 2004-07-04 12:11:39 PDT
Oh god, we have already had any situation were any of the behaviour (prompt
immediately, prompt after 3 wrong attempts, never prompt) made somebody scream
that this is wrong.

Currently the situation is nearly as bad as with the first fix from bug 160425.
The behaviour now (since bug 219162) is, if a password has proven to be valid in
*this* session it's never discarded. If this is the first login you've two tries
before discarding the password.

I guess the best solution would be modifying this further. Either by giving the
user the chance to stop authentication (via Cancel in the alert, I think this is
bug 189633) or automatically do this after say three failed tries without
discarding the password.
Comment 3 Rich 2004-07-13 05:34:23 PDT
Actually if this is the first login it tries once and fails.  The password is
not discarded.  Then when you hit get mail again it tries twice and then
discards the password.  In many environments after 3 failed attempts accounts
are locked out.  If it tried twice when opened and then prompted the lockout
would be avoided.

However what is the benefit of attempting the password multiple times?  I would
like to think that all mail systems are reliable enough for one attempt and then
discard the password if it fails.

Also a password should be immediately discarded when it fails regardless of the
session.  Passwords can be changed at any time and to assume it will not be
changed mid-session is fairly unreasonable.

Thanks,
Comment 4 Christian Eyrich 2004-07-13 06:02:49 PDT
See discussion in e.g. bug 160425 and bug 219162.

> I would like to think that all mail systems are reliable enough for one
> attempt and then discard the password if it fails.

It would be great if this were reality. We had many cases reported in which
servers failed to accept valid credentials via CRAM-MD5 or PLAIN authentication
mechanism but accepted it with LOGIN or USER/PASS (note, they advertised all
four mechanisms as being available).
So we have to fall back and try PLAIN after CRAM-MD5 and LOGIN after PLAIN
a.s.o. (Actually falling back from highest to lowest mechanism is counted as one
try, so in reality we can really issue maxtries*available mechanisms tries.)
Or scenarios in which the server says "logged in to often, please wait 5
minutes" or "mailbox in use". Discarding the password immediately in these cases
made people angry.

> Also a password should be immediately discarded when it fails regardless of
> the session.

I guess this has been implemented because it's unlikely that a server password
realy changes while the user uses the application (at least for people that only
start the mail client for getting and reading mail and then close it - so it's
open for say 20 minutes continuously).
Comment 5 Rich 2004-07-13 13:47:07 PDT
So essentially what you are stating is this software will never be usable in a
secure commercial workgroup environment?
Comment 6 Rich 2004-07-13 13:53:21 PDT
Also please note if you examine other commercial mail clients you will find they
rely upon the user to properly configure the client.  If they want MD5 or a
secure connection they must specify it, and so on.  After a failure the other
commercial applications will ask for a new password after one failure.  At some
point you have to rely upon the software and the server being properly
configured and not taking responsibility for working around their mistakes.

Also in a world going towards single sign on user accounts / password it will be
more common for passwords to change mid stream.
Comment 7 Christian Eyrich 2004-07-13 14:37:27 PDT
> Also please note if you examine other commercial mail clients you will find
> they rely upon the user to properly configure the client.  If they want MD5
> or a secure connection they must specify it, and so on.

That's AFAIK true. But that's unnecessary if 
> At some point you have to rely upon the software and the server being properly
> configured
since in this case a server would support the mechanisms it advertises properly.
So what you write is a little contradictory. Either rely or do everything by hand.
The motivation to not ask the user what mechanism to use is that most will
simply don't use any advanced function if he don't know it.

> After a failure the other commercial applications will ask for a new
> password after one failure.

Any other client I know has a password field in the server configuration and
will not discard the password at any time. But they stop at the first error
encountered.

As I wrote, we had asked for a new password at every error. And users complained
as you do now about the opposite.

> At some point you have to rely upon the software and the server being
> properly configured and not taking responsibility for working around
> their mistakes.

I know a dozend bugs reported by users where the cause was a corrupt server. But
users don't care about that, that's a fact.
Comment 8 Rich 2004-07-14 04:35:45 PDT
I know users don't care about a corrupt server, but neither should you.  You
cannot take the responsibility of making every corrupt server work and maintain
a quality piece of software.  In the end that is a great disservice to you and
especially your users.

From what you are saying, this software will never be suitable for a secure
commercial workgroup environment.  This is really a shame as it is a wonderful
piece of software with great capabilities.  If you choose to eliminate such a
large audience, that is your decision.  I will simply find another software
product for the multiple isolated secure workgroups and not look back.  

While at it we will also remove all other Mozilla applications as the intent of
the software development now appears tainted and unstable.
Comment 9 Christian Eyrich 2004-07-14 05:07:42 PDT
> I will simply find another software product for the multiple isolated secure
> workgroups and not look back.  

Well, it's up to you, but please no empty threats.

> From what you are saying, this software will never be suitable for a secure
> commercial workgroup environment.

Really? What did say?
I just explained why it is like it is and what I know about other software.
There was no "and we're not gonna change it" or something similar.

> as the intent of the software development now appears tainted and unstable.

Wow, you know what "the project" or "the maintainers" say? I don't, and I'm no
official, I'm no module owner or so. Before damn the whole software you should
have a more definitive knowledge about the further development.
Maybe David will say something about his thoughts.

Also you can't expect all jumping around to do what you want. Some constructive
critics and respect to what other users want and expect would be nice. Why
should someone make changes to the client in order to please you while this will
make other hundred people throw it away?
Comment 10 David :Bienvenu 2004-07-14 07:29:15 PDT
Er, to echo what Christian said, he was describing the way it works now, and
why, not that it couldn't and shouldn't be improved...see
http://bugzilla.mozilla.org/show_bug.cgi?id=249240#c2

If we're really talking about enterprise deployments, it's trivial to add a pref
that enterprises can customize through MCD or at install time that gets rid of
fallback and password retries, or one which specifies which authentication
mechanism to use. Adding a UI that says something like "only use most secure
authentication supported by server" might be reasonable as well. I'm a little
confused about your situation, Rich, however. Have you turned on "Use secure
authentication" in your pop3 server settings? How many secure authentication
mechanisms does your server support?

Comment 11 Christian Eyrich 2004-07-22 03:00:04 PDT
*** Bug 252044 has been marked as a duplicate of this bug. ***
Comment 12 jwq 2004-07-23 22:26:07 PDT
Bug 246291 and Bug 246542 appear to report the same password problem while using
IMAP. I believe that they might be duplicates of this bug. If they are, the
summary of this bug ought to be changed to mention both POP and IMAP (or not
mention the protocol at all).
Comment 13 Henrik Skupin (:whimboo) 2004-08-02 02:09:31 PDT
*** Bug 253983 has been marked as a duplicate of this bug. ***
Comment 14 Henrik Skupin (:whimboo) 2004-08-02 02:14:20 PDT
Yes, this should be moved to Networking: MailNews General. Duping the other
addresses.

Asking for blocker of aviary1.0PR.
Comment 15 Henrik Skupin (:whimboo) 2004-08-02 02:15:58 PDT
*** Bug 246542 has been marked as a duplicate of this bug. ***
Comment 16 Henrik Skupin (:whimboo) 2004-08-02 02:16:28 PDT
*** Bug 246291 has been marked as a duplicate of this bug. ***
Comment 17 Brian 'netdragon' Bober 2004-08-02 08:17:13 PDT
Henrik: Nice catch on changing the subject. I like the new subject a lot better.
The old one almost made it sound like the pop server should bring up the dialog ^.^
Comment 18 chris hofmann 2004-08-19 14:22:15 PDT
sounds like bienvenu might be working on this one.  plus for now.
Comment 19 Scott MacGregor 2004-08-24 17:18:57 PDT
we aren't working on this for 0.8. so this should be a minus for the firefox
1.0PR flag since that maps to .8.

We may consider it for .9/1.0
Comment 20 David :Bienvenu 2004-10-06 09:17:15 PDT
Created attachment 161273 [details] [diff] [review]
proposed fix for pop3

This patch adds a server pref that allows the user to disable logon fallback.
Then, during pop3 logon, if that pref is true (it defaults to false), then we
will not fallback on an authentication failure. There's no UI for this pref
currently, but we should consider adding on. For enterprises, they can set this
pref via MCD, if important. The reason we default to false is that there are so
many bad servers out there, as has already been discussed.

If this approach is reasonable, we can add similar code to the imap protocol
code.
Comment 21 Christian Eyrich 2004-10-06 09:50:31 PDT
(In reply to comment #20)

> This patch adds a server pref that allows the user to disable logon fallback.
> Then, during pop3 logon, if that pref is true (it defaults to false), then we
> will not fallback on an authentication failure.

You should be aware that the problem described in bug 262584 could still occur.
We'll never increase logonFailureCount (not to speak of isAuthenticated could be
true) and still loop.
You could continue with this patch and modify the one from bug 262584 (or use
the first variant I posted there but is uggly) or modify this patch so it
includes the necessary changes to prevend a loop.

Additionally, solving bug 259679 would also solve this one too because it would
define one mechanism to use and nothing else. If you/we think a fix of bug
259679 will take too long, your patch would be a ok interims solution - but IMHO
nothing more.
Comment 22 David :Bienvenu 2004-10-06 20:17:44 PDT
> modify this patch so it includes the necessary changes to prevent a loop.

what would that look like? 

re bug 259679, I think forcing the user to limit themselves to one
authentication mechanism would be confusing for a lot of users - they'd have no
idea which one to pick. Only using the most secure by default and not falling
back to less secure mechanisms by default is also going to be a support pain.
So, I think giving the user the options in bug 259679 is a good feature, but I
think out of the box we want to work on the greatest variety of servers. I think
the situation described in this bug is definitely a less common issue than the
issues we've had with bad servers so I don't mind making users with this problem
have to configure some UI.  I don't think that runs counter to anything you've
said about the relationship between this bug and bug 259679, but I just wanted
to make sure that's true.
Comment 23 Christian Eyrich 2004-10-07 02:16:15 PDT
(In reply to comment #22)
> > modify this patch so it includes the necessary changes to prevent a loop.
> 
> what would that look like? 

I can think of three ways.
Either faking authenticated and the count by putting

    m_nsIPop3Sink->SetUserAuthenticated(PR_FALSE);
    m_pop3ConData->logonFailureCount = 2;

in the action of if (TestFlag(POP3_AUTH_FAILURE) || !logonFallback) 
or doing something like

-      if (!isAuthenticated && m_pop3ConData->logonFailureCount > 1)
+      if ((!isAuthenticated && m_pop3ConData->logonFailureCount > 1) ||
+          TestFlag(POP3_AUTH_FAILURE) || !logonFallback)
         rv = server->ForgetPassword();

while logonFallback needs to be global here.
Or we set POP3_AUTH_FAILURE if !logonFallback in AuthFallback() and go with
patch v2 from bug 262584.

> re bug 259679, I think forcing the user to limit themselves to one
> authentication mechanism would be confusing for a lot of users - they'd have
> no idea which one to pick.

Sure, but if you remember, you proposed this in bug 258077, comment #17.

> So, I think giving the user the options in bug 259679 is a good feature, but I
> think out of the box we want to work on the greatest variety of servers.

Of course the default would "automatic" be as I layed out in the description and
thus the current behaviour.

> I think the situation described in this bug is definitely a less common issue
> than the issues we've had with bad servers so I don't mind making users with
> this problem have to configure some UI.

But because it's less common I think it would be tolerable to use a UI (though
the pref of bug 259679 could also be set directly). The problem for the user
would be to find out which mechanism to use. :(
Comment 24 Andrew White 2004-10-07 06:13:58 PDT
(In reply to comment #23)
> > I think the situation described in this bug is definitely a less common issue
> > than the issues we've had with bad servers so I don't mind making users with
> > this problem have to configure some UI.
> 
> But because it's less common I think it would be tolerable to use a UI (though
> the pref of bug 259679 could also be set directly). The problem for the user
> would be to find out which mechanism to use. :(

Actually, it's possible to auto-detect this if you want to.  If the default is to try all the authentication 
mechanisms one after the other, you just try them all (in some sensible order) until one works.  It would 
even be possible to set that default behaviour on startup for a new account is to try them all until 
connection is achieved, and then remember that one thereafter.

Eg Preferences:
* method 1
* method 2
* method 3
# autodetect (initially selected)

Once it successfully autodetects, it changes to that method unless the user manually switches it back to 
autodetect.  You could add another setting to try all methods every time, but that strikes me as an 
option that would rarely get used.
Comment 25 Christian Eyrich 2004-10-18 11:00:44 PDT
Created attachment 162493 [details] [diff] [review]
patch v2

This patch is a combination of David's and mine from bug 262584. This makes
sure that the user will be prompted even if already succeeded in this session
and it's the first time login fails.
If this patch is ok, we should dupe bug 262584.
Comment 26 David :Bienvenu 2004-10-18 21:01:59 PDT
Comment on attachment 162493 [details] [diff] [review]
patch v2

I should have rev'ed the uuid for nsIMsgIncomingServer - can you add a new one?
Comment 27 Christian Eyrich 2004-10-19 05:00:53 PDT
Created attachment 162572 [details] [diff] [review]
patch v2.1

Added new uuid.
Comment 28 Christian Eyrich 2004-10-28 13:05:37 PDT
Patch has been checked into trunk and aviary branch on 26th.
Comment 29 Hem Ramachandran 2004-12-03 06:43:55 PST
So, it doesn't appear on the 1.0RC1? Seems to be listed as fixed, but I still do
have problems. It is behaving the same way as before.

Another problem I am finding is, if one deletes an email account and add it
back(hoping to resolve the issue), it still saves up the old profile info,
(username/password) giving the same annoying problem. I think UNDER THE MAIL
SETTINGS THERE NEED TO BE A LOCATION TO CHANGE PASSWORD, not on a prompting basis.
Hem

(In reply to comment #28)
> Patch has been checked into trunk and aviary branch on 26th.

Comment 30 Christian Eyrich 2004-12-03 08:48:26 PST
(In reply to comment #29)
> So, it doesn't appear on the 1.0RC1? Seems to be listed as fixed, but I still
> do have problems. It is behaving the same way as before.

Yes it does. The changes where the new pref to prevent retries and stopping
login immediately if server issued [AUTH].
So if you didn't change the pref or your server uses the advanced code, nothing
changes for you.

What's your situation? The server password changed, you start TB and check
mails, an alert pops up saying the password is wrong but you don't have a chance
to enter a new one?
Or what is happening exactly?

> Another problem I am finding is, if one deletes an email account and add it
> back(hoping to resolve the issue), it still saves up the old profile info,
> (username/password) giving the same annoying problem.

Therefore TB has the password manager. If you want to manage your passwords, use it.
Comment 31 Henrik Skupin (:whimboo) 2005-01-19 15:30:29 PST
> What's your situation? The server password changed, you start TB and check
> mails, an alert pops up saying the password is wrong but you don't have a chance
> to enter a new one?
> Or what is happening exactly?

This happens for me with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20050116 Thunderbird/1.0. When starting TB I get this popup four times.
IMO TB should stop authenticating to the server after the first login fails -
the other 3 times will result in the same warning. 

The solution - what the summary also describes - would be to show the password
dialog. The user should be able to input the new password directly. Why he
should do that over the password manager? Every other client asks for a new
password when the login fails. 

I reopen this bug because the current solution isn't that one which is described
in the summary.
Comment 32 Christian Eyrich 2005-01-20 06:59:58 PST
(In reply to comment #31)

> This happens for me with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
> Gecko/20050116 Thunderbird/1.0. When starting TB I get this popup four times.
> IMO TB should stop authenticating to the server after the first login fails -
> the other 3 times will result in the same warning. 

But we show the password dialog right on the first error - if we can be sure
it's a password problem, i.e. the server send [AUTH].
As I wrote in comment #2 directly discarding the password/showing the password
dialog as we did before also made people scream.
Comment 33 Hem Ramachandran 2005-01-20 07:29:18 PST
In my opinion, the best way would be to have a password box just under the
username under Server Settings. And have a check box to save it.
That would require different handling of the password pop up box. Might even
completely eliminate it, and ask with a popup box - if the password is wrong- to
go to Server settings and reenter it.
Comment 34 Christian Eyrich 2005-01-20 07:38:22 PST
(In reply to comment #33)
> In my opinion, the best way would be to have a password box just under the
> username under Server Settings.

Well, in a better world the current behaviour would be perfect. Since we have to
live with this world, what you wrote has also become in the last months.

But that is a different (IMHO already existing) bug, no?
Comment 35 Henrik Skupin (:whimboo) 2005-01-20 13:53:07 PST
Mmh but there isn't a chance to stop the login process. The dialog only tells me
that my password is not correct and I have to click OK. Why there isn't a cancel
button? I have to wait until TB tried logging in 4 times without a positive
effect. If I know that the password has changed I would prefer to stop the
process immediately after the first failure. 

I've taken a look at the patches. Where is the part for an IMAP server? I can
only see changes for the POP3 protocol. Any reason why there is no IMAP patch
while the summary of that bug enclose this protocol?
Comment 36 Hem Ramachandran 2005-02-03 07:41:52 PST
Well, at least, I can go back and redo the password and try it again.
Yes, I see your point, it need to prompt for password again, if it cannot log
in. It can be as simple as that. I have a feeling that the this problem is fixe
d in POP, but not on IMAP. But I am not sure. Sorry, I am not a geek, don't look
at code, so I dont know where things are. Just an end user.

(In reply to comment #35)
> Mmh but there isn't a chance to stop the login process. The dialog only tells me
> that my password is not correct and I have to click OK. Why there isn't a cancel
> button? I have to wait until TB tried logging in 4 times without a positive
> effect. If I know that the password has changed I would prefer to stop the
> process immediately after the first failure. 
> 
> I've taken a look at the patches. Where is the part for an IMAP server? I can
> only see changes for the POP3 protocol. Any reason why there is no IMAP patch
> while the summary of that bug enclose this protocol?
Comment 37 Jack Eidsness 2005-03-30 22:03:58 PST
*** Bug 288393 has been marked as a duplicate of this bug. ***
Comment 38 Mike Cowperthwaite 2005-04-19 12:41:55 PDT
*** Bug 290805 has been marked as a duplicate of this bug. ***
Comment 39 John David Galt 2005-05-16 21:24:48 PDT
*** Bug 293106 has been marked as a duplicate of this bug. ***
Comment 40 Neil J. McLeish 2005-09-04 09:03:26 PDT
I reported this a while back too.  In my opinion, it is simply a matter of
usability (Ref: Schneidermann, Nielson et al.):  The user must feel that they
are in control.  This behaviour violates that directive.

In addition to this, virtually every other commonly used mail client discards an
invalid or failed password immediately. Therefore, for consitency's sake,
Thunderbird should exhibit the same behaviour.

Neil McLeish
Comment 41 Henrik Skupin (:whimboo) 2006-03-15 00:27:55 PST
It's still existent in Thunderbird version 1.5 (20051201) and Exchange IMAP server. Can we get this for TB 2.0?
Comment 42 David :Bienvenu 2006-04-20 13:36:44 PDT
Created attachment 219189 [details] [diff] [review]
work in progress

this patch makes it so when the pop3 password changes, we will reprompt. It also makes it so we'll fill in the previously sent password in the password dialog, if any. To do that, I had to stop doing getter_Copies on the return password, which made me do some extra string allocation/copying/freeing, that I'd like to figure out how to avoid.
Comment 43 David :Bienvenu 2006-05-22 16:04:21 PDT
Created attachment 222962 [details] [diff] [review]
proposed fix

this makes it so when we reprompt, we auto-fill in the dialog with the last password sent (which probably failed, but we don't know why...). I'd like to get this some baking on the trunk.
Comment 44 Scott MacGregor 2006-05-22 16:08:18 PDT
Comment on attachment 222962 [details] [diff] [review]
proposed fix

+      //nsXPIDLString uniPassword;

should we just remove that line?

+      nsCString aCStr; aCStr.AssignWithConversion(uniPasswordAdopted); 

two lines?
Comment 45 David :Bienvenu 2006-05-23 10:19:01 PDT
fixed on trunk - I'll land on branch when it has baked on the trunk for a bit.
Comment 46 David :Bienvenu 2006-05-23 10:19:39 PDT
Comment on attachment 222962 [details] [diff] [review]
proposed fix

approving for 1.8.1 branch
Comment 47 Worcester12345 2006-05-24 09:04:13 PDT
version is listed as 1.0 branch.

Will this also go onto the 1.8.0.x branch?
Comment 48 David :Bienvenu 2006-05-24 09:06:48 PDT
no, I doubt it. Trunk and 2.0 branch only, most likely.
Comment 49 David :Bienvenu 2006-06-26 11:45:11 PDT
fixed on 1.8 branch as well
Comment 50 Scott MacGregor 2006-07-17 16:12:49 PDT
flag cleanup
Comment 51 David :Bienvenu 2006-08-10 08:13:33 PDT
*** Bug 296447 has been marked as a duplicate of this bug. ***
Comment 52 David :Bienvenu 2006-08-10 12:03:15 PDT
you'll need this fix if you want the fix for bug 286628 .
Comment 53 Daniel Veditz [:dveditz] 2006-08-10 12:22:24 PDT
Comment on attachment 222962 [details] [diff] [review]
proposed fix

approved for 1.8.0 branch, a=dveditz for drivers
Comment 54 David :Bienvenu 2006-08-10 14:36:10 PDT
fixed for 1.5.0.7
Comment 55 Marcia Knous [:marcia - use ni] 2006-09-07 10:37:49 PDT
Can folks that are having this issue please try the Tbird build in this directory (ftp://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/1.5.0.7-candidates/rc4) and confirm that this bug is fixed? Thanks.
Comment 56 Henrik Skupin (:whimboo) 2006-09-07 11:02:56 PDT
(In reply to comment #55)
> Can folks that are having this issue please try the Tbird build in this
> directory

It is not fixed for any version of Thunderbird. I've tested following win32 versions:

* version 1.5.0.7 (20060906)
* version 2 alpha 1 (20060906)
* version 3 alpha 1 (20060907)

Changing the password for my POP3 account let's Thunderbird infinitely repeat the user/pass combination and only shows me the error dialog.

=> Reopen
Comment 57 Daniel Veditz [:dveditz] 2006-09-07 11:16:58 PDT
I'd say this definitely blocks Thunderbird 2.0, and we'll take it in 1.5.0.x when it's really fixed. But at this point I don't think we hold Thunderbird 1.5.0.7 for this.
Comment 58 David :Bienvenu 2006-09-07 11:58:30 PDT
Henrik, can you attach a pop3 protocol log of a session where your password has been changed so I can see which authentication mechanism is used and what error the server returns?
Comment 59 Henrik Skupin (:whimboo) 2006-09-07 12:46:41 PDT
Created attachment 237170 [details]
POP3 logfile after changing password externally

I'm using Courier mail server. Here its output from mail.log

Sep  7 21:36:05 xxx courierpop3login: LOGIN FAILED, ip=[::ffff:84.57.233.245]
Sep  7 21:36:06 xxx courierpop3login: LOGIN: DEBUG: ip=[::ffff:84.57.233.245], command=CAPA
Sep  7 21:36:06 xxx courierpop3login: LOGIN: DEBUG: ip=[::ffff:84.57.233.245], command=USER
Sep  7 21:36:06 xxx courierpop3login: LOGIN: DEBUG: ip=[::ffff:84.57.233.245], command=PASS
Sep  7 21:36:06 xxx courierpop3login: LOGIN: DEBUG: ip=[::ffff:84.57.233.245], username=%username%
Sep  7 21:36:06 xxx courierpop3login: authdaemon: starting client module
Sep  7 21:36:06 xxx courierpop3login: authdaemon: REJECT
Comment 60 Henrik Skupin (:whimboo) 2006-09-08 01:44:54 PDT
Created attachment 237307 [details]
IMAP4 log of failed authentication
Comment 61 Worcester12345 2006-09-13 08:53:20 PDT
This is now a showstopper here. Is there a key or any way to fix this? I tried an older version (1.5 and 1.5.0.6), but I think the settings were already set and cannot be undone. 

Thanks.
Comment 62 David :Bienvenu 2006-09-13 09:32:20 PDT
no, you need to go into the password manager and delete the password...1.5.0.5 and 6 had the same bug.
Comment 63 Henrik Skupin (:whimboo) 2006-09-13 10:02:13 PDT
David, were the log files helpful for you? Or do you need any further information?
Comment 64 David :Bienvenu 2006-09-13 10:04:50 PDT
Henrik, no, those were helpful. I just have to try it out with my servers...I'm just doing that now. 
Comment 65 David :Bienvenu 2006-09-13 10:14:14 PDT
ok, my pop3 server does auth login, where this works as expected...I'll turn off auth login and try to recreate the problem you're seeing.
Comment 66 David :Bienvenu 2006-09-13 10:31:27 PDT
It still works when I turn off auth login so TB does user <user> login just like in your pop3 log. This is on the trunk, when I've changed the password before starting TB.  I'm not sure what would be different about your case, Henrik. Do you have a master password set? There was a bit of weirdness where TB tried to do a stat after the failed logon before reprompting for the password...maybe that's somehow involved. 
Comment 67 David :Bienvenu 2006-09-13 10:43:54 PDT
Henrik, perhaps it's because you're trying to do an auth login, which is failing, and then we fall back to normal logon, and get confused when the password is wrong. You might try turning off auth logon by going into the config editor and searching for auth_login, and toggling the prefs you see to false, and see if it works better after that. I'll try to figure out a way to simulate your situation, but it's tricky because my server supports auth logon.
Comment 68 Worcester12345 2006-09-13 10:44:58 PDT
(In reply to comment #62)
> no, you need to go into the password manager and delete the password...1.5.0.5
> and 6 had the same bug.
> 

There IS NO PASSWORD in password manager. It is completely blank. That is part of the problem.
Comment 69 David :Bienvenu 2006-09-13 11:19:13 PDT
Henrik, do you have the ability & time to apply and build patches? Unless I can find a pop3 server that doesn't support AUTH, I'm going to have to try to guess at a fix, because the pop3 auth fallback code is complicated...
Comment 70 Henrik Skupin (:whimboo) 2006-09-13 12:26:16 PDT
(In reply to comment #69)
> Henrik, do you have the ability & time to apply and build patches? Unless I can
> find a pop3 server that doesn't support AUTH, I'm going to have to try to guess
> at a fix, because the pop3 auth fallback code is complicated...

David, I don't have a build system at the moment. That's why I don't have the ability to build my own Thunderbird. But I have another solution. I could give you a POP3/IMAP account on my server. I think that would help you much. You can reach me on Moznet. My nick is whimboo.

Comment 71 Henrik Skupin (:whimboo) 2006-09-13 12:35:47 PDT
I forgot, no I don't have set a master password.(In reply to comment #67)
> password is wrong. You might try turning off auth logon by going into the
> config editor and searching for auth_login, and toggling the prefs you see to
> false, and see if it works better after that. I'll try to figure out a way to
> simulate your situation, but it's tricky because my server supports auth logon.

No, that doesn't help. Turning off auto login shows me the warning dialog (login failed) 4 times and stopps afterwards. Later tries results in one warning dialog and a STAT failure dialog. But I don't have the chance to change my password. There is no such dialog. I really think it is better when you can test it for your own.
Comment 72 David :Bienvenu 2006-09-13 12:48:19 PDT
Henrik, it turns out that one of my mail servers shows this same bug for pop3 (I was only using it with IMAP, so I didn't see it before). So I'm debugging that. I may need to get a test account to recreate the problem you're seeing with IMAP (it's completely separate code, believe it or not).
Comment 73 Henrik Skupin (:whimboo) 2006-09-13 12:57:01 PDT
(In reply to comment #72)
> Henrik, it turns out that one of my mail servers shows this same bug for pop3
> (I was only using it with IMAP, so I didn't see it before). So I'm debugging
> that. I may need to get a test account to recreate the problem you're seeing
> with IMAP (it's completely separate code, believe it or not).

I've sent you a message with the needed account data. You should see the problem immediately. By the way I can see the same behavior after changing my password on an Exchange Server 2003 and accessing it by IMAP.
Comment 74 David :Bienvenu 2006-09-13 15:24:41 PDT
Created attachment 238302 [details] [diff] [review]
fix case where username contains a '.'

The remaining bug was that if the username contained a '.', we were failing to remove the bad password from the password manager because the process of converting the server uri string to an actual URI was escaping the '.'. So we were adding the password using an unescaped '.' but trying to remove it using a uri that when wallet got the spec, was escaped, and so didn't match. So the fix was to use the password manager RemoveUser interface directly, which takes a uri string instead of a uri object.
Comment 75 David :Bienvenu 2006-09-13 16:13:08 PDT
fixed on trunk - I'll wait to see if this fixes it for Henrik before landing on the 2.0 branch
Comment 76 Henrik Skupin (:whimboo) 2006-09-13 22:04:04 PDT
(In reply to comment #75)
> fixed on trunk - I'll wait to see if this fixes it for Henrik before landing on
> the 2.0 branch

I'll test it as soon as a new trunk build is available. Thanks David.

Comment 77 Henrik Skupin (:whimboo) 2006-09-14 12:18:53 PDT
With version 3 alpha 1 (20060914) I get asked now. But why do we try to login three more times after we still got the response that the login had failed? Can't we display the password dialog immediately after we got a login error? 
Comment 78 David :Bienvenu 2006-09-14 12:30:32 PDT
we do that for imap because some servers advertise certain authentication mechanisms, but always fail when you use them - we retry to fall back to other authentication mechanisms - maybe we should only put up the logon failed alert after the final one fails...
Comment 79 Henrik Skupin (:whimboo) 2006-09-14 12:45:44 PDT
(In reply to comment #78)
> authentication mechanisms - maybe we should only put up the logon failed alert
> after the final one fails...

Yes, this is a great idea. I'll open a new bug for that issue later today.
Comment 80 David :Bienvenu 2006-09-14 12:49:53 PDT
fix for account name with '.' in user name checked into 1.8.1 branch
Comment 81 David :Bienvenu 2006-09-14 12:50:48 PDT
Comment on attachment 238302 [details] [diff] [review]
fix case where username contains a '.'

requesting 1.8.0.8 approval - user names with '.' in them are becoming much more common.
Comment 82 Daniel Veditz [:dveditz] 2006-09-19 15:35:59 PDT
Restoring lost blocking flag
Comment 83 Daniel Veditz [:dveditz] 2006-09-26 14:44:55 PDT
Comment on attachment 238302 [details] [diff] [review]
fix case where username contains a '.'

approved for 1.8.0 branch, a=dveditz for drivers
Comment 84 Jo Hermans 2006-12-29 15:18:31 PST
*** Bug 365327 has been marked as a duplicate of this bug. ***
Comment 85 Jo Hermans 2006-12-29 15:25:06 PST
*** Bug 365347 has been marked as a duplicate of this bug. ***
Comment 86 donotcare 2009-12-21 07:51:54 PST
According to all the dupes pointing here, this must be the place to post my problem, although it has nothing to do with a changed password.

I always type my IMAP account password in manually.  If I accidentally mistype it, T'bird 3 does not give a prompt that says the login failed, please re-enter the password.  Instead, the status text in the lower-left of the just keeps saying  "Sending authenticate login unformation..."  This is contrary to how Thunderbird 2 worked.

This problem occurs in 3.0 release and 3.0.1pre (nightly build 20091220033857).
Comment 87 David :Bienvenu 2009-12-21 08:05:42 PST
donotcare, can we get an IMAP protocol log of a session where that happens? https://wiki.mozilla.org/MailNews:Logging

thx. And if you want to just send it to me at bienvenu@mozillamessaging.com, instead of posting it here, that would be fine. It won't contain your password, but it will tell us a little about what it tried to do.
Comment 88 donotcare 2009-12-21 09:01:56 PST
[also emailed bienvenu privately as requested]

Here is an IMAP log which shows Tbird getting the password failure. I entered the wrong password (remember password is UNchecked), and Thunderbird gave no indication that the login had failed.  I clicked on a few folders, and they either showed up empty, or showed the cached messages from the initial login during account creation (with the correct password as forced by the Account 
Wizard).

Thunderbird did not prompt me at all, it just kept using the wrong password everytime I clicked on a folder or message.

NOTE:  in the logfile I have replaced my real userid with USERID%40EXAMPLE%2ECOM@imap.example.com and my real IMAP server hostname with imap.example.com .

Thunderbird 3.0.1pre (nightly 20091220033857) on Windows XP.

Thanks,
Comment 89 donotcare 2009-12-21 09:03:05 PST
Created attachment 418663 [details]
donotcare's IMAP log showing password failures
Comment 90 David :Bienvenu 2009-12-21 10:45:29 PST
Thx, yep, it's definitely broken - this may have to do with auth=plain auth being broken in TB 3 with a bad password. I remember BenB making noises to that effect. I think we need a new bug for this.
Comment 91 donotcare 2010-02-04 09:43:08 PST
Hello, I still am seeing this today with Thunderbird 3.0.1 release and 3.0.2pre (Shredder) and also 3.1b1pre (Lanikai).  All on Windows XP.

The problem occurs with one of my IMAP servers (fastmail.fm, SSL) but not on another one (cyrus-imapd-2.3.14-3, TLS).

Again, my issue is when an incorrect IMAP password is entered, TB does not give any "failed login" type of message, and does not prompt for password re-entry.  It keeps using the bad password, and the user is given no indication of the password failure whatsoever.  The user will see any locally cached messages, but obviously no new messages from the IMAP server.

Attaching a new IMAP:5 trace log.  I replaced my user id with "USERID".
Comment 92 donotcare 2010-02-04 09:45:21 PST
Created attachment 425227 [details]
donotcare's new log 2010-FEB-04 (using 3.1b1pre)
Comment 93 David :Bienvenu 2010-02-04 14:00:55 PST
this regressed with the new password management stuff, I believe, in the case of the server dropping the connection after an authentication error. I'm not sure if there's a new bug open on the regression (there need to be separate bugs for imap/pop3/smtp, because the fixes are all distinct, unfortunately). I have a patch somewhere in a bug for the imap case, though I haven't been able to test it.
Comment 94 Michael A. Pasek 2010-08-06 09:17:08 PDT
(In reply to comment #93)
> this regressed with the new password management stuff [...]

Yep, it did.  Looks like Bug 505481 was reopened for this case (I'll add corroborating info there).

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