Si Zimbra informa de un error connect to mx.example.net[203.0.113.25]:25: Connection timed out, el mensaje suele haber llegado a la cola de correo de Zimbra, pero el servidor no ha completado la conexión TCP con el servidor de correo del dominio del destinatario. Comience por revisar la cola, el DNS y la ruta de red de salida. No modifique los tiempos de espera de Postfix ni vacíe la cola repetidamente hasta que identifique qué salto está bloqueando la conexión.
Un tiempo de espera agotado es diferente de un rechazo SMTP. Un rechazo como "550" significa que un servidor remoto respondió y rechazó el mensaje; "Tiempo de espera de conexión agotado" significa que el intento de conexión no recibió una respuesta oportuna. La causa puede ser un firewall local, la política de correo saliente de un proveedor de nube o alojamiento, el enrutamiento, un destino inaccesible o, con menos frecuencia, un problema de DNS/familia de direcciones.
Zimbra utiliza su MTA para enrutar los mensajes salientes. Cuando un destinatario se encuentra fuera de su organización, el MTA busca el servidor de correo de ese dominio y se conecta a él mediante SMTP. La guía de administración de Daffodil de Zimbra describe los mensajes que no se pueden entregar como mensajes que entran en la cola de mensajes diferidos, donde se reintenta la entrega. La entrada en la cola y el registro de correo identifican el destino y el error, por lo que constituyen la mejor evidencia inicial.
En un flujo de correo típico, los servidores de correo públicos intercambian mensajes entre sí a través del puerto TCP 25. El puerto 587 suele ser utilizado por clientes de correo autenticados para enviar mensajes a un servidor de retransmisión saliente. Cambiar la ruta de retransmisión de Zimbra al puerto 587 solo es una opción si se dispone de un servicio de retransmisión autorizado configurado para tal fin; no se trata de una alternativa general para recibir correo de Internet en el puerto 25.
Verifique la cola diferida antes de realizar cambios. En el host Zimbra MTA, ejecute los comandos administrativos como la zimbracuenta:
su - zimbra
postqueue -pBusque mensajes de tiempo de espera repetidos y anote el dominio del destinatario, el nombre de host MX de destino y la dirección IP resuelta. En la consola de administración de Zimbra, abra Monitor → Colas de correo e inspeccione la cola de correo diferido por tipo de error y dominio del destinatario. La etiqueta exacta del menú puede variar según la versión y edición de Zimbra.
Si los fallos se concentran en un dominio de destino o una dirección MX, es posible que el destino no esté disponible temporalmente o que esté filtrando las conexiones desde su servidor. Si varios dominios no relacionados fallan con el mismo tiempo de espera en el puerto 25, sospeche primero de la ruta de salida del host de Zimbra, la política del proveedor o el firewall. Registre las marcas de tiempo y algunos destinos representativos; no publique el contenido de los mensajes ni las credenciales cuando solicite ayuda.
Consulta los registros MX del dominio receptor desde el servidor Zimbra. Reemplaza example.netcon un dominio que esté fallando:
dig MX example.net +shortUtilice el nombre de host MX devuelto para buscar sus direcciones:
dig A mx.example.net +short
dig AAAA mx.example.net +shortUn dominio puede tener varios servidores MX. Compruebe los nombres de host reales que muestra el DNS en lugar de asumir que el servidor web del destinatario acepta correo. Si el DNS no devuelve ningún destino MX utilizable, inspeccione la configuración DNS autoritativa de ese dominio; no añada un registro MX ficticio a su servidor Zimbra.
A continuación, pruebe una conexión TCP. Si ncestá instalado, utilice:
nc -vz -w 10 mx.example.net 25O bien, utilice telnet mx.example.net 25esa opción si está disponible. Una conexión TCP exitosa debería generar un mensaje de confirmación; un servidor SMTP podría mostrar un saludo. Un tiempo de espera agotado indica que el protocolo de enlace TCP no se completó. Un resultado de "conexión rechazada" es diferente: el host remoto respondió, pero no aceptó la conexión en esa dirección y puerto.
Repita la prueba para cada destino MX y, cuando sea posible, pruebe tanto las rutas IPv4 como las IPv6. Si el nombre de host se resuelve a una dirección IPv6, pero el servidor no tiene una ruta IPv6 que funcione, un intento de IPv6 puede fallar, aunque IPv4 funcione. Verifique la ruta y los registros antes de modificar la configuración de la familia de direcciones de Postfix; cualquier cambio de este tipo debe ser específico para la versión y la implementación.
Compruebe primero la política de firewall del servidor sin modificarla. En sistemas que utilizan UFW:
sudo ufw status verboseUFW puede gestionar tanto el tráfico saliente como el entrante. Si la política de salida es restrictiva, revise las reglas numeradas y confirme si se deniegan las conexiones TCP al puerto remoto 25. Añada una regla de permiso de salida de alcance limitado solo si coincide con su política de seguridad y el servidor está autorizado a enviar correo directamente.
Es posible que el firewall del host permita la conexión, mientras que un firewall de nivel superior, el control de seguridad de la nube, la lista de control de acceso (ACL) de la red o la política del proveedor de alojamiento la bloqueen. Consulte con el proveedor si se permite el tráfico TCP/25 saliente para esta instancia, si se aplica alguna restricción a nivel de cuenta y si existe un proceso de liberación o revisión. Las políticas varían según el proveedor, la cuenta, la región y el producto, por lo que una comprobación exitosa del firewall local no garantiza que la ruta a Internet esté abierta.
Si administra un firewall de red, revise sus reglas de salida y los registros para la IP de origen del servidor Zimbra, la IP MX de destino, el protocolo TCP y el puerto de destino 25. Una captura de paquetes puede ayudar a un administrador experimentado a distinguir los paquetes SYN sin respuesta de las respuestas bloqueadas en la ruta de retorno, pero capture solo los encabezados relevantes y proteja los datos operativos. No abra el puerto de entrada 25 como solución para los tiempos de espera de salida; se trata de direcciones de tráfico distintas.
Si el proveedor no permite el envío directo de SMTP, utilice un servidor de retransmisión o un servidor de retransmisión autorizado. Obtenga del operador del servidor de retransmisión el nombre de host, el puerto, los requisitos TLS, el método de autenticación, los dominios de remitente permitidos y cualquier requisito de inclusión de direcciones IP en la lista blanca. Configure el servidor de retransmisión mediante el método de administración de Zimbra compatible con su versión o siga el proceso de cambio de Zimbra de su organización. La guía del administrador de Zimbra indica que se debe configurar un servidor de retransmisión cuando la entrega basada en DNS no está habilitada.
Muchos proveedores ofrecen envío autenticado en el puerto 587 con STARTTLS, pero la documentación del servidor de retransmisión es la que prevalece. Un servidor de retransmisión podría requerir el puerto 465, la inclusión de direcciones IP en una lista blanca o un conector específico del proveedor. No asuma que el puerto 587 está abierto ni que cualquier servidor SMTP público puede utilizarse como servidor de retransmisión. Mantenga las credenciales en la configuración protegida compatible, restrinja quién puede leerlas y nunca guarde la contraseña del servidor de retransmisión en un ticket de soporte ni en el historial de la consola.
Tras configurar el relé, envíe un mensaje de prueba controlado a un buzón de correo que administre. Confirme en el registro de correo de Zimbra que la conexión se establece con el servidor del relé y el puerto esperado, que la autenticación TLS se realiza correctamente si es necesario y que el relé acepta el mensaje. Si devuelve un error SMTP, investigue esa respuesta como un problema de autenticación, política del remitente, TLS o permisos del relé, en lugar de como un tiempo de espera agotado en el puerto 25.
Una vez corregida la causa raíz y tras una prueba directa al destino o relé exitosa, solicite un reintento de la cola. Desde la cuenta de Zimbra, postqueue -fsolicite a Postfix que intente la entrega de los mensajes en cola:
su - zimbra
postqueue -fEsto puede provocar intentos de entrega para muchos mensajes, así que evite ejecutarlo repetidamente durante una interrupción del servicio. También puede usar los controles de cola de la Consola de administración, si están disponibles. Zimbra documenta que el vaciado de la cola intenta la entrega de mensajes en las colas Diferidas, Entrantes y Activas. Revise algunos mensajes después y verifique que el contador de mensajes diferidos esté disminuyendo y que los registros muestren una entrega exitosa o una nueva respuesta SMTP procesable.
| Observación | Probablemente el próximo chequeo |
|---|---|
| Un dominio de destino caduca | Pruebe cada host MX; verifique la accesibilidad del destino y el filtrado remoto. |
| Muchos dominios agotan el tiempo de espera en el puerto 25. | Verifique las reglas del firewall de salida, las rutas y las restricciones del proveedor. |
| TCP se conecta, luego SMTP devuelve 4xx o 5xx. | Utilice la respuesta SMTP remota para solucionar problemas relacionados con políticas, reputación o errores del destinatario. |
| El proveedor de alojamiento ha bloqueado el puerto 25. | Solicitar acceso o configurar un relé autenticado aprobado. |
| El servicio Relay acepta la prueba, pero el correo antiguo permanece en cola. | Revise los registros, vuelva a intentar acceder a la cola una vez y, a continuación, supervise la entrega y los avisos de rebote. |
Utilice una breve secuencia de verificación: confirme que el DNS devuelve el servidor MX o de retransmisión previsto; confirme que la conexión TCP con el host y puerto configurados se establece correctamente; envíe un mensaje de prueba controlado; verifique que el servidor remoto o de retransmisión lo haya aceptado; a continuación, revise la cola de mensajes diferidos y los registros para encontrar los mensajes originales. Una prueba de conexión exitosa por sí sola no demuestra que el destinatario haya aceptado el mensaje, y una transferencia de retransmisión exitosa no garantiza que el mensaje llegue a la bandeja de entrada.
No intente solucionar un tiempo de espera aumentando el tiempo de espera de conexión de Postfix. La smtp_connect_timeoutconfiguración de Postfix controla cuánto tiempo espera el cliente SMTP para completar una conexión TCP; extenderlo no solucionará una ruta bloqueada y puede provocar que los intentos de entrega esperen más tiempo. Evite también eliminar mensajes en cola o modificar la duración de la cola para ocultar el problema. Si los mensajes se acercan al tiempo de espera de rebote configurado, informe a los usuarios afectados que la entrega se retrasa y conserve la evidencia de la cola mientras restablece la ruta.
Con OCC, puede desbloquear de forma segura una página de mantenimiento de Nextcloud que se haya quedado atascada, comprobar si una actualización está incompleta y verificar que la instancia esté lista para los usuarios.
Diagnostica los errores de correo saliente diferido de Zimbra en el puerto 25. Verifica la cola, el DNS MX, los firewalls, los bloqueos del proveedor y configura un relé SMTP aprobado.
Set up a lightweight Matrix homeserver on Raspberry Pi 4 with Conduit, Docker, NGINX, HTTPS, registration controls, federation, and checks.
Agregue servidores Jitsi Videobridge a una implementación compartida de Jitsi Meet, configure el registro y el acceso al firewall, verifique la selección del puente y aprenda cuándo se necesita Octo.
Instale un certificado SSL comercial en Zimbra de forma segura: cree la solicitud de firma de certificado (CSR), construya la cadena de certificados de la autoridad de certificación (CA), verifique la clave y el certificado, impleméntelo, reinicie los servicios y confirme HTTPS.
Cambie el logotipo predeterminado de BigBlueButton, agregue un logotipo a las reuniones individuales y comprenda cuándo la personalización de la interfaz requiere una compilación personalizada del cliente.
Aprenda cómo identificar, archivar, comprimir y eliminar los registros de auditoría antiguos de Zimbra, cuándo evitar truncar audit.log y cómo verificar que el espacio en disco y los registros se recuperen correctamente.
Solucione los problemas de conexión del servidor de almacenamiento Kopano dagent comprobando el estado del servidor, server_socket, los permisos del socket Unix, los oyentes remotos y las pruebas de entrega controlada.
Solucione los errores de tiempo de espera de bloqueo de archivos de ownCloud identificando los bloqueos transaccionales, trasladando el almacenamiento de bloqueos a Redis, comprobando los clústeres y volviendo a realizar pruebas de forma segura.
Solucione los problemas de OOM de Matrix Synapse durante /sync comprobando la presión de la memoria, ajustando cuidadosamente las cachés, aislando la sincronización inicial y supervisando los procesos de trabajo.
