Невозможно определить, был ли подделан мой почтовый отчет Postfix Mail Daemon

Question

Я запускаю почтовый сервер с Postfix на Ubuntu 16.04 Droplet на DigitalOcean. Почтовый сервер является (закрытым) SMTP-ретранслятором, который использует почтовые клиентские интерфейсы, такие как Gmail и Hotmail, для отправки электронной почты с моего домена (назовем его example.com). На нем настроены SPF, DKIM и DMARC, поэтому письма от моего домена не помечаются как спам в Hotmail и Gmail.

Я недавно получал сообщения от моего почтового демона Postfix, которые имеют smtp.mailfrom=[e-mail] заголовки. Эти письма не прошли тесты SPF и DMARC.

Возможная причина, по которой эти письма не проходят тесты, может заключаться в том, что мои записи SPF содержат только записи SPF для example.com, Но почему Postfix Mailer Daemon отправляет электронные письма как @mail.example.com вместо @example.com? В Postfix мой myorigin атрибут установлен как example.comи документация говорит, что адрес двойной отказов установлен как double-bounce@$myorigin,

Возможно ли, что эти письма от Mailer Daemon, которые я получаю, являются поддельными? Я хотел бы получить представление о том, почему мои заголовки SPF и DMARC не сработали. Включены важные части моего почтового заголовка ниже.

PS 1.2.3.4 мой IP-адрес почтового сервера и IP-адрес, который был внесен в белый список в моей записи SPF домена.

Received: from mail.example.com ([1.2.3.4])
    by mx.google.com with ESMTPS id r25-v6si17553370pfk.83.2018.10.27.22.06.59
    for <[e-mail]>
    (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
    Sat, 27 Oct 2018 22:06:59 -0700 (PDT)
Received-SPF: neutral (google.com: 1.2.3.4 is neither permitted nor denied by best guess record for domain of [e-mail]) client-ip=1.2.3.4;
Authentication-Results: mx.google.com;
   spf=neutral (google.com: 1.2.3.4 is neither permitted nor denied by best guess record for domain of [e-mail]) smtp.mailfrom=[e-mail];
   dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=example.com
Received: by mail.example.com (Postfix) id 7CDB5120787; Sun, 28 Oct 2018 13:06:58 +0800 (+08)
Date: Sun, 28 Oct 2018 13:06:58 +0800 (+08)
From: Mail Delivery System <[e-mail]>

Answer 1

Это не отправка как mail.example.comэто просто имя хоста, который отправляет сообщение. Как говорят заголовки, он использует это как "лучшее предположение". Имя хоста выглядит так, как будто оно получено в результате обратного просмотра вашего IP-адреса, который должен соответствовать вашему имени хоста SMTP EHLO - так что убедитесь, что это так. Также проверьте, что заголовок обратного пути заканчивается как на приемнике - если вы видите <> там, вы знаете, это настоящие отскоки. Я бы посоветовал проверить трафик на исходящем с вашего почтового сервера, чтобы вы могли быть уверены, что происходит в SMTP.

Answer 2

У отказов обычно есть пустой путь возврата (<>) и поэтому результат SPF возвращается к проверке имени HELO, как описано в разделах 2.3 и 2.4 RFC 7208. Добавление записи SPF для ваших хостов, используемой в идентификаторе HELO, должно изменить результат с "наилучшего предположения" (обычно в случае отсутствия записи) на фактический результат.

Раздел 2.3:

РЕКОМЕНДУЕТСЯ, чтобы SPF-верификаторы не только проверяли "MAIL FROM"
личность, но также отдельно проверить личность "HELO" [...]

и раздел 2.4:

SPF-верификаторы ДОЛЖНЫ проверять идентичность "MAIL FROM", если "HELO" проверяет
либо не было выполнено, либо не достигло определенной политики
результат, применяя функцию check_host() к "MAIL FROM"
идентичность как.

[RFC5321] позволяет обратному пути быть нулевым (см. Раздел 4.5.5 в [RFC5321]). В этом случае нет явного почтового ящика отправителя, и
такое сообщение может быть принято как уведомление от
сама почтовая система. Когда обратный путь равен нулю, этот документ
определяет идентификатор "MAIL FROM" как почтовый ящик, состоящий из
"postmaster" локальной части и идентификация "HELO" (которые могли или не могли быть проверены отдельно ранее).