spin-off(issue of Bug 428611 Comment #11). After "-ERR [AUTH] Authentication failed" due to wrong password, Thunderbird /Seamonkey issues CAPA and waits for response forever. While waiting for response to CAPA, it looks that login was successful. Attached is NSPR log with next option, with DebugView. (xxxLeak:5 is to see where dialog is displaed) > SET NSPR_LOG_MODULES=POP3:5,DOMLeak:5,DocumentLeak:5,nsDocShellLeak:5,nsSocketTransport:5,nsHostResolver:5 > SET NSPR_LOG_FILE=WinDebug Log was taken with Seamonkey trunk(BuildID=2008041102) on MS Win-XP SP2. (Test scenario) (0) Clear password (don't request "Save password" in this test) (1) 1st Get Msgs => Password prompt => Enter wrong password => "Authentication failed" dialog => "OK" to the dialog => Password prompt => Enter proper password => CAPA => wait response forever At here, it looks that login was successful, even when wrong password was entered again. (2) 2nd Get Msgs => successful login, because proper password. (If last entered password is wrong one, authentication failure occurs.) When TELNET(plain text login), connection is lost after "-ERR [AUTH] Authentication failed" due to wrong password. TELNET open xxx.yyy.xxx 110 user abc (message of 'password is required') pass xyz (wrong password) -ERR [AUTH] Authentication failed => Connection is lost ("status" of TELNET says no connection)

RFC 1734 says; > http://www.faqs.org/rfcs/rfc1734.html > 2. The AUTH command >(snip) > Discussion: >(snip) > (snip) If an AUTH > command fails with a negative response, the session remains > in the AUTHORIZATION state and client may try another > authentication mechanism by issuing another AUTH command, > or may attempt to authenticate by using the USER/PASS or > APOP commands. In other words, the client may request > authentication types in decreasing order of preference, > with the USER/PASS or APOP command as a last resort. Server side error is involved? (close connection, instead of keeping session in the AUTHORIZATION state)

Note: As I wrote Bug 428611 Comment #13 & Bug 428611 Comment #14, above behavior is observed with Mozilla 1.0(1.0.0), Mozilla 1.7.13, Seamonkey 1.1.4, and Seamonkey 1.1.9 too. So I guess "no response to CAPA after -ERR for AUTH due to wrong password" was produced by several server side changes.

My case was USER/PASS, instead of AUTH. RFC 1939 says; > http://www.faqs.org/rfcs/rfc1939.html > USER name >(snip) > Restrictions: > may only be given in the AUTHORIZATION state after the POP3 > greeting or after an unsuccessful USER or PASS command Does it mean that server should be in AUTHORIZATION state after unsuccessful USER/PASS command?

POP3 protocol log with Gmail-POP3, Tb 2.0.0.12 on MS Win-XP SP2. > SET NSPR_LOG_MODULES=POP3:5,DOMLeak:5,DocumentLeak:5,nsDocShellLeak:5 > SET NSPR_LOG_FILE=WinDebug Because Gmail POP3 server returned response to CAPA after USER/PASS failure, password was prompted again on each wrong password entry, and login was successful when correct password was entered.

This bug is "no alternate authentication mechanism" case of bug 490140. Setting dependency to bug 490140.

This was a variation of bug 428611. Changing dependency to it. Sorry for misoperation and spam.

In Bug 533083, Comment #9, WADA wrote: > But I'd like to know difference from "USER/PASS,-ERR,CAPA,connection close by server, > wait for CAPA response" case, Bug 429069 and Bug 533006, well. I would say that this case (and 428611) are caused by the server closing the connection, because I don't observe this behaviour with my server and Tb 3.1a1pre; the connection stays open and multiple authentication attempts can occur. However, I am not sure that Tb will "wait response forever", because I believe it is notified that the server closed the connection; see lines 457, 459, and 461 in Attachment 315691 [details] (NSPR log). I'm guessing that "804b0002" is similar to ENOTCONN or ECONNRESET. Tb should have -- but apparently did not -- notify you that there was an error of some sort during its communication with the server. I think that this may be a variation (or a duplicate) of 428611; it all depends on what you meant in the Description when you wrote: > (2) 2nd Get Msgs => successful login, because proper password. How did the "2nd Get Msgs" occur ? Did you select "File->Get New Messages for" (or use the hot key) ? I see that Tb started that 2nd connection at line 584 in the NSPR log, then successfully authenticated using the password you had entered after being prompted (in step 1 in the Description). Reading through Bug 428611, the difference between this bug and Bug 428611 is the server's support of the SASL authentication capabilities (RFC5034). Because the server closes the connection after the first Authentication Failure in 428611, Tb never gets a chance to try _all_ the authentication possibilities, which would appear to be in violation of this portion of RFC5034: If an AUTH command fails, the client may try another authentication mechanism or present different credentials by issuing another AUTH command (or by using one of the other POP3 authentication mechanisms). Likewise, the server MUST behave as if the client had not issued the AUTH command. However, because Tb first attempts AUTH PLAIN (at least, it did in the log attached to Bug 428611) and received a "-ERR" response, Tb should have assumed that the authentication credentials were incorrect and notified the user, since RFC5034 also states: To ensure interoperability, client and server implementations of this extension MUST implement the PLAIN SASL mechanism [RFC4616] running over TLS [RFC2595]. In this bug report (and in my testing), the USER/PASS authentication is used; there are no other methods to try so Tb recognizes that "-ERR" means the authentication has failed. At least, that's my interpretation from looking at only a couple of RFCs..... I hope that helps (and I do apologize for the long response and spam).

(In reply to comment #7) Michael A. Pasek, thanks for your analysis of this bug. > > (2) 2nd Get Msgs => successful login, because proper password. > How did the "2nd Get Msgs" occur? Did you select "File->Get New Messages for"? I clicked "Get Msgs" button to force next connection in test for this bug. > I think that this may be a variation (or a duplicate) of 428611; I think so too. Common Tb's problem in bug 428611, bug 429069, and bug 490140 (bugs set in Blocks: of bug 533006) is issue stated in bug 533006 when POP3 server violates RFC. Difference is external phenomenon: bug 428611 : There is no opportunity to enter correct password until restart. bug 429069 : Password is prompted by manual Get Msgs. Do you need network level trace such as tcpdump for further problem analysis?

(In reply to comment #8) > Do you need network level trace such as tcpdump for further problem analysis? No -- at least, not yet, anyway. I only asked about the Wireshark ".cap" file in Bug 533006 because I was curious as to whether that server: a) Closed the connection immediately after sending "-ERR" (as in this bug report); or, b) Closed the connection after receiving subsequent commands from Tb. What I really need to do is read more of the RFCs to determine whether Tb should continue to attempt authentication after AUTH PLAIN fails (bug 428611). Or, I need a pointer to the code that does the authentication attempt(s) -- Tb SHOULD recognize that the connection has been closed and notify the user. Both this bug and Bug 533006 will be solved when Tb notifies the user that the server has closed the connection (and offers an opportunity to retry).

A new aspect of this problem....Although RFC5034 says the server MUST act as though an AUTH command had not been issued when the authentication failed (see comment #7), the POP3 standard (STD0053) says, in the discussion of the "AUTHENTICATION" state: After returning a negative status indicator, the server may close the connection. So, for POP servers, it is apparently OK to close the connection after unsuccessful AUTH, UNLESS they're doing SASL authentication as described in RFC5034 -- at least, that's how I read it (and I'm sure there are some server implementers out there that would have a different reading!). I didn't check any of the IMAP RFCs.