[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] Message with repeated content

From: Ken Hornstein
Subject: Re: [Nmh-workers] Message with repeated content
Date: Thu, 05 Jun 2014 10:46:23 -0400

>I am attaching (not forwarding) a message which repeats exactly the same
>content, once as 'Content-Type: text/plain; charset=UTF-8' and once as
>'Content-Type: text/html; charset=UTF-8'. mhshow ignores the first, so it must
>somehow realize that the two contents are identical. I prefer that when the
>two contents are identical mhshow ignore the text/html and use the text/plain.

Be prepared for another long explanation :-)

That message uses a MIME type known as multipart/alternative.  Rather
than give one of my potentially confusing explanations, let me quote from
RFC 2046, ยง5.1.4:

   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

   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.

   "Multipart/alternative" may be used, for example, to send a message
   in a fancy text format in such a way that it can easily be displayed


So this is a multipart/alternative, with a text/plain part first and a
text/html part second.  And before you mention it ... yes, nmh shows
the text/html part as being first if you look at it with mhlist.  I'll
explain why in a moment.

First, nmh isn't figuring out that the parts are the same; it's just using
multipart/alternative handling.  The way that's implemented in nmh (this
is all inherited from the original MIME support in MH) is that it reverses
the ordering for parts in a multipart/alternative MIME part, tries to
display each part starting from the first part, and if it finds a handler
for the requested MIME type it will use it and simply not display the
other alternative parts.  This is one of those things that make mhshowsbr.c
such a mess.

So what's happening here is mhshow is looking at the MIME parts, and
trying to display the text/html part.  You now have a text/html content
handler, so it uses that part and doesn't display the text/plain part.
If you didn't have a text/html content handler, it would silent skip it
and just display the text/plain part.

So, that I hope explains what's going on now.  To address your other

>In practice, is this situation sufficiently rare that I can forget about it?

Well, I suppose it depends on who you email.  For me, it is VERY common.
I would say the large majority of non-nmh and non-spam email I receive
is multipart/alternative with text/plain and text/html parts.  Certainly
that's the default with most Microsoft email, and for webmail places
like gmail.

>If not, how can I tell mhshow to ignore the text/html instead of the
>text/html, when the two contents are identical and mhshow knows that?

It's not easy.

I've often thought about adding the capability to mhshow to list preferred
multipart/alternative MIME types; exmh has that capability and I love it.
But it would involve rototilling the whole mess that is the
multipart/alternative MIME handling, and I haven't had the energy yet.

The simplest way might be to invoke mhshow with an alternate profile
(using the MHSHOW environment variable) that does not include a text/html
content type handler; that would make it fall back to the text/plain part.
That would require you to know beforehand that it's a multipart/alternative
so thats not wonderful.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]