Fix #5051 by always showing inline attachments in list of attachments

[bohwaz]

When a message has attachments with a Content-Id or a Content-Location, they are added as inline, expecting the attachment to show up in the message HTML body.

--==_=_650c1f3a7e07d-b7578f07ad
Content-Type: image/png; name="2023-09-21 12_35_30-XXXX Pierre (Membres actifs) - Chromium.png"
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="2023-09-21 12_35_30-XXX Pierre (Membres actifs) - Chromium.png"
Content-ID: <f_lmt1smiu1>

But, in some cases the attachments are not referred to in the HTML body.
And when you are viewing emails as plaintext only, you still won't see the attachments.

It's weird as the message is seen as having attachments in the messages list, but no attachments show up in the message view:

This patch always adds the inline attachment in the list of attachements, as is the case in most email software, so that you can see and download the attachments.

[alecpl]

What other email software? Thunderbird for example does not list such images as attachments when they are used in the HTML body. And I don't like a solution proposed here.

The discrepancy between list and preview is indeed an issue, but for performance reasons we don't do an extensive check on the message to find out whether there's a real attachment or not. We do a simple content-type check instead. I doubt this will change.

[bohwaz]

For now, the attachements are just hidden and the user experience is poor and confusing.

I checked with Zimbra, Claws Mail, GMail and Mutt, they all display the attachments and don't leave them hidden like Roundcube does.

[Neustradamus]

@alecpl: Any progressed on this @bohwaz PR?

Thanks in advance.

[bohwaz]

On my side, I'm using this patch in production since September with success :)

But it is annoying having to apply the patch after each update.

I'm considering pushing the patch in the Debian package if there is no progress here.

[Neustradamus]

Dear @roundcube team, @alecpl, @thomascube, @karlitschek, @nextcloud team: Can you look this PR done by @bohwaz which solves an imported ticket from 2012 (more 11 years and 3 months)?

Thanks in advance.

Linked to:

• Fix #5051 by always showing inline attachments in list of attachments #9150
• List unrefered inline images as attachments #5051
• E-mail attachments are not visible #6279
• Attachments without optional Content-Disposition headers are not visible in message view #7117
• Problem with replies to messages with attachments from Gmail #7122
• Attachments ignored if BODYSTRUCTURE does not contain content disposition (Mercury/32 server) #7214
• Problem with forwarding/replying to the messages containing multiple inline images. #7293
• Problem forwarding an email with jpg image attached received from iOS mail app #7414
• iPhone only email attachments wont forward #7440
• Apple Mail send image files marked as inline even if it is not on body message (#7414) #7441

[alecpl]

The proposed solution is wrong.

[bohwaz]

The proposed solution is wrong.

Why?

[alecpl]

Because it adds all inline attachments to the attachments list.

[bohwaz]

And how is that an issue?

[alecpl]

In Roundcube inline images (used in HTML content) aren't listed as attachments. It's been this way always. Precisely "Content-Disposition: inline" makes the message part a non-attachment. What to do with such parts could be discussed, but adding them to the attachments list is wrong. As I said before: Thunderbird for example does not list such images as attachments when they are used in the HTML body.

Unfortunately a better fix is not an easy fix.

[bohwaz]

Thunderbird is just one example, other MUA allow to list all attachments.

[bohwaz]

I don't see how giving users more control on the attached files is a bad thing?