摘要

  • RFC 5257 保存的是邮件旁边的持久上下文：.priv 与 .shared 决定可见和可写范围，但不证明注释出自发件人，也不构成组织背书。
  • 同服务器 COPY 会带走全部合格共享注释，却只带走当前用户的合格私人注释；邮件字节相同，目的邮箱中的解释边界仍可能不同。

同一封邮件，两个收件箱，两种“事实”

合规团队把一封供应商邮件从调查邮箱复制到采购档案。正文一字未变，附件哈希也一致。新邮箱里仍有一个共享的“已核准”标记，却没有另一名调查员写下的私人疑点。后来的人看到完整邮件和醒目的核准标签，很容易把缺失的疑点理解为从未存在。

协议并没有犯错。RFC 5257 的设计本来就允许共享注释随消息移动，同时保护其他用户的私人注释。问题出在阅读者把“这份上下文被复制过来”升级成“这就是完整历史”，再把“某个有权限的人写过”升级成“邮件作者或业务主体已经同意”。

注释与邮件靠得很近，但仍处在不同的现实层。邮件是记录；注释是后来附着的解释、提醒或状态。界面可以把两者画在同一行，权威链却不能因此合并。

私人与共享首先是存储边界

RFC 5257 为每个属性隐含提供 .priv 和 .shared 两种形式。读取或搜索时可以省略后缀来同时请求两者；写入、追加和按注释排序时则必须明确选择。这样的不对称迫使写入者声明上下文要进入个人空间还是协作空间。

这一区分很实用。个人可以在共享邮箱中保留自己的调查笔记，团队可以用共享值维护分工、风险或处理状态。然而名称很容易被过度解读。.priv 不等于端到端加密，也不保证管理员永远无法接触；.shared 不等于经过复核，更不意味着机构对内容承担承诺。

后缀说明谁可能看到、谁可能操作，而不是内容是否真实。把敏感资料误写到共享属性会扩大暴露面；把交接信息写进私人属性则会制造只有一个人看得见的“团队状态”。两种错误的根源都是把可见性当成语义。

ACL 证明当时可以做，不证明代表谁

没有 ACL 扩展时，客户端能否修改注释取决于邮箱以只读还是读写状态选中。支持 ACL 时，r 权限控制私人注释的读写以及共享注释的读取，RFC 5257 新增的 n 权限控制共享注释的创建和修改。

这些是精细的操作权限，值得肯定。团队可以允许值班人员更新共享状态，而不授予更广泛的邮箱控制权。但 n 权限的含义只是服务器在那个时刻接受该主体的共享注释写入。它不证明该主体拥有邮件、能代表发件人、获得客户授权，或有权在邮箱之外作出承诺。

因此，审计记录若只保存最终值“approved”，就丢掉了最关键的问题：谁使用哪项凭据、在怎样的 ACL 和邮箱能力状态下写入？“工作流账户写入共享核准值”是可验证陈述；“客户批准了交易”需要另一条来自客户授权链的证据。

持久化不是不可篡改的历史

协议要求注释永久保存，而不是会话结束即消失。这让离线客户端能够同步，也让提醒跨登录存在。但“永久”描述的是存储寿命，不是不可修改、只追加或可追溯。

STORE 可以创建或替换值；写入 NIL 可以删除值。读取不存在的值会得到 NIL，其大小为零。如果没有独立历史，同一个空状态至少可能表示三件事：从未写过、后来被删、或者目的地无法承载它。

并发编辑同样不能靠最终状态解释。RFC 建议离线客户端使用 Conditional STORE 检测自上次快照后发生的变化。冲突检测能减少无声覆盖，却不会判断哪一个值更准确、更符合业务授权或更适合驱动自动化。版本冲突是技术事实，语义裁决仍需负责人和证据。

服务器支持不等于每个邮箱都能保存

服务器可通告实验性能力 ANNOTATE-EXPERIMENT-1，具体邮箱仍会报告自己的现实：NONE 表示不支持，READ-ONLY 表示只能读取，NOPRIVATE 表示仅支持共享注释，数值限制则规定单个值可有多大。服务器还可能限制每封邮件的注释数量。

这使迁移验证不能停在能力横幅。源邮箱能保存私人长注释，并不证明目的邮箱也能；邮件复制成功，也不证明伴随它的每项上下文都成功写入。大小或数量失败是元数据交付失败，应单独暴露，而不是被“邮件已复制”的绿色状态遮住。

能力还是时间相关的。管理员可以改变 ACL，邮箱可以被切成只读，配额或支持模式也会调整。一张旧截图或一次成功写入不能代表以后仍有相同的上下文边界。

COPY 有意制造不对称的包

在同服务器的 COPY 中，支持 ANNOTATE 的服务器复制全部共享注释，只复制执行复制动作的当前用户所拥有的私人注释，并且不得带走其他用户的私人值。目的邮箱的权限、只读状态、功能支持和大小限制还可能进一步减少实际到达的注释。

这是合理的隐私设计，却也揭示了一个治理陷阱：复制对象不是一个封闭的“邮件加完整上下文”包。一个调查员的私人怀疑随其本人复制而来，另一人的不来；共享标签在目的地允许时到达；过大的值可能留在源端。消息正文保持相同，围绕它的知识边界已经改变。

共享值被带走也不会获得新的权威。它可能在邮件抵达数周后由另一个账户写入，在不同 ACL 下修改，再被复制进新的工作流。COPY 保留了值，不会自动保留作者、理由、审批链和原始语境。

搜索与排序会放大未经证明的判断

RFC 5257 允许搜索注释值，并按私人或共享值排序。一项注释由此不再只是边注：它可以决定工单出现在谁的队列、哪一封优先、哪个案件被自动归档。值越能控制后续行动，来源要求就应越高。

语法有效、ACL 可读、复制成功，仍然可能是陈旧或错误的判断。注册标准条目名称或厂商命名空间只是说明字段如何解释，并不为某一个实例背书。查询结果是“系统找到这个值”，不是“系统证实这个值为真”。

后来发布的 RFC 5464 处理服务器和邮箱级元数据，而非这里的逐邮件注释。两者的分离提醒我们：元数据从来不是一个统一权威层。作用对象、写入者、移动规则和消费方式共同决定其风险。

给注释建立自己的回执

对会影响决策的每个值，至少保留邮箱与 UID、邮件或正文部分范围、条目名称、.priv/.shared 类别、写入主体与凭据、ACL 和能力快照、旧值与新值哈希、状态令牌、服务器结果、删除事件、大小或配额决定，以及由它触发的下游动作。

发生复制时，再记录源与目的邮箱、复制主体、两端支持的注释模式、每项属性是否复制或跳过及原因。界面应把注释的写入者、时间和可见类别明确呈现，不能让它在视觉上冒充邮件正文。

表述也要保持克制。“写入后，共享注释的值为‘已核准’”可以验证；“发件人核准”需要发件人的权威链；“档案保留了所有审阅者的上下文”只有在复制回执逐项证明后才能成立。

RFC 5257 提供了一层很有用的持久上下文。领导者真正要守住的，是让这层上下文发挥作用，却永远不能借与记录的邻近位置冒充记录本身的声音。

来源