User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a4) Gecko/20040928 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a4) Gecko/20040928 When POP3 server(APOP) responds "-ERR [AUTH] CRAM-MD5 authentication is disabled." to "AUTH CRAM-MD5" request, 2004100105-trunk/Win-2K retried logon forever. No probelm on 2004092805-trunk. Reproducible: Always Steps to Reproduce:

Christian: This is to 99,9% caused by your Patch from Bug 257299.

(In reply to comment #1) > 2004100105-trunk/Win-2K retried logon forever. > No probelm on 2004092805-trunk. Right Frank, this is caused by my patch. The "[AUTH]" means according to RFC 3206 "any authentication error caused by a problem with the user's credentials." Before the patch we just continued trying other mechanisms, now we go the password failed way. Besides the fact that the server is lying (not the credentials are wrong but CRAM-MD5 disabled - besides he still advertises it ...), normaly password failed should ask for a new password. Because of to many false password discards we never do this anymore if sending the password succeeded once in this session. Can this have been the case, Wada?

While in the case Wada logged it's not really true, we could trust the server if it sends the [AUTH] code. This patch forces the password dialog for this case.

Comment on attachment 160850 [details] [diff] [review] proposed patch Sorry, wrong patch

This is what I meant.

That's much better. Instead faking around, just use POP3_AUTH_FAILURE as indicator to forget password in GetPassword(). Also clearing the flag should not be forgotten.

David, IIRC you implemented this isAuthenticated and m_pop3ConData->logonFailureCount. So what do you think?

Comment on attachment 160856 [details] [diff] [review] patch v2 looks good to me - sorry I didn't comment earlier; I never saw the bugzilla mail notification

Patch v2 has been checked in as part of patch for bug 249240.

Tested on Mozilla Suite 2004102805-trunk/Win-2K. Problem still occurs. If password was deleted from password manager and "use password manager" was not requested on any password prompt, retry loop could be canceled. But once "use password manager" was requested on a password prompt, password was not prompted anymore, and uncancelable infinite retry loop occured again.

(In reply to comment #12) > Tested on Mozilla Suite 2004102805-trunk/Win-2K. > > Problem still occurs. Strange. While I don't have such a server like you, my simulated one should behave like it. And since my patch it works well here. Note, it will still loop if a) the server doesn't answer with [AUTH] (although it does in your posted logs). b) your username contains a dot (.), see bug 263542. If nothing of both applies to you I can't help with a more detailed description and new log (if it differs from the others). BTW, you can cancel the loop if you don't click "OK" but press ESC and hold it until the dialog stops.

> (In reply to comment #12) > b) your username contains a dot (.), see bug 263542. Gotcha! My username contains multiple dots - userid@server.subdomain.company.ne.jp > BTW, you can cancel the loop if you don't click "OK" but press ESC and hold it > until the dialog stops. I closed pop up dialog by clicking close button("X" of top/right corner). This probably means I pressed "OK" button. Anyway, my original problem of this bug has been fixed by you. And my latest loop in comment #12 is DUP of bug 263542. So I change this bug "VERIFIED". Thanks a lot, Christian.

No problem. Let's hope the dot-escape-bug will be fixed soon.