Multi-page / alternative subtype when the client uses it?

Question

Why do web clips (e.g. Gmail) send MIME messages using the multipart / alternative subtype (when compiled in HTML), while others send HTML as MIME with text / html particles inside (without using the alternative subtype)?

Answer 1

multipart/alternative indicates that each part is an "alternative" version of the same (or similar) content, each in a different format, indicated by the "Content-Type" header. The formats are ordered as far as they are true to the original, with the least true first and most true last.

Mail agents such as Gmail know what they are doing and convert text/html to text/plain and put both alternatives in emails and let the receiving end decide which alternative to use.

There are also mail agents who do not know how to extract a text version from html content, just because the developer did not bother to implement it, so they send text/html without any alternatives.

And sometimes - I call them crazy - send multipart/alternative , but actually just put the text / html without any alternatives. Which is not very nice, but it is not against any specification.

Answer 2

RFC 2046 Section 5.1.4 defines the multipart/alternative MIME type to allow the sender to provide different interchangeable views of the same message and leave it on the receiver to select the presentation form that is most suitable for its capabilities. Please note that although the general meaning of each view for the user must be preserved, there is usually some loss of information from one view to another (for example, text/plain no formatting information regarding text/html ). Alternatives should usually be ordered from the simplest to the richest, that is, if the alternatives are again text/html and text/plain , then text/plain should be the first. This helps users of non-MIME-compatible viewers who will initially display the easiest part to interpret. Generally, a MIME-compatible viewer should display the last view that it is able to view, since it is most preferred.

This type of content often contrasts with multipart/mixed when several different resources are combined in a single message.

The main reason some mail services provide messages is because multipart/alternative designed to support various types of receiving applications on the receiving side. For example, some viewers lack the ability to render HTML and require the text/plain view to be readable. At the same time, other viewers are able to display HTML and can provide a much better user interface when a message is sent as text/html . The most flexible compromise solution between supporting a wide range of viewers and improving the user experience for more capable ones is provided by providing both views wrapped in a multipart/alternative message.

See RFC 2046 for details.