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

[Danton Nunes]

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.