I use mutt and unfortunately in the corporate world you can't just ignore HTML or even HTML only mails. I pipe them to elinks, works 99.9% of the time easily.
> HTML email is not merely an HTML file sent by email – it is the email.
I'm not sure if the semantic distinction makes sense. An attached file in an email is the also the email. Both HTML, images, and other content types are all sent in the same manner in the body of the email.
> Both HTML, images, and other content types are all sent in the same manner in the body of the email.
This is not the case. In the case of an attachment, the message body is multipart/mixed, where one part is the actual message the sender typed and other parts are the attachments. In the case of an HTML email, the message body is multipart/alternative, where the parts are two or more representations of the actual message typed by the user.
If what you were saying were true, you wouldn’t be able to send an HTML document as an attachment to an email without it being interpreted as the message typed by the user. There is a clear difference between an attachment and the message itself; HTML email is the message itself, not an attachment.
> In the case of an attachment, the message body is multipart/mixed, where one part is the actual message the sender typed and other parts are the attachments.
This is not correct. In multipart/mixed you can have any number of body parts with any mixture of content types, including sub nested multipart/mixed body parts. There is nothing that separates a "message" from an "attachment" except for presence of a content disposition header.
> If what you were saying were true, you wouldn’t be able to send an HTML document as an attachment to an email without it being interpreted as the message typed by the user.
Indeed, old email clients may not understand mime formatting formating which is why it is recommended that in a multipart/alternative body you should have the plaintext body part first since the entire body will be displayed.
The only reason why a HTML document, that is a body part of a multipart/mixed message, should not be displayed as part of that message is if it has at content disposition header.
There is no clear difference between "message" and "attachment" in the email format spec. Those two categories come from how email clients represent the presence or absence of a content disposition header.
The the text/html content type was not indeed not explicitly part of the mime type standard, but it was a standard that was explicitly designed to be extensible.
It was intended that subtypes of "text" would be human readable as raw data. If HTML emails aren't human readable without piping into an external program and aren't a multipart/alternative type with the plaintext version first, then it is very reasonable to complain that the sender is doing a bad job.
