HTML email

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. For instance, the ASCII Ribbon Campaign advocated that all email should be sent in ASCII text format. Proponents placed ASCII art in their signature blocks, meant to look like an awareness ribbon, along with a message or link to an advocacy site. The campaign was unsuccessful and was abandoned in 2013. While still considered inappropriate in many newsgroup postings and mailing lists, HTML 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. 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. The majority of users prefer to receive HTML emails over plain text. == 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 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. Although workarounds have been developed, 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, resulting in attention from an employee. == Style ==

Some senders may excessively rely upon large, colorful, or distracting fonts, making messages more difficult to read. 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. 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 mailing lists deliberately block HTML email, either stripping out the HTML part to just leave the plain text part or rejecting the entire message. 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. 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. 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. == 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: • Brand impersonation with procedurally-generated graphics (such graphics can look like a trademarked image but evade security scanning because there is no file) • Text containing invisible Unicode characters or with a zero-height font to confuse security scanning • Victim-specific URI, where a malicious link encodes special information which allows a counterfeit site to be personalized (appearing as the victim's account) so as to be more convincing. 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. Requests for special fonts, etc, can also impact system resources. During periods of increased network threats, the US Department of Defense has converted user's incoming HTML email to text email. 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 for these reasons, so spam filters sometimes give higher spam scores to HTML messages. 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. == See also ==