[GTER] Spam

[Enomoto]

-------- Mensagem Original --------
>Assunto: Re: [GTER] Spam
>Remetente: "Renato Fernandes De Lima" <renato.lima at ticbrasil.com.br>
>Data: Qui, 16 de Janeiro de 2003, 15:40
>
>
> Sandro,
>     Olá obrigado pelos comentários. Realmente resumindo seria uma lista
> com
> checagem dinâmica.
>
>>    Como foi citado anteriormente na lista como "interceptação de
>> tcp/25". Mas a sua idéia é capturar a sessão tcp/25 dos usuarios
>> dial/speedy
>> para a Internet ou o contrário, das conexões advindas da Internet para
>> seus servidores?
>
>     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.

    Então você terá dois tipos distintos de regras e dois tipos de
servidores, um não pode permitir o outro tipo de conexão por ele.

> Acho que o problema aqui seria:
> 1) implementar isso de modo transparente, ou seja, ainda queremos que no
> servidor e-mail remoto receba o ip do servidor original como iniciador
> da conexão;

    Qual a sua idéia aqui? Que o servidor de destino receba um email e no
meio dos headers tenha o IP que origou a conexão? Ou que o servidor de
destino receba uma conexão com o mesmo IP que originou o email?

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

    Mesmo querendo que se faça de forma transparente, IMHO isso deveria
estar em contrato.

> 3) performace: isso tem que ser feito sem afetar equipamentos de rede ou
> servidores em geral;

   Gargalos: Volume de email, roteadores já carregados com "acess-lists",
má implementação da solução.

>>    Ops, ai são dois lookup, certo? Um para saber se o dominio do "MAIL
>> FROM" tem MX. E um outro para saber ser o IP de destino da conexão
>> TCP/25 tem reverso ou para saber se existe reverso do IP que esta
>> originado a conexão? Muitos servidores de email não tem o reverso
>> configurado corretamente, não só no Brasil, como lá fora.
>
>     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 ?

    Claro, a maioria dos grandes provedores de serviço, usam um servidor
*só* para recepção (MX do dominio) e um outro só para receber os
emails dos usuários, vide UOL, IG, Terra, etc.
    Acho que no máximo você poderá fazer com a verificação de entrada é
valida o MX do dominio no MAIL FORM da conexão smtp. Verificar se o
reverso bate com o nome no HELO não creio que vá dar certo.

>>    Para isso existem as RBLs, deve-se ter um critério para utiliza-las
> para não haver a possibilidade de um falso negativo.
>>    Além disso uma "white list" para não bloquear alguns clientes da
> própria Telefonica, conhecidos spammers.
>
>     O bom deste processo seria sua checagem dinâmica da situação. Isso
> não
> afetaria os "bons clientes". Sendo que poderia ajudar. Estas listas
> seriam o start inicial da base de dados de "maus clientes". ...hmm!?!?
> -)

[...]

    Vocês querem começar com algo grande, sem saber se terão capacidade de
suportar o "tranco" e se haveria equipe *humana* que pudesse dar
suporte para tanto. Ficar cuidado de lista de bloqueio é uma atividade
chata e que requer critérios bem definidos para inserção ou exclusão.
    Caso queiram algo pago, contratem a Brightmail
(http://www.brightmail.com), que inclusive presta serviços para o
Terra no Mexico, ou outra empresa especializada nesse tipo de
problema.
    Se resolverem fazer algo in-house, sugiro o Qmail ou Postfix e a
partir dai façam sua propria lista de bloqueio, implementando seu
proprio dnsrbl (http://www.dnsrbl.com/howdowework.html) para gerenciar
IPs a serem bloqueados.
    Após a estabilidade, adicionem rotinas que monitorem os logs, gerando
*alertas* com relação a volume de emails gerados a partir de um único
IP. Você como ISP não podera bloquear o volume de emails num primeiro
momento até ter certeza que se caracteriza por um SPAM realmente, pois
pode ser uma mala direta válida de um fornecerdor para seus clientes,
dai você tera que cruzar esse alerta com os emails recebido no
abuse at telefonica.net.br .
   Aumentando o grau de sofisticação, colocar um programa como o
spamassassin para analise do conteudo do email.

[]s
[Sandro]



--------------------------------------------------
Estadão - Internet com alta qualidade de conexão.
GANHE ACESSO GRATUITO à Internet do Estadão em 
http://www.estadao.com.br/discador/
--------------------------------------------------