要約

  • 2011年3月のRFC 6154は、IMAPのLIST応答に任意の特別用途属性を加えた。\Sent、\Drafts、\Trashなどの役割を、表示名を推測せずに発見できる。
  • \Sentはサーバーが送信済みの控えを自動保存する場所かもしれず、アプリに「ここへ保存して」と告げるだけかもしれない。一つのフォルダーに複数の属性が付き、同じ属性が複数のフォルダーに付くこともある。
  • 拡張LISTではSPECIAL-USEを通知できる。任意のCREATEとMETADATAの仕組みでは役割の指定や変更を求められるが、サーバーは実現できない要求を拒否する。IANAの属性登録簿は共通の名前を記録する。

フォルダー名を設定規則にしていた

同じメールアカウントを二つのアプリで開く。一方は「Sent Mail」に送信控えを保存し、もう一方はその名を認識できず、別の「送信済み」を作る。利用者が送ったメールの履歴は二つに割れる。さらに、両方のアプリがサーバーによる自動保存を期待し、サーバーがアプリの保存を期待していれば、控えはどこにも残らない。小さな設定ミスが通信の記録を変えてしまう。

1999年のIMAP実装指針には「Sent Mail」や「Trash」といった慣用名が登場する。人間には便利な目印でも、プログラムには頼りない。名前は現地の言語で表示され、利用者が変更できる。同じ表示名でもサーバーが何を自動で行うかは分からない。画面の文字列に保存の仕事を決めさせていたわけだ。

RFC 6154は用途をLIST応答へ移した。当初の属性は\All、\Archive、\Drafts、\Flagged、\Junk、\Sent、\Trashの七つ。サーバーはフォルダーの既存属性とともに返せる。表示名がSentMailでも、利用者の付けた名前でも、アプリは\Sentを探せる。

これで配置を説明する役が変わる。初めて接続したアプリはサーバー内の区分を知らない。サーバーは自分がどのフォルダーにどんな用途を与えたかを知っている。利用者に毎回翻訳と設定を頼む前に、その情報を機械可読な形で渡せる。フォルダーの見た目を統一する必要はない。

役割の表示は、配達完了の印ではない

RFC 6154の\Sentには異なる使い方がある。サーバーが送信メッセージの写しを自動で入れる場合がある。別の場合は、クライアントにそこへ入れるよう勧めるだけだ。後者のサーバーを前者だと思えば空になる。前者のサーバーへアプリも写しを保存すれば、重複する可能性がある。属性は置き場を発見させるが、誰が入れたかは一通の動きを追わなければ分からない。

\Allは全メッセージの仮想的な表示になり得るが、\Trashや\Junkを除く場合もある。\Archiveの運用上の意味はサーバーに依存する。\Draftsは下書きフラグの付いたメッセージの仮想集合か、アプリが書きかけを保存する宛先だ。\Trashも、サーバーの削除方式によって位置付けが変わる。同じ役割語彙は異なる実装を読めるようにし、異なる実装そのものを消すわけではない。

フォルダーは属性なし、一つ、複数のどれでもよい。二つのフォルダーが同じ\Sentを持つこともある。役割は利用者ごとに違う場合が多い。二人が同じフォルダーを共有していても、二人ともそれを自分の送信控えの置き場とみなすとは限らない。標準化された文字列を見て「必ず一つだけ」と決めるなら、名前当てを別の形で続けることになる。

IANAのIMAPフォルダー属性登録簿は属性名と定義元をそろえる。一通のメールをどのアプリがどのフォルダーに入れたかは記録しない。登録簿は用語を調整し、稼働中のメール保管庫が実際の配置を示す。

発見できても、指定は拒まれ得る

この拡張は拡張LISTの枠組みを使った。対応サーバーはCAPABILITYでSPECIAL-USEを知らせる。クライアントは特別用途のあるフォルダーだけを要求でき、応答に属性を含めるよう求めることもできる。前者は後者を含む。通常のLIST応答にも属性が載り得るが、その形には専用の能力文字列がない。通信記録はCAPABILITY一行だけで判断しない方がよい。

RFC 6154は任意のCREATE USE引数も定義した。クライアントが新しいフォルダーへ役割を指定したいとき、サーバーは別の能力CREATE-SPECIAL-USEで対応を知らせる。既存の役割と衝突すれば拒否でき、移動や複数割当てを許す実装もある。要求された役割とともに作れない場合は、フォルダーを作らずにCREATE全体を拒否しなければならない。応答が失敗なら、クライアントの希望は設定済みの事実にならない。

IMAP METADATAに対応するサーバーでは、/private/specialuseが既存フォルダーの役割を表し、変更手段にもなり得る。サーバーは変更を検証し、受け入れられない役割を機械的に保存してはならない。表示名の変更、役割の指定、実際のメール移動は、それぞれ別の操作だ。

役割によって自動処理が動くと、権限の問題も具体化する。RFC 6154は、サーバーが迷惑メールを\Junkへ自動移動する環境で、その役割を共有フォルダーに与える例を挙げる。誤判定された正当なメールが他人に見える恐れがある。小さな属性が行動を変えるなら、サーバーは誰の要求を受けるか決める必要がある。

RFCと登録簿が示すのは役割の通知、要求、拒否の規則だ。特定のアカウントの送信控えが実際にどこへ入ったかには、日付のあるCAPABILITY/LIST、CREATEやMETADATAのやり取り、そして一通の控えの移動記録が要る。フォルダー名だけが一番弱い証拠である。