要約

  • RFC 9990 の集約レポートは、受信システムが一定の報告期間に観測したポリシー、送信元 IP の行、件数、認証結果を XML で渡す仕組みである。
  • 外部 rua 宛先の DNS 確認は、Report Consumer がそのレポート関係の受信を認めたことを示すだけで、内容の真実性、保存方法、制裁権限を与えるものではない。

メール運用の画面では、レポートが裁定のように見えることがある。ある IP、非常に大きい件数、reject、そしてポリシーの上書き理由が同じ行に並ぶ。だが RFC 9990 の記述はもっと狭い。policy_published は受信システムが観測した構成であり、record は Author Domain のためのメッセージをその受信システムへ配信した IP を見たというデータである。レポートは、受信者の視点を移送する。

その視点は実務上きわめて有用だ。忘れられた一斉配信事業者、切れた DKIM 鍵、移行後に残った送信経路、あるいは詳しく調べるべき量的変化を発見できる。しかし、他のすべての受信者が同じものを見たとは言わない。人間の送信者を特定せず、意図を立証せず、別の受信者も同じ配送判断をすべきだとも言わない。

危険なのは、ダッシュボードがこの観測を一つの「確定リスク」に縮め、仕入先停止、アカウント制限、メール方針変更へ直結させる時だ。追加の証拠があればそうした判断が正当になることはある。だが、その判断は XML の中にはない。受信側の記録と、組織が後から加えた決定は別に記録されなければならない。

報告期間は全履歴ではない

RFC 9990 は report_metadata、policy_published、少なくとも一つの record を要求する。メタデータには生成組織、連絡先、報告 ID、UTC の日付範囲がある。ここで重要なのは、開始と終了が「最初と最後に観測したメール」ではなく報告期間を表すことである。期間は通常 UTC 一日で、重複させないことが求められる。

ゆえに、ある期間に行がないことは、送信が存在しなかったという証明ではない。行があることは、全 Internet の量や到達状況の証明でもない。DKIM と SPF の結果は auth_results に含まれるが、RFC はこれを DMARC について未解釈として扱う。ポリシー上書きの理由も、受信側がその場で行った扱いの説明であり、送信者の本人性や悪意の判決ではない。

高い影響を持つ決定の前には、レポートを自組織の送信元台帳、DNS と鍵の履歴、送信ログ、フォワーダー、事業者変更、複数の独立した受信者の反復観測と照合するべきである。生の添付、ハッシュ、抽出済みの値、表示用に計算したスコアを混ぜない。「危険」という表示は RFC のフィールドではなく、作成者が責任を持つ推論である。

受信の同意と利用の決定は別である

rua は Domain Owner が集約レポートを望む宛先を示す。宛先が組織ドメインの外にある場合、Mail Receiver は RFC 9990 の外部宛先検証を実行する。規定された DNS 名で確認レコードが見つからなければ URI を無視しなければならない。この仕組みは、攻撃者が被害者のアドレスを指定し、多数の受信者に不要なレポートを送らせる反射を防ぐ。

肯定の結果が意味するのは、「この Report Consumer はこの関係のレポートを受ける意思がある」という一点だけである。誰が内容を見るか、保存期間、下請け先、他データとの相関、送信元への処置は決めない。RFC 9990 も、第三者への送信は Mail Receiver のプライバシー方針や利用条件に制約され得るとする。個人のメールアドレス、個人の IP、本文は含まれないが、集約データがドメイン単位のトラフィック分析を可能にし得ることも明記する。

DNS 確認の外側に、受信目的、対象ドメイン、責任者、アクセス権、許される変換、保持・削除、再提供、インシデント対応を含む台帳が必要になる。DNS はその台帳と照合すべき技術的な関係であり、台帳そのものではない。

構文の成功は信頼の成功ではない

レポートはメールの XML 添付として、通常は GZIP 圧縮で送られる。フィードバックを運ぶメールストリーム自身が DMARC に適合し、整合した pass となることを RFC 9990 は求める。これは不正なレポートを処理する危険を小さくするためであり、Report-ID やファイル名は重複を扱いやすくする。

それでも内容は偽造できる。RFC は、攻撃者がポリシーやプラットフォーム設計の判断に影響するために偽の集約データを大量送信する可能性を挙げる。また、壊れたレポートが zip bomb や XML bomb により解凍器・解析器の資源を消費させる危険も指摘する。正しい宛先に届き、見慣れたファイル名を持つことと、内容が真実で安全であることは異なるテストである。

そのため、入力段階に上限を置く。圧縮前後のサイズ、XML の深さ・複雑度、解析時間、スキーマを検証し、生ファイルを限定保管する。形式が疑わしければ、RFC が許すとおり破棄または隔離し、生成側と照合する。パースできたという事実は、証拠として採用できるという事実ではない。

RFC 9989 は、Domain Owner が自分のメールすべてを正しく認証できていると確信するまで、送信頻度によっては数か月の集約レポート消費が必要になるとする。p の選択はその所有者の必要に依存する。これは集約値が、局所的な方針判断を支える材料であって判断そのものではないことを示している。

編集上の解釈：共通層を限定する

これは編集上の解釈であり、IETF の要件ではない。共通の形式、配送の期待、反射防止は相互運用に必要だが、それだけで他者のメール方針を支配する権限は生まれない。どの受信者が観測し、どの検証器が受理し、誰が方針を変え、何が実際に起きたかを分けて追えることが必要である。