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

[João Carlos Mendes Luís]

Marcelo Coelho wrote:
> 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.

     Mas voce vai descobrir que vários servidores estão com esse problema.  Eu 
mesmo perdi algumas informações bancárias por que o servidor de email do meu 
banco estava com essa configuração.

     É um falso positivo sim, mesmo causado pela falha de outras pessoas.

> 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.

     Só funciona por que voce usa duas máquinas diferentes para email entrando e 
saindo, mas acho que foi uma boa idéia.

     Verifique ainda que tem spammer usando endereços IP no HELO.  Em geral, 
127.0.0.1 ou o seu próprio IP.

> 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.

     Tem como fazer melhor aqui.  Se o MAIL FROM for local, exija autenticação, 
ou simplesmente rejeite, mesmo que a conta exista.  Junto com o SPF isso pode 
ser uma solução bastante prática.

> 
> 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.

     Esquece o trabalho do DNS.  Tudo vale na guerra contra SPAM.

> 
> 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.

     Uma RBL que seria muito boa é a rfc-ignorant, mas infelizmente ela dá 
MUITOs falsos positivos.  Ou segundo a sua definição, detecta muito servidor mal 
configurado.  Incluindo ai hotmail, yahoo, terra, etc.

> 
> 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.

     É fogo...


> 
> 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.

     Acredito que as reclamações sejam de empresas com DSL, na maior parte. 
Culpa das carriers DSL que não separam empresas de usuários.  Minha sugestão 
nesse caso: bloqueia e usa lista branca para quem for necessário.

> 
> --
> 
> 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.

     O SPF pode ser a sua solução, mas é preciso informar isso aos usuários.
O interessante do SPF é que ele é uma decisão que parte do dono do domínio 
origina.  Voce só bloqueia se o dono do domínio pediu para bloquear.  Se voce 
colocar SPF no seu dominio, vai evitar que usem o seu dominio como fonte de 
spam.  Procure no google por joejobbing, e entre em panico.  Já aconteceu 
comigo, não é legal.

> 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".

     Nesse caso, voce diz para ele reclamar com o provedor dele, que foi quem 
colocou o SPF a disposição.  É simples.

> É 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

     Está certissimo.  E o legal do SPF é que ele está sendo adotado pelos 
grandes provedores.  Principalmente por que ele resolve o problema deles: A 
maioria dos spams são falsificados usando um email de um grande provedor.

> 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".

     E o que leva voce a acreditar que iriam segui-la?  Não seguem as RFCs...

> 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.

     Os efeitos colaterais existem, e cada um tem que decidir quais aceita ou não.

     Voce poderia ter listado outras forma de bloqueio, todas com efeitos 
colaterais e falsos positivos:

- Bloquear conexoes vindas de IPs sem DNS reverso.
- Bloquear remetentes com MAIL FROM listados em rhsbl como o rfc-ignorant
- Autenticação individual do remetente por web (TMDA, por exemplo)
- Verificação prévia do remetente.  Nesse caso o servidor envia uma mensagem 
"parcial" de volta, e se o servidor remoto acusar erro de usuário, voce rejeita 
a mensagem entrando.

     E finalmente, uma que eu gosto muito, que não tem falsos positivos mas que 
pode causar um pouco de transtorno e atrasos na entrega:

- Greylisting

                                         Jonny

-- 
João Carlos Mendes Luís - Networking Engineer - jonny at jonny.eng.br