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

Question

我有我的电子邮件来源，并希望解析原收件人的电子邮件。

让我们说" user1@example.com“正在接收一封电子邮件，但是在"To”列表user1@example.com中，user2@example.com & user3@example.com被提到了。我只想从电子邮件来源得到user1。

在最初的分析中，来自mdeamon服务器的电子邮件包含“Deliver：”标记。同样，来自Devcot邮件服务器的电子邮件也包含“传递到：”。但是没有得到通用的解析逻辑来获得原始的电子邮件接收者。

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

Answer 1

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

在某些特定的场景中，这可能是可能的，但这将是非常具体的。(可能取决于所使用的特定软件、软件配置等)

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

说明这一点的次要情况是，如果您使用Bcc:字段向同一域中的多个收件人发送电子邮件；在这种情况下，所发送的消息(有效负载数据，包括标头)不包含信封收件人信息，而跟踪标头通常不包含收件人地址。这意味着从电子邮件中解析收件人地址不仅是困难的，而且是完全不可能的，因为信息根本就不在那里。其他完全有效的示例可以构造为该示例的扩展。

引用RFC 5822第7.2节：

SMTP事务中的“反向”(来自邮件、SAML等命令)或“转发”(RCPT)地址(“信封”)与标题部分中的地址之间没有固有的关系。接收系统不应试图推断这种关系，并使用它们来更改消息的标题部分以进行传递。流行的“显然到”标题字段违反了这一原则，也是意外信息披露的共同来源，不应使用。

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

1. 这句话或“不推荐”一词不意味着在特定情况下，当特定行为是可以接受甚至有用的时候，可能存在有效的理由，但是在实施用这个标签描述的任何行为之前，应该理解它的全部含义，并仔细权衡情况。

引用RFC 7258第2节：

总结一下:当前的功能允许一些参与者以前所未有的规模监控整个互联网的内容和元数据。这种普遍的监控是对互联网隐私的攻击。IETF将努力产生减少普遍监控攻击的规范。