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

[Patrick Tracanelli]

Em 15/08/2012, às 16:33, Danton Nunes escreveu:

> Voltando ao assunto, decidi implementar e testar. O texto abaixo servirá de guia da minha implementação mas ainda está muito longe de uma especificação no estilo IETF (mas chegaremos lá).
> 
> Pretendo escrever uma API da forma mais simples possível, em C. Junto com ela um 'milter' que classifica mensagens recebidas de acordo com o RSPF. Se alguém quiser participar dos experimentos será bem vindo.
> 
> No final ainda coloco em discussão alguns pontos que ainda não estão fixos, especialmente em torno do hash.
> 
> --------8<----------------------------------------------------------------
> 
> SPF REVERSO - NOTAS PARA UMA ESPECIFICAÇÃO
> 
> 1. Introdução
> 
> O SPF reverso é um mecanismo baseado em DNS que permite ao responsável por um bloco de endereços IPv4 ou IPv6 designar quais domínios podem enviar e-mail a partir desses IPs.
> 
> No SPF direto ou tradicional o domínio do remetente no envelope ou presente na saudação (HELO/EHLO) provê uma lista dos endereços IP autorizados a enviar. No SPF reverso é o domínio reverso do endereço IP de origem da mensagem que valida o remetente no envelope ou o parâmetro da saudação. Resumidamente, no SPF direto perguntamos ao dono do domínio se o endereço IP é bom, aqui perguntamos ao dono do endereço IP se o domínio é bom.
> 
> Este rascunho serve para orientar experimentos para validar e descobrir furos no protocolo proposto.
> 
> 2. Mecanismo
> 
> À semelhança do SPF serão utilizados registros do tipo TXT dentro do domínio reverso, .in-addr.arpa ou .ip6.arpa.
> 
> O registro TXT conterá dois campos separados por espaço, a saber:
> - identificação do protocolo "rspf/1";
> - resultado, que pode ser 'PASS', 'NEUTRAL' ou 'FAIL'.
> 
> O nome do domínio a ser testado é formado pelos seguintes elementos:
> - Hash do domínio em base 16 (ver adiante como o hash é calculado);
> - endereço IP invertido segundo as convenções de tradução reversa;
> - 'in-addr' ou 'ip6', conforme o caso;
> - 'arpa'.
> 
> Por exemplo, o registro para autorizar e-mails vindos de example.com a partir do endereço IPv4 203.0.113.1 o registro seria:
> 
> 5ababd603b22780302dd8d83498e5172.1.113.0.203.in-addr.arpa in txt "rspf/1 PASS"
> 
> onde 5ababd603b22780302dd8d83498e5172 é o hash MD5 de 'example.com' em hexadecimal e 1.113.0.203 o endereço IP com os octetos reversos.
> 
> 3. Cálculo do hash
> 
> Maiúsculas e minúsculas tem o mesmo valor nos nomes de domínio, mas não no cálculo do MD5, então, antes de calcular o hash todos os caracteres alfabéticos deverão ser convertidos em minúsculas.
> 
> Nomes de domínio internacionalizados devem ser representados em punycode [RFC-3492 e RFC-5891].
> 
> O hash é calculado sobre o nome do domínio sem qualquer terminador de linha.
> 
> O hash é codificado em base 16. É irrelevante se em maiúsculas ou minúsculas, já que os nomes de domínios não são sensitivos ao caso.
> 
> Exemplos:
> 
> example.com -> 5ababd603b22780302dd8d83498e5172
> 
> 老丹童.nom.br -> (punycode) xn--riqy20ichd.nom.br ->
> 	-> 50807287f78ea82a698719357de51805
> 
> NOTA: considerei a possibilidade de codificar o hash em base-32 ou base-64, que certamente resultaria em um componente do domínio mais curto, no entanto ambas as bases usam caracteres que estão fora do conjunto permitido para nomes de domínio e a base-64 distingue maiúsculas de minúsculas, que são confundidas no escopo do DNS.
> 
> 4. Uso de coringas
> 
> Se o servidor de nomes permitir, é permitido usar coringas no lugar do hash para indicar uma política default para TODOS os domínios e para vários nomes reversos de uma zona.
> 
> Um exemplo de aplicação do uso de coringas pode ser para uma rede de acesso de usuários finais (similar a dial-up), em que nenhum endereço está autorizado a enviar e-mail partindo de qualquer domínio. Suponhamos que o bloco 203.0.113.0/24 inteiro esteja nessa situação. O seguinte registro:
> 
> *.113.0.203.in-addr.arpa in txt "rspf/1 FAIL"
> 
> fará com que qualquer associação de domínio com endereços do bloco 203.0.113.0/24 resultem em FAIL, a menos que tenham uma exceção explícita.
> 
> --------8<----------------------------------------------------------------
> 
> Questão do HASH:
> 
> escolhi MD5 um tanto arbitrariamente, me parece um tanto 'over' para esta finalidade. poderia ser um hash mais curto, se bem que quanto mais curto mais o fantasma da possibilidade de colisão assusta.
> 
> por outro lado, há a dúvida, to hash or not to hash? o hash permitiria tratar domínios enormes com até todos os 127 componentes permitidos pela RFC do Mockapetris, enquanto se simplesmente concatenássemos o nome do domínio com o do endereço IP reverso teríamos um limite de 93 componentes (no domínio ip6.arpa, no caso do IPv4 seria menos restritivo). Na prática, duvido que exista um domínio de e-mail com 93 componentes!
> 
> outra questão que ficou em aberto é um mecanismo de delegação para os casos em que o dono dos IPs não controla o domínio reverso, tipicamente quando recebe um bloco de IPv4 menor que /24. houve uma proposta interessante baseada em criptografia de chave pública, mas me pareceu um tanto complicada e resolvi não incorporá-la nesta altura. Estou pensando em alguma abordagem mais ao estilo da BCP-20, para incorporar mais tarde.
> 
> -- Danton.

Danton, você não está prevendo um mesmo IP ou rede entregando diversos domínios no return-path?

Outra coisa, mais que usar ou não usar um hash ou dominio plain, pra que um hash? Voce ja esta usando um RR TXT pra política:

"rspf/1 PASS"

Então, assumindo que o TXT é um RR que não gera problemas de coexistência com PTR, porque não usar tudo no TXT de forma similar ao SPF? Aproveitando e usando o mesmo padrão de versão de informação "arbitrária" ou seja mudando pra:

1.113.0.203.in-addr.arpa IN TXT "v=rspf1 pass:domain1.com pass:domain2.com neutral:domain3.com"
*.113.0.203.in-addr.arpa IN TXT "v=rspf1 :fail "

:POLITICA ou *:POLITICA podem ser sinônimos...

Acho que assim fica mais flexivel e mais humano entender/configurar além de continuar fácil de parsear.

Ainda pode ficar muito trabalhoso para servidores de e-mail que são smtp-out pra muitos dominios (empresas de hosting e afins) então pode ser legal pensar em mecanismos mais flexíveis como co-relacionar o rspf com spf tipo "pass:spf", ...



> --
> gter list    https://eng.registro.br/mailman/listinfo/gter

--
Patrick Tracanelli

FreeBSD Brasil LTDA.
Tel.: (31) 3516-0800
316601 at sip.freebsdbrasil.com.br
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"