Loading article…
HTML メールは、プレーン テキストでは利用できない書式設定や意味的マークアップ機能を電子メールに提供するためにHTMLのサブセットを使用するものです。[ 1 ]テキストは、 URLを表示したり、長い URL を複数の部分に分割したりすることなくリンクできます。テキストは、各行を 78 文字で一律に分割するのではなく ( RFC 5322で定義されており、古いテキスト端末では必要でした)、表示ウィンドウの幅に合わせて折り返されます。画像、表、図、数式などを画像としてインラインで含めることができ、これらは通常 ( ASCII アートを使用して) 伝えるのが難しいものです。
ほとんどのグラフィカルメールクライアントはHTMLメールをサポートしており、多くはデフォルトでHTML形式を使用しています。これらのクライアントの多くは、 HTMLメールを作成するためのGUIエディタと、受信したHTMLメールを表示するためのレンダリングエンジンを両方備えています。
HTMLメールが誕生して以来、さまざまな理由から、多くの人々がHTMLメール（MIME自体も含む）に反対の声を上げてきました。 [ 2 ]例えば、ASCIIリボンキャンペーンでは、すべてのメールをASCIIテキスト形式で送信することを提唱しました。支持者は、意識啓発リボンのように見えるASCIIアートを署名ブロックに配置し、メッセージや啓発サイトへのリンクを添えました。このキャンペーンは成功せず、2013年に中止されました。[ 3 ] [ 4 ]
多くのニュースグループの投稿やメーリングリストでは依然として不適切とみなされているものの、個人用およびビジネス用メールにおけるHTMLの採用は時間とともに増加している。最初に登場した際に強く反対していた人々の中には、今ではほとんど無害だと考えている人もいる。[ 5 ]
オンラインマーケティング企業の調査によると、HTML対応のメールクライアントの採用はほぼ普遍的であり、テキストのみのクライアントを使用していると回答したユーザーは3%未満である。[ 6 ]ほとんどのユーザーは、プレーンテキストよりもHTMLメールを受信することを好む。[ 7 ] [ 8 ]
RFC 2822に準拠するメールソフトウェアは、プレーンテキストのみをサポートすればよく、HTML形式をサポートする必要はありません。そのため、HTML形式のメールを送信すると、受信者のメールクライアントがHTML形式をサポートしていない場合、問題が発生する可能性があります。最悪の場合、受信者は本来のメッセージではなくHTMLコードを見てしまうことになります。
HTMLをサポートするメールクライアントの中には、 W3Cの仕様に一貫して準拠してレンダリングしないものもあり、また多くのHTMLメール自体も仕様に準拠していないため、レンダリングや配信に問題が生じる可能性があります。
特に、<head>HTML ドキュメント全体の CSS スタイル ルールを格納するために使用されるタグは、十分にサポートされておらず、完全に削除されることもあり、インライン スタイル宣言が事実上の標準となっていますが、インライン スタイル宣言は非効率的で、スタイルとコンテンツを分離するHTML の機能を十分に活用できていません。回避策は開発されていますが、[ 9 ]これはニュースレター開発者の間で不満を引き起こし、Web Standards Projectに触発されたAcid テストのレンダリングに基づいて電子メール クライアントを評価し、開発者に製品を改善するよう働きかける草の根のEmail Standards Project が生まれました。たとえば、 GoogleにGmailのレンダリングを改善するよう説得するために、Google は顔をしかめる Web 開発者のビデオ モンタージュを公開し、[ 10 ]従業員の注目を集めました。
送信者によっては、大きくてカラフルなフォントや、注意をそらすようなフォントを過度に使用し、メッセージの読みにくさを増す場合があります。[ 12 ]このような書式設定が特に気になるユーザーのために、一部のユーザーエージェントでは、読み手が書式設定を部分的に上書きできるようになっています（例えば、Mozilla Thunderbird では最小フォントサイズを指定できます）。ただし、これらの機能はグローバルに利用できるわけではありません。さらに、送信者と読み手の視覚的な外観の違いは、各セクションの作成者を区別するのに役立ち、読みやすさを向上させます。
多くの電子メールサーバーは、 RFC 1521で規定されているように、テキストのみの電子メールクライアントでも読めるように、メッセージのプレーンテキスト版を自動的に生成し、HTML 版と一緒に送信するように構成されています。[ 13 ] [ 14 ] [ 15 ]メッセージ自体はタイプであり、2 つの部分から構成されています。最初の部分はタイプで、テキストのみのクライアントで読み取られ、2 番目の部分はで、HTML 対応のクライアントで読み取られます。ただし、プレーンテキスト版には重要な書式情報が欠落している可能性があります。（たとえば、数式の上付き文字が失われ、まったく新しい意味になる場合があります。）Content-Type: multipart/alternativemultipart/alternativetext/plaintext/html
多くのメーリングリストは意図的にHTMLメールをブロックしており、HTML部分を削除してプレーンテキスト部分だけを残すか、メッセージ全体を拒否するかのいずれかの方法で対応している。
パートの順序は重要です。RFC1341では、次のように述べられています。一般に、multipart/alternativeエンティティを構成するユーザーエージェントは、本文パートを優先順位の高い順に配置する必要があります。つまり、優先フォーマットを最後に配置します。 [ 16 ] HTMLバージョンとプレーンテキストバージョンを含むマルチパートメールの場合、プレーンテキストバージョンを最初にリストし、その後にHTMLバージョンをリストする必要があります。そうしないと、HTMLバージョンが利用可能であっても、クライアントはデフォルトでプレーンテキストバージョンを表示する可能性があります。
HTML メールはプレーンテキストよりも大きくなります。特別な書式設定が使用されていなくても、最小限の HTML ドキュメントで使用されるタグによるオーバーヘッドがあり、書式設定が多用されている場合はさらに大きくなる可能性があります。同じコンテンツの複製が異なる形式で含まれるマルチパート メッセージは、サイズをさらに大きくします。ただし、マルチパート メッセージのプレーンテキスト セクションは、IMAPの FETCH コマンドを使用して単独で取得できます。[ 17 ]
プレーンテキストメールと混合メッセージメールのダウンロード時間の差（10倍以上になることもある）は、1990年代（ほとんどのユーザーが低速モデム経由でメールサーバーにアクセスしていた時代）には問題視されていたが、現代の接続環境では、特に画像、音楽ファイル、その他の一般的な添付ファイルと比較した場合、ほとんどの人にとってその差は無視できる程度である。[ 18 ]
HTMLでは、リンクを非表示にして、ユーザーにとって分かりやすいターゲット名など、任意のテキストとして表示させることができます。これはフィッシング攻撃に悪用される可能性があり、ユーザーを騙して偽のウェブサイトにアクセスさせ、銀行口座番号などの個人情報を詐欺師に漏らしてしまうことになります。
メールに画像などの外部サーバーからのインラインコンテンツが含まれている場合、それを取得するには、画像の表示場所や受信者に関するその他の情報を特定する外部サーバーへのリクエストが必要です。 ウェブバグは、メールを追跡し、メールが開かれたことを作成者に知らせるために特別に作成された画像（通常は個々のメールごとに固有）です。これにより、メールアドレスが実在することが明らかになり、将来的に標的にされる可能性があります。
フィッシング攻撃の中には、HTMLの特定の機能を利用するものがあります。[ 19 ]
HTMLコンテンツを表示する際には、クライアントプログラムがHTMLで記述されたテキストを解析・レンダリングするための特別なルーチンを呼び出すことが頻繁に発生します。意図的に誤ったコードが記述されたコンテンツは、これらのルーチンの欠陥を悪用してセキュリティ侵害を引き起こす可能性があります。また、特殊なフォントなどの要求もシステムリソースに影響を与える可能性があります。
ネットワークの脅威が増加する期間中、米国国防総省はユーザーの受信HTMLメールをテキストメールに変換した。[ 20 ]
マルチパート形式は、同じコンテンツを異なる方法で表示するために設計されていますが、悪用されることもあります。一部のスパムメールは、この形式を利用してスパムフィルターを欺き、メッセージが正当なものであると誤認させます。具体的には、メッセージのテキスト部分に無害なコンテンツを記述し、スパムメールの内容をHTML部分（ユーザーに表示される部分）に挿入することで、これを実現しています。
これらの理由から、ほとんどのスパムメールはHTML形式で送信されるため、スパムフィルターはHTML形式のメッセージに対してより高いスパムスコアを与えることがある。
2018年に、多くの一般的な電子メールクライアントのHTML処理における脆弱性（EFAIL ）が明らかにされました。この脆弱性では、外部画像が要求された場合、 PGPまたはS/MIMEで暗号化された電子メール部分の復号化されたテキストが、外部画像アドレスの属性として送信される可能性があります。この脆弱性は、Thunderbird、macOS Mail、Outlook、そして後にGmailとApple Mailに存在していました。[ 21 ]
は消費者の間でほぼ普遍的に採用されています。Jupiter Researchの消費者調査によると、テキストメールのみを受信している人はわずか3%でした。
メールとテキストメールのどちらを好みますか？HTML：41.95%、テキスト：31.52%、どちらでも可：26.53%
企業からのメールはどの形式で受け取るのが好みですか？HTML：88%、プレーンテキスト：12%