Closed Bug 227665 Opened 21 years ago Closed 7 years ago

RETR Command fails and no subsequent mail retrieved.

Categories

(MailNews Core :: Networking: POP, defect)

x86
Windows XP
defect
Not set
major

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: beneisenstein, Unassigned)

References

Details

Attachments

(2 files)

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

The following message occurs with some junk mail. No further mail is retreived.

"The RETR command did not succeed. Mail server mail.comcast.com responded: ved:
from -------------some address here------------- (untrusted sender)."





Reproducible: Always

Steps to Reproduce:
1.Click on "Get Messages"
2.
3.

Actual Results:  
No mail is retreived.

Expected Results:  
Delete or mark the mail as junk.
Severity: normal → major
Summary: RETR Command fails and no subsequent mail retrieved. → RETR Command fails and no subsequent mail retrieved.
Second sentence of Expected results should have read "Continue retreiving mail."
Oh great, comcast again.
Ben, in your expected results you're writing "Delete or mark the mail as junk".
The latter isn't possible as the mail isn't downloaded. We can only mark mails
we've in the inbox.
And delete it, hm, could be possible, but simply deleting any mail that can't be
downloaded might lead to data loss if such a mail isn't junk.

A mechanism that would at least help getting the subsequent messages is to step
over this error and continue retrieving the other mails. To let the user know
there was a problem, the error should still be displayed.

What do you do if this error occurs? Deleting the message via webmail and
continuing with Mozilla?

I think you're using POP, yes? If so, please set this bugs component to
"Networking: POP" - this isn't a front end issue.
OK, it's changed to networking:pop issue.

I have to admit I don't really understand the error. I tried looking it up on 
the net but couldn't find anything about what an untrusted sender was. This 
makes it hard for me to recommend an action other than make it go away and get 
the rest of my mail.

I downloaded the Thunderbird mail client today and that worked just fine. 
However it is handling the errors suits me. MS Outlook Express also seems to 
handle it (although this is the client I am trying to get away from!)
Component: Mail Window Front End → Networking: POP
Aha, so, Thunderbird works (and OE too), did you also try a recent Mozilla
version (e.g. the just released 1.6b)? How often did you get this error? That
means, are you sure you had one of these mails while testing with TB and OE?

The error messages from comcast doesn't mean anything to me too (error messages
aren't standardized). To have a mail in the maildrop and to not give it away is
simply wrong.
The only condition if you are able to retrieve a message or not is if you're
logged in to the server or not, nothing more and nothing less. So there isn't
much Mozilla can do better to prevend such a failure.
2 messages are on the server. TBird retrieves one and then an error.
Attached file 2 messages received ok (deleted) —
This log shows 2 messages being retrieved successfully. Note this client
deletes the messages from the server.
Attachment #137629 - Attachment description: Fails to retrieve 2 messages → Fails to retrieve 2 messages. Note that this client leaves messages on the server.
I recreated what I think is this same bug. I could only get the error if I
configured the client to leave the messages on the server. Details...

Client: Thunderbird  0.4 (20031205)
Server: mail.comcast.net
OS: XP Pro

I receive a similar message from the server if more than 1 message is on the
server: "The RETR command did not succeed. Mail server mail.comcast.net
responded:". Not that the message is truncated prematurely.

Behavior is as described: doing a subsequent "Get Mail" retrieves the next message.

I have two mailboxes on Comcast. Only one account has the problem. The
difference is on the one demonstrating the problem, I have it configured to
"Leave messages on the server". If I uncheck that option, I no longer see the
problem.

See the 2 logfiles added on 12-17-2003.
Thanks for the logs! They clearly show what's going on. The normal flow is the
following:
SEND: RETR msgnumber
RECV: +OK
RECV: multiline message content

What the failed log shows is:
SEND: RETR msgnumber
RECV: first line of message content

The +OK is simply missing for the second mail. 

Hm, knowing that, that's really this bug. The alert the reporter got now makes
sense.

"ved: from -------------some address here------------- (untrusted sender)."
This is a part of the first line from our receive buffer. That's simply from a
line like "Received: from mail2.zoneedit.com (untrusted sender)" without the
first 5 chars (which are stripped because negative responses normally begin with
"-ERR ").

For Mozilla every status not beginning with + is negative and so the retrieve
didn't succeed. And so we do POP3_ERROR_DONE, POP3_FREE and leaving.


There's a little chance Mozilla is choking and the servers "+OK" got lost, but I
doubt it. I really think there's a server problem.
To be sure a log with an independend sniffer like Ethereal would be very
helpful. Dan, do you know how to use such an application?

And secondly, what can we do if such an error occurs? Really leave because of
this failure? Discard the receive buffer (we should, there are waiting 1083
bytes) and continue getting the next message (with a good probability to get the
same result)? Or use our m_commandResponse as input for the first message line
and continue with the other lines then like everything's ok?
Status: UNCONFIRMED → NEW
Ever confirmed: true
I've been leaving my mail on the server. So this last discovery from Dan fits
with my situation. The best option would be to retrieve as described:

"use our m_commandResponse as input for the first message line
and continue with the other lines then like everything's ok?"

This way nothing gets lost. 
Here's a trace of when I get this problem. It appears that, at least to start
with, Mozilla Mail ignores the list of messages it retrieved and tries to get
number 1 anyway.

+OK POP3 Server ready <101309.1088943231241831@c2bpop05>
AUTH
-ERR Unrecognised command
CAPA
-ERR Unrecognised command
USER xxxxxxxx
PASS yyyyyyyy
+OK Mailbox locked and ready
STAT
+OK 246 636182
LIST
+OK Scan listing follows
8 2422
<snip>
253 1500
.
UIDL
+OK unique-id listing follows
8 40243afe000003ad
<snip>
253 40243afe000004a2
.
XSENDER 1
-ERR Unrecognised command
RETR 1
-ERR Invalid command argument
Yes, that's right, see bug 226669 and bug 238087.
What version do you use? These bugs are fixed since about two months (e.g. in 1.7).
I am getting this in 1.7.
> I am getting this in 1.7.

Sorry I made a mistake, the fix didn't go into 1.7 since it was to short to
release. You've to use a newer version.

But the log from comment #10 wasn't made with 1.7, yes? As can be seen, the
client in your log issues the XSENDER command. A fix not to use it unless it's
allowed in CAPA response was checked in in January and is guaranteed to be in 1.7.
Yes, the trace I posted was 1.6 but I recreated it in 1.7. You'll have to trust 
me though as my monitor just broke and I literally can't see a thing. The main 
characteristic is the same though. The mail client executes "LIST" and "UIDL" 
and still proceeds to "RETR 1" even though the list starts at some other 
number. Now after a few tens of tries the server seems to reset the numbering 
to start from "1".

I'll try with a beta when I get a screen that works. In the meantime, the issue 
still remains that this modal, repeating message box stops everything else 
happening - no other accounts' mail gets downloaded until you press "ok".
Product: MailNews → Core
sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.
Assignee: sspitzer → nobody
Filter on "Nobody_NScomTLD_20080620"
QA Contact: esther → networking.pop
Product: Core → MailNews Core
Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.
This should be fixed according to comment 14
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: