Closed Bug 234421 Opened 20 years ago Closed 20 years ago

authentication error login POP3 server

Categories

(MailNews Core :: Networking: POP, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: gcabillon, Assigned: ch.ey)

Details

(Keywords: fixed-aviary1.0)

Attachments

(1 file, 1 obsolete file)

User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 MultiZilla/1.6.0.0e

The FIRST time I check for new POP mail I get the following error:
"Sending of username did not succeed. Mail server xxx responded: unsupported
SASL authentication method".

If I retry I can get mail without problems

You can use this account for test:
    server: adinet.com.uy
    user: mozilla
    pass: moz123

    


Reproducible: Always
Steps to Reproduce:
1. click get mail button
2. 
3.

Actual Results:  
auth error

Expected Results:  
get mail

A log with two consecutive intents, error and OK respectively:

0[323ec0]: Entering NET_ProcessPop3 104
0[323ec0]: POP3: Entering state: 1
0[323ec0]: POP3: Entering state: 2
0[323ec0]: POP3: Entering state: 4
0[323ec0]: RECV: +OK POP3 PROXY server ready (7.0.000)
<5257A897E5ED40ACDF86AEDE4A9D2849A135527F@mta1.in.adinet.com.uy>
0[323ec0]: POP3: Entering state: 29
0[323ec0]: SEND: AUTH

0[323ec0]: Entering NET_ProcessPop3 37
0[323ec0]: POP3: Entering state: 3
0[323ec0]: RECV: +OK list of SASL extensions follows
0[323ec0]: POP3: Entering state: 30
0[323ec0]: Entering NET_ProcessPop3 10
0[323ec0]: POP3: Entering state: 30
0[323ec0]: RECV: CRAM-MD5
0[323ec0]: POP3: Entering state: 30
0[323ec0]: RECV: PLAIN
0[323ec0]: POP3: Entering state: 30
0[323ec0]: RECV: DIGEST-MD5
0[323ec0]: POP3: Entering state: 30
0[323ec0]: RECV: .
0[323ec0]: POP3: Entering state: 31
0[323ec0]: SEND: CAPA

0[323ec0]: Entering NET_ProcessPop3 86
0[323ec0]: POP3: Entering state: 3
0[323ec0]: RECV: +OK Capability list follows
0[323ec0]: POP3: Entering state: 32
0[323ec0]: RECV: TOP
0[323ec0]: POP3: Entering state: 32
0[323ec0]: RECV: RESP-CODES
0[323ec0]: POP3: Entering state: 32
0[323ec0]: RECV: USER
0[323ec0]: POP3: Entering state: 32
0[323ec0]: RECV:  DIGEST-MD5
0[323ec0]: POP3: Entering state: 32
0[323ec0]: RECV: PIPELINING
0[323ec0]: POP3: Entering state: 32
0[323ec0]: RECV: UIDL
0[323ec0]: POP3: Entering state: 32
0[323ec0]: RECV: .
0[323ec0]: POP3: Entering state: 33
0[323ec0]: POP3: Entering state: 5
0[323ec0]: SEND: AUTH PLAIN

0[323ec0]: Entering NET_ProcessPop3 12
0[323ec0]: POP3: Entering state: 3
0[323ec0]: RECV: + go ahead
0[323ec0]: POP3: Entering state: 34
0[323ec0]: POP3: Entering state: 6
0[323ec0]: Logging suppressed for this command (it probably contained
authentication information)
0[323ec0]: Entering NET_ProcessPop3 31
0[323ec0]: POP3: Entering state: 3
0[323ec0]: RECV: -ERR invalid user or password
0[323ec0]: POP3: Entering state: 34
0[323ec0]: POP3: Entering state: 33
0[323ec0]: POP3: Entering state: 5
0[323ec0]: SEND: USER mozilla

0[323ec0]: Entering NET_ProcessPop3 68
0[323ec0]: POP3: Entering state: 3
0[323ec0]: RECV: -ERR unsupported SASL authentication method
0[323ec0]: POP3: Entering state: 34
0[323ec0]: POP3: Entering state: 24
0[323ec0]: POP3: Entering state: 25
0[323ec0]: Entering NET_ProcessPop3 104
0[323ec0]: POP3: Entering state: 1
0[323ec0]: POP3: Entering state: 2
0[323ec0]: POP3: Entering state: 4
0[323ec0]: RECV: +OK POP3 PROXY server ready (7.0.000)
<EB44295CDE4AB7E5B9635A1818AE1760F922A069@mta1.in.adinet.com.uy>
0[323ec0]: POP3: Entering state: 31
0[323ec0]: SEND: CAPA

0[323ec0]: Entering NET_ProcessPop3 86
0[323ec0]: POP3: Entering state: 3
0[323ec0]: RECV: +OK Capability list follows
0[323ec0]: POP3: Entering state: 32
0[323ec0]: RECV: TOP
0[323ec0]: POP3: Entering state: 32
0[323ec0]: RECV: RESP-CODES
0[323ec0]: POP3: Entering state: 32
0[323ec0]: RECV: USER
0[323ec0]: POP3: Entering state: 32
0[323ec0]: RECV:  DIGEST-MD5
0[323ec0]: POP3: Entering state: 32
0[323ec0]: RECV: PIPELINING
0[323ec0]: POP3: Entering state: 32
0[323ec0]: RECV: UIDL
0[323ec0]: POP3: Entering state: 32
0[323ec0]: RECV: .
0[323ec0]: POP3: Entering state: 33
0[323ec0]: POP3: Entering state: 5
0[323ec0]: SEND: USER mozilla

0[323ec0]: Entering NET_ProcessPop3 23
0[323ec0]: POP3: Entering state: 3
0[323ec0]: RECV: +OK Password required
0[323ec0]: POP3: Entering state: 34
0[323ec0]: POP3: Entering state: 6
0[323ec0]: Logging suppressed for this command (it probably contained
authentication information)
0[323ec0]: Entering NET_ProcessPop3 16
0[323ec0]: POP3: Entering state: 3
0[323ec0]: RECV: +OK 0 messages
0[323ec0]: POP3: Entering state: 34
0[323ec0]: POP3: Entering state: 7
0[323ec0]: SEND: STAT

0[323ec0]: Entering NET_ProcessPop3 9
0[323ec0]: POP3: Entering state: 3
0[323ec0]: RECV: +OK 0 0
0[323ec0]: POP3: Entering state: 8
0[323ec0]: POP3: Entering state: 22
0[323ec0]: SEND: QUIT

0[323ec0]: Entering NET_ProcessPop3 36
0[323ec0]: POP3: Entering state: 3
0[323ec0]: RECV: +OK POP3 server closing connection
0[323ec0]: POP3: Entering state: 41
0[323ec0]: POP3: Entering state: 23
0[323ec0]: POP3: Entering state: 25
Thanks for the test account and the log, that's a bug report I love.

But the results aren't so good. It's basically the same problem as in bug 203785.

Problem one, the server doesn't accept the correct login data using the PLAIN
mechanism. But ok, we fall back to USER/PASS but get hitten by problem two:
"-ERR invalid user or password" wasn't the only error to our PLAIN request. A
second error "-ERR unsupported SASL authentication method" is issued after some
wait.
Because the POP3 protocol defines only one response, we see the second error
response not before we're waiting for the response to "USER mozilla" and think
this failed too.

BTW, login via CRAM-MD5 an APOP (both are used when "Use secure authentication"
is checked) fails too although the login is correct.

It's clear that the server is very buggy and the admin should be contacted ASAP.

But what can we do? One might come up with the idea of waiting for at least a
second response line after every command. But how long? For this server it takes
about 2-3 seconds. That would delay the communication for every error response.
And we couldn't still be sure we got a possible second response.
Hey, what are standards for?

Second possible workaround is something similar as what I've done for bug
203785. A (no-UI) pref to prevend using any other authentication than USER/PASS.

I don't like any of them since it's the servers fault.
OS: Windows XP → All
Hardware: PC → All
I receive the same error message on the FIRST mail check of my Adinet email
account, using Firebird 0.4 (20031221) under Debian GNU/Linux Sid.
And? Same server, same problem. Not surprising.
(In reply to comment #1)
> Thanks for the test account and the log, that's a bug report I love.
> 
> But the results aren't so good. It's basically the same problem as in bug 203785.
> 
> Problem one, the server doesn't accept the correct login data using the PLAIN
> mechanism. But ok, we fall back to USER/PASS but get hitten by problem two:
> "-ERR invalid user or password" wasn't the only error to our PLAIN request. A
> second error "-ERR unsupported SASL authentication method" is issued after some
> wait.
> Because the POP3 protocol defines only one response, we see the second error
> response not before we're waiting for the response to "USER mozilla" and think
> this failed too.
> 
> BTW, login via CRAM-MD5 an APOP (both are used when "Use secure authentication"
> is checked) fails too although the login is correct.
> 
> It's clear that the server is very buggy and the admin should be contacted ASAP.
> 
> But what can we do? One might come up with the idea of waiting for at least a
> second response line after every command. But how long? For this server it takes
> about 2-3 seconds. That would delay the communication for every error response.
> And we couldn't still be sure we got a possible second response.
> Hey, what are standards for?
> 
> Second possible workaround is something similar as what I've done for bug
> 203785. A (no-UI) pref to prevend using any other authentication than USER/PASS.
> 
> I don't like any of them since it's the servers fault.

I share your point of view that is the server's fault. Yesterday I contacted to
server admin by mail. (wish me luck :))

Jus one more question, on Mozilla 1.5 I don't have this problem, what changed? I
didn't see anything in the release notes.

 
Yes, I added support for PLAIN authentication mechanism at a time where Moz 1.5
was just about to be released. So 1.6 is the first final version with support
for PLAIN. Without recognizing PLAIN we just used USER/PASS and succeeded since
at least this mechanism works on this obscure server.
Attached patch proposed patch (obsolete) — Splinter Review
This patch introduces the method FlushBuffer for nsMsgLineStreamBuffer. It
flushes the nsMsgLineStreamBuffer internal buffer.
This helps in the situation where a server sends out two reply lines like in
this bug here. Additionally it prevends us from potential problems when the
last line of the previous message doesn't end with a (CR)LF.
Though FlushBuffer is called before any command in SendData() it isn't costly
since all it does are two assigns.

The other code is some cleanup and simplification without change of behaviour.
Assignee: sspitzer → ch.ey
Status: UNCONFIRMED → ASSIGNED
Attachment #152943 - Flags: review?(bienvenu)
Comment on attachment 152943 [details] [diff] [review]
proposed patch

it looks to me like FlushBuffer is really doing more of a clear or reset than a
flush, i.e., it's throwing away the data, not  flushing it to the client. If
that's correct, the method name should change...
(In reply to comment #7)
> (From update of attachment 152943 [details] [diff] [review])
> it looks to me like FlushBuffer is really doing more of a clear or reset than a
> flush, i.e., it's throwing away the data, not  flushing it to the client. If
> that's correct, the method name should change...

Erm, may be that my understanding of "flush" is wrong. I and my dictionary use
it for clear, deplete, empty, exhaust, purge.
But if you're unhappy with it, I can change it to ClearBuffer. Indeed its whole
function is to throw away the data, nothing more.

Attachment #152943 - Flags: review?(bienvenu)
Attached patch patch v2Splinter Review
This pach renames the method to ClearBuffer(). Additionally it fixes two loops
in nsPop3Protocol.
Attachment #152943 - Attachment is obsolete: true
Attachment #153319 - Flags: review?(bienvenu)
you're correct in your understanding of flush in English (e.g., flushing a
toilet), but in io programming, it has a different sense, e.g., flushing to
disk, i.e., saving the data persistently, not throwing it away.
Attachment #153319 - Flags: review?(bienvenu) → review+
Attachment #153319 - Flags: superreview?(mscott)
Ah, ok, thanks for the clarification.
Attachment #153319 - Flags: superreview?(mscott) → superreview+
fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Keywords: fixed-aviary1.0
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: