要約

  • RFC 3028はメールフィルターを制限された動作言語として定義し、配送に影響する動作が選ばれない場合には暗黙の保存を行う安全策を置いた。
  • keep、fileinto、redirect、discard、拒否はインタープリターが選ぶ処置であり、永続保存、相手側の受理、または最終的な配送結果の証明ではなかった。

サーバー上のメールフィルターには、便利さと危険が同居する。利用者は到着時に分類や転送を行いたい。しかし配送サーバーで任意のプログラムを実行できれば、無限ループ、外部コマンド、資源の浪費が共有基盤へ持ち込まれる。

2001年のRFC 3028は、機能を増やすのではなく減らすことでこの問題に答えた。Sieveにはループも関数も外部プログラム呼び出しもない。テストは副作用を持たず、制御構文が分岐を選び、動作だけがメッセージの処置を要求する。制約は表現力の不足ではなく、サーバー側で利用者の規則を安全に扱うための境界だった。

規則の漏れをメールの消失にしない

フィルターは将来のすべてのケースを予測できない。送信者のアドレスやメーリングリストのヘッダーが変われば、昨日の条件は簡単に外れる。何も一致しないときにメールを捨てる設計なら、規則の不備がそのまま損失になる。

そこでSieveは暗黙の保存を定めた。これを取り消す動作がなければ、フィルターを使わない場合と同じ既定処置、通常は主メールボックスへの保存が行われる。

ただし、すべての処置に予備コピーを追加する仕組みではない。keep、fileinto、redirect、discardはいずれも暗黙の保存を取り消す。後の拡張が通知やヘッダー変更のような副次的効果だけを生むなら、暗黙の保存を残すかどうかを明記しなければならない。

discardの意味は特に興味深い。名称は全面的な削除を連想させるが、基本仕様上の核心は暗黙の保存を静かに取り消すことだ。fileintoと併用すれば、指定フォルダーへの保存は残り、既定受信箱への追加保存だけが消える。標準が定義したのは強い印象の単語ではなく、動作集合に対する限定的な効果である。

動作を選ぶことと処理が完了すること

keepは実装の通常処置を要求する。利用者は主メールボックスの物理名や保存方式を知らなくてよい。移植性を生む抽象化である一方、規則の評価成功からディスク容量、権限、トランザクション完了を推定することはできない。

fileintoはフォルダーを指定する。RFC 3028は対応を推奨したが、提供できない環境も認めた。フォルダー名が構文上正しいことと、その場所が存在し書込みが確定することは別である。

redirectはエンベロープ受信者を置き換え、MTA型の転送を開始する。ローカルの規則が正しく選ばれても、相手サーバーは受信を拒める。受理後の扱いも相手側の制御下にある。ループ検出も実装の責任だった。転送命令は新たな配送区間を開始するが、その終点の受領証ではない。

discardは配送不能通知を返さず、沈黙しなければならない。送信者から見える信号がないこと自体が仕様であり、成功証明ではない。監査が必要なら、本文を不必要に保持せず、実行側が決定の証拠を適切な期間だけ管理する必要がある。

動作の組合せは副作用の統治だった

一通のメールに複数の動作が当たると、個々の名前より相互作用が重要になる。RFC 3028は拡張に対して基本動作との関係を説明するよう求め、サイトが数や組合せを制限できるようにした。同じメールボックスへの保存を二度要求しても、実装は重複配送を避けるべきだとされた。

この仕組みは増幅と矛盾を抑える。多数の転送はメール爆弾になり得る。保存と拒否を同時に行えば、送信者へ失敗を伝えながら実際にはコピーを保持することになる。各命令を独立作業として扱うだけでは、規則全体の意味が失われる。

RFC 5228はRFC 3028を置き換えたが、暗黙の保存と基本動作の構造を維持し、エラーや拡張の関係を明確にした。RFC 9122はさらにIANAのSieve Actions登録簿を設け、「暗黙の保存を取り消すか」「他の動作とどう相互作用するか」を項目として記録した。登録簿は契約を示すもので、個別メールの成功記録ではない。

拒否の改訂が示した時間軸

RFC 3028のreject拡張は、メッセージを捨て、エンベロープ送信者へ処置通知を送る方式だった。受信側がいったんメールを受理した後に通知を作る場合があり、送信者アドレスが詐称されていれば、無関係な第三者へ返送が集中した。

RFC 5429はerejectを加え、可能ならSMTPまたはLMTPの会話中に受信を拒む方法を優先した。拒否は暗黙の保存を取り消し、一通に複数の拒否を行ってはならず、配送動作との併用も推奨されない。理由は結果表示の整合性にある。保存したメールを「拒否した」と送信者へ伝えるべきではない。

したがって「拒否済み」という一語では足りない。規則が拒否を選んだのか、実行部品がプロトコル上拒否できたのか、送信者が即時応答、後日の通知、または無信号のどれを見たのかを分ける必要がある。

RFC 5804のManageSieveは、スクリプトの投入、検査、一覧、活性化という管理面を標準化した。活性化されたことは特定メールの評価証拠ではない。評価して動作を選んだことも、その結果の証拠ではない。管理、判断、結果は別の事実である。

情報源

Lu HengはRFC 3028、RFC 5228、RFC 5429の著者ではなく、これらを支持したとも主張しない。本稿では分析視角として明示的に用いている。