[MASOCH-L] Guerra aos IPs dinâmicos

[Leandro]

Pois eh. Faz sentido exigir isso pois qualquer objeto ligado à Internet das
coisas é um enviador de e-mail em potencial. Se não tiver reverso, pode ser
até mesmo a lâmpada da sala querendo enviar e-mail. Pode ser qualquer
objeto.

Exigir o reverso é uma forma de mitigar o estrago causado pela massificação
de endereços IP no mundo. Se a gente já sofre hoje com SPAM de IPv4
dinâmicos, com uma dificuldade enorme de classifica-los, imaginem quando o
IPv6 estiver no seu auge?

Leandro
SPFBL.net

Em 18 de abril de 2017 16:07, César de Tassis Filho <ctassisf at gmail.com>
escreveu:

> Pode não existir uma RFC obrigando PTR para IP(v6) de MTA, mas o operador
> do provável maior serviço de e-mails da Internet possivelmente vai começar
> a recusar suas mensagens: https://support.google.com/mail/answer/81126
>
> Sobre reverso IPv6 para todos os endereços de um bloco (/64, por exemplo)
> tem esse cara aqui: http://all-knowing-dns.zekjur.net/
>
> César
>
> 2017-04-18 14:33 GMT-03:00 Danton Nunes <danton.nunes at inexo.com.br>:
>
> > On Tue, 18 Apr 2017, Leandro wrote:
> >
> > Danton. Refletindo melhor sobre o assunto, percebi que essa técnica do
> >> "rastro de pólvora" só afeta IPs com reverso. Portanto o método é
> seguro,
> >> desde que eu consiga registrar com precisão os padrões de reverso
> >> utilizados em residências, tanto para IPv4 ou IPv6. Eu acho importante
> >> atacar o problema no IPv6 também, pois vai que a cafeteira do sujeito
> >> acorda de mau humor e descarrega toda sua ira na porta 25. Não é
> verdade?
> >> :-)
> >>
> >> Ai o problema vai ficar restrito aos IPs sem reverso mesmo. Paciência!
> >>
> >
> > eu não vejo por que cadastrar reversos em IPv6, a não ser para endereços
> > notáveis. por outro lado a ausência de reverso pode ser uma pista de que
> se
> > trata de usuário final e não um MTA, mas só uma pista, porque também nada
> > obriga a um MTA ter seu(s) endereço(s) com reverso bonitinho.
> >
> > então, acho que esse critério pode ser usado para atribuir pontos em vez
> > de determinar um bloqueio definitivo.
> >
> > os endereços SLAAC são facilmente identificáveis porque carregam a
> > assinatura 0xFFFE a partir do bit 80 até o 95 (contando os bits a partir
> de
> > zero e da ponta mais significativa do endereço). Bloquear ou atribuir uma
> > nota de suspeita a um endereço SLAAC pode ser uma boa política.
> > Dificilmente um servidor de verdade tem um endereço assim, normalmente
> tem
> > endereços estáticos. note que um teste como este não requer sequer uma
> > consulta de DNS e pode até ser implementado pelo firewall, se a opção for
> > pelo bloqueio, mascarando o campo do endereço. (p.ex. com ip6tables no
> > Linux)
> >
> > outro tipo de endereço que pode indicar que se trata de usuário final e
> > não um servidor válido é o definido na RFC-4941. estes são mais difíceis
> de
> > identificar, por não terem um padrão fixo como é o caso do SLAAC.
> > entretanto, por conta mesmo da forma como são gerados, tem alta entropia,
> > aproximadamente metade dos bits em zero, como não costuma ser o caso com
> > endereços de servidores válidos. de qualquer forma melhor não usar isto
> > como critério de bloqueio, mas sim de pontuação. 64bits muito
> "aleatórios"
> > no rabo do endereço IP, mais x pontos de suspeita de spam.
> >
> > a entropia de uma mensagem é H=-Soma(i)[Pi log2(Pi)], no nosso caso i
> pode
> > ser 1 ou 0. P0 = númerio de zeros / 64, P1 = número de uns / 64 = 1-P0,
> > logo H = - ( P0 log2(P0) + (1-P0) log2(1-P0) ) Quando as quantidades de
> uns
> > e zeros são iguais, H=1. Quando todos os bits são iguais H=0.
> >
> > -- Danton
> >
> > __
> > masoch-l list
> > https://eng.registro.br/mailman/listinfo/masoch-l
> >
> __
> masoch-l list
> https://eng.registro.br/mailman/listinfo/masoch-l
>