[GTER] Bloquear SPAM - uma tarefa impossível?

[Marcelo Coelho]

Olá a todos.

Em primeiro lugar, peço desculpas ao tamanho da mensagem, e possíveis erros
de digitação/ortografia (é a maldita falta de tempo).
Quem tiver tempo e paciência, por favor leia, acho que será importante
debater sobre o assunto.

Administro um servidor de e-mails com mais de 20.000 contas de e-mail
distribuídas entre 4.000 domínios diferentes, recebemos mais 250 mil
mensagens por dia.
O volume de SPAM que temos recebido é muito maior do que as estatísticas que
são divulgadas em reportagens por aí. Creio que a cada 10 e-mails recebidos,
8 ou 9 são SPAM. Acho que isso ocorre pela característica do servidor - são
muitos domínios com poucas contas cada domínio.

Chegamos a modificar o código-fonte do nosso servidor qmail, mas tivemos que
voltar atrás em uma série de ítens.
(Aproveito e coloco a disposição para quem estiver interessado nas
modificações que fizemos no qmail, entre em contato por e-mail, e entregamos
os códigos.)

Acredito que outros admins aqui podem compartilhar suas experiências.

Abaixo listarei o que fizemos, quais foram os prós e contras:

Intro: apenas para esclarecer, as modificações foram feitas apenas no
servidor de e-mails MX, os usuários continuavam enviando e-mail normalmente,
através de outro IP com SMTP AUTH, sem passar por estas regras.

1) Passamos a exigir que o HELO seja um hostname válido (FQDN)

Analisando a quantidade de SPAM/VIRUS/SCAM recebido, notamos que a imensa
maioria não fornecia um HELO válido (A RFC determina que servidores usem
FQDN ou o IP entre [ ]).
Fizemos um checagem simples: HELO que não tivesse "." seria descartado.

Pró: diminuimos SPAM sensivelmente (mais de 70%), e o antivirus praticamente
não precisou trabalhar, pois a maioria dos e-mails contaminados eram
barrados no HELO
Contra: Diversos chamados de suporte de clientes alegando que não conseguiam
receber e-mails de outras pessoas. Não considero isso um "falso positivo",
mas sim uma falha na configuração do servidor remoto.

2) Exigimos que o HELO, caso seja FQDN, possa ser resolvido, e não resolva
para o próprio IP do servidor.

Pode parecer bobeira, mas tem muito SPAMMER que informa como HELO o próprio
domínio que receberá o SPAM, ou então informa o próprio IP do servidor.

Pró: bloqueamos bastante SPAM/VIRUS, não tivemos nenhuma reclamação.
Contra: mais um trabalho para o servidor, com resolução DNS, para cada
mensagem recebida.

3) Caso o MAIL FROM seja um domínio local, exigimos que a conta existisse no
servidor.

Muitos SPAMMERS enviam mensagem a partir de nomes aleatórios, usando o
próprio domínio do destinatário do SPAM.

Pró: bloqueamos muitas mensagens, principalmente VIRUS, e SCAMs.
Contra: clientes que tem ativado o recurso "catch-all" (pega-tudo) não
passam por esta checagem.

4) Exigimos que o domínio do SENDER seja um domínio válido.

Recebemos muitos SPAMS de domínios inventados, como hotmaaaaail.com, por
exemplo.

Pró: bloqueamos algumas mensagens, quase todas eram SPAM, e as que não eram
SPAM tratava-se de uma besteira do usuário que no Outlook digitou seu
domínio incorretamente.
Contra: mais um trabalho para o servidor, com resolução DNS.

5) Consultamos diversas RBLs: spamcop, spamhaus, sorbs, ordb

Hoje em dia um servidor que não utilize uma RBL irá receber muito, muito
SPAM.

Pró: bloqueamos muito SPAM :-)
Contra: diversos falsos positivos, e algumas situações comprometedoras: até
o TERRA foi bloqueado pelo SPAMCOP.

No caso específico do Terra, tivemos que liberar a faixa de IPs dos
servidores do Terra, pois os usuários, leigos, não sabem o que é RBL, nem
pra que serve. É a tal inversão de valores: reclamar com quem bloqueia, e
não com quem é bloqueado.

6) Consultamos o reverso, e bloqueamos algumas redes, conforme recomendação
em http://www.spambr.org/bloqueio.php3

Pró: muito, muito, MUITO SPAM bloqueado.
Contra: CAOS TOTAL. Milhões de reclamações de usuários que tem servidores de
e-mail na empresas e não conseguem nos enviar mensagens.

--

A ordem em que o nosso servidor executava os testes era esta que listei
acima. Decidimos fazer desta forma, pois acreditávamos que estáriamos
executando testes mais simples primeiro, bloqueando um maior número de
mensagens, e deixando o trabalho mais pesado para as demais checagens, como
por exemplo a consulta à RBL.
Na primeira semana que implementamos este novo servidor, foi um caos.
Recebemos diversas reclamações de pessoas que não conseguiam receber e-mails
de outros "servidores". Não tivemos outra alternativa a não ser remover
diversos tipos de bloqueios que eram eficientes, mais infelizmente
bloqueavam um percentual de servidores mal configurados. Ficamos apenas com
a checagem na RBL, e todos os dias temos reclamações.

O que nos deixou desanimados, é a incapacidade de certos administradores, de
configurar corretamente suas máquinas. Só de HELO e reverso, acredito que
muitos estejam mal configurados.
Empresas contratam serviços ADSL, e mesmo que não seja uma modalidade
empresarial, mesmo que o IP seja DINÂMICO, colocam um servidor de e-mails lá
e pronto, querem entregar mensagens para o mundo.

Estamos numa situação muito diferente dos grandes provedores como UOL,
Terra, AOL. Este grandes provedores, podem fazer o "que bem quiserem", na
modalidade do "eu faço e os outros que se danem". Só para citar: UOL
bloqueia diversos IPs de ADSL, AOL bloqueia quem não tem reverso, bloqueia
IP dinâmico, etc.

Já no nosso caso, cada ação que tomamos contra o SPAM se reverte contra nós.
Não podemos ignorar nossos clientes, nem usar a tática de UOL e AOL, que
"bloqueiam e problema de quem está bloqueado".

Toda esta experiência me leva a crer que o SPF não irá funcionar, pois vai
causar muitos chamados de suporte. Talvez eu até publique o registro TXT no
DNS, mas este terá ?all e não irei fazer qualquer checagem de SPF, pois é
dor-de-cabeça na certa.

Quem tem conta de e-mail @uol.com.br e tem um servidor em sua rede interna,
vai querer mandar e-mail a partir de sua rede interna. O que posso alegar
para um cliente, com e-mail @uol.com.br, que não consegue mandar e-mail para
o meu servidor, mas consegue mandar e-mails normalmente para diversos outros
servidores (os que não adotaram SPF)? Vou dizer que a partir de 01 de
outubro o Hotmail (que é gratuito) também não irá receber? O usuário na
maioria das vezes não usa a cabeça, e usa a máxima: "funciona com outro
provedor, tem que funcionar aí também".

É um papo de maluco, sei, mas chego a conclusão que medidas de combate ao
SPAM devem ser tomadas em conjunto com grandes provedores, e amplamente
divulgadas à seus usuários, talvez até nos demais meios de comunicação,
antes do início de tais mudanças. O Registro.br, em conjunto com o Comitê
Gestor, poderia enviar e-mail para todos os contatos no Registro.br,
informando uma "cartilha de recomendações".

Gostaria de saber a opinião dos assinantes desta lista, que tipos de
bloqueios estão fazendo, que tipo de "efeito colateral" têm em decorrência
disto, e se alguém tem alguma sugestão a respeito de uma ação coletiva
contra o SPAM.

Bom, é isso. Ufah, cansei de tanto escrever. ;-)

[ ]'s

--
Marcelo Coelho
marcelo at tpn.com.br