摘要

  • RFC 9979 登记了 17 个 IMAP/JMAP 消息关键词和三个邮箱名称属性，让不同客户端能识别同一状态；登记的是共享语义，不是某个实例的真实性证明。
  • $new 表示现在值得重新引起注意，不代表邮件刚刚产生；$istrusted 是服务器的高置信判断；$unsubscribed 记录尝试；Scheduled 只标识存放位置。每一层都需要自己的时间和回执。

一封三个月前收到的邮件，在早晨八点重新出现在收件箱顶部，客户端给它加了 $new。值班人员导出状态时，把这条记录当成“八点收到的新邮件”。原始接收时间没有改变，改变的是系统希望用户现在注意它。

标签没有出错。错误发生在标签跨越了不属于它的现实层。

这个场景是为了说明机制而构造的，不涉及真实服务或事故。RFC 9979 于 2026 年 5 月以 IETF Informational 文档发布。它把多种实现已经使用的 17 个消息关键词和三个邮箱名称属性纳入共同定义，以免同名冲突和语义分裂。这是一项有用的最小协调工作，却不负责证明每封邮件上那一个状态是否正确。

IANA 的 IMAP/JMAP Keywords 注册表记录名称、共享或私有类型、用途、范围与规范引用；IMAP Mailbox Name Attributes 注册表登记 Memos、Scheduled 与 Snoozed。注册表证明公共命名空间已经协调，不证明某台服务器跑过分类器，也不证明某次动作完成。

这种边界之所以重要，是因为 RFC 9979 里的词并非同一类事实。有些由服务器在投递时设置，有些由客户端依据用户操作设置或清除；有些只向界面提供建议，有些可能触发自动处理。一个同步令牌若脱离设置者、规则、时间和对象范围，仍可被所有设备一致显示，却已经失去可问责性。

它建立在已有的邮件状态体系上。RFC 5788创建了关键词注册表，RFC 8457较早定义了共享的“重要”语义。RFC 9051定义 IMAP4rev2，RFC 8621定义 JMAP Mail。跨协议一致使状态可移植，但不会把本地判断变成全球裁决。

附件标签给出了最清楚的三值逻辑。$hasattachment 与 $hasnoattachment 互斥，可是没有前者并不等于后者。RFC 明说，缺失也可能因为分析尚未发生。于是系统必须区分“发现附件”“确认无附件”和“不知道”。界面只显示回形针或空白，往往把后两种状态错误合并。

JMAP 的 hasAttachment 必须反映相同信息。两种协议给出一致结果，只能证明投影一致。它没有证明哪个 MIME 解析器执行过、分析的是哪一版内容、判定何时过期，也不能排除同一错误被同步到全部客户端。

备忘录机制又暴露了关系状态。$memo 标在备忘录消息上，$hasmemo 标在被注释的原消息上。创建或删除时，两端都要更新。RFC 8474提供相关 IMAP 对象和线程标识。若客户端在两次写入之间中断，剩下的令牌仍然合法，却可能指向已经不存在的关系。当前快照不能代替事务历史。

$istrusted 的风险更高。RFC 9979 把它定义为服务器设置的咨询性判断：服务器以高置信度验证了发件人显示名称和邮箱地址。文本强调，误用会让用户相信欺诈邮件，并明确禁止仅因为 SPF、DKIM 或 DMARC 通过就设置这个关键词。

这不是否定邮件认证，而是尊重其范围。RFC 7208判断某主机能否使用信封身份；RFC 6376验证域签名覆盖的选定消息材料；RFC 9989检查可见作者域的对齐，并表达域所有者请求的接收方策略。这些证据都很重要，但不会自动证明显示名称对应的自然人、组织授权、链接安全或正文真实。

RFC 没有给“高置信度”规定统一算法或数值门槛。运营者可以使用本地知识，这种自主性必须与责任同行。标签旁边应有受保护的来源记录：作出判断的服务器、规则与版本、证据类别、置信区间、时间、有效期、撤销条件和负责人。用户界面可以简化表达，但不能把本地判断装扮成无条件保证。

安全章节指出，客户端和用户对这些词的理解取决于其能否信任 IMAP 服务器。被攻陷或恶意服务器可以故意设置、修改状态来误导用户。五台设备都忠实呈现同一个 $istrusted，不是五份独立证词，只是一个源头的断言被复制了五次。

退订标签展示了另一条证据链。$canunsubscribe 意味着邮件带有符合规范的 List-Unsubscribe 机制，并通过了服务器自定的声誉检查。RFC 8058定义一键退订信号。这个状态支持客户端安全地提供按钮，却没有证明用户点击或远端接受。

$unsubscribed 再向前一步，只表示用户尝试过退订，即使尚未收到成功确认；如果已明确失败，则不得设置。一个可靠状态机至少需要“可尝试、已尝试、明确失败、结果未知、确认成功”五种状态。用一个看似完成的英文词吞掉中间层，会让隐私、客服和合规团队得到不同的错误答案。

$new 与 $notify 属于注意力层。前者可以把沉睡后唤醒的旧邮件重新突出；后者要求支持的客户端在用户配置允许时显示通知。它们不证明创建时间、接收时间、通知已呈现、用户已看到或已经行动。请求展示、实际展示、阅读和反应是四份回执。

邮箱名称属性同样有限。Snoozed 标识暂存延后邮件的位置，RFC 明确说它本身不定义延后机制或界面。Scheduled 标识计划稍后发送的邮件所在邮箱。邮件出现在那里，不等于调度器执行、SMTP 接受或收件人收到。计划、尝试、传输响应和最终结果需要分别记录。

$followed 与 $muted 不能同时成立；若冲突，系统按 followed 处理。这条规则让不同实现作出相同决定，但没有解释矛盾来自旧客户端、竞态、恢复还是入侵。RFC 9979 还提醒，攻击者取得账户后可能通过 mute 隐藏关键回复；恢复账户时应审查并确认或撤销这类动作。

这意味着同步状态也可能保存攻击者的意志。重置密码只是撤销未来访问，不能自动净化已经传播到设备上的 mute、规则和标签。若恢复流程只验账户控制，不验注意力与自动化状态，关键对话仍可能沉默。

RFC Editor 信息页与勘误检索界定应采用的文档版本。它们没有列出实际部署、分类算法、邮件或事故。作者所在单位也不是产品采用证明。

Heng Lu 的现实层分析要求分开注册语义、本地规则、服务器断言、同步状态、客户端展示、人的理解、自动动作与外部结果。Running-Code Primacy要求以真正执行的分类和行为压过漂亮的名称。Minimum Initial Specification则说明，共同层应保持窄小：协调名称与冲突规则，不接管运营者的全部未来判断。

因此，配套回执应记录消息、线程或邮箱身份，精确关键词，允许设置或清除的角色，服务器、客户端与协议，旧值和新值，规则或用户动作，证据引用与置信度，时间和到期，传播事件，实际界面，用户偏好，触发动作，外部结果以及纠正。敏感输入不必对每个客户端公开，但其存在、所有者和可复核性必须可证明。

RFC 9979 让状态跨系统流动。真正的治理工作，是阻止标签把没有发生的证明一同带走。

来源