By all accounts, this seems to only happen with Yahoo-type mail servers, which includes ATT, Verizon, Rogers, BT etc.

http://kb.mozillazine.org/Yahoo#The_POP3_email_server_.28plus.pop.mail.yahoo.com.29_does_not_support_UIDL_or_XTND_or_XLST

I doubt the POP parameters in TB are getting corrupted, but rather the Yahoo server is malfunctioning. As annoying as it may be, restarting TB is probably the best workaround. Although it's probably no consolation to you, Yahoo accounts have been relegated to the 'not recommended' category for some time.

As a retired software professional who wrote his first computer program in 1966, I have to disagree with your response. You claim that the error is in the POP3 server, in my case inbound.att.net. When my TB gets into this error state, it remains in this state. There have been times when I have not been at my computer for 12-24 hours, and my TB will not connect to the POP3 server. If the server were at fault, then I assume that there would be MANY at&t customers who would be complaining about the outage. But I have not seen evidence of this. Assuming that at&t notices this error and reboots the inbound.att.net server, my TB should be able to connect to the rebooted POP3 server. But my TB does not connect. I can connect ONLY after Exiting TB and re-starting it. This implies that the connection parameters that my TB is sending to the server are bad.

I would love to do a test (which obviously I cannot do) - when my TB gets into this state, start another TB instance and try to connect to the POP3 server. This would prove who is correct.

I have to conclude, using Occam's Razor, that the connection parameters that my TB, in its corrupted state, are sending to the POP3 server are incorrect. But I do not know enough about the internals of TB to be able to look at the dump and make any assessment.

One thing I could try - I could change the connection parameters and then set the, back to what they were. Updating the parameters might re-set the corruption.

If you had a security program scanning SSL connections (secure POP uses port 995 with SSL/TLS security), it's possible it could cause some kind of interference or 'corruption'. But I think you will find the error persists even if SSL scanning is disabled or the AV completely turned off.

As the links in my reference show, it's a common issue with Yahoo servers. It may not be as common as you expect, given that most users have moved to IMAP setups, for which the error doesn't appear.

I still cannot accept your reply. If the problem is in the POP3 server, then I would not be able to download mail until the server is rebooted. I can not think of any other way to correct the problem, according to your scenario.

My experience is that rebooting the server CANNOT be the solution to the problem, If I had to wait until the server were rebooted, my wait time would depend upon how quickly the ISP resets the server. In my experience, I can Exit TB and restart, and the mail is immediately downloadable. I have a hard time believing that if I Exist and restart within five minutes, the ISP had corrected the problem, but if I am not at my computer for 12-24 hours, my ISP has not corrected the problem until (mysteriously) I Exit TB and restart.

I have read the http://kb.mozillazine.org/ article before, and I am assuming that the author(s) have/had not considered my theory.

In the answers.yahoo.com article, there is ONE case where TB worked after Yahoo! fixed their server; in the other cases, the users re-started TB.

In the ubuntuforums.org article, the user states that a re-start of TB corrects the problem.

As I see it, there is only one way to resolve this "dispute". Someone with access to the source code and compiled listings needs to tell me what Windbg commands to issue to find the connection parameters in my dump. Or I can place the dump in a location where someone who has more TB internals knowledge than I can review the dump.

I have not looked at the RFC 5321 SMTP standard or POP3 standard in a long time, so I do not know if the POP3 server can respond to a command from the client in such a way as to cause the client to change the parameters in an incorrect way.

I am using plain Occam's Razor logic - it has worked for me in my many years of IT systems administration. Yes, re-starting TB will clear the problem, but in the process it destroys all evidence as to what happened. This is the problem with Windows operating system debugging mentality. When I was working with IBM mainframe systems, my job was to look at every system dump and determine what happened.

I don't have the technical knowledge that you guys have but I can tell you if you uncheck the "Leave messages on Server" box it resolves the problem. Maybe that will help you figure it out. Unfortunately that is not a good option for me. I have a computer in my office and one at home and I want my emails to go to both computers. By unchecking "Leave messages on Server" my emails go to one compute or the other but not to both.

TexMech said

I don't have the technical knowledge that you guys have but I can tell you if you uncheck the "Leave messages on Server" box it resolves the problem. Maybe that will help you figure it out. Unfortunately that is not a good option for me. I have a computer in my office and one at home and I want my emails to go to both computers. By unchecking "Leave messages on Server" my emails go to one compute or the other but not to both.

Your method seems to contradict the advice given here, and probably explains why the messages can't be downloaded by more than one computer. The best way to access accounts on multiple devices is to set them up as IMAP.

My provider is AOL. Will the IMAP setting work with them?

For AOL, use imap.aol.com on port 993, SSL/TLS security, authentication = OAuth2, User Name = email address. For the outgoing server: smtp.aol.com on port 587, STARTTLS security, authentication = OAuth2, User Name = email address.

If you are changing from POP to IMAP:

http://kb.mozillazine.org/Convert_a_POP_account_to_a_IMAP_account

Thanks, I'm going to try that.

I get the following msg from TB on primary computer for sbcglobal.net email. "The POP3 mail server (pop.att.yahoo.com) does not support UIDL or XTND XLST, which are required to implement the ``Leave on Server, ``Maximum Message Size or ``Fetch Headers Only options. To download your mail, turn off these options in the Server Settings for your mail server in the Account Settings window."' 5 seconds later I pull email for the same email addr and it goes through fine on my image copy BACKUP computer. This seems to discount the error as a mail server issue.

Seems to be a persistent problem with Yahoo POP accounts:

http://kb.mozillazine.org/Yahoo#The_POP3_email_server_.28plus.pop.mail.yahoo.com.29_does_not_support_UIDL_or_XTND_or_XLST

YaBut, my other 5 pop emails on the same computer are not generating the message at the same time as the failing email ....

Finally, someone else agrees with me! I have not had time to look a the source to see where Thunderbird stores the login credentials. For each of my recent occurrences (09/06, 10/24, 11/11, 11/15, and 12/03) I have created a dump via the Task Manager. I do not know enough about using Windbg to see if the credentials (if they are stored in memory. as I assume they are) have been corrupted. If someone with knowledge on this could tell me what Windbg commands to issue, I would gladly look at any or all of my dumps to look for possible credential corruption.

Two people suggested to me (privately) that maybe Thunderbird has persistent connection to the POP3 server. But I cannot believe that that is the case, as then the POP3 server would have a HUGE number of simultaneous connections active at any given time. And, if this were the case, why would Thunderbird be sending the credentials again (as I see in the bottom of the Thunderbird window when I click on "Get Messages").

Why is it so hard to accept yahoo is a failure at email? They are a failed company that even those that own them are writing off as a loss. Mention Yahoo in the bug reporting system and folks sagely shake their head and go not them again.

Why does failure automatically mean the mail client. It rarely is.

The anti virus on Windows is almost always sitting in the middle like a hacker, often actually offering itself to the mail client as the mail server. Using fake SSL certificates to implement man in the middle hacking on the connection and at other times acting as a mail proxy. Again a good way to break connectivity.

Then we have the products that push you into using their mail proxy/vpn. Talk about issues hidden under the hood. Avoid them like the plague unless you like troubleshooting.

So any diagnostic process must remove those sources of connection corruption from the equation. How you do that is your choice. But it has to be done. Personally I just get rid of the mail scanners, they are a waste of time anyway.

The next step is to get a log of the connection. It is simple to do, but only a customer of the provider can create one. https://wiki.mozilla.org/MailNews:Logging What that will not give you are your user name and password. But really they are not required. I would hope you actually know them.

You say the connection parameters get overwritten, but the truth is probably more like Thunderbird is lied to about what the server supports. A large part of any POP "conversation" is both sides speaking in commands the other understands. So the conversation early on uses the CAPA command where the server actually cites what it can and can not do. If Yahoo has a server that is not correctly configured (out of probably thousands) it may respond that is does not support commands required for certain functions. If you get that server this time, you might continue to get it every time. It depends on how their load balancing works.

That you receive a message that the server says, Thunderbird is just acting a a messenger. Something the program does not understand just occurs, here is the message. It has no idea what else to do with it.

Further information on how pop works here https://tools.ietf.org/html/rfc1939 https://tools.ietf.org/html/rfc2449

With the RFC's and the log you can establish exactly where things go wrong and tell us. Instead of just not accepting what you are told. You can be the authority.

There is one problem with looking at the RFCs and determining what is happening - the credentials connection between Thunderbird and the POP3 server is encrypted so the userid and password are not sent in clear text. I can see the packets via Wireshark, but I have no way to un-encrypt the packets to see what is being passed from Thunderbird to the POP3 server and vice-versa.

I am basing my opinion on Occam's Razor and my 50+ years of IT experience.

Assume the following timeline (which somewhat matches my experiences):

 1) I leave my computer at 5 PM Friday afternoon.
 2) I return to my computer at 9 PM Saturday night  I see:
    a) The Thunderbird UIDL message, and
    b) The last e-mail downloaded has timestamp 6 PM Friday.
 3) I click "Get Messages", and I see another UIDL message.
 4) At 9:10 PM Saturday I Exit Thunderbird and restart.
 5) Mail is downloaded; the next mail message has timestamp 6:30 PM Friday.

Sometime between 6 PM and 6:30 PM Friday the first UIDL message appeared. I do know what Thunderbird does after the message appears. Either

  a) Thunderbird continues to download messages every few minutes, and gets repeated UIDL errors, or
  b) Thunderbird gets the first UIDL error and then does not retry every few minutes.

Assume a). Then the Yahoo! POP3 server must have been down the entire time from 6 PM Friday to 9 PM Saturday. I cannot believe that a widely-used POP3 server would be down for that long period of time and then, mysteriously be repaired when, at 9:10PM I restart Thunderbird.

Now assume b). The Yahoo! POP3 server failed at 6 PM Friday and then was repaired. It then mysteriously was down at 9 PM Saturday when I tried a "Get Messages", and it mysteriously came back up at 9:10 PM Saturday after I restarted Thunderbird.

If this is a Yahoo! POP3 mail server problem, then the timeline is mysterious, as the server comes back to life at the same time as I restart Thunderbird, and not before. Are there any holes in my argument?

If you use Google, you will discover that this type of error has shown up in various email clients. eg: Outlook, Seamonkey, Thunderbird, Opera Mail, EG: https://help.smallbusiness.yahoo.net/s/question/0D51a00001vjNxsCAE/pop-mail-server-showing-errors-in-outlook-thunderbird-not-downloading-mails

The common denominators in all instances is Pop accounts and Yahoo server.

I was even sceptical that yahoo pull a fast one every once in a while just to clear down their pop servers.

Try this: Logon to webmail account, create a folder and move all previously downloaded emails from the Inbox into that newly created server folder. In Thunderbird try the Get Messages.

bsfinkel said

There is one problem with looking at the RFCs and determining what is happening - the credentials connection between Thunderbird and the POP3 server is encrypted so the userid and password are not sent in clear text.

As the userid and password are not relevent (there is no issue with connecting, only getting mail). I fail to understand what it is your are chasing in this.

I can see the packets via Wireshark, but I have no way to un-encrypt the packets to see what is being passed from Thunderbird to the POP3 server and vice-versa.

I gave you a link to a logging that will present the information in plain text. But you went off to wireshark. Great tool but you are a long way from having a need for it in this instance.

I am basing my opinion on Occam's Razor and my 50+ years of IT experience. Assume the following timeline (which somewhat matches my experiences): 1) I leave my computer at 5 PM Friday afternoon. 2) I return to my computer at 9 PM Saturday night I see: a) The Thunderbird UIDL message, and b) The last e-mail downloaded has timestamp 6 PM Friday. 3) I click "Get Messages", and I see another UIDL message. 4) At 9:10 PM Saturday I Exit Thunderbird and restart. 5) Mail is downloaded; the next mail message has timestamp 6:30 PM Friday. Sometime between 6 PM and 6:30 PM Friday the first UIDL message appeared. I do know what Thunderbird does after the message appears. Either a) Thunderbird continues to download messages every few minutes, and gets repeated UIDL errors, or b) Thunderbird gets the first UIDL error and then does not retry every few minutes.

I will go with B. the get of messages is not complete until you click the OK box, so that account would not be checked.

Now assume b). The Yahoo! POP3 server failed at 6 PM Friday and then was repaired. It then mysteriously was down at 9 PM Saturday when I tried a "Get Messages", and it mysteriously came back up at 9:10 PM Saturday after I restarted Thunderbird.

Now assume you were finally allocated a different server in the cluster when you restarted thunderbird. A connection to a yahoo pop server is not a one to one connection. There are probably multiple clusters of servers that yahoo load balancing routes requests to POP servers to.

If this is a Yahoo! POP3 mail server problem, then the timeline is mysterious, as the server comes back to life at the same time as I restart Thunderbird, and not before. Are there any holes in my argument?

I think I poked more than one.

But I will suggest other issues that could be involved, power saving and sleep on windows. The way The operating system saves power, the setting you use and the use of sleep and hibernate on windows can produce some truly odd actions. Especially if Thunderbird makes a request to the server, the anti virus works out the network is down (Power saving) so it replied something silly so thunderbird gives you something equally silly in response.

Note I also gave you a number of steps that had to be in place before any diagnostic on logging should be undertaken. But you persevere with the very difficult to impossible and post your theories here without anything more than supposition to support them. undertake some logging, see what Thunderbird is sending and exactly when and why the error message appears. Then there will be something meaningful to talk about.

I have been dealing with computers and user support since the mid 1980s I might not have your 50 years, but I am not wet behind the ears.. In that time have spent more than a reasonable amount of time talking about issues with folks with strong opinions and no basis for them but supposition. I consider this another of those occasions lots of discussion, but still no facts. Produce the log showing the issue..

I've had this same problem for a couple of years now, and it's clear to me that there's a bug in TB that should be addressed. Maybe Yahoo sometimes does something to trigger that bug, but the problem persists when Yahoo's servers are working just fine. The following facts lead me to conclude that there's a bug in TB and not just in Yahoo:

I have identical versions of TB, identically configured, running on two different computers. I have several email addresses, and both copies of TB regularly try to download email from all my email addresses, and all from the same server, namely inbound.att.net. Sometimes TB will stop downloading email from one address on one computer, but TB will continue downloading email from that same address on the other computer, and email from all other addresses continues to download on both computers. This problem crops up on both computers and for all email addresses, and it's pretty random except for the fact that addresses that get checked more regularly are also more likely to fail.

To deal with this problem, I regularly exit TB and then start TB up again. It's annoying but effective. And from the foregoing conversation it looks like I will continue going through this routine for some time, as the folks at TB insist on blaming only Yahoo.

If the good people at TB won't take ownership or part ownership of this specific problem, then there are still things that those folks can do that would be helpful. For example, I find it surprising that TB doesn't ever notify me if it is repeatedly unable to access an account which I've told it to check regularly. Maybe there's a switch somewhere that would cause TB to notify me, but I haven't been able to find it, and if there isn't one it would be a nice feature to add. As it is, I don't know there's a problem with an address until I get email at that address on one of my computers and not the other, or unless I click on "Get Messages."

I do not know how many times I have to say that inbound.att.net is a cluster of yahoo servers, not a single server. So if one of the 10 or 100 or whatever makes up the cluster has a bad config then you get random odd responses.

About the first things that happens when a mail client connects to a mail server is it asks the server for it's capabilities. Based on the response the mail client talks to the sever. What you are seeing is the digital equivalent of you saying to speak russian and then barfing when you are told Прощай

Just to be clear, setting connection times more frequently that 10 minutes is almost guaranteed to fail due to the latency involved in getting mail. I find some folks think settings like 2 minutes should work. They will not unless the server you connecting to it in the same room with a fibre connection between the two devices.

Is there at least a way to get TB to notify me automatically when it runs into a problem with a particular address? If not, I and people like me will have to constantly ask TB if it's still working OK.