摘要

  • RFC 9979 把 $istrusted 登记为 IMAP/JMAP 的共享、建议性关键字：服务器在投递时设置它，表示已经高度确信地核验发件人的显示名称和邮件地址。仅仅通过 SPF、DKIM 或 DMARC 明确不足以设置该标记。
  • 客户端可以把共享状态显示为验证徽标，但它不证明正文安全、链接可信、操作获得授权、界面表达准确，也不保证服务器判断永远有效。RFC 还警告，受损或恶意服务器可操纵这些关键字误导用户。
  • Daniel Kade 提出最小化的“信任展示纠错记录”，串联服务器的证据类别与政策版本、关键字状态、客户端呈现、重要依赖和后续纠正，不保存邮件正文、凭据与无关行为。

一个状态被同步出去以后，影响不再只在服务器上

假设邮箱服务商向用户发送账户通知。收件服务器掌握足够强的来源证据，能够同时确认 From 中显示的名称和地址，于是给邮件设置 $istrusted。网页端显示小型对勾，手机端写着“发件人已验证”。用户看不到后台规则，却会合理地理解为：邮箱服务商以自己的判断为这个身份背书。

几天后，调查推翻了原结论。也许某类证据被错误地扩展到更多身份，也许旧政策没有按期退出，也许服务器完整性曾经受损。清除关键字能够改变当前状态，却回答不了历史问题：哪些邮件处于错误状态，哪一版策略作出判断，哪些客户端把它显示成什么，哪些高风险流程在徽标可见时被启动？

RFC 9979 于 2026 年 5 月作为 IETF 信息类文件发布。它定义并登记了 17 个消息关键字和 3 个邮箱名称属性，这些名称此前已见于不同服务器与客户端实现。统一登记避免命名冲突，也让“谁设置、共享与否、是否触发动作、 intended use 是什么”有共同语言。

$istrusted 的门槛被写得很高。它表示服务器已对发件人名称和地址的真实性取得高度信心。文件给出的典型场景，是邮箱服务商识别自己发给客户的真实消息；支持该关键字的客户端可以提供验证提示，帮助用户把真消息与冒充服务商的钓鱼邮件区分开。

标准也把最容易出现的捷径明确封死。服务器设置该关键字时必须格外谨慎，因为它向用户传递信任；误用可能诱使人相信欺诈消息。文件进一步规定，不能只因标准的 SPF、DKIM 或 DMARC 检查通过就设置它。这些机制各自在特定范围内提供有价值的事实，却不会自动合成为对显示名称和地址的高置信判断。

注册表规定谁在说话，却不会替说话者解释全部依据

IANA 的 IMAP 与 JMAP 关键字注册表 把 $istrusted 列为 SHARED、COMMON、BOTH。RFC 的登记表称其为建议性关键字，并说明由服务器在投递时设置。这里已经划出了重要权责：断言来自服务器，状态可在客户端间共享，而它本身不是必须自动执行的命令。

不过，一个 token 不会自带完整案卷。客户端只获得服务器的结论，看不到采用了哪类证据、哪版决策规则、证据何时被观察、事后由谁复核，以及为什么后来撤回。服务器同样未必知道客户端如何表达：一个灰色小图标、醒目的“官方可信”、屏幕阅读器读出的“安全邮件”，甚至完全不显示，都可能源于同一个关键字，却塑造截然不同的期待。

RFC 9979 中的其他关键字展示了这种边界差异。$new 是提升注意力的建议状态，用户交互后可由客户端清除；$notify 可能触发通知；$muted 由客户端设置，服务器可能据此降低线程中新消息的显著度；$unsubscribed 记录的是退订尝试，不是成功证明。每个名称协调一个状态或动作，而不是把整个结果链收进自己名下。

邮箱属性给出更直观的例子。Snoozed 标识暂存延后邮件的位置，但 RFC 明说，这个属性本身不定义延后机制与界面。IANA 邮箱名称属性表 让客户端发现一种角色，不会因此变成调度器。类似地，$istrusted 让服务器判断可以携带，不会因此成为完整的审计和纠错系统。

“身份可信”不能在界面里悄悄变成“照做无妨”

RFC 的语义对象是显示名称和邮件地址的真实性，不是整封信的真理性。它没有担保每句话准确、每个链接无害、每个附件安全，也没有授权付款、重置账号或披露信息。真实的发送者也可能犯错、被内部滥用，或者提出收件人不应执行的要求。

产品文案很容易抹去这条界线。“此身份已由邮箱服务器确认”仍然描述来源判断；“此邮件安全”则替正文和后果作了更宽的承诺。若徽标紧挨着转账或凭据重置按钮，身份信号还可能在心理上替代业务授权。共享关键字不会记录产品究竟鼓励了哪种解释。

解决办法并不是要求每台客户端重做服务器的全部认证。集中判定可以提高一致性与效率，也可能接触到终端没有的证据。真正需要的是把责任拆开：服务器负责发件人真实性判断，客户端负责如何解释，用户或下游系统负责后续行动。前一个判定不能冒充后一个判定。

Why BTW Media Exists 提出的工作纪律正适用于此：先保留可观察事实，再讨论叙事。可观察事实是某台服务器在某个政策版本下给某条消息设置了某个关键字；“这封邮件安全”是需要另外举证的解释。

对服务器的信任，是断言的一部分

RFC 9979 的安全章节没有把邮箱服务器当成透明背景。文件指出，这些关键字和属性的使用与解释，取决于客户端和用户能否信任 IMAP 服务器；受损或恶意服务器可能错误设置或操纵状态，以此误导人。$istrusted 因而不能脱离断言者独立作证。

一张客户端截图至多证明某个界面在某个时刻呈现了标记。若要判断来源真实性，调查者还需把它连接到同步状态、提供状态的服务器、决策服务的版本，以及被接受的证据类别。服务器完整性本身受质疑时，关键字应当成为待核验的证据，而不是调查裁判。

共享状态还有传播时差。服务器清除标记后，在线客户端可能立刻更新，离线客户端仍保留缓存，先前出现的通知与截图则继续影响人的认识。RFC 9979 不承诺各客户端的缓存和 UI 行为一致。因此，“服务器位已清除”和“所有地方的信任提示已撤下”必须作为两个事件记录。

The Policy Mirror 要求政策反映真实控制面。此处服务器控制结论，同步与缓存控制传播，产品控制表达，人或下游服务控制行动。把四者折叠为一个绿色对勾，会在需要纠正时隐藏责任人。

纠错不需要复制整座邮箱

补足证据不能变成监控工程。邮件正文、凭据、密钥、完整认证追踪和细粒度阅读习惯都会形成过量且敏感的数据仓库。问题其实很窄：一次服务器判断怎样抵达人或自动化表面，判断改变后又怎样被撤回？

“信任展示纠错记录”可以分成六个平面。第一，用邮箱范围内的对象标识或加盐摘要指认邮件，附投递时间与账户范围，不复制正文。第二，记录决策服务、证据类别、政策版本、判断时间和置信区间，不保存原始秘密。

第三，记录关键字状态事件：谁设置 $istrusted、状态版本、同步范围、后来何时移除或替换，以及原因类别。第四，以粗粒度但可用的方式记录客户端呈现：客户端家族与版本、使用的语义标签、无障碍等效表达、已知首次与最后展示时间，以及用户能否查看标记含义。

第五，只在机构有权观察时记录重要后果类别，例如徽标可见期间是否启动高风险流程；不得收集正文与无关行为。第六，记录纠正：调查权限、结论变化、受影响状态区间、通知到的客户端或账户、补救与申诉路径、负责关闭事项的人。

各层只能声称自己知道的事实。服务器清除状态，不代表它知道客户端图标已经消失；客户端缓存有图标，不代表它拥有独立来源证据；事故团队没有时间与呈现证据，就不能断言某次行动由徽标导致。纠错记录的价值，是允许这些未知继续被标记为未知。

这是 Daniel Kade 的治理建议，不是 RFC 9979 新增的字段或要求。它不改变协议语义，只让语义在现实系统中的旅程可以被审查。

来源