Eel*_*aak 7 email email-server smtp gmail dmarc
从我的网络服务器发送到 Gmail 地址（From:地址为 ）的几封电子邮件websitevisitor@gmail.com已被 Gmail 标记为垃圾邮件。该From:字段由表单数据填充，对应于访问者的实际电子邮件地址，通常是 Gmail 地址。将Return-Path:始终指向一个地址account@mywebserver.com，这意味着SPF和DKIM检查将正常工作。
当我检查 Gmail 帐户中的原始电子邮件时，我看到以下内容：
Delivered-To: webformrecipient@gmail.com
...
Return-Path: <account@mywebserver.com>
Received: from mywebserver.com (mywebserver.com. [my:ipv6:address])
by mx.google.com with ESMTPS id xxx
for <webformrecipient@gmail.com>
(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 account@mywebserver.com designates my:ipv6:address as permitted sender) client-ip=xxx;
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of account@mywebserver.com designates my:ipv6:address as permitted sender) smtp.mailfrom=account@mywebserver.com;
dkim=pass header.i=@mywebserver.com;
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 <account@mywebserver.com>)
id 1aQWVF-00009b-2X
for webformrecipient@mywebserver.com; Tue, 02 Feb 2016 09:40:01 +0100
To: webformrecipient@mywebserver.com
From: Website User <website-user@gmail.com>
Sender: webformrecipient@mywebserver.com
...
请注意，SPF 和 DKIM 检查均通过，但 DMARC 检查未通过。From:根据有关 stack overflow 的答案，经过一番搜索，我使用地址将其追踪到 DMARC以获取其参考域。
三个问题：
dmarc=fail是 Gmail 将电子邮件分配给垃圾邮件的原因？From:地址进行操作，而不是Return-Path像 SPF 和 DKIM 那样对（信封发件人）进行操作？From:头也必须对应一个地址，@mydomain.com那么我们应该如何指定消息的实际（逻辑上的，有血有肉的）发送者？将 SPF 和 DKIM 视为验证邮件路径的方法，并将 DMARC 视为也验证消息发件人的扩展。将此视为发送 FedEx 信件。很容易验证信封是从哪里发货的，信使是合法的，但它并没有提供一种方法来证明信封内的信件确实来自印在信封上的人。
您的网络服务器是 mywebserver.com 的有效 SMTP 服务器，并且您的发件人地址是合法的，但这还不足以让其他服务器相信您有权以 website-user@gmail.com 的身份发送邮件。GMail 如何知道您的服务器未被黑客入侵或以其他方式用于恶意目的？Gmail 的服务器不会盲目信任您作为其用户之一发送邮件——除非您由他们托管，然后您可能无法发送到雅虎。
为了解决您的第一部分问题，是的，这很可能就是 GMail 将其归类为垃圾邮件的原因。最古老的垃圾邮件形式以欺骗“发件人”地址为中心。这是大多数用户在收到消息时看到的内容，也是他们想要信任的主要字段。当来自合法邮件服务器的邮件使用不属于该邮件服务器的发件人地址发送时，它仍然是一个危险信号。
正如您提到的，作为规范的一部分，DMARC 对发件人地址进行操作。诚然，编写代表某人发送的网络应用程序变得更加困难，但这就是重点。至于他们为什么这样做 - 好吧，这取决于规范的设计者，但这是一种权衡。如果您保持在该限制范围内，他们正在走高路并制作一个运行良好的系统。也许未来的机制会找到解决这个问题的方法。
不幸的解决方案是仅使用您可以控制的地址。要解决您的第三个问题，请使用您的域名签署您的邮件，并在正文中提及它是代表 website-user@gmail.com 发送的。否则，您将不得不请求您的收件人将该地址添加到他们的白名单中。对于合法的 Web 应用程序开发人员来说，这没什么好玩的，但它会保护收件人收件箱的完整性。将 Reply-To 标头与 Web 用户的电子邮件地址一起使用可能会很幸运。
在此 DMARC 线程上有关于此限制的讨论。
同时，您可以尝试确保您的服务器没有被列入任何 RBL 的黑名单。如果您的声誉足够好，您可能无法通过 DMARC，但仍然可以通过一些垃圾邮件过滤器……但我不会依赖它。
小智 5
有两个“为什么”的问题：
该部分明确规定，为了识别负责发送消息的一方，标头（Sender:当存在时）优先于标头：From:
“发件人：”字段指定负责实际传输消息的代理的邮箱。例如，如果秘书要为另一个人发送邮件，则秘书的邮箱将出现在“发件人：”字段中，而实际作者的邮箱将出现在“发件人：”字段中。如果消息的始发者可以通过单个邮箱来指示，并且作者和发送者是相同的，则不应使用“发件人：”字段。否则，两个字段都应该出现。
将此与RFC 7489中给出的基本原理进行对比：
DMARC 通过要求RFC5322.From域与经过身份验证的标识符匹配（对齐）来验证 RFC5322.From 域的使用。选择RFC5322.From域作为 DMARC 机制的中心标识，因为它是必需的邮件标头字段，因此保证出现在合规邮件中，并且大多数邮件用户代理 (MUA) 将 RFC5322.From 字段表示为发起者消息的一部分或全部内容呈现给最终用户。
我认为这个逻辑是有缺陷的，因为RFC 5322继续明确指出了这个错误：
注意：发射机信息始终存在。缺少“发送者：”字段有时会被错误地认为表示尚未指定负责传输消息的代理。这种缺失仅仅意味着发送者与作者相同，因此不会被多余地放置在“发送者：”字段中。
我相信 DMARC 在设计上就被破坏了，因为
Sender:标头来标识自己。如果Sender:存在某个字段，DMARC 应指示验证该字段并忽略该From:字段。但事实并非如此，因此我认为它已被破坏。
RFC 7489继续：
因此，该字段是最终用户用来识别消息来源的字段，因此是滥用的主要目标。
这完全是错误的（在证明忽略标题的情况下Sender:）。在设计 DMARC 时，常见的电子邮件客户端通常会显示来自Sender:和From:字段的信息组合，例如From name-for-mailing-list@server代表user@original.domain。因此，用户总是很清楚谁负责发送他们正在查看的消息。
充分替换的建议Reply-To:也存在缺陷，因为该标头被广泛误解为“附加收件人”而不是“替换收件人”，并且替换原始发件人会损害这些Reply-To:用户的功能。
| 归档时间： |
|
| 查看次数： |
6788 次 |
| 最近记录： |