[20] HTMLメールは、 HTML によって本文が記述された電子メールです。
HTML のみによって本文が記述されている場合と、 multipart/alternative
によって平文と HTML の両方が含まれている場合があります。
[45] HTML は HTML Standard で規定されていますが、電子メール固有の事項の規定は含まれていません。
[46] 次に示す通り MHTML などいくつかの要素技術は IETF などで仕様化されています (が90年代末頃に出版された後放置されている仕様書ばかりで、近代的な品質は持っていません)。
[47] しかしそれらの仕様書の規定を総合しても、HTMLメールを実装するのに十分な情報は得られません。 事実上、 HTMLメールは標準不在状態が続いています。これまで HTMLメールの標準化が試みられたことが幾度かありましたが、 いずれも成功していません。
[22] HTMLメールのように MIME と HTML を組み合わせた形態を MHTML
と呼び、90年代末に IETF で標準化されました。 MHTML では cid:
URL や Content-ID: ヘッダーによって他の MIME
本体部分の画像等を HTML に埋め込むことができます。また Content-Location:
ヘッダーによって MIME 本体部分の URL を記述することもできます。
[49] HTML と画像等は、 multipart/related によってひとまとめにします。
[21] 通常は安全上、実装上、その他の理由から完全な HTML ではなく、 HTML (や CSS その他関連技術) の一部だけが有効となっています。 ただ、どの一部分が有効かについては MUA によって様々です。 過去に標準化の試みが何度かなされましたが、成功したことはなく、 事実上の標準といえる部分集合すら明らかにはなっていない状態です。
[34] 制限方法は、実装によります。限定されたレンダリングエンジンを用いることもあれば、 不適切な要素を削除したり URL を書き換えたりするなどして変換を行った後に汎用のレンダリングエンジンで表示することもあります。
[25] HTMLメールから http: URL 等によって外部の画像等を参照できると電子メールのサイズを削減できたり、
送信時点ではなく最新の情報を表示できたり、便利なことがあります。しかしながら、
メールの送信者が受信者のメール閲覧行動をある程度把握できてしまうので、
プライバシー上の問題があります。
[26] Gmail など一般的な MUA は既定の状態では外部参照を無視し、 送信者等の条件で許可したメールにおいてのみ外部参照を有効とする実装になっているようです。
[27] 現在では Twitter や Facebook など主要なWebアプリケーションからの通知メッセージや Amazon 等の DM など、 HTMLメールで多くの画像等を含める場合には外部参照が一般的となっているようです。
[31] >>30 によると Gmail は Google を経由して画像を表示するようにしています。参照先のサーバーには Google のサーバーからのアクセスであることしかわかりませんし、 Google 側でウイルスチェックもしているとのことです。
[71] 現在では画像を利用した開封確認などの tracking が相当数の HTMLメールで行われるようになっています。 既定の状態では画像を表示しない MUA でも、画像を有効にする時に追跡の危険性を利用者に明確に説明していないのが現状です。
[72] MUA は img 要素のサイズ指定が異常に小さければ画像にアクセスしない、
サービス提供者のサーバーからアクセスする、といった対策により利用者のプライバシーを守ることを試みることはできますが、
完全ではありません。画像を有効にすることでプライバシー上のリスクが高まることを
MUA は利用者に十分警告するべきです。
[73] MUA は、画像の取得時に Cookie や認証情報を送信するべきではありません。 特に、通常の Webブラウザーの Cookie を送信することで Webブラウザーのセッションとメールの受信者が意図せず紐付けられることがないよう、 気をつけなければなりません。
[92] 追跡目的の画像は、 URL に受信者識別情報が埋め込まれていることが多いようです。 MUA は追跡目的であることがわかっている起源やサイトからの画像読み込みを拒否する機能を用意するべきでしょう。
[56] MHTML の一環で開発された cid: URL
により、他の本体部分の Content-ID を参照することができます。
[57] 通常は multipart/related で含めた他の本体部分を参照します。
cid: URL の仕様上はそれ以外の本体部分を参照することもできるはずですが、
どう実装されているのかは不明です。
[58] 理論上は画像などの埋め込みなどに限らず、 cid: URL
へのハイパーリンクなども記述はできますが、そのように実装されていることがあるのかは不明です。
利用例も見たことがありません。
[38] Gmail は schema.org データの埋め込みに対応しています。
[40] 明示的または暗示的に記述されたデータを使って、「詳細を見る」 のような機能を提供したり、 Gmail から Googleカレンダーへの自動登録を行ったりしているようです。
[101] Gmail Actions
[78] この機能を有効にするには、送信元ごとに Google に登録する必要があり、 Google が審査基準を提示しています >>77。
[41] HTML 本体仕様にも HTMLメールに関する規定がいくつかあります。
[42] Subject: によって題名が指定される電子メールのメッセージにおいては、
HTML文書の title 要素は省略できます。
multipart/* によって添付ファイルなどの形で含まれる
HTML文書は、 Subject: が直接適用される対象ではないので、
本規定の対象外と思われます。 multipart/alternative
や multipart/related なら、 Subject:
の直接の適用対象と解釈可能なので、省略できると思われます。 (HTML Standard
は HTMLメール自体を直接規定する仕様書ではないので、そのような詳細までは規定していません。
HTMLメールの仕様書は、現時点で存在していません。)[44] img 要素の alt 属性は、
当該電子メールの宛先がそれを必要としていないことが明確な場合には、
省略できます。
[50] MUA が送信する HTMLメールは、 multipart/alternative
により (自動生成された) text/plain と text/html
の2つの本体部分を含めるのが普通です。
[51] HTMLメールに対応しない MUA (古くからあるものや HTML
を実装したくないもの、メーリングリストのアーカイブなど) は
text/plain を表示します。
[52] Webアプリケーションからの通知メールやメールマガジンの類などでは、
text/html のみの HTMLメールが送られることもよくあります。
[82] 実際には意味のないデータや低品質のデータが含まれていることもよくあるようです (>>68)。 平文と HTML の両方が含まれている場合、 MUA は平文を無視して HTML だけ表示するべきだと思われます。非 GUI 環境の MUA も、HTML をテキストのみでレンダリングする方が平文部分を選択するより適切と思われます。
[53] 添付ファイルが存在する場合、 multipart/mixed
によって本文部分 (multipart/alternative、
multipart/related、text/html のいずれか)
と添付ファイルの本体部分を含めるのが普通です。
[54] HTML から参照される画像等は multipart/related
に含めるのが普通なので、添付ファイルとは区別されます。
[55] しかし MUA でどのように表示されるかは、 MUA 次第です。中には埋め込み画像等も添付ファイルとして扱うものもあります。
[23] 90年台中頃に HTMLメールが登場した頃は、まだテキスト・ベースのシステムへの信仰が根強く、 また MIME を正しく処理できない MUA が (送受信とも) 多かったこともあり、 HTMLメールは不適切な技術と受け止められました。特に Windows に同梱されていた Outlook Express などは、電子メールの標準に反する点が多かったこともあって、 HTMLメールが既定値である好ましからざる MUA として利用者を含めて攻撃の対象となりました。 当初は HTML と電子メールのセキュリティ上の問題も明確になっておらず、 しばしば脆弱性が発見されて問題になっていました。
[24] それでも HTMLメールの表現力は魅力的であり、携帯電話のデコレーション・メールや Webアプリケーション事業者等からの DM や通知メールに採用され、広まっていきました。 Thunderbird や Gmail をはじめ、2000年代以後に登場した MUA は HTMLメールの送受信ができるのが一般的になっています。
[35] 現在では MUA の新規メールの形式が HTMLメールとなっていることもかなり多くなっています。 ただし従来の平文メールと切り替えられるようになっているのが普通です。 平文メールに対する返信は平文メールとするような実装も一般的です。
[76] Webアプリケーションからの通知メールや、各企業からの宣伝メールなど、 機械的または不特定多数に対するメールも、最近は HTMLメールがかなり多くなっています。 かつては登録サイトで HTMLメールと平文のメールを選択できる場合もありましたが、 現在では無条件でHTMLメールが使われることがほとんどです。
[48] ガラケーでは、デコメなどの呼称で高機能なメールメッセージ形式として HTMLメールが採用されていました。全体的にはどのキャリアの形式も、 PC 用 MUA の HTMLメールと同じ形となっていました。しかし細部はいずれも互いに異なっていました。
[100] KDDI au: デコレーションメール > サポートタグ, https://www.au.com/ezfactory/tec/spec/decorations/support.html
[5] HTMLメールマーケティングガイド - HTMLメールのメール配信、効果測定、コンバージョン向上施策 - http://www.html-mail.jp/ (名無しさん 2006-08-12 05:42:54 +00:00)
[6]
CSS support in HTML emails of Hotmail, Yahoo! Mail and Gmail (2007-03-26 20:40:47 +09:00 版) http://www.xavierfrenette.com/articles/css-support-in-webmail/
(名無しさん)
[7]
Style In Email - css-discuss (2007-03-26 20:41:51 +09:00 版) http://css-discuss.incutio.com/?page=StyleInEmail
(名無しさん)
[8] [Interoperability] Implementation reports for HTML in mail clients and Good Practices (Karl Dubost 著, 版) https://lists.w3.org/Archives/Public/public-html-mail/2007Feb/0008.html
[10]
HTML Email Guide (2007-03-26 20:45:39 +09:00 版) http://www.anandgraves.com/html-email-guide
(名無しさん)
[11]
W3C HTML Mail Workshop - 24 May 2007 - Paris (2007-03-30 20:12:07 +09:00 版) https://www.w3.org/2007/05/html-mail/
(名無しさん 2007-03-31 08:37:24 +00:00)
[12]
WEBTECH - webtech:vantguarde (2007-04-03 08:30:53 +09:00 版) http://web.g.hatena.ne.jp/vantguarde/20070402#1175441443
(名無しさん 2007-04-02 23:32:17 +00:00)
[13]
W3C HTML Mail Workshop - List of Papers (2007-06-08 10:05:55 +09:00 版) http://www.w3.org/2007/05/html-mail/minutes
(名無しさん)
[14]
Writing a Team Submission for the HTML in mail Workshop (Karl Dubost 著, 2007-06-11 16:27:22 +09:00 版) http://lists.w3.org/Archives/Public/public-html-mail/2007Jun/0000.html
(名無しさん)
[15]
Keep HTML and CSS out of my inbox. Please. | 456 Berea Street (Roger Johansson 著, 2007-07-27 23:04:38 +09:00 版) http://www.456bereastreet.com/archive/200706/keep_html_and_css_out_of_my_inbox_please/
(名無しさん 2007-07-27 14:07:52 +00:00)
[16]
Help improve support for Web Standards in HTML email | 456 Berea Street (Roger Johansson 著, 2007-09-13 21:10:52 +09:00 版) http://www.456bereastreet.com/archive/200709/help_improve_support_for_web_standards_in_html_email/
(名無しさん)
[17]
Home | Email Standards Project (2007-12-08 10:30:01 +09:00 版) http://www.email-standards.org/
[18] The Email Standards Project launches | 456 Berea Street (Roger Johansson 著, 版) http://www.456bereastreet.com/archive/200712/the_email_standards_project_launches/
[19] 最近 Gmail のメール送信画面が新しいのになりましたが、今まで平文を選択していた人でも HTMLメールに勝手に切り替わっているようです。メール作成画面の設定から平文を再度選ぶことができますが、 意識しないと気づかないかもしれません。
[28] Enlisting the help of HTML mails ( (Bjoern Hoehrmann 著, 版)) http://lists.w3.org/Archives/Public/www-archive/2013Oct/0046.html
[29] HTML for email Community Group ( ( 版)) http://www.w3.org/community/htmail/
[36] Official Gmail Blog: Images Now Showing ( ( 版)) http://gmailblog.blogspot.jp/2013/12/images-now-showing.html
[37] Guide to CSS support in email | Campaign Monitor ( 版) https://www.campaignmonitor.com/css/
[59] HTML for email Community Group ( 版) https://www.w3.org/community/htmail/
[60] W3CGHtmail/compat-tables ( 版) https://github.com/w3cghtmail/compat-tables
[61] HTML for email Community Group ( 版) https://www.w3.org/community/htmail/wiki/Main_Page
[62] W3CGHtmail ( 版) https://github.com/W3CGHtmail
[63] CSSSpec - HTML for email Community Group ( 版) https://www.w3.org/community/htmail/wiki/CSSSpec
[64] Status Quo Email - HTML for email Community Group ( 版) https://www.w3.org/community/htmail/wiki/Status_Quo_Email
[65] Business reasons for a new HTML concept - HTML for email Community Group ( 版) https://www.w3.org/community/htmail/wiki/Business_reasons_for_a_new_HTML_concept
[66] Conventions for HTML in Email ( 版) http://www.w3.org/TR/1998/NOTE-HTMLThreading-0105
[67] public-htmail@w3.org Mail Archives ( 版) https://lists.w3.org/Archives/Public/public-htmail/
[68] HTMLメールの状況 2015/8 ( 版) http://wiki.suikawiki.org/n/HTML%E3%83%A1%E3%83%BC%E3%83%AB%E3%81%AE%E7%8A%B6%E6%B3%81%202015%2F8$25062
DFA のトラッキング方式では、1x1 ピクセルの画像を使用します。ユーザーがメールを開くか表示すると毎回、DFA 広告タグによってこの画像が呼び出され、DFA 広告サーバーに通知が送られます。1 回の表示が 1 インプレッションとしてカウントされます。クリック数をカウントする方法は、302 リダイレクト(仮想ディレクトリともいいます)、メタリフレッシュ(HTML リフレッシュともいいます)、クリック トラッカーの 3 種類です。
誰かがこのメールを開封すれば、上記HTMLコード(<img>タグ)によってトラッキングリンクURLが呼び出され、その結果として「1×1gifイメージ(1x1.gif)」が表示されます。
We are excited to see how you plan to use schemas in email. You can start testing your own integration today. All schemas you send to yourself (from x@gmail.com to x@gmail.com) will be displayed in Google products. So go ahead and try it out now!
When you are ready to launch your marked up emails to your users, you will need to register with Google.
[9] HTML Rendering - The Do's and Dont's of Cross-Platform Email Design - SendGrid Documentation | SendGrid ( (SendGrid著, )) https://sendgrid.com/docs/Classroom/Build/Format_Content/html_rendering__the_dos_and_donts_of_cross_platform_email_design.html
[83] CSS Prefixing · Issue #1 · W3CGHtmail/html-email-spec () https://github.com/W3CGHtmail/html-email-spec/issues/1
[84] G Suite Developers Blog: Your emails, optimized for every screen with responsive design () https://gsuite-developers.googleblog.com/2016/09/your-emails-optimized-for-every-screen-with-responsive-design.html
[85] CSS Support | Gmail & Inbox Sender Resources | Google Developers () https://developers.google.com/gmail/design/css
[86] Gmail Supported CSS Properties & Media Queries | Gmail & Inbox Sender Resources | Google Developers () https://developers.google.com/gmail/design/reference/supported_css
[87] JMAP HTML email security considerations (Neil Jenkins著, ) https://lists.w3.org/Archives/Public/public-webappsec/2018Apr/0022.html
[88] HTML email security considerations by neilj · Pull Request #197 · jmapio/jmap () https://github.com/jmapio/jmap/pull/197
[89] jmap-mail: security considerations for mail content · Issue #190 · jmapio/jmap () https://github.com/jmapio/jmap/issues/190
[90] () https://www.emailprivacytester.com/about
[91] Mike Cardwell / ept3 · GitLab () https://gitlab.com/mikecardwell/ept3
[93] EFAIL () https://efail.de/
[94] >>93 MIME を解釈して multipart を結合してから HTML として解釈する酷い MUA があるのか・・・。
[95] MIME は仕様書が曖昧過ぎるからそういう実装もあり得るとは思っていたけど、 まさか実在しているとは!
[97] インターネット経由でデコメールを送るには | サービス・機能 | NTTドコモ () https://www.nttdocomo.co.jp/service/developer/make/content/deco_mail/mechanism/internet/index.html
[98] デコメールタグ一覧 | サービス・機能 | NTTドコモ () https://www.nttdocomo.co.jp/service/developer/make/content/deco_mail/tag/index.html
[99] インターネット経由でデコメアニメを送るには | サービス・機能 | NTTドコモ () https://www.nttdocomo.co.jp/service/developer/make/content/deco_mail/decome_anime/mechanism/internet/index.html
[104] Xユーザーの鈴木うどんみさん: 「弊社の標的型メールの訓練、「京急が運賃改定したから出張旅費入れ直せ」って社内システムのフォーマットできて、しかもリンクがhtmlメールでURL偽装されており、当然引っかかった人が続出したんだが、いくらなんでも本気出し過ぎだと思う。あれはずるいわ。」 / X, , https://twitter.com/_udonchan_/status/1735940667946455060
[105] >>104 HTMLメール配信業者はたいていリンクのアクセス数計測の仕組みを用意していて、 本来の URL ではなく計測 URL にリンクしてリダイレクトさせる形の HTMLメールが世にはびこってる。これだとたとえリテラシーがある人でも、 クリック前にリンク先を確認することができない。 接続先がどこかわからないから MUA も対策のしようがない。 それがこういうフィッシング被害の温床になっている。
[106] 目先の利益のためにそういう技術的におかしくエコシステム全体を危険に晒す商売をやってる技術者倫理のかけらもない糞業者は反省しろ。 業界内で自主規制できないならもう法規制するしかなくなるぞ。