SMTP TLS Reportingとは何ですか？

ユネス・タラダ

3ヶ月前

読書時間 8 分

組織が主要なコミュニケーション手段として電子メールに依存するようになるにつれ、潜在的な脅威から電子メール・チャネルを強化することの重要性は、いくら強調してもし過ぎることはありません。トランスポート・レイヤー・セキュリティ（TLS）は、ネットワークを介して送信されるデータの機密性と完全性を確保するための礎石です。

いくつかのプロトコルは、サイバー攻撃者による電子メール通信の傍受を防ぐため、SMTPメッセージチャネルの暗号化に役立ちます。これにはSTARTTLS、DANE、MTA-STSが含まれます。しかし、これらのプロトコルを使用しているときに暗号化の試みが失敗すると、メールが配信されないことがあります。 TLS-RPT ( RFC 8460)は、このような配信失敗を報告するフィードバックメカニズムを提供します。

TLS-RPTは、以下のものと組み合わせて使用することを強くお勧めします。 MTA-STSプロトコルと併用することを強くお勧めします。これらのプロトコルがどのように連携して電子メールのセキュリティを強化するのかを理解しよう。

TLS-RPTとは何ですか？

TLS-RPTとは、Transport Layer Security Reportingの略です。これは、電子メールがTLSで暗号化されていない場合に発生する電子メール配信の問題を報告するための規格です。電子メール認証におけるTLS-RPTの重要性は、電子メールのTLS暗号化を有効にする理由と密接に関係しています。

TLS暗号化により、送信されたメールはすべて安全に配信されます。接続が安全でない場合、メールが配信されないことが多々あります。TLS-RPTは、ドメイン所有者がメールの配信や接続障害を監視することを可能にします。レポートには以下の情報が含まれます：

MTA-STSポリシーの処理に関する問題
配達不能の理由と種類
メール送受信代行業者のIPアドレス
成功したTLS接続セッションと失敗したTLS接続セッションの合計数

これにより、メールチャネルを可視化し、配信上の課題に迅速に対処することができます。

TLSレポートの仕組み

SMTP電子メール通信では、TLS暗号化は「日和見的」である。つまり、暗号化チャネルがネゴシエートできない場合、電子メールは暗号化されていない（プレーンテキスト）フォーマットで送信される。実際、40年近く前、SMTP電子メールプロトコルはTLS暗号化をサポートしていなかった。後にSTARTTLSコマンドという形で後付けしなければならなかったのだ。

STARTTLSコマンドは、SMTP通信で双方がTLS暗号化をサポートしている場合にのみ発行される。そうでない場合、メールはプレーンテキストのまま送信される。

SMTP における日和見的暗号化を排除するために、MTA-STS が導入された (RFC 8461).MTA-STSプロトコルは、電子メールが配信される前に暗号化されることを保証します。メールサーバーまたはメール転送エージェント（MTA）は、受信サーバーがSTARTTLSコマンドをサポートしているかどうかを確認するために、受信サーバーとネゴシエートします。対応していれば、メールはTLSで暗号化されて配信されます。そうでない場合、配信は失敗します。

TLS暗号化の失敗にはいくつかの理由が考えられる。どちらの側にも暗号化のサポートがない以外に、SMTPダウングレード攻撃など、より不吉な理由がTLS接続の失敗につながることがある。.MTA-STSを有効にすると、接続が失敗した場合、攻撃者はプレーンテキストでメッセージを配信することができなくなる。

しかし、ドメイン所有者は配信失敗について知りたいと思うだろう。TLSレポート（TLS-RPT）は、あなたに通知するプロトコルです。配信に失敗すると、TLS-RPTレコードで定義されたメールアドレスにJSONファイル形式でTLSレポートが届きます。

なぜSMTP TLSレポートが必要なのか？

ドメイン所有者は、Eメールについて常に情報を得る必要がある。

MTA-STS対応ドメインから送信されたメールのTLS暗号化の失敗による配信の問題。TLSレポートは、この情報を提供することでこれを可能にする。TLS-RPT

ご契約の保険タイプにハイライトを当てたフィードバック・レポートを受け取るには
TLS暗号化に失敗した原因を特定するには
Eメールチャネルで認知度を高める
配送に関する問題を解決する

TLS-RPTの設定手順

TLS-RPTのTXTレコードを作成し、DNSで公開することで、ドメインのTLSレポートを有効にできます。このレコードは、サブドメイン smtp.tls.yourdomain.comで公開する必要があります。

ステップ1：TLS-RPTレコード生成ツールの選択

あなたはサインアップPowerDMARCに無料でサインアップし、TLS-RPTレコードジェネレーターを使ってレコードを作成してください。

ステップ2：報告用メールアドレスを入力

SMTP TLS レポートを受信するメールアドレスを入力します。

ステップ3：DNSでTLSレコードを公開する

ドメインレジストラに連絡して、TLS-RPTの新しいTXTレコードを作成することができます。自分でDNSを管理している場合は、DNS設定を編集してレコードを含めます。

TLS-RPTレコードの例

構文：v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com；

提供されたTLS報告記録の2つの構成要素を分解してみよう：

v=TLSRPTv1： このタグは、使用するTLS-RPTプロトコルのバージョンを指定する。この場合 「TLSRPTv1" はプロトコルの最初のバージョンを示す。
rua=mailto:tlsrpt@yourdomain.com： ruaは「Reporting URI(s) for Aggregate Data」の略である。このタグは、受信者のメールサーバーが集計されたTLSレポートをどこに送るかを指定する。

レポートの受信先を複数設定できます。複数の宛先を指定する場合は、コンマ（,）で区切ってください。このステップでは、"maito: "を使用してメールアドレスを指定するか、rua=フィールドに "https: "を使用して、エンドポイントURLへのPOST経由でレポートを送信するようにMTAに指示することができます。https:" を使用する場合は、フィールドに "https:" が定義されていることを確認すること。を使用する場合、フィールドが有効な証明書を持つ HTTPS 対応ウェブサーバーへの URL を定義していることを確認してください。mailto:」と「https:」の両方を、カンマで区切って1つのレコードに使用することもできます。

例：v=TLSRPTv1; rua=mailto:tlsrpt@example.com,https://tlsreport.example.com；

注意： 実際には"を" を、これらのレポートを受け取りたい実際のドメイン名に置き換えます。

TLS報告書フォーマット

TLSレポートはJSON形式で送信されます。下記はJSON TLSレポートの例です：

{

"組織名"：「株式会社組織

“date-range”: {

"start-datetime"：“2020-10-22T00:00:00Z”,

"end-datetime"：“2020-10-22T23:59:59Z”

「contact-info"："smtp-tls-reporting@organization.com"、

"report-id"：“2020-10-22T00:00:00Z_domain.com”,

"ポリシー"：[

{

“policy”: {

"policy-type"："sts"、

"policy-string"：[

「バージョンSTSv1」、

「モード：テスト」、

「mx: mx.domain.com」、

「mx: mx2.domain.com」、

"mx：mx3.domain.com"、

"max_age：604800"

"policy-domain"："domain.com"

“summary”: {

"total-successful-session-count"：15,

"total-failure-session-count"：0

}

このJSON TLSレポートの主なフィールドの内訳は以下の通りです：

フィールド	説明
組織	TLS-RPTレコードを所有するドメイン組織。
電子メール	集計レポートを送信するEメールアドレス。
開始日	報告期間の開始日。
終了日	報告期間の終了日。
政策	報告期間中に適用されたポリシーを記述するポリシーオブジェクトの配列。
方針	適用されたポリシーに関する情報が含まれています。
ポリシータイプ	ポリシーの種類を指定する
ポリシーの文字列	ポリシーに関連するポリシー文字列を指定します。
モード	MTA-STS ポリシーモード (Enforce/Testing) を指定します。
概要	試行されたセッションの概要情報を含む。
合計成功セッション数	正常に確立されたTLSセッションの総カウント。
合計失敗セッション数	TLSセッションの失敗の総カウント。
失敗の詳細	特定の失敗についての詳細を提供するオブジェクトの配列。
理由	失敗の理由を示す文字列（例："certificate_expired"）。
カウント	特定の理由で失敗したセッション数。

TLS暗号化の失敗の理由と種類

証明書の問題

故障の種類	理由	考えられるトラブルシューティングの提案
証明書_期限切れ	リモート・サーバーが提示した証明書は有効期限を過ぎている。このため、暗号化には信頼できない。	証明書を更新してください。
まだ有効でない証明書	リモートサーバーが提示した証明書がまだ有効でない。これは、サーバーの時刻が正しくないか、証明書の使用時期が早まっている可能性があります。	証明書プロバイダーに問い合わせる。
証明書失効	リモートサーバーが提示した証明書が、セキュリティ上の懸念から認証局によって失効された。	証明書プロバイダーに問い合わせる。
no_valid_signature	リモートサーバーが提示した証明書チェーンが、送信者のメールサーバーまたはクライアントによって信頼されておらず、潜在的なセキュリティリスクを示している。	証明書プロバイダーに問い合わせる。
未対応証明書	リモートサーバーが提示する証明書は、送信者のメールサーバーがサポートしていない暗号化アルゴリズムまたは鍵長を使用しており、安全な接続を妨げている。	証明書プロバイダーに問い合わせる。

ホスト名とIDの不一致

故障の種類	理由	考えられるトラブルシューティングの提案
ホスト名不一致	サーバーの証明書で指定されたホスト名が、送信者のメールサーバーが接続しようとしているサーバーのホスト名と一致しない。これは中間者攻撃の可能性または設定の問題を示しています。	MTA-STSポリシーファイルのMXレコードを確認し、ドメインのMXレコードと一致していることを確認します。

ハンドシェークとプロトコルの問題

故障の種類	理由	考えられるトラブルシューティングの提案
握手失敗	送信者のメールサーバーと受信者のメールサーバー間の最初のTLSハンドシェイク処理中に問題が発生し、セキュアチャネルが確立されませんでした。	SMTP STARTTLS接続が確立されているか再確認する。STARTTLSのサポート不足やTLSダウングレード攻撃など、暗号化に失敗する原因はいくつか考えられます。

MTA-STSの政策課題

故障の種類	理由	考えられるトラブルシューティングの提案
MTA_STS_POLICY_NOT_FOUND	この失敗は、送信者のメールサーバーが受信者のドメインのMTA-STSポリシーを見つけられないときに発生する。	MTA-STSポリシーファイルを確認してください。 MTA-STSレコードを確認し、正しくパブリッシュされていることを確認してください。
MTA_STS_POLICY_INVALID	この失敗は、受信者のドメインのDNSで見つかったMTA-STSポリシーが無効であるか、エラーが含まれているか、MTA-STS仕様に準拠していない場合に発生する。	MTA-STSポリシーファイルを確認してください。適切なMTA-STSポリシーモードを指定します。None、Enforce、またはTestingのいずれかを指定します。これは、MTA-STSポリシーの検証に失敗したメールをどのように処理するかを送信サーバーに指示します。政策モードについての詳細はこちら。
MTA_STS_POLICY_FETCH_ERROR	この失敗は、送信者のメールサーバーが受信者のドメインのDNSレコードからMTA-STSポリシーを取得しようとしてエラーが発生したときに起こる。	DNSのMTA-STSレコードを検証し、レコード構文が正しいことを確認します。
MTA_STS_CONNECTION_FILURE	この失敗は、送信者のメールサーバーがMTA-STSを使用して安全な接続を確立しようとしたが、信頼できない証明書、サポートされていない暗号スイート、またはその他のTLSの問題などの理由で失敗した場合に発生する。	証明書の有効性を確認し、証明書が最新のTLS規格に対応していることを確認してください。
mta_sts_invalid_hostname	この失敗は、MTA-STSポリシーで指定された受信者のメールサーバーのホスト名が、サーバーの実際のホスト名と一致しない場合に発生する。	MTA-STSポリシーファイルのMXレコードを確認し、ドメインのMXレコードと一致していることを確認します。