Estou tentando descobrir por que e-mails forjados estão sendo entregues aos principais provedores de e-mail (gmail.com, outlook.com), embora o e-mail esteja marcado com um SPF hardfail . O email também é entregue ao Microsoft Exchange, que está lançando um PermError para o mesmo registro SPF.
Estou enviando e-mail usando o domínio SOME_DOMAIN.com, que define um registro SPF quebrado. O email é transmitido do meu próprio endereço IP, que não está listado explicitamente no registro SPF de SOME_DOMAIN.com. O registro SPF para SOME_DOMAIN.com tem as três propriedades a seguir, as duas primeiras são uma violação do SPF RFC-4408:
include: . ~all e -all , ambas dizendo que o conjunto de todos os endereços deve softfail e hardfail
O e-mail enviado para um endereço outlook.com representando o admin@SOME_DOMAIN.com conterá o seguinte erro no cabeçalho SMTP do e-mail entregue. Este e-mail foi entregue normalmente à caixa de entrada do usuário :
Received-SPF: PermError (: domain of SOME_DOMAIN.com used an invalid SPF mechanism)
O Gmail também enviará o e-mail para a caixa de entrada do usuário, mas apresentará um erro de SPF diferente:
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
Então, o que está acontecendo aqui? Por que o email está sendo entregue, apesar de um SPF hardfail ? Ter um registro SPF quebrado significa que outros servidores SMTP desconsideram totalmente o SPF? Ou há algo que sinto falta aqui ...
As condições de erro do SPF não indicam nada sobre a política desejada. Como tal, não fornecem orientação quanto a aceitar ou não a mensagem. É possível que a política pretendida seja +all . É normal aceitar email neste caso. Parece que o Google está sendo tolerante com a falha deste domínio em cumprir com o padrão.
Mesmo as rejeições de políticas de SPF ( -all ) não são confiáveis ao validar os endereços dos remetentes. Há vários casos em que rejeitar essas mensagens seria inadequado, incluindo:
Eu corro um servidor relativamente pequeno onde posso adiar uma falha de hardware. Isso me permite listar as falhas legítimas. Se o remetente perceber que o e-mail não foi entregue, ele poderá corrigir sua configuração. Em alguns casos, tentarei entrar em contato com o postmaster relevante, mas muitos domínios não têm um endereço postmaster .
Os usuários que desejam impor uma política mais rígida podem usar o DMARC, que ainda não é um padrão. O correio ainda é provável de ser entregue, mas pode ser colocado em quarentena ou rejeitado conforme especificado nessa política. Mail que falha a política pode ser entregue para a pasta de spam, em vez da caixa de entrada normal.
Falhas no disco rígido do SPF parecem ser confiáveis para validar a identidade do servidor de envio. Eu fiz uma pesquisa há um tempo atrás, e descobri que até mesmo soft failure no nome HELO é uma razão razoável para falhar ou adiar as mensagens recebidas.
Muitos servidores de email não possuem um registro SPF. Se o servidor de email não tiver um registro SPF, eu verifico no domínio pai por um registro SPF. Isso não é padrão, mas é efetivo. Incentivo os administradores de email a garantir que haja um registro SPF para o IP dos servidores, conforme listado no registro PTR. Seu servidor deve se identificar pelo nome retornado por seu registro PTR também. Verifique se você tem um registro A correspondente para verificação reversa de DNS.