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

[Danton Nunes]

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.