Content deleted Content added
No edit summary Tag: possible vandalism |
m →Adoption: Punctuation |
||
| (92 intermediate revisions by 66 users not shown) | |||
Line 1:
{{Short description|Type of email}}
{{Use dmy dates|date=
{{POV|talk=POV|date=December 2021}}
'''HTML
== Adoption ==▼
Most graphical [[email client]]s support HTML email, and many default to it.<ref>[http://www.expita.com/nomime.html#programs Configuring Mail Clients to Send Plain ASCII Text]{{dead link|date=November 2012}} — E-mail client programs</ref> Many of these clients include both a [[GUI]] editor for composing HTML emails and a rendering engine for displaying received HTML emails.▼
▲Most graphical [[email client]]s support HTML email, and many default to it.
▲HTML mail allows the sender to properly express [[block quote|quotations]] (as in [[Posting style#Interleaved style|inline replying]]), headings, [[Bullet (typography)|bulleted lists]], [[Emphasis (typography)|emphasized text]], [[subscript]]s and [[superscript]]s, and other visual and [[typographic]] 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 [[Uniform Resource Locator|URL]]s 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 5322, which was necessary on older [[Data terminal#Text terminals|text terminals]]). It allows in-line inclusion of [[Table (information)|table]]s, as well as diagrams or [[mathematical formula]]e 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.<ref>[https://subversion.american.edu/aisaac/notes/htmlmail.htm HTML Email: Whenever Possible, Turn It Off!]</ref> For instance, the ''ASCII Ribbon Campaign'' advocated that all email should be sent in [[ASCII]] text format. Proponents placed [[ASCII art]] in their [[signature block]]s, 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.<ref>{{Cite web |title=The Ascii Ribbon Campaign official homepage |url=http://www.asciiribbon.org/ |access-date=30 January 2016 |archive-url=https://web.archive.org/web/20100311081242/http://www.asciiribbon.org/ |archive-date=11 March 2010 |url-status=dead }}</ref><ref>{{Cite web|title = Shutdown of the ASCII ribbon campaign – Pale Moon forum|url = http://forum.palemoon.org/viewtopic.php?f=4&t=2705|website = forum.palemoon.org|access-date = 2016-01-30|archive-url = https://web.archive.org/web/20160203102930/http://forum.palemoon.org/viewtopic.php?f=4&t=2705|archive-date = 3 February 2016|url-status = dead}}</ref>
▲== Adoption ==
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.<ref
== Compatibility ==
Email software that complies with [https://tools.ietf.org/html/rfc2822 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.▼
{| class="wikitable" align=right width=50%▼
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 <code><nowiki><head></nowiki></code> 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|''de facto'' standard]], even though
|+"Email standards project" ''Acid test'' comparison (as of January 2013)<ref>{{Cite web |date= |title=Home |url=http://www.email-standards.org/ |archive-url=https://web.archive.org/web/20130114102435/http://www.email-standards.org/ |archive-date=2013-01-14 |access-date=2024-12-22 |website=Email Standards Project}}</ref>
|-
!Clients !! Result (as of)
Line 56 ⟶ 64:
|-
|[[Google Gmail]]
|{{
|-
|[[Lotus Notes]] 8
|{{
|-
|[[Microsoft Outlook]] 2007
|{{
|}
▲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, especially for users of [[GMail]].
▲In particular, the <code><nowiki><head></nowiki></code> 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|''de facto'' standard]], even though they are not optimal from a [[Separation of style and content|semantic web]] point of view.<ref>{{cite web|url=http://www.yourtotalsite.com/archives/online_marketing/not_your_ordinary_html_em/Default.aspx |title=Not your ordinary html email tips |publisher=Yourtotalsite.com |date= |accessdate=2012-06-24}}{{Dead link|url=http://web.archive.org/web/20070927043051/http://www.yourtotalsite.com/archives/online_marketing/not_your_ordinary_html_em/Default.aspx |date=February 2009}}</ref> Although workarounds have been developed,<ref>{{cite web|author=Dialect <http://dialect.ca/> |url=http://premailer.dialect.ca/ |title=Premailer: make CSS inline for HTML e-mail |publisher=Premailer.dialect.ca |date= |accessdate=2012-06-24}}</ref> this has caused no shortage of frustration among newsletter developers, spawning the [[grassroots]] [http://www.email-standards.org/ 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.<ref>{{cite web|url=http://www.campaignmonitor.com/blog/archives/2007/09/why_we_need_web_standards_supp_1.html |title=Why we need standards support in HTML email |publisher=Campaign Monitor |date= |accessdate=2012-06-24}}</ref> To persuade [[Google]] to improve rendering in [[Gmail]], for instance, they published a video montage of grimacing web developers,<ref>{{cite web|url=http://www.email-standards.org/gmail-appeal |title=The 2008 Gmail Appeal | Email Standards Project |publisher=Email-standards.org |date= |accessdate=2012-06-24}}</ref> 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.<ref>{{cite web |last=Shobe |first=Matt |url=http://www.burningdoor.com/matt/archives/000782.html |title=A pretty fair argument against HTML Email |publisher=Burningdoor.com |date=2004-10-12 |accessdate=2012-06-24 |url-status=dead |archiveurl=https://web.archive.org/web/20120424084806/http://www.burningdoor.com/matt/archives/000782.html |archivedate=24 April 2012 }}</ref>
== 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 client]]s, using the <code>[[MIME content type|Content-Type]]: [[MIME#
Many{{Citation needed|date=September 2009}} [[Electronic mailing list|mailing list]]s deliberately block HTML email, either stripping out the HTML part to just leave the plain text part or rejecting the entire message.{{Citation needed|date=September 2009}}
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.''<ref>{{cite web|url=http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html|title=RFC1341 Section 7.2 The Multipart Content-Type|accessdate=2014-07-15}}</ref> 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.<ref>{{cite web|url=http://dsv.su.se/jpalme/ietf/mhtml-discussion.html |title=Do we really want to send web pages in e-mail? |publisher=Dsv.su.se
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 [[modem]]s), on a modern connection the difference is negligible for most people, especially when compared to images, music files, or other common attachments.<ref>[http://
▲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 [[modem]]s), on a modern connection the difference is negligible for most people, especially when compared to images, music files, or other common attachments.<ref>[http://momentum.insertdisc.com/archives/2004/09/17/html_email_still_evil_part_1.html HTML Email — Still Evil?]</ref>
== Security vulnerabilities ==
HTML allows
If an email contains inline content from an external server, such as a [[Digital image|picture]],
▲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.
retrieving it requires a request to that external server which identifies where the picture will be displayed and other information about the recipient. [[Web bug]]s 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:<ref name=Trend>{{cite web|title=Trend-spotting email techniques: How modern phishing emails hide in plain sight |date=August 18, 2021 |url=https://www.microsoft.com/en-us/security/blog/2021/08/18/trend-spotting-email-techniques-how-modern-phishing-emails-hide-in-plain-sight/ |publisher=Microsoft.com}}</ref>
* 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.{{cn|date=June 2024}} Requests for special fonts, etc, can also impact system resources.{{cn|date=June 2024}}
During periods of increased network threats, the US Department of Defense converts all incoming HTML email to text email.<ref>[http://www.fcw.com/article97178-12-22-06-Web/ DOD bars use of HTML e-mail, Outlook Web Access]{{dead link|date=June 2012}}{{Dead link|url=http://www.fcw.com/article97178-12-22-06-Web/ DOD bars use of HTML e-mail, Outlook Web Access |date=September 2009}}</ref>▼
▲During periods of increased network threats, the US Department of Defense
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 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 (that which is displayed to the user).
Most email spam is sent in HTML{{Citation needed|date=December 2013}} for these reasons, so spam filters sometimes give higher spam scores to HTML messages.{{Citation needed|date=December 2013}}
In 2018 a vulnerability ([[EFAIL]]) of the HTML processing of many common email clients was disclosed, in which decrypted text of [[Pretty Good Privacy|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.<ref name="ars">{{cite web|url=https://arstechnica.com/information-technology/2018/05/decade-old-efail-attack-can-decrypt-previously-obtained-encrypted-e-mails/|title=Decade-old Efail flaws can leak plaintext of PGP- and S/MIME-encrypted emails|website=arstechnica.com|date=14 May 2018 }}</ref>
== See also ==
* [[Enriched text]]
* [[
== References ==
{{Reflist
== External links ==
* https://www.caniemail.com/
[[Category:Email]]
[[Category:Internet terminology]]
[[Category:HTML]]
| |||