If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

All POP3 accounts fail with repeat password dialog (CRAM-MD5 authentication refused), IMAP accounts OK

RESOLVED FIXED in mozilla1.4beta

Status

MailNews Core
Networking: POP
--
major
RESOLVED FIXED
15 years ago
6 years ago

People

(Reporter: paul erkkila, Assigned: Bienvenu)

Tracking

Trunk
mozilla1.4beta
x86
All
Bug Flags:
blocking1.4b +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments, 1 obsolete attachment)

2.41 KB, text/plain
Details
5.79 KB, text/plain
Details
1.02 KB, patch
(not reading, please use seth@sspitzer.org instead)
: review+
Bienvenu
: superreview+
(not reading, please use seth@sspitzer.org instead)
: approval1.4b+
Details | Diff | Splinter Review
2.14 KB, text/plain
Details
716 bytes, patch
Details | Diff | Splinter Review
(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030412 Mozilla Firebird/0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030424

I have 6 email accounts defined in mailnews. 3 are setup for POP3 , 3 for IMAP.
I pulled the cvs tree last night, and ran mail and news. Now all of my POP3
accounts fail to work. All of my IMAP accounts still work fine.

If you have saved the password in the password mangler, OR type in the password
I get the "Connect: Host contacted, sending login information" in the bottom
status bar, followed bye an alert box that says "The PASS command did not
succeed. Mail server blah.blah.com responded: Authentication failed".

This alert box seems to repeat every 10 seconds or so , forever.

I have verified the passwords I am typing are in fact correct for all three
accounts. I have also deleted the accounts from the password manager. 

I have telneted to port 110 of each system and verified that they are working
correctly.

My previous build of mozilla from 03/04 or so works correctly.

Reproducible: Always

Steps to Reproduce:
1. Add a pop3 account
2. Try and connect

Actual Results:  
Repeat PASS command did not succeed dialog box

Expected Results:  
Let me see my mail

Comment 1

15 years ago
i just saw that this is the same as bug 203227
(Reporter)

Comment 2

15 years ago
Same bug as far as i can tell

Comment 3

15 years ago
*** Bug 203227 has been marked as a duplicate of this bug. ***
20030423/20030424 build has this problem.
20030422 build is good.
By patch of bug 43923 ?
(Assignee)

Comment 5

15 years ago
can we get a client-side pop3 protocol log? thx! It's likely that it was
cram-md5 pop work that caused this.

http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap
Assignee: naving → bienvenu
Status: UNCONFIRMED → NEW
Ever confirmed: true
this is a blocker, I think.

if people can't get pop mail (due to the cram-md5 work), that's bad.

guenter-huerkamp@web.de, if you can get us a protocol log, that would really help.
Flags: blocking1.4b+
Target Milestone: --- → mozilla1.4beta
Caused by the fix for bug 202442 (add CRAM-MD5 authentication to POP3)?

Comment 8

15 years ago
i don't know how to generate an protocol log. can someone tell me the way?
(Assignee)

Comment 9

15 years ago
click on the link below and follow the instructions: 

http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap

thx.
I have 2 POP3 mail accounts on different provider and one has no problem and
other was always rejeced.

[Test Procedure] 
 (2003042412-trunk/Win-Me)
(1) Delete password entry for mail by Password Manager of Mozilla
    Browser to force prompt and to avoid infinite error loop.
(2) "Get Message" to account A
  => Password was prompted
  => Enter password and normaly accessed
(3) "Get Message" to account B
  => Password was prompted (Do NOT save password to avoid loop)
  => Error message and password prompt
  => If password is entered, error/prompt continues forever
  => "Cancel" on prompt is only way to escape from loop

Difference of these 2 mail servers is supported protcol;     
 Mail server of account A has POP3 service only.
 Mail server of account B has both POP3 and APOP service.
On my provider B, POP3 or APOP can be chioced and I use POP3.

Above situation indicates that "Rejection Code" is different between Mail server
A(POP3 only) and Mail server B(POP3 and APOP) and Mozilla failed to handle such
error code properly.

Comment 11

15 years ago
It would be great if I could get access to an account on one of the POP servers
they fail. Is there a freemailer among them where it would easy to subscribe?

Or it could even help to just try telnet them, so please mail me the failing
servers addresses please.

Or any logs like bienvenu said, I'll take Ethereal logs too (mail me).

Comment 12

15 years ago
Created attachment 121645 [details]
protocol logfile

.

Comment 13

15 years ago
WADA, POP3 doesn't know different "Rejection Codes", it only knows -ERR. What
should Mozilla do if the server answers +OK to the authentification command but
-ERR after sending username/password?

BTW APOP is no service, only an extension for secure authentification to POP3.
Christian, protocol log of attachment 121645 [details] contains follwing record.
 0[234138]: RECV: -ERR Unrecognized authentication type
It contains not only -ERR but also the "Reason of Error".
I do not know correct terminology for this "Reason of error" of POP3 protocol.
So I said "Rejection code".
Sorry for my inappropriate word.

By the way, reason is not password error in this case.
Retry of sending password is apparently not a valid action for "Unrecognized
authentication type".

Comment 15

15 years ago
Yes, but this "Reason of Error" is not standardised and not always really
descriptive.
In general the text after -ERR and +OK can be everything. That's a design flaw
of POP3.

Your right in saying retry of sending password is apparently not a valid action
for "Unrecognized authentication type". But first as said above text after -ERR
and +OK isn't trustworthy.

Besides of this, the message in the protocol from guenter isn't the problem. As
you can see USER/PASS is tried then and succeeds. This protocol apparently isn't
from a buggy build but an earlier version - guenter knows of this.

I think I know what the problem is and have a patch, but I want to be sure and
thus need protocol(s) from the right builds (20030423 or newer).
(Assignee)

Comment 16

15 years ago
Paul, if you can generate a protocol log by clicking on the link below and
following the instructions: 

http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap

then, attach the log to this bug (or send it to ch.ey.gmx.net and
bienvenu@netscape.com) that would help us a lot. Thx!
Christian & bienvenu, I'll try to get protocol log.
Fortunately, 3-days holiday starts from tomorrow in Japan.
But I hate many re-bootings of Windoze especialy at Friday mid-night and 
holidays ;)
Created attachment 121670 [details]
NSPR POP3 protcol log

Comment 19

15 years ago
Created attachment 121681 [details]
protocol logfile

New logfile from guenter produced by the buggy Mozilla.
Attachment #121645 - Attachment is obsolete: true

Comment 20

15 years ago
Created attachment 121682 [details] [diff] [review]
proposed patch

Ok, it was my fault to assume, even if the server doesn't answer with a list of
supported mechanisms to AUTH, we could try CRAM-MD5 nevertheless.
We currently do this and although the command AUTH CRAM-MD5 being answered with
a challenge, we get -ERR after sending our response.

So it looks like a password or username problem to Mozilla and it asks for
entering the correct on. We don't fallback because the server answered our
explicit question "Do you support CRAM-MD5" with "yes, here's your challenge".

This patch removes the assumption we could try LOGIN or CRAM-MD5 if answer to
AUTH is negative.

Thanks for the Logfiles and special thank to Florian for the test account.
(Assignee)

Comment 21

15 years ago
Comment on attachment 121682 [details] [diff] [review]
proposed patch

r=bienvenu, thx Christian.
Attachment #121682 - Flags: superreview+
Comment on attachment 121682 [details] [diff] [review]
proposed patch

r=sspitzer, a=sspitzer for 1.4 beta.
Attachment #121682 - Flags: review+
Attachment #121682 - Flags: approval1.4b+
I'll land when the tree opens.
fixed
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
20040426-trunk/Win-Me has got mails successufully from POP3 server who returns
"-ERR [AUTH] CRAM-MD5 authentication is disabled." to "AUTH CRAM-MD5"
request(attachment 121670 [details] case).
Christian, thanks for very quick fix.

Comment 26

15 years ago
Although initially using 2003042608 this seemed to be fixed, the same problems
recently cropped up again for me. Using 2003042808 (win98) they persist. 

"The PASS command did not succeed Mail server [withheld] responded: Bad
authentication"

Reopening (and setting OS to all, also based on dupe).
Status: RESOLVED → REOPENED
OS: Linux → All
Resolution: FIXED → ---

Comment 27

15 years ago
Created attachment 121937 [details]
NSPR POP3 logfile

Comment 28

15 years ago
I wouldn't agree that's the same bug.
Well, it looks like to the user, but this time we really only do CRAM-MD5 if the
server advertised it.

But ok, your log isn't very informative on what server you connected to and what
challenge you received (did you insert the [DATA HIDDEN]? Since this is not
sensitive information but one that could be useful for us please don't do this).
So I'm unable to reproduce the problem.

Does it fail every time or just sometimes?
Would it be possible to get access to an account on the pop server?
If not, are you able to test this with other mail apps that try CRAM-MD5 (e.g.
KMail)?

Comment 29

15 years ago
My apologies on the uninformative log; but with possibly sensitive things like
this I always prefer being on the safe side. In place of the [data hidden]
string was a string: "+ longstring+" (the plusses I'm certain about; comparing
it to a log from just now I see "+ similarlongstring=="), the [server hidden]
string is somethingrandom @ the name of a small server.

For the past three days things have worked (using 2003042608), but slightly
before I posted comment 28 they started failing (while in the five hours before
there were no problems whatsoever), and failed consistently (through half a
dozen reboots over a period of at least half an hour, using various ways to
start the "get messages" process, and also with a new build - 2003042808), while
2003041908 worked just fine. I continued working with that build, and trying
again right now things seem to be working correctly again. (So the problem
occurs only sometimes, but when it does, it does so consistently and continuously.)

I wonder if the local time could have anything to do with these problems? It's
only a very vague hunch, but just now as the problems started occurring it was
around 23:00 here, and that happened to be the time that I first encountered the
problems with 2003042508 as well. (Possibly related to summer time? The server
time is GMT, while I'm GMT+1, and another +1 for summer time (so two hours ahead).)


Since you say this is technically a different bug and right now I'm not able to
reproduce anymore, should this be resolved again with me filing a new one as
soon as I encounter it again? Will the log be useful if I don't insert that
[data hidden] bit, or is there anything else I can do to make the log more useful?
I'll see about getting you an account (not certain if I can); only have win98
here, so can't run kmail, but if there's another windows program that does the
same I'm willing to test with that.

Comment 30

15 years ago
Ok, thank you for your answer. The + longstring== or + is what is called
challenge and normally is a base64 coded string consisting of more or less
random numbers@servername - so very often the same as in the greeting banner.
Why I wanted it is, that it could be that the string is corrupted, decoding
fails and so the PASS does.

But if getting mail suceeds at least sometimes, the challenge should be ok.
Except the server is only one of a server farm and some of them sending corrupt
challenges. But if it fails consistently and continuously and then works for
hours, that is unlikely. I can't imagine a problem that depends on the daytime.

I closed this bug again and ask you to open a new one if the problems continue.
I don't want to conceal that in comment #19 of bug 202575 a problem has been
described that sound similar to yours.
But since this bug at least startet with a problem special to the servers at
mail.attbi.com, that could be something else too.
If you open a new one, please CC me.

Regarding a mail client you could use for testing, The Bat!
(http://www.ritlabs.com/the_bat/download.html) is suitable for our purposes.
Small and simple to install and you can choose the authentication mechanism.
If this has also problems when Mozilla has, it should be a server prob (a mail
to me would be nice then too), if not ...
Status: REOPENED → RESOLVED
Last Resolved: 15 years ago15 years ago
Resolution: --- → FIXED

Comment 31

15 years ago
re-opening this bug. I just realeased a new thunderbird build tonight
(04-28-2003) and I am getting lots of users complaining that they are still
unable to log onto their POP accounts. They are still getting this error
message.  This first showed up with builds. Will ask some of them to comment in
here. But this regression is still present in a build from today. 
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 32

15 years ago
....still cannot login to my POP3 mail account with Charter Cable after trying
out  4/28 build

Comment 33

15 years ago
Adding keywords "CRAM-MD5 authentication refused" to summary.
Summary: All POP3 accounts fail with repeat password dialog, IMAP accounts OK → All POP3 accounts fail with repeat password dialog (CRAM-MD5 authentication refused), IMAP accounts OK

Comment 34

15 years ago
It would really help us knowing if it's a failure in Mozilla or in the server.

I'd really appreaciate if someone who has problems could try getting mail with
another mailer that can do CRAM-MD5. On Linux e.g. KMail, on Windows e.g. The Bat!

Comment 35

15 years ago
I've experienced this problem using the 2304 Thunderbird build, and the 2804
Thunderbird build, same(?) problem with both, and a recent build of Mozilla mail.
Thunderbird usually manages to authenticate after a number of retries, which
seems to be random, but I don't think it has ever worked on the first try.

I just tried connecting with The Bat as requested, and it worked fine, with the
authentication method to Regular, MD5 APOP, or MD5 CRAM.
(Assignee)

Comment 36

15 years ago
Created attachment 122025 [details] [diff] [review]
proposed fix

I don't think there's a CRLF at the end of the response, so we're not
converting the challenge correctly.
(Assignee)

Comment 37

15 years ago
fix checked in, r/sr/a=sspitzer.
Status: REOPENED → RESOLVED
Last Resolved: 15 years ago15 years ago
Resolution: --- → FIXED

Comment 38

15 years ago
Many thanks, David.
It was my fault not to remove this subtraction after copying the code from SMTP.

Comment 39

15 years ago
Should I have expected this bug to be fixed in the seamonkey 0429 build?  'cuz 
it's not.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030429

Comment 40

15 years ago
Actually, re-reading this, it's not clear that I'm seeing the same bug as 
reporter (or the potential duplicate at Bug 203882).  The error box put up by 
Mozilla reads: "The PASS command did not succeed. Mail server xxx.yyy.net 
responded: CRAM-MD5 authentication refused"

I've already sent bienvenu a POP3 log from the 0426 build; I can generate 
another for 0429 if necessary.

Comment 41

15 years ago
No, you shouldn't expect the bug fixed in 0429 but 0430 and on.

Bug 203882 should be a dupe of this one and your problem is also this one (as it
looks from your 0426 log).
If you think it's not because the message from the server is different, I can
say, that doesn't matter. These messages are freetext and not always to the point.
(Assignee)

Comment 42

15 years ago
please try today's build. The builds are made the morning after the fix is
checked in, and I checked this fix in on the afternoon of 04/29, so it was not
in the 04/29 morning build.

Comment 43

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

Comment 44

15 years ago
OK, it is fixed for me in the 0430 build.  Thanks!!

Verifying.
Status: RESOLVED → VERIFIED

Comment 45

15 years ago
I still have this problem.

-> Reopen

Comment 46

15 years ago
It occurs on 2003-05-02-11 (new profile)
Status: VERIFIED → REOPENED
Resolution: FIXED → ---

Comment 47

15 years ago
It was my mistake.
Sorry for bug spam.
Status: REOPENED → RESOLVED
Last Resolved: 15 years ago15 years ago
Resolution: --- → FIXED

Comment 48

14 years ago
*** Bug 203232 has been marked as a duplicate of this bug. ***

Comment 49

14 years ago
*** Bug 203563 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.