235205 - MailNews stops checking an account after the server connection closes prematurely

Status: RESOLVED EXPIRED

(MailNews Core :: Networking: POP, defect)

Description

[Seairth Jacobs]

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

I have been receiving mal-formed e-mails lately.  These e-mails cause the POP3
server to spontaneously terminate its connection on RETR of the bad message. 
The problem with Mozilla is that, once it encounters the disconnect, it stops
checking messages for that account.  The only way to get it to start checking
again is to restart the application.

Reproducible: Always
Steps to Reproduce:



Expected Results:  
Mailnews should continue to check, even if it cannot get beyond that message. 
Ideally, I would like mailnews to detect that a specific message is causing the
problem and offer to delete it for me.  Otherwise, I have to go in through
WebMail (which I don't always have installed) or Telnet in and delete the
message by hand.  Also, if the bad message is (e.g.) number 89 of 90, then the
prior 88 messages do not get deleted from the server.  In the meantime, the
messages continue to fill the message queue (msg 91+) while subsequent checks
from mail appear as though there are no new messages at all.

Again, I realize that the connection problem is with the server, not MailNews. 
However, MailNews also flakes out in the process.  And even if it didn't, it
could be more proactive in resolving the problem.

Comment 1

[Max Alekseyev]

dup of / related to bug 195596 ?

Comment 2

[Seairth Jacobs]

No, that bug is different.  In that case, the download process is being stopped
because of a dialog box.  Once the box is closed, normal operation can continue.
 In my case, the server is about to respond to a RETR POP command and suddenly
terminates the connection.  Mozilla does not display any error message.  In
fact, it does not do anything at all, not even check mail again (at the given
time or if manually invoked).  The only way to get around this is to restart
Mozilla.  If the offending message is not removed from the server first, then
Mozilla immediately hits the same problem again.

For a user who is not using WebMail and does not know how to Telnet a POP
session, by all outward appearances, it would just look like they were not
getting mail through that account anymore.

Now, it may be that the appropriate response is to throw up an error message. 
If Mozilla at least did that (and was still able to check messages again later
without restarting the app), then it would be an improvement.

Ideally, I would like Mozilla to allow deletion of the offending message
directly so that I don't have to use WebMail or Telnet to do it.  But I realize
that the "bad message" part of the problem doesn't really have to do with
Mozilla (OE doesn't deal with it either, though it doesn't fail in the way
Mozilla does).

Comment 3

[Lewis Rosenthal]

I have to deal with this situation all too often, with not only my own mail
server, but with others (I support a broad range of clients with varying OSes,
and always recommend the Mozilla suite and/or FF/TB). When the client's mail is
hosted on my server, it's usually a simple matter for me to VNC to the box or
telnet in to zap the offending message, though it sure would be nice if Moz
would flag that message number as "irretrievable" and continue with the rest.
Instead, after numerous attempts to download messages, one ends up with a hoard
of duplicate messages which must be manually deleted.

Also, this should probably be changed to OS=All, as I think this is pretty much
cross-platform (at least, I know it happens on Win32, OS/2, and Mac; I haven't
yet observed it under Linux).

Comment 4

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 5

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.