Summary

  • 结构化邮件主体草案提出用 application/ld+json 承载机器可读内容；信任草案第 02 版讨论客户端何时显示和处理这些内容。
  • 信任草案第 4.1 节列出七种可供显示的情形，其中包括可信签名者、与可信发件人持续的会话，以及与早前可信邮件的关联。客户端保存的历史因此参与当下的放行决定。
  • DKIM可签整封邮件，JWS可只签结构化部分。签名者是否值得信任，由接收端应用判断。

同一封邮件可以同时说三套话。纯文本写着航班几点起飞，HTML 排出漂亮的行程卡，结构化部分则把预订、地点和可能的操作交给软件识别。主体草案定义了第三套表示；11 月 2 日更新的信任草案追问：软件凭什么把它画成一个按钮？从“读懂数据”到“邀请用户行动”，中间隔着一次产品授权。

草案把邮件分为垃圾邮件、普通邮件和可信邮件，并让可信类别进入结构化数据处理。这里的“可信”不是签名格式自带的勋章。签名可以把内容与签名者绑定；客户端还得判断这个人、这个域名、这个上下文能否获得额外界面。收件人最终看到的是按钮，很少看到按钮背后的分类依据。

第 4.1 节给了七条可选路径。结构化内容没有比 HTML 增加攻击面，是一条；按日历邀请或更新的既有方式处理，是另一条。其余路径涉及可信发件人与有效的个人或域名签名、可信发件人与有效 DKIM 签名、可信 JWS 签名者、与可信发件人的持续会话，以及与过去可信邮件相连的内容。这七项是草案提出的替代条件，不是要同时通过的七道闸。两个客户端看到同一份 MIME，因为本地历史与策略不同，可能画出不同的界面。

旧会话给新按钮借权

最有分量的是“持续会话”。新邮件可以借用旧关系的信誉。一个早已进入对话的账号如果被控制，新的结构化操作就可能顺着那条熟悉的线进入收件箱。软件必须知道自己认的是哪一段历史、哪一个发件人，以及信任何时失效。只记录“DKIM 通过”会漏掉真正促成按钮出现的条件。

签名范围也会改变证据的含义。DKIM 覆盖邮件，JWS 可以只覆盖结构化数据。草案仍在讨论分离式 JWS 载荷，以及应逐字节比较还是使用规范化 JSON。垃圾邮件过滤器、HTML 渲染器和结构化数据解析器若读出不同的预订信息，签名通过与界面误导就能同时发生。需要对照用户实际看到的操作、三种表示，以及真正被签名覆盖的部分。

外部引用是另一道出口。客户端为显示内容而抓取远端资源，可能告诉对方这封邮件已被打开，还可能引入签名载荷之外的新内容。第 4.3 节建议：若有意义的交互原本需要网络抓取，应尽量把必要数据放进邮件本身。公开材料尚缺一组跨客户端测试：同一封已签名邮件、相关回复和外部引用，在不同客户端究竟显示什么、发出什么请求。保存原始 MIME、渲染结果与网络轨迹，就能把这道关口测出来。

信任草案版本记录 · 结构化邮件主体草案 · DKIM · JWS