Closed Bug 219162 Opened 21 years ago Closed 20 years ago

Password Manager forgets password when checking mail

Categories

(MailNews Core :: Networking: POP, defect)

Product:
MailNews Core
Component:
Networking: POP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: raccettura, Assigned: Bienvenu)

References

Details

(Keywords: fixed1.5)

Attachments

(2 files)

proposed fix
2.08 KB, patch
ch.ey
: review+
mscott
: superreview+
asa
: approval1.5+
Details | Diff | Splinter Review
proposed fix
11.21 KB, patch
mscott
: superreview+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030912
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030912

Several times in the past week, Mozilla has started forgetting my password when
checking mail.  It will keep prompting me for a password.  

Quitting and reopening Mozilla, and entering my password, will fix it for
several hours...

rince and repeat.

Definately not a mail server problem.  Another email client is working just
fine, no interuptions.

Reproducible: Always

Steps to Reproduce:
I confirm this !
I got this problem several times. It could be that the server answers with an
error during the login but i couldn't see an error popup.

Christian: Is it possible that Mozilla displays no error message from the server
in such a case ?

I don't think the server is giving an error.  Looks to me like it's just 
forgetting the password.

Either way, it looks like a serious regression for 1.5 (not sure if it impacts 
1.4.1)  IMHO blocker, but I'll let someone else make that decision as I'm 
not important.
We indeed changed the behaviour on failure to prevend loops. But this should
make PM forget the PW only in case of error.

Robert, please change Product to MailNews and the Component to the protocol
you're using to get mail (POP3, IMAP). Or do you have this problem with both
protocols? Matti, what protocol are you using?

It's possible to get no error message displayed if you have checked your mail
automatically background. But for manual mail check I don't think so.

A communications log would be best again. But not that easy to create in this
case as it doesn't happen always, right?

I use pop3 and I know that my server sometimes respons with an error but I never
get a error message with recent builds and the password is sometimes lost.

I know that the password is lost due to the other reopened bug (btw: I hate it
!) but older builds displayed the server error message.

> I use pop3 and I know that my server sometimes respons with an error but I never
> get a error message with recent builds and the password is sometimes lost.

You _know_, your server sometimes respons with an error? Do you know with what
error? Or know how to produce?
Without knowing the error or the situation in which it occurs I cannot tell why
it's not displayed. IMO we don't hide errors except when auto check is active.

> I know that the password is lost due to the other reopened bug (btw: I hate it
> !) but older builds displayed the server error message.

I guess you speak of bug 160425. That might be, yes and it's your right to hate
it. But before reopening that patch other people hated the old behaviour ...
for my case :
just let mozilla autocheck and get this error popup with Mozilla1.4 :
"The PASS command did not suceed. Mail server foo responded: les: fatal: unable
to move /home/vpopmail/etc/tcp.smtp.tmp.2108 to /home/vpopmail/etc/tcp.smtp.cdb:
file does not exist"

A log could be difficult (size) because I get this only sometimes (every 1-2h
with a 5 minute auocheck)

My password is lost (bug 160425) but the error doesn't display with a nightly trunk
Changing to mail&news, flagging blocking1.5 as it seems I'm not the only one
with this issue (and I continue to see it).
Component: Password Manager → Networking: POP
Product: Browser → MailNews
Is this blocking 1.5?  I personally find this a blocker.  Not sure how wide
spread it is.  I like it to remember my password, as entering it every few
minutes is a real pain.

Lastly, can someone change this to "new"
Flags: blocking1.5?
I'd rather dupe this bug to bug 160425.
All aspects of this bug are covered by that - except that you say, you don't get
an error message. But that's only an issue if you auto check your account.

> Not sure how wide spread it is.

I don't think that wide spread. It affects users using faulty servers. Good
servers only throw an error in answer to password if the password is wrong.

I don't wanna say, this bug can't be annoying. And I don't wanna say it
shouldn't be fixed. But this Mozilla bug is only a symptom of a server bug.
At least as far I can see from the informations provided here.
bug 160425 looks like an old bug.  This is a *new* issue.  

There was no problem in 1.4, 1.3, 1.2, 1.1, 1.0, or any other release in my memory.

I'm using the same mail server since May 03, and another one since Sept. 02.  I
even tried one that I stopped using way back... and it had the same result.  3
mail servers that worked with previous versions.

So it's not the server, it's Mozilla, as previous versions (anything below 1.5)
didn't have a problem.

IMHO it's a new bug, because it's a different issue with the same impact on the
end user.

This bug, doesn't apply to anything other than 1.5 (1.4.1 I haven't tested, but
I know 1.4 doesn't have this issue).

So it's different because it doesn't matter what the mail server is or does. 
AND it only effects 1.5+ that I can see.  bug 160425 should effect all versions
to my understanding.
> There was no problem in 1.4, 1.3, 1.2, 1.1, 1.0, or any other release in my
> memory.

Because the former patch for bug 160425 was backed out on 2003-07-30, short
after relaese of 1.5a.
This patch made that passwords saved more than 15 minutes ago never be discarded
- even if they were wrong.

> So it's not the server, it's Mozilla, as previous versions (anything below
> 1.5) didn't have a problem.
> So it's different because it doesn't matter what the mail server is or does. 

Ah great, so you think Mozilla discard the passwords randomly, without any
signal from the server, yes?

Ok, so your original Product and Component would have been right. But I can't do
 anything against it. I won't go hunting a random error that occurs without a
visible reason.
> Because the former patch for bug 160425 was backed out on 2003-07-30, short
> after relaese of 1.5a.
> This patch made that passwords saved more than 15 minutes ago never be 
> discarded
> - even if they were wrong.

It can happen repeatedly.  can happen after 1 minute, or several hours.


> Ah great, so you think Mozilla discard the passwords randomly, without any
> signal from the server, yes?

Can't confirm that, but it's my belief.  I can't packet sniff, on a school
network for legal reasons... so I can't really say.  

> Ok, so your original Product and Component would have been right. But I can't 
> do anything against it. I won't go hunting a random error that occurs without 
> a visible reason.

I think it was password manager, though I will let someone else change it back
if they feel it's more qualified.  I'm not quite sure.

I don't see random errors, or any other problems other than this.
mscott, ssptizer, bienvenu, can one of you take a look at this?
I still see this problem on RC1.  I can't find any pattern to this.  "it just
happens from time to time".  To get it to take my password successfully again, I
need to quit Mozilla, open mozilla again, enter my password, and check save to
password manager.

Then I'm good for a while.
Christian, might your patch to look err codes for pop3 servers with CAPA help
here? I think I checked that into 1.6. Could we get a log from someone who sees
this? Then we could tell if the server in question has the CAPA extension and if
so, if the problem is likely to be fixed.
Assignee: dveditz+bmo → bienvenu
Status: UNCONFIRMED → NEW
Ever confirmed: true
I see this sometimes 2-5 times a day... sometimes not for 2-3 days.  Just had it
this morning.

Teach me how to log, and I will log.  Hopefully catch this.  It's real annoying.
 Password Manager is very unappreciated until it doesn't seem to work for you. 
Then you realize how great it is.
ah, sorry, I thought there were already instructions. Follow these instructions
for POP3:

http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap
Should the value be:
Variables: NSPR_LOG_MODULES   Value: IMAP:5 

?
no, setenv NSPR_LOG_MODULES=POP3:5
That would explain why it wasn't logging anything.

Off to logging.  Hopefully back sooner than later with something useful.
David, the patch could help if the cause is an -ERR sent by mistake.

But, five days ago Robert denied the problem can be caused by a server answer.
And even if the server sends -ERR this can only be the reason for discarding the
password. But wouldn't explain why Robert has to quit Mozilla and open it again
before it takes the password again.

Will see the log tomorrow.
It's now logging... hopefully the problem will manifest again so we can see.


I try re-entering the password when prompted, but it just keeps asking me again
and again and again.  Never actually checking.

Restarting Mozilla corrects it.
no, that doesn't explain why he has to quit and restart - we'll just have to see
the log and hope it has something helpful.
Ok, I got something, a little different from the error before (this is the first
time I've gotten it with 1.5rc1).  In 1.7MB Log file.

Since this log does contain some email information, I would perfer the bug be
considered security if possible.  I'm not exacly thrilled on posting it to the
general public (would take quite some time to clean up the log... and not sure
if that would negatively effect it's validity).
It apparantly starts after a set of binary characters (which no text editor I
have can read).

It then reads as follows
--------------------------- Log ---------------------------
4018]: POP3: Entering state: 2
0[274018]: POP3: Entering state: 4
0[274018]: RECV: +OK <c23c9b1ddc10770290c90a5e3faee30c@green>
0[274018]: POP3: Entering state: 31
0[274018]: POP3: Entering state: 5
0[274018]: SEND: USER robert@accettura.com

0[274018]: Entering NET_ProcessPop3 28
0[274018]: POP3: Entering state: 3
0[274018]: RECV: +OK Tell me your password.
0[274018]: POP3: Entering state: 32
0[274018]: POP3: Entering state: 6
0[274018]: Logging suppressed for this command (it probably contained
authentication information)
0[274018]: Entering NET_ProcessPop3 78
0[274018]: POP3: Entering state: 3
0[274018]: RECV: -ERR Unable to open mailbox; it may be locked by another
concurrent session.
0[274018]: POP3: Entering state: 7
0[274018]: POP3: Entering state: 24
0[274018]: POP3: Entering state: 0
0[274018]: POP3: Entering state: 25
--------------------------- /Log ---------------------------


To me the question is what's happening before (where those binary characters are)?

This is the only intelegent (readable) portion of the log.  
A few lines before the start of the snap you posted is binary crap?

You can e-mail the whole unchanged log to my address if you like. You could use
a hex editor to cut the 1.7 MB file down before. But is no must.
Robert sent me a complete log file. The printable text is the same like in
comment #25. But it also contains two confusing things:

1. the file is filled with over hundred KB of null bytes (0x0) before the
printable text (the 1.7 MB log he mentioned is almost all 0x0 too).
2. behind the string SEND: USER robert@accettura.com the log contains a single
0x0d (CR) (hence the additional line break in the log above).

I don't think this is the cause of Roberts problem. But maybe another symptom of
the problem.
If Mozilla writes out thousands of null bytes, something is really wrong.
Here's why we dropped the password:

 POP3: Entering state: 3
0[274018]: RECV: -ERR Unable to open mailbox; it may be locked by another
concurrent session.

We can't tell this logon failure from a bad password failure. I'm not sure why
the server couldn't open the inbox but I don't think it was Mozilla that had the
session open. I think the only way we can handle this, other than sniffing the
error returned by the server to see if it mentions password, the only think I
can think to do is check if we've been authenticated to this pop3 server in the
current mozilla session, and if so, don't drop the password. Or, if the password
is in the password manager, we could just try it again one more time and see if
the error is temporary...

I don't know what the null bytes in the log are - that's very odd.
Status: NEW → ASSIGNED
David,

Is this a change of functionality since 1.4?  In 1.4 I had no problems.  In
1.5b+ (never used 1.5a)  I see the problems.
yes, it's a change since 1.4. With 1.4, if your password changed, we would just
continually logon with the original password, and fail, and never prompt the
user for the new password. So we made it so if the logon failed, we forgot the
password. Unfortunately, POP3 is really primitive about error codes and so on,
so the client basically has to guess. 
Well your little change is annoying the ____ out of me ;-)

It's driving me nuts.  Any chance on getting some sort of solution in for 1.5? 
It's making mail&news seriously stink.  I can't just trust it to check my mail
on interval anymore... that's a big regression (to me personally).
I realize it's a painful problem. I doubt this will get into 1.5 (since we don't
even have a fix) but we would try to get it into 1.5.1 or something like that.
Robert, if you've influence on the servers software, choose one (or an
enhancement) that implements the Extended POP3 Response Codes from RFC 2449
(especially [IN-USE]) or RFC 3206. This makes POP3 error codes more meaningful.

David, your suggestion from comment #28 would be easy to implement.
If a login succeeded, we set a flag and if login fails later, we'd handle it
like POP3_STOPLOGIN.
Besides I hate workarounds for silly servers I hope this won't have another
annoying side effect.
yes, we already have such a flag in the nsIMsgIncomingServer:
GetIsAuthenticated() I think it does the right thing for us. If the password has
been saved in password manager, returns true, or if a logon has succeeded in the
current session. This will allow us to specialize the case where the user is
trying to logon to a server w/o a stored password for the first time in a
session. I'll attach a patch shortly. This will have to go into 1.6 first, so,
Robert, once I check in, you would need to try 1.6 to verify this is fixed for
you. If it is verified, we can try to get it into 1.5 final or 1.5.1
Not exactly thrilled about using 1.6 (pre alpha)... 

but if it's required.

Ok.
Attached patch proposed fix — — Splinter Review 
this is as I described earlier. It worked for me in the case I tried (which is
bringing up webmail and bonking get new mail simultaneously until I got an
error). I think it will work for the biff case too.
Attachment #131969 - Flags: superreview?(scott)
Attachment #131969 - Flags: review?(ch.ey)
Attachment #131969 - Flags: superreview?(scott) → superreview+
Comment on attachment 131969 [details] [diff] [review]
proposed fix

That doesn't convince me.
If I understand the parch correctly, the password should be discarded every
time if not saved. If saved, we have two chances before it will be discarded.

What if the server throws two or three errors after another before it's alright
again? Or say about one minute? With your patch the get will performed
immediately after the user presses ok and very likely produce more than one
failure.

Or what if through a failure the mailbox is really in-use? The server will
close the connection in this case -> nsPop3Protocol will be deleted and
logonFailureCount reset to 0.
So the count is useless.
Attachment #131969 - Flags: superreview?(scott)
Attachment #131969 - Flags: superreview+
Attachment #131969 - Flags: review?(ch.ey)
Attachment #131969 - Flags: review-
this patch assumes the inability to open the folder is temporary. It is POP3,
after all - no one should be holding onto the connection for a long time. The
time it takes the user to dismiss the warning alert is probably sufficient for
the mailbox lock to get released. It certainly was in the case I was able to
reproduce.

>nsPop3Protocol will be deleted and logonFailureCount reset to 0.
>So the count is useless.

Well, in this case, we won't forget the password. So I wouldn't say it's
useless. It does what we want.

Think about it this way - there are two scenarios:

1. The user presses get new mail. If we get an error, we'll try sending the
password one more time. If that fails, the failureCount will be > 1, and we'll
forget the password. If the password had changed on the server, this is the
behaviour we want.  If the password is correct but the server has an error with
the inbox, either the server will drop the connection as you say, and we won't
forget the password (which would be the desired behaviour), or the server won't
drop the connection and we'll try again. If that fails, we will drop the
password, but most locks will be very temporary.

2. Biff fires. With this patch, biff firing and failing should *never* cause us
to drop the password because we don't retry (because there's no msgWindow) and
thus the count will never get > 1, and again it does what we want.


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

Ok, with these assumptions you're right.
So let's try and see if this helps in Robert's case.
Attachment #131969 - Flags: review- → review+
too risky for 1.5
Flags: blocking1.5? → blocking1.5-
fix checked in. Robert, I know it's a little risky using a pre-alpha build, but
I use the daily builds exclusively and I very rarely have problem.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
FYI, fixed in the thunderbird 0.3 branch.
Blocks: 219336
Comment on attachment 131969 [details] [diff] [review]
proposed fix

putting my plus back for clarity
Attachment #131969 - Flags: superreview?(scott) → superreview+
As long as I can back up into 1.5 builds, I'm fine.

Just pop me an email when a build with this patch hits the FTP servers, since
I'm not in te routine of using trunk builds.
Asa:  Provided the fix works... is it more risky to ship with this bug?  I for
some reason doubt I'm the only one effected by this on two servers (one of which
I am pretty sure is running iPlanet, don't know the version, don't know about
the other one).  

I'm of the reasoning that there may be quite a few more like myself who are
finding Mail&News to be unreliable since it can't check mail as it should.

Perhaps if there is going to be an RC2 it could be included?

I'm wondering how widespread this symptom can be of mail&news users.
You can use the .zip build. Just uncompress it to a different folder and run
Mozilla.exe (close the other Mozilla before).
You can always delete the directory if you want...

FWIW, I think this fix is fairly safe. The only potential regression is that we
might go back to the way things were in 1.4 - i.e., if the password has changed
on the server, we might end up not being able to log on until the user removes
the password from the password manager. I don't think that will generally be the
case, except on pop3 servers that drop the connection after a bad password.
Comment on attachment 131969 [details] [diff] [review]
proposed fix

Scott and David sold me. a=asa (on behalf of drivers) for checkin to the 1.5
branch. Please add the fixed1.5 keyword when this has landed. Thanks.
Attachment #131969 - Flags: approval1.5+
David, you make me feel smart.  That was exactly what I infered as the only real
possible regression...

which I think someone besides myself would be able to detect fairly quickly (I'm
looking to see if it curesmy issue).

As a sidenote.  Wouldn't it be wiser to perhaps make an error "Server rejected
password", with an option to open the password manager (and change the
password).  Or just ignore it (for the instance that Mozilla is running). 
fixed on the 1.5 branch.

Fixed on the Thunderbird 0.3 branch.
Flags: blocking1.5- → blocking1.5+
Keywords: fixed1.5
Robert, something like that is a possiblity, but it's such a crap shoot with POP
- you just don't know why the connection failed, so it might be misleading to
bring up the password manager...
Gottcha.  

I'm just wondering how Outlook Express 5/Mac did it?  It seemed to know the
difference.  Just wondering how.

Then again, it had a boatload of other issues.
*** Bug 220128 has been marked as a duplicate of this bug. ***
Robert, Outlook maybe looks at the server answers text for "bad login" or
"password". This is bad behaviour though it might give the right result in 90%
of the servers.
I'm assuming since this has been checked into 1.5, sometime this afternoon I can
download a latest-1.5 build:
http://ftp.mozilla.org/pub/mozilla/nightly/latest-1.5/

and test this patch on the 1.5 branch (which I much perfer, thanks Scott, David,
and Asa).
This is... semi-fixed, I think.  Before this fix, Mozilla would forget my
password whenever there was a problem logging into the mail server (caused by my
xlassie biff'ing at the same time, I expect).

Now this is usually okay, but a few minutes ago I got the usual 'problem' dialog
twice in a row, one after the other, dismissed them both and then my password
had been forgotten, prompting me to enter it again.
OS: Windows XP → All
Hardware: PC → All
I haven't seen a 1.5 nightly yet:
http://ftp.mozilla.org/pub/mozilla/nightly/latest-1.5/

They are still from the 23rd.  When are the new ones coming out?
Is this included in 1.5rc2? (which according to Asa's blog is due out tonight).
yes, it should be.
Bug 189335 Looks like a duplicate of this bug
I haven't seen it in days.

VERIFIED
Status: RESOLVED → VERIFIED
*** Bug 189335 has been marked as a duplicate of this bug. ***
reopening as it happened again.  Don't have a log, will turn on logging hoping I
can caputure it again.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Ahh Nutz
Can confirm. A lot of users on mozillapl.org support forums are complaining
about password dialog popping up all the time. This seems to affect only some of
POP3 accounts.
Blocks: 160425
Mozilla should never decide to forget the password on it's own.

The dialog that pops up should give the options:

1. Retry NOW with the old password.
2. Retry a few minutes later with the old password.
3. Cancel and give up for now, still remembering the old password for use the
next time the user tries to access the mail server.
4. Enter in the new password.

This is the behavior of Outlook Express, and to me it is the obvious proper
behavior, with a timer on the dialog to default to retrying every few minutes if
no one response to the dialog.

I am having a problem with only one mail server where it periodially causes this
password dialog to come up.

I should not need to type in my password again, which is the only option that I
apparently have now.

In my opinion, I should be entering in the password to the accounts when I set
up the e-mail account, and maintain it on through those dialogs by default.
Attached patch proposed fix — — Splinter Review 
this fix makes it so we don't throw away a pop3 password that has worked in the
current session. The password prompting code we're using in mailnews doesn't
allow us to pass in the current password to the password dialog so I can't
currently prompt for a password, so we'll keep trying the password that worked
before. I've also cleaned up the name of another method to avoid confusion with
the new method I've added to tell if we've authenticated successfully with the
pop3 server.
Attachment #135520 - Flags: superreview?(mscott)
Attachment #135520 - Flags: superreview?(mscott) → superreview+
fix checked in - please let me know how it goes.
Status: REOPENED → RESOLVED
Closed: 21 years ago → 20 years ago
Resolution: --- → FIXED
Awesome work David.  I'll give it shot when 1.6b comes out.  I had lots of
issues with 1.6a, so I'm waiting until post 1.6b to hopefully avoid more problems.
Really, this bug should be a duplicate of bug 91656.  This fix will probably
help most cases, but not the real problem, nor the problem I originally filed
bug 91656 for.  The reason this appears to be a new regression is because it was
causing other regressions as noted earlier by others.  I outlined an algorithm
in bug 91656 comment 19 as to the best way to fix this.

As far as I can tell, this patch still does not fix the problem where a user has
multiple machines and is trying to access mail from those multiple machines at
the same time (by forgetting/neglecting to shutdown the mail app on the other
computer).  Or if someone is using say both Mozilla mail and Thunderbird and
they happen to ping the mailbox at the same time.

The bottom line is, we don't need to guess whether the password is correct or
not.  Mail servers will respond that the server is in use if it is.  We should
parse that and act appropriately.
I'm not sure why you say this won't fix the problem of multiple machines/apps
pinging the pop3 inbox since that's exactly what it attempts to fix. Fix, in the
sense of not forgetting the pop3 password in that case, which is what this patch
does.  Parsing server response text is not the way to go, for reasons explained
in bug 91656. Also, as I mentioned earlier, we're not using a prompting
interface that allows us to pre-fill the password, and I'll bet you dollars to
donuts the interface we're using is frozen.
*** Bug 91656 has been marked as a duplicate of this bug. ***
Christopher, what you outlined in bug 91656, comment #19 has already been
implemented by bug 151452 (and improved by patch for bug 219282). Ok, not the
"maildrop" thing cause that's not only forbidden by RFC but it would have caused
more problems. Some servers say "+OK maildrop locked" if login succeeded ...

The problem where (and IMHO are even after Davids patch in cases like initial
login failes although right login data entered) servers not supporting the
extended response codes like [IN-USE].
using - Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6b) Gecko/20031118

my mozilla mail is used to pull 2 POP accounts.

under server settings on BOTH, the only box I have checked is "Empty trash on exit"

even though "check for messages every _____ minutes is unchecked, I have it set
to 3000.

the damn thing still requests a password every 5 minutes.  I believe this is
only happening on the "first" account.

for the life of me, I can't see why it is asking/checking at all 
Nice to see this bug (and bug 91656) fixed. But there is still a related issue
in bug 189633. Now, in case of POP error, MailNews doesn't forget the password
but annoy the user with endless error Alerts.

What do you mean with "endless error Alerts"? Mozilla reports the errors the
server sent. Shouldn't it do so?
By fixed in 1.5 does that mean it is fixed in a release after 1.5b?

The problem is still visible in Mozilla 1.5b.

Mozilla/5.0 (X11; U; OpenVMS AlphaServer_DS10_617_MHz; en-US; rv:1.5b)
Gecko/20030827


Reproduction is less frequent, but it appears that after 2.5 years the broadband
ISP is starting to get their mail servers under some control.
This bug was fixed very close to the 1.5 release.  It didn't really make much
time in beta (it was a small fix anyway, not high risk).

So yes, it's fixed in 1.5 final, I have seen it only once since, and can't
reproduce it so far.
It is still present when accessing news.  Bugs number 214533 and 206634 are related.
Product: MailNews → Core
Status: RESOLVED → VERIFIED
*** Bug 300113 has been marked as a duplicate of this bug. ***
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.