要約

  • RFC 2342のNAMESPACE応答は、三種類のメールボックス名を構成するprefixと階層delimiterをクライアントに知らせた。
  • 名前の規則、LISTでの可視性、実在、SELECT権限、メッセージ取得、画面表示、人間の閲読は、それぞれ別の証拠を要する。

最初に届いたのは在庫表ではなく文法だった

あるクライアントが ("" "/")、("~" "/")、NIL というNAMESPACE応答を受け取る。個人メールボックスにはprefixがなく、他ユーザーはチルダから始まり、共有クラスはこの応答では利用できない。構文は明快で、クライアントは ~mark/INBOX のような名前を組み立てられる。

それでもMarkという利用者が存在するとは限らない。そのINBOXがLISTに現れるとも、SELECTできるとも、メッセージがあるとも、誰かが読んだとも言っていない。

RFC 2342 が解決したのは、ユーザーに「共有フォルダーのprefix」を手入力させる相互運用問題だった。NAMESPACEはPersonal、Other Users'、Sharedの順に名前空間を返し、各要素にはprefixとdelimiterを置く。複数の名前空間や異なるdelimiterも許し、利用できないクラスにはNILを返す。

これは名前を解釈する規則である。サーバーは、実際に支える名前空間の一部だけを公開してもよく、ユーザーごとに応答を変えてもよい。したがってNILも完全な不在証明ではなく、この接続に対する公開範囲の記録にすぎない。

他ユーザーの枝は意図的に見えにくくできた

RFC 2342はOther Users' prefixに % を付け、LISTで利用可能な他ユーザーを探す方法を示す。同時に、list accessを与えていないユーザー名を返さないよう求める。サーバーは許可済みの名前だけを返してもよく、広いLISTをNOで拒否し、具体的なユーザー名を要求してもよい。

文書の例では #Users/% が失敗しても、利用者がMikeを指定した #Users/Mike/% はINBOXとFooを返す。名前空間の有無は変わっていない。列挙方針と認可条件が違うだけだ。

この非対称性は欠陥ではない。アカウント名の一覧そのものが機密情報や攻撃の足場になり得るためである。名前の領域を告知することは、その住人を列挙する権利を与えない。

LISTの名前にも寿命と属性がある

RFC 9051 では、LISTはクライアントが利用できる全メールボックス名の「部分集合」を返し、応答がゼロ件でもよい。名前には \Noselect や \NonExistent が付き得る。購読済みの名前が、実在しないメールボックスを指している場合もある。

従って、名前空間が宣言された、名前がLISTに出た、購読されている、現在SELECTできる、という状態は一致しない。削除やrename、ACL変更、キャッシュの古さが重なると、同じ文字列でも意味は移動する。

可視性と読取権限は別の権利だった

RFC 4314 は権利を細分化する。l はLIST/LSUBでの可視性、r はSELECT/STATUS、s はSeen/Unseen状態の保持に関わる。名前が見えるだけでは内容を読めない。

RFC 9051も、l はあるが r がないメールボックスでは、LISTの結果があってもSTATUSや選択が成立しない例を扱う。RFC 8440のLIST-MYRIGHTSは権利情報を同じ応答に近づけたが、「許されている操作」と「実際に成功した操作」を同一にはしない。

SELECT成功はさらに強い証拠である。接続はselected stateに入り、FLAGS、EXISTS、UIDNEXT、UIDVALIDITYなどを受け取る。それでもFETCH完了、クライアントのデコード、画面の可視性、人間の注意は別段階だ。

\Seen も人間の閲読証明ではない。FETCHやSTORE、バックグラウンド同期によって変わり、ACLの s によって保持可能性が決まる。プロトコル状態は目や理解を観測しない。

精密な地図ほど境界を守る必要がある

RFC 2342はローカル慣習を消さず、その解釈方法だけを共通化した。これは最小限の共通層として優れた設計だった。prefixは次のコマンドを正しく作るための入力であり、その結果を先取りする認可証ではない。

運用上の教訓は単純である。スキーマは識別方法を示せるが、対象の実在を作らない。CAPABILITYは命令を理解すると示せるが、要求成功を保証しない。制御応答は調査を前へ進めるが、最終結果を閉じない。

RFC 2342が開いたのは、正しい名前で扉を探す道だった。扉そのものを作ったわけではない。