- HTML e-mail
HTML e-mail is the use of a
subset ofHTML (often ill-defined) to provide formatting and semantic markup capabilities ine-mail that are not available withplain text .Most graphical
e-mail client s support HTML e-mail, and many default to it. [ [http://www.expita.com/nomime.html#programs Configuring Mail Clients to Send Plain ASCII Text] — E-mail client programs] Many of these clients include both aGUI editor for composing HTML e-mails and a rendering engine for displaying received HTML e-mails.HTML mail allows the sender to properly express quotations (as in inline replying), headings, bulleted lists, emphasized text,
subscript s andsuperscript s, and other visual andtypographic cues to improve the readability and aesthetics of the message, as well as semantic information encoded within the message, such as the original author and Message-ID of a quote. Long URLs can be linked to without being broken into multiple pieces, and text is wrapped to fit the width of the user agent's viewport, instead of uniformly breaking each line at 78 characters (defined in RFC 2822, which was necessary on older text terminals). It allows in-line inclusion oftable s, as well as diagrams ormathematical formula e as images, which are otherwise difficult to convey (typically usingASCII art ).Adoption
Since its conception, a number of people have vocally opposed all HTML e-mail (and even
MIME itself), for a variety of reasons. While still considered inappropriate in many newsgroup postings and mailing lists, its adoption for personal and business mail has only increased over time. Some of those who strongly opposed it when it first came out now see it as mostly harmless. [ [http://birdhouse.org/blog/2006/01/15/html-email-the-poll/ HTML Email: The Poll] (Scot Hacker, originator of the much-linked-to "Why HTML in E-Mail is a Bad Idea" discusses how his feelings have changed since the 90s)]According to surveys by
online marketing companies, adoption of HTML-capable email clients is now nearly universal, with less than 3% reporting that they use text-only clients. [http://www.emaillabs.com/resources/resources_statistics.html Email Marketing Statistics and Metrics] ] A smaller number, though still the majority, prefer it over plain text. [http://www.clickz.com/showPage.html?page=1428551 Real-World Email Client Usage: The Hard Data] ]Compatibility
As HTML mail is more complex than plain text, it is also more prone to compatibility issues and has problems with rendering consistently across platforms and software.
Some popular clients do not render consistently with
W3C specifications, and many HTML e-mails are not compliant, either, which may cause rendering or delivery problems, especially for users ofMSN orHotmail . [http://www.emaillabs.com/resources/resources_statistics.html Email Marketing Statistics and Metrics] ]In particular, the
tag, which is used to house CSS style rules for an entire HTML document, is not well supported, sometimes stripped entirely, causing in-line style declarations to be the "de facto" standard, even though they are not optimal from a semantic web point of view. [ [http://www.yourtotalsite.com/archives/online_marketing/not_your_ordinary_html_em/Default.aspx Not your ordinary html email tips] ] Although workarounds have been developed, [ [http://code.dunae.ca/premailer.web/ Premailer: make CSS inline for HTML e-mail] ] this has caused no shortage of frustration among newsletter developers, spawning thegrassroots [http://www.email-standards.org/ Email Standards Project] , acid test which grades email clients on their rendering of an acid test, inspired by those of theWeb Standards Project , and lobbies developers to improve their products. [ [http://www.campaignmonitor.com/blog/archives/2007/09/why_we_need_web_standards_supp_1.html Campaign Monitor: Why we need standards support in HTML email] ] To persuadeGoogle to improve rendering inGmail , for instance, they published [http://www.email-standards.org/gmail-appeal a video montage of grimacing web developers] , resulting in attention from an employee.Style
Some senders may excessively rely upon large, colorful, or distracting
font s, making messages more difficult to read. [ [http://www.burningdoor.com/matt/archives/000782.html A pretty fair argument against HTML Email] ] Those who especially dislike certain types of formatting can override them in theiruser agent while still seeing other formatting and getting the other benefits of HTML. For instance,Mozilla Thunderbird makes it easy to specify a minimum font size.Multi-part formats
The default e-mail format according to RFC 2822 is plain text. Thus e-mail software isn't required to support HTML formatting. Sending HTML formatted e-mails can therefore lead to problems at the recipient's end if it's one of those clients that don't support it. The recipient may see the HTML source code or nothing at all.
Many e-mail clients are configured to automatically generate a plain text version of a message and send it along with the HTML version, to ensure that it can be read even by text-only
e-mail client s, using theContent-Type: multipart/alternative
, as specified in RFC 1521. [ [http://www.yahoo.com/CIE/RFC/1521/18.htm RFC 1521 7.2.3. The Multipart/alternative subtype] ] [ [http://www.codestone.ltd.uk/software/docs/csmail/tn1010-11-2.pdf TN1010-11-2: Multipart/Alternative — Gracefully handling HTML-phobic email clients.] ] [ [http://www.wilsonweb.com/wmt5/html-email-multi.htm Sending HTML and Plain Text E-Mail Simultaneously] ] The message itself is of typemultipart/alternative
, and contains two parts, the first of typetext/plain
, which is read by text-only clients, and the second withtext/html
, which is read by HTML-capable clients. The plain text version may be missing important formatting information, however. (For example, an equation may lose a superscript and take on an entirely new meaning.)Many mailing lists deliberately block HTML e-mail, either stripping out the HTML part to just leave the plain text part or rejecting the entire message.
Message size
HTML e-mail is larger than plain text. Even if no special formatting is used, there will be the overhead from the tags used in a minimal HTML document, and if formatting is heavily used it may be much higher. Multi-part messages, with duplicate copies of the same content in different formats, increase the size even further. The plain text section of a multi-part message can be retrieved by itself, though, using
IMAP 's FETCH command. [ [http://dsv.su.se/jpalme/ietf/mhtml-discussion.html Do we really want to send web pages in e-mail?] ]Although the difference in download time between plain text and mixed message mail (which can be a factor of ten or more) was of concern in the 1990s (when most users were accessing e-mail servers through slow
modem s), on a modern connection the difference is negligible, especially when compared to images, music files, or other common attachments. [ [http://momentum.insertdisc.com/archives/2004/09/17/html_email_still_evil_part_1.html HTML Email — Still Evil?] ]Security vulnerabilities
HTML allows for a link to have a different target than the link's text. This can be used in
phishing attacks, in which users are fooled into believing that a link points to the website of an authoritative source (such as a bank), visiting it, and unintentionally revealing personal details (like bank account numbers) to a scammer.If an e-mail contains
web bug s (inline content from an external server, such as a picture), the server can alert a third party that the e-mail has been opened. This is a potential privacy risk, revealing that an e-mail address is real (so that it can be targeted in the future) and revealing when the message was read. For this reason, some e-mail clients do not load external images until requested to by the user.During periods of increased network threats, the US Department of Defense converts all incoming HTML e-mail to text e-mail. [ [http://www.fcw.com/article97178-12-22-06-Web/ DOD bars use of HTML e-mail, Outlook Web Access] ]
The multipart type is intended to show the same content in different ways, but this is sometimes abused; some
e-mail spam takes advantage of the format to trickspam filter s into believing that the message is legitimate. They do this by including innocuous content in the text part of the message and putting the spam in the HTML part (which is what displays to the user).Most e-mail spam is sent in HTML for these reasons, so spam filters sometimes give higher spam scores to HTML messages.
See also
*
Enriched text — an HTML-like system for e-mail using MIME
*MHTML References
External links
* [http://mailformat.dan.info/body/html.html Dan's Mail Format Site]
* [http://dsv.su.se/jpalme/ietf/mhtml.html Using HTML in E-mail]
* [http://www.w3.org/TR/1998/NOTE-HTMLThreading-0105 HTML Threading: Conventions for use of HTML in email]
* [http://www.expita.com/nomime.html Configuring Mail Clients to Send Plain ASCII Text] — Argues that HTML (and MIME in general) should never be used in mail
* [http://home.earthlink.net/~bobbau/email/avoiding-html/ Configuring Your E-mail Software to Avoid Sending HTML-formatted Messages]
* [http://birdhouse.org/etc/evilmail.html Why HTML in E-Mail is a Bad Idea] (written in the late 90s)
** [http://birdhouse.org/etc/html_mail_counter.html Rebuttal]
** [http://birdhouse.org/blog/2006/01/15/html-email-the-poll/ HTML Email: The Poll] — January 2006 poll and comments on whether the original document is still relevant
* [http://www.georgedillon.com/web/html_email_is_evil_still.shtml HTML e-mail is STILL evil!!!]
* [http://www.evolt.org/article/HTML_Email_Isn_t_Rich/25/53732/ HTML Email Isn't Rich] (2003)
* [http://dsv.su.se/jpalme/ietf/mhtml-discussion.html Do we really want to send web pages in e-mail?]
* [http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0000Pb&topic_id=1 HTML in Email] — Ask E.T. Forum (2003)
* [http://www.campaignmonitor.com/blog/archives/2006/03/a_guide_to_css_support_in_emai.html A Guide to CSS Support in Email] (2006, [http://www.campaignmonitor.com/blog/archives/2007/04/a_guide_to_css_support_in_emai_2.html updated in 2007] )
* [http://www.andybudd.com/archives/2007/04/css_support_in_email_clients_still_pretty_poor/ Andy Budd's blog discussion regarding CSS in MUAs]
Wikimedia Foundation. 2010.