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
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
See Also: → 227551
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: