要約

  • environment はインタープリターが観測した実行文脈を返す。標準化された項目名は、その値の由来や信頼性まで認証しない。
  • remote-host は信頼できないPTRから得られる場合がある。ドメイン末尾の一致を組織内部の証明として使うことをRFC自身が警告している。

ルールは「受信箱Aで始まったメッセージを受信箱Bへ移す」ものだった。実行後の監査画面には imap.mailbox=A と成功した fileinto が並び、別の集計は環境値だけを読んで「Aに残った」と判定した。

どちらの値も壊れていない。RFC 6785は imap.mailbox をスクリプト開始時に固定し、fileinto があっても変化させない。環境値は起点を説明し、アクションのレシートは遷移を説明する。二つを一つの現在状態として扱った集計が誤っていた。

これは特定製品の障害報告ではない。標準が保存している現実の層を、運用記録でも分離するための設計例である。

メッセージではなく実行環境を照会する

RFC 5183の environment テストは、項目名と照合キーを受け取る。指定がなければ :is と i;ascii-casemap を使う。値は現在のメッセージから直接抽出されず、インタープリターの動作環境から与えられる。

この仕組みにより、同じスクリプトが実行ホストやサービス位置、配送段階、接続元に応じて振る舞いを変えられる。しかし、その柔軟性は値を身元証明に変えない。値を生成したプロセス、観測点、導出手法、時刻を失えば、後から判断を再現できない。

初期項目の役割は限定されている。domain は実行文脈の主要DNSドメイン、host は実行ホスト、location は MTA・MDA・MUA・MS の別、phase は最終配送に対する pre・during・post を示す。name と version は製品情報、remote-host と remote-ip は適用可能なリモートSMTP・LMTP・Submissionクライアントの情報である。

どの定義も、企業所属、信頼済みテナント、正確なビルド、コミット済み配送、利用者の閲覧を保証しない。より強い意味はローカルな証拠契約が担う。

存在しない項目はスクリプトを壊さない

項目が実装されていない場合、テストは常に偽になり、スクリプト自体をエラーにしてはならない。これは異なる実装へ移動するための重要な失敗経路である。

空文字列を :contains で照合すれば、項目が既知かを調べられる。返された文字列は必ず空文字列を含むからだ。ただし、既知であることと情報があることは別である。remote-host は取得不能なら空文字列になる。

RFC 5231の :count を使うと、空の値は0、非空は1となる。これは値の有無に近い判定であって、証拠源の数、確度、鮮度ではない。

したがってテスト計画は、項目なし、項目あり・空、非空・未検証、ポリシーによる検証済みを別々に扱う。どれも同じデフォルト分岐へ落とせば、互換性のための寛容さが権限昇格になる。

逆引き名は境界線にならない

RFC 5183は remote-host の決め方を実装に委ね、信頼性が異なると明記する。一般的な方法は接続元IPのPTR検索だが、その情報は信頼できない源から来る可能性がある。

逆引きゾーンを管理する者は、自分が選んだドメイン名を公開できる。そのため *.example.com との一致を「外部ではない」証拠にするのは不適切である。比較が正しくても、名前に与えた権限が誤っている。

重大な分岐では、ピアIP、観測したプロトコル上の位置、逆引きクエリ、リゾルバー、応答、キャッシュ年齢、検証状態、正引き確認方針を保存する必要がある。それでもDNS名が人や企業の業務上の役割まで自動的に証明するわけではない。

remote-ip は導出前の観測に近いが、リレー、プロキシ、NAT、Submissionサービスでは原送信者と直近ピアが異なる。どのホップを誰の代理として信頼するかは配備側の規則である。

開始時スナップショットと結果を分ける

RFC 6785はIMAPイベントにRFC 5183を応用する。location=MS、phase=post とし、imap.user、imap.email、imap.cause、imap.mailbox、imap.changedflags を追加する。

imap.cause は APPEND・COPY・FLAG という起動原因を表す。起動後のSieveアクションが成功したことまでは示さない。imap.mailbox は開始時に固定される。imap.changedflags は変化したフラグ名を示せても、各フラグが設定されたか解除されたかを示さず、現在値を別に調べる必要がある。

この設計は欠陥ではない。一つのフィールドが一つの問いだけに答えるための境界である。監査側が起点、判断、アクション、遷移後の状態を別々に保存すれば、値は明確な証拠になる。

phase=post も同じで、配送ライフサイクル上の位置を示す。ストレージトランザクション、レプリカ、索引、クライアント表示をまとめて保証する語ではない。

登録は語彙を守り、意味の同一性は保証しない

RFC 5183は標準項目とベンダー項目のレジストリを定める。標準利用の項目は標準化過程または実験RFCで定義され、ベンダー項目は vnd. で始まる。IANAの現行表には初期項目、IMAP用追加項目、ベンダー空間がある。

名前衝突の防止は重要だが、移植性の完全証明ではない。ある製品の vnd. 項目が別製品に存在するとは限らず、似たクラスタ名が同じ障害領域を表すとも限らない。標準の location=MS でも、コミット点や可視化順序はローカル設計に依存する。

RFC 5463の ihave は能力の有無を条件分岐できる。能力あり、項目あり、本次値あり、値を信頼可能、という四つは独立している。ManageSieveの管理面でスクリプトが保存されていても、特定メッセージの実行文脈までは証明しない。

最小共通仕様はここで役目を果たしている。将来の選択を中央に固定せず、参加者が理解する値だけを採用できる。運用者は、その自由を曖昧なフォールバックで失ってはならない。

時系列を持つ証拠オブジェクト

拒否、破棄、転送、隔離、解放を行うポリシーでは、不変の判断IDとスクリプトハッシュ、実際のインタープリタービルドを記録する。各環境項について、存在状態、原値、由来、導出方法、location、phase、比較器、選択分岐を残す。

次にアクションの応答と下流システムのレシートを結ぶ。メールボックスが変わるなら開始時 imap.mailbox と最終宛先を別フィールドにする。利用者可視性が要件なら最後に実測する。

最終確認は「項目は一致したか」ではない。「その値はいつの状態で、誰がどう観測し、どの権限判断に使い、その後の状態は何で確認したか」である。時間軸を失わなければ、環境値は結果を装う必要がない。

情報源

  1. RFC 5183 — HTML
  2. RFC 5183 — プレーンテキスト
  3. RFC Editor情報ページ
  4. IETF Datatracker文書ページ
  5. IETF Datatracker履歴
  6. IETF Datatracker参照関係
  7. RFC 5183正誤表
  8. RFC 5228 — Sieve基本仕様
  9. RFC 5228情報ページ
  10. RFC 5231 — relational拡張
  11. RFC 5598 — Internet Mail Architecture
  12. RFC 6785 — SieveのIMAPイベント
  13. RFC 6785情報ページ
  14. RFC 5804 — ManageSieve
  15. RFC 5463 — Sieve ihave拡張
  16. IANA Sieve Extensionsレジストリ
  17. IANA Sieve Environment Itemsレジストリ
  18. Heng Lu — 現実の層
  19. Heng Lu — 最小仕様と自発的採用
  20. Heng Lu — running codeの優先