Почему электронная почта доставляется, как правило, несмотря в SPF «hardfail»?

Я пытаюсь выяснить, почему поддельная электронная почта доставляется основным поставщикам электронной почты (gmail.com, outlook.com), даже если электронная почта помечена SPF hardfail. Электронная почта также доставляется в Microsoft Exchange, который выбрасывает PermErrorдля той же записи SPF.

Я отправляю электронную почту, используя домен SOME_DOMAIN.com, который определяет поврежденную запись SPF. Электронная почта передается с моего собственного IP-адреса, который явно не указан в записи SPF SOME_DOMAIN.com. Запись SPF для SOME_DOMAIN.com имеет следующие три свойства, первые два являются нарушением SPF RFC-4408:

1. Требуется более 10 DNS-запросов для разрешения всей записи SPF include:.
2. Синтаксическая ошибка в одной из записей SPF, python-spf выдает ошибку разбора.
3. Запись SPF содержит как правила, так ~allи -allоба, говорящие о том, что набор всех адресов должен softfailиhardfail

В электронном письме, отправленном на адрес outlook.com, имитирующем admin@SOME_DOMAIN.com, в заголовке SMTP доставленного электронного письма будет указана следующая ошибка. Это сообщение было доставлено в почтовый ящик пользователя в обычном режиме :

Received-SPF: PermError (: domain of SOME_DOMAIN.com used an invalid SPF mechanism)

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

spf=hardfail (google.com: domain of admin@SOME_DOMAIN.COM does not designate x.x.x.x as permitted sender) smtp.mail=admin@SOME_DOMAIN.COM

и так, что здесь происходит? Почему электронная почта доставляется несмотря на SPF hardfail? Означает ли наличие поврежденной записи SPF, что другие SMTP-серверы полностью игнорируют SPF? Или я что-то здесь упускаю ...

SPF настолько плохо настроен на многих сайтах, что получающие MTA часто считаются hardfailтолько рекомендательными и просто учитывают его в своих оценках обнаружения спама. В конце концов, это зависит от администратора MTA, как будут обрабатываться сбои SPF.

Условия ошибки SPF ничего не указывают на желаемую политику. Как таковые, они не дают никаких указаний относительно того, принимать или не принимать сообщение. Возможно, что предполагаемая политика есть +all. В этом случае принято принимать почту. Похоже, что Google снисходительно относится к тому, что эти домены не соответствуют стандарту.

Даже отклонения политики SPF ( -all) ненадежны при проверке адресов отправителей. Есть ряд случаев, когда отказ от такой почты был бы неуместным, включая:

• Почта, отправленная заказчиками по почте (Эти люди получают деньги за нарушение политики.);
• Почта отправляется с веб-форм и других подобных автоматизированных систем;
• Почта, пересылаемая списками рассылки или другими механизмами пересылки; а также
• Просто неверная конфигурация записей SPF (не часто, но не достаточно редко).

Я использую довольно маленький сервер, на котором могу откладывать отказы. Это позволяет мне занести в белый список законные ошибки. Если отправитель замечает, что почта не доставлена, он может исправить свою конфигурацию. В некоторых случаях я буду пытаться связаться с соответствующими postmaster, но у многих доменов нет postmasterадреса.

Пользователи, которые хотят применять более строгую политику, могут использовать DMARC, который еще не является стандартом. Почта все еще может быть доставлена, но может быть помещена в карантин или отклонена, как указано в этой политике. Почта, которая не соответствует политике, может доставляться в папку со спамом, а не в обычную папку «Входящие».

Кажется, что сбои SPF надежны для проверки личности отправляющего сервера. Некоторое время назад я провел некоторое исследование и обнаружил, что даже программные сбои в имени HELO являются разумной причиной для отказа или откладывания входящих сообщений.

Многие почтовые серверы не имеют записи SPF. Если почтовый сервер не имеет записи SPF, я проверяю запись родительского домена на наличие SPF. Это нестандартно, но эффективно. Я рекомендую администраторам электронной почты обеспечить наличие записи SPF для IP-адреса серверов, как указано в записи PTR. Ваш сервер также должен идентифицировать себя по имени, возвращенному его PTR-записью. Убедитесь, что у вас есть соответствующая запись для обратной проверки DNS.