[ 報告と調査 ]

代表的な障害とエッジケースを使用してDMARCパーサーを検証する

レポート由来のメトリクスを信頼する前に、バージョン管理されたフィクスチャ マトリックスを使用して、セマンティックの正確さ、リソースの制限、重複の処理、安全なリカバリを検証します。

EmailAuth研究チームによる

【ポイント】

  • 生の認証結果を DMARC に準拠した結果から分離します。
  • サポートされるスキーマ、拡張機能、および競合動作を明示的に定義します。
  • 事前に設定された期待値を比較し、安全性と測定されたリソースの結果を再生します。
このページでは

1 つの適切な XML レポートを受け入れるパーサーは、狭いテストにのみ合格します。便利な検証スイートは、何を抽出するか、何を拒否するか、サポートされているバリエーションをどのように処理するか、再試行によって合計が変化するかどうかをチェックします。期待される正規化値は、テストで作成できる出力としてではなく、フィクスチャの一部として扱います。

サポートされているコントラクトを宣言する

参考文献: RFC 9990 §3.1.1, RFC 9990 §3.2.

パーサー、ランタイム、デコンプレッサー、およびスキーマのバージョンを記録します。どのレポート形式と拡張子がサポートされているか、またレガシー入力がどのように処理されるかを説明します。 RFC 9990 現在の集約フォーマットと拡張モデルを定義します。古い形式のサポートは、互換性を個別に決定する必要があります。

最初に最小限の有効なフィクスチャを構築します。バイト、ハッシュ、予期されるメタデータ、間隔、ソース IP、カウント、ID、およびアライメントされた結果を保存します。 XML 解析が成功しただけでは十分ではありません。フィールドのタイプと意味を確認してください。無効な必須データとは別に、欠落しているオプション値を保持します。

よくある意味上の間違いをテストする

参考文献: RFC 9990 §3.1.1.9, RFC 9990 §3.1.1.11, RFC 9989 §5.3.5.

生を含む DKIM 整合性のとれたDKIM障害を伴う無関係なドメインを通過し、生の SPF なしで通過する アライメント。調整されたメカニズムの 1 つは成功したが、もう 1 つは失敗した場合を含めます。正規化された結果が、両方のメカニズムに、生の成功をアライメントに合格させるか、アライメントと同等に評価することを要求していないことを確認してください。

公表されたポリシーからの単純な推論とは異なる、報告された性質を追加します。利用可能なオーバーライド理由を保持します。現在のスキーマの場合、不明なレガシー値として拒否するのではなく、ActionDispositionType 値パスを含めます。 RFC 9990付録 A 渡すために定義します DMARC 強制的なポリシーを使用します。レガシー形式の期待を明示的に分離してください。最初の署名を除くすべての署名を削除せずに、複数のDKIM結果をテストします。目的は、レポートの内容を保存することであり、不完全なデータから新しい受信機の評価をでっち上げることではありません。

構造的およびセキュリティのケースを演習する

参考文献: RFC 9990 §3.2, RFC 9990 §8.1.

参照: OWASP XML 外部エンティティの防止、一般的なガイダンス.

無効な必須値、不正な形式の XML、サポートされている名前空間拡張子、サポートされていないバージョン、欠落しているオプション要素、過度の境界付きネストを使用します。圧縮および拡張されたサイズ制限、中断された入力、無害な外部参照センチネルを個別にテストします。各入力が受け入れられるか、隔離されるか、拒否されるか、およびその理由を定義します。

サポートされている拡張機能は、ダウンストリーム分析で保存されていると主張される場合でも、サイレントに消えてはいけません。サポートされていない構造は、失敗した認証として再分類されるのではなく、明示的な互換性の結果を生成する必要があります。セキュリティ テストは規模を小さくし、リソースを制限してください。単に限界を示すために、破壊的なワークロードを生成しないでください。

重複とトランザクションの動作を確認する

参考文献: RFC 9990 §3.5.4.

フィクスチャをインポートして再生し、再度再生する前にワーカーを再起動します。カウントされたレポートは、文書化された重複ルールに従って単一のままである必要があります。同じレポート ID を主張する別の添付ファイルを追加し、明示的な競合の決定を必要とします。同一の ID だけでは、異なる証拠を審査せずに破棄することは許可されません。

コミット前に制御された割り込みを挿入します。部分的なレコードが運用メトリクスに影響を与えていないこと、および許可された再試行で期待どおりの結果が 1 回得られることを確認します。ゼロで割ったり、完璧な合格率を作り出すのではなく、ゼロ観測出力を使用できないものとしてテストします。

受付列を通過する

合成フィクスチャ F1 には、位置合わせされたDKIMパスを含む 90 個の観測値と、位置合わせされた通過メカニズムを含まない 10 個の観測値が含まれています。予想されるインクルード数は 100 で、予想される観察パス数は 90 です。F1 を再生する場合は、両方の値を変更しないでください。意図的に切り詰められたコピーは、どちらの合計も増加させずに拒否する必要があります。

実行前に期待値を保存します。実際の出力、リソースの測定値、診断をそのベースラインと比較します。これはパーサーの受け入れ仕様であり、商用またはテナントのパーサーがこの仕様に合格したという主張ではありません。別の新しいオフライン算術/再生モデルは、繰り返される同一性の 100/90 値と変更されていないカウントをチェックします。 RFC 9990 XML レポートの解析や検証は行いません。ケースが失敗した場合は、後のリビジョンで再現できるように、欠陥と正確な治具を保存してください。

記録結果のゲート変更

フィクスチャ ID、ハッシュ、目的、期待される結果、実際の結果、パーサー構成、およびレビューの決定を含むマトリックスを保持します。サポートされていない機能については文書化された例外を除き、すべての必須ケースがデプロイされたリビジョンで合格することを要求します。依存関係または正規化の変更後に再実行し、保存されたレポートを再処理する前に履歴メトリックの影響を比較します。パーサーの検証は、システムの可用性と、人々がポリシー決定に使用する数値の意味の両方を保護する必要があります。

[ 取り除く ]

事前に設定された期待値を比較し、安全性と測定されたリソースの結果を再生します。

【役割別】

これがあなたにとって何を意味するか

実際の次のステップに向けて、自分の役割を選択してください。

IT / メール管理者

バージョンフィクスチャと期待される正規化された値。

アライメントセマンティクスをテストし、再生します。トランザクションの回復とリソースの制限を確認します。

次のステップ

  1. バージョンフィクスチャと期待される正規化された値。
  2. アライメントセマンティクスをテストし、再生します。
  3. トランザクションの回復とリソースの制限を確認します。

CISO / SecOps

セキュリティと整合性のケースを一緒にレビューします。

正確なバージョンの受け入れ証拠が必要です。履歴を再処理する前にメトリックへの影響を評価します。

次のステップ

  1. セキュリティと整合性のケースを一緒にレビューします。
  2. 正確なバージョンの受け入れ証拠が必要です。
  3. 履歴を再処理する前にメトリックへの影響を評価します。

創業者 / 非技術系

ダッシュボードの変更を信頼する前に証拠が必要です。

失敗した受け入れケースに所有者を割り当てます。サポートされていない形式のギャップを表示したままにします。

次のステップ

  1. ダッシュボードの変更を信頼する前に証拠が必要です。
  2. 失敗した受け入れケースに所有者を割り当てます。
  3. サポートされていない形式のギャップを表示したままにします。

[ よくある質問 ]

よくある質問

有効な XML はレポートを受け入れるのに十分ですか?

いいえ。サポートされているレポート構造とフィールドのセマンティクスも検証します。

RFC 9990 §3.1.1

生のDKIMパスは、調整されたDKIMパスを意味する必要がありますか?

いいえ。署名ドメインは作成者のドメインと一致しない可能性があります。

RFC 9990 §3.1.1.11 RFC 9989 §4.4

調整されたSPFとDKIM両方に合格する必要がありますか?

いいえ。どちらのメカニズムを介して調整されたパスを通過してもDMARC満たすことができます。

RFC 9989 §5.3.5

リプレイテストで何を証明すべきでしょうか?

再試行と再起動では、含まれている同じ観測値が再度追加されることはありません。

同じ要求されたレポート ID を持つ異なるファイルはどのように処理されるべきですか?

対立を維持し、明確な証拠に基づいた決定を適用します。

RFC 9990 §3.5.4

サポートされていない形式は認証に失敗しますか?

いいえ。それらは互換性または取り込みの結果です。

不正な形式のフィクスチャにより、本番環境のメトリクスはどう変化するでしょうか?

アトミックコミットの前に検証が失敗した場合は何もありません。

検証レコードには何が含まれますか?

フィクスチャのハッシュ、予想される結果と実際の結果、構成、測定された制限、およびレビューの決定。

[ 情報源 ]

情報源

  1. RFC 9989

    セクション §4.4 · §5.3.5

  2. RFC 9990

    セクション §3.1.1 · § 3.1.1.11 · § 3.1.1.9 · §3.2 · §3.5.4 · §8.1 · 付録 A

  3. OWASP XML 外部エンティティの防止

    セクション 一般的なガイダンス

[ 用語集 ]

用語集

生の認証結果
SPFおよびDKIM結果は、 DMARCアライメントとの関係を解釈せずに報告されました。

RFC 9990 §3.1.1.11

整列された結果
DMARCに関連する、policy_evaluated SPF / DKIM結果。

RFC 9990 §3.1.1.9

リプレイ
意図しない余分なメトリックカウントを発生させずに、文書化された重複ルールに基づいて入力を再処理します。

企業の来歴

一流の金融機関と政府が選ばれる理由 電子メール セキュリティ ダッシュボードを廃止しました。

従来の電子メール認証プラットフォームはダッシュボードを販売し、エンジニアに作業を依頼します。一か八かの環境では、手動による監視は適用の遅れ、構成のドリフト、および監視されていないシャドウ ドメインを意味します。

EmailAuthは、エージェントの電子メール来歴プラットフォームです。 当社のエージェントが執行します p=reject、サードパーティの送信者を調整し、ドメインを完全に移動します。 RFC 9989 新しいDMARC標準に準拠し、人間による監査機能を備えています。

政府 大企業 ティア1金融機関

SaaS · 専用テナント · エアギャップオンプレミス · BYOK 暗号化

ナレッジベース