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
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.
"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
anywhere:
[...]
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
questions:
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.
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers