User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/101.0.4951.67 Safari/537.36

Steps to reproduce:

1. In Thunderbird, open a newly received message.
2. While the message is still loading (fetching data from the IMAP server), remove it.

The problem is difficult to reproduce. We still don't know what our end users are doing to trigger the problem. What we observed is that Thunderbird was endless trying to fetch a message that was deleted.

Anyway, we were able to successfully reproduced the problem by removing the message directly in our IMAP server while Thunderbird was fetching it.
The log attached shows this scenario.

We're also able to reproduce the problem by removing the message in our webmail (horde) while opening the message in Thunderbird.

Actual results:

After we remove the message, the IMAP server process get stuck in a endless loop, consuming processing and memory resources. By analyzing this process, we noticed that Thunderbird was endlessly trying to fetch data from this removed message.

We are using 'courier-imap' 5.1.4 for our IMAP server. The log attached is the output of a strace -p [PID] command executed on our server, where [PID] the Process ID that got stuck.

We anonymized the log and reduced its size by striping some of the data returned by the IMAP FETCH command.

The issue is not affecting Thunderbird. The application continues to run without any warning to the user using it. The server process in endless loop is terminated if Thunderbird is closed.

I don't know if it is the same problem, but it seems to be related to Bug 1315533.

Expected results:

Thunderbird should have stopped trying to fetch the removed message.

The issue is not affecting Thunderbird. The application continues to run without any warning to the user using it. The server process in endless loop is terminated if Thunderbird is closed.

Just curious how the end user knows there is a problem? Does TB slow down or something so the user notices?
Any theory on how the end users are seeing this. Is this a shared folder where someone may be trying to read a message and someone else is deleting it? Is this only on newly received messages or does it occur for old ones that have been around a while too? Are you using offline store (mbox or maildir) or do you just let TB store headers?

I'm not good at reading the strace log so can you provide an IMAP:5 log from TB that shows the problem? You can find details on how to record the log here: https://wiki.mozilla.org/MailNews:Logging

I'll also try to duplicate the problem here by deleting the email file from my local dovecot server while TB is fetching it. Or maybe have 2 TB instances with one fetching it and the other deleting it.
Thanks for digging up Bug 1315533. Lots to read there and it does sound similar and never resolved.

I tested with a fairly large message in a dovecot mailbox and two tb instances with no offline store. On instance two I select and display the message. Then on instance one I select the same message and begin fetching it with an IMAP:5 log recording. I immediately switch to instance two and delete the message. I can see on instance 1 that only a partial upload occurs (the message is mostly a very large graphics file and I only see maybe half of the picture). Looking at the instance one log I see that imap expunges are reported by the server as part of the fetch response. For as yet undetermined reasons, TB sees these expunge responses as a syntax error and the connection is dropped and no more fetch activity occurs. So I'm not seeing an endless loop of fetching with dovecot.
I don't have a locally available Courier server to test this with but do have access to someone else's Courier server. I'll see if I can test with it tomorrow with the same large message. And if you can provide an IMAP:5 log of what you see, a comparison to what I see might be helpful.

Same test with courier seems to work OK. When I delete the large message on instance two while instance one is downloading (fetching) the same large message, the download finishes and the message is completely there. I think this may be because courier doesn't support imap move (just copy) so the message is still present and just marked deleted in the mailbox so instance one can still keep fetching it since it is not expunged. Maybe if I quickly "compact" the folder (does a mailbox expunge) it will cause an expunge response seen on instance one like I see with dovecot. Will try that a bit later...

(In reply to gene smith from comment #1)

Hi Gene. Thanks for your answer!

Just curious how the end user knows there is a problem? Does TB slow down or something so the user notices? Any theory on how the end users are seeing this.

I don't think they've noticed the problem at all. At least, we don't know of any users complaining of TB crashes. In our tests, TB just don't show the message to the user.

We've found this problem because the load of our imap server was quite high one day. When we started to analyze the problem, we saw that 2 courier-imap processes were consuming a lot of CPU. By running strace in these processes, we observed that the imap client (TB in this case) was incessantly sending FETCH to a file that did not exist on the server. Then, we inferred that a race condition could have triggered that loop and we were able to reproduce the issue by deleting the file while a FETCH was in progress.

Is this a shared folder where someone may be trying to read a message and someone else is deleting it?

No.

Is this only on newly received messages or does it occur for old ones that have been around a while too?

We reproduced the problem with old messages. But I really don't know how our users triggered the problem.

Are you using offline store (mbox or maildir) or do you just let TB store headers?

We' re using Maildir to store our client's e-mails.

I'm not good at reading the strace log so can you provide an IMAP:5 log from TB that shows the problem? You can find details on how to record the log here: https://wiki.mozilla.org/MailNews:Logging

I will provide it.

In the meantime, I highlighted some parts of the strace log bellow. In this log, write means data sent by server and read data received.

The snippet bellow is when the courier-imap tells TB that the file was deleted.

24: read(0, "66 check\r\n", 8192)           = 10
131: write(1, "* 2196 EXPUNGE\r\n* 2195 EXISTS\r\n* 1 RECENT\r\n66 OK CHECK completed\r\n", 66) = 66

After that, TB tries to fetch the file anyway.

133: read(0, "67 UID fetch 70279 (UID RFC822.SIZE BODY[]<1900544.65536>)\r\n", 8192) = 60
134: write(1, "67 OK FETCH completed.\r\n", 24) = 24
136: read(0, "68 UID fetch 70279 (UID RFC822.SIZE BODY[]<1966080.65536>)\r\n", 8192) = 60
137: write(1, "68 OK FETCH completed.\r\n", 24) = 24
139: read(0, "69 UID fetch 70279 (UID RFC822.SIZE BODY[]<2031616.65536>)\r\n", 8192) = 60
140: write(1, "69 OK FETCH completed.\r\n", 24) = 24

Two things are interesting here (besides the fact that thunderbird continues to send the fetch command):

1. The file position, sent by the fetch command, increases on every call. But the server did not return any data. With the process in this loop state for enough time, TB starts to send a file position that is greater than the file size, to a point that the file position overflows and turns to a negative number (I think it might be another bug here).

2. The courier-imap returns OK FETCH for a file that don't exists. I thought that was weird, but it seemed to be in compliance with RFC 3501 (https://tools.ietf.org/html/rfc3501#section-6.4.8):

A non-existent unique identifier is ignored without any error
message generated.  Thus, it is possible for a UID FETCH command
to return an OK without any data or a UID COPY or UID STORE to
return an OK without performing any operations.

I'll also try to duplicate the problem here by deleting the email file from my local dovecot server while TB is fetching it. Or maybe have 2 TB instances with one fetching it and the other deleting it.

We're not able to reproduce the problem with only one TB instance. We reproduced the problem in the following scenarios:

1. TB fetching the message and we delete the file from the server.
2. TB fetching the message and we delete the message using our webmail client.
3. Two instances of TB: one fetching the message and the other one deleting it.

(In reply to gene smith from comment #3)

Same test with courier seems to work OK. When I delete the large message on instance two while instance one is downloading (fetching) the same large message, the download finishes and the message is completely there. I think this may be because courier doesn't support imap move (just copy) so the message is still present and just marked deleted in the mailbox so instance one can still keep fetching it since it is not expunged. Maybe if I quickly "compact" the folder (does a mailbox expunge) it will cause an expunge response seen on instance one like I see with dovecot. Will try that a bit later...

Thats weird. Even when we used two instances of TB to test the issue, I think the file was removed from the server's file system. We will test it again the check.

I will have to confirm this, but I think a friend of mine were able to reproduce the problem by moving the file to another folder instead of deleting it.

BTW, we're using courier-imap 5.1.4

I will have to confirm this, but I think a friend of mine were able to reproduce the problem by moving the file to another folder instead of deleting it.

Confirmed. Move also triggers the problem. Our webmail sends the file to folder trash when we press delete and we reproduced the problem in this scenario.

Another information is that, when we reproduced the problem using two TB instances, we've ran them in different computers. We were not able to reproduce the problem when we ran both instances on the same machine.

I checked closer and move to a folder or move to trash actually copies the message but then does a "uid expunge" on the message, so the test is removing (expunging) the message from the source folder while it is being fetched.

I also tried the test using "SqWebMail" to the courier server, it is in Italy, tana.it and I don't have access to its internal files (I'm in TN, USA). Still don't see what you see. When I delete the message in SqWebMail with tb downloading the message, the IMAP:5 log shows that tb detects a problem and logs out and then creates a new connection and finishes the download. It appears that courier has maybe a semaphore and holds off expunging the message until the download finishes.

Don't know the courier version but do see copyright 2022 in the capability response so probably it is maybe newer than your 5.1.4 version. (Courier doesn't support imap ID it appears.)

I haven't tested with two computers each with their own tb instance. I don't see why that would matter but who knows.

TB fetching the message and we delete the file from the server.

Are you going in and deleting the "maildir" file on the server containing the email (if that's how courier stores messages)?
I haven't tried this with my local dovecot.

I'll ask Alessandro, the courier server owner, if he has any ideas on this.

We' re using Maildir to store our client's e-mails.
We reproduced the problem with old messages. But I really don't know how our users triggered the problem.

That's kind of interesting that you see the problem with old messages. They should have been stored in the maildir file and not require fetching to access them. The full fetch should only occur on the initial access to the message.

I've just been testing with no offline store since the full message is fetched on the 1st access of each session and then stored in ram cache for later access. It is only re-fetched on access during a session if the ram cache fills up with other messages or you clear cache and access it again.

So you have each user's TB configured to use maildir offline storage? (Just want to make sure that's what you mean and you are not referring to how emails are stored in the courier server.)

What version of TB are you using? It looks like you are using version 52. If that's the case there have been a lot of changes (e.g., fixes to maildir) that may have an effect and explains why I don't see the problem with my daily build 102.

Don't know the courier version but do see copyright 2022 in the capability response so probably it is maybe newer than your 5.1.4 version. (Courier doesn't support imap ID it appears.)

You've definitely tested in a newer version of couerier-imap.

Are you going in and deleting the "maildir" file on the server containing the email (if that's how courier stores messages)?

Yes. That's exactly one of the tests we did.

So you have each user's TB configured to use maildir offline storage? (Just want to make sure that's what you mean and you are not referring to how emails are stored in the courier server.)

I told you that I was using Maildir, but I didn't specify the storage type we're using in TB. Sorry.
The main INBOX folder of our users is configured to be offline. But other folders can be online (with message sync disabled). When I told I was able to reproduce the problem with old files, I was testing in a online folder. Sorry about that.

What version of TB are you using? It looks like you are using version 52. If that's the case there have been a lot of changes (e.g., fixes to maildir) that may have an effect and explains why I don't see the problem with my daily build 102.

We will try to reproduce the problem in this TB version.

Thanks for your reply.

Actually I tested with daily 103.a1. But I would recommend you test with the latest TB release or, if you prefer, the latest beta.
Anyhow, thanks for the clarifications.

Hi,
I tried to reproduce that behavior, but didn't succeed. I sent myself a large file, and limited the client's connection to 80kb/s (using wondershaper). Then I opened the message and deleted the corresponding file on the server. TB showed the message but not the attachment, and at the same time displayed "1 message deleted from Inbox" on the status bar.

I tried again putting all the fluff in the message text (by commenting out MIME boundaries in between). In that case TB shows a white windows with "Loading message..." in the status bar. As soon as I clear the network limit it says that the message is junk and closes the window quickly.

In neither case imapd was showing up in top.

I run courier-imap 5.1.7, but saw nothing in the ChangeLog looking like fixing such a bug since 5.1.4. TB 91.9.0.

Hi Alessandro,
Thanks for the very thorough test! Hopefully it is something that is fixed in the current TB release that was present back in TB 52. We'll see when reporter Cristiano tests with the newer TB version.
Also, thanks again for keeping open the tana.it account using Courier that I can use for occasional TB testing.

You're welcome.

Hi Gene and Alessandro. Thanks for the answers and your time!

A friend of mine was able to reproduce the problem using the current stable version of TB. We are still using courier-imap 5.1.4 for our testing. He collected the IMAP:5 logs and I will anonimize them and send to you as soon as I can. But I'll sumarize the tests now, as the they're still fresh in my mind.

The Environment:

• TB version 91.10
• TB running on windows 10
• All folders on TB configured to be online
• TB Message Pane turned on
• courier-imap version 5.1.4

The test:

Nothing new here:

1. We opened TB and clicked on a big and old message on our INBOX. The message started to download when we clicked on it as the Message Pane is enabled.
2. While the message is downloading, we deleted it in our webmail (horde). As I told you before, when we tested in TB 52 we were able to reproduce the problem by deleting the message directly in our server or using another instance of TB. For this time, we only tested deleting the message in our webmail.
3. Infinity loop happened.

What we've observed so far:

• We had a hard time trying to reproduce the problem using TB 91. It is much easier to reproduce the problem using TB 52.

• The problem only seems to happen when TB sends an IMAP CHECK command while it is downloading the message. The courier-imap tells TB that the message was deleted in response to one these CHECK commands.

• I also think a CHECK command only seems to happen when TB uses several IMAP FECTH commands to download the message. In TB 52, I don't remember seeing a chunk size greater than 65536 bytes in a FETCH command. So, it is easy to see several FETCH commands to download a message.

• Most of the time, TB 91 is fetching the message body using just one FETCH command and sending no CHECK. Maybe that's why it's so difficult to reproduce the problem on TB 91. Was this feature implemented after TB 52? Related to BUG 1580480?

• However, there are still times when TB 91 downloads the message using several FETCH commands and also sends CHECK. The few times we were able to reproduce the problem in TB 91 we saw this behavior.

• I don't know if it is just a coincidence, but it seems to be easier to reproduce the problem if we use a fresh new installation of TB or a fresh new profile. Maybe with a new installation, TB is still learning the optimal chunk size the use in FETCH and used smaller values?

Not sure what CHECK does. I think it's an alternate form of NOOP or something. I'll look into it.
Yes, I guess 52 used a constant "chunk" size of about 64k. I did notice my chunks were a lot bigger than you show in the log fragment provided.
Also, starting from a new profile the chunk size grows depending on network speed. If you reset the pref value "mail.imap.chunk_size" back to default 65536 and then set the "mail.imap.chunk_add" to 0 or something small, the chunk size won't grow or grow as fast and you will have more chunk fetches to maybe see the problem easier. I think that will work and I'll try it myself tomorrow and see if I can duplicate the problem.
You can also turn off chunking so the whole message is fetched in one transaction: mail.server.default.fetch_by_chunks = false. This may avoid the CHECKs completely, not sure.

As recommended, I changed the following parameters in TB 91:

mail.imap.chunk_size=65536
mail.imap.chunk_add=0

Now I can easily reproduce the problem in our environment using TB 91.

I was also able to reproduce the problem using only one TB instance:

1. We opened TB and clicked on a big and old message on our INBOX. The message started to download when we clicked on it, as the Message Pane is enabled.
2. While the message is downloading, we moved it to another folder, using the same TB instance
3. Infinity loop happened. In TB, the message don't load. But there is no other indication that a problem is happening. You can continue to use TB and ignore this.

Deleting the message doesn't seem to trigger the problem. The message has to be moved. This is a plausible explanation of what our users might be doing.

I'm attaching a IMAP:5 log. Highlighting here some of its contents:

• Download begins. Message has 15107357 bytes.

263: I/IMAP 1a9d5334800:*.****.***.**:S-INBOX:STREAM:OPEN Size: 15107357: Begin Message Download Stream

• courier-imap tells TB that message was deleted is response to an CHECK (is TB ignoring this?):

107478: I/IMAP 1a9d5334800:*.****.***.**:S-INBOX:SendData: 63 check
107481: I/IMAP 1a9d5334800:*.****.***.**:S-INBOX:CreateNewLineFromSocket: * 1 EXPUNGE
107485: I/IMAP 1a9d5334800:*.****.***.**:S-INBOX:CreateNewLineFromSocket: * 0 EXISTS
107489: I/IMAP 1a9d5334800:*.****.***.**:S-INBOX:CreateNewLineFromSocket: * 0 RECENT
107493: I/IMAP 1a9d5334800:*.****.***.**:S-INBOX:CreateNewLineFromSocket: 63 OK CHECK completed

• After that, TB continues to ask for new chunks and courier-imap just returns an OK FETCH completed without any data.

107497: I/IMAP 1a9d5334800:*.****.***.**:S-INBOX:SendData: 64 UID fetch 11 (UID RFC822.SIZE BODY[]<1966080.65536>)
107500: I/IMAP 1a9d5334800:*.****.***.**:S-INBOX:CreateNewLineFromSocket: 64 OK FETCH completed.
107504: I/IMAP 1a9d5334800:*.****.***.**:S-INBOX:SendData: 65 UID fetch 11 (UID RFC822.SIZE BODY[]<2031616.65536>)
107507: I/IMAP 1a9d5334800:*.****.***.**:S-INBOX:CreateNewLineFromSocket: 65 OK FETCH completed.

• TB asks for a chunk which the partial is greater than the file size (maybe checking this could solve the problem?):

109024: I/IMAP 1a9d5334800:*.****.***.**:S-INBOX:SendData: 285 UID fetch 11 (UID RFC822.SIZE BODY[]<15138816.65536>)

• TB asks for a chunk using a negative partial, probably overflowing an int32. Another bug? Shouldn't it be uint32?

356371: I/IMAP 1a9d5334800:*.****.***.**:S-INBOX:SendData: 36075 UID fetch 11 (UID RFC822.SIZE BODY[]<-2147483648.65536>)

Endless loop.

I reproduced it too.

I created a new TB account from scratch, disabled local cache and junk filters. Sent a large message, load it. Now start a new session and read the message. Delete the file from server while downloading. I registered the IMAP dialog server side for the whole session. I removed a quantity of fluff from the log, related to the file download, thereby reducing the log from 19701295 to 17371397 bytes. That's still too much, so I truncated it.

Ok, I think I'm seeing it too. Before I was just deleting to trash in webmail while fetching the large message and in checks it only reported the message marked as /deleted. So the message was still there and the download finished normally. I then tried to move the message to Inbox in the SqWebMail the message gets expunged from the source mailbox, not just marked deleted. This causes check to report the message as expunged which triggers the infinite loop. Right now the fetches just keep going. I haven't shut down tb so they are pounding the tana.it server with stuff like this:

2022-06-07 18:28:59.449335 UTC - [Parent 1122518: IMAP]: I/IMAP 7fcf0128a000:fwmail.tana.it:S-INBOX.Skräpppost:SendData: 4735 UID fetch 32 (UID RFC822.SIZE BODY.PEEK[]<147584000.32000>)
2022-06-07 18:28:59.449409 UTC - [Parent 1122518: IMAP]: I/IMAP 7fcf02cd4000:fwmail.tana.it:S-INBOX.Skräpppost:SendData: 4775 UID fetch 32 (UID RFC822.SIZE BODY.PEEK[]<147872000.32000>)
2022-06-07 18:28:59.655664 UTC - [Parent 1122518: IMAP]: D/IMAP ReadNextLine [rv=0x0 stream=7fcf00f7e160 nb=26 needmore=0]
2022-06-07 18:28:59.655741 UTC - [Parent 1122518: IMAP]: I/IMAP 7fcf0128a000:fwmail.tana.it:S-INBOX.Skräpppost:CreateNewLineFromSocket: 4735 OK FETCH completed.
2022-06-07 18:28:59.655755 UTC - [Parent 1122518: IMAP]: D/IMAP SetConnectionStatus(0x0)
2022-06-07 18:28:59.655761 UTC - [Parent 1122518: IMAP]: D/IMAP ReadNextLine [rv=0x0 stream=7fcf16feeb60 nb=26 needmore=0]
2022-06-07 18:28:59.655806 UTC - [Parent 1122518: IMAP]: I/IMAP 7fcf0128a000:fwmail.tana.it:S-INBOX.Skräpppost:SendData: 4736 check
2022-06-07 18:28:59.655811 UTC - [Parent 1122518: IMAP]: I/IMAP 7fcf02cd4000:fwmail.tana.it:S-INBOX.Skräpppost:CreateNewLineFromSocket: 4775 OK FETCH completed.

I set the chunk size to 32000 with no addition so it's constant. Also, in the code I changed the time between checks to 10 seconds, up from default 600 seconds/10 minutes.

Actually, I saw something like this with dovecot but it fairly quickly disconnected with an error "too many invalid requests" or something like that. It seems that courier just keeps accepting them forever.

Anyhow, need to find out why TB gets confused with the expunge response from the check.

Actually, I wrote comment 20 before I saw comment 16 to 19 and there was a "collision". So I'm sure we are all seeing the same thing. Thanks for the attached logs.

When a message is expunged while a message is being fetched in chunks, when the server detects the expunge it will return no data with the fetch but responds with with <tag> OK. TB was not seeing this as a problem and just went ahead and incremented the message offset by the chunk size and requested the next chunk even though no message content was received. This repeated without end until TB was shut down.

The patch now checks that data of non-zero length is actually received for each chunk fetch. If no data is received, the loop for fetching chunks is exited and the stream is closed, thus stopping the fetches to the server.

I've tested this on the following servers:
Courier-imap (where the problem was originally seen)
Dovecot
Cyrus
Gmail
Yahoo

Note: Courier-imap doesn't notice the expunge until the expunge is reported during the imap CHECK response. Other servers I tested report the expunge within the fetch response independent of CHECK and then return the empty fetch response.

Hi Gene.

The patch now checks that data of non-zero length is actually received for each chunk fetch. If no data is received, the loop for fetching chunks is exited and the stream is closed, thus stopping the fetches to the server.

I don't how you've implemented it, but you might take a look at https://bugzilla.mozilla.org/show_bug.cgi?id=1315533#c15

Thanks!

Bug 1315533 comment 15 is about some servers reporting the message size wrong. The problem here is because a message expunged during a fetch in chunks will return no / empty response data and the loop that iterates through the chunks never knows there is no data and just asks for the next chunk at the previous file offset plus the chunk size until hell freezes over.
Bug 1315533 mentions "expunge" in several places but never reaches a conclusion that I can tell. (The comments by WADA are very detailed and difficult to parse, at least for me.)

TB/Mozilla allows the creation of "try" builds to allow testing of a change by users before it is pushed or landed. I created a try build for linux64 and win64 here: https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=0e70ab45b94426d17aba9bfb76670878d11c0ca1.
For windows, click the green "B" next to "Windows 2012 x64 opt" and then down below click "Artifacts". In the list select and download target.installer.exe and install it. This is the daily build with just my not-yet-reviewed changes applied. Not sure where you are but the try builds are only in English locale.
With this fix you shouldn't see the infinite loop any more after the message being fetched is expunged even with the chunking parameter as you show in comment 16.

(In reply to gene smith from comment #25)

TB/Mozilla allows the creation of "try" builds to allow testing of a change by users before it is pushed or landed. I created a try build for linux64 and win64 here: https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=0e70ab45b94426d17aba9bfb76670878d11c0ca1.
For windows, click the green "B" next to "Windows 2012 x64 opt" and then down below click "Artifacts". In the list select and download target.installer.exe and install it. This is the daily build with just my not-yet-reviewed changes applied. Not sure where you are but the try builds are only in English locale.

Hi Gene.
I downloaded and installed this version and could not reproduce the BUG anymore.
Thanks again for your time!

Will this fix be available on TB 103?

Glad it seems fixed. Thanks for testing the try build!

Will this fix be available on TB 103?

That's probably up to Magnus and/or Wayne. Also, still waiting on a review by Ben. Also, this is my first patch submission via the "phabricator" tool (as requested that I use by Magnus) instead of just the old way of attaching the patch. So hopefully I've done it right.

(In reply to gene smith from comment #27)

Glad it seems fixed. Thanks for testing the try build!

Will this fix be available on TB 103?

That's probably up to Magnus and/or Wayne. Also, still waiting on a review by Ben.

Ineed depends on review. But I say it has a good chance to be in 103

Pushed by alessandro@thunderbird.net:
https://hg.mozilla.org/comm-central/rev/438bac3b39f2
Avoid non-stop imap chunk fetches if message expunged during fetch r=BenC

I think I saw this on 102rc build 2 while testing bug 1776727. Not sure what I did to trigger it. Looks like this patch is not in 102rc.

I think we should get this into ESR as well.

Comment on attachment 9280584 [details]
Bug 1770811 - Avoid non-stop imap chunk fetches if message expunged during fetch r=benc

[Approval Request Comment]
Regression caused by (bug #): not a regression
User impact if declined: can get into endless loop
Testing completed (on c-c, etc.): has been in 103 beta from start
Risk to taking this patch (and alternatives if risky): seems safe

Comment on attachment 9280584 [details]
Bug 1770811 - Avoid non-stop imap chunk fetches if message expunged during fetch r=benc

[Triage Comment]
Approved for esr102

Thunderbird 102.0.3:
https://hg.mozilla.org/releases/comm-esr102/rev/294930097ed6