Jargons of Info Tech industry

[Gordon Burditt]

>>>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