Sieve 邮件过滤语言：服务器端邮件分类的脚本之美

客户端邮件过滤规则存在设备绑定缺陷，更换终端、切换Webmail后规则全部失效，无法实现统一的邮件分类效果。自建邮件系统的运维者常会遇到分类一致性问题，投递阶段过滤生效的邮件，在IMAP端手动调整后无法触发二次过滤，最终导致邮箱分类逻辑混乱、状态不一致。

第一节：为什么邮件过滤要放在服务端？——Sieve 的设计目标与投递时决策的代价

根据 RFC 5228 定义，Sieve 的核心设计目标是在邮件最终投递阶段完成服务端自动化过滤，执行节点严格锁定在MDA将邮件写入用户信箱的瞬间，而非SMTP传输、MTA中继环节。这一定位直接划定了Sieve的核心职责边界：仅负责投递最终环节的分类决策，不介入邮件传输全流程管控。

服务端过滤的核心价值在于单次配置、全端统一生效，分类结果固化在邮件进入个人信箱之前，无论用户使用任意客户端、任意设备访问邮箱，均可看到一致的邮件归档、拦截、转发结果。彻底规避了客户端过滤规则依赖本地运行时状态、无法跨设备同步执行的底层缺陷。

客户端过滤与Sieve服务端过滤存在本质逻辑差异，Outlook、Foxmail等客户端规则仅在对应软件运行时触发，Webmail、移动端等其他访问渠道完全不会加载、执行本地规则，导致多设备邮件分类体系割裂。客户端过滤是“终端侧后置处理”，Sieve过滤是“服务侧前置定型”，执行时序与生效范围完全不同。

行业内常将Sieve的投递时执行模型类比Git的pre-commit钩子，仅在邮件投递这一固定生命周期节点单次触发，决策完成后永久锁定邮件分类状态。Sieve最核心的设计权衡：投递时即时过滤带来全端一致性优势，同时换取了无法回溯重分类的局限性。

Sieve的时效性边界具备明确约束，仅对新投递邮件执行过滤逻辑，用户修改、更新Sieve规则后，已经存入邮箱的历史邮件不会自动重新分类，无原生回溯执行能力。若无IMAP扩展能力加持，Sieve规则变更仅对增量邮件生效，存量邮件分类状态永久固化。

Sieve的职责范围存在严格技术边界，不覆盖SMTP传输层的拒收、灰名单拦截、IP风控等前置逻辑，仅针对完成传输、抵达最终投递环节的完整邮件进行处理。所有邮件传输阶段的风控逻辑，均不属于Sieve的标准能力范畴。

针对最终投递的时序语义，行业标准未细化LMTP传输下的精准执行节点，但主流MDA实现均遵循统一逻辑：LMTP DATA命令传输完成、邮件完整接收完毕后，MDA写入信箱前执行Sieve脚本。Sieve必须获取完整邮件数据后才可执行判断，无法在流式传输过程中完成过滤决策。

Sieve脚本执行失败存在固定回退逻辑，语法错误、运行时异常等故障发生时，邮件默认流入用户收件箱，该兜底行为由MDA实现规范定义，而非Sieve基础标准强制约束。Sieve执行故障不会导致邮件丢失，仅会失效并回归默认投递逻辑。

第二节：Sieve 脚本长什么样？——基本语法结构与过滤动作

Sieve基础脚本采用结构化逻辑设计，整体由条件测试（test）与执行动作（action）构成，依托if/elsif/else实现分支控制，无复杂语法冗余，适配服务端轻量化执行场景。Sieve以极简语法模型为核心设计，优先保障执行安全性与服务器资源可控性。

标准定义的核心条件测试包含三类高频场景，header测试匹配邮件头部字段关键字、address测试精准匹配发件人/收件人地址的域名或本地字段、size测试依据邮件体积判定过滤规则。所有基础测试维度均聚焦邮件元数据与基础属性，不涉及复杂内容解析。

Sieve规范定义五类核心执行动作，fileinto实现邮件文件夹归档、redirect完成邮件转发、keep保留邮件至默认收件箱、discard静默丢弃邮件、reject拒绝投递并生成退信通知。不同动作对应完全不同的邮件流转结局，无模糊中间状态。

Sieve脚本具备明确的终止语义，脚本按顺序逐行执行，除keep隐式动作外，任意显式动作执行完成后，脚本会立即终止，不再遍历后续分支规则。靠前的匹配规则会优先抢占执行权，后续同条件规则永久失效。

无任何条件匹配、无显式动作触发时，Sieve会默认执行隐式keep动作，将邮件存入默认收件箱，该默认逻辑可通过手动编写兜底分支覆盖。如需实现“未匹配邮件全部丢弃”的效果，必须在脚本末尾显式配置else { discard; }分支，无原生自动替换能力。

discard与reject存在明确语义差异，discard为静默丢弃，发件人无任何投递失败感知，无退信报文生成；reject会主动终止投递并生成标准退信通知，反馈投递失败原因。运维场景中，垃圾邮件、无效广告邮件适用discard，合规性投递失败、权限拦截场景适用reject，兼顾邮件礼仪与运维规范性。

基础版Sieve语法刻意剔除循环结构与自定义变量能力，仅通过线性分支实现过滤逻辑，从语法层面杜绝死循环、超长执行耗时等风险。这是典型的表达能力换安全性的设计决策，保障服务端批量邮件投递的稳定性。

RFC 5229扩展规范可受控引入变量能力，但循环结构始终被严格禁止，无任何官方扩展支持。无论基础版还是扩展版Sieve，均不存在循环执行逻辑，彻底规避无限执行风险。

redirect动作存在邮件环路风险，A用户脚本转发邮件至B用户，B用户反向转发至A用户时，会形成闭环转发逻辑。标准仅要求实现者应当（SHOULD）配置环路检测机制，未做必须（MUST）强制约束。不同邮件系统的环路检测能力存在差异，该风险无法通过Sieve标准完全根除。

以下为标准化可运行示意脚本，适配垃圾邮件自动归档场景： require ["fileinto"]; if header :contains "X-Spam-Flag" "YES" { fileinto "Spam"; } 该脚本仅匹配垃圾邮件标记头部，匹配成功则将邮件移入垃圾文件夹，未匹配邮件默认保留至收件箱，完全符合RFC 5228基础语法规范。

第三节：Sieve 在投递流程的哪个环节插入？——执行点的精确位置与影响

Sieve在邮件投递链路中的固定插入点为：MTA通过SMTP/LMTP协议完成邮件传输、交付至MDA之后，MDA将邮件写入用户mailbox之前。Sieve是邮件落地存储前的最后一道逻辑关卡，直接决定邮件最终存储位置或流转结局。

该执行时序具备明确的协议层级含义，Sieve执行时SMTP会话已完全终止，链路传输流程彻底结束。Sieve的reject动作与SMTP传输层550拒收属于完全独立的两套机制，无逻辑关联。

SMTP 550拒收发生在传输会话阶段，直接终止邮件传输链路、实时反馈拒收结果；Sieve reject发生在投递阶段，由MDA生成全新的退信通知邮件，完成逆向反馈。两者的执行时序、协议载体、反馈形式完全不同，不可等效替换。

Sieve触发reject后，退信发送主体由具体MDA实现决定，主流系统默认使用postmaster系统地址作为发件人，极少使用原始收件人地址。采用系统地址发件可提升退信可信度，降低退信邮件被误判为垃圾邮件的概率。

Sieve所有判断逻辑必须等待邮件完整接收完毕后执行，size体积测试等核心能力，要求MDA完整缓冲整封邮件数据。Sieve不支持流式增量判断，所有过滤决策均基于完整邮件数据。

执行点的时序特性划定了清晰的能力边界，所有基于传输层IP、虚拟域、会话状态的前置风控逻辑，均不属于Sieve的处理范围。Sieve仅可解析邮件内容、头部元数据等已固化的邮件信息，无法获取传输层动态会话数据。

Sieve投递决策具备不可逆特性，一旦执行fileinto归档、redirect转发动作，邮件会脱离默认投递路径。后续文件系统写入失败的回退恢复逻辑，无统一标准规范，完全依赖各MDA厂商的自定义实现。

第四节：IMAP 里的邮件变动能触发 Sieve 吗？——Sieve 与 IMAP 集成的模型扩张与一致性陷阱

原生Sieve仅支持投递时单次触发，IMAP扩展对其执行模型完成关键扩张，支持在IMAP协议消息创建、状态变更时触发二次过滤，打破了仅增量邮件可过滤的局限。Sieve的执行模型从“投递一次性决策器”升级为“全场景邮件状态维护器”，是对原生设计的反直觉扩展。

标准定义的IMAP触发场景包含两类核心操作，一是通过IMAP APPEND命令手动上传邮件至邮箱，二是通过COPY、MOVE命令跨文件夹迁移邮件。仅邮件实体创建、跨目录迁移行为可触发过滤，常规邮件标记、已读状态变更无默认触发能力。

IMAP集成的核心价值是弥补原生模型的缺陷，支持对存量邮件、手动导入邮件执行延迟过滤，实现规则更新后的存量邮件重分类。该能力是解决自建邮件系统分类不一致问题的核心方案，但属于可选扩展能力，非基线标准。

IMAP事件触发过滤存在致命的循环递归风险，Sieve脚本通过fileinto完成文件夹迁移后，该MOVE操作本身可能再次触发IMAP过滤事件，形成持续递归执行。标准未定义统一的循环阻断机制，递归深度限制、防循环逻辑完全依赖服务端实现。

投递时执行与IMAP触发执行的语义存在差异，两类场景共享同一套脚本语法，但部分动作逻辑不再适配。IMAP场景下邮件已落地存储，reject拒绝投递的语义完全失效，多数实现会自动屏蔽该动作或降级为discard。

IMAP集成能力不具备通用性，RFC标准未强制要求所有MDA实现适配该扩展，大量轻量化邮件系统仅支持原生投递过滤，无IMAP事件触发能力。部署前未确认该能力，会直接导致“规则更新重分类”的预期完全落空。

IMAP过滤触发粒度无统一标准，部分实现仅响应APPEND、MOVE、COPY核心操作，部分实现会拓展至标签变更、状态修改等场景。实现层面的差异，直接决定过滤行为的可预测性与系统一致性。

第五节：怎么远程管理 Sieve 脚本？——MANAGESIEVE 协议（RFC 5804）的能力与暴露面

根据 RFC 5804 规范，MANAGESIEVE协议专为Sieve脚本远程管控设计，支持用户远程完成脚本上传、删除、查询、激活与停用全流程操作，实现邮件过滤规则的远程迭代更新。该协议本质是邮件系统过滤路由表的远程管理通道，直接掌控邮件流转核心逻辑。

MANAGESIEVE协议具备明确的运行特征，基于TLS加密传输，复用IMAP体系的SASL用户认证机制，独立运行在4190默认端口，与IMAP、SMTP服务端口物理隔离。统一认证体系保障账号安全性，独立端口则形成额外的服务暴露面。

协议定义五类核心标准化操作，PUTSCRIPT实现脚本上传、SETACTIVE配置活跃生效脚本、GETSCRIPT下载已有脚本、DELETESCRIPT清理无效脚本、LISTSCRIPTS查询全部脚本及状态。所有操作均围绕脚本存储与激活状态管控，不涉及脚本执行调度。

PUTSCRIPT上传环节自带强制语法校验，服务器会实时解析脚本语法合规性，存在语法错误、非法扩展调用的脚本会直接驳回，不予存储。服务端从源头杜绝无效、异常脚本生效，避免邮件投递故障。

MANAGESIEVE采用单活跃脚本模型，同一用户同一时间仅可启用一份有效脚本，新脚本SETACTIVE生效后，原有活跃脚本自动降级为非活跃状态。该模型与crontab配置逻辑一致，简化执行调度逻辑，但牺牲了多脚本独立并行生效的灵活性。

多场景过滤需求需通过脚本合并实现，垃圾邮件过滤、邮件归档、自动转发等多套逻辑，必须整合至单一活跃脚本中，无原生多脚本叠加能力。单脚本模型降低了服务端执行复杂度，提升了规则一致性，但增加了复杂场景的脚本维护成本。

协议设计存在明确的安全权衡，复用成熟SASL认证体系保障身份可信，但独立端口的部署模式增加了系统攻击暴露面。RFC 5804放弃IMAP扩展复用端口的方案，以端口暴露风险为代价，换取了脚本管理逻辑的独立性与稳定性。

MANAGESIEVE的职责边界清晰，仅负责脚本的存储、状态管控与校验，不参与脚本执行流程，脚本运行仍由MDA或IMAP服务独立完成。脚本上传生效后的热加载时效无统一标准，是否即时生效完全依赖服务端实现。

协议原生不支持脚本版本管理与回滚机制，覆盖更新、删除脚本后，历史版本无自动留存能力。运维场景中，脚本变更前手动备份是规避配置丢失、故障回滚的唯一可靠方式。