Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

RETR command did not succeed

  • 6 odgovori
  • 21 ima ovaj problem
  • 1 view
  • Posljednji odgovor poslao Tonnes

more options

One of four email accounts keeps responding "RETR command etc." Went to ATT.net domain and deleted all Spam & Trash. retried get messages with same result. Then moved all current unread messages from inbox to a new folder ~ same response. ATT no help ~ "must be Thunderbird problem!!

One of four email accounts keeps responding "RETR command etc." Went to ATT.net domain and deleted all Spam & Trash. retried get messages with same result. Then moved all current unread messages from inbox to a new folder ~ same response. ATT no help ~ "must be Thunderbird problem!!

All Replies (6)

more options

Can you have a look at this question and report back if the solution helps?

Additionally, it may help to move some older messages received around the time and after the issue started using webmail. There may be one that’s causing the issue even though it seems to have been read.

In case you are comfortable and familiar with it, you could also use Telnet to log in and do a RETR command for the recent ones listed to see what responses you get.

more options

Enjoyed reading the archived thread. Left site alone as I went away to granddaughters engagement party. Cranked up TB after 5 day pause ~ no error msg. Checked ATT site & both trash / Span folders were empty. Will empty them more frequently in the future. Thanks again for suggestions!!

more options

I just started having this problem, also with att.net. It happens with two different Thunderbird profiles and does not happen with Windows Live Mail.

I went to the webmail interface. My inbox is too big to fully empty out. I emptied my Spam and Trash folders, and made sure I moved enough recent messages out of my inbox to a temporary folder so that the inbox should only contain messages that arrived before the problem started (unless the messages are sorting other than in arrival order). This still didn't help.

Thunderbird reports that it wants to download 13 messages. So using the instructions from https://www.bearfruit.org/2008/04/17/telnet-for-testing-ssl-https-websites/ and http://wayback.archive.org/web/20131217112057/http://techhelp.santovec.us/pop3telnet.htm I connected to the server. It reported 3229 messages. I issued "top 3229 0" down to "top 3210 0" (more than 13 messages) and examined the headers. I compared the subject lines to those I see in my inbox in the webmail interface, and they seem to match. So I see no evidence of hidden messages.

So I'm wondering: Where are those 13 messages that Thunderbird wants to download, one of which presumably is confusing it?

Does anyone have any other ideas for how to diagnose or remedy this problem?

more options

Pinky51: is your issue resolved?

dhg: The issue is also similar to this question and most likely a server issue; here you can find some details about the situation and instructions, this thread on mozillaZine shows some other successful methods.

Assuming there would be an issue in Thunderbird itself, I can’t think of any reason it would be wrong in fetching emails that simply don’t exist, other than when an UIDL was also assigned previously, which would be very rare but not impossible. My ISP for instance recently 'renumbered' some existing messages left on server (i.e. assigned new UIDLs for them), resulting in hundreds of duplicate local messages. Imagine the POP server assigns an UIDL to a non-existent message, or an UIDL previously assigned to a message even removed years ago (or not), which should not happen but might be possible with thousands of messages left on server. This is just a theory though.

If you really like to do more troubleshooting or just just feel interested, I think all you can do is compare the UIDLs in your local mailbox file (e.g. Inbox) and make sure the X-UIDL headers for each message are unique both in e.g. the Inbox file and in popstate.dat. Try to view the headers of the local messages around the time of the issue starting. Look for e.g. "X-UIDL: 00002c2d64db765" or "X-UIDL: 227714" - string formats may vary - from messages received around the time of the issue starting. There could be several reasons for them to appear twice or be missing instead. And even then, there could be some message looking fine, but there are reports of Thundebrid 'choking' in weird content, most often in Junk messages.

However, there is a reopened bug for this issue, at least about finding a way to cope with it more easily. At the bottom you can find an additional method to find the problematic message.

A nice description of the retrieval process can be found here. At the bottom of that page, there is a link to the Remove duplicates extension for removing duplicate local messages that may be worth a try too, but I don’t think it will fix the issue.

more options

Tonnes: Thank you very much for your extensive reply and all your suggestions! Unfortunately, I am still stuck.

Several of the links you provided mentioned moving some or all messages out of the inbox, using the webmail interface. I already tried moving all the messages that arrived starting with soon before the problem started, to no avail. I have thousands of messages in my inbox, and I can only find a way to move 50 at a time (the maximum it seems the webmail interface will let me select at once easily), so it doesn't seem practical to empty my inbox -- but I may have no choice but to work my way through this over time :-(

I tried creating a completely fresh Thunderbird profile, so there should not be any issue of corruption or inconsistency in my local mail; I have the exact same problem with the fresh profile. In light of this, I think your (interesting!) UIDL discussion is not relevant to my problem.

The old mozillazine article you link to mentions "get a transaction log for the POP3 protocol" but cites a dead link for this (not too surprising -- it's from more than 8 years ago).

Right now the options I see are: - Do not use Thunderbird with this account. - Laboriously move all 3000+ messages out of inbox, 50 at a time. - Try IMAP rather than POP3. - Do not use the problematic account directly and instead rely completely on automatic forwarding to some other account that Thunderbird likes better.

more options

dhg: Thank you for your feedback. Sorry to hear you’re still stuck.

Good to know you tried a new profile - it’s obvious there is something wrong on ATT’s end by now, or at least some content on the server that Thunderbird doesn’t like.

Did or could you try what happens for the new profile when fetching the headers only, i.e. by checking "Fetch headers only" (and of course, "Leave messages on server") for the account after setting it up? (To save the trouble of setting up the account in a new profile again, you could remove the local mail and popstate.dat file using a file explorer after making sure "Until I delete them" and "For at most n days" are unchecked, but a new profile may be safer to avoid removing messages on the server accidentally.)

Fetching headers only is of course faster than retrieving all messages for a test, and may very well succeed. If it does, the issue should occur as soon as you click the specific message’s body link to retrieve its full body content. As said, the issue may also occur because of content, not a header. That’s why sometimes a junk message may be the culprit. If the issue occurs when fetching headers only, it will be proof an example of a header Thunderbird "chokes" in as mentioned in the bug referred to (look for "header" there.) It may involve the X-YMailISG header added by Yahoo/ATT.

For the mozillaZine article, this should be the archived version / updated link. Please report back.