Я пытаюсь понять, почему поддельная электронная почта доставляется основным поставщикам услуг электронной почты (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:
include:.~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) ненадежны при проверке адресов отправителя. Есть ряд случаев, когда отклонение такой почты было бы неуместным, в том числе:
У меня довольно маленький сервер, на котором я могу отложить отказ в случае серьезных сбоев. Это позволяет мне занести в белый список допустимых ошибок. Если отправитель замечает, что почта не доставляется, он может исправить свою конфигурацию. В некоторых случаях я попытаюсь связаться с соответствующим postmaster, но многие домены не имеют postmaster адрес.
Пользователи, которые хотят применить более строгую политику, могут использовать DMARC, который еще не стал стандартом. Почта по-прежнему будет доставлена, но может быть помещена в карантин или отклонена, как указано в этой политике. Почта, которая не соответствует политике, может быть доставлена в папку для спама, а не в обычный почтовый ящик.
Жесткие сбои SPF кажутся надежными для проверки подлинности отправляющего сервера. Некоторое время назад я провел некоторое исследование и обнаружил, что даже мягкие сбои для имени HELO являются разумной причиной сбоя или задержки входящих сообщений.
Многие почтовые серверы не имеют записи SPF. Если на почтовом сервере нет записи SPF, я проверяю наличие записи SPF в родительском домене. Это нестандартно, но эффективно. Я рекомендую администраторам электронной почты обеспечить наличие записи SPF для IP-адресов серверов, указанных в записи PTR. Ваш сервер также должен идентифицировать себя по имени, возвращаемому его записью PTR. Убедитесь, что у вас есть соответствующая запись A для обратной проверки DNS.