[TriLUG] Preferring text/plain in multipart/alternative messages

[Tanner Lovelace]

On Tue, 2002-11-12 at 15:33, Mike Broome wrote:
> I don't know anything about configuring Evolution since I've never run
> it, but google coughed up this link to an e-mail on the evolution list
> 
>   http://lists.ximian.com/archives/public/evolution/2002-October/021969.html
> 
> which is from the beginning of October and unfortunately says that you
> can't tell Evolution to prefer a particular multipart/alternative
> section over another.  (Although it sounds like it is hard-coded to
> prefer text/html or text/enriched over text/plain.)

Okay, since I happened to have the evolution source (or at least
1.0.7) handy, I took a look at it.  They reference RFC 2046 which
in section 5.1.4 says:

   The "multipart/alternative" type is syntactically identical to
   "multipart/mixed", but the semantics are different.  In particular,
   each of the body parts is an "alternative" version of the same
   information.

   Systems should recognize that the content of the various parts are
   interchangeable.  Systems should choose the "best" type based on the
   local environment and references, in some cases even through user
   interaction.  As with "multipart/mixed", the order of body parts is
   significant.  In this case, the alternatives appear in an order of
   increasing faithfulness to the original content.  In general, the
   best choice is the LAST part of a type supported by the recipient
   system's local environment.

Apparently, the evolution authors have interpreted this as given
in this comment (in mail-format.c)

/* RFC 2046 says "display the last part that you are able to display".
*/

I don't agree with their interpretation, since it says "In general",
but that's their reasoning.  They do, however, have code to prefer
text/plain in the find_preferred_alternative function in the same
file.  However, in their handle_multipart_alternative function 
(also in the same file), they specifically call the
find_preferred_alternative function with a FALSE value for the
"want_plain" parameter.  (Or in english, for those who aren't
hardcore developers: they can do it, but it's hard coded in to
not prefer text/plain).

The good news is, however, that you should be able to recompile
evolution with the FALSE value changed to TRUE and have it
always display text/plain.  A better solution, however, would
be to figure out how to make it a configurable option.

Cheers,
Tanner
-- 
Tanner Lovelace | lovelace at wayfarer.org | http://wtl.wayfarer.org/
--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--
GPG Fingerprint = A66C 8660 924F 5F8C 71DA  BDD0 CE09 4F8E DE76 39D4
GPG Key can be found at http://wtl.wayfarer.org/lovelace.gpg.asc
--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--
          Si hoc legere scis, nimium eruditionis habes.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://www.trilug.org/pipermail/trilug/attachments/20021112/bdfa3900/attachment.pgp>