Bug 376287 - multipart/related with text/html should not hide all other parts
Summary: multipart/related with text/html should not hide all other parts
Status: RESOLVED UNMAINTAINED
Alias: None
Product: trojita
Classification: Applications
Component: Core (other bugs)
Version First Reported In: git
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Trojita default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-02-10 13:53 UTC by Jan Kundrát
Modified: 2024-09-23 18:50 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Kundrát 2017-02-10 13:53:17 UTC
A new bank just started sending me e-mails like this one:

Content-Type: multipart/related; 
	boundary="----=_Part_6487_1186403229.1486732952500"

------=_Part_6487_1186403229.1486732952500
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

[html stuff here]
------=_Part_6487_1186403229.1486732952500
Content-Type: application/pdf; 
	name="... .pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; 
	filename="... .pdf"

[PDF]
------=_Part_6487_1186403229.1486732952500--

Unfortunately, our MIME interpreter deems stuff which is nested in the same layer as the main HTML part within a multipart/related container to be a part of the HTML message.

In this case, we should take a hint of the Content-Disposition header at least. Our code also already correctly handles the attachment icon in the message listing.
Comment 1 Erik Quaeghebeur 2018-01-24 10:07:39 UTC
I can confirm this. I encountered this issue in a slightly different form: a linked inline(!) application/pdf in a text/html in a multipart/related. The pdf cannot be reached from Trojitá, also not by clicking the link. There is an inline image that is decoded, however.

Content-Type: multipart/alternative;
	boundary="------------D478949D69471ABC8287B74F"

--------------D478949D69471ABC8287B74F
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit

…
<cid:part1.8F8AE3B0.FE8D5CAA@…>
…

--------------D478949D69471ABC8287B74F
Content-Type: multipart/related;
	boundary="------------84789C173342F1615D0EC401"

--------------84789C173342F1615D0EC401
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 8bit

…
<a moz-do-not-send="false" href="cid:part1.8F8AE3B0.FE8D5CAA@…">…</a>
…
<img alt="…" src="cid:part2.6149188C.8194FD1B@…" …>
…

--------------84789C173342F1615D0EC401
Content-Type: application/pdf; name="…"
Content-Transfer-Encoding: base64
Content-ID: <part1.8F8AE3B0.FE8D5CAA@…>
Content-Disposition: inline; filename="….pdf"

…
--------------84789C173342F1615D0EC401
Content-Type: image/png; name="….png"
Content-Transfer-Encoding: base64
Content-ID: <part2.6149188C.8194FD1B@…>
Content-Disposition: inline; filename="….png"

…

--------------84789C173342F1615D0EC401--

--------------D478949D69471ABC8287B74F--

One approach would be to make all non-text parts available through the attachment list.

(I realize this message is somewhat broken, given that the text/plain part also ‘refers’ to a part of the multipart/related part.)
Comment 2 Justin Zobel 2022-11-10 22:32:44 UTC
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version?

If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Comment 3 Christoph Cullmann 2024-09-23 18:50:51 UTC
Trojitá is no longer maintained, please switch to a maintained alternative like https://apps.kde.org/kmail2/

Sorry for the inconveniences.