249240 - Password dialog for POP/IMAP server does not reprompt when password is changed externally.

Status: VERIFIED FIXED

(MailNews Core :: Networking, defect)

Description

[Rich]

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]

applies to version 0.7 and 0.7.1

Comment 2

[Christian Eyrich]

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]

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]

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]

So essentially what you are stating is this software will never be usable in a
secure commercial workgroup environment?

Comment 6

[Rich]

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]

> 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]

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]

> 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]

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]

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

Comment 12

[jwq]

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][⌚️UTC+2]]

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

Comment 14

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Yes, this should be moved to Networking: MailNews General. Duping the other
addresses.

Asking for blocker of aviary1.0PR.

Comment 15

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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

Comment 16

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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

Comment 17

[Brian 'netdragon' Bober]

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]

sounds like bienvenu might be working on this one.  plus for now.

Comment 19

[Scott MacGregor]

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]

Attachment: 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]

(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]

> 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]

(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]

(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]

Attachment: 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]

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]

Attachment: patch v2.1

Added new uuid.

Comment 28

[Christian Eyrich]

Patch has been checked into trunk and aviary branch on 26th.

Comment 29

[Hem Ramachandran]

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]

(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][⌚️UTC+2]]

> 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]

(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]

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]

(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][⌚️UTC+2]]

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]

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]

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

Comment 38

[Mike Cowperthwaite]

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

Comment 39

[John David Galt]

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

Comment 40

[Neil J. McLeish]

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][⌚️UTC+2]]

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]

Attachment: 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]

Attachment: 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]

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]

fixed on trunk - I'll land on branch when it has baked on the trunk for a bit.

Comment 46

[David :Bienvenu]

Comment on attachment 222962 [details] [diff] [review]
proposed fix

approving for 1.8.1 branch

Comment 47

[Worcester12345]

version is listed as 1.0 branch.

Will this also go onto the 1.8.0.x branch?

Comment 48

[David :Bienvenu]

no, I doubt it. Trunk and 2.0 branch only, most likely.

Comment 49

[David :Bienvenu]

fixed on 1.8 branch as well

Comment 50

[Scott MacGregor]

flag cleanup

Comment 51

[David :Bienvenu]

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

Comment 52

[David :Bienvenu]

you'll need this fix if you want the fix for bug 286628 .

Comment 53

[Daniel Veditz [:dveditz]]

Comment on attachment 222962 [details] [diff] [review]
proposed fix

approved for 1.8.0 branch, a=dveditz for drivers

Comment 54

[David :Bienvenu]

fixed for 1.5.0.7

Comment 55

[Marcia Knous [:marcia]]

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][⌚️UTC+2]]

(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]]

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]

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][⌚️UTC+2]]

Attachment: 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][⌚️UTC+2]]

Attachment: IMAP4 log of failed authentication

Comment 61

[Worcester12345]

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]

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][⌚️UTC+2]]

David, were the log files helpful for you? Or do you need any further information?

Comment 64

[David :Bienvenu]

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]

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]

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]

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]

(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]

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][⌚️UTC+2]]

(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][⌚️UTC+2]]

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]

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][⌚️UTC+2]]

(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]

Attachment: 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]

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][⌚️UTC+2]]

(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][⌚️UTC+2]]

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]

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][⌚️UTC+2]]

(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]

fix for account name with '.' in user name checked into 1.8.1 branch

Comment 81

[David :Bienvenu]

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]]

Restoring lost blocking flag

Comment 83

[Daniel Veditz [:dveditz]]

Comment on attachment 238302 [details] [diff] [review]
fix case where username contains a '.'

approved for 1.8.0 branch, a=dveditz for drivers

Comment 86

[donotcare]

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]

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 [e-mail], 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]

[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 [e-mail] and my real IMAP server hostname with imap.example.com .

Thunderbird 3.0.1pre (nightly 20091220033857) on Windows XP.

Thanks,

Comment 89

[donotcare]

Attachment: donotcare's IMAP log showing password failures

Comment 90

[David :Bienvenu]

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]

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]

Attachment: donotcare's new log 2010-FEB-04 (using 3.1b1pre)

Comment 93

[David :Bienvenu]

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]

(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).