要約

  • RFC 3503 は一つの IMAP メールボックスを使う複数の MUA が同じ Message Disposition Notification を繰り返さないよう、共有キーワード $MDNSent を定めた。
  • そのフラグは送信履歴ではなく将来の抑止命令だった。利用者が通知を拒否した場合、送信済みコピーや未完成メッセージを保存した場合、実際には MDN が送られなかった自動処理でも設定され得た。

一台のパソコンだけでメールを扱うなら、通知を送ったかどうかはローカル設定に覚えさせられる。ところが、会社の端末と自宅の端末が同じ IMAP メールボックスを開くと、その記憶は共有されない。先に処理した MUA は事情を知っていても、後から接続した MUA には同じメッセージと同じ要求しか見えない。結果として、同じ通知を二度生成する余地が生まれる。

2003 年 3 月の RFC 3503 は、この問題を新しい配送プロトコルではなく共有状態の問題として扱った。新しい IMAP コマンドも応答も追加していない。代わりに特別なメールボックスキーワード $MDNSent を定義し、複数の MUA がそれをどう扱うかを決めた。

名称だけを見れば「MDN は送信済み」と読める。しかし規範的な書き込み条件はもっと広い。自動処理では、MDN が実際に送られたかどうかにかかわらず、対象メッセージにフラグを設定する。利用者が送信を明確に拒否した時も、別の MUA が後で送らないよう設定できる。送信済みメッセージをフォルダーへ保存する時も、書きかけのメッセージを保存する時も設定が必要だった。

つまり、同じビットには異なる経歴が折り畳まれている。そこから確実に読めるのは「この保存メッセージについて、今後 MDN を生成してはならない」ということだけだ。通知の生成、投稿、配送、到着、さらに元のメッセージを人が読んだかどうかは含まれない。

共有状態を使う前に、永続化できるかを確かめる必要がある。クライアントはメールボックスを開いた時に PERMANENTFLAGS を調べ、サーバーが $MDNSent そのもの、または任意のキーワードを保存できることを確認する。能力の広告と個別の成功は同じではない。任意キーワード対応を示したサーバーでも、メールボックスの上限などにより STORE を NO で拒否し得る。

その時、RFC 3503 は MDN を送らないことを勧めた。共有記憶を書けないまま送れば、別のクライアントには処理済みだと分からず、重複が起こり得るからだ。これは完全な一回実行保証ではない。協調の根拠を残せない場合に、あえて外向きの動作を止める安全側の選択である。

既存フラグの流用も制限された。\Recent は複数接続が同じメールボックスを選択している時、どの接続で見えるかが未定義なので、送信判断の根拠にしてはならない。\Seen は送らない理由の一つにはなり得るが、既に別の意味を持つ。\Draft はメッセージが未完成であることを示し、別の理由で MDN を止める。$MDNSent がある場合、MDN 生成については他のフラグより優先された。

一度設定された $MDNSent はクライアントが解除してはならない。この単調な遷移は、古い要求を再び有効にする競合を減らす。一方で、監査記録の機能は持たない。誰が、いつ、どの同意に基づき、どんな結果で設定したかはビットから復元できない。未来の制御に強いことと、過去の説明に強いことは別である。

コピー時の継承も重要だった。通常の COPY で $MDNSent が保たれるかをクライアントは確認すべきであり、サーバー間を APPEND で移す場合は正しくキーワードを付けなければならない。内容だけが移り、停止状態が落ちれば、コピー先の MUA は未処理メッセージとして扱ってしまう。

ACL との関係は権限の境界を示す。サーバーは、クライアントがメッセージをコピーする権利を持つかを引き続き検査する。しかしコピーが認められたなら、一般的なフラグ書き込み権限がなくても $MDNSent を保持することが推奨された。コピー権限と任意の状態編集権限を混同せず、協調属性だけはオブジェクトとともに保存する設計である。

大文字と小文字も状態を分けない。例では $MdnSENt、$MdnSENT、$mdnsent が同一として扱われる。表記差によって二つのクライアントが別のビットを見れば、共有層は共有でなくなる。

MDN の本文が示すものも限定される。RFC 2298 の初期形式は RFC 3798 に改訂され、さらに RFC 8098 が Internet Standard の STD 85 となった。displayed は MUA がメールボックスを見ている誰かにメッセージを表示したことを表すが、内容を読んだことも理解したことも保証しない。processed は人のいない規則処理でも成立する。deleted は、事前に読まれなかったことや将来復元できないことを意味しない。

プライバシーの規律もある。既定は MDN を送らない側であるべきで、アドレスの不一致などでは同意が必要になる。通知は偽造、喪失、メール爆撃への悪用、クライアント情報の露出を起こし得る。RFC 8098 は MDN が配送の否認防止を提供せず、メッセージが見られたか否かの保証にもならないと明記する。

RFC 5788 が後にキーワードを登録した時、目的はより正確に表現された。$MDNSent が付いたメッセージについて MDN を送ってはならない、という共有キーワードである。これは過去形の証明ではなく、次の主体に対する禁止である。

JMAP の RFC 9007 は動作と状態の結合を強めた。MDN/send を呼ぶクライアントは成功時に $mdnsent を更新するよう指定し、サーバーはその更新につながらない呼び出しを拒否する。既にフラグがあれば mdnAlreadySent を返せる。JMAP 内の隙間は小さくなるが、人の読了や配送結果を証明するわけではなく、2003 年の実装へさかのぼって要件を追加するものでもない。

証拠は階段として読む必要がある。PERMANENTFLAGS は保存能力の広告、STORE OK は状態変更の受理、$MDNSent は将来の抑止を示す。通知の構築、メール投稿、輸送、到着はそれぞれ別の記録を要する。Disposition は限定された主張であり、人の注意、理解、行動はさらに先にある。

RFC 3503 の設計が興味深いのは、共有しなければならない最小の事実だけを共有した点にある。複数クライアントが同じ動作を繰り返さないことは必要だった。しかし、メールボックスのビットが人の認識や法的承認まで決める必要はなかった。

便利な名前を現実そのものへ昇格させてはいけない。$MDNSent が存在しても、送られたものが一つもない場合がある。それでも停止命令としては正しい。このねじれを保つことが、記録と結果を分離して読むための手掛かりになる。

出典