I saw a UIDL error in Thunderbird. The last message received had timestamp 02/21 06:07PM ==> 02/22 00:07 UTC. copy pop3.log pop3.200221.log grep "2020-02-22 00:" pop3.log > pop3.200222-00.log

02/22/2020 11:26 PM 1,785,927 pop3.200222-00.log

Line 11471: 2020-02-22 00:26:09.149000 UTC - ... ERROR: pop3ServerDoesNotSupport UidlEtc

grep ERROR pop3.log > pop3.200222-error.log

02/22/2020 11:42 PM 26,227 pop3.200222-error.log

Here are dropbox links to the two excerpted log files:

https://www.dropbox.com/s/xm3kmi6qvgdtxr7/pop3.200222-error.log?dl=0 https://www.dropbox.com/s/zjjt39auk98pf6z/pop3.200222-00.log?dl=0

Here is a continuation of the steps I took after creating the pop3.200222-error.log file:

Extract the data from the "00" .log (columns 86-end). cut -c86- pop3.200022-00.log > pop3.200022-00.data.log

Thunderbird checks for new mail every 10 minutes. It checked at 00:04.

Add "[00:_4]" to the "LoadUrl()" line at the start of each 10-minute segment as an identifier.

Extract the 10-minute segments of the data.log into pop3._4 files,

C:\Users\BARRYF~1\Desktop>dir pop3.?4

Volume in drive C is Win7-BOOT
Volume Serial Number is 8CC2-2BB1

Directory of C:\Users\BARRYF~1\Desktop

02/25/2020 03:47 PM 170,903 POP3.04 02/25/2020 03:48 PM 156,336 POP3.14 02/25/2020 03:49 PM 28,848 POP3.24 02/25/2020 03:50 PM 28,561 POP3.34 02/25/2020 03:50 PM 28,561 POP3.44 02/25/2020 03:51 PM 28,636 POP3.54

              6 File(s)        441,845 bytes
              0 Dir(s)  12,313,980,928 bytes free

In the 00:04 and 00:14 segments, mail was downloaded, so those segment logs contain more lines than the 24, 34, 44, and 54 segments.

C:\Users\BARRYF~1\Desktop>diff pop3.24 pop3.34 1c1 < LoadUrl() [00:24] --- > LoadUrl() [00:34] 45c45 < POP auth: server caps 0x221CB2, pref 0x1C00, failed 0x0, avail caps 0x1C00 --- > POP auth: server caps 0x221C82, pref 0x1C00, failed 0x0, avail caps 0x1C00 76c76 < C9D0] BeginMailDelivery acquiring semaphore --- > AB80] BeginMailDelivery acquiring semaphore 1495,1505d1494 < SEND: UIDL < Entering NET_ProcessPop3 56 < Entering state: 3 < RECV: -ERR [SYS/TEMP] Server error - Please try again later. < Entering state: 12 < Entering state: 13 < SEND: XTND XLST Message-Id < Entering NET_ProcessPop3 23 < Entering state: 3 < RECV: -ERR Invalid Command. < Entering state: 14 1508,1509c1497,1498 < C9D0] Calling ReleaseFolderLock from AbortMailDelivery < C9D0] ReleaseFolderLock haveSemaphore = TRUE --- > AB80] Calling ReleaseFolderLock from AbortMailDelivery > AB80] ReleaseFolderLock haveSemaphore = TRUE 1515,1516c1504,1505 < C9D0] Calling ReleaseFolderLock from ~nsPop3Sink < C9D0] ReleaseFolderLock haveSemaphore = FALSE --- > AB80] Calling ReleaseFolderLock from ~nsPop3Sink > AB80] ReleaseFolderLock haveSemaphore = FALSE

C:\Users\BARRYF~1\Desktop>diff pop3.34 pop3.44 1c1 < LoadUrl() [00:34] --- > LoadUrl() [00:44] 76c76 < AB80] BeginMailDelivery acquiring semaphore --- > C550] BeginMailDelivery acquiring semaphore 1497,1498c1497,1498 < AB80] Calling ReleaseFolderLock from AbortMailDelivery < AB80] ReleaseFolderLock haveSemaphore = TRUE --- > C550] Calling ReleaseFolderLock from AbortMailDelivery > C550] ReleaseFolderLock haveSemaphore = TRUE 1504,1505c1504,1505 < AB80] Calling ReleaseFolderLock from ~nsPop3Sink < AB80] ReleaseFolderLock haveSemaphore = FALSE --- > C550] Calling ReleaseFolderLock from ~nsPop3Sink > C550] ReleaseFolderLock haveSemaphore = FALSE

C:\Users\BARRYF~1\Desktop>diff pop3.44 pop3.54 1c1 < LoadUrl() [00:44] --- > LoadUrl() [00:54] 74c74 < RECV: +OK 705 57605909 --- > RECV: +OK 707 57796295 76c76 < C550] BeginMailDelivery acquiring semaphore --- > C0D0] BeginMailDelivery acquiring semaphore 79c79 < Entering NET_ProcessPop3 7679 --- > Entering NET_ProcessPop3 7702 81c81 < RECV: +OK 705 message(s) (57605909 octets). --- > RECV: +OK 707 message(s) (57796295 octets). 1492a1493,1496 > RECV: 706 152126 > Entering state: 10 > RECV: 707 38260 > Entering state: 10 1497,1498c1501,1502 < C550] Calling ReleaseFolderLock from AbortMailDelivery < C550] ReleaseFolderLock haveSemaphore = TRUE --- > C0D0] Calling ReleaseFolderLock from AbortMailDelivery > C0D0] ReleaseFolderLock haveSemaphore = TRUE 1504,1505c1508,1509 < C550] Calling ReleaseFolderLock from ~nsPop3Sink < C550] ReleaseFolderLock haveSemaphore = FALSE --- > C0D0] Calling ReleaseFolderLock from ~nsPop3Sink > C0D0] ReleaseFolderLock haveSemaphore = FALSE

C:\Users\BARRYF~1\Desktop>

In the .24 segment, the error message appears at 00:26

   00:24 SEND: UIDL
   00:24 Entering NET_ProcessPop3 56
   00:24 Entering state: 3
   00:26 RECV: -ERR [SYS/TEMP] Server error - Please try again later.
   00:26 Entering state: 12
   00:26 Entering state: 13
   00:26 SEND: XTND XLST Message-Id
   00:26 Entering NET_ProcessPop3 23
   00:26 Entering state: 3
   00:26 RECV: -ERR Invalid Command.
   00:26 Entering state: 14

This is the difference between the .24 and .34 segments. There is no real difference between the .34, .44, and 54 segments except for the number of messages returned by the POP3 server.

I have not looked at the POP3 RFCs, and I have not looked at the source code. Here is what I conjecture:

o There is one generic error message from the server in response to a UIDL command. I am not sure that the error message is related specifically to that command.

o In the next attempt to contact the server, there is no difference except for the error message block; contacting the server seems to have occurred OK, without error.

o Did Thunderbird save the information that there was an error and subsequently not clear that information, so the next attempt 10 minutes later result in an "assumed" failure? That is my conjecture after looking at the UIDL trace log in detail.

I have looked at RFC 1939 and the some of the Thunderbird source code, but not in detail. From the UIDL trace log, the inbound mail server has this response to a UIDL command:

     RECV: -ERR [SYS/TEMP] Server error - Please try again later.

I do not know if this message is found in any of the follow-on POP3 RFCs. I interpret this message as a generic temporary error because it says, "Try again later". As I wrote previously, I am not sure that this server reply is related specifically to the POP3 UIDL command just sent; it could be that any POP3 command sent at that time to the server would have gotten that response.

I conclude that this response means that the server had some sort of temporary error, and it wants the sender to re-send the command later. It appears that Thunderbird is treating this error return code from its sent UIDL command as a permanent error, and thus produces the error message seen by the end-user:

    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.

Thunderbird believes that the server does not support the UIDL command, when in actuality the server only had a temporary problem. When Thunderbird believes that the server does not accept the UIDL command, no further mail will be downloaded. Of course, when Thunderbird is re-started, the subsequent UIDL command will not experience the temporary error, and inbound mail will again be downloaded. This is exactly what I and others have observed in Thunderbird.

Thanks, bsfinkel. If I understand you correctly you're saying that, if Thunderbird gets the temporary error message when checking for email on an account, then Thunderbird cannot be made to check that account for email ever again without a restart. So when I click on "Get Messages" Thunderbird automatically gives me the POP3/UIDL error message without noticing that the temporary problem is gone, and perhaps without even attempting to connect to the server. That explanation makes a lot of sense to me and is completely consistent with my experience working with multiple email accounts in identically configured copies of Thunderbird running on different computers.

Your explanation makes a lot more sense to me than the only other explanation I've seen -- namely, that Yahoo maintains one or more permanently misbehaving servers and that somehow one (and only one) of my accounts spontaneously gets locked in to one of those bad servers, but only when accessed from one of my computers and only after working fine for several days. To me that explanation sounds like nothing more than a contrived and convoluted attempt to blame Yahoo for the problem. It seems to me that, to the contrary, there's a problem with Thunderbird's error handling that needs to be addressed.

Norman, you are partially correct. From the trace I see that Thunderbirde is contacting the server periodically (in my case, every 10 minutes), but when it does, it never sends the POP3 UIDL command to the server b ecause it has remembered that the lastUIDL command did not get a non-zero return code.

The Simple Mail Transport Protocol (SMTP) - RFCs 2321 (and its clarifying RFC 5321) define various levels of response messages; 1xy, 2xx, and 3xy are informational messages, while 4xy are temporary (retryable) messages, and 5xy are permanent error messages. I believe that the POP3 RFCs do not define severity levels for error messages, so the temporary ERR message returned by inbound.att.net has to be parsed by Thunderbird to determine that the error is NOT a fatal error. As I wrote before, I have not read the POP3 RFCs in detail.

The error message from Thunderbird states that the server does not understand the POP3 UIDL command, when it is clear that it does.

I wrote my first program over 50 years ago (it never worked), but in my many years of IT and programming, I know that the scenario put forth by the Thunderbird support personnel who respond to his forum did not pass the Occam Razor test.

I had another occurrence yesterday (03/02) that was similar, but different. Here is what I did:

I had another occurrence of Thunderbird UIDL error on 03/02/2020.

The last piece of mail recdeived had timestamp 1:11PM.

     1:11PM = 13:11 = 19:11 UTC

After I restarted Thunderbird, the next piece of mail had timestamp 1:44.

     1:44PM = 13:44 = 19:44 UTC

copy pop3.log pop3.200302.log

pop3.200302.log

   First entry - 2020-02-24 16:08:44.801000 UTC
   Last  entry - 2020-03-02 21:38:30.398000 UTC

grep "2020-03-02 19:" pop3.200302.log > pop3.200302.19xx.log grep "2020-03-02 20:" pop3.200302.log > pop3.200302.2wc -g

wc -l pop3.200302.??xx.log

    27483 pop3.200302.19xx.log
     8350 pop3.200302.20xx.log

Via an editor extract relevant error lines from the two xx log files. Save as pop3.200302.piece.log .

cut -c69- pop3.200302.piece.log > pop3.200302.piece69

C:\Users\BARRYF~1\Desktop> type pop3.200302.piece69 SMTP Send: QUIT SMTP entering state: 0 SMTP entering state: 0 SMTP Response: 221 Service Closing transmission SMTP entering state: 10 SMTP entering state: 12 SMTP connection error quitting 804b0002, ignoring [this=1A058C10] Entering NET_ProcessPop3 56 [this=1A058C10] Entering state: 3 [this=1A058C10] RECV: -ERR [SYS/TEMP] Server error - Please try again later. [this=1A058C10] Entering state: 12 [this=1A058C10] Entering state: 13 [this=1A058C10] SEND: XTND XLST Message-Id [this=1A058C10] Entering NET_ProcessPop3 23 [this=1A058C10] Entering state: 3 [this=1A058C10] RECV: -ERR Invalid Command. [this=1A058C10] Entering state: 14 [this=1A058C10] ERROR: pop3ServerDoesNotSupportUidlEtc [this=1A058C10] Entering state: 24 sink: [this=2667F160] Calling ReleaseFolderLock from AbortMailDelivery sink: [this=2667F160] ReleaseFolderLock haveSemaphore = TRUE [this=1A058C10] Entering state: 25 [this=1A058C10] Clearing server busy in POP3_FREE [this=1A058C10] Clearing running protocol in POP3_FREE [this=1A058C10] Clearing server busy in nsPop3Protocol::OnStopRequest [this=1A058C10] ~nsPop3Protocol() sink: [this=2667F160] Calling ReleaseFolderLock from ~nsPop3Sink sink: [this=2667F160] ReleaseFolderLock haveSemaphore = FALSE ... [this=143B4D60] RECV: . [this=143B4D60] Entering state: 11 [this=143B4D60] ERROR: pop3ServerDoesNotSupportUidlEtc [this=143B4D60] Entering state: 24 sink: [this=1AEDF8B0] Calling ReleaseFolderLock from AbortMailDelivery sink: [this=1AEDF8B0] ReleaseFolderLock haveSemaphore = TRUE [this=143B4D60] Entering state: 25 [this=143B4D60] Clearing server busy in POP3_FREE [this=143B4D60] Clearing running protocol in POP3_FREE [this=143B4D60] Clearing server busy in nsPop3Protocol::OnStopRequest

C:\Users\BARRYF~1\Desktop>

In this case, at 19:58:28 Thunderbird sent a UIDL command. At 19:59:15 I sent a piece of mail to outbound.att.net. At 19:59:17 Thunderbird sent the SMTP QUIT command, and the connection closed. At 19:59:14 the inbound.att.net server sent:

    RECV: -ERR [SYS/TEMP] Server error - Please try again later.

in response to the UIDL command sent 46 seconds earlier. I have no idea what the temporary error was. Then Thunderbird send an "XTND XLST" command to the server, and the server replied

    RECV: -ERR Invalid Command.

This is, essentially the same scenario as the one I posted earlier, except there is an outbound mail transmission in the log between the UIDL command and the error response from the server. The XTND XLST command after the UIDL command gets an error response, probably because the UIDL command did not get a good response code.

Note that I am also tracing SMTP in this log for a content-filtering problem with the outbound.att.net server; I am working with at&t on that problem.