跳转到内容

HTML郵件

维基百科，自由的百科全书

这是本页的一个历史版本，由Tcsh002​（留言 | 贡献）在2017年10月22日 (日) 12:09编辑。这可能和当前版本存在着巨大的差异。

HTML郵件 用於一個子集在HTML提供格式化和語義標記功能在email裡是個不合宜的計畫文本:[1] 文本可以連接而不用顯示統一資源定位服, 或是闖入統一資源定位服,多件的事件被包裹在適當寬度的視窗裡, 而不是均勻的打破每一行在78個文字裡

（定義在 RFC 5322, 是必要在舊的文本末). 它允許在自行間包容影像,表格,以及圖或是數學公式影像 , 那些除此以外的傳達困難 (一般使用ASCII art).

採用

大多數圖形的電郵客戶支持HTML郵件, 還有很多默認它. 很多的客戶包含一個GUI編輯者來構成構成 HTML 電子郵件以及用於顯示接收到的HTML電子郵件的呈現引擎。

從它的概念以來, 一些人有聲音反對整個HTML email (和甚至 MIME本身), 由於各種不同的理由.[2] 舉例來說,ASCII Ribbon 運動主張全部的電子郵件應該被放進去 ASCII 文字格式. 而這個運動 是不成功的而在2013被放棄了.[3][4] 當持續思考不當 i在很多的新聞群組的發表和郵件清單, 它採用個人和商務郵件隨著時間的推移而增加. 一些強烈反對它的人當它首度出現至今我們視它為無害.[5]

根據線上市場公司調查, 採用HTML能夠讓電郵用戶現今能幾乎普遍, 憑著小於 3% 報告他們的純文本客戶端。他們大多數用戶喜歡通過純文本接收HTML電子郵件.[6][7]

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, especially for users of Gmail.[來源請求]

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.[來源請求] Although workarounds have been developed,[8] 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.[9] 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)[1]
Clients Result (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 Beta Solid support (8 July 2011)
Windows Live Hotmail Some improvement recommended (8 July 2011)
Google Gmail Improvement recommended (13 July 2011)
Lotus Notes 8 Improvement recommended (28 November 2007)
Microsoft Outlook 2007 Improvement 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[來源請求] 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.[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 displayed as arbitrary text, so that rather than displaying the full URL, a link may show only part of it or simply a user-friendly target name. 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 web bugs (inline content from an external server, such as a picture), the server can alert a third party that the email 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 email clients do not load external images until requested to by the user.

HTML content requires email programs to use engines to parse, render and display the document. This can lead to more security vulnerabilities, denial of service or low performance on older computers.

During periods of increased network threats, the US Department of Defense converts all incoming HTML email to text email.[18]

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.[來源請求]

See also

References

  1. ^ Text Email vs HTML Email – The Pros and Cons | Thunder Mailer – Mass Emailing Software. www.thundermailer.com. [2016-01-30]. 
  2. ^ HTML Email: Whenever Possible, Turn It Off!
  3. ^ The Ascii Ribbon Campaign official homepage. 2013-07-25 [2016-01-30]. （原始内容存档于25 July 2013）. 
  4. ^ Shutdown of the ASCII ribbon campaign - Pale Moon forum. forum.palemoon.org. [2016-01-30]. 
  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. ^ Grossman, Edward. Real-World Email Client Usage: The Hard Data | ClickZ. www.clickz.com. 2002-07-09 [2016-01-30]. Do you prefer receiving HTML or text email? HTML: 41.95%, Text: 31.52%, No preference: 26.53% 
  7. ^ The Science of Email Marketing. www.slideshare.net. [2016-01-30]. In what format do you prefer to receive email messages from companies? HTML: 88%, Plain text: 12% 
  8. ^ Dialect <http://dialect.ca/>. Premailer: make CSS inline for HTML e-mail. Premailer.dialect.ca. [2012-06-24]. 
  9. ^ Why we need standards support in HTML email. Campaign Monitor. [2012-06-24]. 
  10. ^ The 2008 Gmail Appeal | Email Standards Project. Email-standards.org. [2012-06-24]. 
  11. ^ Shobe, Matt. A pretty fair argument against HTML Email. Burningdoor.com. 2004-10-12 [2012-06-24]. 
  12. ^ RFC 1521 7.2.3. The Multipart/alternative subtype
  13. ^ TN1010-11-2: Multipart/Alternative — Gracefully handling HTML-phobic email clients. (PDF). [2012-06-24]. 
  14. ^ Sending HTML and Plain Text E-Mail Simultaneously. Wilsonweb.com. 2000-04-28 [2012-06-24]. 
  15. ^ RFC1341 Section 7.2 The Multipart Content-Type. [2014-07-15]. 
  16. ^ Do we really want to send web pages in e-mail?. Dsv.su.se. [2012-06-24]. 
  17. ^ HTML Email — Still Evil?
  18. ^ DOD bars use of HTML e-mail, Outlook Web Access. fcw.com. [2015-06-23]. 
检索自“https://zh.wikipedia.org/w/index.php?title=HTML郵件&oldid=46669306”