User: Password:
|
|
Subscribe / Log in / New account

The real killer is HTML

The real killer is HTML

Posted Jun 29, 2004 21:19 UTC (Tue) by nix (subscriber, #2304)
In reply to: The real killer is HTML by ssavitzky
Parent article: The Grumpy Editor's guide to graphical mail clients

Nothing wrong with rendering HTML: the problem is rendering images (and other external objects that involve touching the network) in that HTML.


(Log in to post comments)

The real killer is HTML

Posted Jun 29, 2004 21:50 UTC (Tue) by bfields (subscriber, #19510) [Link]

> Nothing wrong with rendering HTML: the problem is
> rendering images (and other external objects that
> involve touching the network) in that HTML.

Well, this is a different issue, but I also do worry
about the complexity of the processing that is triggered
when reading a mail (usually from someone I don't trust).
HTML adds a bit more--can you be positive that someone
can't overflow some buffer by, e.g., sending you mail
with some bizarre set of nested tables?

The real killer is HTML

Posted Jun 29, 2004 22:04 UTC (Tue) by Ross (guest, #4065) [Link]

I disagree. HTML is very complicated and there are numerous places for
security problems. Things like Javascript have absolutely no business in
email. Plugins certainly don't belong. Images don't either (they are all
remote... how do you insert an image into HTML?).

In fact there are so many inappropriate features in HTML that I wish Netscape
had standardized a subset which would understood enough to be safe rather
than just force the web into our mailboxes. Actually there would be no point
to stick with HTML (though a markup language would have been best). It
should have been very minimal. No exectable code, remote data, hidden links
or text, or display outside of the message area should have been allowed.
Even comments are suspect in my book. And besides security concerns I wish
blinking text, fonts over 18 points tall, and overly-contrasting colors
had been banned :)

The real killer is HTML

Posted Jun 29, 2004 22:36 UTC (Tue) by bastiaan (guest, #5170) [Link]

FYI, images need not be remote in HTML mail: you can add the images as attachment and refer to them from within the HTML. In fact Evolution has a configuration setting which allows you to either show all, some or no remote images in the mail you receive.

The real killer is HTML

Posted Jun 29, 2004 22:42 UTC (Tue) by Ross (guest, #4065) [Link]

That's interesting. What does an image tag which refers to an attachment
look like?

The real killer is HTML

Posted Jun 29, 2004 22:52 UTC (Tue) by bastiaan (guest, #5170) [Link]

You insert an IMG tag like this:
<IMG SRC="cid:1088549203.3067.4.camel@email.example.com" ALIGN="top" ALT="test" BORDER="0">

And add an attachment to your message with the corresponding content-id:

Content-ID: <1088549203.3067.4.camel@email.example.com>
Content-Disposition: attachment; filename=001_star_butterfly.png
Content-Type: image/png; name=001_star_butterfly.png
Content-Transfer-Encoding: base64

iVBORw0.....

The real killer is HTML

Posted Jul 9, 2004 4:30 UTC (Fri) by xoddam (subscriber, #2322) [Link]

And there's another way: Attachments with a 'Content-Location:' header (which can specify any kind of URI) get priority over the remote resource which would otherwise be fetched from the specified location.

But OTOH it would be easy to omit to implement this part of the MHTML spec and allow your mail client to fetch http: or ftp: URLs despite their being provided as attachments.

The real killer is HTML

Posted Jun 29, 2004 22:47 UTC (Tue) by jwb (guest, #15467) [Link]

Images in HTML mails are not "all remote". You can attach an image in the MIME structure of the mail, and you can reference that image using a url with the cid: scheme.

The real killer is HTML

Posted Jun 30, 2004 15:16 UTC (Wed) by iabervon (subscriber, #722) [Link]

For that matter, executable code, hidden links and text, and display outside of the message area should be prohibited in web browsers as well. Why should the web be any less safe than our mailboxes?

I think HTML really ought to have three levels of functionality: non-interactive documents, documents you interact with in browser-controlled ways (forms), and documents with executable portions (scripts). Only the first of these should count as "text/html", since the others do not fit the definition of "text/*". Probably there ought to be MIME media types added for "form" and "script" (and, while we're at it "style").

HTML isn't really all that complicated if you force documents to be non-interactive, particularly now that experience with XML parsers has elucidated the proper representation for parsed documents. (SGML/HTML being essentially XML damaged in recoverable ways, and parsable by an XML parser that's willing to be not too picky)


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds