要点

  • RFC 9991は、一通の失敗メールまたは同じような理由で失敗した一群を対象とするDMARC失敗報告を定義する。集計報告より早く、はるかに細かな原資料を含み得る。
  • ドメイン所有者のrufとfoは詳細を求める意思表示であって、引き渡し命令ではない。メール受信者は、自らの方針、失敗条件、プライバシー、安全能力に基づき、何を送るか、そもそも送るかを決める。
  • Daniel Kadeは、本文やアドレス、認証情報、攻撃用ペイロードを保存せず、目的、選択したデータ区分、編集、集約、流量制限、輸送、アクセス、削除を記録する失敗開示レシートを提案する。

一枚の証拠が新しい事故を作るとき

署名障害を調べている担当者が、変換前後のヘッダーを一つ見れば原因を特定できる場面は珍しくない。集計表に現れるのは、送信元と認証結果と件数である。壊れたDKIMセレクターなのか、中継で本文が変わったのか、なりすましなのかは、その表だけでは分からない。

しかし、原因を示す同じヘッダーが、個人の受信先、内部ホスト、転送経路、メーリングリストへの所属を示すこともある。本文まで加われば、人事、契約、予定、製品情報、資格情報、追跡URL、悪性添付物が同時に移動する。診断価値と開示損害は別の包みに入っていない。

ここで「要求されたのだから送る」という自動化を採用すれば、最初の認証失敗を二度目の情報事故に変えかねない。RFC 9991の統治上の価値は、共通形式を定めながら、この判断を受信側から奪わなかった点にある。

DNSに書かれた希望は取得権ではない

RFC 9991は2026年5月の標準化過程文書であり、新しいDMARC本体と集計報告の仕様とともにRFC 7489の関連部分を置き換え、従来の認証失敗報告規則も更新する。

ドメイン所有者はDMARC方針レコードでruf宛先を示し、foで関心のある失敗条件を指定する。この記述は報告を要求する。だが、メール受信組織は、実際の失敗、要求された条件、自らの方針に従い、どの種類の報告を送るか、または一切送らないかを決定する。

したがって、一つの自動処理に見える流れには少なくとも三つの決定がある。所有者は要求と宛先を決める。受信者は開示の有無と範囲を決める。消費者は閲覧者、分析方法、保存期間、再移転を決める。ある段階の正常終了は、次の段階に代わって正当性を証明しない。

失敗報告は一通を扱うことも、似た理由の複数通をまとめることもでき、集計報告より早く届き得る。即時性は修復を速める一方、プライバシー審査、宛先確認、危険物隔離の時間を短くする。自動化の役割は境界を消すことではなく、各決定をその境界に結び付けることである。

詳細化は証拠の性質を変える

Abuse Reporting Formatは、人が読む説明、機械可読のフィードバック項目、元メッセージの素材を異なるMIME部分に分ける。RFC 9991はそこにDMARC固有の意味を加え、Identity-Alignment、関連するDKIM情報、SPFのDNS情報、認証失敗種別などを扱う。

Identity-Alignmentが述べる範囲は狭い。整合した識別子を認証できなかった仕組みを列挙し、試行した仕組みが成功していればnoneを示せる。署名が壊れた原因、見かけ上の著者が実際に送ったか、内容が悪性か、後の処分が正しいか、開示が許されるかまでは証明しない。

派生項目にない答えを元ヘッダーや本文が持つことはある。その代わり、それらを報告にコピーした時点で、新たな管理者、アクセス権、保存期限、派生物が生まれる。「フォレンジック」という目的名は、その会計を免除する万能のデータ区分ではない。

外部宛先の承諾は個別開示の正当化ではない

方針レコードは組織ドメイン外へ報告を向けられる。RFC 9991は集計報告で使う外部宛先承認の手続きを再利用し、宛先側がDNSで当該ドメイン向け報告を受け取る意思を示すよう求める。これにより、所有者が無関係な第三者へ一方的に大量の報告を向ける行為を抑える。

ただし、その確認が示すのは受領意思である。各報告の正確性、各項目の必要性、消費者の法的・契約上の根拠、転送先の統制までは証明しない。内部に見える宛先がさらに外へ転送する可能性もあり、公表アドレスだけで最終保管場所を確定できない。

統治記録では、宛先として適格かという判断と、今回のデータ量が目的に比例するかという判断を分ける必要がある。前者を後者の代わりにすると、「ある報告を受ける用意」が「生成者の持つ全内容を受ける権限」へ膨らんでしまう。

役に立つ最小化には有効期限がある

RFC 9991は、要求する目的と期間を絞り、報告URIを慎重に管理し、本文やヘッダーを編集し、安全な輸送を用いることを勧める。多くの大規模事業者がプライバシー上の費用を理由に失敗報告を制限または停止している現実も指摘する。

編集は単なる消去ではない。RFC 6590の安定した耐衝突変換を使えば、元の文字列を見せずに、二つの伏せ字が同じ値に由来するかを判定できる。調査上の相関が残る一方、長期間または複数目的で同じ方式と秘密を使えば、仮名値は永続的な関係識別子になる。

実装では、編集方式の版と適用範囲を記録し、目的ごとに鍵を分離または更新し、元値と変換値が同じ広いログ基盤へ流れないようにする。相関が不要なら、安定したトークンを生成する理由もない。失敗区分、一回限りの案件番号、あるいは非報告の方が適切なこともある。

最小化は、解くべき診断問題に照らして試験すべきである。残し過ぎれば私信が不要に越境し、削り過ぎれば役に立たない報告のために受領と保管の危険だけを負う。正解は固定項目表ではなく、理由と期限を伴う選択である。

流量制限が沈黙の意味を一つでなくする

失敗報告はDoSの経路にもなり得る。攻撃者が被害ドメインを装うメールを大量に送り、参加する受信者から被害者または委託先へ報告を集中させることができるからだ。RFC 9991は生成側に流量制限を求め、似た事例のまとめや超過分の破棄を認める。目的は異なる失敗条件を見せることであり、失敗メールを一通ずつ数えることではない。

そのため、消費者は報告の列を完全なイベント台帳と見なせない。ゼロ件は失敗なしのほか、不参加、ローカルなプライバシー方針、集約、上限到達、輸送障害、診断期間終了を意味し得る。急増も、新しい障害だけでなく方針変更や意図的な洪水かもしれない。

量から結論を出す前に、生成者の集約規則と流量制限の文脈が要る。生成者側も、抑制理由を説明するために機微な一通単位の別台帳を作る必要はない。限られた時間帯ごとの理由別件数で、統治上の説明は十分できる。

報告を普通のメールとして開いてはならない

失敗報告は、元の失敗メッセージからスパム、フィッシング、マルウェア、欺瞞的リンク、添付物を再現し得る。仕様は隔離、サンドボックス、ネットワーク分離、訓練された権限者だけのアクセスを勧める。一般メールボックス、チケットの自動プレビュー、全社検索へ直接入れれば、調査対象だった攻撃を社内へ広げる。

報告ストリーム自体をDMARC整合させることは、期待する送信ドメインと輸送上の識別を結び付けるのに役立つ。それでも内部の内容を安全にはせず、機械可読部分の主張をすべて真にせず、原文を見る権限を全分析者に与えない。認証、内容安全、データ取得資格、操作権限は独立した制御である。

有用な自動化には拒否動作も含まれる。活動性コンテンツの除去、未対応MIME構造の拒否、添付物の検疫、展開・解析資源の上限、一般検索からの除外である。パーサーが成功した瞬間は処理の完了ではなく、制御された保管の開始である。

目的限定の失敗開示レシート

私は、各開示方針と例外的な提供ごとに、小さな失敗開示レシートを残すことを提案する。これはIETFへの追加要件ではなく、運用統治のための提案である。

レシートは、DMARC方針ドメイン、DNS参照時刻と結果、要求されたruf宛先とfo条件、外部宛先承認、受信者方針の版、目的と失効日から始める。次に失敗区分と単独・集約の別を示し、派生認証項目、限定した追跡ヘッダー、編集済みアドレストークン、短い抜粋など、選択したデータの種類だけを列挙する。値そのものは写さない。

さらに編集方式と版、相関範囲、集約規則、流量制限結果、安全輸送結果、生成エラーを記録する。消費側では、利用者の役割、アクセス境界、隔離結果、保存期限、削除または後継レシートを、責任者の決定に結び付ける。

本文、ローカル部、受信者アドレス、資格情報、動作する悪性URL、添付物をレシートに入れてはならない。内容の指紋も、目的とリスクが必要性を上回る場合に限り、範囲と期限を定めて使う。そうすれば、後日「なぜこのデータが境界を越えたのか」と問われたとき、DNSに書いてあったからではなく、誰が何を理由に選んだかを答えられる。

出典

  1. Lu Heng — データ主権の技術的現実と実務的現実
  2. Lu Heng — BTW Mediaが存在する理由
  3. Lu Heng — Policy Mirror
  4. IANA — Messaging Abuse Reporting Format Parameters
  5. RFC 9991情報ページ
  6. RFC 5322 — Internet Message Format
  7. RFC 5965 — メール・フィードバック報告形式
  8. RFC 6590 — メール悪用報告に含まれる機微データの編集
  9. RFC 6591 — ARFによる認証失敗報告
  10. RFC 6650 — メール・フィードバック報告の作成と利用
  11. RFC 7489 — DMARC
  12. RFC 9989 — DMARC
  13. RFC 9990 — DMARC集計報告
  14. RFC 9991 — DMARC失敗報告