When a message on a server that Trojità says binary.peek to has an inline attachment (e.g., picture in an html mail, but also in text-only mails), Trojità hangs while loading the content of that message. With ‘hangs’, I mean that the content is not fetched and that no further IMAP requests seem possible. The GUI is still responsive, e.g., other, cached messages can still be viewed. I will attach the capabilities and the IMAP log for two servers, the one triggering the hang (Cyrus) and one not triggering it (Dovecot); I'll also attach my test message. (Trojita says body.peek to the latter.) Reproducible: Always
Created attachment 98031 [details] The message that triggers the issue
Created attachment 98032 [details] Capabilities of the server triggering the issue
Created attachment 98033 [details] Connection log of the server triggering the issue
Created attachment 98034 [details] Capabilities of the server not triggering the issue
Created attachment 98035 [details] Connection log of the server not triggering the issue
Hi, This seems to be FastMail :) Jan pointed me over here. We've confirmed that the bug is related to Cyrus' handling of zlib (COMPRESS=DEFLATE) and binary uncompressible boundaries. More as I figure it out.
We've patched upstream and will roll out FastMail with a change that stops putting boundaries in the outstream. It's a bit scummy, but it's better than waiting until we have time to fix it "properly". This just spends a little more CPU at both ends than would strictly be required otherwise.
Ok, the issue is gone, thanks for the quick work. Marking as RESOLVED INVALID, as this was not a Trojità bug. Bron: perhaps add a link here to the patch/commit that fixes this in your upstream, for completeness?
Sure, it's here: https://git.cyrus.foundation/rI8a6cfddcf1c5ac9e3bbac91b226d9e4a13ba0f6c (and the following one adding __attribute__((unused)) so it's warnings clean again, oops) It's a really stinky bad fix, just turning off the optimisation for boundaries by pretending we never saw any. But it's reliable and simple. I'll come up with a proper fix when Mail::IMAPTalk 4.03 gets merged and released so I can add COMPRESS tests to our test suite and prove the existing bug and then write a fix.