Por que os controles do SPF parecem inúteis?

Question

Eu configurei um registro SPF para um domínio, mas a falsificação do remetente ainda funciona, o motivo é bastante simples:

Parece que existem 3 vários "de" em e-mail:

• Responder a
• caminho de retorno
• Envelope de

Veja link para mais informações

Seu cliente de e-mail está exibindo reply to como e-mail do remetente, mas os servidores de e-mail parecem fazer verificações de SPF em relação a return path ou envelope from , o que não faz sentido para mim.

Isso significa que, se eu enviar um email informando que return path e envelope from são hacker.net e reply to é [email protected] , o que estou tentando falsificar, ele verificará o SPF de hacker.net , agora suponha que era o meu domínio para o qual eu configurei o SPF, ele seria transmitido e enviado para a caixa de correio da vítima como [email protected] , mesmo que eu não tenha permissão para enviar e-mails para victim.org , ignorando efetivamente a verificação de SPF. / p>

Existe uma maneira de corrigir isso? Parece que somente DMARC é capaz de evitar isso, mas se isso for verdade, qual é o objetivo dos testes de SPF?

    

Answer 1

Apenas para completar sua lista de vários valores "De", eu adicionaria:

• From , que é o cabeçalho definido pelo cliente e definido no RFC 5322 ( RFC 5322.From )
• Reply to , também é um cabeçalho definido pelo cliente e definido no RFC 5322
• Return path e Envelope from referem-se ao argumento do comando MAIL FROM durante a sessão SMTP ( RFC 5321.MailFrom )

O objetivo do DMARC é transmitir a política para aplicar a mensagens que falham tanto no SPF quanto no DKIM, em vez de confiar nas políticas locais. Esta política é expressa pelo proprietário do nome de domínio do remetente (usando o parâmetro p= do registro DMARC).

Durante a avaliação do DMARC, há uma verificação Alinhamento do identificador (consulte a RFC 7489 Seção 3.1) que garante que:

• o nome de domínio do RFC 5321.MailFrom do SPF transmitido corresponde ao domínio do RFC 5322.From
• o nome de domínio usado no DKIM transmitido corresponde ao domínio do RFC 5322.From

Para corrigir o problema, você deve publicar um registro DMARC na zona victim.org DNS:

_dmarc.victim.org IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]"

Isso garantirá que um alinhamento de identificador com falha, como em seu exemplo, leve a uma falha no DMARC e a mensagem seja sinalizada como spam.

O ponto da verificação de SPF é garantir que o endereço IP do cliente durante a sessão SMTP seja permitido pelo proprietário de hacker.net . No seu exemplo, o SPF está aqui para proteger hacker.net not victim.org : -)

Se você quer uma visão de olho de pássaro, eu publiquei um post com uma ilustração de como SPF, DKIM e DMARC trabalham juntos para prevenir spear-phishing (vá até o meio do post)