[GTER] Luta contra SPAM - Sobre o artigo

[Reinaldo Penno]

Sobre o artigo que enviei...Eu tive a oportunidade de conversar com a
palestrante e outros que estavam no MIT e alguns items levantados foram
discutidos la.

1 - A maioria dos spammers eh pobre. Isso eh uma premissa. Eh claro, que vai
existir sempre alguem que vai falar.."ah, mas o meu primo eh spammer e tem
um Intel Dragon na casa dele". Mas isso nao eh a regra.

2 - A maioria dos spammers tem SMTP proprio e seus email nao passam pelos
servidores "trusted" do ISP ou Carrier. 

3 - Isso cria uma ideia de trusted relatioships que esta muito discutido
hoje em dia. Ou seja, emails que passem pelo SMTP da inexo, por exemplo, sao
trusted (seja por uma PKI estabelecida, troca de chaves estilo IKE, etc),
entao a principio nao tem que calcular a funcao. Qualquer outra sessao SMTP
partindo do bloco da inexo que nao seja desses servidores, deve calcular a
funcao.

4 - No caso da Telefonica, por exemplo, os servidores principais que
provavelmente enviam e recebem emails dos funcionarios seriam trusted, todos
as outras sessoes SMTP teriam que calcular a funcao.

5 - Caso a Telefonica nao faca nada contra os seus queridos spammers, ela
tera que pagar de um jeito relamente efetivo (que doi o bolso) ou seja seus
emails ficaram extremamente lentos. Como a funcao eh ajustavel, no caso da
Telefonica a funcao poderia ser tao pesada que os spammers teria que mudar
de lugar os desistir.

Eh claro que como todos os avancos cientificos, varias outras propostas que
destilarao a inicial serao submetidas, ate que um sistema efetivo seja
alacancado. Mas o importante dessa proposta (filosoficamente falando) eh a
seguinte:

a) eh assumido que qualquer solucao efetiva contra os spammers
(especialmente no Brasil devido a impunidade) deve ser feita de modo que a
carga seja transferida para eles (seja de configuracao, compra de
equipamentos, etc), ou para os que abrigam spammers.

b) Como a maioria dos spammers sao pobres, mas sao muitos, processa-los um a
um por perdas e danos nao dara muito certo. E principalmente no caso
brasileiro onde virtualmente nao existe condenacao para crimes bem piores,
imagine um simples spammer. Ou seja, vamos esquecer solucoes utopicas. Alem
disso, em relacao ao projeto de lei em andamento, o spammer pode ser
brasileiro, mas o SMTP usado esta na Asia ou o spam vem de fora, etc, etc

c) Como mencionado acima (a), qualquer sistema contra spammers que necessite
de um "engenheiro de edicao de arquivos texto" no ISP/Carriers que querem se
proteger nao vai dar certo. Uma pessoa na palestra (no caso um grande
carrier da europa) mencionou que tem 2 pessoas so para cuidar de problemas
de abuse, e que esses engenheiros basicamente ficam editando arquivo texto o
dia inteiro e isso eh inaceitavel.

bom, eh isso.

abracos,

Reinaldo

> -----Original Message-----
> From: Michel Angelo da Silva Pereira
> [mailto:michelpereira at netsite.com.br]
> Sent: Wednesday, January 08, 2003 6:22 AM
> To: gter at eng.registro.br
> Subject: Re: [GTER] Luta contra SPAM
> 
> 
> 	Dei uma lida no artigo, mas acho isso inviável, o 
> interessante seria 
> acabar com a fonte, que seriam os SPAMMERS.
> 	Mas também acho que falta uma conscientização por quem 
> coloca o seu 
> produto para ser anunciado dessa forma.
> 
> t+
> 
> Marcus Grando wrote:
> > Ola,
> > 
> > Um email que o reinaldo mandou a pouco tempo atraz vem de 
> encontro a isso,
> > acho que um modo de comecar a incomodar os spammers vai ser 
> eles terem que
> > validar o email que eles estao enviando. Talvez ajude a 
> diminuir o número
> > de mensagens não solicitadas.
> > 
> > http://eng.registro.br/pipermail/gter/2002-December/001222.html
> > 
> > Alguem sabe se tem alguem implementado isso já?
> > 
> 
> 
> -- 
> =================================
> SCSA - Certificado Conectiva
> Security Officer - Net Site S/A.
> Michel Angelo da Silva Pereira
> michelpereira at netsite.com.br
> =================================
> 
> --
> GTER list    http://eng.registro.br/mailman/listinfo/gter
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://eng.registro.br/pipermail/gter/attachments/20030108/08fe938f/attachment.html>