Todo administrador de sistemas conoce esa sensación. Llega un ticket de soporte que parece simple: “Un usuario no puede enviar correos a un destinatario específico”. Pero pronto, lo que parecía una tarea de cinco minutos se convierte en un viaje por la madriguera del conejo del troubleshooting.
Esta es la historia de uno de esos viajes, una batalla contra el temido error: retry timeout exceeded.
El Escenario del Crimen
La situación era la siguiente:
- Un remitente (
[email protected]) no podía enviar correos a un destinatario específico ([email protected]). - El error devuelto era un
retry timeout exceeded, un mensaje que grita “¡problema de red o firewall!”. - El remitente podía enviar correos a otros destinos sin problema.
- El destinatario recibía correos de todo el mundo sin problema.
El primer instinto, y el más lógico, es culpar a un bloqueo en el servidor de destino. La IP de nuestro servidor de envío debía estar en alguna lista negra.
La Investigación Inicial: Los Sospechosos Habituales
Comenzamos el protocolo estándar, revisando todas las causas probables en el servidor de destino:
- Firewall (CSF, BitNinja): Revisamos si la IP de nuestro servidor estaba bloqueada. Resultado: Negativo. No había rastro de nuestra IP en las listas de bloqueo.
- Filtros de Correo del Usuario: Accedimos al cPanel del destinatario para ver si había alguna regla de filtrado que descartara los correos de nuestro remitente. Resultado: Negativo. No existían filtros.
- Blacklists de SpamAssassin: Verificamos las listas negras globales del servidor. Resultado: Negativo. Nuestro dominio no estaba allí.
- Whitelist Manual: Como medida proactiva, creamos un filtro para permitir explícitamente al remitente. Resultado: Sin cambios. El error persistía.
La evidencia era contradictoria. El problema se comportaba como un bloqueo de red, pero no había ninguna prueba de ello. Cada puerta que tocábamos estaba abierta, pero el paquete nunca llegaba.
El Giro Inesperado: El Testimonio Clave
Cuando las opciones se agotan, se escala. Contactamos al soporte técnico del servidor de destino, presentando toda nuestra evidencia. Su respuesta fue la pieza clave del rompecabezas, el giro en el tercer acto de nuestra película:
“Hemos revisado todos nuestros registros de conexión (
exim_mainlogyexim_rejectlog). No estamos viendo ningún intento de conexión desde su servidor. El correo no está siendo rechazado por nosotros; simplemente, nunca llega.”
Esta declaración lo cambió todo. El problema no era externo. El fantasma vivía en nuestra propia casa. El servidor de envío ni siquiera estaba intentando contactar al mundo exterior.
El Verdadero Culpable: /etc/localdomains
Con la investigación ahora centrada 100% en nuestro servidor de envío, la pregunta era: ¿por qué Exim no intenta enviar este correo a la red? La respuesta se encontraba en un simple archivo de configuración de cPanel: /etc/localdomains.
Este archivo le dice a Exim: “Cualquier dominio listado aquí es uno de los nuestros. No busques sus registros MX en internet; la entrega es local”.
Y allí estaba, esperando silenciosamente: dominio-destino.com.
En algún momento del pasado, por alguna prueba o configuración ya olvidada, el dominio de destino había sido añadido a la lista de dominios locales de nuestro servidor.
Este era el flujo real del error:
- Un usuario enviaba un correo a
[email protected]. - Nuestro servidor Exim recibía el correo y veía el dominio
dominio-destino.com. - Consultaba su archivo
/etc/localdomainsy encontraba una coincidencia. - Exim decía: “¡Perfecto, este dominio es mío! Intentaré entregar este correo localmente al buzón
contacto”. - Como el buzón
contactono existía en nuestro servidor, Exim entraba en un bucle de reintentos internos que finalmente expiraba, generando el famosoretry timeout exceeded.
El timeout no era de red, ¡era un timeout interno!
La solución fue tan simple como devastadora: eliminar la línea dominio-destino.com del archivo /etc/localdomains. Al hacerlo, Exim volvió a tratar a dominio-destino.com como un dominio externo, buscó sus registros MX y entregó el correo al instante.
La Lección Aprendida
Este caso fue un recordatorio brutal de uno de los principios del diagnóstico de sistemas: los síntomas pueden mentir. Un problema que se presenta como un complejo bloqueo de red puede ser una simple línea de configuración incorrecta en casa.
Mi checklist para futuros “timeouts fantasma” ahora incluye un paso esencial:
- Verificar la resolución de DNS desde el propio servidor: No confíes en lo que tu PC local ve. Conéctate por SSH al servidor de envío y ejecuta
dig mx eldominio-a-revisar.com. Esto te dirá lo que el servidor realmente cree. - Revisar la configuración de dominios locales: En servidores cPanel, siempre echa un vistazo a
/etc/localdomainsy/etc/remotedomainspara asegurarte de que el correo se está enrutando como esperas.
A veces, el monstruo que buscas en castillos lejanos está, en realidad, escondido en tu propio sótano.