要約

  • UIDPLUSは、APPENDやCOPYの成功時に保存先メールボックスのUIDVALIDITYと新しいUIDを返し、切断利用するクライアントが操作結果を推測せず照合できるようにした。
  • 返される対応表には境界がある。権限やUIDNOTSTICKYによって省略され得るほか、COPYUIDは世界共通の同一性ではなく、UID EXPUNGEも指定UIDと\Deletedが交わる範囲だけを削除する。

MOVEが露出させた応答順序

メールを移動する処理は、保存先で新しいメッセージを作り、元のメッセージを消す。保存先では別のUIDが割り当てられるため、クライアントは旧UIDと新UIDの対応を必要とする。UIDPLUSを備えたサーバーはUID MOVEにCOPYUIDを返せる。

しかし、対応表が最終のタグ付き成功応答にだけ入っていて、その前にEXPUNGEが流れると扱いにくい。EXPUNGEは元メールボックスのシーケンス番号を変えるからだ。RFC 6851は、削除通知より前に、タグなしOKでCOPYUIDを送るよう勧めた。RFC 9051のIMAP4rev2では、この順序が統合された動作として強められた。

ここで守られているのは単なる速さではない。新旧の対応、元の消滅、命令の完了という三つの事実を、同じ状態像の上で読めるようにすることだ。事実は順番を誤ると、個別には正しくても照合コストを生む。

COPYUIDは二つの集合を同じ長さにした

COPYでは、元のUIDが保存先へ持ち越されるわけではない。サーバーは保存先の名前空間で新しいUIDを割り当てる。COPYUIDは保存先UIDVALIDITY、元UID集合、保存先UID集合を返す。

二つの集合は同数でなければならず、位置が対応を決める。元集合の一番目は保存先集合の一番目に、二番目は二番目に対応する。*や今回の命令に関係しないUIDは入れられない。クライアントは、自分が依頼した集合と応答の形を直接検査できる。

表示上のシーケンス番号では同じ保証を作れない。他のセッションがメールを削除すれば、COPY処理中でも番号がずれる。UIDで命令対象を固定し、UIDで結果を返すことで、見た目の並び替えから対応関係を切り離した。

ただし、この対応を知るのは応答を受け取ったクライアントである。RFC 8474が説明するように、別のクライアントは通常のUIDだけを見ても、二つのメールボックスにあるメッセージが同じ移動・コピーから生じたとは推定できない。ObjectIDはその広い用途を扱う。COPYUIDは一回の命令結果を証明する仕組みにとどまる。

APPENDの成功に新しい参照を添える

APPENDでは、クライアントがメッセージを送っても、UIDを決めるのはサーバーである。通常の成功応答だけなら、クライアントは作成が終わったことを知っても、後でどのUIDを使うべきか分からない。

APPENDUIDはタグ付きOKに保存先UIDVALIDITYと割り当てUIDを載せる。切断中に蓄えた送信待ち項目を、遠隔側の一つの参照へ直結できる。再選択して件名や本文を比べる必要がなくなり、再送による重複も避けやすくなる。

複数メッセージを一度に追加する場合、応答は順序を保ったUID集合になり得る。入力の一番目と出力の一番目が対応する。集合に余計なUIDを含めず、開いた範囲を示す*も認めないという制約が、受領結果を監査可能にする。

UIDだけを保存してはいけない。UIDはサーバー、メールボックス名、UIDVALIDITYの内側で意味を持つ。UIDVALIDITYが変われば、古いUIDとの対応は失効する。新しい番号と、その番号が属する世代は一体の証拠である。

削除にも集合の境界を置いた

通常のEXPUNGEは、選択中のメールボックスで\Deletedが付いたすべてのメッセージを恒久的に除去する。共有メールボックスでは、別の端末が別の目的で付けた印まで実行してしまう可能性がある。

UID EXPUNGEは、指定UID集合に含まれ、かつ\Deletedが付いているメッセージだけを消す。UIDだけでは消えず、フラグだけでも消えない。再接続したクライアントは、自分が完了させたい削除を安定した識別子で囲える。

UIDPLUSのないサーバーでは、残したいメッセージから一時的に\Deletedを外し、EXPUNGE後に戻す手順が代替になる。結果を近づけられても、共有状態を広く書き換える。UID EXPUNGEは、不可逆な操作の権限を一つの集合へ狭めた。

返さないことが情報保護になる

利用者には、あるメールボックスへAPPENDやCOPYする権限があっても、SELECTやEXAMINEする権限がない場合がある。そのときUIDVALIDITYと新UIDを返すと、本来見えない保存領域の情報を漏らす。RFC 4315は、この条件ではAPPENDUIDやCOPYUIDを送らないよう求める。

保存先がUIDNOTSTICKYなら、省略も許される。これはUIDがセッションを越えて持続する保証がないことを示す。仕様はそのような新規ストアを推奨しないが、持続しない名前を永続的な受領証のように見せることもしない。

応答コードがないことは、命令失敗と同義ではない。必要な閲覧権限があれば、クライアントは保存先を選び、自分が埋め込んだ一意な印をSEARCHやFETCHで探せる。成功、閲覧許可、識別子の持続性は別々の判断である。

「最適化」が中核仕様へ入るまで

RFC 2359は1998年、切断利用の負担を減らす最適化としてUIDPLUSを定義した。RFC 4315は2005年にこれを置き換え、応答省略とUIDNOTSTICKY、複数追加時の集合を明確にした。IANAの能力レジストリは現在もUIDPLUSをRFC 4315に結び付けている。

その後IMAP4rev2はAPPENDUID、COPYUID、UID EXPUNGE、MOVEとの順序を本体に取り込んだ。採用率が普遍的だという意味ではない。成功した変更には、その結果を追跡できる限定的な証拠が必要だという設計が、プロトコルの中核へ移ったということだ。

有効範囲を持つ受領証

UIDPLUSは、UIDを認証情報にも世界共通IDにも変えなかった。サーバーが一回の命令で割り当てた保存先参照を、そのメールボックス世代の内側で返した。削除では、すでに付いた印のすべてではなく、依頼者がUIDで囲んだ部分だけを不可逆にした。

検証可能性は、主張を大きくすることではない。どの変更が起き、どの名前が生まれ、どの権限と世代までその名前が通用するかを分けて記録することである。

出典と限界

最初の仕様はRFC 2359、これを置き換えた現行拡張はRFC 4315である。RFC 3501がIMAP4rev1の背景を、RFC 6851がMOVEを、RFC 8474が他クライアントから見た限界を、RFC 9051がIMAP4rev2への統合を示す。IANAレジストリにもUIDPLUSが記録されている。これらは現在の普及率や暗号学的保証を示さない。