[GTER] Re: uol.com.br

[Lao DanTong]

On Tue, 15 Jul 2003, Bruno Borges wrote:

>
>     Seria uma boa idéia, mas você já imaginou o poder de processamento que
> seria necessário para escanear 40 milhões (estou enganado?) de e-mails com
> ele? Em um computador considerado "fraco" (servidor com 1 processador
> Intel(R) Pentium(R) 4 CPU 2.40GHz), fazendo as 4 análises que ele descreve
> (cabeçalho, análise das características do texto, blacklists do usuário, , e
> o razor), o que eu tenho visto, é que leva em média 10 segundos para ele
> analisar se um e-mail é SPAM ou não. Além de gerar alguns (menos de 10%)
> falsos positivos, e de muitos falsos negativos, apesar de isso ser escalável
> a medida que se diminui o SCORE do que se considera SPAM.

não tinha pensado nisso. um dos problemas de desempenho do spamassassin é
o fato dele ser escrito basicamente em perl. alguém já pensou em
reimplementá-lo em C?

outra possibilidade é usá-lo na ponta do usuário, em vez de forma
cntralizada.

de qualquer jeito, eu não acredito nem em whitelists nem em filtros de
conteúdo. as primeiras provocam a confusão que estamos vendo, os segundos
geram falsos positivos e negativos. eu acho que o foco de combate ao spam
tem que mudar, de quem recebe para quem envia. enviar e-mail tem que
custar caro. na última reunião do GTER eu propus um método para contar os
RCPTs que os usuários de um provedor produzem, com o objetivo de
tarifá-los. É bem mais leve do que o sistema de whitelist e não tem
problemas de escalabilidade do spamassassin. se e-mail custar dinheiro o
spam pode até não deixar de existir, mas terá que ser mais seletivo e
ficar parecido com as malas diretas que recebemos pelo correio
convencional.

ok, isso é utópico, mas é o caminho. enquanto o foco de combate ao spam
for o de filtrar e rejeitar mensagens em vez de matar o dragão no ninho,
qualquer coisa será paliativa e incomodará mais do que poderá proteger.

danton