如何解析电子邮件以获取电子邮件的原始收件人？

Question

我有电子邮件源并想解析电子邮件的原始收件人。

假设“[电子邮件保护]“正在接收电子邮件，但在“收件人”列表中[电子邮件保护]，[电子邮件保护]&[电子邮件保护]提到了。我只想从电子邮件源获取用户 1。

初步分析显示，来自 mdeamon 服务器的电子邮件包含“X-MDaemon-Deliver-To:”标签。类似地，来自 Devcot 邮件服务器的电子邮件包含“Delivered-To:”。但无法获得通用解析逻辑来获取原始电子邮件收件人。

我如何解析电子邮件以获取电子邮件的原始收件人？

Answer 1

在一般情况下，这不可能做你所要求的事情。这也是明确劝阻在管理互联网电子邮件的标准中。

在某些特定情况下可能会有这种可能，但这些情况高度具体。（可能取决于所使用的具体软件、软件配置等）

原因是电子邮件消息（RFC 5822）不包含所有传输层信息（SMTP 是RFC 5821）。 此外，包括所有这些信息都很容易导致信息泄露；另见RFC 7258。

说明这一点的简单情况是，如果您使用 Bcc: 字段向同一域中的多个收件人发送电子邮件；在这种情况下，传输的消息（包括标题的有效负载数据）不包含信封收件人信息，并且跟踪标题通常不包含收件人地址。这意味着从电子邮件中解析收件人地址不仅变得困难，而且完全不可能，因为信息根本不存在。可以构建其他完全有效的例子作为此示例的扩展。

引用 RFC 5822 第 7.2 节：

SMTP 事务（“信封”）中的“反向”（来自 MAIL、SAML 等命令）或“转发”（RCPT）地址与标头部分中的地址之间没有内在关系。 接收系统不应该试图推断这种关系并使用它们来改变要传递的消息的标题部分。 流行的“Apparently-to”标头字段违反了这一原则，并且是意外信息泄露的常见来源，不应使用。

SHOULD NOT注意from的定义RFC 2119：

4. 不应该这个短语或短语“不推荐”意味着在特定情况下特定行为是可以接受的甚至是有用的，可能存在正当理由，但在实施任何用这个标签描述的行为之前，应该理解其全部含义，并仔细权衡具体情况。

引用 RFC 7258 第 2 节：

总而言之：目前的能力允许一些参与者以前所未有的规模监控互联网上的内容和元数据。这种普遍的监控是对互联网隐私的攻击。IETF 将努力制定减轻普遍监控攻击的规范。