要約

  • IMAPは \Seen を「メッセージが読まれた」状態と定義する。しかしサーバーが扱うのは可変のメールボックス状態であり、BODY[...] は暗黙に設定し、BODY.PEEK[...] は設定せずに内容を取得でき、権限を持つクライアントは追加も削除もできる。
  • 人間の読了を主張するなら、認証主体、クライアント、メールボックスの世代、UID、命令、変更前後のフラグ、応答、画面表示を結ぶ必要がある。単独のビットは注意、理解、同意、返信を証明しない。

人間らしい言葉が機械状態に付いた

Mark Crispinは、メールをサーバーに置いたまま複数の場所とクライアントから扱えるようIMAPを考案した。Stanfordの追悼記録によれば、1977年から1988年までシステムプログラマーとして働いた期間にIMAPを発明した。IETFプロフィールには25本のRFCが並び、その中にIMAP4rev1の長期的な基準となったRFC 3501がある。Unicode Consortiumも、長年の貢献者をメールの専門家、IMAPの父として記憶している。

RFC 3501は \Seen を端的に「メッセージが読まれた」と説明し、現行のIMAP4rev2であるRFC 9051も引き継ぐ。複数クライアントが同じ状態を共有するには有用な語だ。しかし仕様は、人間の「user」とソフトウェアの「client」を分けている。

サーバーが観測するのは命令、返したデータ、属性の更新であって、視線や注意、理解ではない。確実に言えるのは、その時点で標準の既読フラグが保存されていることまでだ。人について述べるには、そのビットが生じた原因をたどらなければならない。

FETCHは状態を書き、PEEKは暗黙には書かない

境界はFETCHの規則に現れる。クライアントが BODY[...] で本文部分を要求すると、RFC 3501とRFC 9051は \Seen を暗黙に設定する。状態が変われば、サーバーは新しいflagsを応答に含める。取得命令がメタデータ書き込みも起こす設計である。

BODY.PEEK[...] は、同じ内容を取得しても \Seen を暗黙には設定しない別形式だ。本文取得とフラグ変更が共に起きる場合、取得だけが起きる場合、本文を取らずSTOREで設定する場合、取得後にフラグを消す場合が、すべて成立する。

これは矛盾ではない。プレビュー、あとで読む操作、オフライン同期を可能にする。一方で、フラグが人間センサーではないことも示す。索引、フィルター、キャッシュ、プレビュー生成が本文を取得する場面はあり得るが、特定製品への事実認定ではない。逆に、PEEKで得た内容を画面に出しながら未読のままにすることもプロトコル上は可能だ。サーバーの証拠範囲は命令と効果までである。

保存時から既読にできる

APPENDは初期フラグを受け取れる。両仕様には \Seen 付きでメッセージを追加する例がある。この場合、ビットは格納時に選ばれた状態であり、その新しいコピーを人が格納後に読んだ証拠ではない。

STOREはフラグを追加・削除できる。「すべて既読」は本文を表示せずに実行でき、「未読に戻す」は熟読後にも行える。共有メールボックスや複数クライアントでは、後から見る状態を別の権限主体が作った可能性もある。

したがって「未読」は「誰も読んでいない」の論理的反対ではない。現在 \Seen がない、という意味に限られる。取得、手動解除、同期競合、APPEND時の初期状態という履歴は、現在値から失われ得る。

権限が証跡の有無を変える

RFC 4314は \Seen の変更に専用の s 権限を割り当てる。本来フラグを設定するFETCHでも、現在の利用者に s がなければ設定してはならない。STOREによる変更にも同じ権限が要る。

二つの主体が同じ本文を取得しても、永続的な痕跡は異なり得る。一方はフラグを書き、他方はアクセス制御により書けない。\Seen がない理由は、表示されなかったことではなく権限境界かもしれない。

共有フラグか非共有フラグかも実装モデルにより得る。問うべきは「既読か」だけではない。「誰の状態か、どのメールボックスモデルか、どの権限で書かれたか」である。個人箱、共同サポート箱、委任された役員箱は、同じ名前のビットでも同じ証拠ではない。

変更順序は人間の原因を語らない

RFC 7162のCONDSTOREとQRESYNCは、メタデータ変更にmod-sequenceを与える。クライアントは新しい状態を検出し、キャッシュを直し、UNCHANGEDSINCE を条件にSTOREできる。古い書き込みが新しい変更を黙って消す代わりに、競合として失敗できる。

だがMODSEQは順序の受領証であり、証言ではない。暗黙FETCH、明示STORE、別クライアント、外部エージェントのどれかを単独では示さず、画面や注意も記録しない。

RFC 8621はJMAPで $seen を特別なキーワードとして扱い、権限ある利用者が追加・削除できる。同期が完全でも、それが保証するのは同じ状態が複製されたことだ。人間についての観測範囲は広がらない。

「読んだ」を複数の受領証から組み立てる

防御可能な記録は、認証主体、委任、クライアント個体、セッションから始まる。次に UIDVALIDITY とUIDでメールボックスの世代とメッセージを固定する。原因としてBODY FETCH、PEEK、STORE、APPEND、同期、外部エージェントを区別し、対象部分、変更前後のflags、応答、時刻、可能ならMODSEQを残す。

画面表示は別イベントであり、人の確認はさらに別だ。「本文を取得、Seenを暗黙設定、表示は不明、確認なし」と書ければ、便利な一語よりも判断に耐える。

Crispinが相互運用可能にしたのはメールボックス状態である。後世の設計者には、その状態に観測していない人間の証言まで背負わせない責任がある。

情報源