推測されたプロバイダー リストではなく、承認された送信者から構築する
アン SPF ビルダーは、どのシステムが特定のSMTP ID を使用できるかについて、組織の明示的な決定を保存する必要があります。人気のあるプロバイダーの便利なリストでは、それらのサービスがドメインに対して承認されていること、推奨されるメカニズムが最新のものであること、または結果のレコードが検索制限に適合していることを確立できません。出力は、ブランド認知から組み立てられた広範な承認ではなく、送信者の所有権に関連付けられた注釈付きの提案である必要があります。
RFC 7208 SPF公開と評価を定義します。この記事では、ビルダーの要件とそのレビュープロセスを提案します。 EmailAuth特定のビルダー機能を提供したり、本番レコードを生成したり、 DNSを変更したりするとは主張しません。サプライヤー アカウント、プライベート資格情報、ユーザー ドメイン レコードは検査されませんでした。元の出力とテストの証拠はオープンなままです。
実際のSMTP ID と所有者のインベントリを作成する
ワークフローごとに、ビジネス目的、承認されたサービス所有者、送信サービス、関連するサービスを記録します。 メール送信元 または HELOアイデンティティ および提案された認可のソース。 SPF 、表示されている From 表示名を直接認証しません。 1 つのチームが使用するプロバイダーをすべてのチームに自動的に追加しないでください。 組織ドメイン。意図された ID とサービス関係には、責任のある所有者からの明示的な確認が必要です。
RFC 9989 を定義します アライメント SPFが貢献するために必要な関係 DMARC。ビルダーは、 SPF認可とDMARCアライメントは関連しているものの、別個の決定であることを説明する必要があります。プロバイダーの追加 SPFレコード プロバイダーが実際のメールでその ID を使用することを保証するものではありません。統合所有者は、ワークフローを検証するときに、現在の構成と承認されたメッセージの証拠を提供する必要があります。
スコープを拡張せずに現在のプロバイダーの指示を使用する
正確なインクルード ターゲットまたはアドレス範囲は、現在の公式ドキュメントまたは実際のサービスの承認された構成から取得する必要があります。他の顧客の記録、古いチュートリアル、または同様の名前の製品から推測しないでください。証拠の日付と、プロバイダーの変更を追跡する責任のある所有者を記録します。特定の送信側構成が構築のために承認されていないため、この原稿ではプロバイダー インクルード値を考案しません。
直接 IP メカニズムと委任された依存関係には、異なる保守義務が伴います。静的アドレスは、DNS クエリを引き起こすメカニズムと同じ検索期間のバジェットを回避できますが、プロバイダーの現在のアドレスを 記録 プロバイダーがインフラストラクチャを変更すると、情報が古くなってしまう可能性があります。ビルダーは、承認されたメンテナンス モデルなしに最適化として依存関係を黙って平坦化すべきではありません。トレードオフと所有者の決定をアノテーションに保存します。
1 つの一貫したSPFポリシーを作成する
RFC 7208では、評価される ID に対して単一のSPFレコードが必要です。複数のSPFレコードを公開することは、複数のサービスを組み合わせる有効な方法ではありません。したがって、提案された変更では、既存の許可された送信者が 1 つの一貫したポリシーでどのように保存されるかを説明する必要があります。単に既存のレコードの横に別のv=spf1レコードを追加するようにオペレーターに指示するべきではありません。無関係 TXTレコード 副作用として削除してはなりません。
RFC 1035 TXTレコード構造を定義します。 1 つのTXTレコード内の複数の文字列は複数のTXTレコードとは異なるため、ビルダーの表示およびテスト フィクスチャはその違いを保持する必要があります。エディターは、long 値をワイヤー表現とは異なる形式でフォーマットする場合があります。承認された正確な差分では、単一フィールドのスクリーンショットに依存するのではなく、目的のレコード セットを指定する必要があります。
メカニズム、修飾子、修飾子の説明
生成された各用語には所有者と根拠が必要です。標準の結果マッピングに従ってデリゲートに評価を含めます。 redirect は異なるセマンティクスを持つ修飾子であり、すべてのメカニズムが存在する場合は無視されます。ビルダーは、両方が別のドメインを参照しているという理由だけで、これらを交換すべきではありません。修飾子は照合メカニズムに関連付けられた結果に影響を与えるため、明示的なポリシー決定を通じて選択する必要があります。
すべてを追加すると、すべての構成が安全になるという意味ではありません。配置と修飾子が重要であり、広すぎる承認は意図した境界を越える可能性があります。逆に、制限的な終了は、インベントリから除外された正当な送信者に影響を与える可能性があります。ビルダーは、ビジネス リスクの姿勢をテンプレートから自動的に選択するのではなく、未解決のワークフローを明らかにし、公開前に承認を求める必要があります。
カウントを混同せずに評価限界を確認する
RFC 7208セクション 4.6.4 では、include、a、mx、ptr、exists、redirect など、評価される DNS クエリの原因となる用語を 10 に制限しています。これは、表示可能なプロバイダー名が 10 個、または raw パケットが 10 個という制限ではありません。ネストされた依存関係と実際の一致するパスが重要です。ビルダーは、浅いカウントから考えられるすべての入力を認証するのではなく、依存関係のレビューを提供し、評価されていないものを特定する必要があります。
この規格では、動作を構成可能な void ルックアップの制限を 2 にすることも推奨しており、特定のメカニズムに対して追加の制限を定義しています。ジェネレーターの静的出力は、すべての受信者が将来のDNS状態ですべてのパスをどのように評価するかを確立するものではありません。パス テストをフォーマット テストとは別にしてください。ビルダーは、構文チェックの成功が普遍的なSPF成功を証明すると主張することなく、可能性の高い依存関係を説明できます。
所有権を保持する出力ワークシート
アイデンティティ ドメイン、ワークフロー、ビジネス所有者、技術所有者、承認された送信者の証拠、提案された用語、根拠、保守責任を記載したワークシートを作成します。既存のレコード参照、正確な意図した差分、未解決の送信者、ルックアップ パスのレビュー、検証計画、ロールバック基準を追加します。出力では、各承認が存在する理由と、その削除または拡張を誰が承認できるかを説明する必要があります。
テスト セットには、肯定的な有効な提案、無効な構文、重複したSPFレコード、およびサポートされていない用語のケースが含まれている必要があります。 RFC 7208では未知のメカニズムと未知の修飾子を別の方法で扱うため、それらを区別してください。カタログの文言では、サポートされていないタグの場合が必要です。 SPFの場合は、汎用のタグ パーサーを発明するのではなく、その要件をプロトコルのメカニズムと修飾子の語彙に明示的にマッピングします。このドラフトではそのようなテストは実行されませんでした。
架空の診断: 古いサプライヤーが引き続き認可されている
架空の組織がビルダーに新しいメール サービスの追加を依頼します。現在のレコードも廃止されたサプライヤーを参照していますが、別のワークフローがその依存関係をまだ使用しているかどうかを文書化した人は誰もいません。単純化されたビルダーは、新しい用語をマージし、他のすべてを説明なしで保持します。提案されている所有権を意識したレビューでは、代わりに古い承認が未解決であるとマークされ、責任のあるビジネスおよび技術所有者にそのステータスを判断するよう求められます。
チームは、カウントを減らすためだけに古い用語を削除したり、無関係なアイデンティティに新しいサプライヤーを追加したりすることはありませんでした。依存関係を解決した後、正確に承認された変更を準備し、代表的な検証を計画します。これは架空のライフサイクル演習であり、観察された記録、サプライヤーの撤退、または完了したDNS変更ではありません。これは、送信者の所有権が、その後の管理事務処理ではなく、記録構築の一部である理由を示しています。
完了を宣言する前に、意図したワークフローを確認してください
公開が承認された後、運用チームは、関連するワークフローごとに正確なDNS観察と代表的な信頼できる受信メッセージの証拠を保持します。これらの観察は、単に生成された文字列がエディターに表示されるだけでなく、実際の同一性と配置を示す必要があります。成功したサンプルの範囲は、送信者、時刻、受信者に限定されます。今後のすべてのメッセージの結果が確立されるわけではありません。
カタログには、注釈付きレコードと、ポジティブ、無効、重複、およびサポートされていないタグのテスト ケースが必要です。これらのオリジナルのアーティファクトはオープンなままです。人間の専門家によるレビュー、ソースの適用性、生産ルート、アクセシビリティ、所有者の公開も未解決のままです。このドラフトは、提案されたワークシートと架空の診断を提供するものであり、生成された運用ポリシー、実行されたテスト スイート、または検証されたEmailAuth機能の主張ではありません。