要約

  • RFC 5232 により、Sieve は処理中のメッセージについてフラグ集合を作成・検査し、keep や fileinto による配達コピーへ引き渡せる。
  • これは IMAP ストア全体の編集機能ではない。宛先メールボックスが永続保存できないフラグは無視し、それだけを理由にスクリプトの実行失敗としてはならない。

印は配達の判断に伴って移る

受信したメールは解析され、振り分けられ、やがてメールボックスに保存される。IMAP フラグは、保存されたメッセージに結び付く状態だ。2008 年 1 月の RFC 5232 は Sieve からその状態を指定できるようにしたが、いま処理中のメールの配達先を決めることと、メールボックスを書き換えることは区別したままだった。

imap4flags 拡張が必須とするのは、setflag、addflag、removeflag、hasflag の四つの操作・テストと、keep / fileinto に渡す :flags 引数である。最初の三つはフラグの集合を操作し、hasflag は指定した名前の有無を調べる。配達時の引数は、現在のメッセージの保存コピーにフラグ集合を添える。

その集合は Sieve の実行中だけ使われる状態だ。開始時の内部変数は空で、setflag は中身を置き換え、addflag は追加し、removeflag は削る。hasflag は現在の集合を検査できる。別の Variables 拡張も利用できれば複数の名前付き集合を持てるが、対応していない環境で変数名を明示するとエラーになる。フラグ名は大文字・小文字を区別しない。並び順、表記の大文字・小文字、重複が維持されることを前提にしてはならない。

受け渡しの要点は配達アクションにある。keep または fileinto に :flags を付ければ、その引数の集合が保存コピーに使われる。省略した場合は内部変数の現在値が適用される。同じ値は暗黙の keep にも使われる。明示的な配達アクションが別の処理に置き換わっていないとき、メッセージを保持する既定の振る舞いだ。ある分岐で加えた印を後段のアクションへ渡すことも、格納時に別の集合を明記することもできる。

ただし、RFC 5232 が対象にするのは、その Sieve 実行で処理されているメッセージだけである。メールボックスにすでにある別のメッセージを選び、フラグを書き換える権限はない。また、別のアクションの副作用で生成された別メッセージにも作用しない。つまり配達時の接点であって、IMAP ストア全体の汎用変更 API ではない。

宛先メールボックスにも制約がある。:flags は配達コピーに付けたい集合を示すが、すべての保存先があらゆるフラグを永続化できるとは限らない。解釈系は恒久的に保存できないフラグを無視し、それだけを理由に Sieve の実行エラーとしてはならない。RFC の例では、\\Deleted を保存できない箱なら、fileinto :flags "\\Deleted" とフラグなしの fileinto は同じ扱いになる。IMAP の \\Deleted は後の expunge を待つ印であって、物理削除が完了した証拠ではない。

したがって「ルールが印を付けた」だけでは、複数の段階を混同しやすい。条件分岐が成立したか、解釈系が集合を作ったか、配達アクションがそれを要求したか、保存先がどれを永続化したか、クライアントが最終的に何を表示したかは、別々に確かめる必要がある。RFC 5232 は解釈系が IMAP クライアントとして接続するか、保存庫へ直接触るかも指定していない。実装経路が異なっても、拡張の対象は現在のメッセージに限られる。

複数の配達先が重複排除によって一つのコピーにまとまる場合の優先順位も定められている。複数の keep / fileinto による重複メッセージ排除では、最後に指定したフラグ集合を採用する。結果のコピーが、各分岐の意図をすべて併合するとは限らない。スクリプト内の addflag を数えるだけで最終状態を推測せず、アクションの順序と配達処理を追う必要がある。

RFC 5232 は、基礎言語 RFC 5228、変数拡張 RFC 5229、関係演算拡張 RFC 5231 と並ぶ Sieve の標準である。隣接する仕様は構文や値の扱いを説明するが、配達境界は変えない。後年の IMAP4rev2 RFC 9051 は永続フラグとセッション限定フラグを区別し、\\Recent を非推奨とした。指定した印と永続状態は同じではない。標準が示すのは契約であって、特定サーバーの実装、メールの実着、クライアント画面の表示を証明するものではない。

参考資料