Wikipedia

HTML email

This is an old revision of this page, as edited by Omegatron (talk | contribs) at 03:22, 21 September 2006 (Reverted edits by 142.179.125.54 (talk) to last version by Omegatron). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

HTML email is the use of a subset of HTML (often ill-defined) to provide formatting and semantic markup capabilities in email that are not available with plain text.

Most graphical e-mail clients support HTML email, and many default to it.[1] Many of these clients include both a GUI editor for composing HTML e-mails and a rendering engine for displaying received HTML e-mails.

HTML mail allows the sender to properly express headings, bulleted lists, emphasized text, subscripts and superscripts, and other visual and typographic cues to improve the readability and aesthetics of the message. 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 data terminals). It allows in-line inclusion of diagrams or mathematical formula as images, which are otherwise difficult to convey (typically using ASCII art).

Since its conception, a number of people have vocally opposed all HTML email (and even MIME itself), for a variety of reasons. While still considered inappropriate in newsgroup postings and most mailing lists, its adoption for personal and business mail has only increased over time. Some of those who opposed it vehemently when it first came out now see it as mostly harmless.[2]

Compatibility

According to surveys by online marketing companies, the vast majority of Internet users can access HTML mail, and a smaller number, though still the majority, prefer it over plain text.[3][4] As HTML mail is more complex than plain text, however, it is also more prone to compatibility issues and problems with rendering consistently across platforms and software.

Some popular email clients do not render consistently with W3C specifications, and many HTML emails are not compliant, either, which may cause rendering or delivery problems, especially for users of MSN or Hotmail.[3]

In particular, the <head> 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.[5]

Many HTML-based GUI email clients automatically convert common plain text characters, like - and ", into their proper typographic equivalents, like — and “, which are not part of 7-bit ASCII. This can cause translation problems in other users' clients.[citation needed] Unicode supports many such complex characters, but font support issues with Unicode limit the usefulness of this possibility.

Style

Some senders may excessively rely upon large, colorful, or distracting fonts, making messages more difficult to read.[6] Those who especially dislike certain types of formatting can override them in their user 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

Many email clients are configured to send a plain text version of a message along with the HTML version, to ensure that it can be read even by text-only clients, using the Content-Type: multipart/alternative, as specified in RFC 1521.[7][8][9] The message itself is of type multipart/alternative, and contains two parts, the first of type text/plain, which is read by text-only clients, and the second with text/html, which is read by HTML-capable clients.

A few recipients have e-mail clients that cannot display HTML. This may be mitigated by the inclusion of an automatically generated plain text version, but this may be missing important formatting information (e.g. 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.[10]

Download speed was more of a concern in the 1990s, though, when most users were accessing email servers through slow modems. On a modern connection, the difference in download time between plain text and mixed message mail, even though it can be a factor of ten or more, is negligible, especially when compared to images, music files, or other common attachments.[11]

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 email contains inline content from an external server, such as an image, the server can alert a third party that the e-mail has been opened. This is a potential privacy risk, revealing that an email 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.

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 trick spam filters 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 (such as Spamassassin) give higher spam scores to HTML messages.[citation needed]

References

  1. ^ Configuring Mail Clients to Send Plain ASCII Text — E-mail client programs
  2. ^ 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)
  3. ^ a b Email Marketing Statistics and Metrics
  4. ^ Real-World Email Client Usage: The Hard Data
  5. ^ Not your ordinary html email tips
  6. ^ A pretty fair argument against HTML Email
  7. ^ RFC 1521 7.2.3. The Multipart/alternative subtype
  8. ^ TN1010-11-2: Multipart/Alternative — Gracefully handling HTML-phobic email clients.
  9. ^ Sending HTML and Plain Text E-Mail Simultaneously
  10. ^ Do we really want to send web pages in e-mail?
  11. ^ HTML Email — Still Evil?
Retrieved from "https://en.wikipedia.org/w/index.php?title=HTML_email&oldid=76919487"