pop3.web.fr and pop.orange.fr seem to close the TCP connection when we issue any command after a password failure. That breaks the "new password" prompt feature, and leaves us dangling. Reproduction: 1. Delete password from password manager 2. Get Mail from POP account (must be such a server implementation) 3. Enter "nonsense" at the password prompt 4. Confirm the auth error dialog 5. In the "Login failed" dialog, click "Retry" or "New password" 6. Enter "othernonsense" in the new password prompt Actual result in UI: Nothing happens Status bar in main window says "Connect: Host contacted, sending login information..." - forever (no timeout) Actual result on the wire, per Wireshark: 1. Normal POP protocol - CAPA, USER, PASS. 2. Server says "-ERR auth fail". Connection stays open. 3. (User enters password) 4. We send CAPA or USER 5. Server closes connection (I think, it gets red in Wireshark) 6. Nothing happens anymore, but we don't notice that. Expected result: Either - Error dialog "Server closed the connection. Please try again". - Reopen a new connection and try again

Bug 429069 for simplest USER/PASS,-ERR,CAPA,connection-close-by-server case. NSPR log attached to that bug has log by nsSocketTransport:5 also. > https://bug429069.bugzilla.mozilla.org/attachment.cgi?id=315691 I think connection-close is properly detected at socket level. Can you look into log?

(In reply to Description) > [...] > Actual result on the wire, per Wireshark: > [...] > 5. Server closes connection (I think, it gets red in Wireshark) > [...] Can the ".cap" file be attached ? (In reply to comment #1) > [...] I think connection-close is properly detected at socket level. > Can you look into log? As I noted in Bug 429069, Comment #7, I also believe the connection close is properly detected at the socket level. I agree that the expected result should be some sort of "Server Error" message.

> Expected result: > Either > - Error dialog "Server closed the connection. Please try again". > - Reopen a new connection and try again From Bug 533083, by the Reporter: > So, I agree with bienvenu: On startup, we could maybe ask for the password, but > must not alert for errors. That eliminates Option 1 of the "Expected Results". Option 2 will likely result in an endless loop (e.g., if the password is bad), probably resulting in account lockout.

> That eliminates Option 1 of the "Expected Results". No, it doesn't. This bug is not about the start up situation, but about manual checks, too (Step 2 in Reproduction). The same action that creates a dialog in manual check doesn't when the action is initiated by biff. That's exactly what the lack of msgWindow does (see the comment that you remove in the patch in bug 533083).

Replace step 2 with "Check for messages at startup". If it's OK to leave the user with the "Actual Result" at startup (when they've selected to have messages retrieved), then it must be OK at other times, too. The comment (and the code) that I removed does prevent alerts, but it also prevents prompting for a password (and causes Bug 529364). As noted in my comments in Bug 533083, passing/not-passing the msgWindow is NOT predicated on the fact that we're doing biff, it's predicated on whether or not "Automatically download messages" is enabled/disabled. Why on earth should _that_ control whether or not the user sees prompts/alerts ??

Michael A. Pasek, this bug has absolutely nothing to do with biff or startup. Please don't cloud the issue or clutter the bug with orthogonal issues. This is a manual action which just silently fails. A manual, direct action from the user must either just work or fail with an understandable explanation of the reason.

pop.gmx.de does the same, also for unknown usernames. You can easily reproduce by trying to log in via USER/PASS with "B.Thunder@gmx.de" as username. The server closes already after the USER.

if this isn't a dup of an existing 3.1 blocker, I think this should probably block 3.1

> pop.gmx.de Testing again, it doesn't close the conenction anymore. Might be a different condition causing it.

$ netcat pop3.web.de 110 +OK POP server ready H miweb001 USER fred +OK password required for user "fred" PASS dghj -ERR authentication failed (connection closed) $ netcat pop.orange.fr 110 +OK connected to pop3 on 2c12 USER dgjfj (stall, no answer)

I chatted with bienvenu, and he thinks our POP code can deal with connection errors, it's sometimes triggering when we try to read or write. He suspects that the socket transport implementation in necko is at fault here.

We're resetting the blocking flag for 3.1 on this bug and instead setting the wanted-thunderbird+ flag. We have too many blocking-3.1 bugs, to the point where it doesn't mean much, and managing the list is making it hard to actually work on closing bugs, which helps no one. Thunderbird 3.1's primary purpose is to allow us to offer a prompted major update to Thunderbird 2 users, to ensure their continued ability to safely use Thunderbird. Thunderbird 2 is built on an outdated version of Gecko, and our long-term ability to maintain the users' safety for Thunderbird 2 users is limited. If you think this bug meets the requirements below, please renominate with a detailed explanation of how it meets the following two criteria, and we will reconsider. To qualify, this bug must either: a) make the upgrade experience from TB2 very painful for a large number of users or b) be a new, reproducible, severe quality issue (eg dataloss, frequent crashes) Just because this bug doesn't block TB3.1 doesn't mean it can't or won't make the release. Once they're done with their blockers (if any), we encourage developers to keep working on non-blocking bugs, and to try to land them as early in the cycle as possible, as non-blocking bugs will become increasingly difficult to land in the later stages of the cycle.

xref bug 542259

I think this is a dup of bug 505481. The error message in the most recent case in that bug report probably occurs due to recent AUTH and password prompt changes in nsPopProtocol.cpp.

Ben is this fixed by bug 428611 ?

Not sure. I don't think so, but maybe, we'd need to test. Could you test the initial reproduction, please? (You are QA, after all ;-) )

(In reply to comment #16) > Not sure. I don't think so, but maybe, we'd need to test. Could you test the > initial reproduction, please? (You are QA, after all ;-) ) I would if I had accounts there :-)

this is a bit different than bug 428611 because the dropped connection happens after the next command after the auth failure, according to the initial report. But it's certainly worth retesting.

> I would if I had accounts there :-) You don't need accounts, because the bug appears when you enter a *wrong* password. See initial description: > 3. Enter "nonsense" at the password prompt > 6. Enter "othernonsense" in the new password prompt

FYI. There is server side setting of "silent connection killing upon authentication phase failure". Following is copy of Bug 155172 comment #27. > Our company is using qmail-ldap (qmail with LDAP patch) as SMTP server > with authentication (SMTP-Auth) over TLS and we had one option > called SMTP550DISCONNECT (it is an environment variable) active, > this drops the connection when a 550 error occurs during the SMTP dialogue. > The symptom is very similar to the one described on this bug, > and once I removed the option, clients were asked to inform a new password > when the authentication fails. SMTP550DISCONNECT is perhaps almost mandatory when dial up connection.

> Component: Networking:POP3 According to Bug 155172 comment #27, "no password prompt problem after this bug" can happen on SMTP too. Is this bug for POP3 only?

> Is this bug for POP3 only? Bug 701474 is about SMTP. I think it's better to keep them separate, yes.

Ben, is this solved by bug 1400359? I added notifications for connection reset as well. You need to try a local build or today's Daily (assuming it builds).