O uso de SOFTFAIL sobre FAIL no registro SPF é considerado uma prática recomendada?

31

Ou, dito de outra maneira, o uso v=spf1 a mx ~allrecomendado é sobre o uso v=spf1 a mx -all? O RFC não parece fazer nenhuma recomendação. Minha preferência sempre foi usar FAIL, o que faz com que os problemas se tornem aparentes imediatamente. Acho que, com SOFTFAIL, os registros SPF configurados incorretamente podem persistir indefinidamente, pois ninguém percebe.

Todos os exemplos que eu vi online, no entanto, parecem usar o SOFTFAIL. O que me fez questionar minha escolha foi quando vi as instruções do Google Apps para configurar o SPF:

Crie um registro TXT contendo este texto: v = spf1 include: _spf.google.com ~ all

A publicação de um registro SPF que usa -all em vez de ~ all pode resultar em problemas de entrega. Consulte os intervalos de endereços IP do Google para obter detalhes sobre os endereços dos servidores de correio do Google Apps.

Os exemplos estão sendo excessivamente cautelosos ao pressionar o uso de SOFTFAIL? Existem boas razões para tornar o uso do SOFTFAIL uma prática recomendada?

email spf

— Michael Kropat
fonte

Você pode achar isso en.wikipedia.org/wiki/… útil.

— Pacerier 23/07

21

Bem, certamente não era a intenção da especificação que ela fosse usada - o softfail é um mecanismo de transição, no qual você pode marcar as mensagens sem rejeitá-las completamente.

Como você descobriu, a falta de mensagens diretas tende a causar problemas; alguns serviços legítimos, por exemplo, falsificam os endereços de seu domínio para enviar e-mails em nome de seus usuários.

Por esse motivo, a falha macia menos draconiana é recomendada em muitos casos, como uma maneira menos dolorosa de ainda obter muita ajuda que o SPF oferece, sem algumas dores de cabeça; os filtros de spam do destinatário ainda podem considerar o softfail como uma forte dica de que uma mensagem pode ser spam (o que muitos fazem).

Se você está confiante de que nenhuma mensagem deve vir de um nó diferente do que você especificou, use a falha como o padrão SPF pretendido .. mas, como você observou, o softfail definitivamente cresceu além do pretendido. usar.

— Shane Madden
fonte

2

Portanto, a menos que eu tenha circunstâncias específicas que exijam o uso de SOFTFAIL, é seguro permanecer com FAIL. Impressionante. Obrigado.

— Michael Kropat 02/02/12

11

@ Shane, em relação a "alguns serviços legítimos falsificarão os endereços do seu domínio" (parágrafo 2), a que exemplos você se referiu?

— Pacerier 23/07

11

Falsificar o cabeçalho de: está bom. Nenhum serviço legítimo falsificará o envelope - From, que é o único remetente sobre o qual o SPF tem algo a dizer - nenhum outro servidor na Internet tem negócios enviando e-mail enquanto direciona rejeições para mim, sendo essa a função formal do envelope - From .

— MadHatter apoia Monica

7

-todos sempre devem ser usados SEM EXCEÇÃO. Para não usá-lo, você está se abrindo para alguém que falsifica seu nome de domínio. O Gmail, por exemplo, tem um ~ all. Spammers spoof gmail.com abordam o tempo todo. O padrão diz que devemos aceitar e-mails deles por causa de ~ tudo. Pessoalmente, não sigo o padrão, porque percebi que a maioria de vocês configurou seus registros SPF incorretamente. Eu imponho ~ tudo, tudo, exatamente como eu faria - tudo. Erros de sintaxe SPF SPF

— sol da meia Noite
fonte

5

Eu apóio essa opinião. Para mim, o único motivo do Softfail são os testes. Se você mantiver seu registro SPF atualizado, não há razão para usar um softfail. Caso contrário, não há razão para o SPF. Não acho que nenhum serviço legítimo falsifique o email como proveniente do seu domínio.

— Tim

Eu desafiaria isso: porque depende. Se todos que usam esse domínio conhecem as implicações, isso é absolutamente aceitável. Mas não se esqueça: as mensagens dos formulários de contato do site podem se perder sem que ninguém perceba. Geralmente, essas mensagens são configuradas para encaminhar sua mensagem por e-mail em seu nome. MAS, se você estiver configurando e-mails para outra pessoa, não faça isso. Eles não sabem que os formulários de contatos não estão sendo processados e isso os impede de configurar o endereço de email como um alias conveniente em algum outro provedor, como o gmail.

— Wedi

5

No meu entendimento, o Google depende não apenas do SPF, mas também do DKIM e, finalmente, do DMARC para avaliar e-mails. O DMARC leva em consideração a assinatura SPF e DKIM. Se um deles for válido, o Gmail aceitará o email, mas se ambos falharem (ou falha eletrônica), isso será uma indicação clara de que o email pode ser fraudulento.

Isto é das páginas DMARC do Google :

Uma mensagem deve falhar nas verificações SPF e DKIM para também falhar no DMARC. Uma falha de verificação única usando qualquer uma das tecnologias permite que a mensagem passe no DMARC.

Por isso, acho que seria recomendável usar o SPF no modo de falha suave para permitir que ele entrasse no algoritmo maior de análise de email.

— darwin
fonte

11

Muito interessante, embora eu não veja como a conclusão segue das premissas. Se o DMARC pode passar com um SPF FAIL ou um SPF SOFTFAIL, o que importa qual você escolher?

— Michael Kropat 18/03/2015

4

Acho que se você definir o registro SPF como FAIL, ele nem chegará à avaliação do DMARC ... mas posso estar enganado. As especificações não são claras sobre isso ...

— darwin

falha no SPF do anúncio versus SoftFail: a) é importante para aqueles sem o DMARC implementado b) mesmo quando o DMARC passa com falha no SPF sozinho, pode ser um motivo para marcar sua mensagem como spam, enquanto o SoftFail não seria o caso. par.

— Vlastimil Ovčáčík

A falha no SPF do anúncio impede a avaliação do DMARC : se implementado, o DMARC é sempre avaliado porque a) se o SPF e / ou o DKIM passam, o DMARC precisa verificar o alinhamento b) se ambos falham, o DMARC precisa atualizar as estatísticas do relatório de falhas.

— Vlastimil Ovčáčík

1

Talvez o motivo pelo qual o softfail ainda seja usado seja o fato de muitos usuários (com ou sem razão) configurarem o encaminhamento, talvez do email de trabalho para casa, isso seria rejeitado se o hardfail estivesse ativado

— Jon Redwood
fonte

2

Se eles fizerem isso contra o conselho dos administradores de correio, eles merecem que seus emails falhem.

— MadHatter suporta Monica 06/06

11

Os e-mails encaminhados pelo @MadHatter têm seu remetente de envelope preservado; portanto, o registro SPF da origem seria verificado (e provavelmente falhará) e não o registro SPF do empregador. Se o servidor de correio do empregador atualizar o remetente do envelope, ele será atualizado para um valor que não falhará, pois não haveria diferença entre o correio de saída encaminhado e o normal (no que diz respeito ao SPF).

— Vlastimil Ovčáčík

11

@ VlastimilOvčáčík você está certo, ou, de outra forma, se você encaminhar com o SRS, ficará bem. Caso contrário, não será possível, e evitar -allsimplesmente ajudar as configurações de encaminhamento quebradas (ou seja, não SRS) de outras pessoas não é uma boa ideia.

— MadHatter apoia Monica