authentication error login POP3 server

RESOLVED FIXED

Status

MailNews Core
Networking: POP
RESOLVED FIXED
14 years ago
9 years ago

People

(Reporter: Gabriel Cabillón, Assigned: Christian Eyrich)

Tracking

({fixed-aviary1.0})

Trunk
fixed-aviary1.0

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

6.46 KB, patch
Bienvenu
: review+
Scott MacGregor
: superreview+
Details | Diff | Splinter Review
(Reporter)

Description

14 years ago
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
(Assignee)

Comment 1

14 years ago
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

Comment 2

14 years ago
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.
(Assignee)

Comment 3

14 years ago
And? Same server, same problem. Not surprising.
(Reporter)

Comment 4

14 years ago
(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.

 
(Assignee)

Comment 5

14 years ago
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.
(Assignee)

Comment 6

13 years ago
Created attachment 152943 [details] [diff] [review]
proposed patch

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)

Updated

13 years ago
Assignee: sspitzer → ch.ey
Status: UNCONFIRMED → ASSIGNED
(Assignee)

Updated

13 years ago
Attachment #152943 - Flags: review?(bienvenu)

Comment 7

13 years ago
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...
(Assignee)

Comment 8

13 years ago
(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.

(Assignee)

Updated

13 years ago
Attachment #152943 - Flags: review?(bienvenu)
(Assignee)

Comment 9

13 years ago
Created attachment 153319 [details] [diff] [review]
patch v2

This pach renames the method to ClearBuffer(). Additionally it fixes two loops
in nsPop3Protocol.
Attachment #152943 - Attachment is obsolete: true
(Assignee)

Updated

13 years ago
Attachment #153319 - Flags: review?(bienvenu)

Comment 10

13 years ago
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.

Updated

13 years ago
Attachment #153319 - Flags: review?(bienvenu) → review+
(Assignee)

Updated

13 years ago
Attachment #153319 - Flags: superreview?(mscott)
(Assignee)

Comment 11

13 years ago
Ah, ok, thanks for the clarification.

Updated

13 years ago
Attachment #153319 - Flags: superreview?(mscott) → superreview+

Comment 12

13 years ago
fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED

Updated

13 years ago
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.