Mão no barro: o guia de sobrevivência para transição de filtros anti-spam e validação de infra

Trabalhar com infraestrutura de e-mail é, muitas vezes, um jogo de paciência e precisão. Recentemente, enfrentei um cenário clássico, mas complexo: a migração de ferramentas de segurança (como o SpamAssassin, cPguard e SPFBL) e a necessidade de validar ambientes de homologação antes do apontamento definitivo de DNS.

Neste relato, compartilho como tratei as configurações de filtragem, os diagnósticos de latência, as validações de registros e os comandos de firewall que salvaram o dia.

1. O ajuste fino do SpamAssassin (DirectAdmin/cPanel)#

O SpamAssassin opera analisando centenas de regras heurísticas e atribuindo pontuações positivas ou negativas a cada mensagem recebida. A soma dessas pontuações resulta no Score final.

1.1 backup preventivo de configurações#

Antes de efetuar alterações no motor anti-spam ou no MTA, crie uma cópia de segurança dos diretórios de configuração:

# Backup das configurações do SpamAssassin
sudo tar czf /root/spamassassin-backup-$(date +%Y%m%d).tar.gz /etc/mail/spamassassin/

# Backup das configurações do firewall CSF
sudo tar czf /root/csf-backup-$(date +%Y%m%d).tar.gz /etc/csf/

# Backup completo das configurações de mail (Exim e SpamAssassin)
sudo tar czf /root/mail-config-backup-$(date +%Y%m%d).tar.gz \
  /etc/exim.conf \
  /etc/mail/ \
  /etc/csf/ 2>/dev/null || true

1.2 configurações de threshold e níveis de rigor#

O arquivo de configuração principal reside em /etc/mail/spamassassin/local.cf. O threshold (limite padrão geralmente é 5.0) é inversamente proporcional ao rigor do filtro. Configurar um limite muito baixo (ex: 2.0) torna o filtro extremamente agressivo, elevando o índice de falsos positivos.

Para alterar o threshold de bloqueio, edite o arquivo principal:

sudo nano /etc/mail/spamassassin/local.cf

Adicione ou edite a diretiva:

# Limite de score para marcar como SPAM
required_score 4.0

Aplique as alterações reiniciando o daemon correspondente:

sudo systemctl restart spamassassin

(Nota: em sistemas com Exim integrado ao Spamd, também pode ser necessário reiniciar o MTA: sudo systemctl restart exim).

1.3 whitelists, blacklists e regras customizadas#

Para evitar que e-mails legítimos de parceiros críticos caiam na caixa de spam, ou para banir remetentes abusivos de forma permanente, configure regras explícitas no local.cf:

# Whitelist (e-mails que NUNCA receberão marcação de SPAM)
whitelist_from [email protected]
whitelist_from *@dominio-confiavel.com

# Blacklist (e-mails bloqueados por padrão)
blacklist_from [email protected]
blacklist_from *@dominio-abusivo.net

# Desativar regras com alta taxa de falsos positivos locais (ex: URIBL bloqueado)
score URIBL_BLOCKED 0

# Criar uma regra sintática customizada baseada no assunto
header LOCAL_SPAM_BUY Subject =~ /comprar agora/i
describe LOCAL_SPAM_BUY Assunto contem gatilho urgente de compra
score LOCAL_SPAM_BUY 2.5

1.4 verificação do score de uma mensagem#

Para testar a pontuação de um e-mail específico de forma manual antes de sua entrega:

# Validar um e-mail bruto recebido na caixa ou arquivo temporário
spamassassin -t < /var/mail/user

# Ou enviando um payload através de pipe
cat email.txt | spamassassin -t

# Monitorar a atribuição de pontuação em tempo real nos logs do sistema
grep "score=" /var/log/mail.log | tail -n 20

2. Integração do anti-spam com o MTA (Exim/Postfix)#

O SpamAssassin atua como um analisador que recebe as mensagens do MTA. No Exim, a integração pode ocorrer por meio de pipes de transporte ou através de filtros de sistema (system_filter).

Exemplo de configuração de transporte no /etc/exim.conf:

spamassassin_pipe_transport:
  driver = pipe
  command = /usr/bin/spamc -u ${local_part}
  user = nobody
  group = nogroup

Para barrar spam agressivo antes da entrega na caixa de entrada via system_filter.conf:

if $h_X-Spam-Level: contains "*****"
then
    fail text "Mensagem recusada por conter padrao de Spam alto."
    noerror
endif

3. Diagnóstico de autenticação (SPF, DKIM, DMARC) e MX#

Quando ocorrem atrasos (latência) na entrega de e-mails, isole o problema auditando os registros de autenticação do remetente. O receptor pode atrasar a entrega através de greylisting se a autenticação falhar.

# 1. Verificar registro SPF do domínio
dig TXT meudominio.com.br | grep -i "v=spf1"

# 2. Verificar DKIM (especificando o seletor correspondente, ex: default)
dig TXT default._domainkey.meudominio.com.br

# 3. Verificar políticas DMARC
dig TXT _dmarc.meudominio.com.br

# 4. Consultar o apontador de mail exchanger (MX)
dig MX meudominio.com.br +short

# 5. Executar varredura em lote das chaves críticas
for record in TXT MX NS; do
    echo "=== Registro: $record ==="
    dig $record meudominio.com.br +short
done

4. Testes de entrega de e-mail e fila#

4.1 simulação de envio e verificação da fila#

Para comprovar que o fluxo de saída do servidor está ativo e sem bloqueios de reputação em RBLs:

# Enviar um e-mail de teste dinâmico via terminal
echo "Corpo do e-mail de teste operacional" | mail -s "Teste de Entrega Anti-Spam" [email protected]

# Consultar a fila de e-mails do servidor (Exim)
exim -bp

# Listar estatísticas e contagem de mensagens na fila geral
mailq

4.2 monitoramento de entrega nos logs do MTA#

Acompanhe os status de entrega nos arquivos de log específicos da sua stack:

# logs do Exim (DirectAdmin/cPanel)
tail -f /var/log/exim_mainlog | grep "=>"

# logs do Postfix/SpamAssassin (Debian/Ubuntu/CentOS padrao)
tail -f /var/log/mail.log | grep -E "postfix|spamd"

4.3 teste de transação SMTP via telnet (porta 25)#

Valide a comunicação e handshake SMTP com o host de destino simulando uma transação:

telnet meudominio.com.br 25
EHLO test.com
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
DATA
Subject: Teste SMTP Manual
Corpo do email
.
QUIT

4.4 análise de headers de e-mails recebidos#

Para depurar falsos positivos, inspecione a fonte original da mensagem no cliente de destino. Busque o cabeçalho Authentication-Results ou Received-SPF:

Authentication-Results: mx.google.com;
       dkim=pass [email protected] header.s=default header.b=XyZ;
       spf=pass (google.com: domain of [email protected] designates 192.168.1.100 as permitted sender) smtp.mailfrom=[email protected];
       dmarc=pass (p=REJECT sp=NONE dis=NONE) header.from=meudominio.com.br

5. Validação de ambiente local via arquivo hosts#

Durante migrações de servidores de e-mail ou sites, é imperativo validar o comportamento do novo host antes de atualizar as zonas DNS públicas (o que pode levar tempo para se propagar devido ao TTL).

5.1 caminho do arquivo hosts por sistema operacional#

• Linux: /etc/hosts
• macOS: /etc/hosts
• Windows: C:\Windows\System32\drivers\etc\hosts

5.2 edição do arquivo no Linux/macOS#

Rode o editor com privilégios elevados:

sudo nano /etc/hosts

Adicione a linha mapeando o IP de destino ao seu domínio:

192.168.1.100 meudominio.com.br www.meudominio.com.br

5.3 o impacto do TTL (time to live) e propagação de DNS#

Sempre confira o valor de TTL dos registros do seu domínio antes de virar a chave de produção:

# Consultar o TTL de resposta atual da zona
dig meudominio.com.br | grep -A1 "ANSWER SECTION"

• TTL 300 (5 minutos): Mudanças propagam de forma quase instantânea na rede (ótimo para janelas de migração).
• TTL 86400 (24 horas): Alterações levam até 48 horas para serem atualizadas globalmente por todos os resolvers recursivos de ISPs.

Para acompanhar a propagação global do MX ou TXT em múltiplos resolvers públicos:

for resolver in 8.8.8.8 1.1.1.1 208.67.222.222; do
    echo "Resolver: $resolver -> MX: $(dig @$resolver meudominio.com.br MX +short)"
done

6. Configuração e gerenciamento avançado do CSF firewall#

O ConfigServer Security & Firewall (CSF) é o controlador de iptables mais comum em servidores de e-mail Linux.

6.1 liberação e configuração de portas de e-mail#

O arquivo de configuração principal localiza-se em /etc/csf/csf.conf. Garanta que as portas seguras e padrão de SMTP (25, 465, 587) e IMAP/POP3 (143, 993, 110, 995) estejam liberadas:

# Permitir conexões TCP de entrada
TCP_IN = "25,80,443,110,143,465,587,993,995,2087,2083"

# Permitir conexões TCP de saída
TCP_OUT = "25,80,443,110,143,465,587,993,995"

Após editar, recarregue as regras de firewall:

sudo csf -r

6.2 configuração do LFD (login failure daemon)#

O LFD atua monitorando arquivos de log (como /var/log/secure e /var/log/mail.log) e bloqueando temporária ou permanentemente IPs com múltiplas tentativas de autenticação inválidas.

# /etc/csf/csf.conf

# Número de falhas antes de bloquear o IP
LF_TRIGGER = "5"

# Bloqueio permanente (1 = permanente, 0 = temporário)
LF_PERMBLOCK = "1"

# Intervalo de tempo do bloqueio em segundos (ex: 86400 = 24 horas)
LF_PERMBLOCK_INTERVAL = "86400"

6.3 comandos úteis do CSF#

# Buscar se um IP específico possui bloqueio ativo no firewall
csf -g 1.2.3.4

# Remover bloqueio temporário ou permanente de um IP de imediato
csf -dr 1.2.3.4

# Adicionar um IP de forma permanente na Whitelist (liberar acesso completo)
csf -a 1.2.3.4 "IP do Escritorio do Cliente"

# Adicionar um IP na Blacklist de bloqueio permanente
csf -d 1.2.3.4 "IP atacante detectado"

Checklist: migração e transição de filtros anti-spam#

1. Pré-migração (fase de planejamento)#

• [ ] Criar backups completos das configurações do SpamAssassin, CSF, Exim/Postfix e ClamAV.
• [ ] Reduzir o TTL dos registros de DNS (MX e TXT) do domínio para 300 segundos (5 minutos) na zona atual.
• [ ] Exportar whitelists e blacklists vigentes para arquivos locais de migração.
• [ ] Mapear o IP do novo servidor no arquivo /etc/hosts local para realizar testes sintáticos de envio/recebimento de homologação.

2. Migração (execução da janela)#

• [ ] Parar temporariamente o processamento do servidor de e-mail antigo ou pausar a fila para evitar perda de dados.
• [ ] Atualizar os apontamentos MX e TXT (SPF/DKIM/DMARC) com o IP do novo servidor de e-mail.
• [ ] Monitorar a propagação dos registros contra servidores DNS públicos (8.8.8.8, 1.1.1.1).
• [ ] Ativar o processamento e recebimento no novo MTA.

3. Pós-migração e validação#

• [ ] Enviar e-mails de teste para serviços externos (Gmail, Outlook, Yahoo) e analisar os headers das mensagens recebidas (spf=pass, dkim=pass, dmarc=pass).
• [ ] Executar consultas telnet na porta 25 externa para validar handshake e EHLO.
• [ ] Checar reputação do IP do novo servidor em RBLs conhecidas (Spamhaus, Barracuda).
• [ ] Ajustar gradualmente o required_score do SpamAssassin com base nas caixas de falso positivo monitoradas nas primeiras 48 horas.
• [ ] Restaurar o TTL do DNS para valores padrão de produção (ex: 3600 ou 86400 segundos).

Veja também

Infraestrutura Gmail rejeitando e-mails do DirectAdmin: como autenticar o hostname com SPF e DKIM

Infraestrutura A ilusão do `sshd_config`: como realmente garantir a segurança da autenticação SSH no cPanel/CloudLinux

Infraestrutura Guia Definitivo de Troubleshooting de Let's Encrypt e SSL no DirectAdmin (CLI, CAA e Subdomínio WWW)

Este post está licenciado sob CC BY-NC.