![我收到的电子邮件是发往 [email protected] 的。这是怎么做的？](https://linux22.com/image/1530157/%E6%88%91%E6%94%B6%E5%88%B0%E7%9A%84%E7%94%B5%E5%AD%90%E9%82%AE%E4%BB%B6%E6%98%AF%E5%8F%91%E5%BE%80%20%5Bemail%20protected%5D%20%E7%9A%84%E3%80%82%E8%BF%99%E6%98%AF%E6%80%8E%E4%B9%88%E5%81%9A%E7%9A%84%EF%BC%9F.png)
我最近收到了一封诈骗邮件，为了好玩，我打开它阅读了一下。非常简单，而且没有花费太多精力。
我注意到一件奇怪的事情；这封电子邮件不是发给我的。起初，我怀疑是抄送或密送，但邮件上没有我的地址。我在下面提供了一张图片。这是怎么做到的？
答案1
互联网电子邮件信息由两部分组成。我们可以将它们称为信封和有效载荷消息或者简单地信息。
信封中有路由数据：主要包括发件人地址和一个或多个收件人地址。
该消息具有以下消息内容：主题行、邮件正文、附件等。它还包含一些技术信息，例如跟踪 ( Received:) 标头、DKIM 数据等；以及显示发件人和收件人地址（您在邮件客户端的From、To和字段中看到的地址）。Cc
其关键在于：两人没必要同意吧！
邮件服务器将查看信封数据以确定如何发送邮件。另一方面，除了少数例外，邮件本身将被视为数据。特别是，一个运行良好的邮件服务器才不是查看消息本身的To:和Cc:字段来确定收件人列表，也不会查看字段From:来确定发件人的地址。
当你撰写并发送电子邮件时，您的电子邮件客户端将获取您在“收件人”、“抄送”和“密送”字段中输入的内容，并将其转换为信封路由信息。这主要通过删除全名（仅保留电子邮件地址）来完成，但也可能涉及地址重写、别名扩展等操作。结果是电子邮件地址列表，这些地址作为收件人列表提供给您的邮件客户端正在与之通信的邮件服务器。收件人和抄送列表保留在电子邮件中，但密件抄送不会传递给服务器，因此邮件收件人看不到它。发件人地址的工作原理非常相似。
当邮件到达最终目的地时，信封数据要么被丢弃，要么保留在详细的邮件头中。这就是 Spittin' IT 在对您的问题的评论中要求提供完整邮件头的原因之一。
此外，通过互联网电子邮件，可以直接与邮件服务器通信，从而注入一封信封数据与邮件数据不匹配的邮件，而这是正常的，行为良好电子邮件客户端不允许您撰写电子邮件。此外，邮件服务器对信封数据中给出的发件人地址进行不同程度的检查；有些几乎不检查除了确保它是一个句法上合法的邮件地址。邮件数据的“发件人”标头受到的审查甚至更少。
由于接收电子邮件客户端会显示发件人、收件人和抄送标题中的内容，而不是信封中的地址数据，可以把任何你想放的东西放在那里接收电子邮件的客户端别无选择，只能相信它是相当准确的。对于合法邮件，它通常足够准确；对于垃圾邮件，它几乎从来都不够准确。
在我们人类所居住的有形物质世界中，这信封发件人和信封收件人分别对应于您在信封外面写的回信地址和收件人地址； 和From:/To:标题Cc:分别对应于您在信封中的信件中输入的您和收件人的地址。
答案2
tl;dr 在底部。
SMTP 协议没有 CC 或 BCC 收件人的概念；这是邮件客户端的惯例。SMTP 服务器通常只关心路由信息和数据。这是一个重要的区别，因为如果没有此功能，BCC 就不可能存在。作为合法的 BCC 通信，请考虑以下客户端记录：
HELO from-mail-server.com
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
DATA
From: "John Smith" <[email protected]>
To: "Jane Doe" <[email protected]>
BCC: "Anonymous" <[email protected]>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM
This is an important meeting notice. We'll meet tomorrow.
.
现在，在这种情况下，匿名者收到了有关这次会议的消息。然而，这个版本的邮件不是路由到 Jane Doe；她对 Anonymous 收到通知一无所知。相反，Jane Doe 将收到具有不同正文和标题的消息：
HELO from-mail-server.com
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
DATA
From: "John Smith" <[email protected]>
To: "Jane Doe" <[email protected]>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM
This is an important meeting notice. We'll meet tomorrow.
.
这里，由于匿名者在密件抄送中，发送给 Jane Doe 的邮件不包含密件抄送收件人列表。由于密件抄送惯例，电子邮件信封可能不包含实际收到邮件的收件人，也可能包含未出现在邮件标题中的收件人。
正如所提到的@JonasWielicki我还想补充的是，MUA（邮件用户代理）通常负责发送实现 BCC 所需的多封电子邮件。电子邮件服务器对 BCC 一无所知，因此 MUA 必须通过发送信封标题中指定的不同电子邮件路由的多封电子邮件来实现 BCC。因此，BCC 通常比普通电子邮件花费更长的时间，因为必须单独构建和发送不同的邮件正文。
这也有助于遵守一些电子邮件规则。例如，邮件服务器可能配置了自动密送存档电子邮件服务器的规则（发送给它的所有电子邮件也将被存档），在这种情况下，邮件服务器甚至可能不是真正的收件人。
HELO from-mail-server.com
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
DATA
From: "John Smith" <[email protected]>
To: "Jane Doe" <[email protected]>
BCC: "Anonymous" <[email protected]>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM
This is an important meeting notice. We'll meet tomorrow.
.
在这里，接收者是完全不向任何接收者甚至发送者透露身份的另一方。这是协议的一个特性，通常用于中继或存档消息。
这封垃圾邮件正是利用了这种行为。这是一个标准漏洞，从技术上讲，任何符合要求的邮件服务器都应该能够利用它。当然，许多更新的服务器使用 DKIM 等“扩展”来验证此类电子邮件是否真实，但仍有许多旧邮件服务器并不在意，只是因为他们很容易不想修复没有损坏的东西。
还请注意我如何指定日期标头。这可以是任何任意（但格式良好）的值；许多客户端会很乐意显示从遥远的过去到遥远的未来的任何合法日期范围。几年前，我曾亲自给自己发过一封电子邮件，这封电子邮件在我预期寿命之后很长一段时间内仍会留在我的邮箱顶部，还有一封电子邮件的日期早于我的电子邮件帐户和我自己的出生。
总结
因此，总而言之，发件人伪造了一封电子邮件，原始邮件服务器接受/转发了该邮件，您的电子邮件服务器接受了该邮件并将其存储在您的收件箱中，并且您的客户端如实地向您显示收件箱中的数据，所有这些都没有规避任何安全性。从这个角度来看，“发送”安全性通常比“接收”安全性限制少得多，因为 POP3 几乎总是要求您输入用户名和密码才能访问邮箱（理论上您可以规避这一点，但我不知道有任何合法的邮件服务可以这样做）。
答案3
SMTP 和电子邮件是非常古老的互联网服务，诞生于一个对安全性和身份验证不太重视的时代（DNS 是另一个例子）。协议的设计不会尝试验证发件人地址的真实性，而只会验证收件人地址以确保邮件可以送达。
电子邮件通过 SMTP 协议传输。SMTP 协议相对比较简单；它提供了一种将纯文本传输到电子邮件地址的功能，仅此而已。此纯文本的结构定义为RFC 5322。一般来说，电子邮件文本具有元数据（称为标题）和邮件的实际文本正文。此电子邮件标题由发件人生成（其中任何一个都不可信任），并包含“收件人：”、“发件人：”、“主题：”等字段...
SMTP 协议不会（也不应该）验证电子邮件标头是否与 SMTP 协议中定义的极少数内容相匹配，这些内容本质上是您的电子邮件地址和从未以任何方式验证过的发件人电子邮件地址。
电子邮件中的几乎所有内容都可能是伪造的。
如今，关于电子邮件内容唯一值得信赖的就是 DKIM 签名，它证明该电子邮件是通过域名注册人认可的电子邮件服务器处理的。深入挖掘后，您会发现这封诈骗电子邮件没有 DKIM 签名。
答案4
根据检查标题，这是略有不同的外观。其他答案比我更好地处理了 SMTP 的细节。
如果你能得到邮件的完整标题，然后在其中搜索你的地址，你可能Envelope-to在名为或Delivered-to的字段中找到它X-Apparently-to。第一个由我的邮件提供商使用，第二个由 Gmail 使用；我也见过第三个被使用。这些是不同的字段，但就我们的目的而言，它们往往意味着同一件事：实际将邮件发送到的邮箱。我通过从 Outlook（桌面版）发送并将收件人密送来进行测试。
我的邮件提供商也使用该Delivered-To字段，但用于其服务器上的邮箱名称。这不是我的电子邮件地址，尽管它看起来像一个（认为ChrisH-$ACCOUNTNAME@$SERVER.mail.com）。
另一方面，如果您被列为密件抄送，则 Outlook（与 Exchange 服务器结合）不会在标题中包含带有收件人电子邮件地址的单个字段。