我是如何在没有“收件人”字段的情况下收到这封电子邮件的?

信息安全 电子邮件 垃圾邮件
2021-08-11 10:02:15

我收到了一封我的语言(希伯来语)的空电子邮件,只有一个可以翻译的标题I am still waiting for your feedback(原文עדיין מחכה למשוב שלך:)

由于我的 gmail 处理多个帐户(通过转发和用户\通过),我试图找出哪个帐户是目标,令我惊讶的是 - 没有!

没有收件人的奇怪电子邮件

我的问题很简单,为什么 gmail 选择将这封电子邮件放入我的收件箱?附件是电子邮件的完整来源(来自 gmail),除了我的审查电子邮件这怎么不是安全漏洞\被垃圾邮件过滤器阻止


原始信息:

  • 消息 ID <1516107259.760993983@f493.i.mail.ru>
  • 创建于:2018 年 1 月 16 日星期二下午 2:54(2 秒后交付)
  • 来自:约瑟夫安德鲁使用Mail.Ru Mailer 1.0
  • 到:
  • 主题: עדיין מחכה למשוב שלך
  • SPF:通过 IP 217.69.138.160 了解更多
  • DKIM:“通过”域 bk.ru 了解更多
  • DMARC:“通过” 了解更多
Delivered-To: ****<cencored>****@gmail.com
Received: by 10.2.76.217 with SMTP id q86csp4037724jad;
        Tue, 16 Jan 2018 04:54:21 -0800 (PST)
X-Google-Smtp-Source: ACJfBotHqXkzj6W7gd+8IjEmxrwG9SqXBSC+QiTqyAB1j2Dt4ASXtmXr5UpqIpdU7Mge/EFmnzVI
X-Received: by 10.46.101.207 with SMTP id e76mr192303ljf.115.1516107261904;
        Tue, 16 Jan 2018 04:54:21 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1516107261; cv=none;
        d=google.com; s=arc-20160816;
        b=O+SDwmDS2Y7Jxi+mhwkV/+svfXK0KI3VvepeQgBpyhlgYY5gK3wln+RC4YPO+MMn71
         tyrGBUoc1iGKpeGcilWAovf0XLceJY+EAGoMX4Hl4Pse8C5mWiP0DJQXfmolB5myOFD/
         EoSl7Km4KDcQsvSC0DGwcni1yUPjgiQr+KIY+y19WCqVfm5EtCkbYkUCnFP1RWh/BUBp
         YZHKJrRYH/gWsSqBuIm/fDuSFk4bYAFaCOfkq5LfJcnkf7lpRFBnNYseignqwnnYMEzB
         aScqj1ppvCoYLbBuEiw+yLo1iQLoNdXwGOLShsGXELxkpdFpmchOEV44Wx2vp+RlJMF0
         v1/A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=content-transfer-encoding:message-id:reply-to:date:mime-version
         :subject:from:dkim-signature:arc-authentication-results;
        bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
        b=IPjf/U3N1a7Dx8HIw59iWKeccU4mS7Bd0Iy2FY/Be4Mx4QATd8uBvH7pLOVOLHRAXj
         iATzKUy69ZyLgu6gJVc+yjW3+i740O9ccPNbWAPQQASX1H9OkiMsmlhNYOU5u4KDKfbj
         nNm77TeMxrF57z4XKpbO3iE4YEv6JFankI949HvLnehC7wPP5M5YHpS8CllmV3zP8RX4
         2kb14n4PzguduwYoHL3q7wwWHHnyPUsa3UuhCKLvNJYw4KWKLWNY6Kt7fwReb83T+OsG
         lavZ7huDrCcf0P8Ee7YGepcNpGFyh2WjpA4o7l+gAlnqsb6+5FZloH6j7cmQx/gA+gKh
         aVng==
ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass header.i=@bk.ru header.s=mail header.b=kgyoMcic;
       spf=pass (google.com: domain of joseph.andrew@bk.ru designates 217.69.138.160 as permitted sender)
       smtp.mailfrom=joseph.andrew@bk.ru;
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=bk.ru
Return-Path: <joseph.andrew@bk.ru>
Received: from f493.i.mail.ru (f493.i.mail.ru. [217.69.138.160])
        by mx.google.com with ESMTPS id 1si926950ljd.480.2018.01.16.04.54.21
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Tue, 16 Jan 2018 04:54:21 -0800 (PST)
Received-SPF: pass (google.com: domain of joseph.andrew@bk.ru designates 217.69.138.160 as permitted sender) client-ip=217.69.138.160;
Authentication-Results: mx.google.com;
       dkim=pass header.i=@bk.ru header.s=mail header.b=kgyoMcic;
       spf=pass (google.com: domain of joseph.andrew@bk.ru designates 217.69.138.160 as permitted sender)
       smtp.mailfrom=joseph.andrew@bk.ru;
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=bk.ru
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bk.ru; s=mail; h=Content-Transfer-Encoding:Content-Type:Message-ID:Reply-To:Date:MIME-Version:Subject:From;bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=kgyoMcicHiqU/OvYmq/2sQYQ3607jIk9ZHkh3oVDZTrA6cWDxLGvol37xuQ3L0mfrqIOpSTYHuJzssIjww+4FL/h/GwBRRO1AsuLgxyjSQaOLVqidNe0MUIz6EVQxYXLcUCl9USryPLWAWKBiwL80efALu5znH8K96P6fF33Gzw=;
Received: by f493.i.mail.ru with local (envelope-from <joseph.andrew@bk.ru>) id 1ebQkt-0004Zj-4G; Tue, 16 Jan 2018 15:54:19 +0300
Received: by e.mail.ru with HTTP; Tue, 16 Jan 2018 15:54:19 +0300
From: joseph
  andrew <joseph.andrew@bk.ru>
Subject: עדיין מחכה למשוב שלך
MIME-Version: 1.0
X-Mailer: Mail.Ru Mailer 1.0
Date: Tue, 16 Jan 2018 15:54:19 +0300
Reply-To: joseph
  andrew <joseph.andrew@bk.ru>
X-Priority: 3 (Normal)
Message-ID: <1516107259.760993983@f493.i.mail.ru>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
Authentication-Results: f493.i.mail.ru; auth=pass smtp.auth=joseph.andrew@bk.ru smtp.mailfrom=joseph.andrew@bk.ru
X-7FA49CB5: 0D63561A33F958A5898151702DBFE222A841889EBAE90B8E20672C31CB87FE38725E5C173C3A84C39B8A9203B4187291E49527301AB7C5D479C543ECCDAE434EC4224003CC836476C0CAF46E325F83A50BF2EBBBDD9D6B0F20A889B128FC2D163B503F486389A921A5CC5B56E945C8DA
X-Mailru-Sender: AEEF7784B292FD580FA14CB39DA65BAAC14FF9386EF48BFAB56EC34AB37A73FC68AD8B15A0E9EE36875DC23763F10D8F75E89B9EB25B1370F805D6321A69DA8E2FB9333096616C166E245241366DF001CF5B8F1B83B229A3C432A6261406F5E9E7E03437FF0094633453F38A29522196
X-Mras: OK
X-Spam: undefined

编辑:

尝试使用密件抄送和空“收件人”发送,gmail 显示密件抄送。所以目前@Luc 的答案似乎是真正的答案(RCPT TO被使用)。

BCC 尝试失败

4个回答

为什么?

两种解释:

  • 密件抄送
  • 垃圾邮件

我经常收到垃圾邮件,他们似乎出于某种原因想要隐藏它的收件人。由于我的域上有一个包罗万象的东西,无论他们使用什么地址,它都会到达我的手中(除非他们使用了我列入黑名单的地址)。

这怎么可能?

SMTP 流量如下所示:

EHLO example.com 
MAIL FROM:<user1@example.com>
RCPT TO:<user2@example.com>
RCPT TO:<user3@example.com>
RCPT TO:<user4@example.com>
DATA
Subject: test
From: <user1@example.com>
To: <user2@example.com>
CC: <user3@example.com>

Hi Jake,
Just letting you know that email works.

.
QUIT

您可以打开与任何邮件服务器的 TCP 连接并键入此内容,它会回复您并发送您的电子邮件(我在示例中省略了回复)。在 Windows 上,从 Windows 功能菜单安装 Telnet,然后在端口 25 上键入telnet example.com 25以连接到服务器。example.com

如您所见,user4 的地址是RCPT TO在他们的电子邮件收件箱中,但在电子邮件数据的 from、to 或 cc 标头中没有提及。DATA命令到单独.一行的电子邮件数据是您在电子邮件客户端中打开“查看源代码”时将看到的部分。所以它与实际的电子邮件交换关系不大。当然它通常匹配,但在恶意情况下,他们不在乎什么是“通常”。在密件抄送的情况下,您也不会看到它。

我经常收到垃圾邮件,它们隐藏在发送到的地方。为了能够追踪它,我必须挖掘我的邮件服务器日志。

服务器管理员也可以像这样查找密件抄送,当然只是他们自己的域(如果密件抄送到joe@a.example.comand stefan@b.example.com,管理员a.example.com将看不到 stefan)。

至于为什么您可以在密件抄送中将 GMail 发送给自己,并在接收端看到一个包含您自己的密件抄送字段:电子邮件程序/提供者可以只为密件抄送中的每个收件人发送单独的 SMTP 消息,并BCC在嵌套中制作标题电子邮件标头仅列出该收件人。

To像,CcBcc基本上都是装饰性的标题;他们不根据 SMTP 协议控制电子邮件的实际收件人。可以将您喜欢的任何内容放入这些字段中,并且仍然可以在协议级别单独控制电子邮件发送给谁。

当您在 Internet 上发送电子邮件时,您的发送邮件服务器通过 SMTP 与接收邮件服务器通信。为了发送电子邮件,发送服务器向接收服务器发送一系列命令。

  1. 指定发送服务器主机名的HELO命令(在较新版本的协议中,这可以替换为EHLO(“Extended HELO”的缩写))。
  2. MAIL FROM宣布电子邮件发件人地址的命令
  3. RCPT TO宣布消息接收者地址的命令
  4. DATA宣布消息本身开始的命令,包括标题和正文

消息中的标头(例如To或)不会被执行CcBcc使用,但不会被修改地传输。

如果发送和接收邮件服务器忽略这些标头,为什么它们存在?

因为它们是邮件用户代理使用的通用约定(邮件客户端)软件,这是用户实际与之交互以发送邮件的软件。邮件客户端的常用工作方式是用户在邮件客户端中的三个字段中键入收件人地址,称为“收件人”、“抄送”和“密件抄送”,邮件客户端使用这些字段作为将消息发送给谁的基础. 然后,邮件客户端将写入“To”和“Cc”字段中的内容放入名为“To”和“Cc”的邮件标题中,作为发件人最初在这些字段中键入内容的指示符。这只是对接收邮件客户端的礼貌;发送邮件的客户端可以选择保守这个秘密——事实上,这就是它的“Bcc”字段发生的事情:邮件客户端从不创建“Bcc”

邮件客户端还包含一个“主题”字段,它作为“主题”标头放入邮件中,并在电子邮件中创建一个“发件人”标头,其中包含有关发件人的信息。

这怎么不是安全问题?

它是。它使将有关发件人或收件人的虚假信息放入电子邮件中变得非常容易。当用户相信这是准确的而事实并非如此时,这就是一个潜在的安全问题,因为虚假信息可以用来欺骗收件人。

邮件客户端可以简单地忽略此类标头,但是您将错过在此信息存在且真实时知道电子邮件发给谁的便利,并且按照相同的逻辑,您还必须忽略“发件人”和信封发件人(MAIL FROM命令)也是如此,没有留下任何发送者的迹象。因此,邮件客户端采用的方法是,即使这些信息可能是伪造的,显示这些信息也会带来更多好处。

一个名为 DMARC 的新标准搭载了其他标准 DKIM 和 SPF,可以允许接收邮件客户端验证“发件人”标头的域/主机名部分是否真实。虽然这仅验证“From”标头的一部分,而不验证“To”或“Cc”标头,但它可以让您知道邮件确实来自它声称来自的系统。如果这是一个受信任的系统,您至少可以推断出邮件及其标头是由该系统的授权用户创建的。

除了这些选项之外,电子邮件根本不是为所有这些都可验证而设计的。如果你想要更多,你必须在你的消息之上使用某种形式的加密验证,比如 PGP,并有一些带外验证权限的方式。

到目前为止,我认为您的地址被用作BCC

这可能令人惊讶,但这在 SMTP 协议中是很正常的。消息由标头和正文组成。它通过邮件传输代理链发送。任何代理都不应该更改正文,但他们可以更改标题,主要是添加一个Received字段,Date如果它不存在则添加一个字段以及他们自己处理所需的任何其他字段。但是ToFrom字段都不是特殊的,特别是它们不用于传递邮件MTA 使用所谓的信封,即在 SMTP 协议的MAIL FROMRCPT TO命令中传递的内容。

邮件用户代理(如 Thunderbird)确实使用 To、Cc 和 Bcc 字段来构建信封,但如果您知道SMTP 协议,则很容易发送带有伪造或缺少 To 和 From 标头的邮件。