The timestamp in popstate.dat relates to the 'From' located at the top of the email received (as seen in mbox file) - it's the first item at start of email and not the Date timestamp when email was created as seen in the 'Date column header'.

I'm on a Windows OS, but the timestamp relates to epoch clock. https://www.epochconverter.com/

Using the link above to test/convert it says: Assuming that this timestamp is in seconds: GMT: Saturday, 11 January 2025 16:47:49 Your time zone: Saturday, 11 January 2025 16:47:49 GMT+00:00

so epoch timestamp located in popstate.dat = 1736614069 = From - Sat Jan 11 16:47:49 2025

In mbox file - I located email Top first line says: From - Sat Jan 11 16:47:49 2025 In same email further down in headers- Date: Sat, 11 Jan 2025 16:47:22 +0000

I created and sent this email so the date I created and sent was merely a few seconds (25) different from when it was received and downloaded. That difference is shown when I compare 'From' date and 'Date' in header. But the epoch timestamp only uses the 'FROM' date and not the 'Date' in headers.

This is my findings using a Windows OS and a Thunderbird installation downloaded from the official website : https://www.thunderbird.net/en-US/thunderbird/all/

I've had a thought....maybe the account setup in eg: Windows OS is not completely identical to setup in Linux.

I found one user had this issue: eg: different account name/username being logged - The account/username name started with uppercase in Windows whereas it always started with lowercase letter in Linux.

Another user had popstate.dat file corruption and needed to delete it and force a new one to be created.

Added this link as it has good info and you never know who reads the question: http://kb.mozillazine.org/Sharing_a_profile_between_Windows_and_Linux

Hi Toad-Hall,

thanks for the explanations about the timestamp. I guess it makes sense for Thunderbird to store the time of retrieval so it can delete the mail from the server after the configured 7 days of retention are over. Someone should fix this knowledge base article though, as it is flat out lying by claiming that the message source has anything to do with it.

And it still doesn't explain why the emails get downloaded again. My popstate.dat isn't corrupted. I ran several tests, deleting it every time and starting fresh. About the different name/username being logged, I don't get it. popstate.dat isn't logging those, so how could that be the issue?

I tried the following: - Made two identical copies of the entire TB directory structure. - On the first copy, started the Windows client -> duplicates get downloaded. - Copied popstate.dat from first to second copy. - Started Windows client on the second copy -> nothing gets downloaded.

This proves that popstate.dat is the only source of the problem, and the only difference in the popstate.dat files are the timestamps. So why does an old timestamp make the Windows client think it has to download the messages again, although identical messages with the same UIDL are located in its Inbox? This smells like a bug to me.