From Bugzilla Helper: User-Agent: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.0.0) Gecko/20020602 BuildID: 2002060216 I try to send an email. Mozilla says: AUTH PLAIN DSIFDOJFdhoIUOID SMTP server answers: 535 Incorrect authentication data Mozilla says: AUTH PLAIN DSIFDOJFdhoIUOID It looks like mozilla does not look at the response code and tries to send auth info again and again. Reproducible: Always Steps to Reproduce: 1. Create a mozilla mail account for smtp.web.de and any name and password 2. Send mail with this account

This could be a dup of bug 141052.

Just checked if it's a dup of bug 141052. It's not. 141052 is not looping. In this bug here, mozilla loops. It send the AUTHINFO again and again and does not stop.

I think the reason is nsSmtpProtocol.cpp: nsSmtpProtocol::AuthLoginResponse 807 switch (m_responseCode/100) 808 { [...] 815 case 5: 816 default: 817 if (smtpServer) 818 { 820 if (mLogonCookie.IsEmpty()) { 821 smtpServer->ForgetPassword(); 822 if (m_usernamePrompted) 823 smtpServer->SetUsername(""); 824 } 825 m_nextState = SMTP_SEND_AUTH_LOGIN_USERNAME; 826 } If the user does not use password manager, he is prompted for the password again and again. This makes sense, but I think there is no "cancel" button. But if the user uses password manager, the password manager always returns the same wrong password and the thing loops.

This is heppening for me too. It results in a locked mailaccount for 24 hours ! This is reproduceable and I have a log from the communication with the mailserver (created with Ethereal). 220 {mp006-rz3} GMX Mailservices ESMTP EHLO gmx.de 250-{mp006-rz3} GMX Mailservices 250-AUTH=LOGIN CRAM-MD5 PLAIN 250-AUTH LOGIN CRAM-MD5 PLAIN 250-PIPELINING 250 8BITMIME AUTH PLAIN XXXXXXXXXXXXX 535 {mp006-rz3} auth failure AUTH PLAIN XXXXXXXXXXXXX 535 {mp006-rz3} auth failure (I've replaced the password with XXXXXXXXXXXX) I've setup my mail account with smtp auth (as shown in the log) Then I've changed my mail password (XXXXXXXXXX => my old password) POP3 displayed the message (login failed => invalid password) SMTP sends the old password until the user presses stop

see also Bug 155172

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 I am using the Password Manager as well, however, this is not my primary email client at work. I just opened the Mail & News module and it had an old POP3 password stored. Our internal mail server is SLmail v5.1.0.4420 on an NT 4.0 SP6a server. Our SLMail is not requiring authentication for incoming SMTP, but is requiring authentication for POP3 access. The Password Manager seems to be attempting to repeatedly authenticate ("The PASS command did not succeed. Mail server mail responded: invalid password") without allowing the user to Cancel and attempt a new password. The pop up says Alert in the caption bar, and has the ! in a triangle image. Pressing OK just pops up the same alert again. However, closing the pop up alert using the X Close window at the top right, it closes, the Mail & News window is still up and running, and the status bar at the bottom shows that it thinks it is still sending login information. Also, at this point, I can go into the Preferences module without interruption and check/change settings. My client system is Win2000 Pro, SP3.

Did you see this?: http://kb.mozillazine.org/Password_not_remembered_%28Thunderbird%29

jens, et al, Do you find this and its ilk, eg bug 155172, still fail? bz marked this dupme but it's not clear what he had in mind - perhaps Bug 121926 or Bug 141052, which you seem to have ruled out?

I tested it and it seems to be fixed at least in Thunderbird. If TB recognizes that the password is wrong, it repeatedly asks for the password, even if I check "remember password".

(In reply to comment #9) > I tested it and it seems to be fixed at least in Thunderbird. If this works in TB then it should also work for suite, which it does - WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061025 SeaMonkey/1.5a perhaps several other bugs in this area of networking now work that are still marked open. (Over a dozen bugs fixed since 2003, so hard to say which checkin fixed this bug and any others without examining them all.)