Roundcube is showing both HTML and plain text versions of emails

[stratoss]

Prerequisites

• I have searched for duplicate or closed issues
• I can recreate the issue with all plugins disabled

Describe the issue

Sample e-mail:

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

--boundary1
Content-Type: text/plain; charset="UTF-8"

This is the plain text content.

--boundary1
Content-Type: text/html; charset="UTF-8"

This is the HTML content.

--boundary1--

Latest version of roundcube shows both versions. I've temporarily fixed it by switching the default $parse_alternative from false to true in rcube_message.php.

What browser(s) are you seeing the problem on?

Chrome, Edge, Firefox, Safari

What version of PHP are you using?

v8.2

What version of Roundcube are you using?

v1.6.9

JavaScript errors

No response

PHP errors

No response

[alecpl]

I'm unable to reproduce in the release-1.6 branch. I don't see any unreleased changes in rcube_message in this branch. So, I suspect it's something external.

I tested with PHP 8.1. Could you enable imap_debug and provide the log? Also, what plugins?

[stratoss]

I've tried without any plugins, to exclude them as a potential cause. The key is multipart/alternative. I've tried on other Roundcube instances (with older versions) - the bug is persistent.

[syspir]

I have the same thing, it's terrible, will you do anything about it?

[gomanuke]

Just got exactly the same after migrating to Debian 12 (php 8.2.26) without any changes in configuration of RC 1.6.10
Mail body attached

Body.zip

[gomanuke]

$parse_alternative = true

really works. Thanks!

[alecpl]

Works for me with PHP 8.2.27. All of you guys on Debian?

[gomanuke]

Debian 11, 12

[stratoss]

I've tried with Debian 11 and Windows Server. All problematic e-mails are multipart/alternative. Roundcube is without any plugins, the same email is properly rendered with all major e-mail providers plus Thunderbird.