Errores SMTP 4xx temporales: causas principales y soluciones que realmente funcionan

Qué significan realmente los fallos SMTP 4xx temporales

Los códigos de respuesta SMTP son instrumentos toscos con una apariencia engañosamente educada. Una respuesta 4xx es un fallo transitorio: se espera que el remitente vuelva a intentar más tarde. Eso no es una promesa de que más tarde funcionará—solo una petición para que tu MTA deje de martillar.

La diferencia práctica entre 4xx y 5xx

• 4xx: “Intenta de nuevo.” Tu MTA encola el mensaje, programa reintentos y finalmente desiste tras un TTL (el valor por defecto de Postfix suele ser días, pero verifica tu configuración).
• 5xx: “Detente.” El receptor dice que está rechazado de forma permanente (destinatario inválido, política de rechazo, rebote duro). Reintentar suele ser un esfuerzo en vano a menos que el remitente corrija algo primero.

Los códigos aumentados importan más que los tres dígitos

Los MTAs modernos suelen incluir un código “aumentado” como 4.7.0 o 4.4.1. Ese segundo código es donde se esconde el significado. Ejemplos:

• 421 4.7.0: normalmente throttling, bloqueos temporales por políticas, o “lárgate”.
• 450 4.2.0: buzón no disponible, a menudo temporal o greylisting.
• 451 4.3.0: error de procesamiento local; podría ser agotamiento de recursos.
• 452 4.3.1: almacenamiento del sistema insuficiente; o el destinatario dice “buzón lleno”.
• 454 4.7.0: TLS no disponible por una razón temporal (o negociaciones de política).

Una regla operacional: trata 4xx como una señal de capacidad y corrección. Incluso si es “del otro lado”, tu sistema es el que acumula correo diferido, ruido de alertas y riesgo reputacional.

Idea parafraseada atribuida a Gene Kranz: Falla rápido, mantén la calma y actúa a partir de los datos. No es poesía, pero gana incidentes.

Broma 1: SMTP 4xx es como una invitación a reunión que dice “tentativo”—no te rechazan, solo estás atrapado en el purgatorio del calendario.

Guía rápida de diagnóstico (primero/segundo/tercero)

Cuando la cola crece, no tienes tiempo para meditar sobre RFCs. Necesitas encontrar el cuello de botella con una secuencia que minimice los desvíos.

Primero: identifica el patrón de fallo (lado receptor vs nuestro lado)

1. ¿Es un dominio o muchos? Si es un proveedor grande, piensa en throttling/greylisting/política. Si son muchos, piensa en DNS, red, recursos locales, configuración rota o una dependencia compartida.
2. ¿Es un host remitente o todos los MTAs? Si solo un servidor está afectado, sospecha de la reputación de la IP de ese host, enrutamiento o agotamiento de recursos locales.
3. ¿Está correlacionado con el tiempo? ¿Picos a inicio de hora? Suena a trabajos por lotes y límites de tasa. ¿Picos durante backups? Suena a I/O y latencia.

Segundo: lee el texto SMTP exacto, no tus sentimientos

Extrae líneas de ejemplo de los registros y agrúpalas por la cadena de respuesta remota. La ganancia fácil está en notar “4.7.0 try again later” frente a “4.4.1 connection timed out” frente a “451 4.3.0 internal error.” Cada uno apunta a una capa distinta.

Tercero: revisa la salud de la cola y del sistema en paralelo

La profundidad de la cola por sí sola no es el problema; es un síntoma. Quieres responder:

• ¿Estamos intentando entregas a una tasa normal, o estamos atascados (DNS roto, red rota, proceso bloqueado)?
• ¿Estamos siendo diferidos por política (throttling/greylisting), requiriendo backoff o calentamiento?
• ¿Estamos limitados por recursos (disco lleno, agotamiento de inodos, latencia I/O, presión de memoria)?

La matriz de triage más rápida

• 4.4.x timeouts → red, DNS, enrutamiento, firewall, outage remoto.
• 4.7.x policy/throttling → límites de tasa, reputación, autenticación, patrones de contenido.
• 4.3.x procesamiento local → almacenamiento, permisos, corrupción de cola, salud del proceso MTA.
• 4.2.x buzón → problemas del destinatario o greylisting; a menudo específico del dominio.

Principales causas de fallos SMTP 4xx (y soluciones reales)

1) Throttling del receptor y límites de tasa (421/450/451/4.7.x)

Los grandes proveedores se defienden con throttles. No quieren que envíes demasiado rápido, desde demasiadas conexiones o con patrones que se parezcan a spam. El resultado suele ser 421 4.7.0, 451 4.7.x o un vago “Inténtelo más tarde”.

Soluciones que funcionan:

• Reduce la concurrencia hacia ese dominio: menos conexiones paralelas, menos destinatarios por conexión.
• Calienta las IP nuevas en lugar de lanzar el volumen completo el primer día.
• Separa las clases de tráfico (transaccional vs masivo). Deja que el masivo reciba el impacto del throttling, no los restablecimientos de contraseña.
• Usa reintentos/backoff sensatos. Reintentos agresivos pueden parecer abuso.

2) Greylisting (450 4.2.x / 451 4.7.x)

El greylisting es una táctica deliberada de “vete y vuelve”. Parte de la asunción de que MTAs legítimos reintentan, mientras que muchos bots de spam no lo hacen. Verás un fallo temporal en el primer intento; los intentos posteriores suelen tener éxito.

Soluciones que funcionan:

• No te enfrentes a ello con pánico. Asegura que tu calendario de reintentos sea correcto y que no esté deshabilitado.
• Mantén estable la IP de envío. Las claves de greylisting a menudo incluyen IP.
• Asegúrate de que tu MTA no se comporte como un bot: HELO/EHLO correctos, reverse DNS válido, comportamiento TLS consistente.

3) Problemas de DNS: timeouts de consulta, SERVFAIL, resolvers rotos (451 4.4.3, “Temporary lookup failure”)

SMTP depende mucho del DNS: búsquedas MX, registros A/AAAA, PTR, SPF, selectores DKIM, a veces RBLs y comprobaciones de políticas. Si tu resolver es lento, está mal configurado o bloqueado, obtienes fallos transitorios que parecen problemas remotos pero son locales.

Soluciones que funcionan:

• Usa resolvers fiables localmente (systemd-resolved es un villano recurrente cuando se comporta mal).
• Monitorea la latencia DNS y la tasa de SERVFAIL, no solo “si DNS está arriba”.
• Cachea responsablemente. No caches respuestas rotas para siempre.

4) Problemas de negociación TLS (454 4.7.0, fallos de handshake, casos límite de TLS oportunista)

TLS es mayormente aburrido hasta que no lo es. Un fallo TLS temporal puede venir de incompatibilidades de cifrado, problemas de validación de certificados (para TLS forzado), bugs de SNI, o middleboxes que “optimizan” rompiendo cosas.

Soluciones que funcionan:

• Registra detalles TLS SMTP en el MTA y captura una transacción que falle.
• Prefiere TLS moderno, pero mantén compatibilidad si debes hablar con endpoints antiguos.
• Si aplicas TLS obligatorio para ciertos dominios, asegúrate de que tu almacén CA y manejo de SNI sean correctos.

5) Problemas de almacenamiento y filesystem de la cola (451 4.3.0, 452 4.3.1, “cannot write file”)

Tu MTA es un sistema de almacenamiento con sombrero de correo. La cola es efectivamente una base de datos de mensajes, y las bases de datos odian discos lentos, discos llenos, agotamiento de inodos y permisos descuidados.

Soluciones que funcionan:

• Comprueba el espacio en disco, los inodos y la latencia I/O.
• Pon la cola en almacenamiento fiable. Si compartes un volumen con vecinos ruidosos, espera dolor.
• Cuidado con snapshots de backup que detienen I/O o llenan volúmenes.

6) Agotamiento de procesos/recursos (451 4.3.0, “out of memory,” demasiados archivos abiertos)

Los MTAs no son enormes, pero bajo carga pueden alcanzar límites de descriptores de archivos, presión de RAM o límites de tabla de procesos. Los síntomas incluyen diferimientos por errores locales, entrega lenta y comportamientos intermitentes extraños.

Soluciones que funcionan:

• Aumenta ulimit -n y los límites del sistema apropiadamente.
• Deja de fingir que la swap es una característica de rendimiento.
• Ajusta la concurrencia adecuadamente. Meter más hilos en un disco saturado es la forma de provocar un outage mayor.

7) Reputación / bloqueos temporales por política (421/451 4.7.0, “temporarily deferred”)

Los receptores pueden bloquearte temporalmente por picos sospechosos de volumen, quejas por spam, destinatarios inválidos o autenticación desalineada. A veces el receptor no quiere decir “tu correo parece malo”, así que dice “intenta más tarde”.

Soluciones que funcionan:

• Alinea SPF, DKIM y DMARC para el correo que envías.
• Reduce la tasa de rebotes limpiando listas y corrigiendo la validación de destinatarios.
• Estabiliza el volumen. El tráfico con picos es un impuesto reputacional.

8) Problemas de ruta de red: timeouts, pérdida de paquetes, anomalías MTU (4.4.x)

Si estás expirando conexiones hacia múltiples dominios, no te quedes mirando las configuraciones de Postfix durante horas. Mira la red. Pérdida de paquetes, enrutamiento asimétrico, firewalls mal configurados o IPv6 roto pueden convertir SMTP en una tragedia a cámara lenta.

Soluciones que funcionan:

• Prueba v4 y v6 por separado. Las fallas dual-stack son famosamente confusas.
• Revisa las tablas de estado del firewall y la capacidad de NAT.
• No ignores problemas de PMTUD/MTU si los handshakes TLS se quedan colgados.

9) Fallos de dependencias aguas abajo: escaneo de contenido, latencia de milter, outages antivirus (451 4.3.0)

Muchas configuraciones enrutan correo a través de milters, filtros de contenido, motores DLP o “appliances de seguridad”. Cuando estos se degradan, tu MTA espera, bloquea y luego difiere. El error SMTP puede mencionar un filtro; puede que no.

Soluciones que funcionan:

• Mide la latencia y los fallos del milter explícitamente.
• Usa timeouts y políticas de fail-open/fail-closed deliberadamente según la clase de correo.
• Planifica capacidad para los filtros como si fueran servicios de producción. Porque lo son.

Broma 2: Si tu “gateway de seguridad de correo” está caído, enhorabuena: has construido un generador de pérdida de paquetes muy caro.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas son tareas de campo. Cada una incluye un comando, una salida de ejemplo, lo que significa y la decisión que tomas. Úsalas para convertir “los correos están atascados” en un diagnóstico concreto.

Task 1: Count deferred vs active queue (Postfix)

cr0x@server:~$ mailq | egrep -c "^[A-F0-9]"
1842

Qué significa: Tamaño aproximado de la cola (IDs de mensaje). Si este número aumenta más rápido de lo que disminuye, tienes un problema de rendimiento.

Decisión: Si la cola > línea base normal y está en aumento, procede a aislar por dominio y texto de error antes de reiniciar nada.

Task 2: Identify top deferred reasons from logs (Postfix)

cr0x@server:~$ sudo awk '/status=deferred/ {print $0}' /var/log/mail.log | tail -n 2000 | sed -n 's/.*said: //p' | sort | uniq -c | sort -nr | head
  421 4.7.0 Try again later
  198 451 4.4.2 Timeout while waiting for server greeting
   74 450 4.2.0 Greylisted, please try again
   41 451 4.3.0 Error: queue file write error
   22 454 4.7.0 TLS not available due to temporary reason

Qué significa: Estos son los “principales hablantes” de tu incidente. Te indican qué capa investigar primero.

Decisión: Escoge los 1–2 mensajes principales y persíguelos. No disperses atención en cinco familias de errores distintas.

Task 3: Find which recipient domains dominate the queue

cr0x@server:~$ mailq | awk '/@/ {print $NF}' | sed 's/.*@//' | tr -d '>,' | sort | uniq -c | sort -nr | head
  912 gmail.com
  376 outlook.com
  211 example-corp.com
   94 yahoo.com
   51 proton.me

Qué significa: Si un dominio domina, probablemente tengas throttling, reputación o una política específica del proveedor.

Decisión: Aplica limitación por dominio y verifica la alineación de autenticación para el tráfico de ese dominio.

Task 4: Inspect a single queued message’s last error (Postfix postcat)

cr0x@server:~$ sudo postcat -vq 3F2A91C02B | sed -n '/^*** ENVELOPE RECORDS/,/^*** MESSAGE CONTENTS/p' | head -n 30
*** ENVELOPE RECORDS ***
message_size:           48213              2812               1               0            48213
message_arrival_time: Wed Jan  3 11:02:19 2026
sender: noreply@yourdomain.tld
*** RECIPIENT RECORDS ***
original_recipient: user@gmail.com
recipient: user@gmail.com
offset: 2812
dsn_orig_rcpt: rfc822;user@gmail.com
dsn_notify: failure
dsn_orcpt: rfc822;user@gmail.com
orig_to: user@gmail.com
recipient_status: 421 4.7.0 Try again later

Qué significa: Confirma la respuesta del receptor asociada a ese registro de cola (no solo lo que viste en los logs).

Decisión: Si el error es de política/throttle, ajusta la concurrencia y la estrategia de reintentos en lugar de reiniciar Postfix.

Task 5: Show Postfix concurrency/rate settings that influence throttling

cr0x@server:~$ sudo postconf | egrep 'default_destination_concurrency_limit|smtp_destination_concurrency_limit|smtp_destination_rate_delay|smtp_destination_recipient_limit|maximal_queue_lifetime'
default_destination_concurrency_limit = 20
smtp_destination_concurrency_limit = 20
smtp_destination_rate_delay = 0s
smtp_destination_recipient_limit = 50
maximal_queue_lifetime = 5d

Qué significa: Alta concurrencia + sin delay de tasa es una forma clásica de ser throttled por grandes proveedores.

Decisión: Si ves throttling 4.7.x, reduce la concurrencia por destino (empieza con 2–5) y añade un pequeño rate delay para dominios pesados.

Task 6: Confirm DNS resolution for MX and A/AAAA

cr0x@server:~$ dig +time=2 +tries=1 MX gmail.com
;; ANSWER SECTION:
gmail.com.              300     IN      MX      10 alt1.gmail-smtp-in.l.google.com.
gmail.com.              300     IN      MX      20 alt2.gmail-smtp-in.l.google.com.

cr0x@server:~$ dig +time=2 +tries=1 A alt1.gmail-smtp-in.l.google.com
;; ANSWER SECTION:
alt1.gmail-smtp-in.l.google.com. 300 IN A 142.250.102.26

Qué significa: Si esto es lento, da SERVFAILs o caduca, tienes un problema de DNS que se manifestará como 4.4.x o “temporary lookup failure”.

Decisión: Si DNS es inestable, arregla los resolvers primero. La entrega de correo depende de un DNS sano.

Task 7: Check resolver health (systemd-resolved)

cr0x@server:~$ resolvectl status | sed -n '1,40p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 127.0.0.53
       DNS Servers: 10.0.0.2 10.0.0.3
        DNS Domain: corp.local

Qué significa: Estás usando un resolvedor stub local; los servidores upstream están listados. Si los upstream están mal o inalcanzables, espera fallos intermitentes.

Decisión: Si los upstream son internos y están sobrecargados, cambia a resolvers conocidos o ejecuta un resolvedor de caché local con monitorización.

Task 8: Test outbound SMTP connectivity (TCP and banner)

cr0x@server:~$ nc -vz alt1.gmail-smtp-in.l.google.com 25
Connection to alt1.gmail-smtp-in.l.google.com 25 port [tcp/smtp] succeeded!

cr0x@server:~$ timeout 5 bash -lc 'exec 3<>/dev/tcp/alt1.gmail-smtp-in.l.google.com/25; head -n 1 <&3'
220 mx.google.com ESMTP

Qué significa: Si la conexión TCP falla o la lectura del banner caduca, sospecha de firewall, enrutamiento, pérdida de paquetes o outage remoto.

Decisión: Si esto falla de forma amplia, escala a red. Si falla solo con un proveedor, verifica listas de bloqueo o reputación/política.

Task 9: Verify IPv6 isn’t silently breaking outbound delivery

cr0x@server:~$ getent ahosts alt1.gmail-smtp-in.l.google.com | head
2607:f8b0:4004:c06::1a STREAM alt1.gmail-smtp-in.l.google.com
2607:f8b0:4004:c06::1a DGRAM
2607:f8b0:4004:c06::1a RAW
142.250.102.26 STREAM
142.250.102.26 DGRAM
142.250.102.26 RAW

Qué significa: Si existe IPv6, tu MTA podría probarla primero. Si tu enrutamiento IPv6 está roto, verás timeouts y diferimientos.

Decisión: Si la ruta v6 es poco fiable, arréglala o prefiere IPv4 para SMTP hasta que sea confiable.

Task 10: Check disk space and inode exhaustion (queue writes)

cr0x@server:~$ df -h /var/spool/postfix
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        40G   39G  620M  99% /var

cr0x@server:~$ df -i /var/spool/postfix
Filesystem      Inodes   IUsed   IFree IUse% Mounted on
/dev/sda2      2621440 2620101   1339  100% /var

Qué significa: Espacio o inodos al 99–100% causarán errores de escritura en la cola y diferimientos 451/452.

Decisión: Libera espacio/inodos de inmediato (rota logs, elimina archivos antiguos), luego planifica expansión del filesystem de la cola y formateo con inodos adecuados.

Task 11: Check I/O latency (a common hidden villain)

cr0x@server:~$ iostat -xz 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          3.01    0.00    1.24   18.55    0.00   77.20

Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
sda              5.12   92.40   164.0  8120.3  98.40   1.12  99.60

Qué significa: await cerca de 100ms y %util cerca de 100% indica un disco saturado. Las colas de correo odian esto.

Decisión: Reduce la concurrencia, mueve la cola a almacenamiento más rápido o detén al vecino I/O ruidoso (backups, scans AV, tormentas de snapshots).

Task 12: Confirm Postfix processes are alive and not stuck

cr0x@server:~$ sudo systemctl status postfix --no-pager
● postfix.service - Postfix Mail Transport Agent
     Loaded: loaded (/lib/systemd/system/postfix.service; enabled)
     Active: active (exited) since Wed 2026-01-03 10:58:01 UTC; 10min ago
    Process: 1123 ExecStart=/bin/true (code=exited, status=0/SUCCESS)

cr0x@server:~$ ps -ef | egrep 'postfix/(master|qmgr|smtp|pickup)' | head
root      1180     1  0 10:58 ?        00:00:00 /usr/lib/postfix/sbin/master -w
postfix   1182  1180  0 10:58 ?        00:00:00 pickup -l -t unix -u
postfix   1183  1180  0 10:58 ?        00:00:00 qmgr -l -t unix -u

Qué significa: Postfix parece vivo. Si la cola no se vacía, céntrate en errores de entrega y dependencias en lugar de reiniciar a ciegas.

Decisión: Reinicia solo si tienes evidencia de un proceso bloqueado o un cambio de configuración; los reinicios pueden amplificar tormentas de cola.

Task 13: Measure queue age and “how bad is it”

cr0x@server:~$ mailq | awk 'BEGIN{old=0} /^[A-F0-9]/{id=$1} /^[[:space:]]*[A-Z][a-z]{2}[[:space:]]/{print}' | tail -n 5
     Wed Jan  3 08:41:22  user@outlook.com
     Wed Jan  3 08:41:23  user@gmail.com
     Wed Jan  3 08:41:24  user@yahoo.com
     Wed Jan  3 08:41:25  user@proton.me
     Wed Jan  3 08:41:26  user@example-corp.com

Qué significa: Entradas antiguas en la cola implican incapacidad prolongada para entregar. Ya no es solo un parpadeo transitorio.

Decisión: Si el correo más antiguo tiene horas de antigüedad para tráfico transaccional, empieza mitigaciones: cambios de throttling por dominio, separar pools, enrutar vía MTA alternativo o pausar envíos masivos.

Task 14: Check for too many open files (classic 451 local errors)

cr0x@server:~$ cat /proc/$(pgrep -n master)/limits | egrep 'open files|Max processes'
Max processes             127528               127528               processes
Max open files            1024                 1048576              files

Qué significa: Si Max open files es bajo (p. ej., 1024), la alta concurrencia puede alcanzar el agotamiento de FD bajo carga.

Decisión: Eleva límites para Postfix mediante overrides de systemd y ajusta concurrencia para coincidir con la realidad del disco/red.

Task 15: Validate TLS from your host to a target (debug handshake failures)

cr0x@server:~$ openssl s_client -starttls smtp -connect alt1.gmail-smtp-in.l.google.com:25 -servername alt1.gmail-smtp-in.l.google.com -brief < /dev/null | head -n 12
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN=mx.google.com
Verification: OK
250 SMTPUTF8

Qué significa: TLS funciona end-to-end desde este host. Si Postfix informa 454, puede ser un desajuste de política, problema del almacén CA o interferencia del milter.

Decisión: Si esto falla, arregla el bundle CA del sistema, ajustes de SNI/ciphers o middleboxes de red antes de tocar el enrutamiento de correo.

Task 16: Spot milter/filter delays (symptom: local tempfail)

cr0x@server:~$ sudo journalctl -u postfix --since "30 min ago" | egrep -i 'milter|timeout|warning' | tail -n 20
Jan 03 11:10:12 server postfix/smtpd[2841]: warning: milter inet:127.0.0.1:8891: can't read response packet: Connection timed out
Jan 03 11:10:12 server postfix/smtpd[2841]: warning: milter inet:127.0.0.1:8891: aborting milter conversation
Jan 03 11:10:12 server postfix/smtpd[2841]: warning: milter inet:127.0.0.1:8891: unavailable: temporary failure

Qué significa: Tu dependencia de filtrado está expirando, empujando SMTP a fallos temporales.

Decisión: Restaura la capacidad del filtro, evita para tráfico crítico o establece timeouts/política de conmutación deliberadamente.

Tres microhistorias corporativas de producción

Microhistoria 1: El outage causado por una suposición equivocada (“4xx significa que el otro lado está caído”)

La empresa ejecutaba un par de relays Postfix delante de una flota de aplicaciones. Todo estaba “bien” hasta un martes por la mañana cuando los restablecimientos de contraseña empezaron a retrasarse. El de guardia vio 451 4.4.2 Timeout while waiting for server greeting y decidió que el proveedor mayor debía estar teniendo un incidente. Esa suposición les dio a todos dos horas de espera.

Mientras tanto la cola de correo creció. No solo para el proveedor mayor—para casi todos. La pista estaba enterrada en los registros: los timeouts ocurrieron con dominios que no tenían nada en común. El equipo siguió culpando “a Internet”, lo cual es una señal de que se han quedado sin ideas.

Un ingeniero de red finalmente corrió una prueba directa de banner y notó algo extraño: la conexión TCP se establecía rápido, pero la lectura del banner SMTP se quedaba colgada. Eso no es “el remoto está caído”. Es “los paquetes se están comiendo”. El culpable fue una actualización de firewall stateful que redujo el tamaño de la tabla de seguimiento de conexiones. Bajo carga normal estaba bien; bajo pico descartaba flujos nuevos y algunos establecidos de forma impredecible.

La solución fue mundana: restaurar la capacidad de tracking y reducir la concurrencia SMTP innecesaria por unas horas mientras la acumulación se drenaba. La acción del postmortem fue más importante que la perilla del firewall: “Cuando ves timeouts 4.4.x en múltiples dominios no relacionados, trátalo como tu red hasta que se demuestre lo contrario.”

Microhistoria 2: La optimización que salió mal (cola en almacenamiento compartido “rápido”)

Otra organización decidió “modernizar” sus relays de correo. Movieron la cola de Postfix de un SSD local a un filesystem de red compartido porque era “durable” y “más fácil de gestionar”. El cambio pasó porque sonaba a mayor fiabilidad.

Al principio funcionó. Luego se introdujo un job de backup que tomaba snapshots consistentes de ese mismo almacenamiento compartido. Cada hora, a la hora, el proceso de snapshot causaba un pico en la latencia. Las entregas SMTP se ralentizaron, luego se diferieron, y la cola creció. El error fue una mezcla de fallos locales 451 4.3.0 y timeouts aleatorios, porque cuando el gestor de cola se atasca lo suficiente, todo lo demás empieza a parecer roto.

El equipo respondió con el ritual estándar malo: reiniciar Postfix. Temporalmente “ayudó”, mayormente al resetear trabajo en vuelo y dar la ilusión de acción. Pero cada reinicio hacía la recuperación más lenta porque aumentaba el churn de conexiones y forzaba más handshakes TLS.

La solución final fue dejar de tratar la cola de correo como un directorio de logs. La movieron de vuelta al SSD local, habilitaron monitorización adecuada para latencia de disco y trataron el almacenamiento compartido como lugar para backups—no para escrituras en el camino crítico. La lección fue directa: la entrega de correo es sensible al I/O, y el “almacenamiento compartido duradero” puede ser una trampa de rendimiento si la latencia no está muy controlada.

Microhistoria 3: La práctica aburrida y correcta que salvó el día (separación de clases de tráfico)

Una empresa en realidad hizo lo poco glamoroso: separaron correo transaccional del masivo. Dos identidades lógicas de remitente, dos pools de IP, colas diferentes, límites de tasa distintos. Sonó a burocracia y fue impopular—hasta que dejó de serlo.

Una campaña salió con un error tipográfico en un segmento que causó un aluvión de destinatarios inválidos. Las tasas de rebote se dispararon, y un receptor mayor empezó a devolver diferimientos de política temporales (421 4.7.0). La cola masiva se amontonó rápido, como una driza de nieve contra una puerta.

Pero el correo transaccional siguió fluyendo. Restablecimientos de contraseña y notificaciones de factura se enrutarán por el pool transaccional con higiene de listas más estricta y un perfil de volumen estable. Ese pool tenía límites de concurrencia por dominio separados y una política de reintentos distinta. Casi no sufrió throttling.

La respuesta al incidente fue casi aburrida: pausaron el envío masivo, corrigieron el segmento, dejaron que la cola masiva se vaciara despacio y mantuvieron el correo crítico sano. El postmortem leyó como un cuento para dormir: “La separación aburrida de responsabilidades evitó retrasos en correos que afectan a los ingresos.” No hizo a nadie famoso, lo cual suele ser señal de buena ingeniería.

Datos interesantes y contexto histórico (útil, no trivia)

• SMTP precede a la era moderna del spam. Fue diseñado en una red más confiada, por eso tanta política de rechazo está añadida hoy en día.
• Los fallos temporales se convirtieron en arma y escudo. El greylisting popularizó usar 4xx para hacer perder tiempo a los spammers, apostando a que MTAs legítimos reintentarán.
• Los códigos aumentados (como 4.7.0) se introdujeron para añadir precisión más allá de las respuestas de tres dígitos, porque “451” solo no era suficientemente expresivo para fallos de política modernos.
• Las colas de correo son intencionalmente persistentes. SMTP asume que las redes fallan; encolar y reintentar es la idea central. Tu trabajo es evitar que la cola se convierta en un vertedero.
• Históricamente, algunos MTAs reintentaban durante una semana o más. Tenía sentido cuando los enlaces eran poco fiables; hoy puede convertir una caída corta en días de notificaciones retrasadas.
• Las comprobaciones RBL/RHSBL y la política basada en DNS explotaron con el spam. La fiabilidad del resolver se volvió crítica para el correo, por eso los fallos de resolver pueden parecer “el correo está caído”.
• TLS para SMTP empezó como cifrado oportunista. Mejoró la privacidad sin requerir coordinación, pero también creó casos límite donde “a veces TLS funciona” se vuelve una variable de entrega.
• Los grandes proveedores de buzón operan como objetivos DDoS. Sus throttles son parte de la supervivencia; si envías a escala, negocias con sus sistemas anti-abuso.
• Incluso los bloqueos “temporales” pueden ser efectivamente permanentes si tu comportamiento de reintento activa más políticas (p. ej., reintentos concurrentes que parecen martilleo).

Errores comunes: síntomas → causa raíz → solución

“Todo está diferido” y la cola crece en muchos dominios

Síntoma: Muchos 4.4.x timeouts o “temporary lookup failure”, afectando destinatarios diversos.

Causa raíz: Problemas con el resolver DNS local, agotamiento de firewall/NAT, pérdida de paquetes o IPv6 roto.

Solución: Valida DNS con dig, prueba lecturas de banner con nc//dev/tcp y aisla v4/v6. Arregla la red antes de sintonizar Postfix.

Un dominio domina los diferimientos con “Try again later”

Síntoma: 421 4.7.0 específico del proveedor o similar, mayormente un dominio.

Causa raíz: Throttling por concurrencia, pico de volumen o señales de reputación.

Solución: Baja la concurrencia por destino, añade rate delay, separa clases de tráfico y estabiliza el volumen. No reintentes agresivamente.

451 4.3.0 intermitente durante picos

Síntoma: 451 4.3.0 “internal error” / errores de escritura en cola, a menudo correlacionados con otros jobs.

Causa raíz: Disco lleno/agotamiento de inodos, o latencia I/O por backups/snapshots/escaneos AV; a veces agotamiento de FD.

Solución: Revisa df -h, df -i, iostat y límites de descriptores. Mueve la cola a almacenamiento de baja latencia y detén vecinos ruidosos.

454 4.7.0 TLS no disponible, solo para algunos destinatarios

Síntoma: TLS oportunista funciona para la mayoría, pero un subconjunto falla temporalmente.

Causa raíz: Incompatibilidad de cifrados, middlebox roto, peculiaridades SNI, problemas del almacén CA o configuración de TLS forzado mal alineada.

Solución: Reproduce con openssl s_client -starttls smtp desde el host remitente; ajusta configuración TLS o evita middleboxes.

Eliminar greylisting como si fuera un outage

Síntoma: El primer intento recibe 450, después tiene éxito, pero la gente entra en pánico de todos modos.

Causa raíz: El greylisting está funcionando como diseñado, y tus alertas son demasiado ingenuas.

Solución: Ajusta alertas a umbrales de tasa/edad, no a un solo 450. Asegura que los intervalos de reintento no sean excesivamente largos para correo crítico.

La cola drena lentamente incluso después de “arreglar el problema”

Síntoma: El receptor vuelve a aceptar correo, pero sigues acumulado durante horas.

Causa raíz: Límites de throughput del propio MTA, latencia de disco o topes de concurrencia por dominio demasiado bajos para recuperar el backlog.

Solución: Aumenta temporalmente el throughput con cuidado (más procesos worker, mayor concurrencia), vigila disco y tasas de error y luego revierte.

Listas de comprobación / plan paso a paso

Paso a paso: desde la primera alerta hasta la entrega estable

1. Fotografía el estado. Tamaño de cola, cadenas de error más comunes, dominios destinatarios principales, edad del mensaje más antiguo.
2. Clasifica la familia de error dominante. 4.4.x timeouts vs 4.7.x política vs 4.3.x errores locales.
3. Prueba o descarta problemas DNS/red locales. Consultas DNS, connect TCP, lectura de banner, sanity v4/v6.
4. Revisa la salud del almacenamiento. Espacio, inodos, latencia I/O, filesystem de la cola.
5. Revisa dependencias. Milters/filtros de contenido, proxies salientes, NAT/firewalls.
6. Aplica la mitigación más pequeña y segura. Limita por dominio, pausa tráfico masivo o reroutea correo crítico.
7. Monitorea la tasa de drenado y la tasa de errores. No declare victoria hasta que la cola esté disminuyendo y el correo nuevo se entregue normalmente.
8. Tras la estabilidad: endurecimiento post-incidente. Mejores umbrales de alerta, mejor separación de tráfico, mejores márgenes de capacidad.

Checklist operacional: qué afinar (y qué no)

• Hacer: sintoniza concurrencia por dominio y rate delay para proveedores grandes.
• Hacer: separa transaccional y masivo, idealmente por IP/identidad y a nivel de cola.
• Hacer: monitoriza latencia DNS, latencia de disco y edad de cola.
• No hacer: “arreglar” una acumulación de cola subiendo la concurrencia a ciegas; a menudo provocará más throttling y peor reputación.
• No hacer: reiniciar MTAs como primera respuesta. Es un buen último recurso. Es una terrible herramienta de diagnóstico.
• No hacer: ignorar IPv6. O ejecútalo correctamente o prefiere explícitamente IPv4 para SMTP hasta que puedas.

Checklist de alertas (evita incidentes falsos de “correo caído”)

• Alerta por edad del mensaje más antiguo para clases críticas, no solo por tamaño de cola.
• Alerta por tasa de diferidos por dominio (picos súbitos de 4.7.0).
• Alerta por tasa de SERVFAIL/timeout DNS desde hosts de correo.
• Alerta por espera I/O y lleneza del filesystem para volúmenes de cola.
• Alerta por latencia/timeout de milter si tienes milters.

Preguntas frecuentes

1) ¿Los errores SMTP 4xx son “seguros de ignorar” porque se reintentarán?

No. Los reintentos son un mecanismo, no una solución. Un pico de 4xx es o una señal de política (throttle) o una señal de fiabilidad (DNS/red/almacenamiento). Trátalo como latencia creciente en cualquier otro sistema de producción.

2) ¿Cuál es la forma más rápida de distinguir throttling de fallo de red?

Mira los códigos aumentados y la distribución. Agrupaciones de 4.7.x en un proveedor sugieren throttling/política. 4.4.x timeouts en muchos dominios sugieren problemas de red/DNS/locales.

3) ¿Por qué veo “Try again later” sin detalles útiles?

Los receptores mantienen la política deliberadamente opaca para no ayudar a los spammers. Tu mejor señal es el comportamiento: qué dominios, qué volúmenes, qué patrones de conexión y si tu identidad IP cambió recientemente.

4) ¿Cuánto tiempo debo reintentar mensajes diferidos?

Suficiente para manejar outages reales, pero lo bastante corto para no entregar notificaciones obsoletas. Muchas organizaciones ponen TTLs más cortos para notificaciones transaccionales que para correo masivo de bajo valor. Alinea el TTL con el valor de negocio.

5) ¿Pueden problemas SPF/DKIM/DMARC causar 4xx en vez de 5xx?

Sí. Algunos receptores difieren mientras evalúan reputación, esperan DNS o aplican política temporal. Además, tus propios sistemas (p. ej., milters) pueden tempfail durante consultas DNS para estas comprobaciones.

6) ¿Debo deshabilitar el greylisting en el lado receptor (si lo controlo)?

Si puedes, prefiere controles anti-abuso más modernos. El greylisting puede retrasar correo legítimo y crear ruido operativo. Si lo mantienes, whitelistéa remitentes críticos y asegura ventanas de reintento razonables.

7) ¿Por qué reiniciar Postfix a veces “lo arregla”?

Porque resetea estado, limpia procesos atascados o reduce temporalmente la concurrencia mientras el sistema vuelve a arrancar. También puede empeorar las cosas aumentando el churn de conexiones y handshakes TLS. Úsalo con evidencia, no con superstición.

8) ¿Cuál es la forma correcta de manejar un backlog masivo una vez solucionada la causa raíz?

Drena deliberadamente. Prioriza tráfico crítico, limita dominios que penalizan ráfagas y aumenta throughput solo hasta donde disco/red lo puedan soportar. De lo contrario activarás nuevos throttles y alargarás la recuperación.

9) ¿Los errores 452 siempre son por disco lleno?

No. 452 puede significar que el receptor está sobre cuota, o que el remitente no puede asignar recursos. Revisa si el texto menciona “insufficient system storage” localmente y valida tu propio disco/inodos.

10) ¿Cómo evito que los 4xx me despierten a las 3 a.m.?

Separa clases de tráfico, monitoriza la edad de la cola y razones de diferido, mantén el almacenamiento de la cola rápido y espacioso, y trata DNS como una dependencia de primera clase con su propio SLO.

Conclusión: siguientes pasos para evitar repeticiones

Los fallos SMTP 4xx rara vez son un misterio. Son solo sistemas distribuidos con corbata. Tu trabajo es dejar de adivinar y empezar a clasificar: política vs red vs recursos locales vs dependencias.

Siguientes pasos que pagan dividendos inmediatamente:

1. Añade un panel de “principales razones diferidas” (texto de error + códigos aumentados) y alerta sobre cambios súbitos.
2. Alerta sobre la edad del mensaje más antiguo para correo transaccional; deja de tratar todo el correo por igual.
3. Haz cumplir la separación de tráfico: transaccional vs masivo, idealmente con colas y políticas de tasa separadas.
4. Haz que el DNS sea aburrido: resolvers rápidos, monitorización y failover probado.
5. Protege el almacenamiento de la cola: baja latencia, espacio/inodos suficientes y sin tormentas de snapshots inesperadas.
6. Documenta la guía de diagnóstico rápido en tus runbooks, y practícala una vez mientras nada esté en llamas.

Si haces esto, los “fallos temporales” volverán a ser lo que debían ser: turbulencias ocasionales, no un estilo de vida recurrente.