我有我的电子邮件源，并希望parsing电子邮件的原始收件人。
假设“[email protected]”正在接收电子邮件，但在“To”列表中，[email protected]，[email protected]和[email protected]被提及。 我想从电子邮件源只获得user1。
在最初的分析中，来自mdeamon服务器的电子邮件包含“X-MDaemon-Deliver-To：”标签。 同样来自Devcot邮件服务器的电子邮件包含“Delivered-To：”。 但没有得到通用的parsing逻辑来获得原始的电子邮件收件人。
如何parsing电子邮件以获取电子邮件的原始收件人？
在一般情况下， 不可能做你所要求的。 在标准的互联网电子邮件中也显然不鼓励 。
在一些特定的情况下可能是可能的，但这些将是非常具体的。 （可能取决于所使用的特定软件，软件configuration等）
原因是电子邮件（ RFC 5822 ）不包含所有的传输层信息（SMTP是RFC 5821 ）。 另外， 包括所有这些信息都很容易导致信息泄露; 另请参阅RFC 7258 。
用于说明这一点的微不足道的情况是，如果您使用“密件抄送”字段将电子邮件发送到同一个域上的多个收件人， 在这种情况下，所发送的消息（包括报头的有效载荷数据）不包含信封接收者信息，并且在这种情况下，跟踪报头通常不包含接收者地址。 这意味着从电子邮件中parsing收件人地址变得不仅困难，而且完全不可能，因为信息甚至不在那里。 其他完美有效的例子可以作为这个例子的扩展。
引用RFC 5822第7.2节：
在SMTP交易（“信封”）中的“反向”（来自MAIL，SAML等命令）或“转发”（RCPT）地址与标题部分中的地址之间没有固有关系。 接收系统不应该试图推断这种关系，并使用它们来改变邮件的标题部分以便传送。 stream行的“明显到”标题字段违反了这个原则，也是一个共同的意外信息来源，不应该被使用。
请注意RFC 2119中的SHOULD NOT的定义：
- 不应该这个短语或者“不推荐”这个短语表示在特定的情况下，特定的行为是可以接受的或者甚至是有用的时候，可能存在有效的理由，但是应该理解全部的含义并且仔细权衡这个情况，这个标签。
引用RFC 7258第2节：
总而言之：目前的function允许一些参与者以前所未有的规模监控互联网上的内容和元数据。 这种普遍的监测是对互联网隐私的攻击。 IETF将努力制定缓解普遍监视攻击的规范。