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

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

Недавно я получил сообщения от моего почтового демона Postfix с заголовками [email protected]. Эти письма не прошли тесты 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 <[email protected]>
    (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 [email protected]) 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 [email protected]) [email protected];
   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 <[email protected]>

email spf dmarc postfix-mta
person John Doe    schedule 30.10.2018    source источник

Ответы (2)


arrow_upward
0
arrow_downward

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

person Reinto    schedule 10.01.2019

arrow_upward
2
arrow_downward

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

person Synchro    schedule 30.10.2018