DMARC и RFC2298-совместимые MDN с нулевым MailFrom… Может ли это работать?

Это проблема, которую мы наблюдаем с Exchange Online, но я подозреваю, что это проблема с большей частью размещенной электронной почты. Когда Office 365 / Exchange Online отправляет автоматический ответ (например, Out of Office), он соответствует RFC 2298, а RFC5321.MailFrom имеет значение 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.MailFrom имеет значение 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.Mail От: <>
• RFC5322. От: "person@company.com"
• Идентификатор HELO / EHLO: "mail-.outbound.protection.outlook.com"

Когда получающий почтовый сервер выполняет свои проверки на спам, они будут выглядеть примерно так:

• SPF против postmaster@mail-.outbound.protection.outlook.com -> PASS
• DKIM против "c = расслабленный / расслабленный; d = company365.onmicrosoft.com; s = selector1-company-com" -> PASS
• Согласование DMARC между RFC5321.MailFrom и RFC5322.From -> FAIL, потому что @ *. 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', поэтому сообщение все равно будет доставлено, но с отклонением или карантином сообщение никогда не будет доставлено, и поскольку обратный путь равен нулю, отчет о недоставке не доставляется пользователю, отправившему автоответчик (в этом суть и почему он равен нулю.) Итак, внешний контакт не получает автоответчика и не знает, что он должен был, а внутренний пользователь не знает, что внешний контакт его не получил. Проигрыш-проиграл.

Только по трассировке сообщений вы обнаружите проблему:

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 почтовых серверов - any.mail.company.com, это не проблема, поскольку aspf = r в записи DMARC позволит поддомену пройти выравнивание; Однако, поскольку идентификатор HELO / EHLO является доменом * .Microsoft, а не * .company.com, выравнивание всегда не удастся.

Есть ли способ преодолеть это ограничение? Какое-то исключение или флаг политики? Я не думаю, что использование правила для отправки автоматических ответов или правила транспорта; Это обходные пути, и пользователи неизбежно забудут / проигнорируют обмен сообщениями и в любом случае установят автоматические ответы.