>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 [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
