HTML Email: Turn It Off!

HTML mail should be an act between consenting parties. Unless you know that you are sending writing to someone who does not mind HTML email, send plain text. There are many people who simply do not like to receive HTML email, others who find it to be a personal inconvenience, and others who must literally pay for the greater bandwidth consumed by HTML email. All of these considerations become particularly strong on newsgroups and mailing lists (with their great variety of participants from around the world), where the use of HTML email is often considered ignorant or rude.

Since HTML mail should be an act between consenting parties, we can quickly find three situations in which HTML email is acceptable.

You work in a business environment that accepts HTML email for internal communications.
You and an interlocutor have agreed (perhaps implicitly) that HTML email is acceptable in your communications. (Perhaps your interlocutor implies this by sending you HTML email.)
You have no other way to access the character set you require to communicate with someone using another language, and yet you wish to write that person.

In all other circumstances: TURN IT OFF! Sending unwanted HTML email signals that you are either ignorant or rude.

HTML Email Is Ignorant

The norms of internet communication are that email interaction takes place by means of plain text messages, except in the situations indicated above. Sometimes these norms are explicitly stated, but most of the time they are implicit. When you use HTML email, you indicate your ignorance of these norms. When you participate in email lists or newsgroups, you will quickly be informed of these norms. At that point the excuse of ignorance disappears.

If your excuse is that you have not learned how to turn off HTML in your email client, this is a different kind of ignorance that you can easily overcome: you can find online help, or you can ask a friend or colleague.

HTML Email Is Rude

Except in the situations indicated above, HTML email disregards the preferences of your interlocutor. Such disregard is of course rude. But that leaves open the question of why your interlocutor may prefer plain text. Here are a few possibilities.

I might be using an email reader that does not support HTML mail. Many people still prefer to use small, fast, text-only email agents.

I might be configuring my email reader to display text as I desire to see it. If you send plain text, I can configure my email agent to display this text as I desire. I can use the font, font-size, and color scheme that make it easy for me to read. If you send me HTML email, you will often force you formatting preferences upon me. Additionally, I will have to waste time adjusting to the new format, looking for the information that I care about in your email. So you have reduced my comfort in reading and you have wasted my time.

And that is not all. Many professional communications take place on email lists and in newsgroups. HTML email there acquires a different level of rudeness. First it violates the norms established for such interactions, and it is always rude to enter a group conversation without respecting its norms. Second, these norms are well founded: they are designed to save the participants time (as discussed above) and money. Many people still pay per minute to download their email over slow modems, especially if the communication is international in scope. If I must pay by the minute to download your needlessly bloated HTML email, you do not just cause me discomfort and waste my time—I have to pay real money for your rudeness. Finally, the bandwidth issues are particularly acute for people who read their news and email on a personal digital assitant, a practice that has become quite widespread.

But Where Is It Written … ?

Dislike of HTML email is so wide-spread and the drawbacks of HTML email are so well-known that it may seem surprising that there is no RFC addressing it directly. (Indeed, that lack was my motivation for writing this document.) The core reason, I surmise, is that the acceptability of HTML email depends on the environment in which it occurs, as discussed above. The arguments are not against HTML email per se, but against sending it to a recipient whom you do not know to consider it acceptable.

Nevertheless, RFC 1855 http://www.dtcc.edu/cs/rfc1855.html addresses internet standards for email, and it clearly presumes that plain text is the standard for email. Especially relevant are the request to limit bandwidth use, the suggestion to restrict the character set to ASCII and, related to this, the suggestion to use ASCII symbols to connote *emphasis* or _underlining_ in your text. (In an appendix, I quote a few pieces of RFC 1855 to make this point. However it should be clear that the arguments supplied above apply even if we disregard this RFC.)

Security Risk

This document focuses on why you should not send HTML mail. However, you should also be very careful about accepting HTML mail. Bulk emailers embed "web bugs" to determine whether your email address is valid. Smith and Martin 2001 note that it is also possible to embed JavaScript that will track forwarded HTML email and transmit any added text! This is known as "email wire tapping", and it is a very good reason for businesses to forbid the use of HTML mail. If you do decide to read an HTML email, make sure you first instruct your email client to turn off JavaScript and not to display external images. Also, do not forward the message, because you will forward any email bug or email wiretap to a recipient who may be less security conscious than you are. Good luck!

Efficient Communication

Many people who handle a lot of email assume HTML mail is spam and filter it on that assumption. As this practice becomes increasingly widespread, sending HTML mail becomes increasingly inefficient: your message will be postponed or even deleted because of its format.

Anyone who handles a lot of email should be concerned about efficiency in communication. Even if your own volume of email is small, you should still support efficiency in communication as a courtesy to your interlocutor. Some basic norms of email communication have evolved to promote this efficiency. Quoting practices are among these—especially selective quoting, interlineated responses, and standard quote indicators. These established practices again favor plain text over HTML mail for two reasons: plain text editors are more powerful and faster than HTML editors, and standard quote indicators are more likely to be handled intelligently by text editors.

An additional consideration is particularly important for people who handle large quantities of email and, correspondingly, for any newsgroup or email list. HTML mail reduces the useability of old mail archives. Search of text messages is much faster than search of HTML messages. (Similar considerations support selective quoting over indiscriminate quoting, since the latter leads to too many matches during archive searches.)

Selective quoting:

Selective quoting is both a courtesy and a communication device. Quote only the text that is relevant to your response. The quotation should be selective and to the point. Editing for selective quoting is much easier in plain text messages. If you communicate in plain text, you can speed up your own response and assist any responding reader of your email.

Interlineated responses:

When responding to more than one comment in an initial email, standard practice is to place each response after a relevant section of quoted text. This allows the reader to more easily see how the conversation is taking place: the response is adjacent to the text responded to. Editing for interlineated responses is much easier in plain text messages.

Standard quote indicators:

The most widespread standard is to use a greater than sign (>) for each level of quotation. For example

>> This text was quoted in the email I am responding to.

> This was original text in the email I am responding to.

This is my response to the two quotes.

All modern email agents will correctly nest standard quote indicators in plain text messages. Note how the level of quotation is indicated not only by the standard quotation scheme (i.e., by the use of >) but also by the color of the text, which makes it very easy to see the structure of the message. All modern email agents will colorize plain text in response to the standard quotation scheme. This is yet another courtesy to your reader that you can provide, if you stick to plain text in your email.

Comment: users of webmail and of older email agents cannot expect the helpful colorizing of text in response to the standard quoting practices. However the quote indicators still provide the same information about the structure of the message.

Conclusion

HTML mail can be useful in specific settings. Groups of people can reasonably agree to use HTML for their email communications. However HTML email can impose costs in lost readability, reduced convenience, higher bandwidth use, and reduced security. Therefore the use of HTML should be restricted to consenting parties, where it is understood that consent can be given implicitly as discussed above.

Resources

Appendix: Quotes from RFC 1855

Use symbols for emphasis. That *is* what I meant. Use underscores for underlining. _War and Peace_ is my favorite book.
This of course presumes ASCII mail, not HTML mail.
Do not include control characters or non-ASCII attachments in messages unless they are MIME attachments or unless your mailer encodes these.
HTML of course has no such character set restriction and cannot be presumed to.
Limit line length to fewer than 65 characters and end a line with a carriage return. This of course presumes ASCII mail and is generally violated by HTML mail. The line length restriction may seem dated, but in fact many email clients will wrap at 70 characters and a slightly shorter line-length allows for the standard quoting conventions (e.g., >).
Remember that many people pay for connectivity by the minute, and the longer your message is, the more they pay.
As discussed above, HTML mail is always much longer than the ASCII equivalent (at least for European nations). One reason for this is that a text copy of the mail is always included with HTML email, because some email clients do not read HTML. Another reason is that the HTML codes require bandwidth. Finally, often HTML email will include graphics, which are usually unwanted by the recipient (as well as being a security risk).
'Reasonable' expectations for conduct via e-mail depend on your relationship to a person and the context of the communication. Norms learned in a particular e-mail environment may not apply in general to your e-mail communication with people across the Internet.
It is a norm on most active email lists and on most active newsgroups that only ASCII mail shall be posted.

Document Topics

HTML Email: Whenever Possible, Turn It Off!