邮件在没有 VPN 的情况下到达服务器：规则该在哪里执行

邮件仍在轮询，VPN 已断，但账户依旧同步。应用只是在按配置行事；普通的邮件配置里，没有任何一处说服务器只能经隧道访问。这留下两条不同的要求，而它们很容易被混为一谈：要么服务端拒绝直连客户端，要么 Mac 根本不发起尝试。

先选定要求，再选产品。服务端规则和客户端规则在不同的位置失效，产生不同的证据，也属于不同的责任人。两条都成立时同时实施是合理的，但其中一条不能替代另一条。两条要求都正当；只是它们并不是同一项控制。

症状看起来在 Mac，但泄漏点可能在服务器

邮件在隧道外同步时，先看服务器接受什么。如果邮件监听器会回应来自互联网的直连，客户端任何便利设置都改变不了这个事实。Mac 对一个仍然开放的服务表现得完全正常。

问邮件管理员，服务端看到的源地址是什么。VPN 网关、反向代理或负载均衡器可能改写客户端地址，所以 VPN 配置里的地址池未必与到达邮件进程的地址一致。针对错误来源写的规则，要么拦住所有人，要么一个也拦不住。

这个答复也能说明服务端究竟能否区分 VPN 客户端。如果每个客户端都经同一个代理地址进来，基于来源的准入就无法区分它们，要求就必须转到身份认证或客户端一侧。

主机或网络防火墙可以把邮件监听器限制在获批的源地址范围内，同时不改动身份认证与 TLS。匹配远端地址、子网或地址段的规则条件是常见做法；具体语法属于服务器的防火墙产品，而不属于邮件应用。

当要求是「服务端不得直接为客户端提供服务」时，这是最强的边界。即使用户安装了别的邮件客户端，它依然成立，因为拒绝发生在身份认证之前。它也能挡住无视自身 VPN 策略的 Mac。

它的局限同样重要。被拒绝的连接证明服务端拒绝了这次会话，却不能证明 Mac 没有发起尝试。DNS 解析、发往更早一层负载均衡器的 TCP SYN，以及失败后的重试，都可能在触达服务器规则之前发生。如果要求关乎的是尝试的暴露而非访问本身，那么服务端准入只是这项控制的一半。

客户端规则必须禁止流量，而不只是打开邮件时启动隧道。针对邮件域名的激活触发器能在正确时刻拉起 VPN，却无法定义隧道断掉期间或失败之后会发生什么。

使用终端产品支持的阻断策略，并有意划定其范围。应用级规则覆盖该邮件应用中的每一个账户，包括个人账户。目标级规则必须点明工作账户的 IMAP、提交和认证端点，并且在这些地址变动时仍然有效。

覆盖两种地址族和已有会话。只拦新的 IPv4 连接、却放过 IPv6 或已建立套接字的策略，会产生看似随机的间歇性同步。网络变化和睡眠周期属于同一项测试。

应用级阻断很好理解：没有隧道，邮件就发不出任何流量。它也很粗暴，因为同一个应用里可能还有与策略无关的个人账户。用户最先察觉的正是这一点，并把它报告成邮件应用坏了。

目标级阻断更窄，也更难维护。它需要账户所用的全部端点，包括发现与认证服务，还需要一套更新这些端点的流程。漏掉一个，账户就只工作一半；纳入太多，无关邮件就会被停掉。

按要求的措辞来选。「这个工作账户不得直连」指向目标范围。「这台 Mac 不得在 VPN 之外运行邮件」则可以为更宽的应用规则辩护，前提是责任人接受对个人账户的副作用。

用专用测试账户经 VPN 连接，确认工作正常。然后断开并测试两次：一次看服务端是否拒绝登录，一次看 Mac 是否发起任何连接。这是两种不同的观察，属于不同的日志。

断开时查看客户端一侧是否有 SYN 或 DNS 查询，并在服务端日志里查看会话是被拒绝还是被接受。如果服务端拒绝而客户端仍在尝试，说明服务器规则在起作用，客户端规则缺失。如果客户端不尝试而服务端仍接受其他客户端，边界就正好落在你放置的位置。

记录执行责任人、服务器实际看到的源地址，以及所用的测试账户。下一次网络或代理变更可能挪动这个来源，而写明观测值的记录，比再来一轮猜测更快核对。