256294 - Use secure authentication (CRAM-MD5) if it is offered via CAPA

Status: VERIFIED FIXED

(MailNews Core :: Networking: POP, defect)

Description

[:aceman]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1
Build Identifier: Mozilla/1.7

Currently, only the AUTH command is used to find out which authenticatin methods
can be used on the pop3 server. I have a server, which doesn't understand AUTH,
but lists CRAM-MD5 as a response to CAPA command. Mailnews should utilize also
this knowledge and try secure authentication.

Reproducible: Always
Steps to Reproduce:

Actual Results:  
Moz should try secure if it is in the response to AUTH or CAPA.


This is the log from my server (pop3.inmail.sk):
0[771e20]: RECV: +OK X1 NT-POP3 Server <2352.1091730300750@inmail-data> (IMail
8.12 1206027-6)
0[771e20]: POP3: Entering state: 29
0[771e20]: SEND: AUTH

0[771e20]: Entering NET_ProcessPop3 37
0[771e20]: POP3: Entering state: 3
0[771e20]: RECV: -ERR authentication exchange failed
0[771e20]: POP3: Entering state: 30
0[771e20]: POP3: Entering state: 31
0[771e20]: SEND: CAPA

0[771e20]: Entering NET_ProcessPop3 168
0[771e20]: POP3: Entering state: 3
0[771e20]: RECV: +OK Capability list follows
0[771e20]: POP3: Entering state: 32
0[771e20]: RECV: TOP
0[771e20]: POP3: Entering state: 32
0[771e20]: RECV: USER
0[771e20]: POP3: Entering state: 32
0[771e20]: RECV: SASL LOGIN PLAIN CRAM-MD5
0[771e20]: POP3: Entering state: 32
0[771e20]: RECV: RESP-CODES
0[771e20]: POP3: Entering state: 32
0[771e20]: RECV: LOGIN-DELAY 120
0[771e20]: POP3: Entering state: 32
0[771e20]: RECV: PIPELINING
0[771e20]: POP3: Entering state: 32
0[771e20]: RECV: EXPIRE 30 USER
0[771e20]: POP3: Entering state: 32
0[771e20]: RECV: UIDL
0[771e20]: POP3: Entering state: 32
0[771e20]: RECV: IMPLEMENTATION Ipswitch_IMail_8.0
0[771e20]: POP3: Entering state: 32
0[771e20]: RECV: .
0[771e20]: POP3: Entering state: 33
0[771e20]: POP3: Entering state: 5
0[771e20]: SEND: USER <censored>

0[771e20]: Entering NET_ProcessPop3 24
0[771e20]: POP3: Entering state: 3
0[771e20]: RECV: +OK send your password
0[771e20]: POP3: Entering state: 34
0[771e20]: POP3: Entering state: 6
0[771e20]: Logging suppressed for this command (it probably contained
authentication information)
0[771e20]: Entering NET_ProcessPop3 31
0[771e20]: POP3: Entering state: 3
0[771e20]: RECV: +OK maildrop locked and ready
0[771e20]: POP3: Entering state: 34
0[771e20]: POP3: Entering state: 7
0[771e20]: SEND: STAT

Comment 1

[Christian Eyrich]

Ok, analyzing CAPA response and setting the flags for the listed mechanisms is
no problem, patch follows.

Comment 2

[Christian Eyrich]

Attachment: proposed patch

That should help.

Comment 3

[David :Bienvenu]

Comment on attachment 156632 [details] [diff] [review]
proposed patch

looks good, thx.

Comment 4

[:aceman]

Very nice patch, I can almost understand it :) And the instant fix... you 2 guys
really rule :)

Comment 5

[Christian Eyrich]

Nice to hear you like it. Closing this bug - if you've problems with it in the
future, add a comment.

Comment 6

[:aceman]

Yes, I like it because it looks nice, easy and correct. Of course I couldn't
test it, there is no indicaton it was already checked in. Anyway I can only test
it once 1.8 comes out. But I have nothing against closing this, I will verify at
that time. Thanks.

Comment 7

[Christian Eyrich]

Ah yes, according to Bonsai, David checked it in 2004-08-25 11:11. So from our
side you could test it starting with today's nightlies.

Comment 8

[:aceman]

Verified in seamonkey 1.0.2. Mozilla sent "0[781d00]: SEND: AUTH CRAM-MD5" and the  server sent the long token. The negotiation didn't work in the end, but it may be a server problem. Anyway, Mozilla did try, so the bug is fixed :)