From: John Stracke <francis(_at_)ecal(_dot_)com>
The practice of sending both HTML and cleartext of supposedly the same
message reflects very poorly on those who do it intentionally and on those
who cause MUA's to trick others into doing it unintentionally. Never mind
the security issues, but consider only the wastes of disk space, CPU
processing, network bandwidth, and the inevitable differences between the
two versions. If the two messages were the same, then there would be no
excuse for sending both. If they differ, then one must be wrong, and
sending both is worse than a waste.
So why does multipart/alternative exist?
Perhaps in theory, it exists for the reasons implied by RFC 2046,
especially the last part of section 5.1.4 or in the scenario described
in RFC 1766. There are also RFC 2447 and RFC 2532. They all seem to
involve situations where the two messages are not identical, but the
having a wrong version is better than none at all and which cannot
be predicted in order to avoid the waste.
However, most of the vast quantity of objective evidence implies
that multipart/alternative exists so that people can look stupid
and technically incompetent by sending plaintext with HTML that
when rendered looks practically identical to the plaintext.
The remaining evidence implies that multipart/alternative exists
to trick unwary recipients into rendering HTML containing things
they would be wise to not let their computers evaluate, starting
with porn (with all of its modern legal dangers) and tricky URLs
(e.g. the concrete example recently displayed here), and continuing
to other things with significant security problems.
When was the last time you received a multipart/alternative message that
did not make the sender look stupid, malicious, or both? I can't remember
ever receiving any other kind of multipart/alternative. Maybe that's
why so many competent people apologize when they realize they've been
tricked by a MUA into sending visually identical HTML and plaintext.
Vernon Schryver vjs(_at_)rhyolite(_dot_)com