摘要

  • 10 月 27 日提交的个人 Internet-Draft 提议给 JMAP 增加 DeletedItem，让已经销毁的邮件、联系人、日历事项、文件和邮件过滤脚本在保存期内可恢复。
  • 共享账户中，删除时的阅读权限决定谁有资格看这条留存记录；彻底清除和恢复还要分别经过操作权限检查。

团队邮箱里一封发票被清空，普通邮件列表不再显示它。按照新提交的 JMAP Undelete 草案，采用该扩展的服务器会留下另一条记录：DeletedItem 标出删除时间、到期时间、部分原有属性，并可附上供下载的内容。服务器先公布支持哪些对象类型，以及新删除项目的保存期。

触发条件看的是结果，而不是用户按了哪个按钮。对已公布支持的类型，JMAP 销毁、IMAP 清除、POP3 删除或垃圾箱自动清空，都应产生留存记录。仅仅把邮件搬进垃圾箱不算。想给“撤销删除”做界面的团队，得先弄清哪一步才叫销毁。

第 3.3 节把共享账户的门槛放在过去：只有在对象被销毁时，用户对其至少一个原容器享有阅读权，才可能看到这条 DeletedItem。这只是必要条件；服务器还可以收紧，甚至只让账户所有者查看。草案还建议，若无法可靠追溯当时的权限，就只对所有者开放。RFC 9670 的共享模型描述当前对象权限；新提案另外要求服务器有办法判断删除瞬间的旧权限。

看得到，不等于能处置。彻底清除要同时满足账户允许 mayPurge 和用户有权从原容器移除对象；恢复则要看用户能否在目标容器创建对象。原容器已不存在或不可写时，可改放收件箱等默认位置；默认位置也不可写，就恢复失败。于是，共享成员可能够得着留存记录，却没有清除或放回它的权力。草案把这三种动作分开写了。

保存期限也不是随手可改的倒计时：服务器调整设置，不得缩短现有记录的 expiresAt。到期后，扩展必须立即停止提供该记录；成功清除也结束通过该扩展恢复的路径。草案的隐私章节把独立的法律或合同留存放在此接口之外；安全章节指出，持有账户访问权的被盗凭据或委托会话，也可能读到近期销毁的资料。Datatracker将它列为仍在 I-D Exists 阶段的个人草案。文中点名的服务器已有自己的恢复界面，却尚未实现这个 JMAP 方法。现有材料缺少一项测试：删除后共享容器权限变化时，留存记录究竟对谁可见。