MTA-STSとは何ですか?
MTA-STS (Mail Transfer Agent Strict Transport Security) を使用すると、ドメインは、受信 SMTP 接続で有効な証明書を持つ TLS を使用する必要があることを宣言できます。これは、_mta-sts.yourdomain.com の DNS TXT レコードと、mta-sts.yourdomain.com/.well-known/mta-sts.txt で HTTPS 経由で提供されるポリシー ファイルを組み合わせます。 DNS レコードは、ポリシーが存在することをアドバタイズし、ポリシーが更新されるたびに変更される ID を伝えます。
MTA-STS がないと、SMTP の便宜的な TLS が攻撃者によってパス上でサイレントに剥奪され、メールが平文で配信されるようになります。 MTA-STS は、TLS をネゴシエートできない場合に送信サーバーに配信を拒否するよう指示することで、そのギャップを埋めます。これは、送信者がポリシーを遵守できない場合に電子メールで報告する TLS-RPT と自然に組み合わされます。この標準は RFC 8461 で定義されています。
MTA-STS レコードを確認する理由は何ですか?
1ポリシーが検出可能であることを確認する
DNS レコードが欠落しているか形式が正しくない場合、送信者はポリシー ファイルを検索しません。解決されていることを確認してください。
2決して変更されない ID を取得する
ID はポリシーが変更されるたびに更新する必要があります。そうでない場合、キャッシュが古いポリシーを提供します。チェッカーによって現在の値が表示されます。
3サイレント TLS ダウングレードを防止する
作業記録は送信者に暗号化を要求するよう通知し、送信中のメールを傍受から保護します
4強制モードの前に検証する
テストモード中にレコードとポリシーが一致していることを確認して、強制に切り替えても正当なメールが返送されないようにする
MTA-STS の仕組み — ステップバイステップ
モード、MX ホスト、および max_age を記述したポリシー ファイルを https://mta-sts.yourdomain.com/.well-known/mta-sts.txt でホストします。
バージョンと一意の ID を含む TXT レコードを _mta-sts.yourdomain.com で公開します。
TXT が記録するメール クエリを配信しようとしている送信サーバーは、アドバタイズされているポリシーを確認します。
HTTPS ポリシー ファイルを取得し、受信した MX とその TLS 証明書をそれに対して検証します。
ポリシーが強制モードであり、TLS を検証できない場合、送信者は平文に戻すのではなく、配信を拒否します。
MTA-STS レコードの構文
_mta-sts.example.com. 3600 IN TXT "v=STSv1; id=20240118T120000Z"
# https://mta-sts.example.com/.well-known/mta-sts.txt
version: STSv1
mode: enforce
mx: mail.example.com
max_age: 604800DNSタグの内訳
v=STSv1— プロトコルのバージョン、常に最初id=— 一意のトークン、ポリシー更新ごとに変更ポリシーファイルのフィールド
一般的な MTA-STS の障害と修正
ポリシーファイルに到達できません
.well-known ファイルは、有効な証明書を使用して HTTPS 経由でロードする必要があります。送信者が適用する前にホストを修正してください。
古いID
ポリシーを編集した後に ID をバンプするのを忘れると、送信者は古い ID を保持することになります。更新のたびに ID を変更します。
MX の不一致
mx エントリが実際の MX レコードと一致しない場合、強制モードにより正当なメールがブロックされ、メールの同期が維持されます。
まっすぐにジャンプして強制する
TLS-RPT を使用してテストを開始し、強制モードでメッセージをバウンスする前に問題を発見します。
よくある質問 (FAQ)
MTA-STS (Mail Transfer Agent Strict Transport Security) を使用すると、メールは有効な証明書を使用して TLS 経由で配信される必要があることを送信サーバーに通知できます。 _mta-sts.yourdomain.com の DNS TXT レコードと HTTPS でホストされるポリシー ファイルを組み合わせます。これがないと、SMTP の便宜的な暗号化がネットワーク パス上で攻撃者によって解除され、メールが平文で送信される可能性があります。
_mta-sts.yourdomain.com の TXT レコードには、バージョン (v=STSv1) と ID (ポリシー ファイルを更新するたびに変更する必要がある一意のトークン) という 2 つの情報が保持されます。レコードにはポリシー自体は含まれません。これは単にポリシーが存在することをアドバタイズし、変更された ID を介して、送信者がいつそれを再取得する必要があるかを通知するだけです。
モードは、DNS レコードではなく、HTTPS ポリシー ファイルで設定されます。テスト モードでは、送信者は TLS 障害を (TLS-RPT 経由で) 報告しますが、メールは配信されるため、問題を安全に見つけることができます。強制モードでは、TLS が検証できない場合、送信者は配信を拒否します。ベスト プラクティスは、最初にレポートを有効にしてテストを実行し、すべてが機能することを確認したら強制に切り替えることです。
どちらも受信メールに TLS を必要としますが、信頼の固定方法が異なります。 DANE は DNSSEC および TLSA レコードを使用して証明書を固定するため、展開されている DNSSEC に依存します。 MTA-STS はパブリック Web PKI と HTTPS ホスト型ポリシーを使用するため、DNSSEC がなくても機能します。既存のインフラストラクチャへの展開が簡単であるため、多くのドメインが最初に MTA-STS を採用します。
一般的な理由としては、TXT レコードの欠落または不正な形式、ポリシー変更後に更新されなかった ID、または有効な証明書を含むポリシー ファイルが HTTPS 経由で読み込まれないことが挙げられます。このチェッカーは DNS レコードを検証します。また、/.well-known/mta-sts.txt にあるファイルが到達可能であること、およびその mx エントリが実際の MX レコードと一致していることも確認してください。