Em servidores compartilhados ou VPS com cPanel e CloudLinux, é muito comum definir um teto preventivo para disparos de mensagens. No menu Tweak Settings do WHM, podemos configurar, por exemplo, o parâmetro Max hourly emails per domain para 500 mensagens por hora. Essa trava serve para conter disparos em massa acidentais ou abusos provocados por contas comprometidas.
O problema aparece quando um cliente específico precisa de uma cota maior, como 1000 e-mails por hora, para transações legítimas ou notificações de e-commerce.
Ao tentar editar o pacote ou a conta diretamente pelo painel web do WHM, a interface recusa a alteração com o seguinte erro:
(XID psafa9) The value “1000” exceeds the server-wide limit of “500” set in Tweak Settings interface for “Max hourly emails per domain”.Neste artigo, vamos entender como essa validação funciona nos bastidores, como aplicar a cota desejada diretamente no sistema de arquivos e como auditar o comportamento do servidor de e-mail sem abrir brechas de entrega.
1. Por que o erro XID psafa9 acontece no WHM#
Camada visual em perl versus o motor real de entrega em c#
A interface administrativa do cPanel e do WHM é desenvolvida em grande parte em Perl. Quando você submete uma alteração de pacote ou conta pelo navegador, módulos internos (como Whostmgr::Packages) realizam uma checagem de consistência.
O script lê o arquivo global /var/cpanel/cpanel.config, extrai a chave maxemailsperhour e compara o valor com o que foi digitado no formulário. Se o valor solicitado for maior do que o limite global, o script interrompe a execução com um die() e devolve a mensagem de erro XID psafa9 na tela.
O propósito dessa trava na interface é puramente administrativo: impedir que revendedores com acesso à criação de planos definam limites arbitrários que sobrecarreguem a fila de mensagens do servidor.
No entanto, o mecanismo que de fato entrega as mensagens, o Exim (escrito em C), não consulta a interface do WHM no momento do envio. Quando uma mensagem é enfileirada no sistema operacional, as regras de controle de acesso (ACLs) do Exim em /etc/exim.conf buscam os limites em um local individual: o arquivo de metadados da própria conta.
2. Ajuste manual no sistema de arquivos e armadilhas no terminal#
Para conceder os 1000 envios por hora a uma conta sem mexer na regra global do servidor, basta editar o arquivo de metadados do usuário em texto puro:
/var/cpanel/users/nome_do_usuario
O erro comum ao tentar usar sed com aspas simples#
Uma tentativa comum de automação no terminal é rodar um comando sed direto para substituir o valor:
# Exemplo com erro de sintaxe
TOTAL="1000" && sed -i 's/MAX_EMAIL_PER_HOUR=/MAX_EMAIL_PER_HOUR=$TOTAL/'g /var/cpanel/users/usuarioEsse comando falha por dois motivos:
- Aspas simples impedem a expansão de variáveis: no Bash, qualquer expressão entre aspas simples (
' ') é tratada literalmente. O shell não substitui$TOTALpelo número 1000. O arquivo passa a conter a string literalMAX_EMAIL_PER_HOUR=$TOTAL. Quando o cPanel tenta converter esse valor para número inteiro, a leitura resulta em zero ou nulo, bloqueando completamente os disparos da conta. - Substituição sem âncora de linha: a expressão
s/MAX_EMAIL_PER_HOUR=/.../substitui apenas o nome da chave. Se o arquivo já tiver o valor 500, o resultado gravado no disco seráMAX_EMAIL_PER_HOUR=1000500.
Como alterar o arquivo do usuário com segurança no shell#
O procedimento correto exige aspas duplas para permitir a expansão da variável e uma expressão regular ancorada no início da linha (^):
Caso 1: A chave já existe no arquivo
TOTAL="1000"
sed -i "s/^MAX_EMAIL_PER_HOUR=.*/MAX_EMAIL_PER_HOUR=$TOTAL/" /var/cpanel/users/usuarioCaso 2: A chave ainda não existe (conta usando o padrão global)
Se a conta nunca teve um limite personalizado, a linha MAX_EMAIL_PER_HOUR nem sequer constará no arquivo. O script defensivo abaixo verifica a existência da chave antes de decidir entre atualizar ou anexar a linha:
TOTAL="1000"
USER="usuario"
if ! grep -q "^MAX_EMAIL_PER_HOUR=" "/var/cpanel/users/$USER"; then
echo "MAX_EMAIL_PER_HOUR=$TOTAL" >> "/var/cpanel/users/$USER"
else
sed -i "s/^MAX_EMAIL_PER_HOUR=.*/MAX_EMAIL_PER_HOUR=$TOTAL/" "/var/cpanel/users/$USER"
fi3. Sincronização de estado com o ecossistema do cPanel#
O papel do script updateuserdomains#
Apenas salvar o arquivo no disco não altera o comportamento imediato do servidor. Para não sobrecarregar o disco com operações constantes de leitura (stat), os serviços do cPanel (cpanellogd, queueprocd e o próprio exim) utilizam bancos indexados em Berkeley DB (.db) e estruturas em cache.
Para que a nova cota passe a valer, é obrigatório recompilar esses mapas com o utilitário oficial:
/usr/local/cpanel/scripts/updateuserdomainsEsse script processa todos os arquivos em /var/cpanel/users/, atualiza /etc/userdomains e /etc/trueuserdomains, sincroniza as pastas em /var/cpanel/userdata/ e emite sinais locais para os daemons recarregarem suas tabelas em memória.
Cuidados com sincronizações automáticas de pacotes#
Se no futuro alguém editar o plano da conta diretamente pelo WHM, o painel reconstruirá o arquivo /var/cpanel/users/usuario com base nas configurações do pacote, revertendo o limite personalizado de volta para o padrão.
Para evitar que isso aconteça:
- Altere o plano da conta para um pacote personalizado (ou desvincule a conta de pacotes com limites rígidos).
- Caso tenha uma rotina de provisionamento, inclua a verificação do limite horário nos seus scripts pós-criação.
4. Interações com o CloudLinux, LVE e governadores#
Em servidores rodando CloudLinux, os disparos originados por scripts PHP (como o wp_mail do WordPress ou sistemas de boletins informativos) passam pelo isolamento do LVE (Lightweight Virtual Environment).
Dois pontos merecem atenção quando uma conta começa a enviar volumes maiores de mensagens:
Limites de processos simultâneos no envio por PHP#
Se o script tentar abrir dezenas de conexões concorrentes para despachar mensagens de uma vez, a conta pode bater no limite de processos simultâneos (Entry Processes ou Number of Processes).
Para auditar se a conta está sofrendo bloqueios de processos:
lveinfo --user usuario --period 1hAnalise as colunas fEP (falhas de Entry Processes) e fNPROC (falhas de total de processos). Se houver números diferentes de zero, o script de e-mail está sendo estrangulado pelo kernel antes mesmo de falar com o Exim.
Consultas ao banco de dados e o MySQL governor#
Sistemas de envio em massa costumam consultar tabelas com milhares de contatos. Se essas consultas forem lentas ou não utilizarem índices adequados, o db_governor do CloudLinux colocará os processos da conta em fila de espera para poupar o restante do servidor.
Para verificar o estado do usuário no governador do banco:
dbgovctl --status usuario5. Auditoria e validação da entrega de e-mails em tempo real#
Depois de editar o arquivo e rodar a sincronização, é recomendável checar se o sistema está realmente aceitando o novo volume de mensagens.
Acompanhando o diretório de contagem horária do cPanel#
O cPanel armazena o histórico do volume enviado em uma estrutura própria de arquivos de contagem:
ls -lah /var/cpanel/email_send_limits/track/dominio.com.br/Cada envio gera registros dentro dessa pasta, permitindo ver quantas mensagens foram despachadas na janela atual de uma hora.
Registros de transação do Exim#
Para acompanhar o tráfego do domínio e conferir se nenhuma mensagem está sendo recusada por estouro de cota:
tail -f /var/log/exim_mainlog /var/log/exim_rejectlog | grep "dominio.com.br"Se o limite tiver sido ultrapassado, o Exim registrará mensagens informando que o domínio excedeu a quantidade máxima permitida por hora.
Investigando chamadas de sistema com strace#
Se restar qualquer dúvida sobre qual arquivo o Exim está consultando durante o roteamento, podemos rastrear as chamadas de sistema simulando a entrega de um endereço:
strace -f -e trace=open,openat,stat,read exim -bt [email protected] 2>&1 | grep "usuario"Na saída do comando, procure pela chamada openat ou stat acessando /var/cpanel/users/usuario. Isso confirma que o binário leu o arquivo de configuração correto e vinculou a cota ajustada na memória.
Monitorando a fila de mensagens do Exim#
Para checar se mensagens estão acumulando na fila do servidor:
# Exibe a contagem total de mensagens na fila
exim -bpc
# Lista as mensagens pertencentes ao usuario que possam estar retidas
exim -bp | grep "usuario"6. Boas práticas para manter a reputação do servidor estável#
Permitir envios acima da média para contas específicas é perfeitamente viável, mas exige disciplina na administração do servidor:
- Monitore a taxa de rejeições (bounces): contas autorizadas a disparar volumes maiores devem manter listas de e-mails limpas. Uma taxa de erros acima de 5% pode manchar a reputação do IP do servidor perante grandes provedores.
- Utilize autenticação completa de e-mail: certifique-se de que o domínio possui registros SPF, DKIM e DMARC devidamente configurados antes de autorizar o aumento do volume de saída.
- Considere um serviço de relay externo para volumes elevados: se a conta precisar enviar mais de 5.000 ou 10.000 mensagens por hora com frequência, o caminho mais saudável para o servidor compartilhado é rotear esses envios por um smarthost dedicado (como SendGrid, Mailgun ou Amazon SES), preservando o IP principal para a comunicação do dia a dia dos demais clientes.
Este artigo foi útil?
Deixe uma reação rápida para apoiar o conteúdo:
Veja também
Este post está licenciado sob CC BY-NC.
Comentários
Participe da discussão abaixo.
0 comentários