摘要

  • 特殊用途属性先决定邮件应放在哪里；找不到对应邮箱时，才回到按名称指定的默认路径。这个默认路径不是任意投递失败后的备用仓库。
  • 邮箱用途可以改变而过滤脚本保持不变；同一用途也可能对应多个邮箱。因此，脚本没有修改，不等于邮件去向没有变化。
  • 存在性与权限检查通过，并不保证实际写入成功。拒绝静默改投保护了位置一致性，却仍要求有人承担容量恢复、故障处理和历史邮件核对的责任。

空着的文件夹为什么不能接手

设想一个邮件账户：当前承担归档用途的邮箱已经没有足够配额，旁边还有一个可写的普通文件夹。过滤脚本里恰好也写着那个普通文件夹的名称。运维人员若只看“投递是否完成”，很容易认为顺手存过去就是恢复服务。

这里描述的是为了说明规则而构造的场景，不是某家服务商的事故。关键在于，脚本为什么保留第二个名称。它究竟表示“没有找到归档用途时用这里”，还是表示“无论哪里出错，最后都可以用这里”？两种授权的范围并不一样。

规定 Sieve 特殊用途邮箱投递的 RFC 8579 选择了前一种解释。已经找到特殊用途邮箱后，如果投递因与邮箱是否存在无关的原因失败，解释器不得再把邮件投进指定的默认邮箱。配额不足不会让一个仍然存在的邮箱变成不存在，也不会自动扩大默认名称的用途。

这不等于规范要求所有失败邮件一律进入队列，也不等于必须退信或丢弃。失败之后仍按普通投递动作的相应规则处理。RFC 8579 在这里限定的是一项具体动作：不能拿“写不进去”当作另选地址的许可。

限制背后并非形式主义。假如归档邮箱时好时坏，有时信件进入归档，有时被悄悄放到另一个目录，读者面对的将是被故障节奏切开的通信记录。每封信也许都能在某处找到，原先依赖的归档位置却不再完整。投递成功率提高了，找信和理解历史的成本转移给了用户。

用途不是文件夹名称的另一种写法

按名称投递很直观，却要求脚本记住当前目录结构。用户更换客户端、调整文件夹或使用不同语言时，承担归档、草稿、已发送邮件等用途的位置不一定有相同名称。反过来，一个叫“归档”的目录也不必然就是这个账户当前指定的归档位置。

IMAP 的特殊用途扩展 RFC 6154 让客户端通过属性识别角色，例如 \Archive、\Drafts 和 \Junk。这些属性帮助软件理解目录的用途，而不只是猜测目录名。RFC 8579 则让 Sieve 的投递动作能够直接使用这种角色信息。

加入 :specialuse 参数后，动作先在用户的个人命名空间里查找带有指定属性的邮箱。找到就选它；没有找到，或者实现根本不认识这个属性，才按没有该参数时的普通规则处理名称指定的默认邮箱。因此，一个动作里虽然出现两种指向，二者却不是可以随意轮换的目的地。

这种间接选择有明显好处。用户调整了归档位置，脚本可以跟随角色，而不必把所有硬编码名称重新改一遍。随之而来的责任也很具体：谁能改变角色分配，谁就可能改变后续邮件的投递位置。

所以，事故复盘只展示“脚本与昨天完全一样”还不够。脚本是选择方法，角色分配是它读取的运行条件。保存了前者而丢失后者的历史，仍然可能无法解释一封邮件为什么被送到那里。

三种状态，不能只记一个失败码

没有用途对应的邮箱、用途对应的邮箱写入失败、同一用途出现多个候选邮箱，是三个不同问题。

第一种情况下，默认名称承担了原本设计的兼容职责：角色没有建立起来，按名称继续处理。第二种情况下，角色已经把目的地确定下来，普通写入故障不应偷偷更换目的地。第三种情况下，应先按候选选择规则得出位置，不能因为不止一个候选就假装没有匹配项。

监控如果把这些情况统称为“走了备用路径”，会掩盖最关键的区别。默认名称使用率升高，可能说明账户没有正确建立用途分配，并不一定说明主存储服务越来越不稳定。反之，先选中用途邮箱、遇到配额错误、随后又向默认目录写入，不能因为最后一次写入成功，就被归入同一种正常回退。

为自动改投辩护并不困难。很多用户确实可能宁可稍后到另一个目录找邮件，也不愿现在遇到投递障碍。问题不在于这种偏好不合理，而在于它需要被明确表达，相关客户端、查找方式和恢复流程也需要知道。不能把一个负责处理角色缺失的参数，悄悄解释成完整的故障接管政策。

规范保留了这个分界，但没有替运营者承担服务责任。守住不静默改投的边界后，谁恢复容量、谁解释失败、谁确认邮件最终如何处理，仍然必须有答案。

“存在”并不是“这封邮件一定能放进去”

specialuse_exists 的名字看起来很像一个足够简单的预检。它确实能回答有用的问题，但问题的范围比“投递一定成功”小得多。

不指定具体邮箱时，测试要求每个列出的用途属性都能在个人命名空间中找到至少一个允许当前脚本用户投递的邮箱。不同属性可以由不同邮箱满足，并不要求一个邮箱同时承担所有用途。指定具体邮箱时，条件才集中到同一个对象：该邮箱存在、允许投递，并且带有全部所列属性。

这里“允许投递”的含义继承自 RFC 5490 对邮箱存在性检查的定义。那个定义明确指出，测试成功不代表之后的投递动作必然成功。例如，实际放入邮件可能导致账户超过配额。

权限回答的是能不能尝试这一类操作，容量影响的是这一封邮件能不能完成写入。二者不能被一个绿色检查结果替代。存在性测试没有替下一步预留空间，也没有承诺所有运行条件会保持不变。

这使“预检通过但投递失败”成为一种可以解释的状态，而不是必须用自动改道消除的矛盾。可靠的证据应分别留下用户上下文、角色对应关系、被选中的邮箱、当时的投递资格，以及实际写入结果。只保留一个检查布尔值，无法重建目的地选择与失败之间的关系。

一个归档角色，可能有几个候选

RFC 8579 并没有把特殊用途定义成账户内部绝对唯一的地址。多个个人邮箱可以带有相同属性。此时，如果按名称指定的默认邮箱也在候选集合中，规范要求选择它。显式名称在这种情况下承担了明确的决胜作用。

如果默认邮箱不在候选中，选哪一个由实现决定。规范建议在相关角色分配没有变化期间保持选择一致；当分配发生变化时，选中的邮箱也可以改变。这不是通用排序算法，更不是“所有符合标准的系统都会选择同一目录”的承诺。

迁移因此不只是把角色名称和文件夹列表复制过去。旧系统与新系统都识别归档属性，并不保证两边会从多个候选中作出同一选择。一个表面上完全保留配置的迁移，仍可能让新邮件开始进入不同位置。

角色本身也有语义边界。RFC 6154 中归档邮箱的具体含义依赖服务器实现。一个 Archive 属性，不会自动赋予固定保存年限、不可更改性或任何特定的机构留存义务。企业希望“归档”这个词代表什么，必须由另一个可核对的服务约定说明，不能让标签替它背书。

不能把初始化工作推给另一端

用途发现依赖已经存在的用途分配。RFC 6154 允许各类特殊用途属性是可选的；支持创建特殊用途邮箱的 CREATE-SPECIAL-USE 是另一项可选能力。客户端通过元数据调整用途，同样取决于服务器是否支持，以及相应变更是否通过有效性检查。

该规范的勘误记录 中有一条很实际的历史线索。编号 4422 的记录描述了 2015 年 7 月 19 日的一次非正式互操作测试：服务器以为客户端会建立特殊用途分配，客户端却以为服务器会先做好这件事。两边的能力看似可以配合，初始化责任却没有落实。

这条记录的状态是“待文档更新”，不是已经生效的新强制要求。不能把其中的改进建议说成现行规范，也不能拿它推断今天某个厂商的部署表现。但它提供了一个有出处的结构性问题：有能力交换一个属性，不等于已经有人负责让这个属性可用。

Sieve 的创建路径也没有彻底消除这种区别。当用途邮箱与默认邮箱都不存在时，需要按相应规则处理默认邮箱的缺失。显式 :create 可以要求在需要时创建默认邮箱；服务器支持 CREATE-SPECIAL-USE 时，RFC 8579 建议把请求的用途属性赋给新邮箱。这里的建议不能写成所有实现都会完成的保证。

于是，一次按默认名称成功存信，可能恰恰掩盖了用途分配仍然没有建立。下一封邮件继续沿默认名称处理，日志却只留下接连成功的写入。操作没有失败，原本期望的选择机制却可能从未真正启用。

为什么不把整个邮件库都搜一遍

如果个人命名空间里没有找到匹配用途，到共享邮件库里再找找，似乎也是一种热心的补救。RFC 8579 没有赋予这种无限扩大的搜索范围。

限制既涉及负载，也涉及控制。如果所有用户都能通过给共享邮箱附上某种用途属性，影响另一名用户过滤脚本的目的地，角色发现就不再只是便利功能。它可能让邮件意外地，甚至被恶意引向共享位置。

这里需要把结论保持在证据允许的范围内。个人命名空间限制约束的是按特殊用途属性发现目的地的过程，并不是声称所有个人邮箱都不能共享，也不是说按名称显式指定的默认邮箱必须满足同样的个人范围限定。RFC 6154 还单独提醒，某些用途赋值可能引起自动处理，把误判的私人邮件放进共享位置会产生暴露风险。

用途由谁赋予、在什么范围里寻找、实际选择了哪个邮箱，合起来才形成投递控制。把搜索范围扩大一点，可能改变的不是检索效率，而是谁有机会影响邮件去向。

这是一份边界分析，不是产品事故通报

本文依据规范和公开勘误，不声称检查过任何真实账户、厂商系统或邮件事故，也没有运行其中的 Sieve 或 IMAP 示例。RFC 8579 已验证的技术勘误 5877 修正的是末尾示例中提取匹配变量所用的操作符，不改变本文讨论的选择与投递失败规则。

Lu Heng 对代理问题的讨论 提供了一种观察角度：作决定的人，是否承担决定造成的损失？把它用于邮件服务，可以看到过滤系统想提高完成率、客户端想保持界面简单、用户想在预定位置找回信件，这些目标并不自动一致。不能因此推断哪一方有恶意，但必须看清成本如何转移。

他对 BTW 应如何描述现实的说明 则要求把结构讲清楚，而不是把报道写成倡议。这里的结构很窄，也很有约束力：默认名称处理角色缺失；已经确定的目的地承载实际投递尝试；普通写入失败不会凭空产生改投授权。真正的恢复必须面对这个失败，而不是把它藏进另一个空目录。