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

Question

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

Недавно я получал сообщения от моего почтового демона Postfix с заголовками smtp.mailfrom=double-bounce@mail.example.com. Эти письма не прошли тесты 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 не удалось Включены важные части моего почтового заголовка ниже.

P.S. 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 <example@gmail.com>
    (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 double-bounce@mail.example.com) 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 double-bounce@mail.example.com) smtp.mailfrom=double-bounce@mail.example.com;
   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 <MAILER-DAEMON@example.com>

Answer 1

Отказов обычно имеют пустой обратный путь (<>), и поэтому результат 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" локальной части (которые могут или могут ранее не проверялось отдельно).

Answer 2

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