[GTER] Spam

Danton Nunes danton at inexo.com.br
Thu Jan 16 18:41:00 -02 2003


On Thu, 16 Jan 2003, Renato Fernandes De Lima wrote:

>     Todo o tráfego tcp com porta destino 25. Tanto inbound como outbound.
> Acho que controlando o tráfego outbound controlariamos que nossas redes
> mandem spam para fora. E controlando para inbound podemos protege-las. Acho
> que o problema aqui seria:

sim, mas voce tem que ter políticas distintas para inbound e outbound.

> 2) privacidade: com certeza cairiamos em questões como: o isp está lendo
> meus mails!

balela! smpt, por sua própria natureza de store and forward faz com que o ISP
"leia" minhas mensagens. faz parte do processo. fora a quantidade de
'wiretaps' que tem por aí (echelon, carnivore,...)

>     Opa, desculpem e por favor ignorem a frase    "e o ip do servidor " no
> item 2. O que queria dizer é que ele checa os MX apenas. Sem reverso. Nesso
> caso penso que possíveis problemas seriam:
> 1)  Alguem possui ou conhece alguma arquitetura em que o servidor de mx não
> é realmente aquele que envia o e-mail...simplificando o mx só recebe e-mail
> e a saida do mesmo é por outro ip..existe ?

SIM. em minha rede corporativa, por exemplo, as estações podem mandar
mensagens diretamente sem passar pelo MX.

> >    Existem RBLs que contem listas de open relays, fazer testes de open
> relay "on the fly" só iria gerar timeout nas suas conexões.
>     Será que este timeout seria tão grande ? Talvez sim na primeira vez(vou
> tentar realizar testes). Depois isso iria para um cache(tipo um cache que o
> bind faz para não precisar fazer queries toda a hora).

poderia ser de horas, dias até. como disse em outra mensagem, um servidor não
rejeitar um endereço de RCPT não quer dizer que ele é um open relay.

resumindo: voce pode provar que determinado servidor é open relay, e isso pode
tomar tempo. é muito mais complicado provar que determinado servidor *não é*
open relay. por isso é que existem listas de relays via dns.

O critério: "tomo o domínio do destinatário e testo se o servidor de destino é
um MX (ou A, ou A6, ou AAAA) para esse domínio. Se for, OK, se não é suspeito"
vai bem. Só que se voce tiver um interceptador tipo null relay client ele vai
ignorar solenemente o IP de destino e vai recalculá-lo exatamente desse jeito
(via MX)

finalmente, ou deveria ser primeiramente, não vi de onde tiramos a informação
de quem é o servidor de destino. não pode ser do pacote IP porque seu campo de
destino foi reescrito pelo roteador que desviou o tráfego.

danton





More information about the gter mailing list