We have seen a number of attacks via e-mail that use text/html to carry
pointers to malicious code. We also had, many moons ago, a small war regarding
text/html versus application/html.
I propose the following straw man:
text/html be redefined such that it contains static content only.
application/html be redefined such that active content such as Javascript
be allowed.
This would allow MUAs that can parse html to employ whatever "sandbox"
techniques it wanted to on text/html, and more importantly, for the SENDING
MUA to be able to flag the intent - if the sender knows it's only static
content (using text/html as a text/enriched, for example), the sender will
know what restrictions will be placed at display time.
Conversely, if there IS active code, the sending MUA can flag this, and
be prepared to be sandboxed if the recipient wishes to do so.
There would probably have to be a restriction for the text/html variant on
what references would be acceptable on an embedded URL - possibly restricting
it to multipart/related with the same message-id:, so that you can't induce
a reference to a malicious webserver.
OK, there's a straw man. Get your matches out. ;)
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech
pgpK5cPf0jTjy.pgp
Description: PGP signature