☰

为什么 DMARC 对发件人地址进行操作，而不是对信封发件人（返回路径）进行操作？

tag-icon • tag-icon email smtp email-server gmail dmarc
为什么 DMARC 对发件人地址进行操作，而不是对信封发件人（返回路径）进行操作？

我的网络服务器向 Gmail 地址发送了几封电子邮件，地址为From:，[email protected]但都被 Gmail 标记为垃圾邮件。 字段From:由表单数据填充，与访问者的实际电子邮件地址相对应，后者通常是 Gmail 地址。Return-Path:始终指向地址[email protected]，这意味着 SPF 和 DKIM 检查将起作用。

当我检查 Gmail 帐户中的原始电子邮件时，看到以下内容：

Delivered-To: [email protected]
...
Return-Path: <[email protected]>
Received: from mywebserver.com (mywebserver.com. [my:ipv6:address])
        by mx.google.com with ESMTPS id xxx
        for <[email protected]>
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Tue, 02 Feb 2016 00:40:02 -0800 (PST)
Received-SPF: pass (google.com: domain of [email protected] designates my:ipv6:address as permitted sender) client-ip=xxx;
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of [email protected] designates my:ipv6:address as permitted sender) [email protected];
       dkim=pass [email protected];
       dmarc=fail (p=NONE dis=NONE) header.from=gmail.com
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mywebserver.com; s=mydkim;
    h=Date:Message-Id:Sender:From:Subject:To; bh=w2snQznwxlVRVACmfQELC7VGmD1dcYdiCXbCIRYFKRs=;
    b=a0Vy3Ky43J5FdiWSuQ4qvTTH47G+Js0W/qtRU5gMlxfesNqrlyaIyExaIZlWvHNL4o0LNOF1GI94w4C41mmH+2JIkMEQZazw0MainP7UyUgsm/RZbAWoRuecPv+k108FlsWMP/l1UttXAdlvBVJmV2UGsYYlSSjKErQEF8tv3K0=;
Received: from apache by mywebserver.com with local (Exim 4.80)
    (envelope-from <[email protected]>)
    id 1aQWVF-00009b-2X
    for [email protected]; Tue, 02 Feb 2016 09:40:01 +0100
To: [email protected]
From: Website User <[email protected]>
Sender: [email protected]
...

请注意，SPF 和 DKIM 检查均通过，但 DMARC 检查未通过。经过一番搜索，我使用地址From:获取其参考域，将其追溯到 DMARC，根据这个答案在 stack overflow 上。

三个问题：

  1. 这是否确实dmarc=fail是导致该电子邮件被 Gmail 归为垃圾邮件的原因？
  2. 为什么 DMARC 对From:地址进行操作，而不是Return-Path像 SPF 和 DKIM 那样对（信封发件人）进行操作？
  3. 如果现在From:标题也必须对应一个地址@mydomain.com，那么我们应该如何指定实际的（合乎逻辑、有血有肉的）信息的发送者？

答案1

将 SPF 和 DKIM 视为验证邮件路径的方法，将 DMARC 视为验证邮件发件人的扩展。将其视为递送联邦快递信件。很容易验证信封的发货地以及快递员是否合法，但它无法证明信封内的信件确实来自印有姓名的人。

您的网络服务器是 mywebserver.com 的有效 SMTP 服务器，并且您的发件人地址是合法的，但这还不足以让其他服务器相信您有权以[电子邮件保护]. GMail 如何知道您的服务器没有被黑客入侵或被用于其他恶意目的？Gmail 的服务器不会盲目地信任您作为其用户发送邮件 - 除非您的服务器由他们托管，那么您可能无法向 Yahoo 发送邮件。

回答你问题的第一部分，是的，这很可能就是 GMail 将其归类为垃圾邮件的原因。最古老的垃圾邮件形式是伪造“发件人”地址。这是大多数用户收到邮件时看到的，也是他们想要信任的主要字段。当使用不属于该邮件服务器的发件人地址发送来自合法邮件服务器的邮件时，这仍然是一个危险信号。

正如您所提到的，DMARC 作为规范的一部分对发件人地址进行操作。诚然，这使得编写代表某人发送邮件的 Web 应用程序变得更加困难，但这正是重点所在。至于为什么他们这样做了——好吧，这取决于规范的设计者，但这是一种权衡。他们走的是高端路线，如果你遵守这一限制，那么系统就能很好地运行。也许未来的机制会找到解决这个问题的方法。

不幸的是，解决方案是只使用您能控制的地址。为了解决您的第三个问题，请使用您的域名签署您的邮件，并在正文中注明它是代表[电子邮件保护]。否则，您将不得不要求收件人将地址添加到他们的白名单中。对于合法的 Web 应用程序开发人员来说，这并不好玩，但它可以保护收件人收件箱的完整性。您可能会幸运地将 Reply-To 标头与 Web 用户的电子邮件地址结合使用。

关于这一限制的讨论此 DMARC 线程。

同时，您可以尝试确保您的服务器未被列入任何 RBL 的黑名单。如果您的声誉足够好，您可能会无法通过 DMARC，但仍能通过一些垃圾邮件过滤器……但我不会依赖它。

答案2

有两个“为什么”的问题：

  1. 为什么接收邮件服务器以这种方式执行检查
  1. DMARC 为什么要这样设计？

该部分明确规定，为了识别负责发送消息的一方，Sender:标头（如果存在）优先于标头：From:

“发件人：”字段指定负责实际发送消息的代理的邮箱。例如，如果秘书要为另一个人发送消息，则秘书的邮箱将显示在“发件人：”字段中，而实际作者的邮箱将显示在“发件人：”字段中。如果消息的发件人可以通过单个邮箱指示，并且作者和发送者相同，则不应使用“发件人：”字段。否则，两个字段都应出现。

将此与RFC 7489：

DMARC 验证RFC5322.来自域，要求它与经过身份验证的标识符匹配（对齐）。RFC5322.来自域被选为 DMARC 机制的中心身份，因为它是必需的消息头字段，因此保证存在于合规消息中，并且大多数邮件用户代理 (MUA) 代表RFC5322.来自字段作为消息的发起者，并将该标头字段的部分或全部内容呈现给最终用户。

我认为这种逻辑是有缺陷的，因为RFC 5322继续明确指出这个错误：

注意：发送者信息始终存在。“发送者：”字段的缺失有时会被误认为未指定负责传输消息的代理。这种缺失仅表示发送者与作者相同，因此不会多余地放入“发送者：”字段中。

我认为 DMARC 在设计上存在缺陷，因为

  • 它混淆了发送权限和作者证明；
  • 它误解了先前的 RFC，并且
  • 在这样做时，它会破坏任何先前兼容的列表服务，该列表服务通过添加自己的Sender:标头来标识自己。

如果Sender:存在字段，DMARC 应该要求进行身份验证那字段并忽略该From:字段。但事实并非如此，因此我认为它有问题。

RFC 7489继续：

因此，该字段是最终用户用来识别消息来源的字段，因此是滥用的主要目标。

这完全是错误的（在忽略标头的背景下Sender:）。在设计 DMARC 时，常见的电子邮件客户端通常会显示来自Sender:和From:字段的信息组合，例如从邮件列表名称@服务器代表[电子邮件保护]。因此，用户始终能够清楚谁负责发送他们正在查看的消息。

认为这是一个足够替代的建议Reply-To:也是有缺陷的，因为这个标题被广泛误解为“附加收件人”而不是“替代收件人”，而替换原始发件人的Reply-To:标题会损害那些用户。

答案3

  1. 这是否确实dmarc=fail是导致该电子邮件被 Gmail 归为垃圾邮件的原因？

    是的，DMARC 故障可能会导致 GMail 将您的邮件视为垃圾邮件。

  2. 为什么 DMARC 对发件人：地址进行操作，而不是像 SPF 和 DKIM 那样对返回路径（信封发件人）进行操作？

    我对这个问题的答案很感兴趣。

  3. 如果现在From:标题也必须与地址相对应，@mydomain.com那么我们应该如何指定消息的实际（逻辑的、有血有肉的）发送者？

    我们使用该reply-to字段来填写客户地址。我们的邮件如下所示：

    from: [email protected]
to: [email protected]
subject: contact form
reply-to: [email protected]

相关内容