Cannot download attachment for some multipart/mixed messages with base64-encoded jpg images

[sebastka]

Hello,

We have an issue where pictures sent from a phone (presumably iPhone) to an e-mail address by Telenor DK will not be downloadable from Roundcube. The webmail will show the paperclip icon, indicating there is an attachment, but it won't be displayed when opening the message, nor will it allow the user to download it. See Example 1. The same message opened in Thunderbird will show correctly and the attachment will be downloadable.

We have produced a similar example (Example 2) of a picture sent from an iPhone to an e-mail address using Telenor Norway, where Roundcube does show the attachment correctly.

Is this a bug in Roundcube?

1. Example 1: Not OK - Cannot download attachment

   
   Message-Id: <XXXXXXXXXXXXX@mx01.lytzenitmail.dk>
   Date:Mon, 06 May 2024 15:24:47 +0200
   From: <+45XXXXXXXX@telenor.dk>
   To: XXXXXX@jubii.dk
   Subject: Not OK
   Mime-Version:1.0
   Content-Type:multipart/mixed;boundary="--------------------------------------------=_NextPart_0_24856"

this is a multi-part message in MIME format.

----------------------------------------------=_NextPart_0_24856 Content-Type:image/jpeg; name="Resized_20240427_200026(1).jpeg" Content-Transfer-Encoding:base64 Content-Location:Resized_20240427_200026(1).jpeg Content-ID:<Resized_20240427_200026(1)>

iVBORw0KGgoAAAANSUhEUgAAAQAAAAEACAIAAADTED8xAAADMElEQVR4nOzVwQnAIBQFQYXff81R UkQCOyDj1YOPnbXWPmeTRef+/3O/OyBjzh3CD95BfqICMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0C MK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0C MK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0C MK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0C MK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0C MK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0C MK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0C MK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0C MK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0C MK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0C MK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0C MK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0C MK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0C MK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMO0TAAD//2An hf4QtqobAAAAAElFTkSuQmCC

----------------------------------------------=_NextPart_0_24856--

<img src="https://github.com/roundcube/roundcubemail/assets/35309144/f0043d51-7a4b-4cc2-9fd7-342bf5a34e9b" width="500">

2. **Example 2**: OK - Can download attachment
```text
Content-Type: multipart/mixed; boundary=1_663B4185_194FAEF8
Date: Wed, 08 May 2024 09:10:29 GMT
To: XXXXXXXXXX@corp.inbox.com
Subject: OK
From: 47XXXXXXXX@mms.mnc001.mcc242.gprs
Mime-Version: 1.0

--1_663B4185_194FAEF8
Content-Type: image/jpeg;Name=IMG_0639.jpg
Content-Disposition: Attachment;Filename=IMG_0639.jpg
Content-ID: 0
Content-Location: IMG_0639.jpg
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAAQAAAAEACAIAAADTED8xAAADMElEQVR4nOzVwQnAIBQFQYXff81R
UkQCOyDj1YOPnbXWPmeTRef+/3O/OyBjzh3CD95BfqICMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0C
MK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0C
MK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0C
MK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0C
MK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0C
MK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0C
MK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0C
MK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0C
MK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0C
MK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0C
MK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0C
MK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0C
MK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0C
MK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMK0CMO0TAAD//2An
hf4QtqobAAAAAElFTkSuQmCC
--1_663B4185_194FAEF8--

[pabzm]

The relevant difference is that the broken version's attachment mime-structure doesn't have a Content-Disposition-header. After adding that the message gets shown as expected.

We'll have to check if/how to fix this.

[pabzm]

Related: #7117, #5905

[alecpl]

Related to #5051. At least in this specific case we can more easily detect that the message has no html part so any images should be treated as non-inline.

[pabzm]

Currently the image in the "Not OK" email is considered an inline image by Roundcube. I fiddled with some code in program/actions/mail/show.php to make it display the image, but maybe a more general approach to handle "dangling" images would be better.

Also I figured that some code probably relates to concrete edge cases, like is_attachment() – because for a general check this is too specific. Changing that code without tests checking these edge cases is too dangerous for my taste.

@alecpl Do you have some kind of test corpus of emails to check against? I started to extend TestCases in order to check the correct rendering of emails (will open a PR later).

[alecpl]

I agree that fixing this kind of issues properly might involve quite a big refactoring. There's no easy bugs in this tracker ;).