>>>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*. 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").
- Javascript.
- Any ability to automatically generate hits on sender-specified
servers when the email is read.
- Any kind of return-receipt mechanism that doesn't require initiation
by the recipient.
- Any kind of return-receipt mechanism that indicates that the
message got past the spam filter.
>>>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.
>> 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. Why do you think people put "web bugs" in email?
Because they work.
>>>I try to explain Java each day both on my website on the plaintext
>>>only newsgroups. It is so much easier to get my point across in HTML.
>
Gordon L. Burditt
--
http://mail.python.org/mailman/listinfo/python-list
