发送给我的电子邮件地址为 MAIL@MAIL.COM。这是怎么做的？

Question

我最近收到了一封诈骗电子邮件，为了笑声，我打开它阅读。非常简单，并没有投入太多精力。

我注意到一些奇怪的东西；这封电子邮件不是发给我的。起初，我怀疑是抄送，或密送，但邮件上没有任何地方有我的地址。我在下面提供了一张图片。这是怎么做的？

Answer 1

Internet 电子邮件消息由两部分组成。我们可以将它们称为信封和有效载荷消息或简称为消息。

信封有路由数据：主要是发件人地址和一个或多个收件人地址。

邮件具有邮件内容：主题行、邮件正文、附件等。它还携带一些技术信息，如trace( Received:)头、DKIM数据等；以及显示的发件人和收件人地址（您在邮件客户端的From、To和Cc字段中看到的内容）。

问题的关键在于：两者不必达成一致！

邮件服务器将查看信封数据以确定如何发送邮件。另一方面，除了少数例外，消息本身将被视为数据。特别是，行为良好的邮件服务器不会查看邮件本身的To:和Cc:字段来确定收件人列表，也不会查看From:字段来确定发件人的地址。

当您撰写和发送电子邮件时，您的电子邮件客户端会接收您在“收件人”、“抄送”和“密件抄送”字段中输入的内容，并将其转换为信封路由信息。这主要是通过删除任何全名（只留下电子邮件地址）来完成的，但也可能涉及地址重写、别名扩展等。结果是一个电子邮件地址列表，这些地址列表作为收件人列表提供给您的邮件客户端正在与之通信的邮件服务器。To 和 Cc 列表保留在电子邮件中，但 Bcc 不会传递到服务器，从而使其对邮件收件人不可见。发件人地址的工作原理非常相似。

当消息到达其最终目的地时，信封数据要么被丢弃，要么保留在详细的消息头中。这就是 Spittin' IT 在对您的问题的评论中要求提供完整邮件标头的部分原因。

此外，使用 Internet 电子邮件，可以直接与邮件服务器对话，从而注入信封数据与正常的、行为良好的电子邮件客户端不会的消息数据不匹配的消息让你作曲。此外，邮件服务器会对信封数据中提供的发件人地址进行不同程度的检查；除了确保它是一个语法上有效的电子邮件地址之外，有些人几乎不检查它。消息数据的 From 标头受到更少的审查。

由于接收电子邮件客户端显示的是 From、To 和 Cc 标头中的内容，而不是信封中的地址数据，因此可以将您想要的任何内容放在那里，并且接收电子邮件客户端将没有追索权，只能相信它是相当准确的。对于合法邮件，它通常足够准确；对于垃圾邮件，几乎从来没有。

在由我们这些人，居住有形的，实物的世界的信封发件人和信封收件人分别对应于返回地址和收件人地址，你写在信封的外面。和From:和To:/Cc:头对应不管你把分别作为您和收件人的地址，在其中放入信封的信。

Answer 2

tl;博士在底部。

SMTP 协议没有 CC 或 BCC 收件人的概念；这是邮件客户端的约定。SMTP 服务器通常只关心路由信息和数据。这是一个重要的区别，因为没有这种能力，BCC 就不可能存在。作为合法的 BCC 通信，请考虑以下客户记录：

HELO from-mail-server.com
MAIL FROM:<john.smith@from-mail-server.com>
RCPT TO:<anonymous@another-mail-server.com>
DATA
From: "John Smith" <john.smith@from-mail-server.com>
To: "Jane Doe" <jane.doe@to-mail-server.com>
BCC: "Anonymous" <anonymous@another-mail-server.com>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM

This is an important meeting notice. We'll meet tomorrow.

.

现在，在这种情况下，匿名者收到了有关这次会议的消息。然而，这个版本的邮件没有被路由到 Jane Doe；她对匿名被通知一无所知。相比之下，Jane Doe 将收到具有不同正文和标题的消息：

HELO from-mail-server.com
MAIL FROM:<john.smith@from-mail-server.com>
RCPT TO:<jane.doe@to-mail-server.com>
DATA
From: "John Smith" <john.smith@from-mail-server.com>
To: "Jane Doe" <jane.doe@to-mail-server.com>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM

This is an important meeting notice. We'll meet tomorrow.

.

在这里，由于匿名在 BCC 中，发送给 Jane Doe 的消息不包括 BCC 收件人列表。由于密件抄送约定，电子邮件信封可能不包括实际收到邮件的收件人，也可能包括未出现在邮件标题中的收件人。

正如@JonasWielicki所提到的，我也想包括，MUA（邮件用户代理）通常负责发送实施 BCC 所需的多封电子邮件。电子邮件服务器对 BCC 一无所知，因此 MUA 必须通过使用信封标头中指定的不同电子邮件路由发送多封电子邮件来实现 BCC。出于这个原因，密件抄送通常比普通电子邮件需要更长的时间来发送，因为必须单独构建和发送不同的邮件正文。

这也有助于某些电子邮件合规性规则。例如，邮件服务器可能具有配置为自动密件抄送存档电子邮件服务器的规则（发送给它的所有电子邮件也被存档），在这种情况下，邮件服务器甚至可能不是真正的收件人。

HELO from-mail-server.com
MAIL FROM:<john.smith@from-mail-server.com>
RCPT TO:<mail-archive@archive-server.com>
DATA
From: "John Smith" <john.smith@from-mail-server.com>
To: "Jane Doe" <jane.doe@to-mail-server.com>
BCC: "Anonymous" <anonymous@another-mail-server.com>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM

This is an important meeting notice. We'll meet tomorrow.

.

这里，接收方是对任何接收方甚至发送方完全不公开的另一方。这是协议的一个特性，通常用于中继或归档消息。

这条垃圾邮件所做的就是利用这种行为。这是一个标准漏洞，技术上应该适用于任何兼容的邮件服务器。当然，许多更新的服务器使用像 DKIM 这样的“扩展”来验证这样的电子邮件是真实的，但是仍然有许多旧的邮件服务器不在乎，仅仅因为很容易不修复没有损坏的东西。

还要注意我是如何指定 Date 标头的。这可以是任意（但格式良好）的值；许多客户很乐意显示从遥远的过去到遥远的未来的任何合法日期范围。几年前，我亲自给自己发送了一封电子邮件，该电子邮件将在我的预期寿命之后很长一段时间内保留在我的邮箱顶部，以及一封早于我的电子邮件帐户和我自己出生的电子邮件。

tl;博士

因此，总而言之，发件人欺骗了一封电子邮件，原始邮件服务器接受/转发了它，您的电子邮件服务器接受了它并将其存储在您的收件箱中，您的客户忠实地向您显示了您收件箱中的数据，所有这些都没有绕过任何安全。从这个角度来看，“发送”安全通常比“接收”安全受到的限制要少得多，因为 POP3 几乎总是需要用户名和密码才能访问邮箱（理论上您可以绕过这一点，但我不知道任何合法的做的邮件服务）。

Answer 3

SMTP 和电子邮件是非常古老的 Internet 服务，在那个时代，安全性和身份验证的重视程度要低得多（DNS 是另一个例子）。该协议的设计不努力验证发件人地址的真实性，仅在确保邮件可投递的情况下验证收件人地址。

电子邮件通过 SMTP 协议传输。SMTP 协议比较笨；它提供了一种将纯文本传输到电子邮件地址的工具，仅此而已。此明文的结构由RFC 5322定义。总体思路是电子邮件文本具有称为标题的元数据和消息的实际文本正文。此电子邮件标头由发件人生成（没有一个是可信的），包含“收件人：”、“发件人：”、“主题：”等字段...

SMTP 协议不会（也不应该）验证电子邮件标头是否与 SMTP 协议中定义的极少数内容相匹配，这些内容本质上是您的电子邮件地址和从未以任何方式验证的发件人电子邮件地址。

电子邮件中的几乎所有内容都可能是假的。

今天，对于电子邮件内容，唯一可以远程信任的是 DKIM 签名，它证明电子邮件是通过域注册人批准的电子邮件服务器处理的。深入挖掘，您会发现此诈骗电子邮件没有 DKIM 签名。