243152 - Mozilla shall have a time-out for authentication on secure pop3 server

Status: RESOLVED INCOMPLETE

(MailNews Core :: Networking: POP, defect)

Description

[Constantine A. Murenin]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.6) Gecko/20040113
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.6) Gecko/20040113

I've changed my password on the server and Mozilla's Password Manager does not
yet know that I did so. I try to check my mail over secure pop3 server, but
Mozilla does not show that the password is not correct. Last thing it says is
"Connect: Host contacted, sending login information...". It does not say "No new
messages on the server", nor does it says that the password is incorrect. 

Reproducible: Always
Steps to Reproduce:
1. Change your password on the server.
2. Open mozilla, check your mail with your old password in the password manager.
Actual Results:  
No error message appears, nor do any new messages are downloaded/reported. 

Expected Results:  
Error message like "your login/password is incorrect".

The pop3 server in question is pop.cs.ecu.edu over secure connection (port 995).

Comment 1

[Constantine A. Murenin]

People on IRC have suggested that the server just closes the connection and does
not say anything if the login is incorrect. If this is the case, then mozilla
should return some general kind of error. No error in this situation is
unacceptable, because it is clear that mozilla does not succeed in asking the
server for the new messages. 

Comment 2

[Christian Eyrich]

> People on IRC have suggested that the server just closes the connection

That was also my thought. Maybe it responds with an error code and then
disconnects. But we fall down the available mechanisms before reporting that
sending the password failed. So if the server disconnects after the first
mechanism, we don't hit this point.

Before doing anything I'd like to be sure what happens. So please have a look at
http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#pop and attach us
(please use the above option for this) a communications log.

Comment 3

[Constantine A. Murenin]

Attachment: secure pop3 log file

This is the tail of the log file after exiting Mozilla App Suite. From @guard,
I can see that mozilla never closes the connection to the server, i.e. it seems
to be waiting for the server to answer something, but the server stays still
(i.e. it does not say anything, nor does it close the connection). 

Clearly, the server is broken. :-) Nevertheless, mozilla should have some
timeout for mail/news as well as it does for http. I bet this is not the only
installation of a pop3 server that behaves this strange way.

Comment 4

[Christian Eyrich]

Yes, some timeout would be nice also in other situations.
The protocol handler itself isn't active at this time and is only called if
something is on the wire.
So the timeout has either to be in the low level code or some kind of timed
callback has to be implemented.
Unfortunately that's nothing I could do.

Comment 5

[Constantine A. Murenin]

This is a blocker. An important email was delayed almost a week, due to this
problem. 

(Having the same account for computers in the school lab, and for remote access
to the mail, I was required to change the password at school and never even
thought about the need to change it at home in mozilla. This caused one
important email to not being received by me for 4 days, due to the fact that
mozilla never told me that the authentication failed. I noticed it only today,
when I called my supervisor and asked why I have not received anything. Later
on, I remembered about this issue and it became clear to me what's going on.)

The message I finally received still holds, but someone could loose his whole
business if such situation occurs with a time-expiring message. 

If someone is unclear what a time-expiring message is, then it is a message that
holds the information once significant, but now useless. For example, "your
domain expires in 7 days" received on the 8th day, or "your job application
needs a signature by this evening" received the next week, etc. This is a clear
loss of data. 

Changing Severity to Critical, due to the mentioned "loss of data". 

Comment 6

[Walter 'Dutch' Duering]

Following the instruction to look for a possibly related bug before creating a new bug report, I've landed here.

Situation: downloading or uploading files receive server timeout error message with attachments > about 300KB +/-30KB; different response by mail client based on whether being uploaded or downloaded.

Local conditions:
     Firefox 2.0.0.3; This error did not occur with the previous version.

     Connected via MODEM (this seems important)

     OS: Windows XPPro, Build 2600.xpsp_sp2_gdr.061219-0316 : Service Pack 2


Repeatability: Everytime

Has been tested against 2 mail servers: 1) my ISP; and, 2) my host's servers.  
Behaviour the same from both mail servers.  Different companies.

Specifics:

Downloading or uploading, the error message seems to be presented at about 60 seconds.  The following data is extracted from an email sent to my host when I believed the problem resided there.

QUOTE
Time before time out

I attempted to download the email with the 2,452 KB attachment four times while monitoring the approximate time to to time-out
    65 sec
    72 sec
    67 sec
    64 sec

These are not stop-watch accurate times.  Also, these times include the time for the email client to establish the connection with the server, which is at least four seconds.
END Quote

It is at this point that Firefox's behaviour changes.  If it is a download, this terminates the downloading of any other messages as well.  Before I discovered what was happening this permitted the mailbox to fill.  This resulted in bounces that caused the loss of data I'd been expecting.

If I am uploading the error message occurs, but Firefox continues to transmit the email.  The intended recipient DOES receive the email; the message is not posted to the sent mail box.

Thank you.

Comment 7

[(not reading, please use [e-mail] instead)]

sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.

Comment 8

[Wayne Mery (:wsmwk)]

do you still see this problem?

Comment 9

[Joshua Cranmer [:jcranmer]]

RESO INCO per lack of response to last comment. If you feel this change was made in error, please respond to this bug with your reasons why.