HTML Email: Whenever Possible, Turn It Off!
===========================================
:Author: Alan G. Isaac
:Copyright: http://creativecommons.org/licenses/by-nd/2.0/
:First posted: 2002 Feb 15
:Last modified: 2006 Dec 25
:Text version: http://www.american.edu/econ/notes/htmlmail.rst
:HTML version: http://www.american.edu/econ/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.
1. You work in a business environment that accepts HTML email for
internal communications.
2. 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.)
3. 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!**
HTML Email Looks 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 (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.
HTML Email Looks 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 may have a visual disability or another reason to need
audio translation of my email. (HTML mail is much harder for such
tranlators to handle correctly.)
- I might be using an email reader that does not support HTML mail.
Many people still prefer to use small, fast, text-only email clients.
- I might be configuring my email reader to display text as I
desire to see it. This reason is the most important, and it
highlights the common courtesy of relying on plain text for email
communication. If you send plain text, I can configure my email
client 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. (In principle email readers could allow the
use of reader style sheets to override author formatting choices
in HTML mail that itself relied on CSS, but this does not seem
possible with existing practices.) 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.
- I might have to pay for bandwidth when I retrieve my email, and HTML
messages consume much more bandwidth than plain text.
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. Such bandwidth issues
can be acute for people who read their news and email on a
personal digital assitant, a practice that has become quite
widespread.
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.
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`_ 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.
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!
Efficient Communication
-----------------------
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
^^^^^^^^^^^^^^^^^
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.
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.
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.
Standard quote indicators
^^^^^^^^^^^^^^^^^^^^^^^^^
The most widespread standard is to use a greater-than sign (>)
for each level of quotation. For example:
.. tip::
.. class:: colorgreen
| >> This text was quoted in the email I am responding to.
.. class:: colorblue
| > This was original text in the email I am responding to.
| This is my response to the two quotes.
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::
.. class:: colorblue
| > On 31 January 2010, Sam wrote:
.. class:: colorgreen
| >> This text was quoted in the email I am responding to.
| On 1 February 2010, Sara wrote:
.. class:: colorblue
| > This was original text in the email I am responding to.
| This is my response to the two quotes.
Proposals for incorporating such information in HTML email are often complicated_
and there is no widely implemented standard.
Trivial Markup
^^^^^^^^^^^^^^
Two common non-commercial reasons for choosing to send HTML mail are
i. the desire to include images, and
ii. the desire to add visually formatted emphasis to text.
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_.
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 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.
Resources
---------
`ASCII Ribbon Campaign`__
__ http://arc.pasp.de/
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.)
__ http://www.expita.com/nomime.html
Cottrell, Allin, 1999,
`Word Processors: Stupid and Inefficient`__
(Last accessed: 2004 Nov 30)
__ http://www.ecn.wfu.edu/~cottrell/wp.html
Delorie, D.J., 1999,
`Why HTML Mail Is Evil`__
__ http://www.delorie.com/listserv/mime/
Gibson, Steve, 2004,
`The GRC Privacy FAQ: What's a Web Bug?`__
__ http://grc.com/faq-privacy.htm#webbug
Goldberg, Jeff, 2003,
`MS-Word Is Not a Document Exchange Format`__
__ http://www.goldmark.org/netrants/no-word/attach.pdf
Hahn, Harley,
`How to Turn Off HTML in Your Outgoing Mail Messages`__
__ http://www.harley.com/turn-off-html/
Hambridge, S., 1995,
`RFC 1855: Netiquette Guidelines`_
Isaac, Alan G., 2003,
`ASCII and Latin-1 Coded Character Sets`__
__ http://www.american.edu/econ/notes/ailatin1.htm
Nolte, Mike,
`HTML-Mail ist gefährlich und schädlich`__
__ http://www.nolte-buerotechnik.de/keinhtmlinemails.html
Oakes, Chris,
`Word Docs with Ears?`__
Wired, 31 Aug 2000.
Last accessed: 30 Nov 2004.
__ http://www.wired.com/news/technology/0,1282,38516,00.html
Resnick, P., 2001,
`RFC 2822: Internet Message Format`_
RootsWeb,
`Problem Solving: Sending Messages in Plain Text`__
__ http://helpdesk.rootsweb.com/listadmins/plaintext.html
Smith, Richard M., undated,
`FAQ: Web Bugs`__
Last accessed at the Privacy Foundation on 11 April 2003.
(Document missing as of late 2004.)
__ http://www.privacyfoundation.org/resources/webbug.asp
.. [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)
__ http://mailformat.dan.info/body/html.html
Vermeer, Martin,
`plaintext: In Praise of Practical Email Hygiene`__
(Difficult to access as of 2004.)
__ http://www.netby.dk/Oest/Europa-Alle/vermeer/plain.html
.. _web bugs: http://grc.com/faq-privacy.htm#webbug
_`Appendix`: Quotes from RFC 1855
---------------------------------
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.
.. _complicated: http://www.w3.org/TR/1998/NOTE-HTMLThreading-0105
.. _posting guidelines for a newsgroup: http://www.opera.com/support/resources/posting-suggestions.html
.. _online help: http://expita.com/nomime.html
.. _reStructuredText: http://docutils.sourceforge.net/docs/user/rst/quickref.html
.. _RFC: http://www.rfc-editor.org
.. _RFC 1855: http://www.rfc-editor.org/rfc/rfc1855.txt
.. _RFC 1855\: Netiquette Guidelines: `RFC 1855`_
.. _RFC 2822: http://www.rfc-editor.org/rfc/rfc2822.txt
.. _RFC 2822\: Internet Message Format: `RFC 2822`_
.. _spam: http://www.spamhaus.org/index.lasso
.. _JTF-GNO: http://en.wikipedia.org/wiki/Joint_Task_Force-Global_Network_Operations
.. _blocking HTML email: http://www.fcw.com/article97178-12-22-06-Web