DMARC和RFC2298兼容的MDN与空MailFrom.它能起作用吗？

Question

这是我们在Exchange上看到的一个问题，但我怀疑这将是大多数托管电子邮件的问题。当Office 365 / Exchange Online发送自动回复(例如离开Office )时，它将遵循RFC 2298和RFC 5321。Exchange为null：

RFC 2298 – Message Disposition Notifications
https://tools.ietf.org/html/rfc2298

   The From field of the message header of the MDN MUST contain the
   address of the person for whom the message disposition notification
   is being issued.

   The envelope sender address (i.e., SMTP MAIL FROM) of the MDN MUST be
   null (<>), specifying that no Delivery Status Notification messages
   or other messages indicating successful or unsuccessful delivery are
   to be sent in response to an MDN.

当RFC5321. identity为null时，SPF使用发送服务器的"HELO/EHLO“标识，而不是：

RFC 7208 - Sender Policy Framework (SPF)
https://tools.ietf.org/html/rfc7208

   SPF verifiers MUST check the "MAIL FROM" identity if a "HELO" check
   either has not been performed or has not reached a definitive policy
   result by applying the check_host() function to the "MAIL FROM"
   identity as the <sender>.

   [RFC5321] allows the reverse-path to be null (see Section 4.5.5 in
   [RFC5321]).  In this case, there is no explicit sender mailbox, and
   such a message can be assumed to be a notification message from the
   mail system itself.  When the reverse-path is null, this document
   defines the "MAIL FROM" identity to be the mailbox composed of the
   local-part "postmaster" and the "HELO" identity (which might or might
   not have been checked separately before).

当您使用DMARC时，问题就开始了，因为OOF或NDR看起来如下：

• RFC5321.MailFrom 5321.邮件：<>
• RFC5322.From 5322来自："person@company.com“
• HELO/EHLO身份：“mail-”

当接收邮件的服务器进行垃圾邮件检查时，它们会执行如下操作：

• 防晒防晒"postmaster@mail-.outbound.protection.outlook.com“->通行证
• 反对“c=放松/放松；d=company365.onmicrosoft.com；s=selector1-company-com”的->通行证
• RFC5321与RFC5322之间的DMARC对齐。来自->的@*.outlook.com != @*.company.com失败

实际头段(匿名)：

Return-Path: <>
From: John Doe <John.Doe@company.com>
Received: from xxx00-xx0-xxx.outbound.protection.outlook.com (mail-xxx00xx0xxx.outbound.protection.outlook.com. [104.47.xx.xxx])
        by mx.google.com with ESMTPS id y11si90960plg.98.2017.09.07.10.27.33
authentication-results: spf=none (sender IP is ) smtp.mailfrom=<>;
Received-SPF: pass (google.com: domain of postmaster@xxx00-xx0-xxx.outbound.protection.outlook.com designates 104.47.xx.xxx as permitted sender) client-ip=104.47.xx.xxx;
Authentication-Results: mx.google.com;
       dkim=pass header.i=@company365.onmicrosoft.com header.s=selector1-company-com header.b=gb5VTzi+;
       spf=pass (google.com: domain of postmaster@xxx00-xx0-xxx.outbound.protection.outlook.com designates 104.47.xx.xxx as permitted sender) smtp.helo=xxx00-xx0-xxx.outbound.protection.outlook.com;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=company.com

在这个示例中，p等于'none‘，所以消息无论如何都会到达，但是如果使用拒绝或隔离，消息将永远不会到达，而且由于返回路径为null，所以不会向发送自动回复的用户传递NDR (这是点以及为什么为null)。因此，外部联系人不会得到自动回复，也不知道他们应该回复，内部用户也不知道外部联系人没有收到。输了-输了。

只有通过消息跟踪，您才会发现问题：

Event            : Fail
Action           :
Detail           : Reason: [{LED=550-5.7.1 Unauthenticated email from company.com is not accepted due to 550-5.7.1 domain's DMARC policy. Please contact the administrator of 550-5.7.1 company.com domain if this was a legitimate mail. Please visit 550-5.7.1
                   https://support.google.com/mail/answer/2451690 to learn about the 550 5.7.1 DMARC initi. OutboundProxyTargetIP: 74.125.xx.xx. OutboundProxyTargetHostName: gmail-smtp-in.l.google.com

对于邮件服务器的HELO/EHLO标识为whatever.mail.company.com的内部邮件服务器，这不是一个问题，因为DMARC记录中的aspf=r将允许子域传递对齐；但是，由于HELO/EHLO标识是*.Microsoft域，而不是*.company.com对齐。

是否有办法克服这一限制？某种例外或策略标志？使用规则发送自动回复或使用传输规则不是我心目中的解决方案；它们是解决方案，用户将不可避免地忘记/忽略消息传递和设置自动回复。

Answer 1

如果您为您的自定义域"company.com“(d=company.com)设置了DKIM，它将与RFC5322.From标头对齐，并传递给DMARC。

如果两个(SPF或DKIM)通道中的任何一个与RFC5322.From对齐，DMARC将通过。

可以在Exchange管理中心->保护->中为您的自定义域设置DKIM。