281473 - Mail (IMAP) requires restart to fetch mail due to bad, early authentications.

Status: VERIFIED FIXED

(MailNews Core :: Networking: IMAP, defect)

Description

[Stephen Donner [:stephend] Not actively reading bugmail]

Mail (IMAP) requires restart to fetch mail due to bad, early authentications.

Steps to Reproduce:

1.  Create a new IMAP account.
2.  Because my server requires SSL, cancel the first login.
3.  Go to Mail & Newsgroup Account Settings and click the checkbox for "Use
Secure Connection (SSL)
4.  Attempt to login again.

Actual Results:

"The current command did not succeed.  The mail server responded: please login
first."

Expected Results:

Should be able to login during Step #4.

Comment 1

[Stephen Donner [:stephend] Not actively reading bugmail]

Attachment: Logfile

Comment 2

[Hans-Andreas Engel]

In step 2., you say that you "server requires SSL."  However, according to the
log file, the server still happily communicates on port 143 (non-SSL).

The fact, that the server has port 143 open might be relevant for this bug.  (I
was not able to reproduce this bug on a server which allows only SSL
connections, i.e., which has port 143 closed.)

Comment 3

[Stephen Donner [:stephend] Not actively reading bugmail]

Hans, right.  I of course can still 'talk' to the server on port 143 via telnet,
but obviously can't get my mail without authentication.  BTW, this isn't a very
recent regression -- though I haven't nailed it down, it seems to have happened
at least a month ago.

Comment 4

[Hans-Andreas Engel]

Nailing this down would be very helpful; reproducing the bug requires a server
which listens to ports 143 and 993.

Comment 5

[David :Bienvenu]

Stephen, what was the date of the build that generated that log file? Have you
tried a newer build, from 02/04 or later? 

Comment 6

[Stephen Donner [:stephend] Not actively reading bugmail]

David, it would have been with the 2005-02-07 build that I first found out about
this problem.

I just tried again, and am experiencing it with:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050215

Comment 7

[David :Bienvenu]

can you get me an account on this server?

Comment 8

[Stephen Donner [:stephend] Not actively reading bugmail]

Account information sent to David privately via email; let me know if you didn't
receive them (my Netscape.net account is spotty, at best).

Comment 9

[David :Bienvenu]

Attachment: proposed fix

this server is telling us login is disabled on port 143, and we were respecting
that, but looping trying to logon. So I've added an error message when the
server disables login, and break out of the loop in that case.

Comment 10

[David :Bienvenu]

one further note - I tried tls on your account, Stephen, and it failed. However,
TLS works with other imap servers, so I'm hoping there's something wrong with
your imap server. SSL worked fine.

Comment 11

[(not reading, please use [e-mail] instead)]

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

a=sspitzer, assuming mscott gives you sr

Comment 12

[Scott MacGregor]

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

please fix the locale string in mail\locales

Comment 13

[David :Bienvenu]

I did fix the locales string - I just didn't put it in the patch since it's
tbird only (but I tested this in tbird)

Comment 14

[Hans-Andreas Engel]

David, I have a minor question regarding your patch, which adds a check for
|kLoginDisabled|.  This check is inside |if (prefBool) { ... }|, with |prefBool|
set to "mail.auth_login."

When |prefBool| is false, it seems to me that |kLoginDisabled| should also be
checked.  This implies that your check and the invocation of |Capability()|
should be made just before |if (prefBool) ...|.

But maybe I overlooked a subtlety... thank you for your explanations.

Comment 15

[David :Bienvenu]

Setting auth_login means that the user doesn't need to login, so we won't login.
Logindisabled is then basically irrelevant.

Comment 16

[Hans-Andreas Engel]

I see.  So while the "user doesn't need to login," a LOGIN command must still be
sent [via InsecureLogin(), but without entering a password].  This sets the
server in the "authenticated state" according to the IMAP protocol.  Thank you
for the clarification. 

Comment 17

[Stephen Donner [:stephend] Not actively reading bugmail]

We now alert the user properly, but we still fail to issue them back a login
prompt because we haven't sent capability...

Comment 18

[David :Bienvenu]

the issue is that we need to re-issue the capability response if the previous
one was for a different port.

Comment 19

[David :Bienvenu]

Attachment: fix to re-issue capability when login disabled

if we can't login because login was disabled, clear the capability on the host
so that we'll re-issue capability next time we try to connect to that server.

Comment 20

[David :Bienvenu]

fix checked in - please try tomorrow's build - I can't test this fully, but I am
getting a password prompt after switching to ssl

Comment 21

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED using Seamonkey trunk build 2005-03-18 and Thunderbird trunk
build version 1.0+ (20050318).

I see an empty pane when the Inbox is selected for the 1st time, but I think
that's a long-standing bug, and switching to another folder and then back to
Inbox refreshes correctly.

Thanks for fixing this bug, David.

Comment 22

[Stephen Donner [:stephend] Not actively reading bugmail]

Just FYI, nothing more: bug 286764 was filed for the issue I saw in comment 21.