要約

  • 初版草案は、DKIM2 の全署名列に対して機械可読な結果を一つだけ出し、起点ドメインと該当する失敗位置を属性で示す。
  • その Authentication-Results は DKIM2 で署名されず、生成した ADMD の内部でのみ意味を持つ。下流への証明として複写してはならない。
  • pass 以外でも header.d は診断用に現れ得るが、認証済みの身元ではない。各ホップのコメントは人向けの非信頼テキストである。

メール運用では、短い結果ほど長生きしやすい。署名列そのものは保存コストが高く、dkim2=pass は集計しやすい。ところが別組織へ転送された後も短い結果だけが残れば、その文字列は、どの鍵と SMTP エンベロープで誰が検証したのかを説明できない。

2026 年 9 月 5 日に告知された報告草案の初版は、この省略の境界を定義する。DKIM2 はメッセージの取扱いを署名列で記録する。Authentication-Results は、検証済みの結果を同じ管理領域内の評価機能へ伝えるため、検証後に追加される。両者は同じ保護を持たない。

Datatracker API の記録によれば、これは個人提出の Internet-Draft であり、IETF の承認や正式な標準上の地位はない。XML ソースが revision 00 の本文を固定し、I-D 告知が公開時点を示す。Standards Track を意図するとの記載は、到達済みの状態ではない。

基礎となるDKIM2 WG 草案 revision 06は、検証試行の出力として PASS、FAIL、PERMERROR、TEMPERROR を定める。今回の草案は小文字の結果名へ写し、DKIM2 署名がなく検証もしなかった場合の none を加える。基礎文書のDatatracker API 情報は WG 文書としての事実であり、個人提出の報告草案の採用を意味しない。

結果が一つなのは、DKIM1 と設計対象が違うからだ。DKIM1 では独立した署名ごとに結果を持てる。ここではメッセージ全体の Chain of Custody が成立するかを一度だけ報告する。検証者は最新の大きな i= から逆向きに調べ、失敗時に停止できる。未確認の古い署名はコメント内で skipped となる。失敗したのではなく、確認されていない。

この差が header.d の意味を変える。値は i=1 の起点署名ドメインから取る。調査を助けるため、全体が fail や temperror でも表示できる。しかし認証済みの身元になるのは全体が pass のときだけだ。結果を落としてドメインだけを評判DBへ送ると、診断用の観測値を身元証明へ変造する。

header.i は名前の衝突も抱える。DKIM2 では失敗を帰属する署名の連番である。DKIM1 の同名属性は Agent or User Identifier だ。メソッド名を保存しない共通スキーマは、位置番号とアイデンティティを同じ型として扱ってしまう。

信頼の根拠は RFC 8601 にある。Authentication-Results は、一つの Administrative Management Domain 内で、検証機能から評価機能へ結果を渡すための欄だ。外部から到着するメールは、自組織の authserv-id を装った欄を含められる。境界 MTA は、不可信な経路から来たそのような欄を削除してから、自らの結果を追加しなければならない。

authserv-id は検証サービスを識別する文字列であって、自己認証する署名ではない。どの値を信じるかは、ローカル設定と内部配送経路で決まる。DKIM2 はこの欄を署名対象から意図的に外す。検証後に追加され、境界で除去されるからだ。従って、途中の処理系が書き換えても DKIM2 は検出しない。

正規の結果であっても次の SMTP ホップには移転しない。最新の DKIM2 署名は、ある受信取引の MAIL FROM と RCPT TO に結び付く。その検証者の pass は、そこで観測された取引までを表す。転送者は旧結果を下流のためにコピーしてはならない。自らの取扱いを検証可能にするなら DKIM2 署名を加え、次の受信者が全列を検証して新しいローカル結果を書く。

コメントは、各 i=、ドメイン、ホップ結果と診断を人に見せる。草案は、適合パーサーがコメントを捨ててもよいとする。見た目が規則的でもAPIではない。機械判断は定義済みの結果と属性だけに依存すべきだ。

しかも診断へ代入される selector、ドメイン、MAIL FROM、RCPT TO は送信者や中継者の影響を受ける。RFC 5322のコメント文法では、丸括弧とバックスラッシュに意味があるため、quoted-pair としてエスケープする必要がある。長さを制限し、表示時もマークアップとして解釈してはならない。対策を欠けば、攻撃者の値がコメントを閉じ、別の認証結果のように読まれる恐れがある。

詳しいコメントは、経由ドメイン、転送関係、受信者アドレスも漏らし得る。診断価値があることと、無期限に複製すべきことは同じではない。

設計は ARC の先例に近い。少数の属性は機械可読にし、各インスタンスの事情はコメントへ置く。DKIMは従来属性の意味を示し、Internet Mail Architectureは ADMD を運用上の境界として位置付ける。

調査時点の IANA Email Authentication Parameters に dkim2 はなかった。草案はメソッド、二属性、五結果の登録を求めている。要求は将来の調整案であり、登録済みという証拠ではない。

Heng Lu の最小初期仕様は、共通語彙と将来のローカル判断を分ける。現実の層は署名、検証、報告、処置を同一視しない。Running-Code Primacyが問うのは、境界 MTA が実際に何を削除し、どこで再検証したかである。

pass は短い。信頼経路の説明まで短縮してよいわけではない。