Corrigir erro de e-mail de saída adiado no Zimbra: “Tempo limite de conexão excedido na porta 25”

Se o Zimbra reportar um erro connect to mx.example.net[203.0.113.25]:25: Connection timed out, geralmente significa que a mensagem chegou à fila de e-mails do Zimbra, mas o servidor ainda não concluiu a conexão TCP com o servidor de e-mails do domínio do destinatário. Comece verificando a fila, o DNS e o caminho de rede de saída. Não altere os tempos limite do Postfix nem limpe a fila repetidamente até descobrir qual salto está bloqueando a conexão.

Um tempo limite é diferente de uma rejeição SMTP. Uma rejeição como "550" significa que um servidor remoto respondeu e recusou a mensagem; "Tempo limite de conexão excedido" significa que a tentativa de conexão não recebeu uma resposta em tempo hábil. A causa pode ser um firewall local, a política de e-mail de saída de um provedor de nuvem ou hospedagem, roteamento, um destino inacessível ou, menos comumente, um problema de DNS/família de endereços.

O que significa “Tempo limite de conexão excedido na porta 25” no Zimbra?

O Zimbra usa seu MTA para rotear mensagens de saída. Quando um destinatário está fora da sua organização, o MTA localiza o servidor de e-mail desse domínio e se conecta a ele usando SMTP. O guia do administrador do Zimbra, o Daffodil, descreve as mensagens que não podem ser entregues como entrando na fila de espera, onde a entrega é tentada novamente. A entrada na fila e o registro de e-mails identificam o destino e o erro, sendo, portanto, a melhor evidência inicial.

Em um fluxo de e-mail típico, servidores de e-mail públicos trocam mensagens entre si pela porta TCP 25. A porta 587 é comumente usada por clientes de e-mail autenticados para enviar mensagens a um servidor de retransmissão de saída. Alterar o caminho de retransmissão do Zimbra para a porta 587 é uma opção apenas se você tiver um serviço de retransmissão autorizado configurado para essa finalidade; não se trata de uma substituição geral para o recebimento de e-mails da Internet na porta 25.

1. O problema afeta todos os destinatários ou apenas um domínio específico?

Verifique a fila de pendências antes de fazer alterações. No host do Zimbra MTA, execute comandos administrativos como a zimbraconta:

su - zimbra
postqueue -p

Procure por mensagens de tempo limite repetidas e anote o domínio do destinatário, o nome do host MX de destino e o endereço IP resolvido. No Console de Administração do Zimbra, abra Monitor → Filas de E-mail e inspecione a fila de mensagens adiadas por tipo de erro e domínio do destinatário. O nome exato do menu pode variar de acordo com a versão e edição do Zimbra.

Se as falhas se concentrarem em um domínio destinatário ou em um endereço MX específico, o destino pode estar temporariamente inacessível ou filtrando conexões do seu servidor. Se muitos domínios não relacionados falharem com o mesmo tempo limite na porta 25, suspeite primeiro do caminho de saída do host Zimbra, da política do provedor ou do firewall. Registre os carimbos de data/hora e alguns destinos representativos; não publique o corpo das mensagens ou as credenciais ao solicitar ajuda.

2. O DNS resolve o domínio do destinatário para servidores de e-mail acessíveis?

Consulte os registros MX do domínio destinatário no servidor Zimbra. Substitua example.netpor um domínio que esteja apresentando falhas:

dig MX example.net +short

Utilize o nome de host MX retornado para consultar seus endereços:

dig A mx.example.net +short
dig AAAA mx.example.net +short

Um domínio pode ter vários servidores MX. Teste os nomes de host reais exibidos pelo DNS em vez de presumir que o servidor do site do destinatário aceita e-mails. Se o DNS não retornar nenhum destino MX utilizável, inspecione a configuração DNS autoritativa para esse domínio do destinatário; não adicione um registro MX fictício em seu servidor Zimbra.

Em seguida, teste uma conexão TCP. Se ncestiver instalado, use:

nc -vz -w 10 mx.example.net 25

Ou use- telnet mx.example.net 25o se estiver disponível. Uma conexão TCP bem-sucedida deve produzir uma mensagem de sucesso de conexão; um servidor SMTP pode então exibir uma saudação. Um tempo limite excedido indica que o handshake TCP não foi concluído. Um resultado de "conexão recusada" é diferente: o host remoto respondeu, mas não aceitou a conexão naquele endereço e porta.

Repita o teste para cada destino MX e, quando possível, teste os caminhos IPv4 e IPv6. Se o nome do host for resolvido para um endereço IPv6, mas o servidor não tiver uma rota IPv6 funcional, uma tentativa de IPv6 poderá falhar enquanto o IPv4 funcionar. Verifique a rota e os logs antes de alterar as configurações de família de endereços do Postfix; qualquer alteração desse tipo deve ser específica para a versão e a implantação.

3. Algum firewall ou provedor de hospedagem está bloqueando o SMTP de saída?

Verifique a política de firewall do servidor sem alterá-la primeiro. Em sistemas que utilizam UFW:

sudo ufw status verbose

O UFW pode gerenciar tanto o tráfego de entrada quanto o de saída. Se a política de saída for restritiva, inspecione as regras numeradas e confirme se as conexões TCP com a porta remota 25 estão sendo bloqueadas. Adicione uma regra de permissão de saída com escopo restrito somente se ela estiver de acordo com sua política de segurança e se o servidor estiver autorizado a enviar e-mails diretamente.

Um firewall local pode permitir a conexão, enquanto um firewall upstream, um controle de segurança na nuvem, uma ACL de rede ou uma política do provedor de hospedagem a bloqueia. Consulte o provedor para saber se o tráfego TCP/25 de saída é permitido para esta instância, se há alguma restrição em nível de conta e se existe um processo de liberação ou revisão. As políticas variam de acordo com o provedor, a conta, a região e o produto; portanto, uma verificação bem-sucedida do firewall local não comprova que o caminho para a Internet esteja aberto.

Se você controla um firewall de rede, verifique as regras de saída e os logs para o endereço IP de origem do servidor Zimbra, o endereço IP de destino do MX, o protocolo TCP e a porta de destino 25. Uma captura de pacotes pode ajudar um administrador experiente a distinguir pacotes SYN não respondidos de respostas bloqueadas no caminho de retorno, mas capture apenas os cabeçalhos relevantes e proteja quaisquer dados operacionais. Não abra a porta 25 de entrada como solução para timeouts de saída; esses são sentidos de tráfego distintos.

4. O que você deve fazer se a entrega direta no porto 25 não estiver disponível?

Se o provedor não permitir SMTP de saída direto, use um servidor de retransmissão autorizado ou um servidor de retransmissão de saída. Obtenha o nome do host, a porta, os requisitos de TLS, o método de autenticação, os domínios de remetente permitidos e quaisquer requisitos de lista de permissões de IP com o operador do servidor de retransmissão. Configure o servidor de retransmissão por meio do método de administração do Zimbra compatível com a sua versão ou siga o processo de alteração do Zimbra da sua organização. O guia do administrador do Zimbra observa que um host de retransmissão deve ser configurado quando a entrega baseada em DNS não estiver habilitada.

Muitos provedores oferecem envio autenticado na porta 587 com STARTTLS, mas a documentação do servidor de retransmissão é a fonte oficial. Um servidor de retransmissão pode exigir a porta 465, listas de permissão de IP ou um conector específico do provedor. Não presuma que a porta 587 esteja aberta ou que qualquer servidor SMTP público possa ser usado como servidor de retransmissão. Mantenha as credenciais na configuração protegida recomendada, restrinja quem pode lê-las e nunca inclua a senha do servidor de retransmissão em um ticket de suporte ou no histórico do shell.

Após configurar o servidor de retransmissão, envie uma mensagem de teste controlada para uma caixa de correio que você gerencia. Confirme no log de e-mail do Zimbra se a conexão é estabelecida com o host de retransmissão e a porta esperada, se a autenticação TLS é bem-sucedida (se necessário) e se o servidor de retransmissão aceita a mensagem. Se retornar um erro SMTP, investigue essa resposta como um problema de autenticação, política do remetente, TLS ou permissão de retransmissão, em vez de considerá-la como um tempo limite da porta 25.

Quando você deve tentar novamente a fila de espera?

Assim que a causa raiz for corrigida e um teste direto para o destino ou servidor de retransmissão for bem-sucedido, solicite uma nova tentativa de entrega da fila. A partir da conta Zimbra, postqueue -fsolicite ao Postfix que tente entregar as mensagens enfileiradas:

su - zimbra
postqueue -f

Isso pode desencadear tentativas de entrega para muitas mensagens, portanto, evite executá-lo repetidamente durante uma interrupção. Você também pode usar os controles de fila do Console de Administração, quando disponíveis. A documentação do Zimbra indica que o esvaziamento das filas tenta entregar mensagens nas filas Adiadas, de Entrada e Ativas. Verifique algumas mensagens posteriormente e confirme se a contagem de mensagens adiadas está diminuindo e se os logs mostram a entrega bem-sucedida ou uma nova resposta SMTP que possa ser usada.

Guia rápido de decisão

Como posso confirmar a correção?

Utilize uma sequência de verificação curta: confirme se o DNS retorna o MX ou servidor de retransmissão pretendido; confirme se a conexão TCP com o host e a porta configurados foi bem-sucedida; envie uma mensagem de teste controlada; verifique se o servidor remoto ou o servidor de retransmissão a aceitou; em seguida, inspecione a fila de mensagens adiadas e os registros em busca das mensagens originais. Um teste de conexão bem-sucedido por si só não comprova que o destinatário aceitou a mensagem, e uma transferência bem-sucedida para um servidor de retransmissão não garante a entrada da mensagem na caixa de entrada.

Não tente "corrigir" um tempo limite aumentando o tempo limite de conexão do Postfix. Essa smtp_connect_timeoutconfiguração controla por quanto tempo o cliente SMTP espera para concluir uma conexão TCP; estendê-la não fará com que uma rota bloqueada funcione e pode fazer com que as tentativas de entrega esperem mais tempo. Evite também excluir mensagens enfileiradas ou alterar o tempo de vida da fila para ocultar o problema. Se as mensagens se aproximarem do tempo de vida de rejeição configurado, informe aos usuários afetados que a entrega está atrasada e preserve as evidências da fila enquanto restaura a rota.

Referências oficiais

• Guia do Administrador do Zimbra Daffodil (v10): fluxo de e-mails e filas
• Guia de Instalação do Zimbra Daffodil (v10) em Servidor Único: mapeamento de portas
• Postfix postconf(5): smtp_connect_timeout
• Documentação do Ubuntu Server: firewalls e status do UFW