O buraco negro do Exim, falhas de alinhamento DMARC e como recuperar a reputação de IP

Poucas situações geram tanta dor de cabeça na gestão de servidores de e-mail quanto ver o IP da máquina entrar em listas de bloqueio (RBLs) sem que nenhuma conta tenha sido invadida para disparar spam em massa.

Muitas vezes, a degradação de reputação não vem de ataques externos, mas sim de loops silenciosos dentro do próprio servidor: respostas automáticas gerando descompassos de DMARC, e-mails de alerta do sistema sem destinatário válido que colapsam na fila do Exim e tentativas contínuas de reentrega que disparam sensores heurísticos de provedores como TrendMicro, Broadcom e Google.

Neste artigo, vamos dissecar um incidente real em um servidor AlmaLinux com cPanel e Exim, entender o papel da diretiva never_users, descartar hipóteses de invasão e aplicar as correções definitivas no terminal.

1. Os primeiros sinais de alerta e a análise dos logs#

A investigação começou após relatos de falhas de entrega para grandes provedores. Ao filtrar o arquivo /var/log/exim_mainlog, encontramos três padrões claros de rejeição:

Assinatura 1: Rejeição de relay no messagelabs / broadcom#

2026-04-19 01:45:03 1wDRH7-00000003l3z-1Dde H=cluster9.us.messagelabs.com [67.219.246.213] SMTP error from remote mail server after RCPT TO:<[email protected]>: 453-you are trying to use me as a relay, but I have not been configured to let you [192.0.2.1, host.provider.com] do this.

O código de erro 453 foi devolvido pelo gateway remoto logo após o comando RCPT TO. Esse comportamento ocorre quando o servidor de destino interpreta a mensagem como uma tentativa de Open Relay não autorizado, geralmente provocada por falha de alinhamento no DNS reverso (PTR) ou falta de autorização explícita nas políticas de borda do destinatário.

Assinatura 2: Bloqueio temporário no trendmicro ERS-QIL#

2026-04-19 03:00:03 1wDiS5-00000004s2s-07As H=schulz.in.tmes.trendmicro.com [18.208.22.77] SMTP error from remote mail server after RCPT TO:<[email protected]>: 450 4.7.1 <[email protected]>: Recipient address rejected: Mail from <192.0.2.1> was refused due to the sender IP found in ERS-QIL.

A listagem no TrendMicro ERS-QIL (Quick IP List) é dinâmica e baseada em heurística: quando os sensores detectam um aumento súbito de conexões rejeitadas ou envios para caixas inexistentes (tráfego de Backscatter), o IP é temporariamente rebaixado, gerando erros do tipo 450 4.7.1 que forçam o Exim a segurar as mensagens na fila.

Assinatura 3: Rejeição estrita por falta de autenticação no Gmail#

2026-04-19 12:15:02 1wETrR-00000007cN3-3ZrX ** [email protected] ([email protected]) <[email protected]> R=dkim_lookuphost T=dkim_remote_forwarded_smtp H=gmail-smtp-in.l.google.com [172.253.122.27] : SMTP error from remote mail server after end of data: 550-5.7.26 Your email has been blocked because the sender is unauthenticated. DKIM = did not pass, SPF [] with ip: [192.0.2.1] = did not pass

O Google aceitou o aperto de mão inicial, mas encerrou a sessão com código 550 imediatamente após o envio do payload completo. O campo SPF [] com valor vazio indica que o validador não encontrou um domínio válido no Envelope-From durante a consulta DNS em tempo real.

2. Causa raiz 1: autoresponders gerando desalinhamento DMARC e backscatter#

Ao inspecionar uma das mensagens retidas com exim -Mvh 1wDRH7-00000003l3z-1Dde:

bertolisegurosco 1008 984
<[email protected]>
-ident clientuser
-received_protocol local
-auth_id clientuser
-auth_sender [email protected]
From: "[email protected]" <[email protected]>
Precedence: auto_reply
Subject: Desativacao deste e-mail
X-Autorespond: Um olho no fim de semana e outro nessas ofertas.

O que o cabeçalho revelou#

1. Mensagem de origem local: a presença de -received_protocol local e -auth_id clientuser prova que o e-mail não veio de uma conexão externa comprometida, mas sim do utilitário interno /usr/local/cpanel/bin/autorespond.
2. Falha grave no campo From: o usuário configurou o nome de exibição contendo outro e-mail:

   From: "[email protected]" <[email protected]>

1. Desalinhamento DMARC: os validadores externos comparam o Envelope-From da RFC 5321 (clientdomain.com) com o Header-From visual da RFC 5322 (anotherclient.com). Como os domínios não coincidiam, a mensagem foi recusada sumariamente.
2. Resposta a robôs: a mensagem original recebida pelo cliente era uma newsletter automática com endereço de retorno sem monitoramento (donotreply@). A resposta automática do cPanel tentou responder a um remetente automatizado, que recusou o recebimento, gerando um loop clássico de backscatter.

3. Causa raiz 2: o buraco negro do alias do root e a diretiva never_users#

Ao analisar mensagens acumuladas no spool direcionadas ao próprio hostname do servidor (host.provider.com), encontramos o seguinte erro em exim -Mvl:

2026-04-19 14:00:53 Received from <> R=1wEVVt-00000007hTy-051k U=mailnull P=local S=2279 T="Mail delivery failed: returning message to sender"
2026-04-19 14:00:53 [email protected] ([email protected]) <[email protected]> R=localuser_root : root cannot accept local mail deliveries
*** Frozen (delivery error message)

Por que o Exim bloqueia entregas locais para o UID 0#

No código-fonte do Exim, a diretiva never_users impede por padrão que o MTA entregue mensagens diretamente para contas com privilégios administrativos:

never_users = root

Quando um processo de sistema (como alertas do firewall CSF/LFD ou tarefas de cron) envia um relatório para root, o Exim tenta chamar o roteador local. Antes de executar a entrega no disco com setuid(0), ele valida se o UID de destino é 0. Ao constatar que se trata do root, ele aborta a gravação para proteger o sistema de ataques de sobrescrita de arquivos.

O acúmulo de mensagens congeladas#

Como a notificação original já era um aviso de falha (Received from <>), o Exim não pode gerar um bounce de outro bounce. A mensagem é marcada como Frozen e fica retida no spool (/var/spool/exim/input/).

Sem um alias configurado em /etc/aliases, todos os alertas de segurança e notificações do servidor ficavam eternamente congelados. A cada varredura periódica de fila (exim -q), o servidor tentava reprocessar esses itens, gerando conexões de rede inválidas e afundando a pontuação de reputação do IP.

4. Descartando cenários de invasão e tráfego clandestino#

Antes de aplicar as correções, é fundamental certificar-se de que o servidor não está sofrendo envios não autorizados:

Cenário de borda 1: Processos externos enviando diretamente pela porta 25#

Para garantir que nenhum binário ou script em espaço de usuário está abrindo conexões brutas de rede contornando o Exim:

# Inserir regra temporária de auditoria no iptables
iptables -I OUTPUT -p tcp --dport 25 -m owner ! --uid-owner mailnull -j LOG --log-prefix "SMTP_BYPASS_ATTEMPT: "

# Monitorar os logs do kernel
dmesg -w | grep "SMTP_BYPASS_ATTEMPT"

Se nenhum log com outros UIDs for exibido, confirma-se que todo o tráfego de saída passa pelo Exim.

Cenário de borda 2: Falsificação de HELO na entrada#

Conexões externas tentando se passar pelo IP do servidor podem poluir os relatórios de busca:

grep "rejected MAIL" /var/log/exim_mainlog | grep -E "Invalid HELO|HELO name" | head -n 5

Se o log mostrar conexões bloqueadas com closed by DROP in ACL, a regra de proteção acl_check_helo está barrando o spoofing na entrada sem comprometer a saída.

Cenário de borda 3: Encaminhamentos externos sem reescrita de remetente (SRS)#

Se um usuário encaminha mensagens para o Gmail mantendo o envelope original, o SPF inevitavelmente falhará. Verifique se o Sender Rewriting Scheme (SRS) está ativo:

grep -i "srs" /etc/exim.conf

Se estiver ausente, ative o suporte a SRS na interface do cPanel Exim Configuration Manager para preservar o alinhamento de SPF em mensagens redirecionadas.

5. Playbook de comandos para diagnóstico e remediação definitiva#

Abaixo estão os passos executados no terminal para normalizar o ambiente e zerar a fila:

Passo 1: Configurar o alias correto para o root#

Aponte as notificações de sistema do root para uma caixa postal monitorada com UID comum:

# Adicionar ou atualizar o alias no /etc/aliases
echo "root: [email protected]" >> /etc/aliases

# Reconstruir a base compilada de aliases
newaliases

# Testar o roteamento do root para confirmar o destino
exim -bt root

Saída esperada:

[email protected]
    <-- [email protected]
  router = virtual_user, transport = dovecot_virtual_delivery

Passo 2: Purgar mensagens congeladas do spool#

Remova todo o lixo eletrônico e notificações travadas que alimentavam os loops de reentrega:

# Purgar todas as mensagens congeladas da fila
exiqgrep -z -i | xargs -r exim -Mrm

# Reprocessar apenas mensagens legítimas pendentes
exim -qff -v

Passo 3: Auditar DNS reverso e alinhamento de SPF#

Certifique-se de que o rDNS do IP resolve exatamente para o hostname do servidor:

# Validar se o PTR corresponde ao HELO
host 192.0.2.1

# Verificar o registro TXT de SPF
dig txt infraestrutura.com +short

Rotina preventiva para proteger o score de reputação do IP#

Após aplicar o alias do root e limpar o spool, o Exim parou de rejeitar mensagens de sistema por violação de privilégios. Com a eliminação do tráfego circular de bounces e o ajuste no autoresponder, os sensores do TrendMicro ERS-QIL detectaram a queda na taxa de falhas e removeram o IP da lista de bloqueio nas 24 horas seguintes.

Para manter a operação saudável a longo prazo:

1. Nunca deixe o root sem alias definido: garanta que o /etc/aliases tenha um destino válido para que notificações do sistema não fiquem congeladas no spool.
2. Oriente os usuários sobre autoresponders: avise que o campo de nome de exibição não deve conter endereços de e-mail de outros domínios, evitando quebras de alinhamento DMARC.
3. Monitore a relação entre envios e falhas: mantenha um script simples em cron para alertar sempre que o número de mensagens com status frozen ultrapassar duas dezenas no spool.

Veja também

E-mail Anatomia de um ponteiro solto no Exim: depurando o erro "transport not found" em ambientes cPanel com smarthost e SRS

E-mail Anatomia de um e-mail preso em fila: logs de servidores, erros de digitação e a mecânica do Exim com smarthost

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

Este post está licenciado sob CC BY-NC.