Closed Bug 1887070 Opened 7 months ago Closed 6 months ago

POP3 Mailbox Indexes Are Corrupted Daily, Duplicate Messages Created

Categories

(Thunderbird :: Untriaged, defect)

Product:
Thunderbird
Component:
Untriaged
Version:
Thunderbird 115
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 1883760

People

(Reporter: vmikhelson, Unassigned)

References

Details

Attachments

(1 file)

Debug Log -- second attempt
54.04 KB, text/plain
Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.4 Safari/605.1.15

Steps to reproduce:

Mail is set to be fetched from a POP3 account automatically. More often than not I see mail being left on the POP server. If I try to force mail retrieval it would fail typically on a single digit message, e.g. 6 out of 2,584. Duplicate message search would reveal duplicates in the target folders (after rules were applied). Sometimes the duplicates are observed in the Inbox. I end up removing duplicate dates and rebuilding i indexes in all subfolders with new messages which would help for a couple days, and then the problem starts all over again.

Actual results:

POP3 mail fails to be fetched

Expected results:

POP3 should be delivered.

6 out of 2,584

Do you actually have that many new message to download? Or maybe you are setting a new account in TB?
Or do you keep a lot of messages on the POP3 server? Or do you let them be deleted after they are downloaded?

You might try the latest beta. It has a fix in it for POP3 that is helpful when you have a lot of messages left on the server.. Re Bug 1875633.
Archive site for beta 125.0b1: https://archive.mozilla.org/pub/thunderbird/releases/125.0b1/
If you don't have a lot on messages kept on the POP3 server, this probably won't help. (I'm not referring to how many messages are in your Inbox or other folders that are locally stored.)

There has also been reports of POP3 hanging or stopping, maybe like you describe. A "try" build based on TB daily build is here. You can might want to run this and see if it helps:
https://bugzilla.mozilla.org/show_bug.cgi?id=1847137#c52
It's for windows but it looks like you are on a mac and I didn't make the build for mac. Let me know if you want me to update the build and include mac.

If these don't help, need more details such as how many messages you keep on the POP3 server, if the pop3 server(s) is AOL as in you address, how many pop3 accounts do you have, do you have them set up to check for new mail all at the same time, how often is new mail checked, or any other factors you think may be relevant.

Gene,

Yes, this is a high volume account. It receives e-mail notifications from about a hundred or more devices I monitor.

2,584 was an average 6-hour workload. It can go up to 10,000 in case of an attack.

The problem is in how ThunderBird processes the POP downloads:

1. Download a message
2. Apply filters
3. Repeat for all messages reported by the POP server
4. Delete all messages at once after successful download of the whole batch

The last item is the most critical, but most likely it is per RFC. I did not verify. If a message was deleted upon fetching by the client it would have helped.

If all messages were downloaded at once and then filters were applied, it would have allowed for a smother ride as well.
I do experience hangups and occasional crashes which I submitted details for through the automated crash reporting.

The mail account was moved from under-powered Windows 10 virtual machine to a powerful physical iMac Pro running Sonoma.

I do not keep any messages on the server. The POP server is running Mercury 1.48 on NetWare, it is in my full control.

I am down to one (1) POP account. I dropped the fetch interval from 10 minutes default to 3 minutes to minimize the number of messages on the server, and it seems to be optimal.

I do see the ThunderBird's threading does not utilize other cores. If it hangs, it is just one core which is overburdened.

I am using a third-party tool for removing duplicates, and sometimes the ThunderBird would crash at the time of the removal process. My settings are remove permanently vs. moving to trash.

Please let me know what else you would like me to clarify.

Thank you,
Vladimir

Gene,

Interestingly, I have not experienced the corruption issue over the weekend. So we should assume that the issue became intermittent.

My current version is 115.9.0 (64-bit).

I will update the notes when the problem shows up again.

Thank you,
Vladimir

Gene,

The issue is back. It is stuck on 4 out of 1,242.

If I remove first 4 messages from the queue on the server it still stalls on #4.

Do you want me to send you some files for analysis?

Thank you,
Vladimir

Gene,

At the time of occurrence the clients sits for a while on "Downloading message 1 of 1..." or "Host contacted, sending login information..."

Just in case it helps.

Thank you,
Vladimir

Gene,

I have cleared the queue. This time the duplicates were present in the target folders, nit in the Inbox folder.

Two messages I needed to remove from the queue as they would never fetch and stall the client if they were present in the queue.

Thank you,
Vladimir

Gene,

The ultimate remedy was to read the ThunderBird after which everything cleared.

It looks like the software defect is only present in the Mac build. Windows does not seem to have it.

Let me clarify. On Windows duplicate records can be created under certain circumstances, but fetching would never stall, which makes a huge difference.

I will concentrate on creating a cron job to restart the ThunderBird once a day or so as I do not see a lot of activity on this ticket.

Thank you,
Vladimir

(In reply to Vladimir from comment #7)

Gene,

The ultimate remedy was to reload the ThunderBird after which everything cleared.

It looks like the software defect is only present in the Mac build. Windows does not seem to have it.

Let me clarify. On Windows duplicate records can be created under certain circumstances, but fetching would never stall, which makes a huge difference.

I will concentrate on creating a cron job to restart the ThunderBird once a day or so as I do not see a lot of activity on this ticket.

Thank you,
Vladimir

Vladimir,
Sorry for the delay in answering, been working on other bugs.
(Actually, I was writing this and was about to send it when your comment 7 and comment 8 came in. So you now think its is Mac specific problem?)
When you refer to the "queue" and/or "clear the queue" I assume that is something you are doing on the Mercury server? Is "Mercury" server the Pegasus mail server? Someone else recently reported a problem with Mercury but with imap, but it was a TB bug actually that I fixed.

How exactly is your (single?) POP3 account set up?

[] Check for new messages at startup
[] Check for new messages every 3 minutes (as you said above)
[] Automatically download new messages
[] Fetch headers only
[] Leave messages on server
    [] For at most X days
    [] Until I delete them

Please in the reply show how each item is set above.

If not already, with the high volume you are receiving, you might consider just fetching headers. You will only see the header info but, unless you actually read the 1000s of messages you can just download when Subject or sender is interesting. Then again, this probably requires that the messages remain on the server, so maybe not a good idea.

Probably the only way for me to know what is failing is to record the pop3 log. You can do this by setting the Config Editor parameter "mailnews.pop3.loglevel" to "Debug" or "All" (case sensitive). Then to see the log you can do ctrl-shift-j to bring up the console. In console you can select only the "debug" tab to filter out other info and leave only the pop3 log items. You can copy and paste any relevant log content to a file and attach it above. You might also separately enable the warning or error tab to see if there are any pop3 or other system errors occurring.

Gene,
It looks Mac specific to me.
Mail queues are residing on the POP server. Pegasus client and Mercury are written and maintained by the same guy, David Harris. I am running the original NLM version which was abandoned in 2008-2009 by David. Mercury queue is easy to manage as it just contains the actual mail messages in a specific sub-directory. There are no additional SMTP headers inserted like in other POP implementations I worked with. I believe if messages are kept on the server David either inserted a "Read" indicator in the message or modified the file name. As I never keep the messages on the server it is hard to remember what it was.
My settings:
[X] Check for new messages at startup
[X] Check for new messages every 5 minutes (changed to relieve the stress on the ThunderBird which is badly lagged when the fetch failure happens)
[X] Automatically download new messages
[] Fetch headers only
[] Leave messages on server
[] For at most X days
[] Until I delete them

Fetching headers is not an option as I review messages pretty much in real time or as soon as practically possible. All delays are extremely unwelcome.
I will set up the logging as soon as the fetching failures start happening again, probably in couple days.
Thank you,
Vladimir

Gene,

On a separate note, does anybody knows whether it is possible to start the ThunderBird in a cron job on Mac. I can safely terminate it, but cannot start. Tried in root and user contexts.

Thank you,
Vladimir

Gene,

Here is a fragment of the debug log at the time fetching fails:

mailnews.pop3.683: NetworkTimeoutError: a Network error occurred Pop3Client.jsm:369:18
mailnews.pop3.683: SecurityError info: Pop3Client.jsm:375:20
mailnews.pop3.684: NetworkTimeoutError: a Network error occurred Pop3Client.jsm:369:18
mailnews.pop3.684: SecurityError info: Pop3Client.jsm:375:20
mailnews.pop3.685: NetworkTimeoutError: a Network error occurred Pop3Client.jsm:369:18
mailnews.pop3.685: SecurityError info: Pop3Client.jsm:375:20
mailnews.pop3.686: NetworkTimeoutError: a Network error occurred Pop3Client.jsm:369:18
mailnews.pop3.686: SecurityError info: Pop3Client.jsm:375:20
mailnews.pop3.687: NetworkTimeoutError: a Network error occurred Pop3Client.jsm:369:18

Plain ThunderBird restart did n to help. Identified record #3 was stalling the fetch, removed it from the queue. Then observed fetching stalled on record #460, removed first 459 records from the queue, hit F5 which eventually succeeded, and fetching finished.

Please let me know if you need more details.

Thank you,
Vladimir

Re: log fragment at comment 12:
Since I can't tell what was happening before the fragment it's hard to say what is causing the timeout error. There is also an option to add timestamps to the log on the console page, so that info in the log would also probably be interesting.
If you are see 100 second delay in the log before or between the tiemout errors, it's possible that the server is just not responding quick enough and taking more than 100 seconds to respond. You might consider increasing the Config Editor parameter mailnews.tcptimeout which defaults to 100 sec and increase it to maybe 200 and see if that helps.

Please let me know if you need more details

Yes, need to know what was happening before the timeouts. Also, just to be sure, I assume you are not seeing any LIST or UIDL commands sent to the server. Those should only occur if you are keeping message on the server, which apparently you are not.

cannot start [with cron job]

I've never attempted to run tb in a cron job but I don't know why you couldn't/can't. You can definitely start tb from a command line in a bash shell (which I think mac uses like linux also uses).
You may have to put the path to tb in the cron line like this example:
../obj-x86_64-pc-linux-gnu/dist/bin/thunderbird
I assume you mean you can successfully 'kill" tb with cron job but just can't start it?

Edit: typo fixed above. It should be mailnews.tcptimeout

Gene,

It is very unlikely the server takes more than 100 seconds to respond. I can take the packet trace next time it will be happening to exclude this theory.

Please provide the instructions on how to get the preceding events. Should I not pick DEBUG tab, should I not apply the pop filtering?

I was asking about the practical experience with Mac when I was asking about cron. I know the theory, and I have the correct startup line which works fine in the Terminal, but not in the cron job. Unfortunately my yesterday experience proved a plain TB reboot is not a 100% remedy so the forced restart is not a workaround any more.

Thank you,
Vladimir

Gene,

I have started analyzing the debug log collected yesterday and I have a couple questions:

  1. Where the log file is stored in the file system?
  2. What does the magenta in the server response dented to the right mean?

Thank you,
Vladimir

Attached file POP3 negotiations (obsolete) —
Gene, Here is a sample of a healthy negotiation:

Gene,

Here is a sample of a healthy negotiation:

18:04:43.712 mailnews.pop3.10: S: +OK mail.int.hollebcons.com Server closing down. Pop3Client.jsm:348:18
18:04:43.831 mailnews.pop3.10: Connection closed. Pop3Client.jsm:395:18
18:04:44.097 mailnews.pop3.11: Connecting to pop://<server-IP>:110 Pop3Client.jsm:141:18
18:04:44.612 mailnews.pop3.11: Connected Pop3Client.jsm:295:18
18:04:44.856 mailnews.pop3.11: S: +OK <78841924.13655@mail.int.hollebcons.com>, MercuryP/NLM v1.48 ready. Pop3Client.jsm:348:18
18:04:45.091 mailnews.pop3.11: C: CAPA Pop3Client.jsm:508:20
18:04:45.307 mailnews.pop3.11: S: -ERR Bad command. Pop3Client.jsm:348:18
18:04:45.308 mailnews.pop3.11: Possible auth methods: USERPASS Pop3Client.jsm:597:18
18:04:45.308 mailnews.pop3.11: Current auth method: USERPASS Pop3Client.jsm:668:18
18:04:45.308 mailnews.pop3.11: C: USER vladmhc Pop3Client.jsm:508:20
18:04:45.523 mailnews.pop3.11: S: +OK vladmhc. Pop3Client.jsm:348:18
18:04:45.523 mailnews.pop3.11: C: Logging suppressed (it probably contained auth information) Pop3Client.jsm:502:20
18:04:45.795 mailnews.pop3.11: S: +OK 2 messages (12233 bytes) Pop3Client.jsm:348:18
18:04:45.796 mailnews.pop3.11: C: STAT Pop3Client.jsm:508:20
18:04:45.849 mailnews.pop3.11: S: +OK 2 12233 Pop3Client.jsm:348:18
18:04:45.859 mailnews.pop3.11: Folder lock acquired uri=mailbox://vladmhc@<server-IP>/Inbox. Pop3Client.jsm:998:22
18:04:45.859 mailnews.pop3.11: C: LIST Pop3Client.jsm:508:20
18:04:45.904 mailnews.pop3.11: S: +OK 2 messages, 12233 bytes Pop3Client.jsm:348:18
18:04:45.924 mailnews.pop3.11: S: 1 6115 2 6118 . Pop3Client.jsm:348:18
18:04:45.924 mailnews.pop3.11: C: UIDL Pop3Client.jsm:508:20
18:04:45.973 mailnews.pop3.11: S: +OK unique IDs follow... Pop3Client.jsm:348:18
18:04:45.992 mailnews.pop3.11: S: 1 007E3.CNM587E9088 2 00829.CNM587E9091 . Pop3Client.jsm:348:18
18:04:45.992 mailnews.pop3.11: C: RETR 1 Pop3Client.jsm:508:20

As you can see, the server is not happy about CAPA, but digests it perfectly. UIDL is issued by the TB down the road. Is it a problem? It seems normal to me, but you mentioned it as a potential problem.

Thank you,
Vladimir

Gene,

This time it was record 8, see the full Debug log attached.

Wow, it is not so easy to attach a file here. Tried to do it through the terminal, but posted the terminal buffer instead. It can be deleted as irrelevant unless you want to see what happens when TB is started from cron, among other not related activities.

Let's try one more time. It seems to have worked this time.

Please let me know what else you would need top proceed.

It looks like the server does actually stop responding for whatever reason. WireShark shows empty POP|IMF response. But there is no networking events, like drops or anything of that nature.

Thank you,
Vladimir

First off, I guess your server "Mercury" doesn't support CAPA. But that's OK, it's an optional feature and the tb code just assumes default capabilities if CAPA fails because it is not supported.

I think LIST is always needed and is a required capability to know what needs to be downloaded. But I'm not sure about UIDL. It is definitely an optional feature and I thought it would only occur if you want to leave messages on the server. I need to research that some.

As you saw, it looks like the server sent an empty response (log just shows "S: ") and TB waited the 100 seconds (tcptimeout) for more and nothing more came in, so TB received the timeout from the low-level network code and should have dropped the connection. It's good that you also see this empty response in wireshark as a verification that TB log is not lying. In wireshark filter you might have to remove the POP|IMF filtering to see the tcp FIN or RST sent by tb to terminate/drop the connection.

Gene,

I do see TB sending FIN, ACK in 100 seconds.

Now what do we do? Can I adjust something in the TB, is it a bug, or what is the next step?

Why do you think UIDL could be a problem if oil is properly processed by Mercury?

Thank you,
Vladimir

(In reply to Vladimir from comment #15)

  1. Where the log file is stored in the file system?

That's a good question. I looked for it too and didn't see anything in "temp" directories that looked like the log. It does get output to stdout however (but w/o the timestamps and the links to source lines) so you can also see it in the OS console if you start TB from command line..
FWIW, I mostly work on imap issues and it uses a "better" logging method than stuff written in javascript. Its log go into user specified files.

  1. What does the magenta in the server response dented to the right mean?

Not sure what you are referring to. Maybe the source links on the far right of the log screen? Those just show where in the source files the log event ocurred.

(In reply to Vladimir from comment #23)

Gene,

I do see TB sending FIN, ACK in 100 seconds.

Ok, good to know.

Now what do we do? Can I adjust something in the TB, is it a bug, or what is the next step?

You can go into Config Editor (at the bottom of the main Settings page) and look for mailnews.tcptimeout and increase to something, maybe 500, and see if that helps. If server is not crashing and not reporting errors when the timeout occurs and is just being slow, it may help. Be sure to restart TB after changing a low level parameter like this.

Why do you think UIDL could be a problem if oil is properly processed by Mercury?

It shouldn't be a problem. But if you see timeouts or errors doing something that is not really needed (UIDL when not leaving messages on server) it might contribute to the problem(s). (I still need to look into this.)

Gene,

After I removed the first 8 records from the Mercury delivery queue TB would still stall. I then removed 62 duplicates from the TB Inbox. That allowed it to fetch 61 records, but it became stuck on #62, coincidentally or not.

At the same time the log showed Security Error in Pop3Client.jsm:375:20

I then removed 67 records from the queue, and it stalled at record 17. Removed first 17 records. Removed duplicates in the Inbox. It would still stall. Removed duplicates in two (2) sub-folders. TB crashed, submitted report where I have referenced this ticket #, restarted TB. It would not restart on its own. Started from the dock.

Still going through the exercise.

Saw your response about the timeout. I will not do that as it will slow down my recovery effort as I have to wait 100 seconds before my F5 would be processed.

The server never crashes. It is NetWare, not Windows.

Here is the relevant server output:

Connection from <IP-pref>.121 at Mon Apr 1 14:30:51 2024
User vlad.hci, (7) 722 messages, 23047822 bytes

Socket closed unexpectedly.
105 sec. elapsed, connection closed Mon Apr 1 14:32:36 2024

As you see the server was just patiently waiting on the client. If anything I may reduce the timeout to 20 seconds until the issue is hopefully resolved.

Thank you,
Vladimir

(In reply to Vladimir from comment #19)

Gene,

This time it was record 8, see the full Debug log attached

Can the Debug Log be removed? It was an erroneous submission. There is no easy way to attach a file here...

-Vladimir

I can't but I think Wayne can.
Wayne, can you get the attachment at comment 19 removed? Thanks!

Flags: needinfo?(vseerror)

As you see the server was just patiently waiting on the client. If anything I may reduce the timeout to 20 seconds until the issue is hopefully resolved.

All messages are supposed to end with CRLF.CRLF. I can see in the log that your server sent the "." (dot/period/full-stop) and maybe the final CRLF was in the next tcp packet and somehow TB didn't comprehend that and was expecting something else and just kept waiting on the server. I can't tell without the detailed wireshark trace, which maybe you could check. But I'll also check the code to see if that is a possibility.

From comment 21:

WireShark shows empty POP|IMF response.

Are you referring to the response sent by the server here?
Is the response completely empty or might it contain a CR or LF (0x0d or 0x0a)?

(In reply to gene smith from comment #29)

As you see the server was just patiently waiting on the client. If anything I may reduce the timeout to 20 seconds until the issue is hopefully resolved.

All messages are supposed to end with CRLF.CRLF. I can see in the log that your server sent the "." (dot/period/full-stop) and maybe the final CRLF was in the next tcp packet and somehow TB didn't comprehend that and was expecting something else and just kept waiting on the server. I can't tell without the detailed wireshark trace, which maybe you could check. But I'll also check the code to see if that is a possibility.

Gene,

There is definitely a "." in the end of the respective TCP Stream:

<tr><th class=3D"odd">Hostalias:</th><td class=3D"odd">CORWSUS1</td></tr>
</table><p>
</p></body></html>

--======ec2b2425da590718a86328de--

.

-Vladimir

(In reply to gene smith from comment #30)

From comment 21:

WireShark shows empty POP|IMF response.

Are you referring to the response sent by the server here?
Is the response completely empty or might it contain a CR or LF (0x0d or 0x0a)?

Gene,

The 60-byte packet comes from the server. The payload length is 1. Hex 0a.

-Vladimir

Here is the tail of the previous packet in hex:

0580 0d 0a 0d 0a 2d 2d 3d 3d 3d 3d 3d 3d 65 63 32 62
0590 32 34 32 35 64 61 35 39 30 37 31 38 61 38 36 33
05a0 32 38 64 65 2d 2d 0d 0a 0d 0a 2e 0d

And as I mentioned in my previous comment "0a" came as a separate packet. TB should be able to re-assemble.

-Vladimir

The 60-byte packet comes from the server. The payload length is 1. Hex 0a.

Ok, that's very interesting. It means that the "CRLF.CR" ended the 2nd to last packet and the last packet contained just "LF" or hex 0a.

Looking at the code for 115 it seems like it should handle this, but not sure.
I recently made a change to the POP3 data handler but it is only currently in beta. It might fix the problem since it changes and somewhat simplifies the line handling. It is here if you are willing to give it a try:
https://archive.mozilla.org/pub/thunderbird/releases/125.0b2/

Gene,

125.0b2 has been installed. I will let you know how it fares in couple days or earlier if it fails the same way.

Thank you,
Vladimir

Flags: needinfo?(vseerror)

(In reply to Vladimir from comment #35)

125.0b2 has been installed. I will let you know how it fares in couple days or earlier if it fails the same way.

I see that the mercury server returns much smaller packets than the other servers I've tested recently (dovecot, courier and cyrus). So there is more chance of a packet split occurring at the terminating CRLF.CRLF, even for fairly small messages (the example failing message you show at comment 20 is about 4k bytes total) . However. looking at the 115 code it still looks to me like it shouldn't be problem. I tried to find a way in TB/mozilla code to reduce the receive buffer size from default of around 16k down to about 4k like mercury seems to send, but I haven't yet found a way.
Note: The "packets" shown in the log don't necessarily correspond in size with the actual tcp/ip packet sizes seen in wireshark since there's some buffering between the raw tcp/ip and the data presented to TB's POP3 application code as seen in the log.

Gene,

The absolute majority of the POP|IMF packets I see in the packet trace are 1,452 bytes which is inline with the 1,500 MTU. There is no re-assembly as the trace was captured on a router. I do see a consistent pattern of retransmissions always from TB to the POP server. Most of them are ACKs, but I also saw POP packets retransmitted, e.g. "DELE 5\r\n"followed by the server's ACK, all at the same time stamp, 10:27:08.266666. Just FYI.

Thank you,
Vladimir

(In reply to gene smith from comment #34)

The 60-byte packet comes from the server. The payload length is 1. Hex 0a.

Ok, that's very interesting. It means that the "CRLF.CR" ended the 2nd to last packet and the last packet contained just "LF" or hex 0a.

Looking at the code for 115 it seems like it should handle this, but not sure.

This should have been fixed by Bug 1883760 in the Daily recently.

See Also: → 1883760

Indeed, if possible, try Daily or latest 125 beta (which also includes that fix.)

Magnus,

Running 125.0b2 for the third (3) day without any issues. It looks like packet re-assembly / parsing issue is resolved. When will be the fixed code moved into production?

The second part of the problem was duplicate messages or is that not curable? I needed to use an add-on to remove them.

Thank you,
Vladimir

From comment 38:

This should have been fixed by Bug 1883760 in the Daily recently.

Yes, that does look like it fixed it. I was mostly looking at daily code and didn't see that change (look for LF and and not CRLF) even though now I vaguely remember seeing the fix about month ago since someone CC'd me on bug 1883760.

From comment 40:

The second part of the problem was duplicate messages or is that not curable? I needed to use an add-on to remove them.

Are you still seeing dupes even with the LF issue fixed?

I'm also wondering if you know at about which version of TB you started seeing the issues of this bug? The LF bug fixed at bug 1883760 has been present since 102.0.2, almost 2 years ago.

(In reply to gene smith from comment #41)

From comment 40:

The second part of the problem was duplicate messages or is that not curable? I needed to use an add-on to remove them.

Are you still seeing dupes even with the LF issue fixed?

That is comprehensible. POP3 works differently here than IMAP. Mails that have been downloaded once remain in the mailbox until they are deleted locally. If an e-mail is downloaded multiple times, then real duplicates are created.

Pop3Client.jsm:348:18
10:37:31.229 mailnews.pop3.502: C: RETR 1 Pop3Client.jsm:508:20
10:37:31.267 mailnews.pop3.502: S: +OK Here it comes...
[...]
.
Pop3Client.jsm:348:18
10:37:31.313 mailnews.pop3.502: C: DELE 1 Pop3Client.jsm:508:20
10:37:31.335 mailnews.pop3.502: S: +OK Message deleted.

According to the log, the messages were loaded and deleted. This means that the UIDL is of no interest for the TB, as the mail should no longer exist.
Since the connection was interrupted by the bug before the QUIT, the delete commands for the server are no longer valid. The server therefore offered the mails for download again and again. The behavior corresponds to the specifications of the RFC.

Summary: POP Mailbox Indexes Are Corrupted Daily, Duplicate Messages Created → POP3 Mailbox Indexes Are Corrupted Daily, Duplicate Messages Created

(In reply to Vladimir from comment #40)

The second part of the problem was duplicate messages or is that not curable? I needed to use an add-on to remove them.

There is an add-on: "Remove Duplicate Messages".
But I can't say anything about whether it works or whether it is suitable for you.

https://addons.thunderbird.net/en-US/thunderbird/addon/removedupes

(In reply to gene smith from comment #41)

From comment 40:

The second part of the problem was duplicate messages or is that not curable? I needed to use an add-on to remove them.

Are you still seeing dupes even with the LF issue fixed?

I'm also wondering if you know at about which version of TB you started seeing the issues of this bug? The LF bug fixed at bug 1883760 has been present since 102.0.2, almost 2 years ago.

Gene,

No, no more duplicate messages since I do not have the underlying issue any more, i.e. no stalled / interrupted / repeated fetching of the same messages other and other again.

I just wanted to remind it is worth fixing if possible.

As for the version it is really hard to say now. All I know I am on 115.9.0 (64-bit) on Windows and this where I never saw stalled fetching, but I did see duplicates on occasion.

Before going to Beta version I was on the same version on Mac, and this is where all the action happened.

If you want to add a little bit more complexity, since we now know the root cause was related to the TCP/IP kind of, there is another difference between Windows and Mac setup. Windows is located on the same LAN as the POP server, whereas Mac is connected through a VPN.

Thank you,
Vladimir

(In reply to Alfred Peters [:infofrommozilla] from comment #43)

(In reply to Vladimir from comment #40)

The second part of the problem was duplicate messages or is that not curable? I needed to use an add-on to remove them.

There is an add-on: "Remove Duplicate Messages".
But I can't say anything about whether it works or whether it is suitable for you.

https://addons.thunderbird.net/en-US/thunderbird/addon/removedupes

Alfred,

This is the add-on I use. It works as a charm even though TB some times crashes when a massive deletion occurs. By massive I mean several thousand messages at once.

Thank you,
Vladimir

Bug 1883760 will probably be fixed in v115.10.

Status: UNCONFIRMED → RESOLVED
Closed: 6 months ago
Duplicate of bug: 1883760
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: