RFC 5235：零分不等于已经完成扫描

Summary

RFC 5235 把不同实现的垃圾邮件和病毒检查映射成可移植的 Sieve 结果，但 spamtest :percent 的零值同时覆盖“已检查且无异常”“未检查”和“无法确认是否检查”。
重要决策不能只保存归一化分数；还应独立保存检查是否执行及其来源，并把结果、脚本分支、动作和最终效果分开记录。

第一封邮件经过最新规则的扫描器，没有命中垃圾特征。第二封邮件抵达时扫描功能被关闭。第三封邮件所在的 Sieve 环境无法判断上游检查是否运行。按照 RFC 5235 的百分比语义，它们都可能得到零。

这不是规范遗漏，而是接口边界。底层检查由具体实现决定，RFC 提供的是可供脚本比较的归一化字符串。它回答“脚本看见了什么值”，并不自动回答“谁以什么规则检查了什么内容”。

如果治理系统只留下前一个答案，没有证据就会在报表中变成“已经证明安全”。

不同扫描器拥有不同标签、阈值和内部状态。RFC 5235 要求实现把结果投影到公共尺度。实现可以额外提供自有文本，但规范明确提醒，依赖这些文本的脚本不再可移植。

这种取舍有价值：同一条 Sieve 规则无需理解每一种私有输出。然而，公共数字通常不会携带扫描器身份、版本、规则更新时间、策略配置、实际检查的邮件形态、跳过的附件、超时或没有执行的原因。

因此，自动化字段与审计凭据不应被强行合并。前者需要稳定、简洁；后者需要保留差异、异常和责任主体。正确做法不是放弃归一化，而是在它旁边保留源头收据。

不使用 :percent 时，spamtest 的范围是零到十：零表示未检查或未知，一表示已检查且确定无垃圾特征。使用百分比后，零又包含“已检查且确定无异常”。

如果数据库只存数字、不存尺度，它连数字原本要表达的命题都丢失了。从十级尺度迁移到百分比尺度时，页面上看起来仍是零，历史含义却已经改变。把两种模式的数据聚合在一起，问题会更严重。

规范为执行状态提供了另一个问题：用关系匹配的 :count，一表示底层检查确实完成，零表示没有完成或 Sieve 无法确定。它能区分“有无执行”，但不能识别扫描器，也不能证明规则新鲜、覆盖完整或输出渠道可信。

某些实现会通过私有邮件头传递扫描结果。RFC 5235 的安全章节要求结果只能来自合法检查流程，并防止发件人或中间节点伪造这些头部。

这说明归一化字段不是普通描述。它能改变脚本分支，写入者因而拥有影响决策的权力。可信边界必须覆盖结果的生成、传输和解释。

但“来源真实”仍不等于“检查充分”。规范要求扫描器保持更新，也提醒病毒检查并非百分之百可靠。一个真实的过期结果仍然过期；一个正确导出的局部检查结果仍然只覆盖局部。

归一化值描述检查接口。比较操作决定脚本是否进入某个分支。脚本再选择动作，邮件系统尝试执行，存储或传输形成后续凭据，收件人最终看到的又是另一层事实。

“零分”不证明扫描发生。“分支命中”不证明动作完成。“放入邮箱”也不证明收件人阅读或受到保护。每一个结论都需要与其对象相匹配的证据。

本文与既有 Sieve 动作研究的边界也在这里：RFC 5235 最值得审视的不是动作目录，而是本地检查在变成可移植数值时丢掉了什么。

这些来源没有提供任何现行厂商、具体部署、误报率、漏报率、恶意活动或事故。IANA 登记只证明扩展被注册，不证明采用程度或实现质量。

零值也并非必然错误。低后果流程可以有意识地接受未知状态。问题在于必须把它记录为风险选择，而不能声称数字本身已经证明邮件安全。

virustest 的尺度同样提醒我们：未知、无已知病毒、已被无害化、可能感染和确定感染都是底层过程的输出。过程的新鲜度、覆盖面和可靠性仍需另行治理。

结果收据应记录扩展名、尺度、归一化值、比较方式、脚本分支和脚本版本。执行收据应记录检查是否发生、扫描器与规则版本、更新时间、检查对象、排除项、错误、可信结果通道以及策略责任人。

动作与最终效果继续保留独立收据。未检查、未知、超时和部分检查都应成为正式状态，不能因为下游系统只接受数字就被强制写成“安全”。

Lu Heng 的现实优先原则在此意味着：协议名称不能替代运行证据，也不能成为承担责任的人。必须有可归责的决策者，明确何时可以接受归一化的不确定性，何时必须证明有人真正检查过。

零可以是合法输出，但组织仍应知道检查是否发生。