POP3-based accounts download email headers successfully, but unable to access email contents
I have been using Mozilla Thunderbird since 2003 as my email desktop client.
As of Sunday morning, May 17th, I noticed the following:
- All of my WideOpenWest email accounts (mine, my wife's my son's) downloaded email headers successfully, but did not allow me to see email contents, move email to other folders or delete obvious junk mail via the client interface.
- All of my Archive email suddenly also will display the expected email headers, but content is unavailable through the client interface.
- All my IMAP email access and management behavior works as expected.
- If I copy an email from one IMAP account to the other, all is fine, but if I move that copied email to an Archive folder, its contents become unavailable (the email I copied was the "Mozilla Confirm your account ..." email)
Inspecting the filesystem containing the client data (NAS-based SMB share, using SSH to access NAS filesystem), I can see:
- The Archive folder has both the Filed and Filed.msf files updated with a timestamp consistent with the copy.
- The email contents are available in a format unfamiliar to me, but I can read the contents and show the same below:
<(B2=Mozilla <accounts@firefox.com>)(B3=<Ellided>@<Ellided>.com)(B4
=Confirm your account)(B5 =01010196ef885d03-c0d0edd7-b446-43b6-8bc5-8d5eee591202-000000@us-west-2.am\
azonses.com)(84=)(B8=620d)(B9=277)(BA=19204|Mozilla <accounts@firefox.com>)
(BB=plugin)(BC=14)(BD =Open the internet with Mozilla Confirm your account and get the most out \
of Mozilla everywhere you sign in starting with: Firefox on Windows 10 Tuesday\ , May 20, 2025 5:10:13 PM (EDT\) Use this confirmation code: <Ellided> It expires\
in 5 minute)(BE=6176)(BF=nonjunk)(C0=ffffffff)>
- The 'Filed' file contents also seem to be valid and viable. I can provide both if that's helpful.
I checked the underlying file system permissions and the email file attributes (owner, group, access) are all as they should be -- the above copy test results would suggest no problem there.
What are the next diagnostic steps?
Thanks in advance for the help,
AJ
Vybrané riešenie
I appreciate the input @sfhowes :)
I checked this morning and found I am running 128.10.2 -- also found that the issue is fixed :)
All of the accounts (and Archive) are located on an NFS/SMB mount specified as a UNC path. It's interesting that only the POP3 accounts were impacted, not the IMAP accounts.
Do you have knowledge of whether the behavior I described was introduced in a recent update?
Čítať túto odpoveď v kontexte 👍 0Všetky odpovede (3)
Are the Archive folders located on a network drive (UNC path)? If so, update to 128.10.2 or 138.0.2 which fix such folders appearing blank.
Vybrané riešenie
I appreciate the input @sfhowes :)
I checked this morning and found I am running 128.10.2 -- also found that the issue is fixed :)
All of the accounts (and Archive) are located on an NFS/SMB mount specified as a UNC path. It's interesting that only the POP3 accounts were impacted, not the IMAP accounts.
Do you have knowledge of whether the behavior I described was introduced in a recent update?
The error was introduced in the 128.10.1 point release, fixed in the .2 release.
Ak chcete odpovedať na príspevky, musíte sa prihlásiť do svojho účtu. Ak ešte nemáte účet, položte novú otázku.