置き換える記録ではなく、行動から始める
各実装決定に指定された仕様と責任ある所有者があれば、標準の移行は管理可能になります。 DNSエディター、 アライメント エンジンと集計レポート パーサーは同じジョブを実行しません。 3人全員に電話をかけます。DMARC 「サポート」は、1 つのコンポーネントが変更され、別のコンポーネントが古い実装のままである場合に問題となる依存関係を隠します。実際の成果物は、資産全体がアップグレードされたという宣言ではなく、バージョン、インターフェイス、および保持された受け入れ証拠を含むコンポーネントから要件へのマップです。
現在の文書セットは 2026 年 5 月に発行されました。 RFC 9989 コアメカニズムを定義し、廃止する RFC 7489 およびRFC 9091 。 RFC 9990 集計レポートをカバーします。 RFC 9991 障害レポートについて説明し、 RFC 6591も更新します。 RFC エディターの最新の記録が特定する RFC 9989 そして RFC 9990 提案された標準として。公開されたRFC 9991テキストでは、その Standards Track カテゴリが特定されています。これらは公開された仕様であり、未完成の草案ではありませんが、公開によって特定の受信者の実装が確立されるわけではありません。
コアエンジンに正確なコントラクトを与える
レコード解析、ポリシー検出、組織ドメイン検出、および識別子の調整を割り当てる RFC 9989セクション 4.7 ～ 4.10。作成者のドメインはメッセージのドメインから取得されます。 RFC5322より 分野。検出されたポリシー ドメインはその作成者ドメインとは異なる場合があります。 組織ドメイン リラックスした位置合わせに使用されるもう 1 つの明示的な出力です。インターフェースでこれらの区別が失われると、正しいパーサーが間違った意思決定エンジンにフィードを与える可能性があります。
DNSレコードは依然としてv=DMARC1. 「DMARCbis「」は標準作業の名前であり、DMARC2 を発明する許可ではありません。現在の検出では、過去のパブリック サフィックス リスト チェックリストをアルゴリズム全体として扱うのではなく、有界DNSツリー ウォーキングを使用します。psd、np、および t タグには個別の決定カバレッジが必要です。 IANAレジストリ pct、rf、ri は歴史的なものです。デプロイされた製品がそれらを無視、解釈、または公開するかどうかを保証するものではありません。
通常のDMARC障害、利用できないDNS情報、無効なポリシー、受信者の最終的なメッセージの性質の区別を維持します。 RFC 9989セクション 4.10.1 には、構文的に有効な集約レポート URI が残っている場合の無効なポリシー タグに対する特別な処理が含まれています。 「あらゆる不正なポリシーは無効になる」という単純なルールでは、その条件が消去されてしまいます。それを実行するパーサー ケースの横に正確なセクションを記録します。
集約されたフィードバックを独自の実装として扱う
集約プロデューサー、XML バリデーター、レポート コンシューマー、重複処理、配信統合をマップします。 RFC 9990セクション 3 ～ 4 および付録 A。レポート インターフェイスには、実際に評価されたポリシー、認証結果、メッセージ数、レポート期間のコンテキストが必要です。 XML を表示するダッシュボードは、上流の受信者が正しいポリシーを選択したこと、または関連するすべての送信者がデータに現れたことを示すものではありません。
外部レポートの宛先には、独自のコンポーネント行が必要です。宛先の承認は技術的な不正行為防止チェックであり、任意の組織データの送信に同意するものではありません。レポートの生成、宛先の検証、およびアクセス/保持の決定を明確な受け入れ基準に基づいて行います。 RFC 9990セクション 7 ではプライバシーについて言及し、セクション 8 では悪意のあるレポート内容または虚偽のレポート内容について警告しています。したがって、パーサーの強化とソースの信頼性は、スキーマの有効性とともにマップに含まれます。
失敗レポートに集約パーサーを再利用しないでください。
失敗のフィードバックは、開示リスクが異なる別のチャネルです。 RFC 9991 参照された認証失敗レポート仕様と連携して、その生成と形式を管理します。 ruf リクエストおよび fo 条件は、rua 集約と同等ではありません。受信者は障害報告を拒否したり、受信者の不在を拒否したりできます。 失敗レポート すべてのメッセージが通過したという証拠ではありません。
障害レポートの統合で発生する可能性があるのは、 メッセージヘッダー または、集約パイプラインが伝送しないように設計されているコンテンツ。誰がリクエストするのか、どこに送信できるのか、受信した素材がどのように含まれるのか、どのプライバシー レビューが適用されるのかを特定します。機能マトリックスを完全に見せるためだけに有効にしないでください。中核的な参加要件、オプションの障害レポート、および宣伝されている商用製品の機能は、異なる証拠を必要とする異なる主張です。
架空のコンポーネントの一覧表を調べてみる
6 つのモジュール (ポリシー デコーダー、ディスカバリ リゾルバー、アラインメント エバリュエーター、集約ビルダー、XML コンシューマー、および障害コレクター) を備えた架空のサービスについて考えてみましょう。最初の 3 つはRFC 9989にマップされます。次の 2 つは主にRFC 9990にマップされます。コレクターは主にRFC 9991にマップされます。共有ストレージとセキュリティ制御は、処理するすべてのレポート パスから要件を継承します。このインベントリはオリジナルのドキュメント例であり、 EmailAuthのアーキテクチャに関する主張ではありません。
各モジュールについて、実際のビルド識別子、関連セクション、入出力コントラクト、所有者、および受け入れフィクスチャを保持します。架空のディスカバリー フィクスチャは、選択されたポリシーとそのソース ドメインを架空の集約フィクスチャに渡すことができます。レポート行では、表示されている From ドメインを黙って置き換えるのではなく、その区別を保持する必要があります。次に、障害レポート要求を導入し、設計がそれを個別に承認された処理パスにルーティングしていることを確認します。これらは提案されたチェックであり、完了した実行ではありません。
ステータス、エラッタ、デプロイメントを別々に保つ
正確な手数料は次のとおりです。すべての実装コンポーネントをRFC 9989 、または 9991 にマッピングし、正誤表を確認します。実際の実装範囲は提供されていません。現在の正誤表の取得は失敗して停止されたため、この草案では文書に正誤表がないとは断言できません。解決されたRFC 7489正誤表に関するRFC 9989の議論は歴史的背景であり、3 つの新しい文書に対する新たな正誤表のチェックではありません。
リリース前に、実装所有者は実際のインベントリを調整する必要があり、標準所有者は現在のエラッタを解決する必要があり、受信機テスト所有者はバージョンを対象とした相互運用性の証拠を保存する必要があります。専門家のレビュー、生産ルートのチェック、視覚的な受け入れ、出版の承認も引き続き行われます。今日の有用な成果は、更新された標準を普遍的展開という支持されていない主張に変えることなく、欠けている証拠を明らかにするレビュー可能なマップです。