要約

  • RFC 9991ではDomain OwnerがDMARC失敗の詳細を要求できるが、Mail Receiverは報告を作るか、どの種類を送り、何を開示するかを自らの方針で決める。
  • 外部宛先の検証は、そのドメインが報告関係を受け入れたことを示す。本文、個人アドレス、保持期間、再転送、処分のすべてを許可するものではない。
  • 認証失敗、DNS要求、開示判断、削減、配送、報告の検証、アカウントへの措置を一つの自動処理にしてはならない。

メーリングリストは、もとの投稿に件名やフッターを加え、配信し直すことがある。その結果、DKIM署名が壊れ、SPFはリスト側の経路を評価し、最終受信者でDMARCが失敗する。これは不正メールとは限らない。

それでも、投稿者のAuthor Domainがrufを設定していれば、失敗報告の候補になる。報告が原文や完全なヘッダーを含むと、ドメイン所有者はリストの加入者や転送先を知り得る。診断に必要な証拠と、通信当事者が想定しなかった開示が同じファイルに入る。

この例はRFC 9991の弱点ではない。標準が明示的に残したMail Receiverの判断を、運用が省略したときに生じる問題である。

要求者と保有者を同じ主体にしない

RFC 9991は2026年5月にIETF Standards Trackとして公開された。DMARC failure reportは、一通の失敗、または同じ原因で失敗した一群を詳しく伝え、日単位の集計より早く原因を調べられる。

Domain OwnerはRFC 9989のrufとfoで、希望する宛先と失敗条件を公表する。だが、RFC 9991は「要求がある」だけで報告を義務付けない。Mail Receiverが提供する意思を持つ場合に生成し、どの報告形式を送るか、あるいは送らないかを受信者側のポリシーで決める。

Domain Ownerは自社の正当な送信基盤を知っている。Mail Receiverは実際のメールを保持し、受信ユーザーとの契約を持ち、開示の影響を負う。前者の診断要求を尊重しつつ、後者の判断を残すことが、分散したメール運用に必要な権限分離である。

Aggregateとfailure reportは情報量だけでなく性質が違う

RFC 9990のaggregate reportは、期間、送信元IP、件数、認証結果、適用ポリシーをまとめる。傾向と設定漏れを把握しやすいが、一通ごとの会話を再送しない。

RFC 9991のfailure reportはAbuse Reporting Formatを使う。RFC 5965は、人向け説明、機械可読フィールド、原文または全ヘッダーの三部を定める。RFC 6591は認証失敗用フィールドを定義し、RFC 9991がDMARC用に更新する。

原文は原因特定に強い。どのヘッダーが届き、どの署名とドメインが評価され、何が書き換わったかを調べられる。同時に、個人情報、非公開の業務内容、日程、法務相談、最終配送先も運ぶ。

RFC 9991は、対象と期間を限定し、URIを管理し、本文とヘッダーを最小化またはredactし、安全な経路を使うよう強く勧める。大規模プロバイダーの多くがfailure reportを制限・無効化し、内容を露出しないaggregateを好むことも記す。

従って、aggregateを既定にし、必要性が立証された案件だけメタデータ、選択ヘッダー、短期間のサンプルへ段階的に進む設計が合理的である。詳細を出さないことは観測を捨てることではない。

外部宛先のDNS承認は受領範囲を定義しない

rufが別のOrganizational Domainを指す場合、RFC 9991はRFC 9990の外部宛先検証をruf向けに用いる。外部側が対応する承認を公開していなければ、Mail Receiverはそこへ報告を送らない。

この往復確認は、無関係なドメインを勝手に報告先へ登録する行為や、受信者群を使った反射トラフィックを抑える。確認できるのは「この外部ドメインが、このポリシードメインの報告を受ける関係に同意した」という範囲である。

本文を読める担当者、保存場所、再転送、保持年数、機械学習、封鎖措置までは承認しない。見かけ上は社内のメールアドレスでも、さらに転送されれば最終消費者はDNSだけでは分からない。

運用契約には、要求ドメイン、受信ドメイン、実際のReport Consumer、許可フィールド、目的、サンプリング、アクセス、再処理、保持、削除、事故対応を結び付ける必要がある。DNSはその関係を検査する一証拠であり、関係全体ではない。

psd=yのPublic Suffix Domainにあるrufを、特別な合意なしに考慮してはならないというRFC 9991の規則も同じ原理を示す。広い名前空間であることは、配下の詳細メールを集める委任ではない。

Identity-Alignmentから人の意図を読まない

RFC 9991はIdentity-Alignmentを追加した。IANA MARF Parametersでは、aligned identityの認証に失敗した方式を列挙し、すべて成功ならnoneとする現行フィールドである。

これはDKIMとSPFのどちらがDMARC alignmentを満たさなかったかを示す。投稿者が悪意を持ったか、誰が操作したか、転送が正当かは示さない。

画面表示から「Alignment」を落として「Identity failure」とだけ書けば、ドメイン比較を人物認定へ変質させる。評価対象ドメイン、方式、受信者、時刻、結果を保ち、人的帰属は別の調査で扱うべきである。

Redactionは匿名化よりも相関制御である

RFC 6590は、選んだ私的文字列を一貫して変換する方法を示す。同じ入力を同じ仮名にすれば、消費者は元のアドレスを見ずに同一人物への集中を検知できる。

しかし、安定した仮名は相関権限である。長期間、複数顧客、複数用途で共通にすれば、新しい影の識別子になる。鍵とepoch、安定期間、利用目的を決めなければならない。

Message-ID、時刻、珍しい件名、Received列、別組織のログから再識別できることもある。人が書く全言語の私的表現をソフトウェアが完全に見つけることは難しい。RFC 6590自身がその限界を認める。

したがってredactedという一つのフラグでは足りない。対象フィールド、削除、変換、鍵epoch、試験言語、残存識別子、承認目的を版管理する。比例した報告を作れなければ、aggregateまたは抑止を選ぶ。

報告の内容は新たな検証対象になる

RFC 5965はARFの機械フィールドを「assertion」と位置付け、常に正確とは限らないと警告する。フォーマットは内容の真正性を自動的に与えない。認証された報告でも、生成側の解釈が誤ることや、悪意ある添付を含むことがある。

Report Consumerは、関係と送信元、構文、サイズ、整合性を検証し、活動的内容を隔離し、自社の送信ログと鍵履歴に照合する。RFC 6449もfeedback loopを、相手、データ取扱い、量、例外を持つ運用関係として扱う。

RFC 9991が送信rate limitを必須にするのは、報告自体が攻撃になり得るからだ。攻撃者が被害ドメインを名乗る大量メールを送り、SPFとDKIMを失敗させれば、多数の受信者から報告先へ流量を生じさせられる。ドメイン別だけでなく宛先、tenant、全体の予算が必要である。

同じ失敗はIncidentsでまとめられる。リンクは無害化し、添付を除き、受信ストリームを隔離・sandbox化する。報告メール自体もDMARC alignedにして、報告が次の報告を生むloopを避ける。

標準は判断の連鎖を短縮しない

Heng LuのReality Layersに沿えば、認証失敗、要求、開示判断、報告bytes、配送、解釈、処分は別々の現実である。一つの真実が次の権限を生まない。

Minimum Initial Specificationは、共通タグ、フィールド、宛先検証、fail-safeを標準化し、目的と開示を責任あるローカル運用へ残す理由を示す。

Running-Code Primacyが求める証拠は、実際に動いた評価器、ポリシー、生成分岐、変換、DNS応答、送信hash、消費者、最終効果である。

RFC 9991は診断要求を伝達可能にした。メーリングリストの会員を開示する権限まで、その要求に埋め込んではいない。