Some e-mails stop being received halfway through in Thunderbird.
Receiving stops in the middle.
This event is difficult to explain.
Suppose 1,000 e-mails are delivered to a certain e-mail account.
Of these, 995 will arrive normally, but trouble will occur in relation to 5 of them.
In terms of probability, this is 0.5%, or 1 out of every 200 e-mails.
In the example below, 1000 e-mails are in the process of being received, and up to a certain stage, the system works normally and e-mails are stored in the inbox.
However, if the system stops after a certain number of e-mails and is left unattended, the system will finish receiving e-mails, but not all of them will have been received.
When it looks as if receiving is finished and you try to get additional information by pressing the “Receive” button because it is not finished yet, you will see the following message: “Account xxx@xxx is being processed. Please wait a moment while we finish receiving your message. Please wait a moment until the receiving process is finished.
What happens after this is that nothing changes until you close Thunderbird.
So-called force close is required.
Received but no record of receipt
Restarting Thunderbird in the aforementioned state is completely useless.
When I press the receive button, the receiving process starts, but I get stuck with the same message.
Since up to a certain number of emails have already been received, the process stops at the first remaining email.
However, at the time of this restart, the email in question is in the inbox.
In other words, the message has been received in the Thunderbird Inbox as a result of the previous reception process, but the reception is not yet complete.
Same message goes bad.
So I started over from the beginning.
I opened “popstate.dat” from the folder containing the Thunderbird files and deleted all the data recorded in it.
I also deleted the header “POP3 State File” and “This is a generated file! Do not edit.
This will signal to Thunderbird when it communicates with the mail server that no more mail has been received, so it will start receiving all the mail on the server.
In this case, we have 1,000 messages, so we start receiving 1,000 messages.
Then it gets stuck at the same message again.
The location of “popstate.dat” is listed at the bottom of the “Server Settings” tab in the Thunderbird account settings.
By default, it is located in the back of the C drive, but I have set up a folder for receiving messages in the D drive, so it is located as shown in the figure below.
Lying on popstate.dat
I am not lying, but I wrote that I have received the message on my own, not Thunderbird.
In the example below, the inbox has a message “X-UIDL” with “UID12493”, but the last received message in the “popstate.dat” file is “UID13492” with one less number.
So I added one line under “UID13492” and wrote “UID13493”.
The “UID” is a unique identifier, a symbol that is assigned to each message stored on the mail server.
To check the UID of an incoming message in Thunderbird, select “Header” from “View” in the menu bar and choose “All” from the options to display it with the message.
If you set the header display to “All”, the header will be displayed in the quoted text even when replying to an e-mail, so it is recommended to set it to “Normal”.
Writing “popstate.dat” is a foolproof workaround
The “popstate.dat” with one line added manually, but when I started Thunderbird in that state and tried to receive the message, it worked.
I don’t know why that one line would get stuck, but I was able to work around the problem by pretending that the mail causing the stack had already been received (it actually had).
Small Failures
I had multiple failures to get to this point, so there were multiple identical messages in my inbox.
Since they all have the same unique ID (UID) on the mail server, adding one line in “popstate.dat” would have handled the problem, but in the Thunderbird local story, there were multiple identical messages. However, in the local Thunderbird story, multiple identical messages exist.
One thing we can confirm here is that the mail that enters the inbox is immediately filtered and moved to a separate folder called “Dammy”, but this is not done and remains in the inbox folder.
In other words, it is stuck before the filter process.
The message itself is normal.
This time, all 1,000 messages are from the same source, and the text is approximately the same.
The source and destination addresses are the same, although there is no reply address because the messages were sent from a software program that I created myself under an appropriate name as a virtual person.
In other words, it is 1,000 messages addressed to yourself, created by you.
There is no feature in the messages to be stacked. It is very similar to other messages.
If you assume that you have received the message, there is no error in displaying it in Thunderbird.
Webmail is normal
I have no problems at all with webmail, where I can check messages from my browser.
No problem with all 1,000 messages.
No problem with 3,000 messages.
POP3 is also normal
I received the same mail via POP3 on another system, and it doesn’t matter whether I receive 1,000 or 3,000 mails there as well.
Messages that stack are reproducible.
With the message still on the mail server, I emptied Thunderbird’s “popstate.dat” and tried to receive the message in Thunderbird again.
Then, the message that I had a problem with earlier was caught again.
I opened “popstate.dat” and found that the UID was still not recorded.
reproducibility, even in the case of an unorthodox strategy
The mother-in-law remedy worked on another message as well.
In the previous message, the message was “UID12493,” but in the example below, there is a message “UID13330” in the inbox.
And the last received message in the “popstate.dat” file is “UID13329” with one less number.
So I added one line under “UID13329” and wrote “UID13330”.
When I receive a message with this, it works.
Same with different reception speeds.
Thunderbird writes the UID to “popstate.dat” each time it receives a message.
I thought that if there was some problem in the processing executed for each message, and if the problem was related to the writing speed, I tried to slow down the communication speed.
Since I reduced the speed from 100 Mbps to 200 kbps, which is 1/500th of the speed of an optical line, the time required for reception was considerably extended.
However, the stuck point was the same.
I cannot be certain, but I think there is a different problem to begin with, rather than a write error to “popstate.dat”.
Same for timeout setting changes.
Select “Settings” from the “Tools” menu in Thunderbird and go to the bottom of the “General” tab to find the “Settings Editor… (C)”.
Open it and enter “mailnews.tcptimeout” to set the timeout time.
I tried to change this, but there was no change in particular.
I don’t really know what tcptimeout is, so I returned it to the standard setting.
Same with Update.
The latest version at this time was Version 102.2.2.
This version is applicable to 64-bit versions of Windows 7 or later, so it is appropriate for the environment in which it is used.
Reinstalled and same thing.
In the past, when there was a problem with Thunderbird, it was because the author had installed a 32-bit version of Thunderbird on a 64-bit Windows 10.
At that time, the problem was solved by replacing it.
So this time, I uninstalled the 64-bit version and installed the 64-bit version again.
I also deleted the following folders before reinstalling.
[C:\Users\****\AppData\Roaming\Thunderbird]
As a result, nothing changed.
What we have learned so far
To lay out the facts, there are 1,000 e-mails on the mail server, and when viewing them via webmail, one can read all of them from the first one to the 1,000th one.
Furthermore, if you receive mail via a POP3 connection to your local computer on a different system, you can receive the first to the 1,000th message without delay.
As far as Thunderbird is concerned, there is a chance of about 5 out of every 1,000 e-mails getting stuck while being received.
It seems that the mail is not received, but when I restart Thunderbird, I find that the mail has been delivered to my Inbox.
The email is readable. It is not corrupted.
The UID of the email is not recorded in “popstate.dat”, so the email is reported as not received from Thunderbird to the mail server.
When I try again with the message not received, it gets stuck again.
However, if I write the UID of the stuck message in “popstate.dat” and mark the message as received, the subsequent messages can be received smoothly.
However, if the problematic message is encountered again, the same thing will happen again.
Once 1,000 messages have been received by this tactic, all of them can be treated as normal messages (e-mails) so that it is impossible to tell which message is the stuck one.
Perhaps there is some problem in writing to “popstate.dat” that it has received the message.
I don’t know what caused it, nor do I know how to solve it.
Half resolved, then unresolved.
This time, we have solved the problem of receiving e-mails for the time being by mother-in-law’s means.
However, since we have not yet reached a fundamental solution, the problem can recur at any time. In fact, it is recurring.
We will let you know when we find a solution.
Thank you for reading to the end.
