Getting this message - The POP3 mailserver(inbound.att.net) does not support UIDL or XTND XLST
This is a continuation of a thread with the same title that was closed over a year ago. I do not accept the answer therein - "there is a problem with the POP3 mail server.". If there were a problem with the mail server, then an Exit and restart of Thunderbird would NOT work, as Thunderbird would be passing the same (bad) parameters to the mail server. In fact, every time I have experienced this error, an Exit and restart of Thunderbird has corrected the problem.
I believe that what is happening is that the POP3 connection parameters within Thunderbird are getting corrupted, maybe overlaid. I have no way of proving this, as 1) the connection to the POP3 server is encrypted so a Wireshark trace would not tell me anything, and 2) I do not know the internals of Thunderbird. I had an occurrence last week, and what I did was to take a dump via the Task Manager. Maybe someone with knowledge of Thunderbird internal;s can look at the dump and see if the connection parameters are still intact. Or tell me what windbg commands to run against the dump.
I am running 60.9.0 on Windows 7 Professional, 32-bit. Thanks.
Дополнительные сведения о системе
- User Agent: Mozilla/5.0 (Windows NT 6.1; rv:69.0) Gecko/20100101 Firefox/69.0
By all accounts, this seems to only happen with Yahoo-type mail servers, which includes ATT, Verizon, Rogers, BT etc.
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.