摘要

  • RFC 5183 让脚本查询运行环境，而不是从当前邮件正文直接取值。名称标准化，并不等于数值来源经过认证。
  • 标准明确警告：remote-host 可能由不可信的 PTR 记录得出；匹配熟悉的域名后缀，不能证明连接来自该组织内部。

值班面板把一次过滤决策画成三格：消息存储器、交付后、内部来源。前三个原始字段分别是 location=MS、phase=post 和以公司域名结尾的 remote-host。它们都匹配，于是系统给出“内部已交付”。

这个结论跨越了多层现实。MS 只描述哪类服务执行脚本；post 只描述相对最终交付的阶段；远端主机名可能只是反向 DNS 返回的标签。它们没有共同证明邮箱写入、复制完成、用户可见，更没有共同证明连接属于公司。

这不是某个厂商事故，而是一个控制模型。错误不在比较器，而在于展示层把三个有限观察压成了一个更强的权威判断。

环境测试观察谁

environment 能力允许脚本给出环境项名称和待比较的键值列表。未指定时，匹配方式是 :is，比较器是 i;ascii-casemap。当前邮件不是这些值的直接来源；解释器从自己的运行环境提取它们。

因此，证据链的起点不是字符串，而是解释器。哪个进程生成数值、运行在哪个服务点、采用什么解析或查询方法、何时采样，这些信息决定字符串能承担多大的判断。

初始标准项覆盖不同层次。domain 是执行上下文关联的主要 DNS 域；host 是执行脚本的完整主机名；location 在 MTA、MDA、MUA 与消息存储之间分类；phase 标记交付前、交付中或交付后；name 与 version 描述解释器产品；remote-host 与 remote-ip 描述适用时的远端 SMTP、LMTP 或 Submission 客户端。

这些定义中没有“员工”“可信租户”“内部网络”“已修补构建”“已完成事务”或“用户已经收到”。本地系统可以建立这些更强的主张，但必须自己拥有证明。

缺失、空值与可信不是同一状态

如果某个环境项不存在，测试必须返回失败，却不能让脚本报错退出。这使同一脚本可以在能力不同的实现之间迁移。缺项是正常分支，不是异常崩溃。

用 :contains 匹配空字符串可以探测项目是否存在，因为任何被返回的字符串都包含空串。但这不能说明值有信息。RFC 5183 要求 remote-host 无法取得时返回空字符串。

关系扩展的 :count 也只回答窄问题：返回信息为空时计数为零，否则为一。它不计算证据源数量、置信度或验证强度。

安全策略至少需要四态：实现不知道该项；实现知道但本次为空；本次非空但来源未验证；值通过了针对当前决策的明确验证。把四态变成一个绿色图标，正是界面制造符号权威的方式。

PTR 名字可以合法，却没有你赋予的身份

RFC 5183 的安全章节直接指出，服务器可用任意技术确定 remote-host，可信度随方法变化。常见方式是查询客户端 IP 的 PTR，而这项信息可能来自不可信来源。

控制反向区域的人可以把记录指向自己选择的域名。因此，以 *.example.com 判断邮件来自“内部”并不可靠。服务器可以完全符合协议，DNS 也可以正常回应，脚本匹配也可以精确；错误仍然发生，因为本地规则把“解析器返回的名字”当成了“组织身份”。

用于高影响决策的记录要保存连接对端、所见协议跳点、反向查询、解析器与响应、缓存时间、验证状态，以及是否执行正向确认。即使 DNS 数据通过密码学验证，也只证明该 DNS 控制链发布了数据，并不自动证明业务角色或人员身份。

remote-ip 更接近连接事实，但 relay、代理、NAT 与提交服务会让直接对端不同于原始发送者。IP 可以成为证据的一部分，却不能在没有拓扑说明时成为万能主体。

post 不是结果字段

phase=post 把脚本放在交付生命周期中的一个位置。它没有交易 ID，不列出落盘节点，也不说明副本、索引或客户端是否已看到消息。location=MS 同样只说消息存储类服务参与执行，不说明是哪台 worker 或哪一代脚本。

RFC 6785 把这一区别写得更清楚。IMAP 事件触发 Sieve 时，location 设为 MS，phase 设为 post，并增加 imap.user、imap.email、imap.cause、imap.mailbox 与 imap.changedflags。

其中 imap.mailbox 在脚本开始时固定。后续 fileinto 改变目的邮箱，它也不会随之更新。这一字段是初始上下文快照，不是实时结果账本。imap.changedflags 能列出发生变化的标志，却不告诉脚本每个标志是被设置还是清除；还要另查当前状态。

所以面板若用环境项替代结果回执，就会把输入状态伪装成输出事实。正确链路还要记录选中的 Sieve 动作、执行组件返回值、下游存储或协议确认与最终可见状态。

注册表协调名称，不负责给部署背书

RFC 5183 为标准项和供应商项建立注册机制。可互操作的标准项由标准轨或实验性 RFC 定义；供应商自定义项以 vnd. 开头并登记以防名称冲突。IANA 当前注册表同时保留原始项、RFC 6785 的 IMAP 项与供应商命名空间。

这是“最小共同规格”的优点：参与者共享有限词汇，同时保留本地演进空间。但名称唯一不等于含义可移植。一个供应商的集群标签迁移到另一个产品后，可能不存在，也可能对应不同故障域。

即使标准项也需要本地语义表。两个系统都返回 MS，并不说明它们在相同提交点、复制点或可见性边界执行。name 与 version 是产品字符串，不是镜像摘要、补丁证明或已加载代码的远程证明。

RFC 5463 的 ihave 可以测试能力是否可用。能力、环境项存在、本次有值与值可被信任仍是四个问题。ManageSieve 管理脚本，也不会替某封邮件证明具体运行路径。

给高影响分支建立可复核收据

凡是能拒绝、丢弃、重定向、隔离或释放邮件的分支，都应绑定不可变策略 ID、脚本哈希与实际解释器构建。记录能力集合、环境项名称、原始值、来源与派生方法、连接对端、location、phase、比较器和所走分支。

随后继续记录动作，而不是在 predicate 为真时停止。下游 SMTP、LMTP、IMAP 或存储事务各自给出结果；如果政策要求用户可见状态，还要在最后进行核对。

这样的收据也能限制信息暴露。标准提醒环境值可能泄露服务商或企业基础设施。用户脚本只需看到完成安全适配所需的最小稳定上下文；更详细的来源信息可以留在受控审计系统。

结束问题不是“图标是否为绿色”，而是：这个值从哪里来、为什么足以支持当前权限、动作以后到底改变了什么？如果只剩标签，系统保存的是解释，不是证据。

来源

  1. RFC 5183 — HTML
  2. RFC 5183 — 纯文本
  3. RFC Editor 信息页
  4. IETF Datatracker 文档页
  5. IETF Datatracker 历史
  6. IETF Datatracker 引用关系
  7. RFC 5183 勘误
  8. RFC 5228 — Sieve 基础规范
  9. RFC 5228 信息页
  10. RFC 5231 — 关系扩展
  11. RFC 5598 — 互联网邮件架构
  12. RFC 6785 — Sieve 中的 IMAP 事件
  13. RFC 6785 信息页
  14. RFC 5804 — ManageSieve
  15. RFC 5463 — Sieve ihave 扩展
  16. IANA Sieve 扩展注册表
  17. IANA Sieve 环境项注册表
  18. Heng Lu — 现实层级
  19. Heng Lu — 最小规格与自愿采用
  20. Heng Lu — 运行代码优先