A Armadilha do Forwarding e Loops de Backscatter no Exim: Como Evitar Bloqueios no SPFBL e UCEPROTECT-L3

A armadilha do forwarding e o veneno do backscatter em servidores Exim/cPanel#

Neste atendimento eu investiguei um caso que parece simples quando visto pelo painel, mas que fica muito mais interessante quando analisado por baixo, no Exim. O domínio estava sendo usado como ponte de encaminhamento para um destino externo, aqui vou chamar de domain.com, em um ambiente com cPanel/WHM sobre Exim, Imunify360 ativo e integração com Spam-Scanner por Pipe.

O sintoma principal era reputacional: o domínio foi listado no SPFBL como propagador de spam. O detalhe que mudou toda a análise foi que eu não encontrei, de início, os sinais clássicos de abuso direto. Não havia evidência clara de script PHP malicioso disparando e-mail a partir do diretório /home/user/public_html, não havia padrão óbvio de conta comprometida enviando via SMTP autenticado, e a trilha apontava muito mais para roteamento interno e encaminhamento do que para invasão simples.

Em outras palavras, eu não estava lidando com o caso clássico de cwd=/home/user/public_html, onde um arquivo PHP injeta spam via wrapper sendmail. O padrão que me interessava era outro:

cwd=/var/spool/exim

Quando o cwd aparece nessa área, eu penso em fila, roteamento, entrega, bounce, redirecionamento ou processamento interno do MTA. Isso não inocenta o servidor, mas muda a pergunta. Em vez de perguntar "qual script está mandando spam?", eu passei a perguntar "qual fluxo legítimo está transformando meu servidor em origem reputacional de lixo?".

1. O cenário técnico#

O ambiente de produção auditado contava com as seguintes camadas integradas:

• cPanel/WHM como painel de controle administrativo do servidor;
• Exim atuando como o Message Transfer Agent (MTA) principal;
• Imunify360 como firewall de borda e sistema de segurança ativa;
• Spam-Scanner integrado via Pipe para a análise de conteúdo;
• Domínio local configurado com encaminhadores ativos para contas externas (Gmail, Outlook, Microsoft 365);
• SPFBL monitorando reputação de IPs e impondo listagens de spam;
• Dovecot atuando como autenticador SASL para o envio de e-mails via SMTP autenticado.

O domínio local recebia e-mails legítimos e ilegítimos e os encaminhava imediatamente para outro provedor. Este tipo de fluxo ("forwarder") é muito comum em servidores de hospedagem compartilhada, mas em 2026 ele introduz grandes riscos operacionais devido ao aperto das políticas antispam globais.

2. O sintoma e reputação no SPFBL#

O SPFBL passou a enxergar o domínio ou o IP do servidor como uma fonte ativa de spam. O bloqueio ocorreu mesmo sem os seguintes indicadores clássicos:

• Script malicioso localizado sob o diretório /home/user/public_html;
• Envio massivo originado por conexões diretas via SMTP autenticado;
• Fila de e-mails composta majoritariamente por mensagens criadas no próprio servidor.

Isso demonstra que a verificação de segurança tradicional baseada puramente em malware de arquivos falha em identificar o problema. O SPFBL avalia o comportamento dinâmico de entrega e reputação de envio do IP. Se o servidor replica mensagens problemáticas recebidas de terceiros, ele é classificado como o vetor de spam, independentemente de quem o originou.

3. Mecânica do forwarding e a armadilha do SRS#

O coração do problema reside no Sender Rewriting Scheme (SRS). Quando um remetente externo envia uma mensagem para a caixa local encaminhada:

[email protected] -> [email protected] -> [email protected]

Se o Exim simplesmente encaminhar o e-mail mantendo o envelope original (MAIL FROM: [email protected]), o servidor de destino final avaliará o registro SPF de externo.com. Como o IP do nosso servidor cPanel não está listado no SPF daquele domínio de origem, a mensagem falhará no teste SPF e será descartada ou marcada como spam.

Para contornar isso, o Exim reescreve o envelope de retorno no formato do SRS:

[email protected]

Essa reescrita faz com que o servidor local passe a assinar a autoria do caminho de retorno. Embora isso resolva a validação SPF para mensagens legítimas no destino final, cria uma armadilha reputacional crítica: o servidor local assume a "paternidade" de qualquer lixo encaminhado. Se a mensagem encaminhada for spam, o receptor externo penalizará o nosso IP de envio.

4. O veneno do backscatter#

O Backscatter (retrodispersão) é o efeito colateral mais destrutivo desse ecossistema. Ele ocorre quando o servidor aceita a mensagem para encaminhamento, reescreve-a via SRS, envia para o destino final, e este destino rejeita o e-mail (por exemplo, retornando um erro 550 Spam Rejected ou 550 User Unknown).

Diante da rejeição do destino externo, o nosso MTA sente a obrigação de gerar uma Notificação de Status de Entrega (DSN ou Bounce) de volta para o remetente original. Contudo, como spammers frequentemente forjam o remetente original, o nosso servidor acaba disparando e-mails de bounce para vítimas inocentes.

O fluxo de backscatter é estruturado assim:

1. O spammer envia mensagem com remetente forjado;
2. Nosso servidor aceita o e-mail e aplica o SRS;
3. O e-mail é encaminhado para o destino final (ex: Gmail);
4. O destino final rejeita o e-mail por ser spam;
5. Nosso Exim gera um bounce e o envia para o remetente forjado (a vítima);
6. O IP do nosso servidor entra em RBLs por emitir bounces não solicitados (backscatter).

5. Auditoria de fila, cotas e disco#

Antes de intervir no software, um diagnóstico essencial envolve avaliar o estado do armazenamento físico e limites de cota da fila do Exim. Se as partições que abrigam os spools ou logs do MTA estiverem cheias, o Exim pode falhar na escrita de transações temporárias, gerando arquivos de banco de dados internos corrompidos e travamentos silenciosos na entrega de e-mails.

Para auditar o espaço em disco nas partições de spool e logs, execute os comandos:

# Verificar espaço em disco nas partições cruciais
df -h /var/spool/exim
df -h /var/log

Em seguida, avalie o tamanho total e o comportamento da fila do Exim para determinar se há um acúmulo anormal de mensagens congeladas (frozen) ou bounces pendentes:

# Verificar contagem de mensagens na fila
exim -bpc

# Listar mensagens ativas na fila de envio
exim -bp

Se o volume de mensagens na fila for desproporcional à operação normal, ou se a partição do diretório /var/spool/exim estiver próxima do limite de uso, as entregas legítimas sofrerão atrasos severos, piorando a reputação do servidor.

6. Triagem forense de fila e fluxo com exigrep#

O utilitário exigrep é uma ferramenta indispensável no ecossistema do Exim. Como o log principal de transações /var/log/exim_mainlog registra eventos de forma assíncrona, usar um grep puro fragmenta o diagnóstico, pois as linhas de recebimento, entrega e erro de um único e-mail são misturadas com milhares de outras conexões concorrentes.

Para agrupar todas as linhas pertencentes a uma transação específica para um domínio envolvido, usamos o comando:

zgrep "domain.com" /var/log/exim_mainlog* | exigrep -l "domain.com"

A flag -l instrui o utilitário a mostrar apenas a linha inicial de cada transação, facilitando a identificação dos IDs das mensagens suspeitas. O exigrep lê o identificador único de mensagem (Message-ID do Exim) e extrai todo o bloco atômico de log correspondente àquela mensagem do início ao fim, mostrando a trilha completa de roteamento e tentativas de entrega.

7. Rastreio de UID, GID e cwd#

Uma etapa chave para diferenciar injeção de código web (malware) de problemas de roteamento é auditar o diretório de trabalho atual (cwd) de onde os e-mails estão sendo injetados na fila.

Para buscar por e-mails associados a um usuário específico e seu respectivo cwd, execute:

grep "user" /var/log/exim_mainlog | grep "cwd="

• cwd=/home/user/public_html: Indica que um script web executado sob a conta do usuário originou a mensagem (como um formulário PHP vulnerável ou webshell injetada);
• cwd=/var/spool/exim: Indica que a mensagem está sendo processada de maneira interna pelo MTA (roteamento de fila, bounces, ou e-mails encaminhados via forwarders).

Esta divisão metodológica previne a perda de tempo na varredura de malwares em arquivos do site quando o problema é puramente uma falha de política de encaminhamento e roteamento lógico de correio.

8. Auditoria de autenticação Dovecot#

Apesar dos indícios apontarem para o forwarding-induced spam, o analista deve sempre descartar a hipótese de contas SMTP locais comprometidas (com credenciais fracas ou vazadas). No cPanel, o Dovecot gerencia o SASL para a autenticação SMTP do Exim.

Para auditar e tabular a quantidade de e-mails enviados via conexões SMTP autenticadas por um usuário específico, agrupe as origens dos IPs usando o comando:

grep "dovecot_login:user" /var/log/exim_mainlog | awk '{print $NF}' | sort | uniq -c

Se a saída mostrar um grande volume de envios a partir de IPs geográficos suspeitos, a conta local de e-mail deste usuário deve ter sua senha redefinida imediatamente e as configurações de segurança de SMTP devem ser enrijecidas.

9. Detecção do ghost forwarder e arquivos de roteamento#

Um comportamento anômalo comum em servidores Exim/cPanel é o chamado "Ghost Forwarder". Nele, a interface gráfica do cPanel não exibe nenhum encaminhador ativo para o domínio, mas o Exim continua redirecionando mensagens para caixas postais externas. Isso ocorre devido a corrupções de arquivos de índice ou inserções manuais diretas no filesystem do servidor.

A verdade absoluta sobre o roteamento de aliases e filtros é obtida inspecionando os arquivos brutos do sistema:

# Visualizar aliases de encaminhamento do domínio
cat /etc/valiases/domain.com

# Visualizar regras de filtros customizados de e-mail
cat /etc/vfilters/domain.com

Estes arquivos contam com mapas de reescrita lidos em tempo de execução pelo Exim. Se houver entradas de redirecionamento para domínios externos não cadastradas na interface, elas devem ser removidas diretamente nestes caminhos, e os bancos de dados de cache do painel devem ser atualizados.

10. Comprometimento de clientes e strace#

Quando um cliente de e-mail local (Outlook, Thunderbird ou dispositivo móvel) está infectado por malware, ele pode disparar spams usando as credenciais válidas do usuário. Nesses cenários, o envio parece 100% legítimo nos logs de autenticação.

Para auditar processos ativos do Exim e verificar em tempo real o que está sendo escrito nos sockets de conexão de rede sem abrir o conteúdo completo da mensagem (respeitando limites de privacidade), use o comando:

strace -p <PID_DO_PROCESSO_EXIM> -s 80 -e write

Esse comando rastreia a chamada de sistema write() executada pelo processo Exim correspondente, mostrando os primeiros 80 caracteres de dados passados. Isso ajuda a identificar strings repetitivas de spam, cabeçalhos forjados e comandos SMTP anômalos no momento exato em que a transação ocorre.

11. Validação da pilha de entrega (conectividade e portas)#

Para certificar que o Exim está operando nas portas corretas e que a pilha de entrega de rede está saudável e acessível, verifique as portas de escuta do serviço no host:

# Validar portas ativas do Exim no servidor
ss -lntp | grep -E "25|465|587"

Se as portas corretas estiverem em escuta, audite as regras de entrada e saída no firewall do servidor. Caso utilize o ConfigServer Security & Firewall (CSF), garanta que as portas SMTP estão liberadas no arquivo de configuração /etc/csf/csf.conf:

# Exemplo de configuração de liberação de portas no /etc/csf/csf.conf
TCP_IN = "25,465,587,993,995"
TCP_OUT = "25,465,587,993,995"

Por fim, execute testes manuais de conectividade de rede nas portas SMTP a partir de uma origem externa ou da linha de comando interna para garantir que o serviço responde adequadamente:

# Testar conexão básica na porta 25 via netcat
nc -zv mail.domain.com 25

# Testar conexão SMTP interativa
telnet mail.domain.com 25

# Testar handshake TLS SMTP seguro
openssl s_client -connect mail.domain.com:25 -starttls smtp

12. Verificação de DKIM, DMARC e assinatura no forwarding#

Em fluxos de encaminhamento, as mensagens precisam manter a assinatura DKIM válida do remetente original, ou o servidor que encaminha deve assinar em seu próprio nome para passar no alinhamento DMARC. Caso o registro DKIM ou DMARC esteja ausente ou configurado incorretamente, o destino final recusará a mensagem.

Verifique se a chave pública DKIM configurada no servidor confere com a entrada DNS publicada:

# Verificar registro DKIM local
opendkim-testkey -d domain.com -s default -vvv

Em seguida, consulte a política DMARC ativa para o domínio:

# Verificar política DMARC do domínio via DNS
dig TXT _dmarc.domain.com

Para garantir que o módulo OpenDKIM do servidor está habilitado para realizar a assinatura de e-mails de saída, verifique se a diretiva correspondente está ativa em seu arquivo de configuração /etc/opendkim.conf:

grep -i "Signing" /etc/opendkim.conf

13. Plano de backups e rollback de segurança#

Alterações em configurações críticas de correio eletrônico e regras de firewall exigem a execução prévia de um plano de backup estruturado para possibilitar a restauração do estado original do servidor caso ocorra algum downtime operacional inesperado.

Procedimento de backup preventivo#

Antes de modificar qualquer parâmetro, execute os comandos de cópia de segurança a seguir:

# 1. Backup do arquivo de configuração principal do Exim
cp /etc/exim.conf /root/exim.conf.bak.$(date +%Y%m%d)

# 2. Backup recursivo de aliases de encaminhamento
cp -r /etc/valiases/ /root/valiases-backup/

# 3. Backup das regras ativas do Firewall iptables
iptables-save > /root/iptables-backup-$(date +%Y%m%d).rules

Procedimento de rollback e reversão#

Caso as alterações quebrem o fluxo de correio, reverta as configurações utilizando o seguinte roteiro:

# 1. Restaurar arquivo de configuração do Exim
cp /root/exim.conf.bak.YYYYMMDD /etc/exim.conf

# 2. Restaurar aliases de e-mail originais
cp -r /root/valiases-backup/* /etc/valiases/

# 3. Restaurar regras de firewall
iptables-restore < /root/iptables-backup-YYYYMMDD.rules

# 4. Reiniciar o serviço Exim
systemctl restart exim

# 5. Validar integridade básica do Exim
exim -bV

14. Diagnóstico avançado de logs do Exim#

A análise forense da saúde do correio depende da leitura atenta dos arquivos de logs dinâmicos do Exim. O arquivo principal de log do Exim no cPanel está localizado em /var/log/exim_mainlog.

Abaixo estão listados os comandos para isolar comportamentos específicos de erros operacionais:

# 1. Visualizar as últimas 100 linhas do log principal
tail -100 /var/log/exim_mainlog

# 2. Rastrear rejeições de e-mails (erros de envio/recusa do destino)
grep -i "reject\|denied" /var/log/exim_mainlog | tail -20

# 3. Rastrear e-mails retornados (bounces) ou congelados (frozen) na fila
grep -i "bounce\|frozen" /var/log/exim_mainlog | tail -20

# 4. Rastrear tentativas de login de autenticação via Dovecot
grep -i "dovecot_login\|dovecot_plain" /var/log/exim_mainlog | tail -20

15. Validação de sintaxe do Exim#

Erros de sintaxe simples no arquivo /etc/exim.conf podem impedir que o serviço Exim inicialize pós-restart, deixando o servidor sem a capacidade de processar e-mails. Sempre valide as alterações de configuração antes de aplicar reinicializações.

Use as ferramentas nativas do Exim para validar a integridade lógica da estrutura:

# Verificar sintaxe geral e integridade do arquivo exim.conf
exim -bV

# Visualizar a árvore de configuração ativa completa e opções
exim -bP | head -20

# Executar teste em modo interativo de debug para capturar avisos
exim -d -v 2>&1 | grep -i "error\|warn"

Se qualquer erro sintático ou aviso for reportado na saída destes comandos, revise a alteração efetuada antes de recarregar o serviço.

16. Mitigação no Exim e alternativa push vs pull#

Para resolver permanentemente os problemas de reputação gerados por forwarding, a melhor abordagem arquitetural é trocar o modelo de fluxo de mensagens de Push (encaminhamento ativo) para Pull (coleta remota).

• Modelo Push (Forwarding): Nosso servidor recebe o e-mail, reescreve-o com SRS e o empurra para o Gmail. Se o e-mail for spam, nosso IP é penalizado; se falhar, lidamos com o backscatter.
• Modelo Pull (Coleta Remota via POP3/IMAP): O cliente configura sua conta de e-mail externa (como o Gmail) para conectar na nossa caixa postal local via POP3/IMAP e puxar as mensagens.

No modelo Pull, nosso servidor atua apenas como um repositório seguro. O correio indesejado é classificado localmente e fica guardado na pasta de spam, sem gerar qualquer tentativa de envio de saída para terceiros e sem expor a reputação do IP do servidor.

Quando o cliente exige a manutenção do encaminhador de e-mails ativo por razões de fluxo de trabalho, aplique as seguintes mitigações nas configurações do Exim via cPanel/WHM:

1. Mantenha o Sender Rewriting Scheme (SRS) ativado globalmente (isso previne a quebra de SPF de e-mails válidos);
2. Habilite a opção "Do not forward mail to external recipients if it is detected as spam" no painel de controle do WHM. Isso força a validação antispam local antes de disparar o roteador de encaminhamento externo, retendo as ameaças no próprio servidor.

17. Monitoramento proativo de reputação#

Para evitar descobrir bloqueios de IPs apenas quando os clientes reportarem erros de entrega, configure uma rotina de monitoramento contínuo das principais Real-time Blackhole Lists (RBLs) globais e APIs de reputação.

Você pode implementar uma verificação ágil em shell para consultar o IP do servidor em listas públicas:

# Loop simples de consulta de reputação do IP nas RBLs
IP="SEU_IP_AQUI"
for rbl in zen.spamhaus.org bl.spamcop.net; do
    result=$(dig +short $(echo $IP | awk -F. '{print $4"."$3"."$2"."$1}').$rbl)
    if [ -n "$result" ]; then
        echo "LISTADO na RBL $rbl: $result"
    fi
done

Adicionalmente, consulte o status reputacional do IP diretamente através da API pública do SPFBL:

curl -s "http://spfbl.net/api/v1/check/SEU_IP_AQUI"

18. Bloqueios em Larga Escala por ASN (UCEPROTECT-L3), Loops em .forward e Smart Host#

Quem administra servidores de e-mail com cPanel e Exim em grandes provedores de nuvem (como OVH, Hetzner ou DigitalOcean) já deve ter se deparado com rejeições em massa onde o IP do servidor não tem histórico de spam, mas as mensagens são recusadas por bloqueios em nível de provedor.

Para piorar o cenário, um erro comum de configuração interna pode transformar essa rejeição externa em uma tempestade local: centenas de notificações de erro circulando indefinidamente entre o root e o daemon de e-mail, lotando o spool do Exim com mensagens congeladas.

Neste artigo, vamos analisar um caso real em que o bloqueio UCEPROTECT-Level3 interagiu com um arquivo /root/.forward mal configurado, dissecando o fluxo de logs, o descarte de hipóteses de invasão e o script de remediação definitiva.

O bloqueio por ASN: o que é o UCEPROTECT nível 3#

O incidente costuma começar com uma rejeição no log do Exim (/var/log/exim_mainlog) ao tentar entregar uma mensagem legítima:

2026-06-18 16:00:00 H=mx.remote.com [192.0.2.1]: SMTP error from remote mail server after RCPT TO:<[email protected]>: 550-5.7.1 Service unavailable; Client host [40.160.3.114] blocked using UCEPROTECT-Level3

E no relatório da lista de reputação:

Reason for listing - Your ISP OVH, FR/AS16276 is UCEPROTECT-Level3 listed because of a spamscore of 216.

Como essa lista opera#

Ao contrário de listas de reputação comuns que bloqueiam endereços IP isolados (Nível 1) ou faixas de sub-rede /24 (Nível 2), o UCEPROTECT-Level3 avalia o número de sistema autônomo (ASN) inteiro do provedor.

Se outros clientes daquele mesmo datacenter dispararem spam em volume suficiente para elevar a pontuação agregada do ASN nos últimos 7 dias, todos os IPs daquele provedor entram na lista de bloqueio, mesmo que o seu servidor específico tenha reputação impecável.

O diálogo SMTP durante o bloqueio#

Quando o Exim tenta entregar o e-mail:

1. O kernel abre a conexão TCP de saída via connect() com o servidor de destino na porta 25.
2. O servidor remoto responde com o banner SMTP (220) e o Exim envia o comando EHLO.
3. Na fase RCPT TO:<[email protected]>, o MTA de destino consulta a lista em formato DNS reverso: <IP_invertido>.dnsbl.uceprotect.net.
4. Como o ASN está listado, o destino responde imediatamente com 550 5.7.1 Service unavailable e encerra a conexão.

Detecção de acúmulo anormal de double bounces na fila local#

Ao rodar uma verificação de rotina na fila de e-mails para entender o volume de mensagens retidas:

exim -bp | exiqsumm

A saída revelou uma distribuição muito estranha:

Count  Volume  Oldest  Newest  Domain
-----  ------  ------  ------  ------
    1    48KB     50m     50m  domain_a.com
    5   330KB      8h      8h  domain_b.com
  291    13MB     24h      0m  hostname.domain.com
   11  1224KB     23m     23m  domain_c.com
---------------------------------------------------------------
  327    24MB     72h      0m  TOTAL

O que essa contagem indica#

Das 327 mensagens na fila, 291 estavam endereçadas para o próprio hostname do servidor (hostname.domain.com), com a mais recente gerada há zero minutos (Newest: 0m). Havia um vazamento contínuo gerando mensagens locais a cada poucos segundos.

Para listar os identificadores dessas mensagens no spool:

exiqgrep -i -r "hostname.domain.com"

Inspecionando os cabeçalhos de uma delas com exim -Mvh:

1wFdCz-0000000EPmH-2H54-H
mailnull 47 12
<>
1776885961 0
-ident mailnull
-received_protocol local
-frozen 1776885961
-localerror
XX
[email protected]

182P Received: from mailnull by hostname.domain.com with local (Exim 4.99.1)
        id 1wFdCz-0000000EPmH-2H54
        for [email protected];
        Wed, 22 Apr 2026 16:26:01 -0300
054  X-Failed-Recipients: [email protected]
029  Auto-Submitted: auto-replied
071F From: Mail Delivery System <[email protected]>
039T To: [email protected]
059  Subject: Mail delivery failed: returning message to sender

Decodificando o mecanismo de erro#

• mailnull 47 12: o usuário do sistema que gerou a mensagem foi o mailnull, utilizado pelo próprio Exim para processar erros e notificações de entrega.
• Remetente vazio (<>): padrão da RFC 5321 para mensagens de bounce (notificações de falha), projetado para que servidores não respondam automaticamente a notificações de erro.
• -localerror e -frozen: a mensagem foi congelada pelo Exim após falhar repetidamente em suas tentativas de entrega local.
• X-Failed-Recipients: [email protected]: a tentativa original que falhou tinha como destino o usuário root.

O ciclo do double bounce em detalhes via .forward#

Ao investigar as configurações de redirecionamento do usuário root:

cat /root/.forward

O arquivo continha uma única linha:

[email protected]

O ciclo do double bounce em detalhes#

A combinação dessa linha com o bloqueio de ASN gerou uma reação em cadeia:

1. Gatilho de sistema: tarefas agendadas no cron do servidor ou alertas de segurança do firewall (como o lfd do CSF) geram mensagens de aviso para root.
2. Leitura do .forward: o Exim lê /root/.forward e expande o destinatário para [email protected].
3. Desvio para transporte remoto: se o hostname não estiver explicitamente configurado no arquivo /etc/localdomains, o Exim decide que hostname.domain.com deve ser resolvido via DNS externo (roteador lookuphost) e despachado pela internet via remote_smtp.
4. Rejeição externa por RBL: o gateway externo que responde pelo domínio recusa a conexão porque o IP do servidor pertence a um ASN listado no UCEPROTECT-L3.
5. Geração do bounce circular: o Exim tenta devolver a notificação de falha para quem gerou o e-mail (o usuário de sistema cpanel ou root). A notificação bate novamente no arquivo .forward, criando um loop infinito de reenvios.
6. Congelamento protetivo: percebendo que a notificação de erro não pode ser entregue, o Exim congela a mensagem no spool para evitar exaustão de CPU.

Descartando outros cenários de vazamento no servidor#

Antes de limpar a fila, vale a pena descartar se o servidor não está sofrendo envios abusivos por outros vetores:

Hipótese 1: Disparos via scripts PHP locais#

Se uma aplicação web comprometida estivesse disparando spam via mail() do PHP:

grep -r "X-PHP-Originating-Script" /var/spool/exim/input/

Se o retorno for vazio, não há injeção de mensagens originadas por scripts PHP em execução no Apache ou PHP-FPM.

Hipótese 2: Credenciais de autenticação SMTP comprometidas#

Para conferir se alguma conta de e-mail do servidor foi invadida e está enviando tráfego não autorizado:

grep "P=esmtpa" /var/log/exim_mainlog | awk -F'A=' '{print $2}' | sort | uniq -c | sort -n

Se nenhuma conta apresentar milhares de disparos concentrados em pouco tempo, as credenciais de clientes estão seguras.

Hipótese 3: Processos externos enviando diretamente pela porta 25#

Para garantir que nenhum binário invasor está abrindo conexões brutas de rede sem passar pelo Exim:

lsof -i :25 -n -P | grep -v "exim"

Se apenas os processos do Exim estiverem ouvindo na porta 25, não há tráfego paralelo contornando o MTA.

Script automatizado de saneamento e purga do spool#

O script abaixo resolve o loop interno, purga mensagens órfãs da fila e garante que mensagens de sistema do root sejam tratadas localmente:

#!/usr/bin/env bash
# ==============================================================================
# Saneamento de Spool e Correção de Loops no Exim
# ==============================================================================
set -euo pipefail

echo "[+] 1. Removendo arquivo de redirecionamento que causa o loop..."
if [ -f /root/.forward ]; then
    rm -f /root/.forward
    echo "[✔] Arquivo /root/.forward removido com sucesso."
fi

echo "[+] 2. Purgando mensagens de bounce congeladas da fila..."
# Remove mensagens congeladas com remetente vazio (<>)
exiqgrep -i -f '^<>$' | xargs -r exim -Mrm

# Remove mensagens retidas para o próprio hostname
exiqgrep -i -r "$(hostname)" | xargs -r exim -Mrm
echo "[✔] Spool do Exim limpo."

echo "[+] 3. Configurando destino local seguro no /etc/aliases..."
# Garante que saídas de sistema do root sejam descartadas ou fiquem locais
if ! grep -q "^root:" /etc/aliases; then
    echo "root: /dev/null" >> /etc/aliases
else
    sed -i 's/^#\?root:.*/root: \/dev\/null/g' /etc/aliases
fi

newaliases
echo "[✔] Base de aliases reconstruída."

echo "[+] 4. Garantindo hostname em /etc/localdomains..."
HOSTNAME_STR=$(hostname)
if ! grep -q "${HOSTNAME_STR}" /etc/localdomains; then
    echo "${HOSTNAME_STR}" >> /etc/localdomains
    echo "[✔] Hostname adicionado a /etc/localdomains."
fi

echo "[+] Concluído com sucesso."

Estratégia definitiva: roteamento via Smart Host para contornar bloqueios de ASN#

Depois de eliminar o loop local, o servidor volta a operar com a fila limpa. No entanto, o problema de base com a lista UCEPROTECT-Level3 persiste para mensagens enviadas a servidores que adotam essa verificação.

Listas que bloqueiam ASNs inteiros colocam todos os clientes do datacenter no mesmo saco, e pagar taxas de remoção temporária para serviços de reputação controversa não resolve o problema a médio prazo.

A abordagem mais sólida para servidores em provedores com ASNs frequentemente listados é desacoplar a entrega de e-mails do IP do servidor utilizando um serviço de Relay SMTP (Smarthost) externo, como Amazon SES, SendGrid ou Mailgun:

1. No cPanel, abra a Exim Configuration Manager no WHM (modo Advanced).
2. Na seção ROUTERSTART, configure a rota para enviar mensagens externas através do relay autenticado.
3. Na seção TRANSPORTSTART, configure o transporte SMTP com TLS e as credenciais fornecidas pelo serviço de entrega.

Dessa forma, o tráfego de e-mails dos clientes passa a utilizar os IPs e a reputação do provedor especializado em entregabilidade, tornando a operação imune a bloqueios de ASN provocados por vizinhos de datacenter.

19. Checklist Operacional Integrado e Matriz de Riscos#

Checklist operacional de triagem e mitigação Exim/forwarding#

• [ ] Diagnóstico Inicial: Auditar espaço físico do spool /var/spool/exim e verificar logs iniciais.
• [ ] Triagem de Mensagens: Agrupar transações assíncronas do Exim com exigrep.
• [ ] Análise de Injeção: Checar o parâmetro cwd dos logs para isolar injeções web (public_html) de roteamentos de fila.
• [ ] Auditoria de Aliases: Inspecionar fisicamente os arquivos de mapeamento /etc/valiases/domain.com e /etc/vfilters/domain.com.
• [ ] Backups Preventivos: Salvar cópias de segurança do arquivo exim.conf, aliases e regras de firewall.
• [ ] Validação Antispam: Ativar o bloqueio de encaminhamento de spam detectado localmente no WHM.
• [ ] Ajuste de Fluxo: Encaminhar migração do fluxo de Push (forwarder) para Pull (coleta POP3/IMAP) com o cliente.
• [ ] Verificação de DKIM/DMARC: Validar as chaves de assinatura do domínio e registros DMARC publicados.
• [ ] Auditoria de Conectividade: Testar portas SMTP de escuta do Exim e regras de liberação de portas do firewall.
• [ ] Monitoramento de Reputação: Agendar verificações periódicas do IP nas RBLs e na API do SPFBL.

Matriz de riscos operacionais e de entrega#

Veja também

Infraestrutura Quando o filesystem e o daemon entram em desincronia

Servidores Anatomia de uma falha em cascata: do bloqueio de IP por spam à depuração do Roundcube no cPanel

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

Este post está licenciado sob CC BY-NC.