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

[Danton Nunes]

On Sat, 4 Aug 2012, Roberto Alcântara wrote:

> Danton,
>
> Mas ele garante isso.
>
> Apenas o detentor do IP possui a chave privada que é o par da pública
> que está no TXT do reverso do IP.
>
> Sendo assim, apenas ele pode assinar as entradas que vão nos TXT dos
> domínios e dar o aval para o envio dos e-mails daquele domínio por
> aquele IP.

mas qual é a vantagem disso em relação a pedir para o detentor do IP 
inserir um registro no .in-addr.arpa ou .ip6.arpa? operacionalmente é a 
mesma coisa.

para evitar que o cliente de acesso que tem bloco menor que /24 tenha que 
implorar alguma coisa para seu provedor a cada domínio que habilite a 
enviar email é o cliente criar seu par de chaves, entregar a pública para 
seu provedor publicá-la no domínio reverso, e assinar tantos registros de 
domínios que quiser, sem ter que implorar pela assinatura do provedor ou 
pela publicação de um registro no reverso a cada novo domínio.

seja qual for o algoritmo, o esquema de chave pública tem um defeito muito 
sério: ele facilita registrar respostas afirmativas, mas não tem uma 
provisão para respostas negativas! e é exatamente nas respostas negativas 
que estamos mais interessados.

então, seja lá qual for o esquema, com o provedor de IP ou seu cliente 
assinando respostas, não se presta ao propósito original que é perguntar 
ao dono do IP se o domínio x pode enviar email a partir desse IP.

até agora a melhor idéia para implementar o SPF reverso são registros TXT 
formados por:

1. hash(domínio),
2. endereço IP invertido,
3. in-addr.arpa ou ip6.arpa.

com valor contendo uma parte de identificação do protocolo e uma palavra 
que pode ser PASS, NEUTRAL ou FAIL.

se o interessado tiver um bloco IPv4 menor que /24 terá que implorar para 
o seu provedor que ou bem delegue no esquema BCP-20 ou insira o registro 
na zona reversa. ou não fazer nada, o que resultaria em NEUTRAL (a não ser 
que a política padrão do provedor seja outra).

-- Danton.