Resolvendo o erro intermitente: AUTH command used when not advertised no Exim (cPanel)

Diagnóstico do erro de autenticação intermitente no Exim#

Administrar servidores de e-mail com Exim em ambientes cPanel/WHM envolve lidar com falhas intermitentes de conexão. Recentemente, analisei um caso em que uma aplicação WordPress (usando o plugin Post SMTP) em um servidor externo falhava aleatoriamente ao enviar e-mails via SMTP autenticado, retornando o seguinte erro:

AUTH command used when not advertised

Curiosamente, o envio via Webmail (Roundcube) e clientes locais (como Thunderbird) funcionava normalmente. O problema ocorria apenas nas conexões da aplicação remota com o servidor sob minha administração.

Abaixo, detalho o diagnóstico passo a passo, a auditoria de segurança e a correção definitiva do problema usando as ACLs do Exim.

1. Preparação: backup de segurança#

Antes de alterar qualquer parâmetro do servidor de e-mail em produção, é obrigatório realizar o backup das configurações atuais:

# Backup individual da configuração do Exim
cp /etc/exim.conf /etc/exim.conf.bak.$(date +%Y%m%d)

# Backup completo do diretório de configurações do Exim
tar czf /root/exim-backup-$(date +%Y%m%d).tar.gz /etc/exim.conf /etc/exim/

Nota: No cPanel, você também pode exportar as configurações do Exim acessando: WHM » Exim Configuration Manager » Backup.

2. Validação da camada de segurança SSL/TLS#

O erro AUTH command used when not advertised ocorre porque o Exim deixa de anunciar o método de autenticação (AUTH) quando detecta que a conexão não é segura ou falhou em estabelecer uma sessão TLS estável.

Abaixo, o fluxo de decisão demonstra a tomada de decisão do Exim para a exibição ou supressão do recurso AUTH dependendo do status da negociação TLS:

Passo a: verificar certificado e versão do TLS#

Use o comando openssl para validar a expiração do certificado SSL, protocolos ativos e cifras de rede aceitas:

# Verificar datas de validade do certificado de e-mail
openssl s_client -connect mail.meudominio.com.br:465 </dev/null 2>/dev/null | openssl x509 -noout -dates

# Verificar protocolo e cifras negociadas
openssl s_client -connect mail.meudominio.com.br:465 </dev/null 2>/dev/null | grep -E "Protocol|Cipher"

# Testar se o STARTTLS funciona na porta 587
openssl s_client -connect mail.meudominio.com.br:587 -starttls smtp

Passo b: consultar as respostas EHLO do Exim#

Inicie uma conexão SMTP crua e envie o comando EHLO para ver quais recursos o Exim anuncia:

# Conexão SMTP via openssl
openssl s_client -connect mail.meudominio.com.br:465

# Após o estabelecimento do TLS, envie:
EHLO app.cliente.com.br

Se a saída omitir a linha 250-AUTH LOGIN PLAIN, o Exim optou por suprimir os métodos de autenticação para essa conexão específica:

220-server.meuhost.com.br ESMTP Exim 4.99.1
250-server.meuhost.com.br Hello app.cliente.com.br [203.0.113.50]
250-SIZE 52428800
250-LIMITS MAILMAX=1000 RCPTMAX=50000
250-8BITMIME
250-PIPELINING
250-PIPECONNECT
250 HELP

3. Diagnóstico e triagem com logs do Exim#

Para entender por que o anúncio de autenticação foi suprimido, é preciso analisar os logs do Exim e o comportamento da conexão.

Passo a: identificar o IP correto do cliente#

Se a aplicação SMTP remota está hospedada em outra plataforma, descubra o seu IP real antes de analisar os logs:

# Executar a partir da máquina cliente para descobrir o IP de saída
curl -s ifconfig.me

# Ou pesquisar nos logs do servidor de e-mail pelo domínio do cliente
grep "app.cliente.com.br" /var/log/exim_mainlog | tail -n 5

# Confirmar o reverso do IP identificado
dig -x 203.0.113.50 +short

Passo b: investigar os logs de erro do Exim#

Monitore o arquivo /var/log/exim_mainlog filtrando por rejeições, erros de TLS ou falhas de autenticação com o IP em questão:

# Logs gerais do Exim em tempo real
tail -f /var/log/exim_mainlog | grep "203.0.113.50"

# Filtrar especificamente erros de autenticação ou conexões rejeitadas
grep -E "auth|rejected|denied" /var/log/exim_mainlog | tail -n 20

# Verificar logs relacionados a TLS
grep "TLS" /var/log/exim_mainlog | tail -n 20

Se você encontrar erros como estes nos logs: TLS error on connection from app.cliente.com.br [203.0.113.50]: SSL_accept: TCP connection closed by peer

Significa que a aplicação remota fechou abruptamente o socket TCP no início da negociação do TLS. Como o handshake falhou intermitentemente, o Exim desativou a autenticação para proteger o envio de credenciais.

Passo c: emulação de conexão com exim -bh#

É possível testar como o Exim reage à conexões de um determinado IP de forma simulada:

exim -bh 203.0.113.50

Digite EHLO app.cliente.com.br na sessão interativa e veja se há regras de ACL que bloqueiam ou suprimem recursos específicos.

4. A solução: permitir AUTH não anunciado para IPs confiáveis#

Para resolver a instabilidade sem enfraquecer a segurança de todo o servidor, criei uma regra no Exim permitindo que apenas o IP específico da aplicação remota (203.0.113.50) faça autenticação mesmo se o anúncio de AUTH for suprimido durante falhas de negociação.

Passo a: configuração via WHM (recomendado)#

Não edite diretamente /etc/exim.conf, pois o cPanel sobrescreverá suas alterações. Use o painel administrativo:

1. Acesse: WHM » Exim Configuration Manager » Advanced Editor.
2. Procure pela seção: custom_begin_smtp_helo.
3. Insira o seguinte bloco de código:

# 1. Bloqueio padrão de segurança (Mantenha se houver regras pré-existentes)
# Nota: Verifique se o arquivo /etc/heloblocks existe para evitar avisos ou erros de lookup
drop
condition = ${if exists{/etc/heloblocks}{${lookup{$sender_helo_name}lsearch{/etc/heloblocks}{yes}{no}}}{no}}
log_message = HELO/EHLO - HELO on heloblocks Blocklist
message = HELO on heloblocks Blocklist

# 2. Solução: Permitir AUTH não anunciado para o IP da aplicação confiável
warn
hosts   = 203.0.113.50
control = allow_auth_unadvertised

# 3. Aceite padrão
accept

Passo b: aplicar configuração e reiniciar o serviço#

Após salvar as alterações na interface do WHM, as regras serão salvas e o Exim será reiniciado automaticamente. Caso prefira validar e reiniciar manualmente via CLI:

# Validar sintaxe da configuração completa e checar se há erros
exim -bV

# Validar se as regras de allow_auth_unadvertised foram gravadas
grep -r "allow_auth_unadvertised" /etc/exim.conf

# Verificar se a configuração do Exim carrega com sucesso
exim -C /etc/exim.conf -bP | head -n 5

# Reiniciar o serviço do Exim de forma segura
/scripts/restartsrv exim

5. Verificação pós-configuração#

Após aplicar a correção, valide se o bypass funciona de maneira adequada:

1. Testar via simulação do Exim#

Execute a simulação novamente (lembrando que esse utilitário exige privilégios de root) e verifique se o controle permite o uso do AUTH mesmo sem o anúncio:

exim -bh 203.0.113.50
# Envie os comandos na ordem:
EHLO app.cliente.com.br
AUTH PLAIN dGVzdG9wZXJhdGlvbmFs

2. Confirmar configuração ativa#

Verifique se a variável do Exim está configurada conforme planejado:

exim -bP auth_advertise_hosts

3. Teste SMTP manual completo#

É possível testar o envio de e-mails de locais externos.

# Teste de handshake TLS na porta 465 (implícita)
echo "" | openssl s_client -connect mail.meudominio.com.br:465 -quiet 2>/dev/null

# Teste seguro com curl usando arquivo de credenciais
# 1. Crie um arquivo de credenciais temporário com permissões restritas
cat > ~/.smtptestrc << 'EOF'
machine mail.meudominio.com.br
login [email protected]
password senha_aqui
EOF
chmod 600 ~/.smtptestrc

# 2. Execute o curl consumindo o arquivo de credenciais
curl --ssl-reqd --url "smtps://mail.meudominio.com.br:465" \
  --netrc-file ~/.smtptestrc \
  --mail-from "[email protected]" \
  --mail-rcpt "[email protected]" \
  -v

# 3. Remova o arquivo de credenciais do ambiente
rm -f ~/.smtptestrc

6. Plano de rollback#

Caso as alterações causem algum comportamento imprevisto no fluxo de e-mails, siga este roteiro de rollback imediato:

Rollback via CLI#

# Restaurar arquivo de configuração original do backup mais recente
cp "$(ls -t /etc/exim.conf.bak.* 2>/dev/null | head -1)" /etc/exim.conf

# Reiniciar o serviço do Exim
/scripts/restartsrv exim

Rollback via WHM#

1. Acesse: WHM » Exim Configuration Manager.
2. Clique na aba Reset e selecione Reset to Default para reverter as ACLs personalizadas.

7. Auditoria de firewall e compatibilidade#

Passo a: verificar se portas SMTP estão abertas e ativas#

# Verificar portas SMTP em escuta (25, 465, 587)
ss -lntp | grep -E "25|465|587"

# Auditar regras do iptables para as portas SMTP
iptables -L -n | grep -E "465|587"

Passo b: verificar bloqueios de IP no configserver security & firewall (CSF)#

Se o cliente externo perder totalmente a conexão com o servidor, verifique se o IP foi temporariamente bloqueado pelo LFD/CSF:

# Buscar o IP no CSF
csf -g 203.0.113.50

# Remover o IP da lista de bloqueios se listado
csf -dr 203.0.113.50
csf -r

Passo c: obter versão e compatibilidade do Exim#

# Verificar versão instalada
exim -V

# Verificar se existem pacotes pendentes de atualização
# Em RHEL 8/9, Rocky e AlmaLinux, yum é alias para dnf
yum check-update exim
# Alternativa moderna explícita:
dnf check-update exim 2>/dev/null || true

Script de diagnóstico automatizado SMTP e AUTH#

Para triagem rápida do status do Exim e validações do ambiente, utilize o script diagnose-exim-auth.sh:

#!/bin/bash
# diagnose-exim-auth.sh - Diagnóstico de problemas AUTH no Exim
# Uso: ./diagnose-exim-auth.sh <IP_CLIENTE>

set -euo pipefail

CLIENT_IP="${1:-}"

echo "=========================================================="
echo " INICIANDO DIAGNÓSTICO DO EXIM E SMTP AUTH"
echo "=========================================================="

# 1. Versão do Exim
echo -e "\n[1] Versão do Exim:"
exim -V | head -3

# 2. Status do serviço
echo -e "\n[2] Status do Serviço (systemctl):"
if systemctl is-active --quiet exim; then
    echo "    ✅ Exim ativo e rodando"
else
    echo "    ❌ Exim inativo ou com falhas"
    systemctl status exim --no-pager | head -n 10
fi

# 3. Portas SMTP em escuta
echo -e "\n[3] Portas SMTP ativas:"
ss -lntp | grep -E ":25|:465|:587" || echo "    ⚠️ Nenhuma porta SMTP (25, 465, 587) em escuta!"

# 4. Configurações Globais AUTH
echo -e "\n[4] Configuração de Hosts AUTH no Exim:"
exim -bP auth_advertise_hosts || echo "    (não configurado)"

# 5. Validação de IP do Cliente (opcional)
if [ -n "$CLIENT_IP" ]; then
    echo -e "\n[5] Análise do IP do Cliente ($CLIENT_IP):"
    echo -e "    - Reverso de IP (PTR):"
    dig -x "$CLIENT_IP" +short || echo "      Nenhum PTR encontrado"
    
    echo -e "    - logs recentes no exim_mainlog:"
    grep "$CLIENT_IP" /var/log/exim_mainlog | tail -n 5 || echo "      Nenhum registro recente encontrado"
fi

# 6. ACLs Customizadas no arquivo exim.conf
echo -e "\n[6] ACLs Customizadas (allow_auth_unadvertised):"
grep -n "allow_auth_unadvertised" /etc/exim.conf || echo "    Nenhuma exceção de bypass configurada."

# 7. Configuração de tls_advertise_hosts (outra causa comum de supressão de AUTH)
echo -e "\n[7] Configuração tls_advertise_hosts no Exim:"
exim -bP tls_advertise_hosts 2>/dev/null || echo "    tls_advertise_hosts não configurado (AUTH pode ser suprimido em todas as conexões sem TLS)."

echo -e "\n=========================================================="
echo " DIAGNÓSTICO CONCLUÍDO"
echo "=========================================================="

Considerações práticas#

O erro AUTH command used when not advertised é uma resposta defensiva do Exim para evitar trânsito de senhas sob handshakes SSL/TLS corrompidos. Ao identificar o IP confiável de origem e configurar o parâmetro allow_auth_unadvertised nas ACLs de HELO, restabeleço a integridade dos envios da aplicação parceira mantendo a segurança do servidor e isolando-o de vulnerabilidades.

Veja também

E-mail Quando os diretórios do IMAP somem: um relato de "pé no barro" no Roundcube

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.