Bug 233542

Created attachment 150711 [details]
Multipart e-mail containing both text/html and text/plain parts.

Look in

   Evolution Preferences -> Mail Preferences -> HTML Mail (tab)

What do you have selected in the "Plain Text Mode" section?

   Show HTML if present
   Prefer PLAIN
   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:
1.  General
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
release.

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
     first.

  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 [1] to track this issue.

[1] http://bugzilla.gnome.org/show_bug.cgi?id=451976

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.