Correo: «451 temporary local problem» — encuentra rápido el problema del servidor

Qué significa realmente “451 temporary local problem”

SMTP tiene dos grandes clases de fallo: permanente (5xx) y temporal (4xx).
Una respuesta 451 es un 4xx: se supone que el remitente debe reintentar más tarde. La frase “temporary local problem”
no es una ley universal; es una explicación textual común añadida por MTAs (o filtros/políticas intermedias) cuando
el servidor no puede aceptar un mensaje ahora mismo debido a una condición local.

También verás variantes como:
451 4.3.0 Temporary server error,
451 4.3.2 System not accepting network messages,
o 451 4.7.1 Try again later.
El primer número es el estado SMTP; el “código de estado mejorado” (como 4.3.0) da una pista sobre la categoría.
Pero aquí está la verdad incómoda: la parte textual suele ser genérica, y el código mejorado puede ser engañoso
cuando un filtro o un demonio de políticas es quien está hablando.

Dónde se genera el error importa

“451” puede provenir de:

• El MTA receptor (Postfix, Exchange, Sendmail, Exim).
• Un filtro de contenido (antivirus, antispam) que falla temporalmente abierto o cerrado.
• Un servicio de políticas (limitación de tasa, greylisting, comprobaciones de reputación) que agota tiempo.
• Un relay ascendente (tu smart host / proveedor saliente) devolviéndote 451.
• Tu propio MTA al intentar entregar correo saliente, aplazando a la cola.

Tu primer trabajo no es “arreglar el 451.” Tu primer trabajo es responder a una pregunta:
¿Quién dijo 451, en qué etapa y por cuál recurso local?

Una cita para mantener en la pared: La esperanza no es una estrategia. — idea parafraseada frecuentemente atribuida en círculos de ingeniería/ops.
451 es por defecto basado en la esperanza (“reintenta más tarde”). Vamos a convertirlo en evidencia.

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

Quieres encontrar el cuello de botella rápido, no escribir una carta de amor a cada archivo de log del sistema.
Trátalo como un incidente: confirma alcance, identifica el componente que falla y luego valida las restricciones más probables en orden.

Primero: confirma dónde se origina el 451 (10 minutos)

1. ¿Es entrante o saliente? Mira el rastro del mensaje en el lado remitente o los logs de tu propio MTA.
   Si eres el remitente, verás entregas “deferred”. Si eres el receptor, verás sesiones entrantes rechazadas/aplazadas.
2. Captura el fragmento exacto de la transcripción SMTP. Necesitas la línea completa, incluyendo el código mejorado y cualquier texto entre corchetes.
   “451 temporary local problem” sin contexto es como “servicio degradado” sin una gráfica.
3. Identifica el componente que habla. Postfix puede registrar “reject: 451” pero la razón podría ser “policy service unavailable.”
   Exchange puede mapear errores de transporte internos a 451 4.3.0.

Segundo: revisa las restricciones clásicas de recursos (15 minutos)

1. Disco lleno / agotamiento de inodos: spools de correo, directorios de cola, particiones de logs.
2. Crecimiento de la cola: cola de deferred explotando por problemas aguas abajo.
3. Fallos de DNS: timeouts del resolver, caché roto, DNSSEC malo o UDP/53 bloqueado.
4. Presión de CPU / memoria: filtros de contenido con timeouts, demonios de políticas atascados, pools de hilos saturados.
5. Red/TLS: timeouts de handshake, puertos salientes bloqueados, problemas de certificados, MTU extraño.

Tercero: revisa políticas y dependencias (30–60 minutos)

1. Greylisting o limitación de tasa: 451 intencionados que se presentan como “problema local”.
2. Integración Spam/AV: clamd, rspamd, Amavis, timeouts de milter.
3. Dependencias de base de datos/directorio: LDAP, SQL, Redis, servicios de reputación.
4. Retro-presión desde relay ascendente: tu smarthost te está aplazando (y tú te culpas a ti mismo).

Si sólo haces una cosa: revisa disco y DNS primero. La mayoría de incidentes 451 son o
“no podemos escribir el mensaje en ningún sitio” o “no podemos resolver algo que necesitamos ahora mismo.”

Datos interesantes y contexto histórico

• SMTP precede a la mayoría de patrones de fiabilidad modernos. Fue diseñado en una era donde “reintenta más tarde” era normal porque las redes eran poco fiables.
• 4xx es una característica, no un error. Los fallos temporales forman parte del modelo de resiliencia de SMTP; los remitentes deben poner en cola y reintentar con backoff.
• Los códigos de estado mejorados (como 4.3.0) llegaron después. Se añadieron para reducir ambigüedad, pero no todos los sistemas los implementan de forma coherente.
• El greylisting popularizó los 451 intencionales. Devuelve fallos temporales deliberadamente para ver si el remitente reintenta como un MTA real.
• Los directorios de cola son sensibles al rendimiento. Los MTAs históricamente usaron colas basadas en archivos; la latencia de disco puede convertirse en “temporary local problem” rápidamente.
• El filtrado de contenido movió el cuello de botella. Con el aumento del spam, los MTAs delegaron decisiones a milters y escáneres—añadiendo nuevos modos de fallo.
• DNS está en la ruta crítica más de lo que la gente piensa. Incluso al entregar por IP, muchas configuraciones hacen búsquedas inversas, comprobaciones SPF o consultas de políticas.
• 451 se usa a menudo para control de reputación/limitación. Algunos proveedores usan 451 para ralentizar o “bloquear suavemente” remitentes sin rechazos permanentes.

Chiste #1: El correo es el único protocolo donde “inténtalo más tarde” es una vía de éxito de primera clase. Es como un restaurante que sirve “quizá” con papas fritas.

Tareas prácticas con comandos (y qué decidir)

Estas son comprobaciones del lado servidor, seguras para producción. Cada tarea incluye: comando, salida de ejemplo, qué significa y la decisión que tomas.
Los comandos asumen un servidor Linux de correo (ejemplos de Postfix), pero la lógica se aplica a otros MTAs.

Task 1: Find the 451 in logs and extract context

cr0x@server:~$ sudo grep -R --line-number -E " 451 |451 " /var/log/mail.log | tail -n 20
/var/log/mail.log:128772:Jan  4 10:03:22 mx1 postfix/smtp[24188]: 9C2A8402C5: to=<user@example.net>, relay=mx.example.net[203.0.113.25]:25, delay=12, delays=0.1/0.02/3.1/8.8, dsn=4.3.0, status=deferred (host mx.example.net[203.0.113.25] said: 451 4.3.0 Temporary local problem (in reply to end of DATA command))

Significado: Esta es una entrega saliente. El host remoto aplazó después de DATA (fase de contenido), no en connect/HELO.
Eso apunta hacia filtrado de contenido remoto, encolamiento o problemas de recursos—menos probable DNS.
Decisión: Si muchos destinatarios del mismo dominio muestran esto, trátalo como throttling del lado remoto y ajusta reintentos/volumen;
si son muchos dominios, sospecha de tu reputación saliente o de que tu propio filtro de contenido está con timeouts.

Task 2: Check if it’s your inbound side rejecting clients

cr0x@server:~$ sudo grep -E "reject:.*451|NOQUEUE: reject:.*451" /var/log/mail.log | tail -n 20
Jan  4 10:05:09 mx1 postfix/smtpd[24501]: NOQUEUE: reject: RCPT from unknown[198.51.100.44]: 451 4.3.2 Temporary local problem; from=<sender@outside.tld> to=<user@yourdomain.com> proto=ESMTP helo=<mail.outside.tld>

Significado: La sesión entrante está siendo aplazada en RCPT. Eso suele ser política local, búsquedas, greylisting,
o una caída de dependencias (LDAP/SQL) que impide la validación de destinatarios.
Decisión: Deja de mirar colas salientes; empieza a revisar tus servicios de políticas y búsquedas de directorio.

Task 3: Check disk space where queues/spools live

cr0x@server:~$ df -hT
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sda2      ext4   40G   39G  512M  99% /
/dev/sdb1      xfs   200G   45G  155G  23% /var

Significado: El filesystem root está al 99%. Si la cola de Postfix está bajo /var/spool/postfix y /var está bien, podrías estar bien—
salvo que logs o archivos temporales estén en /. Muchas configuraciones siguen ubicando rutas críticas en /.
Decisión: Si cualquier filesystem que aloje /var/spool, /var/lib, /var/log o directorios temporales está >90%,
trátalo como un incidente activo: libera espacio, amplía el disco o mueve los spools. 451 puede ser una advertencia temprana antes de un 5xx contundente.

Task 4: Check inode exhaustion (the silent disk-full)

cr0x@server:~$ df -ih
Filesystem    Inodes IUsed IFree IUse% Mounted on
/dev/sda2       2.6M  2.6M     0  100% /
/dev/sdb1        50M  1.2M  48.8M   3% /var

Significado: Root tiene cero inodos. Puedes tener “espacio disponible” y aun así estar muerto porque el filesystem no puede crear archivos nuevos.
Los MTAs crean muchos archivos pequeños (entradas de cola). El agotamiento de inodos suele disparar “temporary local problem” porque falla la creación de archivos.
Decisión: Encuentra y borra basura que consume inodos (archivos temporales antiguos, volcados de crash, logs descontrolados) o reconstruye el filesystem con más inodos
(opciones de mkfs de ext4) si es crónico.

Task 5: Inspect Postfix queue size and deferred reasons

cr0x@server:~$ sudo postqueue -p | head -n 40
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
9C2A8402C5     3287 Thu Jan  4 10:03:21  no-reply@yourdomain.com
                                         user@example.net
                                         (host mx.example.net[203.0.113.25] said: 451 4.3.0 Temporary local problem (in reply to end of DATA command))

A1B7B40310     9121 Thu Jan  4 10:03:49  app@yourdomain.com
                                         ops@another.tld
                                         (connect to mx.another.tld[192.0.2.10]:25: Connection timed out)

-- 1245 Kbytes in 342 Requests.

Significado: Tienes múltiples modos de fallo: 451 remotos y timeouts de conexión. Esto sugiere problemas salientes amplios (red, reputación,
proveedor ascendente) más que un único problema de dominio remoto.
Decisión: Si el conteo de deferred crece rápidamente, limita remitentes, pausa campañas masivas y protege el volumen de la cola de llenar discos.
Luego aisla: ¿tienes problemas de DNS/conectividad o te están bloqueando temporalmente?

Task 6: Check the mail service health and recent restarts

cr0x@server:~$ systemctl status postfix --no-pager
● postfix.service - Postfix Mail Transport Agent
     Loaded: loaded (/lib/systemd/system/postfix.service; enabled)
     Active: active (running) since Thu 2026-01-04 09:58:12 UTC; 12min ago
   Main PID: 1218 (master)
      Tasks: 3 (limit: 18948)
     Memory: 22.1M
        CPU: 3.912s

Significado: Postfix está en ejecución. Eso no significa que esté sano, pero descarta el escenario más simple de “servicio caído”.
Decisión: Si hay reinicios repetidos, revisa OOM kills, bucles de recarga de configuración o fallos de dependencias que provoquen reinicios por watchdog.

Task 7: Look for OOM kills or kernel-level IO pain

cr0x@server:~$ sudo dmesg -T | egrep -i "oom|killed process|ext4|xfs|i/o error|blk_update_request" | tail -n 30
[Thu Jan  4 10:01:12 2026] Out of memory: Killed process 22219 (clamd) total-vm:2150340kB, anon-rss:824000kB, file-rss:0kB, shmem-rss:0kB

Significado: Tu daemon antivirus fue terminado. Si tu pipeline SMTP depende de clamd, el milter puede entrar en timeout o fallar cerrado,
resultando en aplazamientos 451.
Decisión: Estabiliza la memoria (límites, swap, restricciones de contenedor), y decide si el correo debe fallar abierto (aceptar y escanear luego)
o fallar cerrado (aplazar). En muchos entornos regulados, fallar cerrado es correcto—pero debes dimensionarlo adecuadamente.

Task 8: Validate DNS resolution from the mail server (A/MX/PTR)

cr0x@server:~$ dig +time=2 +tries=1 mx example.net
;; ANSWER SECTION:
example.net.            300     IN      MX      10 mx.example.net.

cr0x@server:~$ dig +time=2 +tries=1 a mx.example.net
;; ANSWER SECTION:
mx.example.net.         300     IN      A       203.0.113.25

Significado: DNS funciona rápido para este dominio. Si dig es lento o falla por timeout, tu MTA se bloqueará,
las colas crecerán y algunos MTAs responden 451 cuando fallan búsquedas para comprobaciones de política.
Decisión: Si DNS es lento, arregla primero la salud del resolver (caché local, alcanzabilidad de upstream, reglas de firewall).
No “afines Postfix” para compensar un DNS roto; eso es decorar una casa en llamas.

Task 9: Check reverse DNS of your outbound IP (common trigger for throttling)

cr0x@server:~$ dig +short -x 198.51.100.10
mail01.yourdomain.com.

Significado: PTR existe. Muchos proveedores no fallan en duro por un PTR faltante, pero te limitarán con respuestas 4xx.
Decisión: Si PTR falta o es incorrecto, arréglalo con tu ISP/proveedor cloud. Espera que esto reduzca “451 misteriosos” en receptores grandes.

Task 10: Check policy daemon/milter responsiveness (socket connectivity)

cr0x@server:~$ sudo ss -lntp | egrep ":10023|:10024|:8891|:8892" || true
LISTEN 0      100          127.0.0.1:10024       0.0.0.0:*    users:(("master",pid=1218,fd=15))
LISTEN 0      100          127.0.0.1:8891        0.0.0.0:*    users:(("rspamd",pid=2110,fd=12))

Significado: Tus puertos de filtrado están escuchando localmente. Eso es necesario, no suficiente.
Decisión: Si los sockets esperados no están escuchando, reinicia ese subsistema e inspecciona sus logs.
Si los sockets existen pero hacen timeout, probablemente tengas sobrecarga, contención de locks o latencia en dependencias.

Task 11: Measure local latency to the filter (a quick “is it slow?” test)

cr0x@server:~$ time (echo -e "QUIT\r\n" | nc -w 2 127.0.0.1 10024 >/dev/null)
real    0m0.006s
user    0m0.002s
sys     0m0.002s

Significado: El puerto responde rápido. Si esto tarda segundos o hace timeout, tu ruta de filtro de contenido está demorando transacciones SMTP,
y algunos clientes/servidores responden con 451 cuando se exceden presupuestos de timeout internos.
Decisión: Si está lento, escala el filtro, ajusta timeouts o evita temporalmente el escaneo para fuentes confiables mientras estabilizas.

Task 12: Check if you’re hitting connection limits or rate limits

cr0x@server:~$ sudo postconf | egrep "smtpd_client_connection_count_limit|smtpd_client_connection_rate_limit|smtpd_client_message_rate_limit"
smtpd_client_connection_count_limit = 50
smtpd_client_connection_rate_limit = 30
smtpd_client_message_rate_limit = 200

Significado: Límites agresivos pueden disparar aplazamientos 4xx para picos legítimos (restablecimiento de contraseñas, alertas de incidente, trabajos por lotes).
Decisión: Si ves picos que causan 451 para apps internas o socios confiables, aumenta límites y añade excepciones por cliente.
Mantén límites para Internet en general; solo no te ataques a ti mismo con “seguridad.”

Task 13: Inspect per-domain deferrals and concurrency (outbound shaping)

cr0x@server:~$ sudo postconf | egrep "default_destination_concurrency_limit|smtp_destination_concurrency_limit|smtp_destination_rate_delay"
default_destination_concurrency_limit = 20
smtp_destination_concurrency_limit = 20
smtp_destination_rate_delay = 0s

Significado: Alta concurrencia y sin retardo de tasa puede parecer abuso para proveedores grandes, disparando throttling temporal 451.
Decisión: Para dominios que sabes que limitan, añade transport maps con menor concurrencia y pequeños delays. Esto no es “ceder”;
es ser un vecino educado para que tu correo llegue.

Task 14: Check the immediate health of the queue filesystem (latency)

cr0x@server:~$ sudo iostat -x 1 3
Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
sda              2.00   85.00    64.0  4200.0  48.12   2.10  89.50
sdb              0.00   12.00     0.0   180.0   1.20   0.35   4.20

Significado: sda está muy utilizado con await alto. Si tu cola está en sda, tienes un cuello de botella de IO.
Los MTAs realizan mucho comportamiento tipo fsync; la latencia de IO de la cola se convierte en timeouts SMTP y aplazamientos 451.
Decisión: Mueve la cola a almacenamiento más rápido, reduce la presión de sync (con cuidado) o reduce el churn de la cola (desactiva logs innecesarios,
evita particiones de filesystem pequeñas).

Task 15: Confirm TLS works and certificates aren’t causing stalls

cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.yourdomain.com:25 -servername mx1.yourdomain.com -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN = mx1.yourdomain.com
Verification: OK

Significado: STARTTLS funciona y el certificado verifica localmente (suponiendo que tu trust store es normal).
Decisión: Si esto falla intermitentemente, revisa certificados expirados, cadenas rotas o contención de CPU durante handshakes.
Los problemas TLS pueden manifestarse como “temporary local problem” dependiendo de dónde se maneje la falla.

Task 16: Check if your upstream relay is the one deferring you

cr0x@server:~$ sudo grep -E "relay=.*\[.*\]:587|relay=.*:587" /var/log/mail.log | tail -n 10
Jan  4 10:04:11 mx1 postfix/smtp[24321]: 3F9B7402D2: to=<user@bigmail.tld>, relay=relay.provider.tld[192.0.2.50]:587, delay=4.2, dsn=4.7.1, status=deferred (host relay.provider.tld[192.0.2.50] said: 451 4.7.1 Rate limit exceeded, try again later)

Significado: El “problema local” no es local. Tu relay te está limitando.
Decisión: Deja de afinar tu MTA a ciegas. Negocia límites con el proveedor, implementa shaping saliente y verifica que no
estés filtrando tráfico spam desde cuentas comprometidas.

Mapa de causas raíz: de dónde viene 451

“Temporary local problem” es un cubo de síntomas. Aquí está el mapa que realmente uso en producción: clasifica por etapa y por dependencia.
Reduce el espacio de búsqueda rápidamente.

Clasificación por etapa

• En connect / banner: listener local sobrecargado, límites de conexiones, accept queue llena, agotamiento de conntrack del kernel, problemas de política TLS.
• En HELO/EHLO: comprobaciones de DNS inverso, restricciones de helo, consultas a servicio de políticas, decisiones de greylisting tempranas.
• En MAIL FROM / RCPT TO: búsqueda de destinatario (LDAP/SQL), restricciones de remitente, comprobaciones SPF, limitación de tasa, greylisting.
• En DATA / fin de DATA: timeouts de filtro de contenido, escaneo antivirus, servicios de puntuación antispam, fallos de escritura/commit de cola en disco.
• Después de la aceptación (bounce más tarde): no es 451; ahí recibes DSNs o descartes silenciosos. Problema distinto.

Clasificación por dependencias (los sospechosos habituales)

1) Restricciones de almacenamiento y filesystem

Si Postfix no puede crear archivos de cola, no puede escribir logs o no puede fsync a tiempo, verás fallos temporales.
Los problemas de almacenamiento aparecen como 451 porque es más seguro aplazar que aceptar y perder correo.

Vigila:
disco lleno, agotamiento de inodos, alta latencia de IO, journal saturado, fallos de NFS (sí, aún hay gente que hace esto), o overlays de contenedores que se funden.

2) Inestabilidad del DNS y del resolver

DNS no es opcional. Los MTAs buscan registros MX, validan dominios, a veces hacen reverse lookup, y los sistemas de política consultan TXT (SPF) y otros datos.
Si tu resolver hace timeout, tu transacción SMTP espera. Si espera demasiado, aplazas. Si aplazas, obtienes 451.

3) Filtrado de contenido y milters

Antivirus y antispam son fábricas frecuentes de 451. Suelen ser intensivos en CPU, demandantes de memoria y con muchas dependencias (actualizaciones, reglas, reputación externa).
Cuando fallan, o:
fallan cerrados (aplazan el correo) o fallan abiertos (aceptan sin escanear). Elige conscientemente, no por accidente.

4) Servicios de políticas y búsquedas de directorio

Verificación de destinatarios, chequeos de remitente, límites de tasa y autenticación pueden llamar a LDAP, SQL, Redis, APIs HTTP o demonios locales.
Cualquier timeout se convierte en “temporary local problem.”

5) Throttling remoto y controles de reputación

A veces 451 es simplemente el lado remoto diciendo: “Envías demasiado” o “Aún no confiamos en ti.”
Grandes proveedores lo hacen para evitar oleadas de correo y forzar buen comportamiento sin bloqueos permanentes.
Tu mejor arreglo suele ser shaping saliente más higiene de reputación, no reintentar más agresivamente.

Chiste #2: La cola de correo es como una membresía de gimnasio—todos aman tenerla, nadie ama revisar cuánto ha crecido.

Tres microhistorias corporativas (anónimas, plausibles, útiles)

Microhistoria 1: El incidente causado por una suposición errónea

Una compañía SaaS mediana operaba su propio relay Postfix para correo transaccional. Tenían una cultura de incidentes estricta y una rotación de on-call decente.
Un viernes, soporte reportó “retrasos en correo” desde un puñado de clientes empresariales. Los logs de correo mostraban muchos aplazamientos 451.

El ingeniero de guardia supuso que los destinatarios remotos los estaban limitando. Esa suposición parecía razonable: eran 451 al fin de DATA,
y las grandes empresas sí limitan. Así que ajustaron la concurrencia por dominio y volvieron a dormir.

El sábado por la mañana, la cola deferred se había triplicado. No era catastrófico, pero la tendencia era mala. El segundo ingeniero revisó espacio en disco
y encontró abundante. CPU parecía bien. Red parecía bien. Entonces notaron algo sutil: los logs de correo dejaban de actualizarse cada pocos minutos,
luego se escribían en ráfagas.

Causa raíz: agotamiento de inodos en el filesystem root, causado por una acumulación silenciosa de pequeños archivos temporales de una app no relacionada.
Postfix vivía en /var (saludable), pero syslog escribía en /var/log sobre /, y cuando syslog no pudo escribir, el equipo perdió visibilidad en tiempo real.
Mientras tanto, el filtro de contenido escribía archivos temporales en /tmp sobre /, fallando de forma intermitente y causando 451 en fin de DATA.

Solución: limpiar directorios que consumían inodos, mover rutas temporales del filtro a /var y añadir monitorización de inodos. La gran lección no fue “revisa inodos”—
fue: nunca aceptes una explicación externa confortante (“throttling remoto”) hasta probar que tu propio sistema puede escribir archivos de forma fiable.

Microhistoria 2: La optimización que resultó contraproducente

Una organización de servicios financieros quería mayor rendimiento de correo para notificaciones internas. Alguien notó que el volumen de la cola de correo estaba en discos lentos.
La optimización propuesta: mover /var/spool/postfix a un filesystem en red “por resiliencia” y liberar IO local.
Pasó una pequeña prueba. Se desplegó.

En una semana, vieron 451 intermitentes en correo entrante. No constantes—lo justo para enfurecer a la gente.
Los errores se agruparon durante ventanas de backup y congestión de red esporádica. La cola aceptaba, luego se atascaba y después aplazaba.

El postmortem fue doloroso porque nada estaba “caído”. El filesystem de red estaba “up”, la latencia estaba “dentro del SLA” y los backups “fueron exitosos.”
Pero SMTP no se impresiona con tu SLA; le importan las colas de cola y el comportamiento de fsync. Operaciones de cola que eran sub-milisegundos localmente se convirtieron
en decenas de milisegundos con ocasionales stalls de segundos. Así es como se fabrican timeouts y 451s.

Solución: devolver la cola a SSD local, mantener resiliencia a nivel de sistema (replicación, backups, configuraciones reconstruibles),
y reservar filesystems en red para cosas que no estén en la ruta síncrona de una transacción SMTP.
La “optimización” mejoró números medios y destruyó p99. El correo vive en p99.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día

Un proveedor de salud tenía requisitos estrictos de seguridad y cumplimiento, lo que implicaba escaneo entrante intensivo y comprobaciones de política conservadoras.
También tenían una práctica aburrida: cada dependencia del flujo de correo tenía un health check y un SLO, incluyendo resolvers DNS y el servicio antispam.
Nadie lo presumía en las fiestas.

Un martes, empezaron a ver un pico de aplazamientos 451 en tiempo RCPT. Los usuarios lo notaron rápido porque los recordatorios de citas se retrasaron.
El ingeniero on-call miró el dashboard y vio que la latencia de búsquedas LDAP se había convertido en una escalera.
Al mismo tiempo, el servicio SMTP en sí estaba bien.

Activaron un toggle de “modo degradado” preaprobado: la verificación de destinatarios cambió de comprobaciones LDAP estrictas a búsquedas en caché para dominios locales conocidos
durante 30 minutos, manteniendo comprobaciones estrictas para enrutamiento externo. Eso redujo los aplazamientos de inmediato.

Causa raíz: un job rutinario de mantenimiento de directorio provocó contención de locks, convirtiendo búsquedas rápidas en timeouts. Si no hubieran tenido SLOs de dependencia,
el equipo habría perseguido ajustes de Postfix, reglas de firewall y ataques de spam fantasma.

Solución: reprogramar el job de mantenimiento, añadir pooling de conexiones y timeouts, y documentar el modo degradado con guardrails.
Lo aburrido ganó: una ruta de rollback limpia más observabilidad hizo del 451 un incidente de 20 minutos en vez de medio día.

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

Estas son las trampas que mantienen a los equipos atrapados en el bucle de “probablemente es culpa del otro.” Sé mejor que eso.

1) Muchos 451 al fin de DATA → timeout del escáner → escala o evitar de forma segura

• Síntoma: 451 ocurre “in reply to end of DATA command,” especialmente en periodos de alta actividad.
• Causa raíz: pipeline antivirus/spam lento o inalcanzable; timeout de milter; OOM kills.
• Solución: revisa procesos de filtro, sockets y timeouts; añade capacidad; ajusta política fail-open/closed explícitamente; mueve directorios temporales a disco local rápido.

2) 451 en tiempo RCPT → dependencia de validación de destinatario rota → arregla LDAP/SQL/DNS

• Síntoma: “NOQUEUE: reject: RCPT … 451” y se correlaciona con latencia de directorio.
• Causa raíz: servicio de búsqueda de destinatarios (LDAP/SQL) agota tiempo; el demonio de políticas no puede alcanzar su backend.
• Solución: restaura la salud de la dependencia; añade caché; ajusta timeouts; asegura que los servicios de políticas degraden con gracia.

3) Brotes de 451 en muchos dominios → problemas del resolver DNS → arregla resolvers, no Postfix

• Síntoma: entregas aplazadas para dominios no relacionados; los logs muestran demoras en búsquedas o “temporary failure in name resolution.”
• Causa raíz: resolver local fallando, DNS upstream bloqueado, daemon de caché sobrecargado, comportamiento malo de DNSSEC.
• Solución: valida alcanzabilidad del resolver; reinicia caché; usa resolvers redundantes; reduce fallos por DNSSEC; monitoriza latencia de consultas.

4) La cola crece, pero la CPU parece bien → latencia de disco → reubica cola / arregla IO

• Síntoma: la cola deferred crece; load average bajo; pero la entrega es lenta.
• Causa raíz: latencia en cola de almacenamiento; filesystem casi lleno; agotamiento de inodos; commits de journal lentos.
• Solución: revisa iostat; mueve cola a SSD; libera espacio; aumenta capacidad de inodos; evita filesystem en red para la cola.

5) Dominios remotos devuelven 451 4.7.1 → throttling/reputación → modela tráfico y limpia

• Síntoma: remoto o relay dice “rate limit exceeded,” “try again later,” “temporarily deferred.”
• Causa raíz: demasiada concurrencia, campañas explosivas, remitente comprometido, mala reputación IP/dominio, PTR faltante.
• Solución: implementa límites por dominio; arregla PTR y HELO; aplica autenticación saliente; rota credenciales; pon en cuarentena cuentas comprometidas.

6) “Reiniciamos Postfix y desapareció” → resets de dependencias ocultas → encuentra el eslabón débil real

• Síntoma: reiniciar “arregla” 451 temporalmente; vuelve después.
• Causa raíz: el reinicio resetea colas, sockets o caché DNS; el problema subyacente persiste (memory leak, filtro atascado, resolver sobrecargado).
• Solución: correlaciona con gráficas de recursos; identifica qué subsistema se recupera con el reinicio; arregla ese componente y añade monitorización.

Listas de verificación / plan paso a paso

Cuando te pasan el aviso: lista de triage de 15 minutos

1. Consigue un ejemplo concreto: un remitente, un destinatario, una marca temporal, una línea SMTP completa.
2. Determina la dirección: aplazamientos entrantes vs salientes.
3. Revisa disco + inodos en cualquier filesystem involucrado en cola, logs, temporales y filtros.
4. Revisa la velocidad de DNS desde el host MTA, no desde tu portátil.
5. Revisa crecimiento de cola: ¿sube el conteo de deferred? ¿la cola activa está atascada?
6. Revisa salud de filtros/políticas: sockets escuchando, procesos vivos, OOM kills recientes.
7. Revisa respuestas de relays ascendentes: ¿te están limitando?
8. Elige contención: limita remitentes, pausa mail masivo, habilita modo degradado para comprobaciones no críticas.

Acciones de contención (haz esto antes de “ajustes profundos”)

• Protege el disco: si la partición de la cola corre riesgo, detén fuentes de correo no esenciales (marketing, informes) antes de llenarla.
• Reduce concurrencia: modela saliente hacia dominios o relay afectados para dejar de activar throttles.
• Fail open vs fail closed: decide explícitamente para los filtros. Si debes fallar cerrado, escala ahora, no después.
• Extiende intervalos de reintento con cuidado: no crees una tormenta de reintentos. El backoff es una herramienta, no un escondite.

Plan de estabilización (mismo día)

1. Arregla la dependencia real: disco, DNS, filtro, directorio o red.
2. Drena la cola de forma segura: verifica throughput y vigila IO y latencia mientras se vacía.
3. Confirma con pruebas externas de entrega: elige algunos dominios representativos y valida end-to-end.
4. Pon guardrails: monitorización de inodos, latencia de resolver, tiempo de respuesta del filtro y profundidad de cola.

Plan de endurecimiento (esta semana)

• Sistemas de archivos separados: cola, logs y temporales no deberían competir en la misma partición pequeña.
• Establece timeouts sensatos: los demonios de políticas deben fallar rápido, no colgar las sesiones SMTP indefinidamente.
• Introduce shaping por dominio: especialmente para receptores que sabes que limitan.
• Audita quién puede enviar: autenticación saliente y límites por cuenta/app evitan que una sola cuenta comprometida queme reputación.
• Realiza un “simulacro de incendio” de correo trimestral: simula fallo de DNS, disco casi lleno y outage de filtro; confirma que el comportamiento coincide con tu intención.

Preguntas frecuentes

1) ¿451 siempre es culpa del servidor receptor?

No. Si estás enviando, el servidor receptor podría estar aplazándote. Pero tu propio relay, servicios de políticas, escáneres, DNS o almacenamiento también pueden generar 451.
La línea de log te dice quién lo dijo—lee la porción host ... said: cuidadosamente.

2) ¿Por qué algunos servidores usan 451 en lugar de un error claro?

Porque SMTP espera reintentos, y aplazar es más seguro que rechazar cuando el problema puede desaparecer (picos de carga, caída temporal de backend).
Además, algunos operadores prefieren bloqueos suaves para gestionar abuso sin crear rebotes permanentes.

3) ¿Cuál es la diferencia entre 451 y 421?

Ambos son temporales. 421 suele significar “servicio no disponible” y a menudo resulta en el cierre de la conexión.
451 es más “error local al procesar” y puede ocurrir en etapas específicas (RCPT/DATA).

4) Solo vemos 451 para un dominio destinatario. ¿Qué hacer?

Supón throttling o un problema remoto primero, pero valida lo básico: reputación de tu IP saliente, PTR, nombre HELO y si estás enviando ráfagas.
Implementa límites de concurrencia por dominio y retraso de tasa. Si persiste, contacta a los administradores del dominio destinatario con timestamps y IDs de cola.

5) ¿Podría ser greylisting la causa?

Sí. Greylisting devuelve intencionalmente errores temporales (a menudo 451 o variantes 4.7.1) a remitentes desconocidos.
Si ejecutas greylisting, confirma que no esté mal configurado o sobrecargado. Si eres remitente, confirma que tu sistema reintente correctamente y no rote IPs fuente.

6) ¿Por qué la latencia de disco causa 451 en lugar de un error más obvio “disco lleno”?

Muchos MTAs y filtros tratan las escrituras lentas o fallidas como una condición transitoria para evitar perder correo.
Si no pueden confirmar commits de archivos de cola con rapidez, aplazan en lugar de aceptar y arriesgar corrupción o procesamiento parcial.

7) ¿Cuánto tiempo reintentarán los remitentes después de un 451?

Varía. Muchos MTAs reintentan durante horas o días con backoff exponencial. Si tu sistema es el que aplaza, estás empujando dolor más allá.
Arregla el problema local rápido; no confíes en reintentos para “suavizarlo” a menos que hayas validado capacidad de cola e impacto comercial.

8) ¿Pueden problemas de SPF/DKIM/DMARC desencadenar 451?

Usualmente causan rechazos permanentes (5xx) o aceptación con puntuación de spam. Pero en sistemas reales, servicios de políticas que realizan estas comprobaciones pueden agotar tiempo.
Cuando la comprobación de política hace timeout, un servidor puede devolver 451 aunque la “causa” subyacente sea una búsqueda TXT DNS lenta.

9) Reiniciamos el filtro y 451 paró. ¿Hemos terminado?

Has terminado por ahora. Averigua por qué necesitó reiniciarse: fugas de memoria, OOM kills, actualizaciones de reglas, IO de disco o timeouts de dependencias.
Añade monitorización para salud del proceso del filtro y latencia de respuesta para que la próxima falla no sea una sorpresa.

10) ¿Debemos aumentar los timeouts de Postfix para evitar 451?

Solo si estás seguro de que la dependencia es lenta pero correcta y tienes capacidad para mantener conexiones abiertas.
Aumentar timeouts puede convertir “fallo temporal” en “sesiones colgadas,” lo cual es peor bajo carga. Arregla la dependencia primero.

Conclusión: pasos siguientes para evitar reincidencias

“451 temporary local problem” no es un diagnóstico; es una invitación a ser sistemático.
Las victorias más rápidas vienen de tratar el correo como cualquier otra canalización de producción: identifica el componente que habla,
luego revisa las restricciones que causan aplazamiento—almacenamiento, DNS, filtros, backends de políticas y throttles ascendentes.

Pasos prácticos siguientes:

1. Añade monitorización de inodos en filesystems de cola/log/temp, no sólo el porcentaje de disco.
2. Mide la latencia del resolver desde el host MTA y alerta por timeouts.
3. Rastrea profundidad y antigüedad de la cola: conteo de deferred y edad del mensaje más antiguo importan más que “servicio arriba.”
4. Instrumenta filtros y demonios de políticas: tiempo de respuesta, tasa de error, OOM kills.
5. Implementa shaping saliente por dominio receptor principal y por relay ascendente.
6. Escribe tus decisiones de fail-open/closed para escaneo y comprobaciones de políticas, y pruébalas en un simulacro.

La meta no es eliminar 451 para siempre. La meta es volverlo aburrido: rápido de atribuir, rápido de contener y raro de repetir.