Bug 360875

Summary:	binary.peek on message with inline attachment hangs while loading content
Product:	[Applications] trojita	Reporter:	Erik Quaeghebeur <bugs.kde.org>
Component:	IMAP	Assignee:	Trojita default assignee <trojita-bugs>
Status:	RESOLVED NOT A BUG
Severity:	crash	CC:	brong
Priority:	NOR
Version First Reported In:	git
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	The message that triggers the issue Capabilities of the server triggering the issue Connection log of the server triggering the issue Capabilities of the server not triggering the issue Connection log of the server not triggering the issue

Description Erik Quaeghebeur 2016-03-22 23:04:16 UTC

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

Comment 1 Erik Quaeghebeur 2016-03-22 23:08:14 UTC

Created attachment 98031 [details]
The message that triggers the issue

Comment 2 Erik Quaeghebeur 2016-03-22 23:10:10 UTC

Created attachment 98032 [details]
Capabilities of the server triggering the issue

Comment 3 Erik Quaeghebeur 2016-03-22 23:10:46 UTC

Created attachment 98033 [details]
Connection log of the server triggering the issue

Comment 4 Erik Quaeghebeur 2016-03-22 23:11:30 UTC

Created attachment 98034 [details]
Capabilities of the server not triggering the issue

Comment 5 Erik Quaeghebeur 2016-03-22 23:12:12 UTC

Created attachment 98035 [details]
Connection log of the server not triggering the issue

Comment 6 Bron Gondwana 2016-03-22 23:33:00 UTC

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.

Comment 7 Bron Gondwana 2016-03-23 01:58:17 UTC

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.

Comment 8 Erik Quaeghebeur 2016-03-23 10:37:34 UTC

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?

Comment 9 Bron Gondwana 2016-03-23 12:47:06 UTC

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.