[GTER] SPAM: resumo.

[Durval Menezes]

Alo Danton,

Muito completo o material que voce incluiu abaixo. Realmente interessante.

Apenas alguns pontos adicionais:

1) A raiz de todo o problema do SPAM (e outros relacionados a email, como 
   fake-mail, picaretagens diversas como as famosas 'Propostas da Nigeria', 
   etc), e' que o SMTP foi concebido na fase de "ingenuidade academica" da
   Internet (ou seja, pre'-1990), e sofreu muito poucas alteracoes de la'
   para ca' (ate' porque esta' tao difundido e -- no geral -- funciona tao
   bem que e' dificil de mudar). Com a experiencia que temos hoje em dia,
   nao e' dificil projetar um protocolo que torne o SPAM um problema bem
   mais controlado...

2) Para evitar do meu endereco de email ficar *mais* difundido do que ja'
   esta' entre os SPAMmers (recebo uns 50 SPAM por dia), sempre que vou
   enviar email pela primeira vez para um destinatario para o qual ha'
   risco de ser incluido em SPAM (listas -- principalmente aquelas com 
   'archive' disponivel via WWW --, USENET, terceiros que podem reenviar
   minhas mensagens para um destes dois, etc):

	a) crio um "alias" no meu servidor, no formato 'jmN at tmp.com.br',
           onde N e' um numero inteiro que se inicia em 0 e e' incrementado
	   com cada uso;

	b) Envio o email, troco respostas, etc (sempre tomando o cuidado 
	   de setar o 'From' no header; o meu '.sig' ja' esta' razoavelmente
	   obscurecido).
	
	c) Se nunca chegar SPAM por este endereco, nada precisa ser feito;

	d) No primeiro SPAM que chegar por este alias, removo-o no meu
	   servidor (ou seja emails para este endereco passam a ser recusados
	   de cara, e nao gastam mais a minha preciosa banda e nem poluem
	   a minha caixa postal).

    Alem de evitar o aumento na quantidade de SPAM, esta tecnica tem a
    grande vantagem de permitir "rastrear" de onde vem o SPAM... so' como
    exemplo, um "alias" que criei recentemente para um cadastro que fiz para
    uma compra em um site WWW depois de algumas semanas comecou a ser usada
    para SPAM por uma outra empresa (que nao tinha a principio nada a ver com
    a dona do site onde fiz a compra); a partir dai' foi so' descadastrar e
    colocar o tal site na minha lista negra (nunca mais compro nada la').

3) Alguns sites WWW ja' usam uma tecnica que "esconde" o endereco de
   email original por tras de um link que chama um CGI, que por sua vez
   (apos checar referer, cookies, etc para filtrar os robots dos spammers)
   gera dinamicamente uma pagina HTML com o 'mail to' original. 

   Desta forma atrapalha-se razoavelmente o SPAMmer, sem atrapalhar demais
   o usuario legitimo...

PS: A lista do GTER e' arquivada em WWW? O Arquivo esta' protegido de alguma
    forma? Pelo sim pelo nao, ai' vai mais um 'jmN at tmp.com.br' :)

Um Grande Abraco,
-- 
   Durval Menezes (durval AT tmp DOT com DOT br, http://www.tmp.com.br/)

On Wed, Apr 03, 2002 at 09:57:09AM -0300, Danton Nunes wrote:
> Considerações sobre o ciclo de vida do SPAM
> 
> O processo começa com a coleta de endereços eletrônicos, especialmente de
> duas fontes: listas/usenet e Web. Qualquer um que poste uma mensagem numa
> lista notória ou cujo endereço apareça em um localizador tipo 'mailto:...'
> é sério candidato a ser incluido nas listas.
> 
> Uma vez compiladas as listas elas são vendidas, geralmente junto com algum
> programa de envio massivo, que faz conexão direta aos servidores das
> vítimas. Essas listas são anunciadas normalmente por SPAM! Nesse caso, o
> ferreiro usa espetos de ferro mesmo.
> 
> Finalmenete vem a fase de envio das mensagens. Ambientes que estão ligados
> permanentemente à Internet são os ideais, pois o programa enviador pode
> ficar rodando em background usando toda a banda upstream o tempo todo.
> 
> Relays abertos são usados como um fator multiplicador da eficácia do spam,
> pois basta enviar uma única cópia da mensagem para o relay que ele se
> encarrega de 'mimeografá-la' e espalhar os clones por aí.
> 
> Tecnicamente podemos atacar o SPAM em vários pontos do ciclo de vida. Na
> fase de coleta uma técnica é a de poluir as listas com enorme quantidade
> de endereços falsos. Isso é possível criando 'trap pages' produzidas por
> programas que geram toneladas de '<a href="mailto:bobagem at outra.bobagem">
> para que o robot de coleta de endereços se empapuce. Evidentemente este
> ataque só funciona para os endereços coletados da Web. Endereços coletados
> de listas são muito mais confiáveis para o coletor. Resta aos
> administradores das listas configurá-las de modo a sumir com o endereço do
> remetente da mensagem, o que prejudica a possibilidade de respostas
> privativas.
> 
> É muito difícil coibir o comércio das listas e os métodos de defesa nessa
> fase do ciclo de vida estão mais no plano legal/policial do que da
> engenharia.
> 
> A transmissão a partir de relays abertos é combatida pela manutenção das
> listas de relays. Isso tem tido lá suas dificuldades, especialmente no
> plano legal, mas bancos de dados como o do mail-abuse.org tem sobrevivido.
> 
> Se defender de mensagens vindas de dial-up/adsl pode ter duas estratégias,
> uma implementada por quem recebe as mensagens outra pelo provedor de
> acesso. O destinatário pode bloquear conexões com base em listagens de
> endereços IP sabidamente pertencentes a linhas discadas ou de adsl. A
> outra estratégia consiste em o provedor de acesso de linha discada/adsl
> forçar a passagem do tráfego sainte de e-mail por pontos de controle, onde
> de alguma forma o joio possa ser separado do trigo. Listas de controle de
> acesso nos roteadores e/ou 'policy routing' empurrando as conexões para
> portas smtp externas para o ponto de controle fazem a mágica. Controles
> quantitativos (número de RCPT's, banda, etc.) a completam.
> 
> Além de rejeitar e-mail com base no fato de o endereço IP do último relay
> estar em uma lista (porque é um dial-up/adsl ou relay aberto, etc.) há
> pouco o que fazer. É difícil distinguir uma mensagem de erro,
> caracterizada pelo remetente vazio no envelope, de SPAM. Embora haja gente
> trabalhando nisso ainda não existe procedimento que faça distinção
> automática e com margem de erro desprezível entre SPAM e mensagens
> válidas.
> 
> Por fim, vem a fase repressiva. Uma vez bombardeado com lixo o usuário tem
> que reclamar para alguém, mas com uma mensagem com cabeçalhos adulterados,
> o único dado confiável é o 'Received:' gerado no servidor do destinatário.
> O processo para identificar responsáveis não é para principiantes ou para
> quem não tem muito tempo ocioso. Porjetos como o SpamCop ajudam muito.
> 
> É possível que no futuro as listas sejam usadas ao contrário, isto é, em
> vez de termos listas bloqueando IPs de rementenes venhamos a ter listas
> com IPs de 'bons remetentes', cujos administradores pratiquem políticas de
> prevenção, controle e repressão ao SPAM e uso correto de e-mail. Uma
> espécie de ISO-9000 do e-mail.
> 
> Mais alguma observação?
> 
> Danton.
> 
> --
> GTER list    http://eng.registro.br/mailman/listinfo/gter