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

最近，我收到了一封骗局电子邮件，为咯咯地笑着，我打开了它来阅读。很简单，没有太多的努力。

我注意到了一些奇特的东西。该电子邮件未发送给我。一开始，我怀疑是抄送人还是密件抄送人，但邮件中没有我的地址。我在下面提供了一张图片。怎么做？

Internet电子邮件包含两个部分。我们可以将它们称为信封和有效载荷消息，也可以简称为message。

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

邮件具有邮件内容：主题行，邮件正文，附件等。它还包含一些技术信息，例如trace（Received:）标头，DKIM数据等。还有显示的发件人和收件人地址（你在看From，To和Cc领域在邮件客户端）。

这是症结所在：两者不必同意！

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

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

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

此外，随着互联网的电子邮件，也可以直接跟一个邮件服务器，从而注入具有包络数据和消息数据之间的不匹配的消息是正常的，乖巧的电子邮件客户端不会让你作曲。另外，邮件服务器会对信封数据中给出的发件人地址进行不同程度的检查。有些人几乎不检查它，只是确保它是一个语法有效的电子邮件地址。消息数据的From头受到的审查更少。

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

在美国仅仅是人类居住的有形的，实物的世界里，在信封发件人和信封收件人分别对应于返回地址和收件人地址，你写在信封的外面。和From:和To:/ Cc:标题分别对应于您放入信封的信件中您作为收件人和收件人的地址所输入的内容。

tl; dr在底部。

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.

.

在这里，由于Anonymous位于BCC中，所以发送给Jane Doe的邮件不包括BCC收件人列表。由于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; dr

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

SMTP和电子邮件是非常古老的Internet服务，其时代已不那么重视安全性和身份验证了（DNS是另一个示例）。协议的设计不费力地验证发件人地址的真实性，仅在确保邮件可传递的范围内验证收件人地址。

电子邮件通过SMTP协议传输。SMTP协议相对笨拙。它提供了一种将纯文本传输到电子邮件地址的功能。此明文的结构由RFC 5322定义。通常的想法是，电子邮件文本具有称为标头的元数据和消息的实际文本主体。此电子邮件标头是由发件人生成的（不能信任），并且包含诸如“ to：”，“ from：”，“ subject：”等字段。

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

电子邮件中的几乎所有内容都是伪造的。

如今，关于电子邮件内容的唯一甚至是值得信赖的都是DKIM签名，该签名证明该电子邮件是通过域注册者认可的电子邮件服务器处理的。深入研究，您会发现此骗局电子邮件没有DKIM签名。

To电子邮件标题中的地址仅供参考，由电子邮件客户端显示。真实的收件人地址RCPT TO在SMTP中提供。如果您写信，放在信封中，然后在信封上写地址1，则相同。然后去快递，给另一个地址2。快递员将您的信封放在地址为2的较大信封中，然后将货件送到那里。您的秘书（电子邮件客户端软件）将外部信封丢了，并向您显示了带有Address-1的内部信封。您可以通过电子邮件的RAW视图看到此内容。

根据检查标头，外观略有不同。其他答案比我能更好地处理SMTP的详细信息。

如果你能得到你的信息的完整标题，然后搜索他们为你的地址，你可以在一个名为领域找到它Envelope-to，Delivered-to或者X-Apparently-to。第一个由我的邮件提供商使用，第二个由Gmail使用；我也看到了第三个。这些是不同的字段，但就我们的目的而言，它们的含义相同：实际将邮件传递到的邮箱。我通过从Outlook（台式机版）发送，收件人为密件抄送进行了测试。

我的邮件提供商还使用该Delivered-To字段作为服务器上的邮箱名称。尽管它看起来像个（想像ChrisH-$ACCOUNTNAME@$SERVER.mail.com），但这不是我的电子邮件地址。

另一方面，如果您将Outlook（与Exchange Server结合使用）列为密件抄送，则在标头中不包含收件人电子邮件地址的单个字段。