HTML郵件
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]
兼容性
郵件軟體符合規定是靠著 RFC 2822 只需要支持純文本,不是將HTML格式化. 發送HTML格式的電子郵件可以因此導致問題 如果收件人的電郵客戶沒有支持它.在最糟的案子裡 收件人將會看到HTML碼而不是預期的消息.
那些支持HTML的電子郵件客戶端, 有些沒有給予它的W3C 始終如一 規格, 許多HTML電子郵件也不兼容， 那些可能造成翻譯或呈現問題, 特別是Gmail的用戶.[來源請求]
尤其是<head>的標記, 它用於容納CSS樣式規則在整個HTML裡文件，沒有很好的支持，有時完全剝離, 導致在線樣式聲明成為事實上的標準, 即使在線樣式聲明效率低下，也無法充分利用HTML的能力從內容分離風格。[來源請求] 儘管已經制定了解決方法,[8] 這已經在通訊開發人員中引起了不少挫折, 催生基層電子郵件標準項目, 對電子郵件客戶端進行酸性測試的評分，受到Web標準項目的啟發， 並遊說開發商改進他們的產品.[9] 說服Google改善Gmail中的呈現, 例如，他們發表了一個鬼臉網絡開發者的視頻剪輯，引起員工的注意。
| 客戶端 | 結果（截至） |
|---|---|
| 美國在線Webmail | 堅實的支持（2011年7月13日） |
| 蘋果iPhone | 堅實的支持（2011年7月13日） |
| 蘋果iPad | |
| 蘋果iPod Touch | |
| 蘋果郵件 | 堅實的支持（2007年11月28日） |
| 蘋果MobileMe | 堅實的支持（2008年8月15日） |
| Eudora
Eudora OSE代號為“Penelope” |
堅實的支持（2007年11月28日） |
| Microsoft Entourage | 堅實的支持（2007年11月28日） |
| Mozilla Thunderbird | 堅實的支持（2007年11月28日） |
| Windows Live Mail | 堅實的支持（2007年11月28日） |
| Windows Mail | 堅實的支持（2007年11月28日） |
| 雅虎 郵件測試版 | 堅實的支持（2007年11月28日） |
| Windows Live Hotmail | 建議進行一些改進（2011年7月8日） |
| Google Gmail | 建議改進（2011年7月13日） |
| Lotus Notes 8 | 建議改進（2007年11月28日） |
| Microsoft Outlook 2007 | 建議改進（2007年11月28日） |
風格
一些發件人可能過分依賴大型，豐富多彩，或分散字體，使訊息更難以閱讀.[10] 對於那些特別被格式化困擾的用戶來說，一些用戶代理可以讓讀者部分地重寫格式 （例如，Mozilla Thunderbird允許指定最小的字體大小）; 但是，這些功能並不是全球可用的. 此外，發件人和讀者之間的光學外觀差異可以幫助區分每個部分的作者，提高可讀性。
多部分格式
許多電子郵件服務器被配置為自動生成純文本版本的消息，並將其與HTML版本一起發送， 以確保它甚至可以通過純文本的電子郵件客戶端使用Content-Type來閱讀: 多部分/備選，如RFC 1521中所規定的.[11][12][13] T他的信息本身是多部分/替代的類型,它包含兩個部分，第一個是純文本客戶端讀取的文本/純文本，第二個是帶有HTML / HTML的客戶端讀取的文本。 但純文本版本可能會丟失重要的格式信息。 （例如，一個數學方程可能會失去一個上標，並具有一個全新的含義。）
許多郵件列表故意阻止HTML電子郵件，或者刪除HTML部分，只留下純文本部分或拒絕整個郵件。[來源請求]
部件的順序是重要的。 RFC1341指出：一般來說，組成多部分/替代實體的用戶代理應該按照優先級遞增的順序放置正文部分，也就是說，首選格式是最後一個。 對於帶有html和純文本版本的多部分電子郵件，這意味著首先列出純文本版本，之後列出html版本，否則即使html版本可用，客戶端也可能默認顯示純文本版本。
郵件大小
HTML電子郵件比純文本大。 即使沒有使用特殊的格式,將會在最小的HTML文檔中使用標籤的開銷, 如果格式化過度使用，可能會高得多。 多部分消息, 以不同格式的相同內容的副本，甚至進一步增加尺寸。純文本部分的一個多部分 消息可以被自己檢索，但是要使用 IMAP的FETCH命令。[14]
雖然明文和混合郵件（可能是十倍或十倍以上）之間的下載時間差異在20世紀90年代（當大多數用戶通過緩慢訪問電子郵件服務器數據機), 在現代連接上，對於大多數人來說差別是微不足道的，尤其是與圖像，音樂文件或其他常見附件相比時。
安全漏洞
HTML允許將鏈接顯示為任意文本，以便不顯示完整的URL， 一個鏈接可能只顯示其中的一部分或只是一個用戶友好的目標名稱。 這可以用於釣魚式攻擊，其中用戶被愚弄，認為鏈接指向權威來源（如銀行）的網站，訪問它，並無意中透露個人信息（如銀行帳號）給騙子
如果電子郵件包含網路漏洞（來自外部服務器的內嵌內容，例如圖片）, 服務器可以提醒第三方電子郵件已被打開。 這是潛在的隱私風險, 揭示了一個電子郵件地址是真實的（以便它可以在將來成為目標）並揭示消息何時被讀取。 為此，有些電子郵件客戶端在用戶請求之前不會加載外部映像。
HTML內容要求電子郵件程序使用引擎進行分析, 呈現並顯示文檔. 這可能會導致更多的安全漏洞，拒絕服務或舊電腦的低性能。
在網絡威脅增加期間，美國國防部將所有傳入的HTML電子郵件轉換為文本電子郵件。[15]
多部分類型旨在以不同的方式顯示相同的內容，但這有時會被濫用;一些垃圾電郵利用這種格式來欺騙垃圾郵件過濾器，使其相信郵件是合法的。 他們通過在消息的文本部分包含無害內容並將垃圾郵件放入HTML部分（向用戶顯示的部分）來實現這一點。
大多數電子郵件垃圾郵件都是用HTML發送的[出於這些原因，所以垃圾郵件過濾器有時會給HTML郵件提供更高的垃圾郵件分數
另請參閱
- 豐富的文本 - 使用MIME的類似於HTML的電子郵件系統
- MHTML
參考
。www.thundermailer.com。[2016年1月30日]。
HTML電子郵件：只要可能，把它關掉！
。 2013-07-25 [2016-01-30] （原始內容於2013年7月25日）。
。forum.palemoon.org。[2016年1月30日]。
HTML電子郵件：投票（Scot Hacker，為什麼HTML在電子郵件是一個不好的想法討論了他的感情自20世紀90年代以來如何變化）的發端，
格羅斯曼，愛德華。。www.clickz.com。 2002-07-09 [2016-01-30] 你喜歡收到HTML或文本電子郵件？ HTML：41.95％，文本：31.52％，無偏好：26.53％
。www.slideshare.net。[2016年1月30日]。 您喜歡以什麼格式接收公司的電子郵件？ HTML：88％，純文本：12％
方言<http://dialect.ca/>。Premailer.dialect.ca。[2012-06-24]。
。 活動監視器。[2012-06-24]。
Shobe，Matt。。Burningdoor.com。 2004-10-12 [2012-06-24]
RFC 1521 7.2.3。 多部分/替代子類型
（PDF）。[2012-06-24]。
。Wilsonweb.com。 2000-04-28 [2012-06-24]
。Dsv.su.se.[2012-06-24]。
。fcw.com。[2015年6月23日]。
- ^ Text Email vs HTML Email – The Pros and Cons | Thunder Mailer – Mass Emailing Software. www.thundermailer.com. [2016-01-30].
- ^ HTML Email: Whenever Possible, Turn It Off!
- ^ The Ascii Ribbon Campaign official homepage. 2013-07-25 [2016-01-30]. （原始内容存档于25 July 2013）.
- ^ Shutdown of the ASCII ribbon campaign - Pale Moon forum. forum.palemoon.org. [2016-01-30].
- ^ 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)
- ^ 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%
- ^ 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%
- ^ Dialect <http://dialect.ca/>. Premailer: make CSS inline for HTML e-mail. Premailer.dialect.ca. [2012-06-24].
- ^ Why we need standards support in HTML email. Campaign Monitor. [2012-06-24].
- ^ Shobe, Matt. A pretty fair argument against HTML Email. Burningdoor.com. 2004-10-12 [2012-06-24].
- ^ RFC 1521 7.2.3. The Multipart/alternative subtype
- ^ TN1010-11-2: Multipart/Alternative — Gracefully handling HTML-phobic email clients. (PDF). [2012-06-24].
- ^ Sending HTML and Plain Text E-Mail Simultaneously. Wilsonweb.com. 2000-04-28 [2012-06-24].
- ^ Do we really want to send web pages in e-mail?. Dsv.su.se. [2012-06-24].
- ^ DOD bars use of HTML e-mail, Outlook Web Access. fcw.com. [2015-06-23].