要約

  • UIDONLY を明示的に有効化すると、RFC 9586 はメッセージ連番を禁止し、UIDFETCH と VANISHED を UID で返す。消えるのは不安定な対応表であり、同期を立証する責任ではない。
  • 持続的な参照はメールボックス名、UIDVALIDITY、UID の組で決まる。能力の広告、有効化、コマンド完了、キャッシュへの書き込み、アプリケーションでの照合は別の受領証である。

大量のメールが並ぶ途中から一通が削除されると、それより後ろの連番は一斉にずれる。クライアントは、動く位置と比較的安定した UID の対応を、通知が飛び交う最中にも維持しなければならない。UIDONLY が取り除くのは、この二重管理である。

ただし CAPABILITY に UIDONLY が載っただけではセッションは変わらない。クライアントが ENABLE UIDONLY を送り、初めて通常の FETCH、STORE、SEARCH、COPY、MOVE が使えなくなる。禁じられた形式には UIDREQUIRED が返り、属性変更は UIDFETCH、削除は VANISHED で示される。広告と実効状態は同じ事実ではない。

改善の意味は大きい。連番は現在位置にすぎず、EXPUNGE のたびに後続へ再割り当てされる。位置を応答から外せば、遅れて届いた応答を別のメールに結び付ける危険を減らせる。クライアントが二つの名前空間を常時変換する負荷も下がる。

それでも UID は世界で一意の名前ではない。RFC 9051 では、その効力はメールボックスと UIDVALIDITY が示す世代に限定される。サーバーが以前の名前空間を維持できなければ UIDVALIDITY が変わり、古い UID は現行の識別根拠を失う。UID だけを監査ログへ残しても参照は完結しない。

UIDNEXT も次の実体を予約する値ではない。後から割り当てられる UID の下限を示すだけで、同じ値のメッセージが現れる保証はない。欠番も削除も正当であり、同じ UID のフラグは変化する。識別が安定することと状態が落ち着くことは別である。

UIDONLY は EXISTS と RECENT を変えない。CONDSTORE や QRESYNC と併用でき、MODSEQ は UIDFETCH に含められるが、これらの同期機能を必須にはしない。QRESYNC の連番照合パラメーターは禁止される。捨てた名前空間を再び持ち込まないためだ。正しい宛先指定から完全な履歴は導けない。

COPY と MOVE にも同じ境界がある。COPYUID は元 UID と、移動先の UIDVALIDITY および UID を対応させる。タグ付き結果は IMAP コマンドの終了を示す。それでも検索索引、保管系、モバイルキャッシュが新しい実体を確定したとは限らず、下流には下流の証明が要る。

草案で検討されたゼロの代案は警告になる。通常の FETCH の形を残し、連番欄にゼロを入れる設計は、古いクライアントが偽の位置を信じてキャッシュを壊しかねないため退けられた。形だけの互換性は意味の断絶を隠す。新しい応答形式で境界を明示する方が安全だった。

運用証拠は、能力広告、この接続での有効化、メールボックスと UIDVALIDITY、観測した UID と変更、タグ付き完了、ローカルへの永続反映、利用側での照合までをつなぐ必要がある。一つの緑色表示に全工程を代表させてはならない。

出典