在 VPN 之上做邮件过滤：内容规则真正运行的位置

这个需求听起来像个网络问题：拦住某类附件出楼，而 VPN 已经在那儿，那就用它。可这个框定在过滤器要回答的第一个问题前就崩了。内容规则必须看见邮件，而邮件可见的位置与隧道不在同一层。我从数据包出发，一路沿邮件路径往外走，停在所需数据真正存在的第一处。

三层彼此独立：VPN 传输、SMTP TLS 连接，以及邮件自身的加密。每一层结束的地方都不一样。

从能看见邮件的那一层开始

VPN 解封装给你的是内层网络流量。如果邮件客户端向提交服务器打开了 TLS 连接，内层流量里仍然是那段 TLS 流，而不是可读的邮件。

所以，在隧道边缘抓包回答的是另一个问题，而不是「这封邮件是否含有被禁止的附件」。

在邮件服务器上终止 SMTP TLS，暴露出的是提交到该端点的那封邮件。服务器能看到头部、信封和 MIME 结构。对许多内容规则来说这就够了。信封告诉你服务器所理解的发件人和收件人。

对受 S/MIME 保护的邮件来说这还不够。服务器收到的是受保护实体，没有相应密钥就读不到里面的内容。完整送达的加密附件同样受这个限制。

不要为了让被动抓包变得可读而削弱传输安全。那是改动架构，而不是把规则放到数据所在之处。

S/MIME 保护的是 MIME 邮件数据，所以它的边界是密钥材料与获授权的解密安排。没有这些密钥的过滤器仍然可以对可见元数据或受保护对象的存在做出反应，但那是另一种结果。

如果组织运行获授权的加密网关或受管理的终端管控，就要写清楚明文存在于何处、哪个身份可以检查它，以及密钥和记录如何受保护。把流量送进 VPN 并不会凭空造出一把主密钥。

在任何人承诺明文分类之前先把这些写下来。承诺才是难以收回的那部分。

如果获批准的邮件服务器收到的是可读邮件，它受支持的内容过滤集成就是执行点。这和允许 SMTP 连接穿过防火墙是两回事。这个区别决定了规则只能拒绝、只能隔离，还是只能加注记。

例如 Postfix 记录了队列之后的内容过滤：邮件先入队，交给过滤器，再回到投递路径。它的事后队列安排，与同一份文档提到的队列前代理和 Milter 选项并不相同。请为你实际运行的邮件服务选择受支持的集成与失败行为。

一条附件规则并不构成完整的数据防泄漏方案。浏览器上传、共享存储和终端操作都需要各自的管控。

用获批准的合成样本测试：一封允许的邮件、一次被禁止的内容动作，以及邮件级加密所声明的处理方式。还要包括过滤器不可用时邮件服务会怎么做。

有用的结果会点明动作、执行点，以及在那里可见的数据。「VPN 把它解密了」只回答了一层，替代不了邮件应用的内容与授权模型。