No error message displayed when wrong password for POP3 account is entered

RESOLVED DUPLICATE of bug 428611

Status

RESOLVED DUPLICATE of bug 428611
12 years ago
10 years ago

People

(Reporter: lupincho25, Unassigned)

Tracking

1.8 Branch
PowerPC
macOS

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4
Build Identifier: 2.0.0.6 (20070728)

POP3 account at gmx.net (using SSL to connect to the mail server). If I enter wrong password, Thunderbird shows "sending login information" in the bottom bar, but doesn't display any error message after that. 

I did some troubleshooting as suggested here:
http://kb.mozillazine.org/Session_logging_for_mail/news

When the password is entered correctly, the following appears in the log:
     RECV: +OK Mailbox locked and ready

When the password is entered incorrectly, in the log it says:
     RECV: -ERR Authentication failed.
however Thunderbird doesn't show any error message.

More observations: if wrong password is entered, it obviously doesn't download any new messages (if there are any). However, if there are no new messages on the server, it doesn't show "There are no new messages..." in the bottom (after "sending login information"), and this is how I can figure out that I entered a wrong password.

Reproducible: Always

Steps to Reproduce:
1. 
2.
3.
(Reporter)

Comment 1

12 years ago
This may be specific to gmx.net. Tried an email account with my webhosting provider and Thunderbird displayed error message, both when using POP3 both with SSL and without SSL.

Comment 2

11 years ago
I had a similar case here on both Windows and Linux, with latest TB 2.0.0.9, also with GMX as the mail provider. After changing the password, TB silently ignored any new mails. I had to manually delete the saved password from the password manager list in order to get a password dialog and save the new password.

I did some further investigations with logging using both TB and Wireshark. The interesting part seems to be after the "-ERR Authentication failed." message. Then TB enters state 34 (POP3_AUTH_FALLBACK) and sends "USER <userName>". Upon receiving this command, the GMX POP3 Server tears down the TCP connection without any further payload data. TB does not issue a message for this, but stops silently.

I still have to figure out whether the server has any right to tear down the connection. TB not issuing any error message is an error for sure.

Comment 3

11 years ago
Created attachment 291172 [details]
Wireshark capture of network traffic

Comment 4

11 years ago
Created attachment 291173 [details]
TB log of network traffic and state transitions
Martin, Lupincho25, does this still happens with a recent version of Thunderbird 3 (like beta2 which can be downloaded from :http://www.mozillamessaging.com/en-US/thunderbird/early_releases/downloads/ ) ?
Component: General → Networking: POP
Product: Thunderbird → MailNews Core
QA Contact: general → networking.pop
Version: unspecified → 1.8 Branch

Comment 6

10 years ago
I won't be able to install a TB3 beta before next week. In case I forget about it by then, please ping me again, though I'll try not to forget.
(In reply to comment #4)
> TB log of network traffic and state transitions
(In reply to comment #2)
> Upon receiving this command, the GMX POP3 Server tears down the TCP connection without any further payload data.
> TB does not issue a message for this, but stops silently.

Same situation as Bug 428611. See also Bug 429069 for similar situation.
Tb never stops login process. Tb simply waits for response forever(USER command in your case). 
As I wrote in Bug 429069 Comment #1, server should keep "AUTHORIZATION state" after -ERR to login request, but server silently stops processing. In this case, error detection by Tb(e.g. timeout detection) doesn't seem to work or Tb doesn't have such mechanism for AUTH/USER/CAPA command.

Confirming based on POP3 log.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 428611
You need to log in before you can comment on or make changes to this bug.