Os e-mails configurados com curinga permitem que os spammers entreguem e-mails? (SPF: “softfail”)

Question

Eu tenho uma conta do Google Apps configurada para um dos meus domínios. A entrega de e-mail com caractere curinga é ativada neste domínio para todos os e-mails (ou seja, qualquer coisa@domínio.com passa e-mails para myemail@domínio.com) e os registros relacionados à entrega de e-mail são configurados da seguinte maneira (segundo o meu conhecimento, configurado às recomendações do Google):

MX: ASPMX.L.GOOGLE.COM with priority 10
TXT: v=spf1 include:_spf.google.com ~all
TXT: v=DKIM1; k=rsa; p=xxxxxxxxxxxxxxxxxxxxxxxxx

Recentemente, no entanto, comecei a receber um número maior de e-mails de rejeição / "fora do escritório" de pessoas que aparentemente estão sendo spam de pessoas que usam endereços de e-mail do meu domínio. Dos saltos, alguns cabeçalhos:

Return-Path: <[email protected]>
Received-SPF: softfail (google.com: domain of transitioning 
    [email protected] does not designate 41.230.231.130
    as permitted sender) client-ip=41.230.231.130;
Authentication-Results: gmr-mx.google.com; spf=softfail (google.com:
    domain of transitioning [email protected] does not designate
    41.230.231.130 as permitted sender) [email protected]
From: "Secure.Message" <[email protected]>
To: <[email protected]>

(posso fornecer cabeçalhos adicionais, se necessário.)

Eu olhei para softfails, mas não tenho certeza se entendi. Eu faço e-mails com curinga no domínio, portanto, simplesmente desabilitar o curinging provavelmente não seria uma solução. Como os e-mails desse domínio são encaminhados para um endereço de e-mail diferente (também no Google Apps, no entanto), eu também preferencialmente precisaria poder enviar e-mails usando o recurso "enviar e-mail como" do Google ("em nome de").

Alguma ideia do que fazer agora? Mais importante, estou preocupado com a reputação do meu domínio; Eu gostaria muito de mantê-lo fora de qualquer lista de spam.

    

Answer 1

Quando você usa o SoftFail qualifier (o ~ ) em um mecanismo SPF, você indica que um remetente correspondente deve ser tratado com suspeita , mas não totalmente rejeitado.

O Fail qualificador (o - ), por outro lado, incentiva o recebimento de MTAs para rejeitar a transferência SMTP imediatamente com um DSN 5.1.7.

Então, quando você está usando ~all no final do seu registro, você está apenas parcialmente impedindo que os spammers abusem do seu domínio e da sua reputação.

Leia mais sobre como os resultados do check_host () devem ser tratados de acordo com a Especificação da RFC aqui: IETF RFC 4408 §2.5 "Interpretando os resultados"

    

Answer 2

Além do que Mathias disse (o que é bom), note que a palavra-chave incentiva em sua segunda sentença: "O qualificador de falha ... incentiva o recebimento de MTAs para rejeitar o email".

Também recomendo investigar o DMARC . Uma vez que você tem os registros SPF e DKIM no lugar, o que parece que você faz, DMARC é uma forma de dizer aos servidores de recebimento de mensagens o que fazer com o email que falha ambos o teste SPF e DKIM. / p>

Quando um e-mail falha nesses testes, E um recebedor do MTA homenageia registros do DMARC, você pode controlar o que eles fazem com esse e-mail: rejeite-o imediatamente, marque-o como spam ou entregue-o.

    

Answer 3

Estou exatamente na mesma situação e mudei meus registros SPF para executar uma falha grave. Isso não ajuda. Os administradores dos domínios que enviam os bouncebacks parecem olhar para o registro spf, ver se ele falha e ignorá-lo. Não estou preocupado com a reputação do meu domínio, uma vez que eles continuarão a enviar esses e-mails, estejam ou não aqui para ver os bouncebacks. Não há nada que você possa fazer além de fazer uma regra para ignorar o padrão da resposta ao endereço.