要約

  • 特別用途の属性に合うメールボックスが見つかれば、そちらが名前指定の既定メールボックスより優先される。既定先は、対応先がない場合などに使うものである。
  • 選んだメールボックスへの配送が、その存在とは無関係な理由で失敗しても、既定先へ再試行してはならない。障害のたびに保存場所が分散することを防ぐためだ。
  • 用途の割り当て、複数候補の選択、初期設定、保存権限、容量は別々の条件である。フィルターの本文が同じでも、メールの保存先が同じとは限らない。

移行で守るべきものは、フォルダー名だけではない

メールシステムの移行では、メッセージとフォルダーの一覧、フィルターの設定を移せば、以前と同じ使い方が続くと考えがちだ。しかし、フィルターが参照しているのがフォルダー名ではなく用途であれば、複製すべき条件はそれだけではない。

「アーカイブとして使う場所」は、利用者が付けた名前と一致するとは限らない。別のクライアントで設定し直したり、言語を変えたり、保存場所を整理したりすれば、同じ用途を別のメールボックスが担うこともある。

この問題に対応したのが、RFC 6154のIMAP特別用途属性である。\Archive、\Drafts、\Junkなどの属性により、クライアントは名前を推測するだけでなく、メールボックスの役割を知ることができる。

Sieveでその役割を使って配送するRFC 8579は、便利な間接指定に、重要な制限を付けた。用途で保存先を探すことと、その保存先が故障したとき別の場所へ逃がすことは、同じ許可ではない。

見つからないときに使う名前

Sieveの配送処理に:specialuseを指定すると、まず利用者の個人用名前空間から、要求した属性を持つメールボックスを探す。見つかれば、通常の引数として名前を記したメールボックスではなく、用途に対応するメールボックスを使う。

該当するメールボックスがない場合、または実装がその属性を知らない場合には、特別用途の指定がないときと同じ処理に戻る。そのとき、名前で指定された既定先が通常の配送規則に従って扱われる。

つまり、二つの参照は、どちらでも書き込めればよいという並列の候補ではない。一方が優先され、もう一方は特定の条件で使われる。既定先という名前が設定に残っていること自体は、あらゆる失敗からそこへ切り替えてよいという意味にはならない。

ここで、用途が未設定の状態と、用途の担当先が満杯の状態を分ける必要がある。前者では、用途から保存先を決められない。後者では、保存先は決まっているが、その場所への保存が完了しない。

同じ「使えない」という説明でまとめると、別々の状態に与えられた処理を取り違える。

満杯でも、存在している

説明のために一つの場面を考える。用途で選ばれたアーカイブ用メールボックスは容量上限に達している。名前指定の既定フォルダーにはまだ余裕がある。運用担当者は、後者に保存してエラーを減らしたくなる。

これは実際の障害報告ではなく、規則を理解するための仮定である。RFC 8579は、選択された特別用途メールボックスへの配送が、その存在に関係しない理由で失敗した場合、続けて既定メールボックスへ配送を試みることを禁止している。

容量が足りないメールボックスは、消えたメールボックスではない。したがって、容量不足を、用途に合う場所がなかったことに読み替えることはできない。

理由も規格に書かれている。一時的・断続的なエラーによって、メッセージが予想外に二つのメールボックスへ分散するのを避けるためである。正常な時間帯のメールはアーカイブへ、障害中のメールは別の場所へ、復旧後のメールは再びアーカイブへ。こうした振り分けは、利用者が選んだ整理方法ではなく、障害の時間帯を保存規則にしてしまう。

全体検索で見つけられる場合でも、問題はなくならない。指定先だけを監視する処理や、その場所をアーカイブとして表示するクライアントには、別のフォルダーへの書き込みが見えないことがある。個々の書き込み成功と、保存場所の一貫性は異なる性質だ。

エラーを残すことは、対応を放棄することではない

利用者が、遅延するより別の場所で受け取りたいと考えることはあり得る。サービス側も、障害時の明示的な代替運用を用意する必要があるかもしれない。

その判断まで否定する必要はない。ただし、保存先を変える権限、利用者への説明、ほかのクライアントとの整合、あとで分散したメールを確認する責任を別途定めなければならない。:specialuseの既定先だけで、その合意が済んだことにはならない。

禁止されている再試行を行わなかった後は、通常の配送アクションの失敗時処理に従う。RFC 8579のこの規則だけから、一律に待ち行列へ入る、差出人へ返る、あるいは破棄されると結論づけることはできない。

規格が守るのは、障害を理由に保存先の意味が無断で変わらないことだ。容量を回復させ、処理結果を確認し、利用者に説明する仕事は依然として残る。エラーを見える状態に保つことと、エラーを解決することは対立しない。

事前確認が保証しないもの

specialuse_existsは、属性とメールボックスの条件を調べるテストである。具体的なメールボックス名を省略した場合、列挙したそれぞれの属性について、個人用名前空間に配送可能な対応先が少なくとも一つ必要になる。別々の属性を、別々のメールボックスが満たしてもよい。

名前を指定した場合は、その一つのメールボックスが存在し、配送を許し、要求したすべての属性を持つことが条件となる。複数の属性を渡しただけで、一つの万能な保存先が見つかったと考えるのは誤りだ。

配送可能性の定義は、RFC 5490のメールボックス確認に基づく。同文書は、存在確認に成功しても、その後の保存が成功するとは限らないと明記する。実際の配送で容量制限を超える場合があるためだ。

この確認は、利用者の権限とメールボックスの存在を調べるものであり、次のメッセージの保存領域を予約するものではない。権限確認が正しくても、その後の書き込みが失敗することはある。

したがって、運用記録にはテスト結果だけでなく、実行した利用者の文脈、用途の割り当て、選ばれたメールボックス、実際の保存結果を残す必要がある。一つの成功表示に集約すると、原因を説明するための区別が消える。

同じ用途が二つ見つかったら

特殊用途は必ずしも一意ではない。個人用名前空間内で、同じ属性が複数のメールボックスに付いている場合もある。

その中に、名前で指定した既定メールボックスが含まれていれば、RFC 8579はそれを選ぶよう求める。含まれていなければ、選択方法は実装に委ねられる。関連する割り当てが変わらない間は、同じ場所を選び続けることが推奨されている。しかし、割り当てが変われば、選択先も変わり得る。

これは、異なるサーバー間で共通の並べ替え規則が保証されているという意味ではない。移行先で属性を正しく再現できても、複数候補から得られる答えまで同じとは限らない。

利用者が用途を変更すれば、フィルターを書き換えずに今後の保存先を変えられる。その利点は、障害調査での注意点でもある。スクリプトの変更履歴だけでは、以前の保存先を再構成できないことがある。

さらに、Archiveという用途の具体的な意味はRFC 6154でもサーバー依存である。属性だけで保存期間、不変性、特定の法的な記録保存義務が証明されるわけではない。役割を見つける仕組みに、それ以上の約束を背負わせてはならない。

初期設定を「相手の仕事」にしない

用途を発見するには、用途が設定されていなければならない。RFC 6154の属性は任意であり、作成時に用途を与えるCREATE-SPECIAL-USEも別の任意機能である。メタデータを通じた割り当て変更も、サーバーの対応と妥当性確認を前提とする。

RFC 6154の正誤情報にある4422番の記録は、2015年7月19日の非公式な相互運用試験で、サーバーがクライアントによる初期設定を期待し、クライアントがサーバーによる初期設定を期待していたと報告している。

この記録の状態はHeld for Document Updateであり、提案された改善が新たな必須規則になったわけではない。現在の製品の普及状況や不具合率を示す資料でもない。それでも、両側が機能を理解していても、初期状態を用意する担当が決まっていなければ連携が成立しないという、具体的な責任の空白を示している。

用途の対応先も既定先もない場合、通常の未作成メールボックスに対する処理が適用される。明示的な:createは、必要なら名前指定の既定先を作成するよう求める。CREATE-SPECIAL-USEに対応するサーバーでは、新しいメールボックスへ要求した用途を付けることが推奨されるが、すべての実装に一律の結果を保証する規則ではない。

名前指定での保存が成功し続けても、用途による選択が一度も使われていない可能性がある。成功件数だけでは、この差を見つけられない。

検索を広げると、影響を与えられる人も変わる

個人用名前空間の外まで属性を探せば、候補が増えるかもしれない。しかし、共有メールボックスまで検索対象にすれば、別の利用者が付けた属性によって、予期しない保存先が選ばれる危険も増える。

RFC 8579は、検索負荷と、共有メールボックスへの意図しない、あるいは悪意ある振り分けを理由に、属性による探索範囲を限定する。この制約は便利さを減らすだけでなく、誰の操作が配送先に影響し得るかを狭めている。

これは、個人用メールボックスが絶対に共有されないという保証ではない。また、明示的な名前で指定された既定先のすべてを同じ探索規則に制限するものでもない。RFC 6154は別途、用途の付与が自動処理を引き起こし、共有先への保存で私的なメールが露出する可能性を指摘している。

役割の付与権限と役割を探す範囲は、保存先の安全性を考えるうえで切り離せない。

ここで証明したのは製品の動作ではない

本稿は公開規格に基づく分析であり、実際のアカウントや事業者のシステムを検査した報告ではない。RFC 8579の検証済み技術正誤5877は、後半の例で変数を取り出すための照合演算子を訂正するもので、保存先選択と配送失敗の規則を変更しない。例示されたコマンドやスクリプトを実行したわけでもない。

Lu Hengの代理問題に関する論考から引き出せる問いは、決定者と損失の負担者が一致しているか、というものだ。書き込み側が成功を増やすために場所を変えれば、その代償を、あとでメールを探す側が負担することになる。

BTWの役割についての論考が求めるのは、誰かを悪者にすることではなく、構造を明らかにすることだ。ここでは、空きがあるという事実と、そこを使う権限があるという事実を分けるだけで、復旧の責任がかなり明確になる。