要約

  • RFC 5293では、通常の検査・保存・送信は編集済みの現在状態を使う一方、MDNやDSN、エラー終了時の暗黙のkeepは未変更の原本ヘッダーを使う。
  • 編集前後は重複排除上同じメッセージであるため、実行成功だけでは保存内容、署名状態、通知内容、最終配送を特定できない。

変更票に欠けていた列

ある組織は外部から付いた承認印を削除し、内部ラベルを追加してからメールを保存・転送していた。処理は正常終了したが、後日の監査でDSNは旧ヘッダーを、保存コピーは新ヘッダーを示し、DKIMは転送側で失敗した。

変更票には「Sieve成功」としかなかった。必要だったのは、各処理がどの状態を読んだかという列である。

addheaderは既定で先頭にフィールドを加え、:lastなら末尾に置く。deleteheaderは全出現または:indexで選んだ出現を削除する。値の照合より先に位置が数えられ、一度削除すれば後続の番号は変わる。最終状態だけでは途中の判断を再現できない。

原本は過去ではなく現役の入力

existsやheader、vacation、保存・送信・変更を行う通常の処理は、その時点の現在ヘッダーを見る。includeされたスクリプトにも変更は引き継がれ、戻った後も維持される。

一方、MDN、DSNなどの処分通知は原本の未変更ヘッダーを使わなければならない。エラーで処理が終わる場合の暗黙のkeepも原本を使う。通常の暗黙keepは、取り消されていなければ編集後に実行されると考えられる。

同じkeepという語でも、発生理由を失えばどの表現が保存されたか判断できない。

同一性と表現は別の契約

重複排除では、addheaderやdeleteheaderを受けたものも原本と同じメッセージである。冗長な二つのkeepから同じメールボックスに二通を作ってはならないが、どちらを実行するかは実装が選べる。

これは、同じメッセージID、同じバイト列、同じ配送結果が同義でないことを示す。監査では三つを分けて保存する必要がある。

無言の無視も結果である

ローカル方針は編集対象を制限でき、禁止された変更はエラーなしで無視される。ReceivedとAuto-Submittedの削除は許されず、Subjectの追加・削除は許可されなければならない。Receivedの保護はSMTPループ防止の証跡を守る。

正常終了は全命令の反映を意味しない。要求、方針判断、実際の差分を別々に記録すべきだ。

署名が示すのは特定の層

DKIMは、追加されたフィールドだけでなく「そのフィールドが存在しない」ことを署名している場合もある。編集でその主張が壊れ得る。S/MIMEやOpenPGP/MIMEでは、署名された内側のヘッダーが残り、外側だけが変わることがある。

また、正しい構文は信頼できる発行者を保証しない。受信時の状態を凍結・検証し、外部由来の印を隔離してから、出所の明確な内部印を発行する順序が必要である。

再現できる実行証跡

原本ヘッダーのハッシュ、全フィールドの順序、スクリプト版、能力セット、各アクションの番号・選択条件・方針判断、変更前後の現在ハッシュを残す。次の処理が原本、現在状態、署名内側のどれを読んだかも明記する。

署名の前後結果、重複排除キー、冗長処理の選択、保存・送信の応答、宛先側の観測も必要だ。redirectの選択は受信完了の証明ではない。

情報源