HTML郵件

维基百科,自由的百科全书
跳到导航 跳到搜索

HTML郵件(HTML email)使用HTML标记语言的子集来在email中提供格式化和語義標記功能,因为在纯文本文档里没有这些功能[1]。文本可以連接而不用顯示統一資源定位服,或是闖入統一資源定位服,多件的事件被包裹在適當寬度的視窗裡,而不是均勻的打破每一行在78個文字裡。它允許在自行間包容影像、表格,以及圖或是數學公式影像,那些除此以外的傳達困難(一般使用ASCIIart)。

採用[编辑]

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

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

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

相容性[编辑]

郵件軟體符合規定是靠著 RFC 2822 只需要支持純文本,不是將HTML格式化。發送HTML格式的電子郵件可以因此導致問題如果收件人的電郵客戶沒有支持它。在最糟的案子裡收件人將會看到HTML碼而不是預期的訊息。

那些支持HTML的電子郵件客戶端,有些沒有給予它W3C始終如一規格,許多HTML電子郵件也無法相容,那些可能造成翻譯或呈現問題,特別是Gmail的用戶[來源請求]

尤其是<head>的標記,它用於容納CSS樣式規則在整個HTML裡文件,沒有很好的支持,有時完全剝離,導致在線樣式聲明成為事實上的標準,即使在線樣式聲明效率低下,也無法充分利用HTML的能力從內容分離風格[來源請求]。儘管已經制定了解決方法,[9]這已經在通訊開發人員中引起了不少挫折,催生基層電子郵件標準項目,對電子郵件客戶端進行酸性測試的評分,受到Web標準項目的啟發,並遊說開發商改進他們的產品。[10]說服Google改善Gmail中的呈現,例如,他們發表了一個鬼臉網絡開發者的視頻剪輯,引起員工的注意。

"電子郵件標準項目“酸性測試比較(截至2013年1月)[2]页面存档备份,存于互联网档案馆
客戶端 結果(截至)
美國在線Webmail 堅實的支持(2011年7月13日)
蘋果iPhone 堅實的支持(2011年7月13日)
蘋果iPad
蘋果iPodTouch
蘋果郵件 堅實的支持(2007年11月28日)
蘋果MobileMe 堅實的支持(2008年8月15日)
Eudora

EudoraOSE代號為“Penelope”

堅實的支持(2007年11月28日)
MicrosoftEntourage 堅實的支持(2007年11月28日)
MozillaThunderbird 堅實的支持(2007年11月28日)
WindowsLiveMail 堅實的支持(2007年11月28日)
WindowsMail 堅實的支持(2007年11月28日)
雅虎郵件測試版 堅實的支持(2007年11月28日)
WindowsLiveHotmail 建議進行一些改進(2011年7月8日)
GoogleGmail 建議改進(2011年7月13日)
LotusNotes8 建議改進(2007年11月28日)
MicrosoftOutlook2007 建議改進(2007年11月28日)

風格[编辑]

一些發件人可能過分依賴大型,豐富多彩,或分散字體,使訊息更難以閱讀.[11]對於那些特別被格式化困擾的用戶來說,一些用戶代理可以讓讀者部分地重寫格式(例如,MozillaThunderbird允許指定最小的字體大小);但是,這些功能並不是全球可用的.此外,發件人和讀者之間的光學外觀差異可以幫助區分每個部分的作者,提高可讀性。

多部分格式[编辑]

許多電子郵件服務器被配置為自動生成純文本版本的消息,並將其與HTML版本一起發送,以確保它甚至可以通過純文本的電子郵件客戶端使用Content-Type來閱讀:多部分/備選,如RFC1521中所規定的.[12][13][14]T他的信息本身是多部分/替代的類型,它包含兩個部分,第一個是純文本客戶端讀取的文本/純文本,第二個是帶有HTML/HTML的客戶端讀取的文本。但純文本版本可能會丟失重要的格式信息。(例如,一個數學方程可能會失去一個上標,並具有一個全新的含義。)

許多郵件列表故意阻止HTML電子郵件,或者刪除HTML部分,只留下純文本部分或拒絕整個郵件。[來源請求]

部件的順序是重要的。RFC1341指出:一般來說,組成多部分/替代實體的用戶代理應該按照優先級遞增的順序放置正文部分,也就是說,首選格式是最後一個。對於帶有html和純文本版本的多部分電子郵件,這意味著首先列出純文本版本,之後列出html版本,否則即使html版本可用,客戶端也可能默認顯示純文本版本。

郵件大小[编辑]

HTML電子郵件比純文本大。即使沒有使用特殊的格式,將會在最小的HTML文檔中使用標籤的開銷,如果格式化過度使用,可能會高得多。多部分消息,以不同格式的相同內容的副本,甚至進一步增加尺寸。純文本部分的一個多部分消息可以被自己檢索,但是要使用IMAP的FETCH命令。[15]

雖然明文和混合郵件(可能是十倍或十倍以上)之間的下載時間差異在20世紀90年代(當大多數用戶通過緩慢訪問電子郵件服務器數據機),在現代連接上,對於大多數人來說差別是微不足道的,尤其是與圖像,音樂文件或其他常見附件相比時。

安全漏洞[编辑]

HTML允許將鏈接顯示為任意文本,以便不顯示完整的URL,一個鏈接可能只顯示其中的一部分或只是一個用戶友好的目標名稱。這可以用於釣魚式攻擊,其中用戶被愚弄,認為鏈接指向權威來源(如銀行)的網站,訪問它,並無意中透露個人信息(如銀行帳號)給騙子

如果電子郵件包含網路漏洞(來自外部服務器的內嵌內容,例如圖片),服務器可以提醒第三方電子郵件已被打開。這是潛在的隱私風險,揭示了一個電子郵件地址是真實的(以便它可以在將來成為目標)並揭示消息何時被讀取。為此,有些電子郵件客戶端在用戶請求之前不會加載外部映像。

HTML內容要求電子郵件程序使用引擎進行分析,呈現並顯示文檔.這可能會導致更多的安全漏洞,拒絕服務或舊電腦的低性能。

在網絡威脅增加期間,美國國防部將所有傳入的HTML電子郵件轉換為文本電子郵件。[16]

多部分類型旨在以不同的方式顯示相同的內容,但這有時會被濫用;一些垃圾電郵利用這種格式來欺騙垃圾郵件過濾器,使其相信郵件是合法的。他們通過在消息的文本部分包含無害內容並將垃圾郵件放入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電子郵件:投票(ScotHacker,為什麼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]

RFC15217.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日]。

參考資料[编辑]

  1. ^ TextEmailvsHTMLEmail–TheProsandCons|ThunderMailer–MassEmailingSoftware. www.thundermailer.com. [2016-01-30]. (原始内容存档于2016-02-03). 
  2. ^ Isaac, Alan G. HTML Email: Whenever Possible, Turn It Off!. subversion.american.edu. [2018-02-03]. (原始内容存档于2016-06-03) (英语). 
  3. ^ TheAsciiRibbonCampaignofficialhomepage. 2013-07-25 [2016-01-30]. (原始内容存档于2013-07-25). 
  4. ^ ShutdownoftheASCIIribboncampaign-PaleMoonforum. forum.palemoon.org. [2016-01-30]. (原始内容存档于2016-02-03). 
  5. ^ [1][永久失效連結](ScotHacker,originatorofthemuch-linked-toWhyHTMLinE-MailisaBadIdeadiscusseshowhisfeelingshavechangedsincethe1990s)
  6. ^ Email Marketing Statistics and Metrics - EmailLabs. 2007-03-29 [2016-01-30]. (原始内容存档于2007-03-29). HTML has nearly universal adoption among consumers: A Jupiter Research consumer survey found just 3% receive only text email. 
  7. ^ Grossman, Edward. Real-WorldEmailClientUsage:TheHardData|ClickZ. www.clickz.com. 2002-07-09 [2016-01-30]. (原始内容存档于2016-02-05). DoyoupreferreceivingHTMLortextemail?HTML:41.95%,Text:31.52%,Nopreference:26.53% 
  8. ^ TheScienceofEmailMarketing. www.slideshare.net. [2016-01-30]. (原始内容存档于2016-02-05). Inwhatformatdoyouprefertoreceiveemailmessagesfromcompanies?HTML:88%,Plaintext:12% 
  9. ^ Dialect<http://dialect.ca/>. Premailer:makeCSSinlineforHTMLe-mail. Premailer.dialect.ca. [2012-06-24]. (原始内容存档于2012-06-21). 
  10. ^ WhyweneedstandardssupportinHTMLemail. CampaignMonitor. [2012-06-24]. (原始内容存档于2012-07-22). 
  11. ^ Shobe, Matt. AprettyfairargumentagainstHTMLEmail. Burningdoor.com. 2004-10-12 [2012-06-24]. (原始内容存档于2012-04-24). 
  12. ^ 存档副本. [2017-10-01]. (原始内容存档于2017-10-10). 
  13. ^ TN1010-11-2:Multipart/Alternative—GracefullyhandlingHTML-phobicemailclients. (PDF). [2012-06-24]. (原始内容存档 (PDF)于2012-02-13). 
  14. ^ SendingHTMLandPlainTextE-MailSimultaneously. Wilsonweb.com. 2000-04-28 [2012-06-24]. (原始内容存档于2012-05-05). 
  15. ^ Dowereallywanttosendwebpagesine-mail?. Dsv.su.se. [2012-06-24]. (原始内容存档于2007-02-19). 
  16. ^ DODbarsuseofHTMLe-mail,OutlookWebAccess. fcw.com. [2015-06-23]. (原始内容存档于2015-06-23).