看起来像 VPN ID 的 cid 后缀其实只是 MIME Content-ID

你在邮件头里一个带尖括号的标识符中看到 openvpn，直觉会以为这封邮件和 VPN 会话有关。下结论前请先读完整行：这个字符串位于 Content-ID 中，而 Content-ID 是同一封邮件里某一段正文的名字。HTML 中的 cid: 引用指向那个名字，这一对的存在是为了让邮件能携带图片而不必发送两次。这套安排不会触及任何 VPN 服务器，后缀里也没有任何信息说明这个标识符由谁生成。

这个标识符真正指向什么

HTML 邮件很少作为单一整块到达。正文和每张内嵌图片通常作为独立的 MIME 正文部分传输，客户端再把它们重新组装起来显示。为此，它需要图片部分的名字，以及一个能解析到该名字的引用。

下面这一对是为举例而虚构的。

Content-ID: <[email protected]>

<img src="cid:[email protected]" alt="Company mark">

头部行属于图片部分；img 元素属于 HTML 部分。尖括号属于头部语法，所以 cid: 引用通常在不带尖括号的情况下写出该标识符。含有需要转义字符的值必须先编码，这也是这组例子只作示例、并非转换规则的原因。真正承载含义的是两个字符串之间的匹配，而不是其中任何单独一个。

@openvpn 后缀只是构造细节

Content-ID 被构造成在同一封邮件内唯一，邮件软件常在它后面加上 @ 和域名，让它看起来像地址。这种形态是生成器的惯例，不是路由：邮件头里没有任何内容要求客户端去联系 mailer.example，显示邮件时也不会发生任何查询。这个字段既不是账号名，也不是 VPN 用户，更不是 VPN 客户端留下的标记。它是拼装邮件的人在给某一部分命名时选定的字符串。

RFC 2392 定义了 cid 方案，并将其限定为引用邮件及其各部分。按字面理解这个范围，后缀就不再是命名之外的任何证据。这也意味着无法从后缀识别生成者，而人们看到熟悉单词出现在邮件头里时，恰恰跳过了这一步。

先看原始源码，再判断隐私问题

打开原始源码并读取完整的 Content-ID 值，因为 RFC 2392 允许该值携带发件人的主机名或类似账号的字符串。然后找出同一名字出现的每一处：HTML 中的 cid: 引用、另一个头部、上一封回复中被引用的区块。这些出现之间的匹配关系，才能说明该部分的用途。

同一个特性也正是标识符可能影响隐私的原因。由主机名或账号名衍生的值会随邮件传播，可能泄露关于发送它的机器或个人的信息。它依然不是 VPN 会话，把它当成会话只会浪费这条发现。

远程图片还是内嵌部分：流量不同

带有 https 源的 img 元素与带有 cid 源的 img 元素在 HTML 里看起来一样，在网络上的行为却不同。前者指向客户端在邮件打开后可以抓取的资源，而这次抓取会告诉发送者邮件已被阅读、从哪个地址阅读。后者针对邮件内已有的部分解析，因此显示它不会联系任何人。

一封邮件可以同时混用两者，检查其中一个并不能排除另一个。请把远程引用与内嵌引用分开计数，并注意客户端设置允许什么。对隐私而言关键的是这一区分，而不是标识符里的那个单词。

分享证据，而不发送整封邮件

当需要别人查看时，先做遮蔽处理，并保持一致。替换地址和无关头部，然后在副本中让 Content-ID 及其 cid: 引用保持完全相同的拼写，因为不一致会毁掉唯一重要的证据。说明该头部属于哪一部分、哪一行引用了它。审阅者需要的是这层关系，而不是整封邮件。

然后把两个结论分开写：邮件包含什么，以及它不能证明什么。这样表述的断言可以被核查、被反驳，这正是有用的报告应当允许的。