Dangerous HTML emails only come from viruses, worms, or malicious people. You cannot unintentionally harm others' computers or invade their privacy just by sending an HTML email. 

Bad people and broken parts can make cars to do bad things. That should not prevent good people from responsibly using a car. The same goes for HTML email.

This anti-HTML email argument is a logical error of composition. It is assumed that because some HTML emails can be dangerous, all HTML emails are dangerous. It is incredibly unlikely that an end user with no malicious intent can create a dangerous HTML email.

Downloading 200 typical HTML email messages on a 40Kb/s modem connection only takes 50 seconds! Even if your connection is slower, nobody is forcing you to do nothing but watch the status indicator during the whole download. You can read messages before everything is downloaded.

For the rapidly growing pool of broadband users, downloading 200 HTML messages is effortless and quick. Legitimate HTML email on corporate networks is hardly a bandwidth concern for network administrators.

Finally, bandwidth is not a scarce commodity. Contrary to the argument, the only wasted bandwidth is bandwidth that is not used.

This anti-HTML email argument is a logical error of insignificance. The anti-HTML argument is as if the bandwidth consumed by legitimate HTML emails [i.e., non-spam, non-virus/worm generated] is a huge issue. While HTML email consumes more bandwidth than plain text, the extra bandwidth of legitimate HTML email is hardly a concern for the ever-growing pool of users on broadband and corporate networks. The extra bandwidth is a minor burden to modem users.

Even with Microsoft's excessive and redunant HTML markup, a 10KB plain text email only becomes 14KB when converted to HTML.

Since the the anti-HTML argument completely false, this anti-HTML argument is a logical error of non-support.

HTML email works fine on modern email clients.

Since the vast majority of email clients support HTML well, this anti-HTML argument is a logical error of non-support.

On my "two years behind the times computer," Outlook XP renders a large HTML email with two embedded JPG images so quickly that I can't even time it with a stopwatch.

For the vast majority of users, this anti-HTML argument is a logical error of non-support.

Most email clients just reuse HTML browser technology already installed on your computer to display HTML email.

This anti-HTML email argument is a logical error of composition. It is assumed that because some email clients have been bloated with redundant HTML rendering capabilities, all email clients are bloated. In fact, the vast majority of email users have installed products that reuse other components on the system (IE or Mozilla) to render the actual email.

It would take over 1,000,000 typical HTML emails to fill a 10GB hard drive. That is what you would accumulate if you downloaded 200 messages every day for 14 years and never deleted a single message.

The least expensive Dell computer (as of 1-9-04) had a 40 GB hard drive.

The anti-HTML email argument is a logical error of insignificance. The anti-HTML argument is that the additional size of HTML emails is unacceptable. Modern computers can easily handle the modest additional size of typical HTML email. Large HTML emails could easily be because of legitimately beneficial features. For example, in an email asking about rust repair a person may use inline photographs to illustrate a rust spot on a car.

The same reasoning wouldn't allow air conditioning in cars because air conditioners were originally designed for buildings.

The anti-HTML email argument is a logical error of a false dilemma because only two options are implied: 1. use X&Y together if they were designed for each other, or 2. do not use X&Y together because they were not designed for each other. Worthwhile innovations often come from harmoniously combining two things that were not designed for each other.

HTML email is as reader-friendly as the author wants to be. Just because some users misuse HTML to make trashy-looking messages does not mean that every message is that way. If you don't like someone's trashy formatting, then ask him to stop being trashy.

Banning HTML email under this premise would be as moronic as banning all legitimate drugs because a few people abuse them.

This anti-HTML email argument is a logical error of composition. It is assumed that because some HTML email users create trashy emails, all HTML emails are not reader friendly. The vast majority of HTML email users compose clean messages.

All emails are self-contained, and there is nothing about HTML email that requires them to leave droppings around your computer. If any external images are loaded in the process of viewing the email, then the images are put in the browser's cache and managed just like any other image loaded by your browser.

If you find HTML-email related droppings, it is because you are running a poorly-written email client.

For the vast majority of users, the anti-HTML argument is a logical error of non-support. A long time ago poorly written email clients could leave unwanted files, but this is no longer the case.

Many spammers use English. Does that make English bad?

The anti-HTML email argument is a logical error of a false analogy: since many spammers use HTML and the ensuing email is undesirable, then if you use HTML email the ensuing email is also undesirable.

Modern list serving programs can put HTML emails into digests just fine.

But digests themselves are an old fashioned, outdated way of reducing inbox clutter. They were most useful when email clients dumped all email in the inbox, giving users no way to filter messages into subfolders. Modern email clients can organize incoming email with filters or rules, directing all list messages to special folders, and free email services like Google Mail automatically organize emails into threads.

Users with poor sight already use assistive technology to read web sites. Putting the same HTML in an email makes it inaccessible?

This anti-HTML email argument is a logical error of non-support.

A spam filter that tosses HTML emails would be useless and unmarketable.

This anti-HTML email argument is probably a logical error of non-support. Are there any spam filters that automatically toss HTML emails? Are there any spam filters for which there is a meaningfully higher probability of causing false positives just because an email is encoded in HTML?

Several vendors' email clients support HTML email: Microsoft, Mozilla, AOL, Netscrape, Eudora, Pegasus Mail, Lotus, etc.

HTML email is a harmonious combination of HTML and email standards. Just because this harmonious combination has not been technically approved by a public rulemaking body (e.g., IETF, IEEE, ANSI, W3C) does not mean it is illegitimate, nor does it reduce its usefulness. Furthermore, it is questionable why this would need to be "approved" by anyone. HTML email is not a new standard.

The anti-HTML email argument is a logical error of a false dilemma because only two options are implied: 1. something is legitimate if it is a standard ratified by a public body, or 2. something is illegitimate because it is not a standard ratified by a public body. These are not the only legitimate forms of a standard.