SMTP TLSレポーティングとは？
MTA-STS運用の要
2024年3月18日
著者: Yunes Tarada
翻訳: 竹洞 陽一郎
この記事はPowerDMARCのブログ記事 SMTP Yahoo Error Codes Explained の翻訳です。
Spelldataは、PowerDMARCの日本代理店です。
この記事は、PowerDMARCの許可を得て、翻訳しています。
組織がメールを主要なコミュニケーション手段として利用する中で、潜在的な脅威からこれらのチャネルを守ることの重要性は非常に高まっています。
Transport Layer Security（TLS）は、ネットワークを介して送信されるデータの機密性と完全性を確保します。
SMTPメッセージチャネルを暗号化して、サイバー攻撃者によるメール通信の傍受を防ぐためのプロトコルには、STARTTLS、DANE、MTA-STSなどがあります。
しかし、これらのプロトコルを使用して暗号化が試みられた際に失敗した場合、メールが配信されないことがあります。
TLS-RPT（RFC 8460で記載されている）は、これらの配信失敗に関する報告メカニズムを提供します。
TLS-RPTをMTA-STSプロトコルと併用することを強く推奨します。
これらのプロトコルがどのように連携してメールセキュリティを強化するのかを理解しましょう。
TLS-RPTとは?
TLS-RPT（Transport Layer Security Reporting）は、TLSで暗号化されていないメールの配信問題を報告するための標準規格です。
TLS暗号化を有効にする理由と同様に、TLS-RPTはメール認証において重要な役割を果たします。
TLS暗号化は、送信されたすべてのメールが安全に配信されることを保証します。
しかし、接続が安全でない場合、メールが配信されないことがよくあります。
TLS-RPTを使用することで、ドメイン所有者はメール配信や接続の失敗を監視することが可能になります。
報告には次の情報が含まれます。
- MTA-STSポリシー処理の問題
- 配信失敗の理由と種類
- メール送信および受信のメール転送エージェント（MTA）のIPアドレス
- TLS接続セッションの成功および失敗の総数
これにより、メールチャネルの可視性が向上し、配信上の課題に迅速に対応できるようになります。
TLSレポートの仕組み
SMTPメール通信では、TLS暗号化は「日和見主義（opportunistic）」です。
これは、暗号化されたチャネルを確立できない場合でも、メールが暗号化されていない形式（プレーンテキスト）で送信されることを意味します。
実際、約40年前にはSMTPメールプロトコルはTLS暗号化をサポートしておらず、後からSTARTTLSコマンドとして導入されました。
STARTTLSコマンドは、SMTP通信で双方がTLS暗号化をサポートしている場合にのみ実行されます。
そうでない場合、メールは依然としてプレーンテキストで送信されます。
SMTPの日和見的暗号化を解消するために、MTA-STS（RFC8461）が導入されました。
MTA-STSプロトコルは、メールが配信される前に暗号化されることを保証します。
メールサーバーまたはメール転送エージェント（MTA）は、受信側のサーバーがSTARTTLSコマンドをサポートしているかどうかを確認します。
サポートしている場合、メールはTLSで暗号化されて配信されます。
サポートしていない場合、配信は失敗します。
TLS暗号化が失敗する理由には、双方の暗号化サポートの欠如に加え、SMTPダウングレード攻撃などの悪意ある理由も含まれます。
MTA-STSが有効になっている場合、接続が失敗すると攻撃者はプレーンテキストでのメッセージ配信に成功することはできません。
ドメイン所有者は配信失敗の詳細を知りたいと考えるでしょう。
TLS-RPTは、これを通知するプロトコルです。
配信失敗時、TLSレポートはTLS-RPTレコードで定義されたメールアドレスにJSONファイル形式で送信されます。
どうしてSMTP TLSレポートが必要なのか？
SMTP TLSレポート（TLS-RPT）は、TLS暗号化の失敗によるメール配信問題について、ドメイン所有者が情報を得るために必要です。
- メール配信問題の把握
- MTA-STSが有効なドメインから送信されたメールにおいて、TLS暗号化の失敗が原因で発生する配信問題について把握できます。
- ポリシータイプの特定
- フィードバックレポートを受け取り、自ドメインに適用されているポリシーの種類を確認できます。
- TLS暗号化失敗の原因特定
- 暗号化が失敗した原因を特定し、潜在的な問題を解決する手助けをします。
- メールチャネルの可視化
- ドメインのメール通信状況を把握し、セキュリティおよび運用効率を向上させます。
- 配信問題の修正
- 配信に関する問題を特定し、迅速に修正することでメールの確実な送信を確保します。
TLS-RPT設定手順
TLSレポート（TLS-RPT）を有効にするには、ドメインのDNSにTLS-RPT用のTXTレコードを作成し公開する必要があります。
このレコードは、smtp.tls.yourdomain.comのサブドメインに公開する必要があります。
- ステップ1: TLS-RPTレコードジェネレーターの選択
-
無料で利用できるPowerDMARCのTLS-RPTレコードジェネレーターにサインアップして、レコードを作成します。
- ステップ2: レポート用メールアドレスの入力
-
SMTP TLSレポートを受信したいメールアドレスを入力します。
- ステップ3: TLSレコードをDNSに公開
-
ドメインレジストラに連絡して、新しいTLS-RPT用のTXTレコードを作成してもらいます。
自身でDNSを管理している場合は、DNS設定を編集してレコードを追加します。
TLS-RPTレコードの例
v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com;
以下は、提供されたTLSレポートレコードの2つの構成要素の詳細です。
v=TLSRPTv1-
このタグは、使用しているTLS-RPTプロトコルのバージョンを指定します。
ここでは"TLSRPTv1"がプロトコルのバージョン1であることを示しています。 rua=mailto:tlsrpt@yourdomain.com-
ruaは"Reporting URI(s) for Aggregate Data"の略で、このタグは受信者のメールサーバが集計されたTLSレポートを送信する宛先を指定します。
レポートの受け取り先を複数設定することも可能です。複数の宛先を指定する場合、それぞれのエントリをカンマ (,) で区切ります。
このフィールドにはmailto:を使用してメールアドレスを指定するか、https:を使用してPOSTを通じてエンドポイントURLにレポートを送信するようにMTAを指示することができます。
https:を使用する場合、このフィールドは有効な証明書を持つHTTPS対応のWebサーバのURLを定義する必要があります。
mailto:とhttps:を単一のレコード内でカンマで区切って併用することも可能です。v=TLSRPTv1; rua=mailto:tlsrpt@example.com,https://tlsreport.example.com;
注意: 実際には yourdomain.comを、これらのレポートを受け取りたい実際のドメイン名に置き換えてください。
TLSレポート形式
TLSレポートはJSON形式で送信されます。
以下は、JSON形式のTLSレポートの例です。
{
"organization-name": "Organization Inc.",
"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",
"policies": [
{
"policy": {
"policy-type": "sts",
"policy-string": [
"version: STSv1",
"mode: testing",
"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レポート内の主要なフィールドの詳細は以下の通りです。
| フィールド名 | 説明 |
|---|---|
| organization | TLS-RPTレコードを所有するドメイン組織名。 |
| 集計レポートが送信されるメールアドレス。 | |
| begin_date | レポート期間の開始日。 |
| end_date | レポート期間の終了日。 |
| policies | レポート期間中に適用されたポリシーを説明するポリシーオブジェクトの配列。 |
| policy | 適用されたポリシーに関する情報を含むフィールド。 |
| policy_type | ポリシーの種類を指定。 |
| policy_string | ポリシーに関連付けられた文字列を指定。 |
| mode | MTA-STSポリシーモードを指定（例: EnforceまたはTesting）。 |
| summary | 試行されたセッションに関する概要情報を含むフィールド。 |
| total_successful_session_count | 成功したTLSセッションの総数。 |
| total_failure_session_count | TLSセッションの失敗総数。 |
| failure_details | 特定の失敗に関する詳細を提供するオブジェクトの配列。 |
| reason | 失敗の理由を示す文字列（例: "certificate_expired"）。 |
| count | 特定の理由で失敗したセッションの回数。 |
TLS暗号化の失敗の理由と種類
| 失敗の種類 | 理由 | 考えられるトラブルシューティングの提案 |
|---|---|---|
| certificate_expired | リモートサーバーが提示した証明書の有効期限が切れており、暗号化には信頼できません。 | 証明書を更新してください。 |
| certificate_not_valid_yet | リモートサーバーが提示した証明書がまだ有効ではありません。これはサーバーの時間設定ミスや証明書の早期使用が原因かもしれません。 | 証明書提供元に連絡してください。 |
| certificate_revoked | リモートサーバーが提示した証明書がセキュリティ上の理由で認証局によって失効されています。 | 証明書提供元に連絡してください。 |
| no_valid_signature | リモートサーバーが提示した証明書チェーンが送信者のメールサーバーまたはクライアントによって信頼されておらず、セキュリティリスクを示しています。 | 証明書提供元に連絡してください。 |
| unsupported_certificate | リモートサーバーが提示した証明書が、送信者のメールサーバーでサポートされていない暗号化アルゴリズムや鍵長を使用しており、安全な接続を妨げています。 | 証明書提供元に連絡してください。 |
| 失敗の種類 | 理由 | 考えられるトラブルシューティングの提案 |
|---|---|---|
| hostname_mismatch |
サーバーの証明書に指定されたホスト名が、送信者のメールサーバーが接続しようとしているサーバーのホスト名と一致しません。 これにより、中間者攻撃の可能性や設定の問題が示唆されます。 |
MTA-STSポリシーファイル内のMXレコードが、ドメインのMXレコードと一致しているか確認してください。 |
| 失敗の種類 | 理由 | 考えられるトラブルシューティングの提案 |
|---|---|---|
| handshake_failure | 送信者のメールサーバーと受信者のメールサーバー間でのTLSハンドシェイクプロセス中に問題が発生し、安全なチャネルを確立できませんでした。 |
SMTP STARTTLS接続が確立されているかを再確認してください。 STARTTLSのサポート不足やTLSダウングレード攻撃など、暗号化失敗の原因が考えられます。 |
| 失敗の種類 | 理由 | 考えられるトラブルシューティングの提案 |
|---|---|---|
| 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_policy_fetch_error | 送信者のメールサーバーが、受信者のドメインのDNSレコードからMTA-STSポリシーを取得しようとした際にエラーが発生した場合に発生します。 | DNS内のMTA-STSレコードを検証し、レコードの構文が正しいことを確認してください。 |
| mta_sts_connection_failure | 送信者のメールサーバーがMTA-STSを使用して安全な接続を確立しようとした際に、信頼されていない証明書、非対応の暗号スイート、その他のTLS問題が原因で失敗した場合に発生します。 | 証明書の有効性を確認し、最新のTLS標準に準拠した証明書であることを確認してください。 |
| mta_sts_invalid_hostname | MTA-STSポリシーに指定された受信者のメールサーバーのホスト名が、実際のサーバーのホスト名と一致しない場合に発生します。 | MTA-STSポリシーファイル内のMXレコードが、ドメインのMXレコードと一致しているかを確認してください。 |
PowerDMARCによる簡易化されたSMTP TLSレポート
PowerDMARCのSMTP TLSレポートサービスは、セキュリティを強化すると同時に、ホスティングサービスを通じて使いやすさを提供します。
- 簡易化されたTLSレポート
-
複雑なTLS-RPTのJSON形式レポートを、数秒でざっと確認できる簡潔な情報に変換します。
また、詳細な読み取りも可能です。 - 問題の自動検出
- PowerDMARCプラットフォームは、直面している問題を特定してハイライト表示します。これにより、時間を無駄にせず迅速に解決できます。
PowerDMARCプラットフォームについて気に入らない点は一つもありません。
使いやすく、理解しやすいレイアウトを備えています。
ホスティングされたDMARC管理、SPFフラットニング、SPFのincludeを簡単に拡張してレコードの詳細を検査できる機能、さらにはMTA-STSとTLS-RPTの完全サポートと、まさにフル機能と言えるものを提供しています。
Dylan B (ビジネスオーナー)
トランスポート層セキュリティに関するよくある質問
- 1. TLSとは何の略ですか？
- TLSは「Transport Layer Security（トランスポート層セキュリティ）」の略です。
- 2. TLS証明書は誰が発行しますか？
-
TLS証明書は認証局（Certificate Authorities、CAs）が発行します。
証明書発行のプロセスでは、証明書所有者の身元確認が行われます。
確認が成功すると、証明書が発行されます。 - 3. TLS証明書が必要な理由は何ですか？
-
TLS証明書は、インターネット上での通信を保護する上で重要な役割を果たします。
通信するWebサーバー間でやり取りされる機密情報を暗号化するのに役立ちます。
一般的な用途には、メール通信の保護やHTTPSの実現が含まれます。 - 4. 現在のTLS標準は何ですか？_
-
TLS 1.3が最新のトランスポート層セキュリティのバージョンです。
TLS-RPTは、TLSの任意のバージョンで実装可能です。
これには、旧バージョンや将来のバージョンも含まれます。
使用されるバージョンは、通常、通信するサーバーの機能などの基準によって決定されます。