通过 VPN 发送的邮件：回信到底去了哪里

你通过隧道发出一条消息，断开连接，第二天早上回信到了。这件事不需要旧的 VPN 地址，也不会因此坏掉。电子邮件把回信送往邮箱，而不是送往发信时的地址。这里有三条路径被挤成了一个疑问，拆开它们，大部分担心就有答案了。

人们常把三条路径混成一条

投递、送达和阅读是三个彼此独立的连接，其中只有两个涉及你的设备。

Submission: your mail app  -> your mail service
Delivery:   other mail service -> your mailbox service
Reading:    your app now -> your mailbox service

VPN 能影响第一条和第三条，因为那是你的设备建立的连接。它影响不了第二条，因为那条路径跑在你无法控制的两台邮件服务器之间。回信不是回到发信地址的数据包，而是对方邮件服务投递到你邮箱服务的一封新消息。

把这三者分开之后，「回信会不会找不到我」就不再神秘了。

Reply-To 是地址，不是路线

RFC 5322 把 Reply-To 定义为回信应当寄往的邮箱。没有这个字段时，默认是 From 邮箱，除非回信的人另填了别的。两者都是写在邮件头里的地址，都不是「重新打开当初投递那封邮件所用的网络连接」的指令。

这就是 VPN 出口地址从不出现在回信路径上的原因。即便投递服务器在某个地方记录过那个出口地址，回信仍然寄往邮箱，而发信服务器查询的是域名的邮件交换记录，不是你当年的套接字。

如果回信去了意想不到的地方，先读 Reply-To 和发信人自己的客户端设置，再怀疑隧道。

跟踪头到底记录了什么

每一次 SMTP 跳转都会在前面加一个 Received 头，描述它处理的那次连接；最上面的那个就是送达前的最后一跳。因此一封已投递的邮件可能带着值得一看的网络细节，而这些细节由服务器写入，不是你选的。里面有什么，取决于服务商的投递架构和处理邮件头的方式。

与其猜，不如从保存下来的邮件里读：

grep -E '^(Received|Return-Path|Reply-To|From):' message.eml

有用的习惯是弄清每个字段由哪个可信服务添加。邮件头块里靠前的任意文本并不是可靠证据，产品名称也不是「你的家庭住址永远在场或永远不在场」的永久承诺。

事后再读邮件，是一次新的连接

打开回信时，客户端通过你此刻所在的网络连接到你的邮箱服务。那是一次带有自己源地址的新连接，不是昨天那次投递套接字的延续。它遵循你那一刻所用网络的当前策略。

远程内容又是第三件事。加载远程图片或点击链接的邮件客户端，会按当前设置发出单独的请求，而这个请求可能带上邮件里嵌入的任何标识符。它不是送到旧地址的 SMTP 回信，把它当成回信，反而掩盖了真正的暴露面。

如果不想让人知道你打开过这封信，就把远程内容关掉。

在说这是泄露之前，该查什么

先看原始邮件视图和 Reply-To 字段。然后弄清那些让你不安的 Received 记录是哪个服务添加的，并拿服务商当前的文档来对照，而不是旧论坛的回答。

最后，把问题拆开：投递服务器观察到了什么、送达链路添加了什么，以及你打开邮件时客户端请求了什么。

把这三件事分别回答，比查一个 IP 页面更费事，但它是唯一能得出站得住脚结论的做法。回复一个邮件地址不会暴露你的家庭住址，也不需要旧隧道一直开着。