HTML email

Last updated

HTML email is the use of a subset of HTML to provide formatting and semantic markup capabilities in email that are not available with plain text: [1] Text can be linked without displaying a URL, or breaking long URLs into multiple pieces. Text is wrapped to fit the width of the viewing window, rather than uniformly breaking each line at 78 characters (defined in RFC 5322, which was necessary on older text terminals). It allows in-line inclusion of images, tables, as well as diagrams or mathematical formulae as images, which are otherwise difficult to convey (typically using ASCII art).

Contents

Adoption

Most graphical email clients support HTML email, and many default to it. Many of these clients include both a GUI editor for composing HTML emails and a rendering engine for displaying received HTML emails.

Since its conception, a number of people have vocally opposed all HTML email (and even MIME itself), for a variety of reasons. [2] For instance, the ASCII Ribbon Campaign advocated that all email should be sent in ASCII text format. The campaign was unsuccessful and was abandoned in 2013. [3] [4] 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. [5]

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. [6] The majority of users prefer to receive HTML emails over plain text. [7] [8]

Compatibility

Email software that complies with RFC 2822 is only required to support plain text, not HTML formatting. Sending HTML formatted emails can therefore lead to problems if the recipient's email client does not support it. In the worst case, the recipient will see the HTML code instead of the intended message.

Among those email clients that do support HTML, some do not render it consistently with W3C specifications, and many HTML emails are not compliant either, which may cause rendering or delivery problems.

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 in-line style declarations are inefficient and fail to take good advantage of HTML's ability to separate style from content.[ citation needed ] Although workarounds have been developed, [9] this has caused no shortage of frustration among newsletter developers, spawning the grassroots Email Standards Project, which grades email clients on their rendering of an Acid test, inspired by those of the Web Standards Project, and lobbies developers to improve their products. To persuade Google to improve rendering in Gmail, for instance, they published a video montage of grimacing web developers, [10] resulting in attention from an employee.

"Email standards project" Acid test comparison (as of January 2013) Archived 6 December 2017 at the Wayback Machine
ClientsResult (as of)
AOL Webmail Solid support (13 July 2011)
Apple iPhone Solid support (13 July 2011)
Apple iPad
Apple iPod Touch
Apple Mail Solid support (28 November 2007)
Apple MobileMe Solid support (15 August 2008)
Eudora
Eudora OSE codenamed "Penelope"
Solid support (28 November 2007)
Microsoft Entourage Solid support (28 November 2007)
Mozilla Thunderbird Solid support (28 November 2007)
Windows Live Mail Solid support (28 November 2007)
Windows Mail Solid support (28 November 2007)
Yahoo! Mail BetaSolid support (8 July 2011)
Windows Live Hotmail Some improvement recommended (8 July 2011)
Google Gmail Improvement recommended (13 July 2011)
Lotus Notes 8Improvement recommended (28 November 2007)
Microsoft Outlook 2007Improvement recommended (28 November 2007)

Style

Some senders may excessively rely upon large, colorful, or distracting fonts, making messages more difficult to read. [11] For those especially bothered by this formatting, some user agents make it possible for the reader to partially override the formatting (for instance, Mozilla Thunderbird allows specifying a minimum font size); however, these capabilities are not globally available. Further, the difference in optical appearance between the sender and the reader can help to differentiate the author of each section, improving readability.

Multi-part formats

Many email servers 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 email clients, using the Content-Type: multipart/alternative , as specified in RFC 1521. [12] [13] [14] 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. The plain text version may be missing important formatting information, however. (For example, a mathematical equation may lose a superscript and take on an entirely new meaning.)

Many[ citation needed ] mailing lists deliberately block HTML email, either stripping out the HTML part to just leave the plain text part or rejecting the entire message.[ citation needed ]

The order of the parts is significant. RFC1341 states that: In general, user agents that compose multipart/alternative entities should place the body parts in increasing order of preference, that is, with the preferred format last. [15] For multipart emails with html and plain-text versions, that means listing the plain-text version first and the html version after it, otherwise the client may default to showing the plain-text version even though an html version is available.

Message size

HTML email 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. [16]

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 email servers through slow modems), on a modern connection the difference is negligible for most people, especially when compared to images, music files, or other common attachments. [17]

Security vulnerabilities

HTML allows a link to be hidden, but shown as any arbitrary text, such as a user-friendly target name. This can be used in phishing attacks, in which users are fooled into accessing a counterfeit web site and revealing personal details (like bank account numbers) to a scammer.

If an email contains inline content from an external server, such as a picture, retrieving it requires a request to that external server which identifies where the picture will be displayed and other information about the recipient. Web bugs are specially created images (usually unique for each individual email) intended to track that email and let the creator know that the email has been opened. Among other things, that reveals that an email address is real, and can be targeted in the future.

Some phishing attacks rely on particular features of HTML: [18]

Displaying HTML content frequently involves the client program calling on special routines to parse and render the HTML-coded text; deliberately mis-coded content can then exploit mistakes in those routines to create security violations.[ citation needed ] Requests for special fonts, etc, can also impact system resources.[ citation needed ]

During periods of increased network threats, the US Department of Defense has converted user's incoming HTML email to text email. [19]

The multipart type is intended to show the same content in different ways, but this is sometimes abused; some email 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 (that which is displayed to the user).

Most email spam is sent in HTML[ citation needed ] for these reasons, so spam filters sometimes give higher spam scores to HTML messages.[ citation needed ]

In 2018 a vulnerability (EFAIL) of the HTML processing of many common email clients was disclosed, in which decrypted text of PGP or S/MIME encrypted email parts can be caused to be sent as an attribute to an external image address, if the external image is requested. This vulnerability was present in Thunderbird, macOS Mail, Outlook, and later, Gmail and Apple Mail. [20]

See also

Related Research Articles

<span class="mw-page-title-main">Email</span> Mail sent using electronic means

Email is a method of transmitting and receiving messages using electronic devices. It was conceived in the late–20th century as the digital version of, or counterpart to, mail. Email is a ubiquitous and very widely used communication medium; in current use, an email address is often treated as a basic and necessary part of many processes in business, commerce, government, education, entertainment, and other spheres of daily life in most countries.

In computing, the Internet Message Access Protocol (IMAP) is an Internet standard protocol used by email clients to retrieve email messages from a mail server over a TCP/IP connection. IMAP is defined by RFC 9051.

Multipurpose Internet Mail Extensions (MIME) is a standard that extends the format of email messages to support text in character sets other than ASCII, as well as attachments of audio, video, images, and application programs. Message bodies may consist of multiple parts, and header information may be specified in non-ASCII character sets. Email messages with MIME formatting are typically transmitted with standard protocols, such as the Simple Mail Transfer Protocol (SMTP), the Post Office Protocol (POP), and the Internet Message Access Protocol (IMAP).

In computing, the Post Office Protocol (POP) is an application-layer Internet standard protocol used by e-mail clients to retrieve e-mail from a mail server. Today, POP version 3 (POP3) is the most commonly used version. Together with IMAP, it is one of the most common protocols for email retrieval.

The Simple Mail Transfer Protocol (SMTP) is an Internet standard communication protocol for electronic mail transmission. Mail servers and other message transfer agents use SMTP to send and receive mail messages. User-level email clients typically use SMTP only for sending messages to a mail server for relaying, and typically submit outgoing email to the mail server on port 587 or 465 per RFC 8314. For retrieving messages, IMAP is standard, but proprietary servers also often implement proprietary protocols, e.g., Exchange ActiveSync.

<span class="mw-page-title-main">Signature block</span> Type of personalized block

A signature block is a personalized block of text automatically appended at the bottom of an email message, Usenet article, or forum post.

<span class="mw-page-title-main">Email client</span> Computer program used to access and manage a users email

An email client, email reader or, more formally, message user agent (MUA) or mail user agent is a computer program used to access and manage a user's email.

<span class="mw-page-title-main">Apple Mail</span> Email client by Apple Inc.

Mail is an email client included by Apple Inc. with its operating systems macOS, iOS, iPadOS, watchOS, and visionOS. Mail grew out of NeXTMail, which was originally developed by NeXT as part of its NeXTSTEP operating system, after Apple's acquisition of NeXT in 1997.

An email address identifies an email box to which messages are delivered. While early messaging systems used a variety of formats for addressing, today, email addresses follow a set of specific rules originally standardized by the Internet Engineering Task Force (IETF) in the 1980s, and updated by RFC 5322 and 6854. The term email address in this article refers to just the addr-spec in Section 3.4 of RFC 5322. The RFC defines address more broadly as either a mailbox or group. A mailbox value can be either a name-addr, which contains a display-name and addr-spec, or the more common addr-spec alone.

S/MIME is a standard for public-key encryption and signing of MIME data. S/MIME is on an IETF standards track and defined in a number of documents, most importantly RFC 8551. It was originally developed by RSA Data Security, and the original specification used the IETF MIME specification with the de facto industry standard PKCS #7 secure message format. Change control to S/MIME has since been vested in the IETF, and the specification is now layered on Cryptographic Message Syntax (CMS), an IETF specification that is identical in most respects with PKCS #7. S/MIME functionality is built into the majority of modern email software and interoperates between them. Since it is built on CMS, MIME can also hold an advanced digital signature.

<span class="mw-page-title-main">Pegasus Mail</span> Proprietary email client

Pegasus Mail is a proprietary email client for Microsoft Windows. It was originally released in 1990 on NetWare networks with MS-DOS and later Apple Macintosh clients, before being ported to Windows which is now the only platform actively supported. Since its inception it has been developed by David Harris and is donationware after having previously been freeware.

An email attachment is a computer file sent along with an email message. One or more files can be attached to any email message, and be sent along with it to the recipient. This is typically used as a simple method to share documents and images.

MHTML, an initialism of "MIME encapsulation of aggregate HTML documents", is a Web archive file format used to combine, in a single computer file, the HTML code and its companion resources that are represented by external hyperlinks in the web page's HTML code. The content of an MHTML file is encoded using the same techniques that were first developed for HTML email messages, using the MIME content type multipart/related. MHTML files use an .mhtml or .mht filename extension.

Many email clients now offer some support for Unicode. Some clients will automatically choose between a legacy encoding and Unicode depending on the mail's content, either automatically or when the user requests it.

Enriched text is a formatted text format for email, defined by the IETF in RFC 1896 and associated with the text/enriched MIME type which is defined in RFC 1563.

DomainKeys Identified Mail (DKIM) is an email authentication method designed to detect forged sender addresses in email, a technique often used in phishing and email spam.

In information and communications technology, a media type, content type or MIME type is a two-part identifier for file formats and content formats. Their purpose is comparable to filename extensions and uniform type identifiers, in that they identify the intended data format. They are mainly used by technologies underpinning the Internet, and also used on Linux desktop systems.

<span class="mw-page-title-main">Feedback loop (email)</span> Process of forwarding user complaints to senders

A feedback loop (FBL), sometimes called a complaint feedback loop, is an inter-organizational form of feedback by which a mailbox provider (MP) forwards the complaints originating from their users to the sender's organizations. MPs can receive users' complaints by placing report spam buttons on their webmail pages, or in their email client, or via help desks. The message sender's organization, often an email service provider, has to come to an agreement with each MP from which they want to collect users' complaints.

The Abuse Reporting Format (ARF) also known as the Messaging Abuse Reporting Format (MARF) is a standard format for reporting spam via email.

<span class="mw-page-title-main">EFAIL</span> Email security vulnerability

Efail, also written EFAIL, is a security hole in email systems with which content can be transmitted in encrypted form. This gap allows attackers to access the decrypted content of an email if it contains active content like HTML or JavaScript, or if loading of external content has been enabled in the client. Affected email clients include Gmail, Apple Mail, and Microsoft Outlook.

References

  1. "Text Email vs HTML Email – The Pros and Cons | Thunder Mailer – Mass Emailing Software". thundermailer.com. Retrieved 30 January 2016.
  2. HTML Email: Whenever Possible, Turn It Off!
  3. "The Ascii Ribbon Campaign official homepage". Archived from the original on 11 March 2010. Retrieved 30 January 2016.
  4. "Shutdown of the ASCII ribbon campaign – Pale Moon forum". forum.palemoon.org. Archived from the original on 3 February 2016. Retrieved 30 January 2016.
  5. 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 1990s)
  6. "Email Marketing Statistics and Metrics – EmailLabs". 29 March 2007. Archived from the original on 29 March 2007. Retrieved 30 January 2016. HTML has nearly universal adoption among consumers: A Jupiter Research consumer survey found just 3% receive only text email.
  7. Grossman, Edward (9 July 2002). "Real-World Email Client Usage: The Hard Data | ClickZ". clickz.com. Retrieved 30 January 2016. Do you prefer receiving HTML or text email? HTML: 41.95%, Text: 31.52%, No preference: 26.53%
  8. "The Science of Email Marketing". slideshare.net. Retrieved 30 January 2016. In what format do you prefer to receive email messages from companies? HTML: 88%, Plain text: 12%
  9. Dialect <http://dialect.ca/>. "Premailer: make CSS inline for HTML e-mail". Premailer.dialect.ca. Retrieved 24 June 2012.{{cite web}}: External link in |author= (help)
  10. "The 2008 Gmail Appeal | Email Standards Project". Email-standards.org. Archived from the original on 15 May 2012. Retrieved 24 June 2012.
  11. Shobe, Matt (12 October 2004). "A pretty fair argument against HTML Email". Burningdoor.com. Archived from the original on 24 April 2012. Retrieved 24 June 2012.
  12. RFC 1521 7.2.3. The Multipart/alternative subtype
  13. "TN1010-11-2: Multipart/Alternative – Gracefully handling HTML-phobic email clients" (PDF). Retrieved 24 June 2012.
  14. "Sending HTML and Plain Text E-Mail Simultaneously". Wilsonweb.com. 28 April 2000. Retrieved 24 June 2012.
  15. "RFC1341 Section 7.2 The Multipart Content-Type" . Retrieved 15 July 2014.
  16. "Do we really want to send web pages in e-mail?". Dsv.su.se. Retrieved 24 June 2012.
  17. HTML Email – Still Evil?
  18. "Trend-spotting email techniques: How modern phishing emails hide in plain sight". Microsoft.com. 18 August 2021.
  19. "DOD bars use of HTML e-mail, Outlook Web Access". nextgov.com. 22 December 2006. Retrieved 22 June 2024.
  20. "Decade-old Efail flaws can leak plaintext of PGP- and S/MIME-encrypted emails". arstechnica.com. 14 May 2018.