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)
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.
Updated•21 years ago
|
Severity: normal → major
Summary: RETR Command fails and no subsequent mail retrieved. → RETR Command fails and no subsequent mail retrieved.
Reporter | ||
Comment 1•21 years ago
|
||
Second sentence of Expected results should have read "Continue retreiving mail."
Comment 2•21 years ago
|
||
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.
Reporter | ||
Comment 3•21 years ago
|
||
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
Comment 4•21 years ago
|
||
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.
Comment 5•21 years ago
|
||
2 messages are on the server. TBird retrieves one and then an error.
Comment 6•21 years ago
|
||
This log shows 2 messages being retrieved successfully. Note this client
deletes the messages from the server.
Updated•21 years ago
|
Attachment #137629 -
Attachment description: Fails to retrieve 2 messages → Fails to retrieve 2 messages. Note that this client leaves messages on the server.
Comment 7•21 years ago
|
||
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.
Comment 8•21 years ago
|
||
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
Reporter | ||
Comment 9•21 years ago
|
||
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.
Comment 10•21 years ago
|
||
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
Comment 11•21 years ago
|
||
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).
Comment 12•21 years ago
|
||
I am getting this in 1.7.
Comment 13•21 years ago
|
||
> 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.
Comment 14•21 years ago
|
||
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".
Updated•20 years ago
|
Product: MailNews → Core
Comment 15•18 years ago
|
||
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
Assignee | ||
Updated•16 years ago
|
Product: Core → MailNews Core
Comment 18•9 years ago
|
||
Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.
Comment 19•7 years ago
|
||
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.
Description
•