コンテンツにスキップ

英文维基 | 中文维基 | 日文维基 | 草榴社区

「HTML電子メール」の版間の差分

出典: フリー百科事典『ウィキペディア（Wikipedia）』
履歴の双方向閲覧
← 古い編集新しい編集 →
削除された内容 追加された内容
ビジュアルウィキテキスト
Content-Typeのリンク先をメディアタイプに変更。
Cewbot (会話 | 投稿記録)
ボット
780,113 回編集
m Bot作業依頼：インターネットアーカイブ - log
14行目: 14行目:


特に、全部のHTMLドキュメントのためにCSS形式で用いられる<head>タグは、十分に対応しておらず、時々、全体が削除される、'[[デ・ファクト|慣習]]'上の標準であるインライン形式の宣言を引き起こす<!--[[セマンティック・ウェブ]]の視点から最適でないにもかかわらず--><ref>
特に、全部のHTMLドキュメントのためにCSS形式で用いられる<head>タグは、十分に対応しておらず、時々、全体が削除される、'[[デ・ファクト|慣習]]'上の標準であるインライン形式の宣言を引き起こす<!--[[セマンティック・ウェブ]]の視点から最適でないにもかかわらず--><ref>
[http://web.archive.org/web/20080408222130/http://www.yourtotalsite.com/archives/online_marketing/not_your_ordinary_html_em/Default.aspx Not your ordinary html email tips]（2008年4月8日時点の[[インターネット・アーカイブ|アーカイブ]]）</ref>。しかしながら、ニュースレターの開発者の要求に対する不足を引き起こさない回避策が開発された<ref>[http://code.dunae.ca/premailer.web/ Premailer: make CSS inline for HTML e-mail]</ref>。互換性の問題に対処するために、[[ウェブスタンダードプロジェクト|The Web Standards Project]]において、[http://www.email-standards.org/ The Email Standards Project]が発足した。この計画では、電子メールリーダアプリケーション開発者やデザインコミュニティの関係者が協同して電子メールにおけるWeb標準の策定を目指す<ref>[http://journal.mycom.co.jp/news/2007/12/03/013/index.html 電子メールHTML標準化を目指す - Email Standards Project発足]</ref>。そこでは、電子メールクライアントをレンダリングで格付けるacid testが行われる。<!--and lobbies developers to improve their products.<ref>[http://www.campaignmonitor.com/blog/archives/2007/09/why_we_need_web_standards_supp_1.html Campaign Monitor: Why we need standards support in HTML email]</ref>-->また、[[Google]]を説得するために、[[Gmail]]のレンダリングを改善した。例えば、従業員の注目の結果、彼らはウェブ開発者にビデオモンタージュを公開した<ref>[http://www.email-standards.org/gmail-appeal]</ref>。
[http://web.archive.org/web/20080408222130/http://www.yourtotalsite.com/archives/online_marketing/not_your_ordinary_html_em/Default.aspx Not your ordinary html email tips]（2008年4月8日時点の[[インターネットアーカイブ|アーカイブ]]）</ref>。しかしながら、ニュースレターの開発者の要求に対する不足を引き起こさない回避策が開発された<ref>[http://code.dunae.ca/premailer.web/ Premailer: make CSS inline for HTML e-mail]</ref>。互換性の問題に対処するために、[[ウェブスタンダードプロジェクト|The Web Standards Project]]において、[http://www.email-standards.org/ The Email Standards Project]が発足した。この計画では、電子メールリーダアプリケーション開発者やデザインコミュニティの関係者が協同して電子メールにおけるWeb標準の策定を目指す<ref>[http://journal.mycom.co.jp/news/2007/12/03/013/index.html 電子メールHTML標準化を目指す - Email Standards Project発足]</ref>。そこでは、電子メールクライアントをレンダリングで格付けるacid testが行われる。<!--and lobbies developers to improve their products.<ref>[http://www.campaignmonitor.com/blog/archives/2007/09/why_we_need_web_standards_supp_1.html Campaign Monitor: Why we need standards support in HTML email]</ref>-->また、[[Google]]を説得するために、[[Gmail]]のレンダリングを改善した。例えば、従業員の注目の結果、彼らはウェブ開発者にビデオモンタージュを公開した<ref>[http://www.email-standards.org/gmail-appeal]</ref>。


== 書式 ==
== 書式 ==
35行目: 35行目:
もし、電子メールが[[ウェブビーコン|ウェブバグ]]（外部のサーバからのインラインコンテンツ。例えば画像）を含めば、サーバは、サードパーティに対して、電子メールが開かれていることを警告することが出来る。これは、潜在的な[[E-mail privacy]]のリスクである。電子メールアドレスが本物であり、メッセージが読まれたときに明らかにされることである。こういった理由で、一部の電子メールクライアントは、ユーザに要求されるまで、外部からの画像を読み込まないようにしている。
もし、電子メールが[[ウェブビーコン|ウェブバグ]]（外部のサーバからのインラインコンテンツ。例えば画像）を含めば、サーバは、サードパーティに対して、電子メールが開かれていることを警告することが出来る。これは、潜在的な[[E-mail privacy]]のリスクである。電子メールアドレスが本物であり、メッセージが読まれたときに明らかにされることである。こういった理由で、一部の電子メールクライアントは、ユーザに要求されるまで、外部からの画像を読み込まないようにしている。


ネットワークの脅威が増加していた期間において、[[アメリカ国防総省]]は、全てのHTML電子メールをテキスト電子メールに変換した<ref>[http://web.archive.org/web/20070921213231/http://www.fcw.com/article97178-12-22-06-Web DOD bars use of HTML e-mail, Outlook Web Access]（2007年9月21日時点の[[インターネット・アーカイブ|アーカイブ]]）</ref>。
ネットワークの脅威が増加していた期間において、[[アメリカ国防総省]]は、全てのHTML電子メールをテキスト電子メールに変換した<ref>[http://web.archive.org/web/20070921213231/http://www.fcw.com/article97178-12-22-06-Web DOD bars use of HTML e-mail, Outlook Web Access]（2007年9月21日時点の[[インターネットアーカイブ|アーカイブ]]）</ref>。


マルチパートタイプは、異なる方法でコンテンツを表示するためのものであるが、これは時々、[[スパム (メール)|スパマー]]が、メッセージを正規のものと信じさせ、[[電子メールフィルタリング|スパムフィルター]]を回避するために悪用される。この方法は、スパマーが、メッセージのテキスト部分に差し障りのないコンテンツを含ませ、ユーザに表示されるHTML部分にスパムの内容を置くことによって実現される。
マルチパートタイプは、異なる方法でコンテンツを表示するためのものであるが、これは時々、[[スパム (メール)|スパマー]]が、メッセージを正規のものと信じさせ、[[電子メールフィルタリング|スパムフィルター]]を回避するために悪用される。この方法は、スパマーが、メッセージのテキスト部分に差し障りのないコンテンツを含ませ、ユーザに表示されるHTML部分にスパムの内容を置くことによって実現される。
56行目: 56行目:
* [http://dsv.su.se/jpalme/ietf/mhtml.html Using HTML in E-mail]
* [http://dsv.su.se/jpalme/ietf/mhtml.html Using HTML in E-mail]
* [http://www.w3.org/TR/1998/NOTE-HTMLThreading-0105 HTML Threading: Conventions for use of HTML in email]
* [http://www.w3.org/TR/1998/NOTE-HTMLThreading-0105 HTML Threading: Conventions for use of HTML in email]
* [http://web.archive.org/web/20090625155306/http://www.expita.com/nomime.html Configuring Mail Clients to Send Plain ASCII Text] — Argues that HTML (and MIME in general) should never be used in mail（2009年6月25日時点の[[インターネット・アーカイブ|アーカイブ]]）
* [http://web.archive.org/web/20090625155306/http://www.expita.com/nomime.html Configuring Mail Clients to Send Plain ASCII Text] — Argues that HTML (and MIME in general) should never be used in mail（2009年6月25日時点の[[インターネットアーカイブ|アーカイブ]]）
* [http://home.earthlink.net/~bobbau/email/avoiding-html/ Configuring Your E-mail Software to Avoid Sending HTML-formatted Messages]
* [http://home.earthlink.net/~bobbau/email/avoiding-html/ Configuring Your E-mail Software to Avoid Sending HTML-formatted Messages]
* [http://birdhouse.org/etc/evilmail.html Why HTML in E-Mail is a Bad Idea] (written in the late 90s)
* [http://birdhouse.org/etc/evilmail.html Why HTML in E-Mail is a Bad Idea] (written in the late 90s)

2017年9月5日 (火) 00:21時点における版

HTML電子メール（エイチティーエムエルでんしメール）は、プレーンテキストでは実現できない機能である「書式の指定」や「データの意味[注釈 1]の指定」を行った電子メールである。マークアップにはしばしばHTMLの部分集合が使われているが、必ずしも明確に部分集合を定義したものばかりではない。

殆どの電子メールクライアントは、HTML電子メールに対応し、大半は既定されている[1]。これらのクライアントの多くは、HTML電子メールを作成するためのGUIエディタと、受け取ったHTML電子メールを表示するためのレンダリングエンジンの両方を含む。

送り手は、HTML電子メールを使って、適確にブロック引用、見出し、ビュレット、太字、添え字及び上付き文字を表現し、その他のビジュアル、タイプグラフの可読性及び文字の美しさを改善することができる。同じように、セマンティック・ウェブの情報をメッセージ中にエンコードすることも、元の文章、メッセージIDの引用もできる。長いURLを複数に分割しないでリンクすることができ、一行につき78文字で統一する（古いテキスト端末に必要なRFC 5322に定義がある）代わりに、文章をユーザのビューポートの幅に合わせることもできる。

採用

その概念の登場以来、多くの人々が口頭で全てのHTML電子メールに対して、様々な理由で反対した[2]。en:ASCII Ribbon Campaign（英語）というインターネット現象は、「電子メールは、人間に読みやすいASCII形式で送られ続けるべきである」と主張している。多くのニュースグループとメーリングリストにおいては、未だに不適切であると考えられている一方で、個人及び広告メールのための採用は、増加し続けている。HTML電子メールはほとんど無害であると見る向きもあるが、セキュリティ上のリスクを理由に反対する主張も多い[3]。

互換性

RFC 2822に準拠する電子メールソフトは、HTML形式の文書ではなく、プレーンテキストに対応することのみを要求されている。HTML形式の電子メールを送ることには、受信者の電子メールクライアントがそれに対応しているかどうかという問題がある。最悪の場合は、受信者がメッセージではなく、HTML文書を読むことになる。

これらのHTML形式のものに対応していない電子メールクライアントの中には、W3Cとともに、一貫してレンダリングしない者もいる。そして、多くのHTML電子メールは、レンダリング又は送信の問題を引き起こす可能性がある特にMSN、Hotmailのどちらにも準拠していない[4]。

特に、全部のHTMLドキュメントのためにCSS形式で用いられる<head>タグは、十分に対応しておらず、時々、全体が削除される、'慣習'上の標準であるインライン形式の宣言を引き起こす[5]。しかしながら、ニュースレターの開発者の要求に対する不足を引き起こさない回避策が開発された[6]。互換性の問題に対処するために、The Web Standards Projectにおいて、The Email Standards Projectが発足した。この計画では、電子メールリーダアプリケーション開発者やデザインコミュニティの関係者が協同して電子メールにおけるWeb標準の策定を目指す[7]。そこでは、電子メールクライアントをレンダリングで格付けるacid testが行われる。また、Googleを説得するために、Gmailのレンダリングを改善した。例えば、従業員の注目の結果、彼らはウェブ開発者にビデオモンタージュを公開した[8]。

書式

一部の送信者は、大きく、カラフルで、邪魔なフォントに過度に依存する可能性があるが、作成したメッセージはより読み難い[9]。これらの形式による特別の心配により、幾つかのユーザーエージェントは、読み手が部分的に形式を無視することができるようにしている。例えば、Mozilla Thunderbirdは、いつでも利用できるのではないが、フォントのサイズを指定することができる。更に、送り手と読み手との間の外観の違いに依り、セクションごとの筆者を区別することができ、読み易さを改善することができる。

マルチパート形式

多くの電子メールサーバは、電子メールクライアントがHTML電子メールの文書のみを読めることを確認するために、RFC 1521で指定されたContent-Type: multipart/alternativeを用いて、自動的にプレーンテキストのメッセージを生成するように設定され、HTMLバージョンとともに送られている[10][11][12]。文書自体は、オルターナティブマルチタイプのもので、クライアントがテキストのみを読むプレーンテキストタイプ、HTML形式のものを受けられるクライアントに読まれるHTMLテキストタイプの二つがある。しかしながら、プレーンテキストバージョンは、欠落した重要な書式情報だろう。例えば、方程式は上付き文字を失い、全く新しい意味を取る。

多くのメーリングリストは、故意にプレーンテキストの部分が残るようにHTMLの部分を取り除き、又は文書全体を拒否してHTML電子メールをブロックする[要出典]。

文書の大きさ

HTML電子メールは、プレーンテキストよりも長い。特別な書式が使われていなくても、最小のHTMLドキュメントで使われるタグのからのオーバーヘッドがあるだろう。そして、書式が多用されれば重くなる。同じ内容を違う書式に複写したマルチパートメッセージは、更にサイズを増加させる。マルチパートメッセージのプレーンテキスト部分は、プレーンテキストそれのみで取得出来るにもかかわらず、IMAPFETCHコマンドを使用している[13]。

プレーンテキストと十以上の因子が混合したメールの間には、ダウンロード時間の違いは、殆どのユーザが遅いモデムから電子メールにアクセスしていた1990年代から懸念されたのであるが、今日の接続では、取り分け、画像、音声ファイルその他の一般的な添付データを比較して殆ど人にとって速度の差は僅かなものである[14]。

セキュリティの脆弱性

HTMLにより、リンクのテキストとは異なるリンクを対象に出来る。これは、フィッシングに使われる可能性がある。ユーザは、これに騙されて、リンクされたウェブサイトを正式なもの（例えば、銀行）と信じてアクセスして、意図せず、詐欺師に銀行の口座番号などの個人情報を提供することになってしまう可能性がある。

もし、電子メールがウェブバグ（外部のサーバからのインラインコンテンツ。例えば画像）を含めば、サーバは、サードパーティに対して、電子メールが開かれていることを警告することが出来る。これは、潜在的なE-mail privacyのリスクである。電子メールアドレスが本物であり、メッセージが読まれたときに明らかにされることである。こういった理由で、一部の電子メールクライアントは、ユーザに要求されるまで、外部からの画像を読み込まないようにしている。

ネットワークの脅威が増加していた期間において、アメリカ国防総省は、全てのHTML電子メールをテキスト電子メールに変換した[15]。

マルチパートタイプは、異なる方法でコンテンツを表示するためのものであるが、これは時々、スパマーが、メッセージを正規のものと信じさせ、スパムフィルターを回避するために悪用される。この方法は、スパマーが、メッセージのテキスト部分に差し障りのないコンテンツを含ませ、ユーザに表示されるHTML部分にスパムの内容を置くことによって実現される。


脚注

[脚注の使い方]

注釈

  1. ^ 「セマンティクス (semantics)」のこと。セマンティック・ウェブなどを参照。

出典

  1. ^ Configuring Mail Clients to Send Plain ASCII Text — E-mail client programs
  2. ^ HTML Email: Whenever Possible, Turn It Off!
  3. ^ 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 90s)
  4. ^ Email Marketing Statistics and Metrics
  5. ^ Not your ordinary html email tips（2008年4月8日時点のアーカイブ）
  6. ^ Premailer: make CSS inline for HTML e-mail
  7. ^ 電子メールHTML標準化を目指す - Email Standards Project発足
  8. ^ [1]
  9. ^ A pretty fair argument against HTML Email
  10. ^ RFC 1521 7.2.3. The Multipart/alternative subtype
  11. ^ TN1010-11-2: Multipart/Alternative — Gracefully handling HTML-phobic email clients. (PDF)
  12. ^ Sending HTML and Plain Text E-Mail Simultaneously
  13. ^ Do we really want to send web pages in e-mail?
  14. ^ HTML Email — Still Evil?
  15. ^ DOD bars use of HTML e-mail, Outlook Web Access（2007年9月21日時点のアーカイブ）

関連項目

外部リンク

「https://ja-two.iwiki.icu/w/index.php?title=HTML電子メール&oldid=65379385」から取得