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

Question

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

假设“user1@example.com”正在接收电子邮件，但在“收件人”列表 user1@example.com 中，提到了 user2@example.com 和 user3@example.com。我只想从电子邮件源中获取 user1。

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

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

Answer 1

在一般情况下，不可能做你所要求的。管理 Internet 电子邮件的标准也明确不鼓励这样做。

在某些特定情况下可能是可能的，但这些将是非常具体的。（可能取决于使用的特定软件、软件配置等）

这样做的原因是电子邮件消息 ( RFC 5822 ) 不包含所有传输层信息（SMTP 是RFC 5821）。此外，包含所有这些信息很容易导致信息泄露；另请参阅RFC 7258。

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

引用 RFC 5822 第 7.2 节：

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

请注意SHOULD NOT来自RFC 2119的定义：

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

引用 RFC 7258 第 2 节：

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