要約

  • RFC 5260 の真偽は、選択された一つのヘッダー位置を指定のゾーンと比較器で評価した証拠であり、その日時が歴史的に正しいという証拠ではない。
  • 検証可能性には、順序付き生ヘッダー、選択子、解析、ゾーン、スクリプト版、実行時刻、分岐と実際の処理結果を別々に残す必要がある。

ゲートウェイを一台増やすと「二番目」の意味が変わった

インシデント調査チームは、二番目の Received: をローカル領域への入口とみなす Sieve 規則を使っていた。新しい検査ゲートウェイを前段に置いた後も、規則はエラーなく動き続けた。しかし同じ :index 2 は別のホップを選んでいた。

コードは同じでも、座標が参照する対象は同じとは限らない。

RFC 5260 の例自身が、フィールドのオフセットが一定であることを前提にする。索引は構文上の位置を再現する仕組みであって、信頼順位やネットワーク境界を固定する仕組みではない。

選択規則を保存しても対象を失えば再現できない

index がなければ date は同名フィールドの最初の出現を使う。:index は一から数え、:last は末尾から逆に数える。複数のフィールド名を指定できるテストでは、スクリプト中のリスト順も計数に影響する。

ログに「2」が残っていても、その時点のヘッダー列がなければ二番目が何だったか分からない。挿入、削除、書き換え、名前リストの順変更は、規則文を変えずに選択対象を変える。

false は原因を一つに決めない

対象フィールドがない、日時構文が壊れている、カレンダー上あり得ない、正しい日時だが条件外。この四つはいずれも false になる。実行分岐には十分でも、監査には不十分である。

:count の一は選択フィールドに有効な日時があること、ゼロはそれ以外を示すだけだ。すべての日時フィールド数でも、真正性の点数でもない。

ゾーン変換は問いを変える

:originalzone は抽出値に書かれたオフセットを保つ。:zone は指定した固定 UTC オフセットへ移す。両方の指定はエラーで、どちらもなければサーバーのローカルゾーンを使う。

同じメッセージと規則でも、配置先のゾーン設定が異なれば曜日や日付の判定が変わり得る。書かれたオフセットは地域や管轄、夏時間履歴を証明しない。変換後の時刻は比較用の投影であり、出所の信頼性を上げない。

currentdate の一貫性は一回の実行に閉じる

一つの Sieve 実行にあるすべての currentdate は同じ時点を参照しなければならない。深夜をまたいで条件同士が矛盾するのを防ぐ、明確な保証である。

ただし、それは送信、受信開始、最終配送、閲覧、承認の時刻ではない。RFC は、現在時刻に依存する規則が静的解析を難しくするとも述べる。コードだけでなく、実行ホストと固定された時点が必要になる。

構文の妥当性と証拠の強さは別である

Date: は通常送信者が入れ、途中で変更できる。最上段の Received: は通常ローカルメールシステムが入れるため、外部からは偽りにくい。これは重要な差だが、後者でも経路全体や後続処理は証明しない。

パーサーが正しい日時として受け入れたことは、誰が時計を支配し、どの出来事を表すかについて沈黙している。

実行レシートに残すもの

メッセージと生ヘッダーのハッシュ、順序付き一覧、選んだ名前と実出現、:index と :last、名前リスト順、抽出文字列、構文・暦妥当性、元オフセット、指定またはローカルのゾーン、正規化値、日時部分、比較器とキー、能力、スクリプト識別子と版、実行ホスト、固定 currentdate、false の原因、選択アクション、実行結果、最終的なメールボックスまたは転送観測を残す。

このレシートは過去を認証しない。システムが実際に答えた問いを失わせない。

Sources