[GTER] uma ideia para discussão: SPF reverso.

[Fernando Ulisses dos Santos]

Danton,

Tenho algumas dúvidas sobre a aplicação dessa técnica nos links atuais 
das grandes operadoras e provedores.

O cliente decide hospedar o e-mail dentro da empresa, tem 1 IP fixo 
(praxe para links xDSL). Hoje o trabalho é só pedir o DNS reverso 
casando com o DNS direto para passar por algumas validações anti-spam.

Com o RSPF, além de pedir pra operadora (já que o cliente não tem poder 
sobre o DNS reverso do único IP dele) o DNS reverso, vai ter que pedir o 
cadastro dos domínios hospedados, o cliente teria que pedir um RSPF assim:

"v=rspf1 +dominio1.com.br +dominio2.com.br +dominio3.com.br -all"

Isso irá gerar dificuldades para lançar novos domínios para e-mail, e 
com o tempo é capaz de pegarem a manha igual no SPF e pedir cadastros assim:

"v=rspf1 +*.com.br +*.br +*.com +*.net -all"

Os quais a operadora de link não tem o direito de negar. Ok, é 
tecnicamente contornável, mas é o mesmo problema que tem no SPF hoje, 
exemplo: "v=spf1 ip4=128.0.0.0/4"

A maior dificuldade seria para grandes provedores de domínios, imagina 
um deles, com milhares de clientes, onde um pool de dezenas servidores 
faz o MTA dos clientes, todos esses servidores deveriam ter o RSPF de 
todos os clientes:
"v=rspf1 +cliente1.com.br +cliente2.com.br +cliente3.com.br ..... 
+cliente1001.com.br -all"

Isso deixaria exposto toda a carteira de clientes do provedor, além de 
que, estouraria o tamanho do campo TXT e geraria dificuldades de 
validação e implementação (alto processamento, rotinas complexas).

Se eu realmente entendi tua proposta de implementação, ela tem esses 
problemas técnicos e comerciais que inviabilizam a utilização em massa, 
por favor, diga que estou errado.

Fernando Ulisses dos Santos

Em 26-07-2012 17:16, Danton Nunes escreveu:

> Esta proposta nasceu dentro de uma discussão na MASOCH-L, mas acho que 
> o GTER é o forum mais pertinente. Se isto mostrar que dá pé poderemos 
> apresentá-la ao IETF como um "draft".
>
> Apresento aqui o "SPF reverso", que espero venha ajudar no combate ao 
> envio não autorizado e frequentemente fraudulento de email.
>
> No SPF clássico é o dono do domínio que diz quais endereços IP podem 
> mandar email em nome do domínio. por exemplo, o meu é assim:
>
> v=spf1 a mx ip4:187.17.47.136 ip4:187.17.37.5 ip4:187.17.38.0/26 
> ip6:2001:12c4:f0da:5e::/64 -all
>
> (é, o endereço IPv6 é essa gracinha mesmo), mas ninguém pergunta para 
> os donos dos endereços se isso é verdade. então se um spammer cria uma 
> lista de SPF cujo default é +all qualquer endereço IP da galáxia 
> internet está autorizado a enviar email em nome desse domínio e a 
> driblar várias ratoeiras antispam. para que o dono dos endereços possa 
> dizer quais domínios podem enviar email a partir deles proponho o SPF 
> reverso.
>
> No SPF reverso o dono do IP diz se esse IP está autorizado a enviar em 
> nome de um dado domínio. Para isso usaria uma cláusula TXT semelhante 
> ao SPF, mas no domínio de tradução reversa (xxx.in-addr.arpa ou 
> xxx.ip6.arpa). Por exemplo, para eu dizer que 187.17.38.5 tem direito 
> de enviar email em nome de inexo.com.br, colocaria um registro TXT 
> assim associado ao nome 5.38.17.187.in-addr.arpa:
>
> v=rspf1 +inexo.com.br -all
>
> poderia ser uma expressão regular ou com coringas, por exemplo:
>
> v=rspf1 +*.inexo.com.br -all
>
> um provedor de acesso para pessoa física poderia por um registro assim 
> para todos os endereços IP da rede de usuários "dialup":
>
> v=rspf1 -all
>
> indicando que NENHUM deles estaria apto a enviar email diretamente. 
> muito melhor que lista negra!
>
> os patifes que tem SPF com +all para fazer com que seus bots possam 
> ganhar 'pass' seriam impedidos, já que o SPF reverso mostraria que o 
> dono do IP não o autorizou a enviar email de lá. (eu conheço 48 
> domínios com +all!)i
>
> a validação de um remetente agora seria feita com duas fontes de dados 
> que podem ser independentes ou não: o dono do domínio e o dono dos 
> endereços IP. A política resultante poderia ser: testamos o SPF e o 
> RSPF, só passa se passar nos dois! mas é claro que ainda sobraria 
> muita margem para falsificação, nada é perfeito.
>
> ATENÇÃO SENHORES PROFESSORES: desenvolver e testar um protocolo destes 
> daria um lindo trabalho de graduação, se futucar mais, até dissertação 
> de mestrado! Aproveitem! Usem o trabalho de seus escra^H^H^Htagiários!
>
> Próximos passos:
> - formalizar o protocolo,
> - escrever uma librspf ou estender a atual libspf2,
> - testar para provar que funciona.
> - escrever a RFC dentro dos padrões do IETF.
> - vender o peixe.
>
> -- Danton.
> -- 
> gter list    https://eng.registro.br/mailman/listinfo/gter