SPF vs. DKIM - Os casos de uso e diferenças exatos


20

Sinto muito pelo título vago. Não entendo completamente por que o SPF e o DKIM devem ser usados ​​juntos.

Primeiro: o SPF pode passar para onde deve falhar se o remetente ou o DNS for "falsificado" e pode falhar para onde deve passar se estiver envolvida alguma configuração avançada de proxies e encaminhadores.

O DKIM pode passar para onde deveria falhar, devido a um erro / fraqueza na criptografia (excluímos isso, daí o ponto simplificado) ou porque a consulta DNS é falsificada.

Como o erro de criptografia é descartado, a diferença (a meu ver) é que o DKIM pode ser usado em configurações nas quais o SPF falharia. Não consigo encontrar exemplos em que alguém se beneficiaria com os dois. Se a configuração permitir o SPF, o DIKM não deverá adicionar nenhuma validação extra.

Alguém pode me dar um exemplo do benefício de usar os dois?

Respostas:


15

O SPF tem muito mais classificações que Aprovado / Reprovado. Utilizá-los na classificação heurística de spam torna o processo mais fácil e preciso. Falha na conta de "configurações avançadas" indica que o administrador de email não sabia o que estava fazendo na configuração do registro SPF. Não há nenhuma configuração que o SPF não consiga explicar corretamente.

A criptografia nunca funciona em absolutos. A única criptografia permitida no DKIM geralmente leva recursos significativos para quebrar. A maioria das pessoas considera isso seguro o suficiente. Todos devem avaliar suas próprias situações. Novamente, o DKIM tem mais classificações do que apenas Aprovado / Reprovado.

Um exemplo em que um se beneficiaria do uso de ambos: enviar para duas partes diferentes, onde um verifica o SPF e o outro verifica o DKIM. Outro exemplo, o envio a uma parte com conteúdo que normalmente seria altamente classificado no teste de spam, mas que é compensado pelo DKIM e pelo SPF, permitindo que o email seja entregue.

Na maioria dos casos, eles também não são necessários, embora os administradores de email individuais definam suas próprias regras. Ambos ajudam a lidar com diferentes facetas do SPAM: o SPF é quem está retransmitindo o email e o DKIM é a integridade do email e a autenticidade de origem.


Ok, eu sigo seus pontos (especialmente que alguns podem simplesmente usar apenas um dos dois - como eu não vi isso!). Portanto, o SPF e o DKIM podem ter configurações e classificações diferentes, mas, no geral, são para faces da mesma moeda. Até o seu último ponto: Um email de uma retransmissão autorizada (SPF) deve ser confiável tanto quanto uma assinatura DKIM válida. Afinal, o proprietário do domínio aprovou os dois. Acabei de testar meu e-mail apenas com SPF e, embora minha universidade e o gmail pareçam aceitá-lo, o hotmail o considera spam - talvez porque eles confiam no DIKM. Obrigado pelo seu comentário Chris!
usuário excluído 42

O Hotmail usa SenderID (SPF 2.0, por assim dizer), DKIM, SenderScore, PBLs e sua própria tecnologia de filtragem. Eles são um pouco secretos sobre a fórmula exata.
Chris S

18

Isso foi respondido há algum tempo, mas acho que a resposta aceita não tem o ponto de por que ambos devem ser usados ​​juntos para serem eficazes.

O SPF verifica o IP do último salto do servidor SMTP em uma lista autorizada. O DKIM valida o email inicialmente enviado por um determinado domínio e garante sua integridade.

Mensagens assinadas DKIM válidas podem ser usadas como spam ou phishing, sendo reenviadas sem modificações. O SPF não verifica a integridade da mensagem.

Imagine um cenário em que você receba um e-mail assinado DKIM válido (do seu banco, um amigo, qualquer que seja) e encontre uma boa maneira de explorar esse e-mail sem modificações: basta reenviar esse e-mail milhares de vezes para pessoas diferentes. Como não há modificação no email, a assinatura DKIM ainda será válida e a mensagem passará como legítima.

De qualquer forma, o SPF verifica a origem (IP / DNS real do servidor SMTP) do e-mail, portanto o SPF impedirá o encaminhamento do e-mail, pois você não poderá reenviar um e-mail válido por um servidor SMTP bem configurado e os e-mails provenientes de outros IPs serão rejeitado, impedindo efetivamente o reenvio de mensagens DKIM "válidas" como spam.


Você poderia dar alguns exemplos de como o correio pode ser explorado sem modificações?
user3413723

Qualquer e-mail começando com um "Caro cliente", "Caro usuário" ou "Caro <primeira parte do seu endereço de e-mail antes do sinal @">. É por isso que é importante que os emails legítimos para você sempre contenham pelo menos 1 parte de suas informações pessoais, como parte de sua postagem / código postal ou seu nome completo. (Isso torna-os mais autêntico e não reutilizáveis.)
Adambean

Mas se os campos do cabeçalho foram assinados, incluindo os destinatários, certamente isso remove a possibilidade de um ataque de repetição contra novos destinatários? ou seja, adicionar assinaturas h=from:to;( de ser exigido no RFC 6376 , para ser opcional) deve permitir apenas ataques de repetição no mesmo destinatário. O que é ruim, mas não tão ruim quanto o que esta resposta está sugerindo.
Richard Dunn

4

Aqui estão algumas razões que você deve sempre publicar tanto SPF e DKIM.

  1. Alguns provedores de caixa de correio suportam apenas um ou outro e outros suportam ambos, mas pesam mais que o outro.

  2. O DKIM protege o email contra alterações no trânsito, o SPF não.

Eu adicionaria DMARC à lista também. Qual é a desvantagem de publicar sempre a autenticação completa de e-mail?


11
"Qual é a desvantagem de publicar sempre a autenticação completa de e-mail?", Esforço! Eu acho que Devops já é um PITA, o que é outro tijolo na parede, ou 3, conforme o caso.
Gordon Wrigley

O que o ISP tem a ver com alguma coisa? Você quer dizer provedor de correio?
William

Sim, eu quis dizer provedor de caixa de correio. As pessoas costumavam obter serviços de e-mail dos provedores, então eu tinha o hábito de dizer ISP.
Neil Anuskiewicz 12/12

Obrigado por apontar isso, pois agora eu o alterei para o provedor de caixa de correio.
Neil Anuskiewicz 12/12
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.