Description of problem:
When reading a multipart e-mail containing both text/html and text/plain parts,
the text/plain part is always displayed. Despite searching the preference
screens and the documentation, I was unable to find any way to display the
text/html part of the e-mail.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Read the attached multipart e-mail message in Evolution.
Only the text/plain part is displayed.
The text/html part should be displayed, as in Outlook.
Created attachment 150711 [details]
Multipart e-mail containing both text/html and text/plain parts.
Evolution Preferences -> Mail Preferences -> HTML Mail (tab)
What do you have selected in the "Plain Text Mode" section?
Show HTML if present
Only ever show PLAIN
Does selecting "Show HTML if present" help?
I believe something has been discovered. There is no "Plain Text Mode" section
on the "HTML Mail" tab. There are only two sections there:
2. Loading Images
Try enabling the "Prefer plain-text" plugin under Edit -> Plugins.
All plugins are enabled, and there is no "Prefer plain-text" plugin in the list.
Huh, that's strange. I see the plugin on Fedora Core, but not on RHEL 5.
This is not a new plugin, and they all should've been built into the package.
Perhaps there are other missing plugins as well.
I'll investigate this further...
It seems this particular plugin was reclassified from 'experimental' to
'standard' during the 2.9 development cycle. This happened in November of last
year, after RHEL 5 was feature frozen. We don't build the 'experimental'
plugins into RHEL because they're considered unstable.
The bad news is I know of no other way to get Evolution to do what you want.
The good news is no changes to the plugin were made between the RHEL 5 feature
freeze and when it got reclassified as 'standard', so if it's stable today then
it's also stable in RHEL 5. So perhaps I can get this enabled for 5.1.
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
Created attachment 158131 [details]
Multipart e-mail with text/html and text/plain parts swapped
There seems to be more to this bug than just the absence of that plugin, though
I'm still going to get the plugin included in RHEL 5.1. I have several other
multipart messages containing both plain text and HTML for which Evolution
displays the HTML part by default. So I took a closer look at these messages
and compared them with the above message (attachment #150711 [details]) and found a
couple differences in the structure of the message:
1) In the messages for which the HTML part is displayed, the text/plain
part comes first. In the attachment above, the text/html part comes
2) The attachment above contains extraneous MIME boundaries.
Here is a revised version of the message wherein I swapped the text/html and
text/plain parts and also removed the extraneous MIME boundaries. If you
import this into Evolution you should find that the HTML part is displayed.
The latest upstream release (Evolution 2.11.3) also exhibits the behavior I
described in comment #10. Therefore I'll have to fix this issue upstream first
and then hopefully I can just backport the patch to RHEL5.
I've opened an upstream bug  to track this issue.
Having investigated this further, it has become apparent that fixing this
properly will require too intrusive of a change to Evolution for RHEL.
Therefore I'm not going to fix this bug in RHEL, but I *will* pursue this upstream.
Here are my findings:
- In the strictest interpretation of the MIME standard (RFC 1521),
Evolution is not at fault here. The MUA that composed the message
in comment #1 is not following the standard.
Section 7.2.3 on the multipart/alternative subtype states:
"In general, user agents that compose multipart/alternative
entities must place the body parts in increasing order of
preference, that is, with the preferred format last. For
fancy text, the sending user agent should put the plainest
format first and the richest format last. RECEIVING USER
AGENTS SHOULD PICK AND DISPLAY THE LAST FORMAT THEY ARE
CAPABLE OF DISPLAYING." (emphasis mine)
- The standard does, however, allow for some flexibility:
It may be the case that some user agents, if they can recognize
more than one of the formats, will prefer to offer the user the
choice of which format to view. This makes sense, for example,
if mail includes both a nicely-formatted image version and an
easily-edited text version.
In my view, this is what the "Prefer plain-text" plugin is doing;
offering the user the choice of which format to view. And this is
the gist of the upstream bug I filed. It should try harder to honor
the user's preference for viewing HTML or plain text even if the
message is not entirely standard compliant.
Unfortunately, making this happen will require redesigning the
"Prefer plain-text" plugin as well as parts of the core mailer.
And that's just not an option for including in a RHEL5 update.
Development Management has reviewed and declined this request. You may appeal
this decision by reopening this request.