EDIÇÃO FINAL: Eu estava completamente errado sobre o DKIM, parece que o domínio de assinatura não precisa ser o mesmo que o domínio do remetente, portanto, toda a premissa da minha pergunta é falha. Muito obrigado a Paul por apontar meu erro!
Pergunta original abaixo:
Tentei ler sobre SPF e DKIM, mas não entendo o objetivo de usar os dois ao mesmo tempo, pelo menos no contexto de combate ao spam (endereços de remetente forjados, que podem resultar em meu servidor/domínio de e-mail na lista negra ). Tanto quanto eu posso entender, o DKIM sozinho deve fazer o trabalho que o SPF deveria fazer.
Meu entendimento até agora é o seguinte:
- Ao enviar um e-mail, o remetente pode reivindicar o que quiser (por exemplo, endereço de remetente falso)
- O DKIM permite detectar um endereço de e-mail de remetente falso, pois você pode verificar a assinatura DKIM em relação à chave pública no registro TXT do DNS.
- O SPF permite verificar se o email foi enviado de um servidor de email autorizado a enviar emails para um determinado endereço de remetente.
O que eu não entendo é o seguinte: a menos que a chave privada DKIM tenha sido comprometida de alguma forma, a verificação DKIM por si só deve ser suficiente para verificar se o email foi enviado de um servidor de email autorizado, porque, caso contrário, o servidor de email não teria a chave privada para assinar o e-mail.
Eu vi a resposta para uma pergunta muito semelhante aqui: https://serverfault.com/a/780248/154775 , nele o autor afirma que o DKIM não pode impedir ataques de repetição. Eu vou admitir esse ponto, mas acho que é um caso de canto, o maior problema na minha opinião é o spam com endereços de remetentes falsos - o DKIM deve evitar isso facilmente por conta própria.
Existe um cenário além dos ataques de repetição em que o SPF fornece proteção adicional em comparação com apenas o DKIM?
EDIT: Eu marquei o núcleo da minha pergunta em negrito para esclarecer o que exatamente eu quero uma resposta.
O SPF e o DKIM protegem coisas completamente diferentes: o SPF protege o remetente do envelope , enquanto o DKIM protege a integridade e a autenticidade dos cabeçalhos e do corpo do e-mail. Além disso, o DKIM só pode validar uma assinatura existente, mas não possui um método para dizer se uma mensagem sem assinatura deve ser aceita ou não. Portanto, o DMARC também é necessário, além do SPF e do DKIM.
Além disso, nenhum desses métodos é para combater o problema de spam, mas contra falsificações de e-mail. Tenha em mente que os spammers também podem configurá-los. Mas sem DMARC, DKIM e SPF eles são livres para usar seu domínio para seus propósitos.
Embora a resposta de Esa Jokinen esteja certa, acho a linguagem confusa.
Simplificando:
DKIM é aprovação/reprovação criptográfica e se uma assinatura for adicionada ao conteúdo por um servidor de e-mail pode quebrá-lo (e pode ser tão inocente quanto um servidor ou retransmissão adicionando retornos de carro adicionais), há várias alternâncias para simples vs relaxado (para cobrir modificações comuns), onde algumas modificações são permitidas, mas à custa de enfraquecer a proteção. No geral, acho o DKIM muito complexo e muito fácil para que os e-mails se percam acidentalmente.
O SPF eu acho que é bastante fácil de configurar em comparação e requer menos depuração, desde que você não altere os endereços dos servidores de e-mail com frequência. Você também pode especificar para tratar os servidores não listados com mais cautela no SPF (uma “falha suave”), o que dará mais credibilidade àqueles que correspondem à lista sem penalizar aqueles que não o fizerem com muita severidade.
DKIM é fácil de errar. Recebi alguns e-mails legítimos que chegaram à minha pasta de spam, pois o DKIM não foi verificado corretamente (como mostrado nos cabeçalhos e no log do meu servidor de e-mail). No entanto, dá mais credibilidade às suas mensagens.
Em suma, o DKIM pode ser útil quando você não tem idéia de quais são os endereços de retransmissão do servidor de e-mail e/ou eles mudam com frequência e você só deseja fornecer a chave de assinatura para um aplicativo em um host em algum lugar para enviar e-mails do seu endereço de domínio em seu nome .
Servidores de verificação de spam que atribuem pontos e limites para resolver spam/não spam normalmente concederão pontos adicionais a uma mensagem que seja aprovada em SPF e DKIM. Literalmente você ganha pontos de bônus por fazer as duas coisas.
Veja também: SPF vs. DKIM - Os casos de uso exatos e diferenças
Acho que uma das razões pelas quais isso é difícil de responder satisfatoriamente é porque seu argumento central parece ser baseado em uma situação teórica ideal, não no mundo real.
Em princípio, o DKIM não é suficiente? Sim, claro, se seu DKIM sempre funcionar e nenhum servidor de e-mail reescrever seu e-mail de uma maneira que quebre sua assinatura DKIM, se você não se importar com o reenvio de seus e-mails e se todos os seus destinatários em potencial também implementarem a verificação DKIM , então o DKIM seria, em princípio, suficiente para você. (Você provavelmente ainda precisará adicionar uma política DMARC para fazer com que o destinatário rejeite e-mails que não tenham uma assinatura DKIM.)
Mas então, as pessoas ainda precisam se preocupar com o FPS? Sim, por razões práticas, eles fazem. O SPF e o DKIM são padrões amplamente independentes, mas o SPF sempre foi mais fácil de implementar do que o DKIM, e muitos administradores parecem estar satisfeitos apenas em usá-lo. Portanto, ainda não há cobertura universal para DKIM. Assim, se o seu servidor de e-mail não tiver registros SPF, as chances são maiores de que alguém possa enviar spam a destinatários que tenham apenas SPF falsificando seu domínio. E assim, as chances também serão maiores de que seus próprios e-mails legítimos possam ser sinalizados como spam por esses mesmos destinatários.
Com apenas DKIM, não há como um servidor de recebimento saber onde encontrar a chave DKIM para seu domínio porque a assinatura do e-mail é o que inclui o local do registro DNS do seletor, que é atribuído por cada administrador do servidor de e-mail. Portanto, os servidores de e-mail que recebem e-mails de outros servidores não poderão usar isso para avaliar uma mensagem.
Se você tem example.com e configurou o DKIM e nada mais, e eu envio um e-mail do meu servidor, que é example.net, mas meu servidor "falsifica" o e-mail para ser de example.com, e eu configurei um registro DKIM para example.net, o e-mail passará nos testes DKIM e os servidores de recebimento terão mais dificuldade em determinar que a mensagem não é de um servidor aprovado pelos proprietários de example.com. Isso ocorre porque o teste DKIM é realizado usando os registros do servidor de envio para verificar a integridade do email , nada mais.
A verificação é realizada usando informações na assinatura de e-mail. Em outras palavras, o início do teste DKIM é o próprio e-mail, que inclui a localização da chave pública DKIM para o servidor de envio . O padrão DKIM serve apenas para validar a integridade do email enviado por um servidor, portanto, o domínio do servidor não precisa ter nada a ver com outras informações de cabeçalho, como
smtp.mailfrom
. É por isso que posso "falsificar" example.com e passar em um teste DKIM usando a chave para example.netÉ por isso que todos aqui estão afirmando que o DKIM serve apenas para a integridade da mensagem, não para a validação do remetente aprovado. O DKIM só pode ser usado como uma "prova de trabalho" em relação à prevenção de spam, a menos que seja usado junto com o DMARC com SPF configurado porque ninguém sabe onde a chave está localizada para seu domínio.
Não há absolutamente nenhuma maneira de evitar spam usando autenticação de domínio ou remetente. Nenhuma dessas técnicas foi projetada para combater o spam, mas elas podem ajudar .
DKIM, DMARC e SPF protegem os destinatários contra falsificação de e-mail ou falsificação de remetente (ponto 1). Isso é particularmente importante para combater mais o phishing do que o spam , no que diz respeito ao significado e à utilização das palavras. Ou seja, o spam geralmente é inofensivo e apenas assediador.
Phishing e spearphishing são intrinsecamente maliciosos e, sem DKIM, podem alavancar a relação de confiança com o endereço do remetente. Isso é especialmente verdadeiro quando os criminosos cibernéticos desejam enviar uma fatura falsa para um cliente de uma empresa alterando o código IBAN/SWIFT para um não autorizado.
Para e-mails comerciais volumosos, essas tecnologias não fornecem absolutamente nenhuma ajuda. Posso comprar, mesmo a granel, um grande número de novos nomes de domínio de gravação e usar um pouco de automação de DevOps para configurar SPF, DKIM, DMARC e começar a enviar grandes campanhas de spam de um endereço de remetente que é inevitavelmente desconhecido. Eu encontro isso todos os dias na minha caixa de entrada de spam (se alguém pedir provas, posso colar alguns cabeçalhos nesta resposta).
Como outro contra-exemplo relacionado ao phishing. Se um phisher quiser atacar os clientes do banco ACME (
acme.com
), ele não pode enviar e-mails que realmente pareçam ser de[email protected]
, mas pode comprar (porque enviaram!!)acme-confirm-credentials.com
e enviar e-mails.Um destinatário instruído perceberá que o e-mail não vem do oficial
acme.com
e se tornará suspeito, apesar de que se deve suspeitar no próprio pedido de "confirmação de credencial".