[EMAIL PROTECTED] (Gordon Burditt) wrote: >>>>But HTML is not the problem! >>> Right, it's what the HTML-interpreting engines might do that is >>> the problem. >> >>You mean the same problem as for example using a very long header in >>your email to cause a buffer overflow? That is possible with plain >>ASCII, and has been done. > > Before worrying about the possible bugs in the implementations, > worry about security issues present in the *DESIGN*.
You mean like email travels like plain text over the Internet? > Email ought > to be usable to carry out a conversation *SAFELY* with some person out > to get you. Thus features like this are dangerous (in the *design*, > not because they *might* hide a buffer-overflow exploit): > > - Hyperlinks to anything *outside* the email in which the link > resides ("web bugs"). Same holds for a link in plain ASCII > - Javascript. Is not HTML >>>>That is like hating all choirs because televangelists use them. >>>> >>>>HTML allows properly aligned table, diagrams, images, use of >>>>colour/fonts to encode speakers. emphasis, hyperlinks. > > The trouble is, it allows way too much dangerous stuff. Same with attachements, shall we remove those too? >>> All good stuff, but I don't like worrying about side effects when I >>> read email. >> >>Then you should ask people to print it out, and use snail mail. >>Exploits in email programs are not happening since HTML was added to >>them. > > Yes, they are. No, they are not. Buffer overruns with plain ASCII text have happened in the past. Dangerous attachements have been sent before HTML was available in email. > Why do you think people put "web bugs" in email? > Because they work. Same with attachements... -- John Small Perl scripts: http://johnbokma.com/perl/ Perl programmer available: http://castleamber.com/ I ploink googlegroups.com :-) -- http://mail.python.org/mailman/listinfo/python-list