Corrigir um acúmulo de e-mails no Zimbra: Limpe o Postfix com segurança e verifique a entrega.

O comando `zimbra mail queue flush` instrui o Postfix a tentar novamente o envio das mensagens enfileiradas. Ele não apaga a fila, não corrige problemas de DNS ou de rede, nem garante que os servidores remotos aceitarão todas as mensagens. Um resultado útil é mensurável: a fila para de crescer, as mensagens em espera diminuem ou são entregues com sucesso, e novas mensagens podem ser processadas pelo MTA.

Siga os passos abaixo no servidor Zimbra como administrador. Os comandos e caminhos podem variar entre as versões do Zimbra. Verifique os caminhos dos executáveis ​​no seu host antes de executá-los; evite usar acidentalmente a instalação separada do Postfix do sistema operacional.

1. Verifique o tamanho da lista de pendências.

Conecte-se ao servidor e acesse a conta do Zimbra usando o método administrativo aprovado para o seu site. O utilitário de resumo de filas geralmente é instalado em /opt/zimbra/libexec/zmqstat. A documentação de filas do Zimbra mostra que ele exibe a contagem de mensagens retidas, corrompidas, adiadas, ativas e de entrada.

sudo /opt/zimbra/libexec/zmqstat

Dependendo da configuração do sudo, execute o comando a partir da conta Zimbra ou use o método de privilégio exato configurado para o seu servidor. Um exemplo de resumo pode mostrar <número> deferred=240e <categoria> active=3. Esses valores são contagens, não comprovam que 240 mensagens estão permanentemente travadas. Compare-os novamente após alguns minutos e observe qual categoria muda.

Em seguida, inspecione as entradas individuais da fila. Muitas instalações atuais usam o common/sbincaminho; instalações mais antigas podem usar postfix/sbin. Use o caminho que realmente existe no seu servidor.

/opt/zimbra/common/sbin/postqueue -p

Se esse caminho estiver ausente, verifique se sua instalação possui /opt/zimbra/postfix/sbin/postqueueo caminho completo e substitua-o nos comandos abaixo. A documentação do Zimbra descreve tanto o resumo da fila quanto a postqueue -plistagem detalhada. Os IDs das filas podem ter um asterisco no final para tentativas de entrega ativas ou um ponto de exclamação para mensagens retidas. Consulte a referência de filas do Postfix do Zimbra .

2. Descubra o motivo pelo qual as mensagens estão aguardando.

Observe a idade das mensagens mais antigas e o status de entrega registrado no log do Zimbra. Uma mensagem adiada está aguardando uma nova tentativa de entrega; o atraso pode ser causado por um servidor remoto, uma consulta DNS, um tempo limite de rede, negociação TLS ou um problema de configuração de roteamento ou retransmissão local. O texto exato do status é mais útil do que a contagem na fila por si só.

grep -E 'status=(deferred|sent|bounced)|connect to|TLS|SASL|relay=' /var/log/zimbra.log | tail -n 50

Interprete essas linhas no contexto. Tempos limite de conexão repetidos para um destino sugerem um problema de conectividade ou com o servidor remoto. Erros de resolução de nomes apontam para o DNS. Uma rejeição temporária remota ou uma limitação de taxa pode exigir espera ou contato com o provedor do destinatário. Erros de autenticação ou TLS podem indicar um problema de configuração local. Uma status=sententrada significa que o próximo salto de entrega aceitou a mensagem; isso não garante que o destinatário a leu ou que ela chegou à caixa de entrada.

Se a fila estiver aumentando rapidamente, procure por remetentes com alto volume de envios ou contas comprometidas antes de tentar novamente repetidamente. As orientações de solução de problemas anti-spam do Zimbra recomendam correlacionar o conteúdo da fila com o remetente e a atividade de autenticação, isolando a origem antes de excluir os e-mails indesejados. Consulte as etapas de investigação de filas e spam do Zimbra .

3. Corrija a causa antes de pedir ao Postfix para tentar novamente.

Use as evidências do log para determinar se o problema é transitório ou local. Verifique se o servidor possui resolução de nomes e acesso de rede de saída funcionando para os destinos de e-mail afetados. Se o log indicar uma resposta de limitação remota, evite enviar solicitações de limpeza repetidas para esse provedor; novas tentativas não podem sobrescrever sua política. Se vários domínios apresentarem o mesmo erro local, inspecione a configuração relevante do Zimbra MTA e a integridade do serviço antes de alterar as configurações.

As mensagens marcadas como retidas exigem atenção especial: um flush normal não é um comando para liberar e-mails retidos. Verifique o motivo da retenção e se as mensagens são legítimas antes de liberá-las. Mensagens marcadas como corrompidas ou devolvidas também precisam de tratamento separado; tentar novamente não transforma uma rejeição permanente em uma entrega bem-sucedida. Preserve os IDs da fila e as entradas de log relevantes durante a investigação.

O material de resolução de problemas do Zimbra identifica o serviço /var/log/zimbra.logcomo um local principal para investigar problemas do MTA e lista utilitários de fila, como ` postqueuemta` e `mta` zmqstat. O layout exato do serviço e os locais dos executáveis ​​dependem da versão, portanto, verifique a documentação da versão instalada antes de reiniciar os serviços ou editar a configuração. Consulte as ferramentas de resolução de problemas do MTA do Zimbra .

4. Limpe a fila do Postfix

Após confirmar que o e-mail na fila é legítimo e corrigir ou compreender a condição de bloqueio, solicite uma execução da fila. Substitua o caminho existente no seu servidor:

/opt/zimbra/common/sbin/postqueue -f

Para uma instalação que utiliza o caminho antigo, use o comando `flush` /opt/zimbra/postfix/sbin/postqueue -fem vez do caminho especificado na documentação de referência da fila do Zimbra postqueue -f. Essa solicitação instrui o Postfix a tentar enviar e-mails para a fila; não se trata de uma operação de exclusão. O comando pode retornar sem uma mensagem de sucesso clara, portanto, avalie o resultado com base na contagem de e-mails na fila e nos registros de entrega posteriores, em vez de se basear apenas na breve saída do comando.

Executar um flush é razoável após uma breve interrupção na rede ou após a correção de um problema temporário de configuração. É improvável que ajude enquanto o DNS, o roteamento, o relay, o TLS ou um servidor de recebimento remoto permanecerem indisponíveis. Repetir o comando rapidamente pode gerar ruído e tráfego adicional de tentativas sem solucionar a falha.

5. Verifique o resultado e escolha a próxima etapa.

Após um breve intervalo para tentativas de entrega, repita o resumo da fila e verifique as entradas de log recentes:

sudo /opt/zimbra/libexec/zmqstat
tail -n 100 /var/log/zimbra.log

Procure por vários sinais simultaneamente: contagem de mensagens adiadas diminuindo, entradas antigas na fila desaparecendo, novos status=sentregistros para os destinos afetados e menos mensagens recém-adiadas. Uma fila pode permanecer com algum conteúdo durante a operação normal. Uma única entrega bem-sucedida não significa que todos os domínios destinatários estejam íntegros.

• Se a contagem diminuir e os registros de entrega mostrarem aceitação: continue monitorando até que o backlog retorne ao seu nível normal.
• Se as mesmas mensagens de erro persistirem: siga as instruções na mensagem de erro repetida e corrija o problema subjacente de DNS, rede, TLS, retransmissão ou do lado do destinatário.
• Se a contagem continuar aumentando: investigue um possível loop de envio, envio de e-mails em massa ou conta comprometida e contenha novos e-mails indesejados antes de tentar novamente.
• Caso ainda existam contagens retidas ou corrompidas: revise essas mensagens separadamente; uma limpeza geral não é uma ação de limpeza para essas categorias.

Não exclua todas as mensagens apenas para que a fila fique vazia. Se uma mensagem específica for confirmada como indesejada ou não entregável e a política permitir a remoção, preserve o ID da fila e revise-o antes de usar o procedimento de gerenciamento de filas correspondente. O Zimbra alerta explicitamente que a exclusão pode afetar os usuários e recomenda registrar os detalhes da fila antes de remover mensagens. Evite excluir arquivos diretamente dos diretórios de spool do Postfix; isso ignora o gerenciamento de filas e pode corromper o estado dos e-mails.

O que uma descarga bem-sucedida pode e não pode lhe dizer

Uma recuperação bem-sucedida é uma melhoria sustentada no fluxo de mensagens, e não apenas uma contagem zero em um instante específico. O Postfix pode continuar a enfileirar e-mails para destinos remotos que estejam indisponíveis ou que estejam rejeitando conexões temporariamente. O comando `flush` inicia novas tentativas; ele não garante a entrega, não libera mensagens retidas intencionalmente, não corrige configurações incorretas nem determina se o sistema do destinatário aceitou uma mensagem após a transferência SMTP.

Em 6 de outubro de 2026, as páginas do Centro Técnico do Zimbra citadas documentavam os comandos de fila e solução de problemas usados ​​aqui, mas não forneciam um único caminho atual garantido para todas as versões do Zimbra. Confirme os locais dos binários e o comportamento dos privilégios em seu próprio servidor antes de executar comandos, especialmente em implantações mais antigas ou personalizadas.