About Thunderbird, here's a review of how we got to this point.
In the past few weeks Thunderbird's beta version started regularly delaying for several seconds in the middle of delivering outbound email messages.
My first theory was that OCSP certificate validation was suddenly taking too long for some reason, but disabling OCSP didn't eliminate the delays.
My next theory was that my VPN was causing networking delays, but disabling the VPN didn't solve the problem.
Now on to the new stuff…
🧵2/12

I had previously used strace on the sendmail daemon on my mail server to prove that during the delay it was waiting for data from Thunderbird, but that didn't rule out the possibility that Thunderbird had sent the data but it was being held up in transit on the network. I was able to rule that out by running tcpdump on my computer and confirming that Thunderbird was pausing before sending the data to the server. Definitely a Thunderbird issue!
🧵3/12

Next: can I use mozregression to figure out exactly when the problem was introduced? Well, it turns out that although doesn't happen every time, it happens often enough that I over the course of a day I was indeed able to identify the exact Thunderbird build where the issue first appeared. I added this information to the bug ticket <https://bugzilla.mozilla.org/show_bug.cgi?id=1986367#c5> in the hope that someone smarter than I would be able to figure out next steps.
🧵4/12

In the process of doing the mozregression thing, I discovered not one, but two additional bugs in Thunderbird, which I reported: "changing selected identity but not really in compose window causes modified draft not to be saved" <https://bugzilla.mozilla.org/show_bug.cgi?id=1986558> and "signature specified as path to HTML file does not work when profile directory is copied to non-standard location" <https://bugzilla.mozilla.org/show_bug.cgi?id=1986555>.
🧵5/12

I was originally planning on just leaving things there and living with the annoying delays until someone from the Thunderbird dev team was able to pick up the investigation where I left off, but while I was writing this thread I ended up doing a bit more digging and discovered that in addition to using OCSP for certificate validation, Firefox also uses something called CRLite, so I decided to see if disabling CRLite would make the problem go away. Alas, no.
🧵6/12

I have another theory… maybe there's something wrong specifically with the STARTTLS code used when connecting to port 587, in which case switching to port 465 and using TLS directly instead of STARTTLS might avoid the problem. I think probably not, but it's worth a try.
While configuring Thunderbird to test this theory, I discovered ANOTHER bug, "message sending hang when you switch outgoing server from port 465 to 587 or vice versa" <https://bugzilla.mozilla.org/show_bug.cgi?id=1986580>.
🧵7/12

Now, on to Synology Drive… my client syncing got messed up again, and this afforded me the opportunity to attempt yet again to debug what was happening and try to come up with a workaround. While doing that I discovered that my workaround for a different Synology Drive issue <https://blog.kamens.us/2021/03/17/synology-drive-client-for-linux-has-a-data-loss-bug-synology-refuses-to-fix-heres-a-workaround/> wasn't working properly.
🧵8/12

It's possible that my synology-inotify script not working properly is the cause of the recent sync issues I've been seeing, i.e., it's possible the sync issues are due to the same Synology bug I already knew about rather than a different one. So I guess I need to get to the bottom of why my script isn't doing what it's supposed to?
🧵9/12

Unfortunately, there are no log messages indicating errors, and I couldn't see any problems with the code (that doesn't mean there aren't any!).
So I ended up adding a bunch of new code: more debug logging; the ability to switch the debug logging on and off by sending the script a signal; the ability to tell the script to reset all of its file watchers by sending it a different signal; and the ability to tell the script to run a self-test on itself by sending yet another signal.
🧵10/12