相互運用性を再現可能な比較にする
受信機がサポートするステートメントが更新されました DMARC 相互運用性の結果ではありません。有益な疑問は、制御された同等の入力を与えられた特定の実装が期待される発見を生み出すかどうかです。 アライメント、ポリシーおよび報告行動。比較では、実験を 2 つのメッセージが受信箱に届いたかどうかに限定するのではなく、これらの段階を維持する必要があります。
バージョン管理されたケース カタログと名前付きのテスト所有者から始めます。受信機のソフトウェアまたはサービス、構成、アクセス可能なバージョン情報、および不明な点を記録します。マネージド サービスは、その実装バージョンを公開しない場合があります。その制限はマトリックスに属します。不足している情報を、製品の発表や最近のレポートのタイムスタンプから得られた採用の主張で置き換えないでください。
結果を変える可能性のある入力を凍結する
それぞれのケースについて、メッセージ バイト、エンベロープおよび接続元の仮定、関連するDNSデータ、観察タイミング、および構成プロファイルを保持します。 2 つのテスト実行間の差異を意図的に視覚的に作成します。 1 つのルートが署名付きメッセージを変更する場合、または別のエンベロープ ドメインを使用する場合、比較はDMARC実装の動作のみに関するものではなくなります。
承認されたドメイン、受信者、および管理された非機密メッセージのみを使用してください。架空の設計ケースは、実行可能なフィクスチャや実際の納品サンプルとは別にしてください。テストを実行する前に、予想される結果とその仕様リファレンスを書きます。そうしないと、驚くべき結果が予想どおり遡及的に説明される可能性があります。未実行のケースは、明示的に実行されないままにしておく必要があり、ドキュメントから推測されるパスを受け取らないようにする必要があります。
送信者の在庫も重要です。ラボの対象範囲が生産変更に関連するかどうかを判断する際には、代表的な正当なルート、特に間接的および定期的なサービスを含めてください。プロトコルのケースは正しくても、実際に影響を受けるビジネス フローを省略することはできます。
処分前に発見と調整を比較する
RFC 9989セクション 4.10 では、 DNSツリーウォークの動作について説明していますが、以前の実装では、サポートされている従来の検出方法を使用できます。ケースでは、明示的な作成者ドメイン ポリシーと制御されたフォールバックの取り決めをカバーする必要があります。明確に指定されたDNS条件がある場合にのみ、適用可能なサブドメインおよび存在しないドメインのポリシー ケースを追加します。期待されるポリシーを定義するにはサブドメインだけでは不十分であるというラベル。
選択されたレコードと、調整に使用される認証された識別子をキャプチャします。次に、選択した p、sp、または np ポリシーとテスト状態を記録します。 RFC 9989セクション 4.4 位置合わせ関係を定義します。通過 SPF または DKIM なぜなら、単に受信者が最終的にメッセージを受け入れたというだけの理由で、無関係なアイデンティティが成功したDMARCとして誤ってラベル付けされることがあってはならないからです。
最後に、ローカル オーバーライドと実際の処理を別の結果として記録します。通常のDMARC計算が一致する場合でも、コンテンツ フィルタリング、ルーティング、およびローカル決定により、異なる配信結果が生じる可能性があります。すべてのメールボックスの違いをポリシー検出によるものとするのではなく、最も初期の異なる段階を診断します。
同等性を仮定せずにテスト移行を含める
識別された実装のプロセスを比較する有用なケース 記録 含む p=reject そしてt=y.下 RFC 9989セクション 4.7、失敗したメッセージのテスト処理は 1 つ下のレベルである隔離です。 t を認識しない従来の実装は、サポートされている異なるロジックに従う可能性があります。これは互換性を測定するために予想される質問であり、その記録をユニバーサル安全スイッチとして展開する理由ではありません。
過去の PCT ケースを t ケースから分離します。更新された受信側が構文エラーなしで古いコントロールを無視するという理由だけで、一度サンプリングを要求したプランは互換性があると宣言されるべきではありません。意図したビジネス効果、指定されたメカニズム、および観察された結果にはすべて、独自のフィールドが必要です。
制御されたテスト範囲内で、不明なタグ、ポリシーの欠落、および不正な入力のケースを保持します。意図的に曖昧なレコードの実験対象として運用ドメインを使用しないでください。テスト設計自体は、運用を実行する前に、関連する承認と回復の要件を特定する必要があります。
別個の機能としてのテストレポート
RFC 9990 オプションの Discovery_method とテスト コンテキストを含む、集計レポートの構造を定義します。これらのフィールドを含むレポートは、そのレポートに関する観察を裏付けることができます。省略されたオプションのフィールドは、従来の動作を証明するものではありません。受信者が情報を正しく生成した場合でも、コンシューマーは情報を失う可能性があるため、生のレポートとパーサー プロファイルを保存してください。
レポート期間にはポリシーの移行が含まれる場合があるため、1 つの集計が常に 1 つの凍結されたポリシーの記録であるとは限りません。カウントを使用して特定のメッセージを説明する前に、比較の時間枠とソース証拠を調整します。重複排除とスキーマの互換性は、ダッシュボードに隠されているのではなく、レポート テスト計画に属しています。
障害レポートは、別の独立した次元です。 RFC 9991 世代は受信者の意欲とプライバシーの制約を受けることになります。いいえ 失敗レポート 相互運用性テストが失敗したことを示す十分な証拠ではありません。不要なメッセージ内容を収集することなく、レポートが要求、サポート、承認、受信、解釈可能かどうかを記録します。
結果セルが観察されない架空の行列
架空のワークシートでは、現在のセマンティクス参照として受信者 A を指定し、レガシー プロファイルとして受信者 B を指定します。どちらにもp=reject;の同じ作成されたメッセージとDNSスナップショットが割り当てられます。 t=y場合。 A の Expected-policy 列は仕様から派生します。 B の実装とすべての実際の結果には依然として証拠が必要です。どの製品もラベルのように動作するとは考えられません。
計画されたマトリックスには、直接調整されたコントロール、無関係な認証済みドメインのケース、フォールバック検出のケース、および集約フォーマットのケースも含まれています。すべての実行セルは実行されないままになります。これにより、適合性の製造証明や受信機の採用を必要とせずに、ワークシートを準備するのに役立ちます。
正確なリリース要件を維持する
元の証拠ゲートは次のとおりです。同一の入力ケースと完全に観察された結果を含む、バージョン管理された相互運用性マトリックスを保持します。コミッショニング要件は次のとおりです。 現在の主な仕様を検証し、製図前に実際に動作した例を保存します。保持された架空のマトリックスは、ライブ観察も生産準備も満たしていません。指定された実装の証拠、管理された結果、人間による SME レビュー、事業展開の承認、および出版の承認は未解決のままです。この原稿では、受信機テスト、 DNS変更、メッセージ送信は行っていません。