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

[Fernando Lima]

At 10:51 05/08/04, you wrote:

Olá,

Temos um ambiente com os mesmos problemas aqui !

O que temos aqui com resultados razoáveis é:

- Servidores separados para receber email e tratar spam/vírus.
- Não receber emails de uma caixa postal inexistente. Sim, alteramos o Qmail.
- Usamos o orbs
- Controlamos o número de emails por hora de um mesmo ip/from
- Se alguém começa a mandar muito email deixamos a conexão lenta
- Se tiver muito from inválido, deixamos a conexão lenta ou cortamos o ip
- Limitamos o número de conexões por subnet
- Para alguns dominios checamos se o from e o reverso são o mesmo ;-)
- Eventualmente não aceitamos conexões de algumas redes
- Limitamos o número de recipientes por mensagem
- Filtros baseados no contéudo do email (from/subject/body etc...)

As regras acima não nos causam grandes transtornos. O maior problema que 
tivemos aqui foi bloquear o reverso de alguns serviços de banda larga 
nacionais. Praticamente acabamos com o spam em português mas o help desk 
foi inundado com reclamações de clientes sobre emails que não eram 
recebidos. Tivemos que voltar atrás....

É isso.

Obrigado.


>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
>
>--
>GTER list    https://eng.registro.br/mailman/listinfo/gter