要約

  • draft-gondwana-dkim2-debug-header-01 は、DKIM2 の初期試験で使う X-DKIM2-Info の形式をそろえる。新しい認証結果を定義する文書ではない。
  • このフィールドはハッシュと署名から意図的に除外される。人を次の証拠へ導くことはできても、発行者、処理、スナップショット、記録の完全性を証明できない。

届いた障害メールには、まるで調査報告書が添えられている。受信フィルターが実装した DKIM2 の草案版、リポジトリ、プログラム名が一行に並ぶ。別の行はメーリングリストソフトウェアが Message-Instance m=2 を作成したと述べ、ハッシュしたヘッダーと以前の保存データを指す。最後に送信フィルターが、チェーン破損を理由に署名しなかったと報告する。

実装同士を比較する担当者には、極めて有用な手掛かりだ。だが、配信、隔離、帰責を決めるソフトウェアにとっては証拠にならない。各行を挿入し、書き換え、並べ替え、削除しても、DKIM2 が保護する部分はそのまま検証に成功し得るからだ。

この境界を明示するのが A Diagnostic Header Field for DKIM2 Implementations である。01 版は太平洋時間 2026 年 9 月 30 日、上海と UTC ではすでに 10 月 1 日に登録された。I-D Exists の個人 Internet-Draft で、想定ステータスは Informational。DKIM ワーキンググループの採択文書でも、RFC でも、IANA 登録でも、DKIM2 の規範的依存先でもない。本文自体が初期テスター向けで、公開規格になる可能性は低いと説明している。

実装差を同じ言葉で観察する

DKIM2 は、メーリングリストなどがメッセージを変形しても検証可能な連鎖を残そうとする。Message-Instance には以前の状態を復元するためのハッシュと Recipe が入り、DKIM2-Signature が保護された記録をつなぐ。二つの試作実装が同じ入力に異なる結果を返したとき、最終的な成功・失敗だけでは分岐地点が分からない。

X-DKIM2-Info は手掛かりの置き場所を統一する。一つのフィールドに draft、repo、date、sw、action の五つを順番に記す。draft は実装対象の DKIM2 版を示す。リポジトリとプログラム名で部品やフォークを区別し、date はその発行者の DKIM2 動作が変わったとき更新する。フィールド一つが処理一つに対応し、複数処理なら複数行になる。

語彙には検証、Message-Instance の追加、署名、署名拒否がある。verify=pass と verify=fail には自由文の説明を付けられる。mi-m=<N> はハッシュ対象ヘッダーの数と順番、参照したスナップショットと新たに保存したスナップショットの識別子を持てる。sign はドメインとアルゴリズム、not-signed は broken-mi-chain のような実装固有の理由を示す。

01 版は 00 版の相互運用上の雑音も減らした。DKIM2 本体の拡張タグ文法をそのまま採用し、最後を含むすべてのタグにセミコロンを付け、mi-m<N> を mi-m=<N> に変更した。表記の違いに邪魔されず実際の動作差を見つけやすくなる。しかし、文法が一致しても証拠能力は増えない。

保護されないからこそ、好きな場所に置ける

DKIM2 本体草案は、名前が X- で始まるヘッダーを Message-Instance のヘッダーハッシュから除外する。デバッグ草案も、発行者が X-DKIM2-Info を署名またはハッシュ対象に入れることを禁じる。したがって処理を説明する一行を対象ヘッダーの隣に置いても、Message-Instance は変わらず、DKIM2 署名も壊れない。

その利便性は、同時に自己証明を不可能にする。草案はこのフィールドを検証結果ではないとし、権威ある結果は Authentication-Results に置くよう求める。記録されるのは発行者が行ったと主張する内容だけであり、ソフトウェアはそれを根拠にメッセージ判断をしてはならない。経路上の誰でも検知されずに追加、変更、削除できる。

BTW の既存記事が扱った DKIM2 の Authentication-Results とは焦点が異なる。既存記事は、一つの管理ドメインと SMTP トランザクションの中で、信頼された authserv-id によるローカル判定をどこまで使えるかを検討した。今回のフィールドは、そのローカル判定よりさらに下にある。自動信頼から明示的に排除され、人間が次に調べる場所を示すだけだ。

隣にあることは、原因であることを意味しない

草案は、まず保護対象または動作対象のヘッダーを追加し、その直上に説明用フィールドを置くよう定める。準拠する発行者は既存のデバッグ行を変更・削除しない。ヘッダーブロックは、処理順を読むための見やすい年表になる。

ただし、隣接関係には認証がない。後段の処理系が本物らしい action=sign を先頭に加え、別の Message-Instance の横へ行を移し、失敗説明を削除できる。リポジトリのパスとプログラム名は自己申告で、バイナリのアテステーションではない。動作日付はコミットハッシュではない。イベント ID、実行インスタンスの鍵、シーケンス番号、受信確認、完全性宣言がないため、別々の行は改ざん耐性のあるログにならない。

何も書かれていない場合も解釈不能だ。最上位の Message-Instance がまだ一致し、発行者が何も追加しなければ、処理記録は残らない。mi-m=<N> がないことは、検査を実行した証拠でも、変更がなかった証拠でも、途中で痕跡が失われなかった証拠でもない。

スナップショット名は、スナップショットそのものではない

運用上とりわけ便利な snapf は Recipe 計算に用いた以前の保存コピーを、snaps は将来の比較用に保管した現在のコピーを指す。ところが識別子の意味は、それを書いた発行者の内部に限られる。例示された値はデータベースキーや保存パスにも見える。

その文字列を担当オペレーターに渡せば、対応するバイト列、ログ、保持状況を依頼できる。だがシステム外では、内容、保管経路、保持期間、現在の可用性を一切証明しない。実装が別途コンテンツダイジェストと取得レシートを提供しない限り、コピーされた識別子は持ち運べる証拠ではない。

詳しい記録には情報開示の代償もある。ソースリポジトリ、プログラム、草案版、保存構造、ハッシュ時のヘッダー一覧、自由文エラーが実装の内側を明かす。運用者は出口でフィールドを除去しても DKIM2 検証を壊さない。内部構造は守れる一方、遠隔テスターが必要とした手掛かりも失われる。内部保持と外部開示を一体で設計する必要がある。

解析にも角が残る。RFC 5322 はヘッダー名中のセミコロンを許すが、この形式はセミコロンをタグ終端に用い、引用構文を持たない。草案は危険な名前を hn から省き、長さを制限し、埋め込む値のセミコロンを置換または削除するよう求める。曖昧さは減るものの、初期実装がすべて同じ安全な処理をする証明にはならない。

RFC 6648 は X- 名の一般的な問題も示している。私的・実験的なフィールドは外に漏れ、事実上のインターフェースとなり、移行や安全性を曖昧にする。今回は、DKIM2 の意味と暗号保護の外にデバッグ情報を置くための意図的な選択だ。きれいなプロトコル境界を、運用上の封じ込めと取り違えてはならない。

手掛かりから検証可能な受領記録へ進む

堅牢な調査では、自己申告されたソフトウェア、自己申告された処理、実際に受信したフィールド、保持または除去した境界、実際の DKIM2 検証、ローカルな Authentication-Results、ビルドとログ、参照スナップショット、原因判断、修正、その後の配信結果を別々に扱う。読みやすさを理由に段階を飛ばせば、支援情報が根拠のない結論に変わる。

Heng Lu の最小初期仕様という考え方は、この分離と合致する。共有形式は独立試験を容易にすべきだが、ローカル実行の真実を代行すべきではない。稼働コード優先の原則は、実装と保存データを観察し、障害を再現し、修正後の結果まで確認するよう求める。

X-DKIM2-Info が有用なのは、故障の近くに人が読める指紋を残すからだ。危険になるのは、支援の便宜を来歴、方針、最終判定へ昇格させたときである。正しい自動化は手掛かりで処分を決めず、手掛かりを使って検証可能な証拠を回収する。

出典