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

[Henrique de Moraes Holschuh]

On 15-08-2012 16:33, Danton Nunes wrote:
> 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.

...

> 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.

Sugiro que não utilize MD5, e sim SHA256.  Não é questão de segurança,
porque existem maneiras altamente triviais de inverter a pergunta "que
domínios usam esse servidor MX".  É questão de aceleração por hardware
(não é comum para MD5, mas é comum para AES e SHA-2 (SHA256, 384, 512) e
estará largamente disponível na base instalada em 2 a 5 anos, à medida
que os servidores são substituídos) e para evitar colisões.

> 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!

Existem diversas bases de dados que fazem o mapeamento (nome de domínio
-> IP do MX), e publicam o resultado da busca reversa (IP do MX ->
domínios). Essas bases de dados são utilizadas pelos serviços de
reputação e para debugging.  Um exemplo de base de dados pública que faz
esse mapeamento é a robtex.

Sugiro que o esquema de hash não seja utilizado, ou que o mesmo seja
utilizado unicamente para evitar o problema do número de componentes de
sub-domínio (e esteja documentado desta forma).

Agora, considerando que pelos padrões de uso correntes, domínio de email
que ultrapasse 93 componentes só pode ser obra de alguém mal
intencionando querendo justamente evitar lookups em bases RHSBL, na
minha opinião, embora utilizar um esquema baseado em hash que torna esse
ataque impossível seja a solução técnica mais correta, considerando o
uso em larga escala de RHSBLs, o melhor é contornar o problema recusando
entrega.

Sou de opinião que deveria propor-se ao WG da IETF que seja publicado um
RFC específico, recomendando que o uso de quaisquer domínios com mais de
X (por exemplo, X=64) componentes em qualquer um dos cabeçalhos e
envelope de email implique na imediata rejeição ou descarte da mesma, ou
alternativamente que seja publicado um RFC recomendando que os
protocolos estilo RHSBL utilizem hash (e aí vai a dor de cabeça de mudar
isso na produção).

Não adianta nós mesmos escrevermos esse RFC, precisa ser escrito pelo
pessoal peso-pesado no WG da IETF, para garantir a adoção rápida pelos
grandes provedores de email (google, yahoo, hotmail)...

-- 
Henrique de Moraes Holschuh <hmh at ima.sp.gov.br>
IM@ - Informática de Municípios Associados
Engenharia de Telecomunicações
TEL +55-19-3755-6555/CEL +55-19-9293-9464

Antes de imprimir, lembre-se de seu compromisso com o Meio Ambiente
e do custo que você pode evitar.