On Mon, 2003-02-03 at 05:58, Shawn McMahon wrote: > On Mon, Feb 03, 2003 at 05:05:29AM -0800, Alexander Hvostov said: > > > > That's changing. Even venerable Pine can read HTML. > > Yes, by converting it back into text. What exactly have you gained in > that overhead? Not quite. It still wraps lines according to the width of the display, renders some text styles, and probably some other things. > > Digests should consist of a multipart message, where each part is a > > message/rfc822, containing one of the emails being digested. That avoids > > this problem nicely. This has several other useful benefits, as well. > > Right; and message/rfc822 parts contain text, not HTML. Actually they contain whatever you want -- including binary formats like images. > > And it was a fallacy. I understand the popular mail reader Pine is > > _full_ of remotely exploitable buffer overflows. > > So is Outlook Express, and most of the other popular proprietary MUAs. This implies that Pine is proprietary, which it is not. > What does that have to do with anything? Most folks here use Open > Source/Free Software email clients, not proprietary ones such as Pine or > Outlook Express. When did Pine become proprietary? What people use _here_ is not relevant. The point you made was that HTML renderers are gold mines of potential security holes, due to their complexity, and that, prior to the introduction of HTML mail, the GoodTimes virus was obviously impossible, for everyone, period. > > Interestingly, you forget to note that only Microsoft Outlook is > > affected by any of them. As much as you may think otherwise, this is an > > You're wrong. There have been ones that affected Netscape, such as > LoveLetter. That one would have affected ANY Windows MUA that allowed > use of Windows Scripting in HTML. Point taken. > I'm sure you'll argue now that this is a Windows problem, not an HTML > problem Holes in Windows Scripting are indeed Windows Scripting and/or MUA-specific problems. > but you're missing the point; HTML in email greatly increases > the complexity, and complexity breeds bugs. So do MIME and PGP; let's get rid of those while we're at it. Seriously, though, HTML renderers do not have to be especially complex if they don't need to handle things like forms and scripts. An SGML parser (or XML parser, if using XHTML) is obviously necessary, but these are libraries which can be reasonably expected to have been thoroughly debugged. > It doesn't greatly increase > the communications ability of email, so it makes no sense to put it in > there. People send email in HTML. Unless you'd prefer to ignore them (which you seem to, for some strange reason), you need to be able to read it. Also, as I said before, HTML gives you support for structured lists, tables, and images, which can be very useful under some circumstances. Alex. -- PGP Public Key: http://aoi.dyndns.org/~alex/pgp-public-key -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS d- s:++ a18 C++(++++)>$ UL+++(++++) P--- L+++>++++ E---- W+(+++) N- o-- K+ w--- !O M(+) V-- PS+++ PE-- Y+ PGP+(+++) t* 5-- X-- R tv b- DI D+++ G e h! !r y ------END GEEK CODE BLOCK------
Attachment:
signature.asc
Description: This is a digitally signed message part