不连 VPN 也能收邮件：它在偷偷走隧道吗？

邮件仍然会到达一部从未显示过 VPN 图标的手机，于是很自然的结论是：有看不见的东西在通过隧道转发它。通常并没有任何看不见的东西参与。添加 Exchange 账户不会选择网关、协议、证书或路由，因为账户是服务身份，而隧道是别人配置好的网络安排。有用的做法是分辨你实际属于哪种安排，而不是去寻找一条从来不存在的隧道。

三种安排，同一块屏幕

三种安排最后都表现为邮件出现在设备上，设置界面在每种情况下看起来都一样。真正的差别在于：路是谁配置的，以及用什么证据证明它存在。

公网可达性值得单独说一句，因为它经常被误读。公网发布的邮件服务并不是没有认证的服务，而邮件可以访问，也完全不代表企业网络的其余部分同样可达。这是不同的人做出的不同决定。

设备管理究竟能绑定什么

Apple 平台支持按应用和按邮件域设置 VPN 规则，受管理的 iOS 或 iPadOS 邮件可以携带账户专属的 VPN 关联。这个关联是有人选定取值的预置配置项，正因如此，它无法靠在一部手机里输入邮箱地址和密码推断出来。

Android 管理和第三方客户端有各自的应用与配置控制，其中任何一项都无法与 Apple 的账户载荷互换。在一种平台上存在的策略，必须在另一种平台上刻意重建一遍。它不会随邮件账户一起迁移，也不会因为同一个人登录了两边就自动出现。指望这种转换自动发生，正是大量跨平台「我这边手机能用」报告的根源。

身份与传输始终分开

邮件服务和 VPN 可以合法地共用目录或身份提供方，人们就把这种共用登录读成了共用会话的证明。事实并非如此。用户名文本重复，并不能说明邮件应用继承了 VPN 会话，也不是为每项服务另造无关密码的理由。

两种服务各自按自己的条件要求认证。邮件登录成功，绝不该被当成可以粘贴进 VPN 客户端的东西；隧道已经建立，也说明不了邮件服务器会接受哪个账户。这里 Intune 的邮件配置文件是个有用的例子，因为它把 VPN 关联当作独立设置，而不是从账户名推导出来的属性。

重新同步胜过缓存收件箱

缓存收件箱可能看起来完全正常，而当前根本没有可用路径，所以打开应用看到上周的邮件什么都证明不了。请使用经过批准的重新同步测试，并读取随之而来的状态或日志证据。

然后检查真正决定结果的四件事：配置的服务端点、解析器返回的内容、实际生效的受管配置，以及当前 VPN 状态。要在正确的环境里做，因为名称相似的个人邮件应用不受工作应用网络策略约束，会出于完全正当的原因表现不同。把这两个环境混在一起，正是让本来正常的配置被报成故障的原因。它也解释了大多数「一个应用遵守策略、名字几乎相同的邻居却无视它」的情况。

把你验证过的内容写下来

如果访问本应依赖隧道，所有者应当同时确认被允许的私有路径以及没有隧道时的行为。如果服务是刻意公开发布的，就应当保留它的 TLS 校验、认证和访问控制，而不是把「没有隧道」当成邮件未加密的证据。

支持记录应当写明邮件产品、端点、账户范围和连接策略。密码相同对上述四项中的任何一项都不构成证据，而这正是一张工单写了四段话却没有一个事实的最常见原因。