MTA-STS 受信ドメインが認証されたTLS配信に対する期待を公開できるようにします。これは、受信サービスへのSMTP接続をアドレス指定します。メッセージ作成者の From アドレスを認証したり、ある人のデバイスから別のデバイスに至るまでメッセージを暗号化したりすることはありません。
動作する展開では、ドメインの実際の受信MXルート、HTTPS ポリシー、およびそのポリシーを通知するDNSレコードの 3 つが接続されます。 TLSレポートは、別のフィードバック パスを提供します。
実際の受信境界を確立する
参考文献: RFC 8461 §3.4, RFC 8461 §4.
バックアップ サービスやアップストリーム セキュリティ ゲートウェイなど、ドメインのメールを受け入れるMXホストを一覧表示します。内部メールボックス サーバーだけでなく、実際のパブリック受信境界でもTLSと証明書の動作を確認します。
MXルート、ポリシー ホスティング、証明書の更新、レポートの宛先の所有者を記録します。ホスト型メールボックス サービスは、必ずしも顧客のMTA-STSポリシーをホストしたり、その前にあるすべてのゲートウェイを操作したりする必要はありません。
サブドメインを個別に評価します。 MTA-STS 、DMARC スタイルの親ポリシーの継承を使用しません。受信サブドメインには、そのドメインに適用できる構成が必要です。
実際のホストのポリシーを構築する
参考文献: RFC 8461 §3.2, RFC 8461 §3.3.
受信ドメインに必要な HTTPS の場所からポリシーを提供します。 example.comの場合、場所はhttps://mta-sts.example.com/.well-known/mta-sts.txt. HTTPS サービスには、ポリシーのホスト名に対する有効な証明書が必要です。
ポリシーは、そのバージョン、モード、許可されるMXパターン、およびキャッシュの最大有効期間を特定します。スコープに適したテスト展開から開始し、適用前に結果を検査します。サンプル期間を普遍的な証拠として扱うのではなく、実際のトラフィックと依存関係から観察期間を選択します。
架空の単一 MX ドメインのポリシーの例は次のとおりです。
バージョン: STSv1 モード: テスト mx: mx1.example.net max_age: 86400この例では、 mx1.example.netがドメインの実際の受信ホストであり、適切なSMTP TLSサポートがあることを前提としています。これは、別のプロバイダー向けの既製のポリシーではありません。許可されたホストを正確に照合し、すべての正当な受信ルートを含めます。
発見とレポートを別々に公開する
参考文献: RFC 8461 §3.1, RFC 8461 §8.1, RFC 8460 §3.
_mta-sts.example.comでは、 TXT値の例はv=STSv1; id=2026110701.識別子はポリシーの改訂を通知します。新しいリビジョンをDNSに公開する前に、ポリシーを公開して検証します。
TLS-RPT _smtp._tls.example.comで独自のレコードを使用します。リクエストの例はv=TLSRPTv1; rua=mailto:tls-reports@example.com,アドレスが存在し、そのコレクション パスが機能していると仮定します。
仮定しないでください DMARC rua 宛先はTLSレポートを自動的に受信するか、 MTA-STSテストだけで機能するレポート要求を作成します。独自の収集プロセスを通じて、正しい名前と各宛先の各レコードを検証します。
デプロイされたチェーンをテストする
参考文献: RFC 8461 §4, RFC 8461 §6.
ポリシーを外部で取得し、必要な HTTPS エンドポイントが意図したプレーンテキスト本文を HTTP 200 で提供していることを確認します。HTTP リダイレクトには従わないでください。リダイレクトは、 RFC 8461 §3.3 に基づく有効なポリシー取得ではありません。検出DNSを確認し、アドバタイズされたすべてのMXルートを許可されたパターンと比較します。
各受信ルートでSMTP TLSと証明書の検証をテストします。 mta-sts.example.comで機能する Web 証明書は、 MXサーバーが有効なSMTP証明書を提示していることを証明しません。
利用可能なTLSレポートと制御された配信の証拠を確認します。送信サービスは参加の仕方が異なるため、沈黙が普遍的な成功を確立するわけではありません。観測ごとにレポーター、間隔、影響を受けるMX維持します。
合成の場合、ポリシーはメイン ゲートウェイのみを許可し、 DNSバックアップMXもアドバタイズします。バックアップは通常のテストではメールを受け入れますが、ポリシーの一致に失敗します。適用前にポリシーまたはルーティング設計を修復します。 1 日あたりのボリュームが小さいため、バックアップを無視しないでください。
キャッシュに関する適用とリカバリを計画する
参考文献: RFC 8461 §5, RFC 8461 §8.3.
強制モードでは、サポートしている送信者が非準拠の接続を介して配信するのを防ぐことができます。サポートしていない送信者はその保証の対象外です。モードを変更する前に、依存関係と許容可能な操作応答を記録します。
送信者キャッシュは、max_age の間、有効な以前のポリシーを保持できます。検出DNSの削除または HTTPS エンドポイントの停止は、即時のグローバル ロールバックではありません。取り消しの場合は、有効期間が短い有効なモード: none ポリシーを公開し、検出 ID を更新します。有効期間が長い古いリビジョンを含め、以前のポリシーがすべて期限切れになるまで、両方のエンドポイントを利用可能な状態に保ちます。次の編集からだけでなく、そのリビジョンが最後に提供されたときから各存続期間をカウントします。
ゲートウェイの移行の場合は、ポリシーを計画された移行と互換性のあるものにし、新しいルートを検証し、キャッシュされたバージョンを許可します。関連する送信者が依然としてポリシー エンドポイントに依存している間は、ポリシー エンドポイントを利用可能な状態に保ちます。
ハンドオーバーでは、 MX構成、ポリシー履歴、証明書の所有権、およびレポート処理を結合する必要があります。 MTA-STSこれらの可動部分が一緒に維持される場合に引き続き役立ちます。