要約

  • 10月27日付の個人Internet-Draftは、破棄されたメール、連絡先、予定、ファイル、メール処理スクリプトを一定期間取り戻すDeletedItemを提案した。
  • 共有アカウントで項目を見るための入口は破棄時の閲覧権。完全消去と復元では、それぞれ操作時の権限が問われる。

たとえば、請求書を扱う共有メールボックスから一通を消す。翌日、担当から外れた人の共有権限も取り消す。普段の一覧にはメールがない。それでも回復用の一覧を開ける人がいるなら、権限を外したつもりの管理者には説明が要る。JMAP Undeleteの新草案は、拡張を採用するサーバーにその引き出しを設ける。

引き出しに残すDeletedItemには、削除日時と有効期限、元の項目の一部属性が入る。内容を取得するための識別子が付く場合もある。サーバーは何を対象にし、削除後にどれだけ保管するかを知らせる。

記録ができるきっかけはJMAPの削除操作だけではない。対象の項目がIMAPやPOP3で消されても、ごみ箱が自動的に空になっても作る。ごみ箱への移動だけなら作らない。利用者には同じ「削除」に見えても、サーバーは移動と破棄を分ける。

共有アカウントでは、消した日の権限が効く。第3.3節によれば、削除時に元の保管場所の少なくとも一つを読めた人だけが、その記録を見る候補になる。読めたからといって、必ず見せるわけではない。

サーバーは所有者だけに絞れる。昔の権限を確実にたどれないなら、そうすべきだと草案は述べる。RFC 9670で扱う共有権限に、「削除した時点では誰が読めたか」という問いが加わる。

記録が見えても、完全消去できるとは限らない。アカウントのmayPurgeに加え、元の保管場所から項目を取り除く権限が要る。復元には、戻し先で新しく項目を作る権限が要る。

元の場所がなくなったり書けなくなったりしたら、受信箱など既定の場所を試す。そこにも書けなければ復元は失敗する。過去の閲覧権と、現在の消去権・作成権は別の鍵だ。

保持方針を後から変えても、既存記録のexpiresAtを早めてはならない。期限になれば、この拡張は記録を直ちに見せなくなる。有効な完全消去も回復経路を閉じる。

もう一つの入口は、盗まれた資格情報や委任セッションだ。アカウントに入れるなら、最近破棄された内容にも届くと草案は警告する。Datatracker上の状態は、個人草案のI-D Exists。名前が挙がるサーバーには独自の回復画面があるが、提案されたJMAP方式は実装していない。削除後に共有権限を変えた実装試験もまだない。その結果が出れば、古い閲覧資格と現在のアクセスの関係が分かる。