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•20 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•20 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•20 years ago
|
||
I am getting this in 1.7.
Comment 13•20 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•20 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•17 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
Updated•10 years ago
|
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
•