| Author: | Alan G. Isaac |
|---|---|
| Copyright: | http://creativecommons.org/licenses/by-nd/2.0/ |
| First posted: | 2002 Feb 15 |
| Last modified: | 2013 May 14 |
| Text version: | https://subversion.american.edu/aisaac/notes/htmlmail.rst |
| HTML version: | https://subversion.american.edu/aisaac/notes/htmlmail.htm |
Abstract
HTML email can impose costs on the recipient. Therefore HTML mail should be an act between consenting parties. Unless you know that you are writing to someone who does not mind HTML email, send plain text. If you do use HTML mail, be aware of the security dangers.
First consider a matter of email etiquette. There are many people who prefer not to receive HTML email: some find it to be a personal inconvenience, and others must literally pay for the greater bandwidth consumed by HTML email. 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. It is therefore a basic courtesy to refrain from sending HTML email except to those who wish to receive it.
Since HTML mail should be an act between consenting parties, we can quickly find three situations in which HTML email is acceptable.
In all other circumstances: TURN IT OFF!
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 (e.g., as posting guidelines for a newsgroup), 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.
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.
Many professional communications take place on email lists and in newsgroups. In such settings, HTML email can be especially rude. First it generally 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.
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 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.)
This document focuses on why you should not send HTML mail. However, you should also be very careful about accepting HTML mail.
HTML email contains commands to be executed by your email client: when you read HTML email you let the sender give commands to your computer. Some of these commands can be used maliciously to exploit common security holes. This can expose you to spam, computer viruses, and worms. On Windows machines, if you enable ActiveX, HTML email can directly infect your computer (without your opening an attachment). Bulk emailers embed web bugs to determine whether your email address is valid, making you more vulnerable to spam. [Smith-and-Martin-2001] note that HTML email can also 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. In 2006, the JTF-GNO reported that for security reasons the Department of Defense is blocking HTML email.
If you do decide to read an HTML email, make sure you do not enable ActiveX, and 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!
Many people who handle a lot of email assume HTML mail is spam and filter it on that assumption. Some commercial spam filtering schemes also treat HTML mail as more likely to be spam. As these practices 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 three reasons: many email clients cannot correctly handle HTML mail when attempting to produce standard quote indicators, 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 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.
Be sure to distinguish quotes from other text in your email.
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.
Many heavy users of email believe that anything other than interlineated responses constitutes a discourtesy. "Top posting" is especially disliked. Unfortunately some email clients promote top posting and fail to use standard quote indicators.
The most widespread standard is to use a greater-than sign (>) for each level of quotation. For example:
Tip
All modern email clients will correctly nest standard quote indicators in plain text messages. The level of quotation is indicated by the standard quotation scheme (i.e., by the use of >), and generally also by the color of the text, which makes it very easy to see the structure of the message. All modern email clients will colorize plain text in response to the standard quotation scheme (unless the reader prefers to turn this off). This is yet another courtesy to your reader that you can provide, if you stick to plain text and the standard quotation indicator in your email.
Users of webmail and of older email clients cannot always 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.
Note that when more than two people are involved in an email exchange, it is important as well to indicate the author of the quote. Standard practice is to do this immediately above the quoted text.
Tip
Proposals for incorporating such information in HTML email are often complicated and there is no widely implemented standard.
Two common non-commercial reasons for choosing to send HTML mail are
Images can be included as attachments, and in most cases should be. (Of course the decision to send no images is often a good one too.) Visually emphasized text can be achieved by using a standard and widely accepted trivial markup: asterisks imply emphasized text, underscores imply _underlined text_, slashes imply /italicized text/, capital letters imply BOLD TEXT, quotation marks are used to indicate "quoted text", and paragraphs are separated by a blank line.
Trivial Markup is a very courteous way to markup text. If your interlocutor wishes this markup to affect the color or size of the displayed text, s/he can use an email client that supports visual formatting of trivial markup. Note that this leaves the display decision up to the reader, which is a natural courtesy.
In the rare case that an email needs mark up beyond that offered by the Trivial Markup conventions, consider reStructuredText.
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 and accessibility, 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.
Boyd, G., Configuring Mail Clients to Send Plain ASCII Text (E.g., in Outlook you can select the menus Tools/Options/MailFormat and select "Plain Text" for your message format.)
Cottrell, Allin, 1999, Word Processors: Stupid and Inefficient (Last accessed: 2004 Nov 30)
Delorie, D.J., 1999, Why HTML Mail Is Evil
Gibson, Steve, 2004, The GRC Privacy FAQ: What's a Web Bug?
Goldberg, Jeff, 2003, MS-Word Is Not a Document Exchange Format
Hahn, Harley, How to Turn Off HTML in Your Outgoing Mail Messages
Hambridge, S., 1995, RFC 1855: Netiquette Guidelines
Isaac, Alan G., 2003, ASCII and Latin-1 Coded Character Sets
Nolte, Mike, HTML-Mail ist gefährlich und schädlich
Oakes, Chris, Word Docs with Ears? Wired, 31 Aug 2000. Last accessed: 30 Nov 2004.
Resnick, P., 2001, RFC 2822: Internet Message Format
RootsWeb, Problem Solving: Sending Messages in Plain Text
Smith, Richard M., undated, FAQ: Web Bugs Last accessed at the Privacy Foundation on 11 April 2003. (Document missing as of late 2004.)
| [Smith-and-Martin-2001] | http://www.privacyfoundation.org/privacywatch/report.asp?id=54 Last accessed at the Privacy Foundation on 11 April 2003. (Document missing as of late 2004.) |
Tobias, Dan, Body: HTML Mail (Last access: 2007-03-30)
Vermeer, Martin, plaintext: In Praise of Practical Email Hygiene (Difficult to access as of 2004.)
This appendix offers some quotes from RFC 1855 that suggest that email is presumed to be plain text. (This is for fun and context rather than for serious argument.)
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.