In plain sight

Even worse than the usual multipart/alternative messages with a contentless text/plain part are messages like that when there quite clearly is a text/plain version of the message (for example, as another option when you sign up for a list) but it’s not been included and this unhelpful “error” has been included. This annoys me: my text mode mail reader is perfectly capable of coping with both multipart/alternative and (via whatever run-mailcap gives it) text/html messages; the error here is entirely in the sending software. It should either include the text/plain version which the sender is already going to the trouble of producing as an alternative in a multipart message or just not bother with the alternative at all.

Given the general quality of implementation one finds the reasoning behind providing the alternative is probably that there’s some widely deployed piece of software out there which explodes horribly if it sees HMTL outside of a multipart/alternative wrapper. There are probably some users who are sufficiently keen on seeing the HTML version of the message to mean that they would actively wish to avoid using a plain version of it but there can’t be many – I expect the actual reasoning behind not putting it in is ease of implementation.