Postfix: Manual de colapso de la cola (cuando el correo se detiene de repente)

Guía de diagnóstico rápido (primeros 15 minutos)

Si el correo “se detiene de repente”, tienes un trabajo: identificar el cuello de botella que limita el rendimiento. El segundo trabajo es no amplificar el daño al vaciar colas a ciegas o reiniciar todo en pánico. Postfix es bueno entregando correo despacio y de forma segura. Aún puedes hacerlo entregar correo rápido y peligrosamente.

Minuto 0–2: Confirmar el modo de falla

• ¿El correo no entra al sistema? (problema de aceptación SMTP entrante, postscreen, fallos TLS, firewall)
• ¿El correo entra pero no sale? (problemas de entrega remota, crecimiento de la cola deferred)
• ¿El correo sale pero con retraso? (cuello de botella de rendimiento: disco, DNS, filtro de contenido, límites de tasa)

Minuto 2–5: Identificar qué cola está creciendo

• Atasco en entrada/cleanup: muchos mensajes en maildrop o actividad intensa de cleanup
• Atasco en la cola active: active permanece enorme; qmgr no puede mover rápido suficiente
• Atasco en la cola deferred: la entrega remota falla o es lenta; timers de backoff se apilan

Minuto 5–10: Encontrar el recurso que está saturado

• Disco/IOPS: agitación del directorio de la cola; fsync storms; controlador RAID que llora en silencio
• DNS: búsquedas MX lentas, consultas RBL, timeouts de DNS
• Red: puerto 25 saliente bloqueado/filtrado; pérdida de paquetes; rarezas de MTU
• CPU: handshakes TLS, escaneo de contenido, mapas regex, milters
• Límites de concurrencia: concurrencia por dominio, default_destination_concurrency_limit, límites de anvil

Minuto 10–15: Elegir una acción segura

• Si el disco está lleno: detener la hemorragia (rechazos temporales), liberar espacio, no vaciar la cola.
• Si el DNS es lento: arreglar el resolvedor o omitir temporalmente las búsquedas RBL; no aumentes la concurrencia.
• Si un filtro aguas abajo es lento: omítelo o escálalo; no reinicies Postfix repetidamente.
• Si un proveedor remoto está demorando: limitar por dominio; no intentes forzar con bucles de flush.

Una cita para mantenerte honesto. Como idea parafraseada de W. Edwards Deming: “Sin datos, eres solo otra persona con una opinión.” En los colapsos de cola, las opiniones son cómo terminas con un segundo incidente.

Modelo mental del colapso de la cola

Postfix es una tubería con buffers. Cuando una etapa se enlentece, los buffers aguas arriba se llenan. Tu trabajo es localizar la etapa lenta y o bien acelerarla o reducir la entrada para que el sistema pueda vaciarse. El peligro es que la propia cola se convierta en la carga de trabajo: cada mensaje es un archivo pequeño, cada reintento genera más IO de disco, cada rebote genera más correo.

Qué significa realmente “colapso”

Un verdadero colapso de cola no es solo “mucho correo”. Es “el sistema dedica más tiempo a gestionar la cola que a entregar correo”. Se ve como:

• crecimiento rápido de las colas deferred y/o active
• carga promedio subiendo sin un rendimiento útil equivalente
• uso de disco y espera de IO en aumento
• líneas de log que repiten las mismas fallas temporales
• procesos de correo acumulándose: smtp, qmgr, cleanup, trivial-rewrite, tlsmgr

Tres categorías de parada

1. Parada de aceptación: fallan las conexiones entrantes, las entregas con autenticación o los mensajes no se pueden encolar.
2. Parada de planificación: los mensajes están en cola pero qmgr no puede programar/entregar lo suficientemente rápido.
3. Parada de entrega: la entrega remota falla, es lenta o está limitada, por lo que domina la cola deferred.

La clave es resistir la tentación de “vaciar todo”. Eso es como resolver un atasco de tráfico abriendo todas las entradas y diciéndole a la gente que conduzca más rápido. El atasco solo se traslada a la siguiente intersección, normalmente el disco.

Broma #1: SMTP significa “A veces el correo se toma una Pausa”. Desafortunadamente, la pausa siempre ocurre en horario laboral.

Hechos interesantes y contexto histórico

El correo es más antiguo que la marca de tu proveedor en la nube, y muchos de sus bordes afilados son artefactos históricos. Algunos hechos concretos que ayudan durante incidentes:

1. Postfix fue diseñado como una alternativa segura a Sendmail, con múltiples procesos pequeños para reducir el radio de explosión cuando algo falla.
2. SMTP se construyó para una Internet más amable; las fallas temporales y los reintentos son fundamentales, no una excepción—tu cola es una característica intencionada.
3. El comportamiento de backoff es deliberado: Postfix no bombardea un dominio remoto continuamente; espacia los reintentos para ser cortés y evitar un auto-DDoS.
4. El diseño “cola como archivos” significa que el rendimiento de almacenamiento importa mucho más de lo que muchos equipos esperan; miles de operaciones con archivos pequeños pueden derrotar a un disco lento.
5. El DNS es parte de tu camino crítico para la entrega remota. Cuando los resolvedores son lentos, el correo “se detiene” aunque Postfix esté sano.
6. El greylisting volvió en la era del spam; intencionalmente provoca fallas temporales, lo que puede inflar el tamaño de la cola si no planificas capacidad.
7. Las consultas RBL son una dependencia oculta: un proveedor de listas negras lento o roto puede bloquear sesiones SMTP y asfixiar el rendimiento.
8. TLS en todas partes aumentó el coste de CPU por conexión; en relays ocupados, la sobrecarga de handshake es un factor real de escalado, no un error de redondeo.
9. El throttling de proveedores de buzones es normal: los grandes proveedores difieren agresivamente cuando aumentas el volumen o activas controles de reputación; no puedes “ganar por concurrencia” contra la reputación.

Tareas prácticas: comandos, qué significa la salida, qué decides

Estas son las tareas que realmente ejecuto cuando suena el pager. Cada una tiene tres partes: comando, cómo leerlo y la decisión que impulsa. Úsalas en orden, no como un buffet.

Tarea 1: Confirmar que Postfix está activo y qué cree que está haciendo

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 Tue 2026-02-04 09:12:08 UTC; 2h 14min ago
   Main PID: 1243 (master)
      Tasks: 6 (limit: 18689)
     Memory: 21.3M
     CGroup: /system.slice/postfix.service
             ├─1243 /usr/lib/postfix/sbin/master -w
             ├─1301 qmgr -l -t unix -u
             ├─1302 pickup -l -t unix -u
             └─1303 tlsmgr -l -t unix -u

Significado: Si Postfix no está activo, estás en territorio de “servicio caído”. Si está activo, el problema suele ser aguas abajo (DNS, red, remoto, filtros) o aguas arriba (disco lleno, permisos).

Decisión: Si está inactivo/fallado, revisa los logs del journal inmediatamente antes de reiniciar. Si está activo, no reinicies de forma reflejo; recopila evidencia primero.

Tarea 2: Ver tamaño y forma de la cola de un vistazo

cr0x@server:~$ mailq | head -n 20
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
A1B2C3D4E5     2456 Tue Feb  4 11:23:05  alerts@example.net
                                         user1@corp.tld

F6G7H8I9J0     1879 Tue Feb  4 11:23:06  noreply@corp.tld
                                         external@bigmail.tld

-- 4821 Kbytes in 217 Requests.

Significado: La última línea es el titular. Requests son entradas de cola; no necesariamente correos únicos si tienes múltiples destinatarios por mensaje.

Decisión: Si las requests crecen rápido, pasa a “qué cola está creciendo” y “por qué falla la entrega.”

Tarea 3: Separar conteos de active vs deferred vs maildrop

cr0x@server:~$ postqueue -p | tail -n 1
-- 4821 Kbytes in 217 Requests.

cr0x@server:~$ find /var/spool/postfix/active -type f | wc -l
53

cr0x@server:~$ find /var/spool/postfix/deferred -type f | wc -l
10241

cr0x@server:~$ find /var/spool/postfix/maildrop -type f | wc -l
0

Significado: Un deferred gigante con active pequeño suele significar que la entrega remota falla/está limitada. Un maildrop grande puede significar problemas con pickup/cleanup o ralentización del filtro de contenido.

Decisión: Deferred grande: enfócate en respuestas remotas y en DNS/red. Maildrop grande: enfócate en la tubería local (cleanup, milters, disco, permisos).

Tarea 4: Leer los últimos 15 minutos de logs de correo como un adulto

cr0x@server:~$ journalctl -u postfix --since "15 min ago" --no-pager | tail -n 80
Feb 04 13:18:02 server postfix/smtp[22190]: connect to bigmail.tld[203.0.113.10]:25: Connection timed out
Feb 04 13:18:02 server postfix/smtp[22190]: A1B2C3D4E5: to=<external@bigmail.tld>, relay=none, delay=620, delays=0.1/0.1/620/0, dsn=4.4.1, status=deferred (connect to bigmail.tld[203.0.113.10]:25: Connection timed out)
Feb 04 13:18:05 server postfix/qmgr[1301]: warning: private/anvil: connection refused
Feb 04 13:18:05 server postfix/master[1243]: warning: process /usr/lib/postfix/sbin/anvil pid 22144 exit status 1

Significado: “Connection timed out” apunta a egress de red, firewall, bloqueo del proveedor o enrutamiento. Anvil fallando es un síntoma local (agotamiento de recursos, límites o problemas de sistema de ficheros).

Decisión: Para timeouts, valida conectividad saliente y la política de puerto 25. Para fallos de anvil, revisa espacio en disco/inodos y límites de procesos antes de reiniciar.

Tarea 5: Verificar conectividad saliente al puerto 25 hacia el mundo

cr0x@server:~$ nc -vz -w 5 203.0.113.10 25
nc: connect to 203.0.113.10 port 25 (tcp) timed out: Operation now in progress

Significado: Si esto caduca de forma general, la ruta de red está bloqueada o rota. Si funciona con algunos hosts pero no con otros, puedes estar lidiando con bloqueo específico de proveedor o problemas de enrutamiento.

Decisión: Si el puerto 25 saliente está bloqueado, deja de ajustar Postfix y habla con tu equipo de red o proveedor en la nube. Ningún ajuste de cola solucionará una política de bloqueo.

Tarea 6: Inspeccionar la salud del DNS y la latencia de las consultas

cr0x@server:~$ dig +tries=1 +time=2 MX bigmail.tld
;; communications error to 10.0.0.53#53: timed out
;; no servers could be reached

Significado: Si el DNS no responde rápido, Postfix no puede enrutar correo de forma fiable. Verás deferrals, sesiones lentas y colas en crecimiento.

Decisión: Arregla los resolvedores primero (alcanzabilidad, rendimiento, cache). Considera reducir temporalmente las comprobaciones dependientes de DNS (RBL) durante el incidente—de forma segura y con rollback claro.

Tarea 7: Identificar las principales razones de defer

cr0x@server:~$ grep -h "status=deferred" /var/log/mail.log | tail -n 2000 | sed -E 's/.*deferred \((.*)\)$/\1/' | sort | uniq -c | sort -nr | head
  312 connect to bigmail.tld[203.0.113.10]:25: Connection timed out
  141 host mx.other.tld[198.51.100.25] said: 451 4.7.1 Try again later
   88 lost connection with mx.slow.tld[192.0.2.77] while receiving the initial server greeting

Significado: Esto convierte una queja de “el correo está caído” en causas ordenadas por prioridad. Los timeouts difieren de los 451 deferrals; las soluciones difieren también.

Decisión: Timeouts: red. 451 try later: throttling remoto/reputación, así que limita. Lost greeting: remoto lento/sobrecargado o tu red es inestable; reduce concurrencia y timeouts.

Tarea 8: Ver si estás limitado por CPU o IO

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  1      0 184320  22112 612300    0    0   120   980  900 1400 12  8 55 25  0
 3  2      0 182900  22120 612400    0    0   110  2200 1100 1800 10  7 40 43  0

Significado: Alto wa significa espera de IO: el disco es el cuello de botella. Alto us/sy significa CPU limitada (TLS, milters, escaneo).

Decisión: Espera de IO alta: reduce la agitación de la cola, reduce la entrada, considera mover colas a almacenamiento más rápido. CPU alta: reduce TLS, escala el escaneo o reduce la concurrencia hasta estabilizar.

Tarea 9: Comprobar espacio en el filesystem de spool y agotamiento de inodos

cr0x@server:~$ df -h /var/spool/postfix
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        20G   19G  700M  97% /

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

Significado: Las colas de correo consumen inodos. Puedes tener espacio libre y aún estar muerto, o tener inodos y estar muerto. Ambos se sienten igual desde la perspectiva del usuario: “el correo se detuvo”.

Decisión: Si el espacio/inodos están bajos: deja de aceptar correo no esencial, limpia basura no relacionada con correo y planifica un vaciado controlado. No inicies un bucle de flush en un filesystem al 97%.

Tarea 10: Comprobar qué procesos de Postfix se están acumulando

cr0x@server:~$ ps -eo pid,comm,pcpu,pmem,args --sort=-pcpu | head -n 15
 22501 smtp       22.4  0.2 postfix/smtp
 22480 smtp       18.1  0.2 postfix/smtp
 22310 cleanup    12.5  0.1 postfix/cleanup
 1301  qmgr        6.2  0.2 qmgr -l -t unix -u
 1243  master      0.1  0.1 /usr/lib/postfix/sbin/master -w

Significado: Muchos smtp pueden significar ralentizaciones remotas o que has permitido demasiada concurrencia. Alto cleanup puede indicar header_checks, milters o contención de disco.

Decisión: Si smtp domina y las deferrals son remotas: limita y reduce la concurrencia. Si cleanup domina: inspecciona filtros de contenido, mapas y salud del disco.

Tarea 11: Confirmar qué límites está usando Postfix

cr0x@server:~$ postconf -n | egrep -i 'queue|concurrency|recipient|timeout|anvil|milter|smtpd_client|stress|dns'
default_destination_concurrency_limit = 20
smtp_destination_concurrency_limit = 20
smtp_connect_timeout = 30s
smtp_helo_timeout = 30s
smtp_data_xfer_timeout = 180s
smtpd_milters = inet:127.0.0.1:8891
milter_command_timeout = 30s
minimal_backoff_time = 300s
maximal_backoff_time = 4000s

Significado: Esto te dice si estás configurado para un rendimiento sensato o para el caos. Los timeouts de milter y DNS son asesinos silenciosos comunes.

Decisión: Si la concurrencia es alta y los remotos son lentos, reduzca la concurrencia. Si los timeouts son demasiado estrictos, podrías estar causando deferrals autoinfligidos; ajusta con cuidado y prueba.

Tarea 12: Localizar los principales dominios destinatarios que obstruyen la cola

cr0x@server:~$ postqueue -p | awk '/^[A-F0-9]/ {id=$1} /@/ {print $NF}' | sed -n 's/.*@//p' | tr -d '><,' | sort | uniq -c | sort -nr | head
  842 bigmail.tld
  317 other.tld
  205 slow.tld

Significado: A menudo un dominio destinatario domina. Ese es tu control: limitar ese dominio en lugar de castigar a todos por igual.

Decisión: Aplica límites de concurrencia por dominio o transport maps para aislar al culpable. No aumentes globalmente la concurrencia para “vaciar más rápido”.

Tarea 13: Inspeccionar con seguridad la historia de un archivo de cola

cr0x@server:~$ postcat -q A1B2C3D4E5 | sed -n '1,80p'
*** ENVELOPE RECORDS active A1B2C3D4E5 ***
message_size:            2456
message_arrival_time: Tue Feb  4 11:23:05 2026
sender: alerts@example.net
named_attribute: log_ident=postfix/smtp
recipient: external@bigmail.tld
*** MESSAGE CONTENTS A1B2C3D4E5 ***
Received: from app01 (app01 [10.10.10.21])
        by server (Postfix) with ESMTP id A1B2C3D4E5
        for <external@bigmail.tld>; Tue,  4 Feb 2026 11:23:05 +0000 (UTC)
Subject: Alert: job failed

Significado: Puedes confirmar remitente, destinatario y tiempos sin adivinar. Útil cuando alguien afirma “nunca salió de nuestra app”.

Decisión: Si los tiempos de llegada son antiguos y los reintentos siguen fallando, deja de tratarlo como transitorio; puede ser política (IP bloqueada, reputación, filtrado saliente).

Tarea 14: Medir el comportamiento del gestor de colas y advertencias

cr0x@server:~$ postqueue -j | head -n 5
{"queue_name":"deferred","queue_id":"A1B2C3D4E5","arrival_time":1707055385,"message_size":2456,"sender":"alerts@example.net","recipients":["external@bigmail.tld"]}
{"queue_name":"deferred","queue_id":"F6G7H8I9J0","arrival_time":1707055386,"message_size":1879,"sender":"noreply@corp.tld","recipients":["external@bigmail.tld"]}

Significado: La salida JSON es apta para scripts. Puedes muestrear y construir conteos rápidos sin parsear formato humano.

Decisión: Usa esto para remediación dirigida (throttles por dominio, identificar mensajes grandes) en lugar de vaciados aleatorios.

Tarea 15: Ralentizar con seguridad por destino (quirúrgico, no global)

cr0x@server:~$ postconf -e "smtp_destination_concurrency_limit=10"
cr0x@server:~$ postconf -e "default_destination_concurrency_limit=10"
cr0x@server:~$ systemctl reload postfix

Significado: Bajar la concurrencia reduce la presión sobre disco, DNS y servidores remotos. Reload es más seguro que restart durante colas pesadas.

Decisión: Si estás viendo timeouts o deferrals 451, throttling suele mejorar el rendimiento reduciendo reintentos y churn de conexiones.

Tarea 16: Pausar la entrada cuando el spool está agonizando

cr0x@server:~$ postconf -e "smtpd_soft_error_limit=5"
cr0x@server:~$ postconf -e "smtpd_hard_error_limit=10"
cr0x@server:~$ systemctl reload postfix

Significado: Esto no es una parada total, pero obliga a clientes abusivos/rotos a retroceder. Para una pausa real de entrada, puedes temporalmente bloquear con firewall o ajustar master.cf, pero comienza con frenos suaves.

Decisión: Si disco/inodos están cerca del agotamiento, debes reducir la entrada. Descargar no puede ganar la carrera contra una manguera inagotable.

Tarea 17: Activar un requeue controlado (solo cuando sabes por qué)

cr0x@server:~$ postqueue -f
cr0x@server:~$ postqueue -p | tail -n 1
-- 4809 Kbytes in 214 Requests.

Significado: Flush indica a Postfix que reintente antes. Eso puede ayudar después de arreglar DNS o red. También puede detonar tu disco si la causa raíz sigue presente.

Decisión: Solo vacía después de arreglar el cuello de botella y haber reducido la concurrencia si es necesario. Flush es un “intenta ahora de nuevo”, no un “haz que desaparezca”.

Tarea 18: Comprobar la latencia del sistema de ficheros que asesina el rendimiento

cr0x@server:~$ iostat -xz 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          10.12    0.00    7.44   41.20    0.00   41.24

Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
sda              8.10  210.30   220.1  5400.7  58.4   3.9   92.1

Significado: Alto await y alto %util sugieren que el dispositivo está saturado. Las operaciones de cola de Postfix son sensibles a latencia, no hambrientas de ancho de banda.

Decisión: Si el almacenamiento está saturado, reduce la concurrencia, mueve la cola a almacenamiento más rápido o reduce temporalmente el logging/filtrado. No aumentes la concurrencia.

Dónde Postfix se colapsa: cuellos de botella comunes

1) Almacenamiento: tu cola es un benchmark de archivos pequeños que no pediste

Postfix utiliza el sistema de ficheros como una cola durable. Eso significa que las operaciones de metadata, búsquedas en directorios, comportamiento de fsync y disponibilidad de inodos importan. Cuando las colas crecen, Postfix realiza más operaciones de fichero: create, rename, unlink, stat, open, close. Multiplica por miles y no estás “enviando correo”. Estás probando la carga de ext4/XFS y lo que haya debajo.

Patrón de fallo: la espera de IO sube, qmgr y cleanup aparecen ocupados, el rendimiento cae, la cola crece más rápido, luego el disco se llena con mail deferred y logs. El sistema se convierte en una máquina de thrash de disco con forma de correo.

2) DNS: la dependencia silenciosa que puede detener toda la entrega

Cada entrega remota necesita DNS: búsqueda MX, A/AAAA, a veces PTR, más cualquier comprobación de política que añadas. Las fallas de DNS suelen aparecer como timeouts y correo deferred, lo que se siente como “Postfix está roto” cuando en realidad es tu resolvedor, la ruta de red hacia él o una capa de cache sobrecargada.

Culpable común: consultas RBL o de reputación. También son consultas DNS. Un solo upstream lento puede añadir segundos a cada sesión SMTP, que a escala se convierte en un paro total.

3) Política de red: la realidad del puerto 25

Muchos entornos bloquean el puerto 25 saliente por defecto. Algunos lo hacen en silencio. Si tu relay está en una red cloud con políticas de egress estrictas, puedes acabar con “connect timed out” hacia muchos destinos. Eso no es Postfix. Es la realidad.

Otro modo de fallo de red: enrutamiento asimétrico, firewalls stateful que agotan sesiones SMTP inactivas, o gateways NAT que alcanzan límites de conexiones. En un colapso de cola, creas muchas conexiones. Las tablas NAT no lo disfrutan.

4) Filtros de contenido y milters: el impuesto al rendimiento

Si ejecutas Amavis, ClamAV, SpamAssassin, OpenDKIM, OpenDMARC o milters personalizados, enhorabuena: tienes un sistema distribuido. Cualquier parte puede enlentecerse, bloquearse o fallar, y Postfix encolará tu dolor con diligencia.

Síntoma típico: maildrop aumenta, procesos cleanup suben, logs muestran timeouts de milter o “queue file write error”. Una actualización lenta del antivirus puede sentirse como una caída total del correo.

5) Throttling remoto y reputación: “451, try again later” es una decisión de política

Cuando un proveedor importante devuelve respuestas 4xx, te está pidiendo que reduzcas la velocidad. Pueden estar limitando por tasa, detectando picos o castigando la reputación. La peor respuesta es subir la concurrencia y vaciar en bucle. Eso aumenta los intentos de conexión, incrementa las deferrals y quema más tu reputación.

Respuesta mejor: limitar por dominio, espaciar los reintentos, arreglar SPF/DKIM/DMARC y dejar de enviar basura. Si envías correo legítimo, estabiliza tu patrón de envío.

Broma #2: “Reiniciamos Postfix” es el equivalente en correo de apagar y encender tu portátil—excepto que tu portátil no tiene una cola diferida de remordimiento.

Patrones de recuperación que no empeoran la situación

Estabilizar primero: reducir la carga entrante antes de “optimizar”

Los colapsos de cola suelen ocurrir durante picos: campañas de marketing, tormentas de restablecimientos de contraseña, inundaciones de alertas o una cuenta comprometida enviando spam. Si sigues aceptando a velocidad completa, apuestas a que tu almacenamiento puede superar el pico. Esa es una mala apuesta la mayor parte del tiempo.

Opciones de estabilización, de menos invasivas a más:

• Reducir concurrencia para disminuir churn de conexiones y actividad de disco.
• Desactivar temporalmente comprobaciones costosas (como una RBL lenta) si claramente es el cuello de botella y puedes asumir el riesgo.
• Limitar la tasa de clientes abusivos usando postscreen/anvil o reglas de firewall.
• Rechazar temporalmente correo no crítico (para remitentes/dominios específicos) preservando los flujos principales.

Vaciar con inteligencia: apuntar a los culpables

Cuando la cola deferred está dominada por uno o dos dominios (común con grandes proveedores), debes aislarlos. Si tratas a todos los destinos por igual, los destinos sanos se verán penalizados por el enfermo.

Enfoque práctico:

• Encontrar los dominios principales en la cola.
• Aplicar throttling por destino (vía transport maps o ajustes de concurrencia).
• Dejar que el resto fluya normalmente.

Tener cuidado con flush y requeue

Flush es apropiado después de arreglar una causa transitoria de infraestructura: caída de DNS, cambio de política de red, reinicio del resolvedor, rollback de firewall. No es apropiado si el remoto sigue deferiendo o tu disco está en llamas.

También cuidado con los hábitos de “requeue todo”. Requeue toca cada mensaje y puede generar más IO que el backlog original. Si tu cuello de botella es disco, requeue es básicamente cardio para lo que ya está exhausto.

Saber cuándo separar roles: relay vs mailbox vs submission

Una de las formas más fiables de prevenir colapsos es arquitectónica: separar la submission entrante del relay saliente, o aislar correo masivo del transaccional. En un colapso, la cola masiva no debe asfixiar los restablecimientos de contraseña.

Si no puedes separar físicamente, aún puedes separar lógicamente: IPs separadas, transports separados, directorios de cola separados (avanzado) o instancias de servicio separadas. La idea es contener modos de fallo.

Movidas de recuperación específicas de almacenamiento (lo que a los SREs les disgusta aprender a las 3 a.m.)

Si IO es el cuello de botella:

• Evita empeorar: reduce concurrencia y tasa de entrada. Cada ciclo de reintento es IO extra.
• Considera mover la cola a almacenamiento más rápido (NVMe, política de caché RAID mejor, volumen dedicado). Esto no es un movimiento “durante el incidente” a menos que lo hayas ensayado.
• Busca hogs de IO externos en el mismo filesystem: tormentas de logs, backups, escaneos antivirus del spool (sí, la gente hace esto).

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

1) Síntoma: la cola deferred crece, logs muestran “connect timed out”

Causa raíz: puerto 25 saliente bloqueado, problema de enrutamiento, límites de firewall/NAT o IP remota inalcanzable.

Solución: validar conectividad con nc a múltiples MX; revisar políticas de egress; reducir concurrencia; detener bucles de flush; involucrar red/proveedor.

2) Síntoma: maildrop crece, procesos cleanup se disparan

Causa raíz: milter/filtro de contenido lento, disco lento o comprobaciones intensas de cabecera/cuerpo.

Solución: inspeccionar timeouts de milter en logs; omitir temporalmente milters no críticos; escalar el servicio de filtro; confirmar espera de IO; reducir entrada.

3) Síntoma: la cola es enorme, pero active es pequeño y sigue rotando

Causa raíz: throttling remoto o deferrals de política causando cadencia lenta de reintentos; o concurrencia por destino demasiado baja para tu patrón de tráfico.

Solución: identificar dominios principales y mensajes de defer; aplicar throttling por dominio y estrategia de reintentos razonable; mejorar reputación y patrones de envío.

4) Síntoma: Postfix registra “queue file write error” o “No space left on device”

Causa raíz: disco lleno o agotamiento de inodos en el filesystem de spool.

Solución: liberar espacio/inodos inmediatamente; dejar de aceptar mail grande/masivo temporalmente; mover logs; limpiar basura no relacionada; luego drenar despacio.

5) Síntoma: CPU alta, muchos procesos smtp, logs relacionados con TLS

Causa raíz: sobrecarga por handshakes TLS, demasiadas conexiones salientes concurrentes o VM con CPU insuficiente.

Solución: reducir concurrencia; asegurar que no hagas operaciones costosas por mensaje; considerar tuning de reutilización de sesiones; asignar CPU o mover la carga.

6) Síntoma: todo lento, timeouts de DNS, entregabilidad intermitente

Causa raíz: resolvedor roto/sobrecargado, resolv.conf mal configurado, servidores DNS inalcanzables o RBL causando consultas lentas.

Solución: arreglar reachabilidad y cache del resolvedor; eliminar temporalmente las comprobaciones DNS más lentas; confirmar con dig latencia y tasas de error.

7) Síntoma: los usuarios reportan “enviado” pero nada llega; no hay crecimiento de cola

Causa raíz: problema en la capa de submission (auth, TLS, firewall), la aplicación apunta a un relay equivocado o el correo se enruta a otro lado.

Solución: revisar logs de submission (smtpd), fallos de autenticación y configuraciones de la aplicación; confirmar que los mensajes aparezcan en la cola usando postcat o logs.

Listas de verificación / plan paso a paso

Checklist A: Incidente “El correo se detuvo” (30–60 minutos)

1. Confirmar alcance: solo entrante, solo saliente o ambos. Revisar cola y logs.
2. Identificar tipo de cola que crece: maildrop vs active vs deferred. Usar conteos de directorios.
3. Rankear razones de falla: parsear los últimos N deferrals de los logs.
4. Comprobar espacio e inodos: filesystem del spool primero.
5. Comprobar DNS: salud del resolvedor y velocidad de búsqueda MX.
6. Comprobar puerto 25 saliente: prueba de conexión a varios MX destino.
7. Comprobar saturación: vmstat/iostat para espera IO vs CPU.
8. Elegir una palanca: limitar, omitir un filtro, arreglar DNS, arreglar egress, detener entrada.
9. Aplicar cambio mediante reload: preferir systemctl reload postfix sobre reinicios.
10. Reevaluar cada 5 minutos: tendencia de tamaño de cola, razones de defer, tendencia de IO.
11. Sólo entonces considerar flush: después de que el cuello de botella esté arreglado y la concurrencia sea sensata.
12. Comunicar claramente: qué está roto, qué se mitigó, próximos pasos y tiempo estimado de vaciado.

Checklist B: Vaciado controlado tras arreglar DNS/red

1. Reducir concurrencia temporalmente para evitar estampida.
2. Ejecutar flush una vez.
3. Vigilar espera IO y tendencia de cola 10–15 minutos.
4. Si es estable, aumentar concurrencia en pequeños incrementos.
5. Dejar de aumentar cuando la espera IO suba bruscamente o vuelvan las deferrals.

Checklist C: Cuando el almacenamiento es el cuello de botella

1. Dejar de aceptar fuentes de correo opcionales (masivo/alertas) si puedes.
2. Reducir concurrencia globalmente.
3. Encontrar y matar IO no relacionado con correo en el volumen del spool (backups, escaneos).
4. Libera espacio/inodos; rotar logs; mover archivos grandes fuera del filesystem.
5. Vaciar despacio; evitar operaciones de requeue que reescriban todo el spool.
6. Planificar un rediseño del almacenamiento de la cola después del incidente.

Tres micro-historias corporativas desde el terreno

Micro-historia 1: El fallo causado por una suposición equivocada

La empresa tenía una arquitectura “simple”: las apps enviaban correo a un relay Postfix, el relay enviaba correo a Internet. El relay vivía en una VM con CPU decente y lo que parecía suficiente disco. Todos asumieron que el correo era de bajo ancho de banda, así que no podía estresar el almacenamiento.

Un lunes, una tormenta de restablecimientos de contraseña golpeó tras un cambio de SSO. El relay aceptó correo sin problema. Luego la cola deferred empezó a crecer. Los usuarios gritaron. El ingeniero de guardia reinició Postfix dos veces—porque eso es lo que hace la gente cuando quiere sentirse involucrada.

El problema real fue el agotamiento de inodos. El filesystem tenía espacio libre pero no inodos en la partición raíz donde vivía /var/spool/postfix. La cola estaba compuesta de archivos pequeños; cada mensaje era un impuesto de inodo. El sistema no estaba “caído”, se estaba asfixiando por metadata.

Una vez que ejecutaron df -i, la solución fue mundana: liberar inodos limpiando artefactos no relacionados con el correo y mover el spool a un filesystem dimensionado adecuadamente con densidad de inodos suficiente. El reinicio no fue dañino, pero desperdició lo único que no puedes reponer durante un incidente: tiempo.

Micro-historia 2: La optimización que salió mal

Otra organización ejecutaba un relay de alto volumen y quería “vaciar colas más rápido”. Alguien aumentó límites de concurrencia por destino y acortó el backoff de reintentos. Pareció genial en una ventana de prueba tranquila. Los mensajes salían volando.

Entonces un resolvedor DNS upstream tuvo latencia intermitente. Con alta concurrencia, Postfix abrió más sesiones SMTP, lo que disparó más búsquedas DNS, lo que sobrecargó aún más el resolvedor. La entrega se ralentizó, los reintentos se apilaron y la cola se hinchó. El disco del relay alcanzó alta espera de IO y luego los logs se convirtieron en una pared de deferrals repetidos.

Habían optimizado para condiciones ideales y accidentalmente construyeron un bucle de retroalimentación bajo fallo. La alta concurrencia magnificó la inestabilidad del DNS; el backoff más corto aumentó el churn de reintentos; el spool se volvió una fábrica de trabajo inútil.

La solución fue revertir la “optimización” y hacerla resiliente: concurrencia sensata, comportamiento de backoff por defecto y un path de resolvedor endurecido con cache y monitoreo. La cola se vaciaba más despacio en días perfectos y mucho más rápido en días imperfectos—que es el único tipo de día para el cual realmente necesitas diseñar.

Micro-historia 3: La práctica aburrida que salvó el día

Una compañía relacionada con finanzas tenía control de cambios estricto y un hábito que a los ingenieros les encanta burlarse: documentaron ajustes “conocidos buenos” de Postfix y mantuvieron un runbook ligero para incidentes de correo. Nadie lo presumía. Simplemente estaba allí.

Una tarde, el correo saliente empezó a diferir con “Try again later” hacia un proveedor de buzones importante. La cola creció, pero no explosivamente. El ingeniero de guardia sacó el runbook y siguió un script simple: identificar dominios principales, aplicar throttling por dominio, evitar bucles globales de flush y mantener el correo transaccional fluyendo.

También tenían dashboards preexistentes para utilización del filesystem del spool y latencia del resolvedor. En minutos confirmaron que el DNS estaba bien y que el proveedor estaba limitando. Limitaron el destino, comunicaron el tiempo estimado de vaciado y evitaron que el incidente se convirtiera en crisis.

El proveedor se recuperó esa noche. La cola se vació durante la noche. Sin heroísmos, sin tormentas de requeue, sin cuentos de “reiniciamos el servidor y funcionó”. El mejor incidente es el que permanece aburrido.

Preguntas frecuentes (FAQ)

1) ¿Debo reiniciar Postfix durante un colapso de cola?

Rara vez. Reload suele ser más seguro. Reiniciar puede interrumpir sesiones en vuelo y provocar más reintentos, lo que significa más churn en la cola. Reinicia solo si un proceso está trabado y ya identificaste la causa.

2) ¿Es seguro ejecutar postqueue -f cuando la cola es enorme?

Seguro para la integridad de los datos, arriesgado para la estabilidad del sistema. Flush aumenta la presión de reintentos inmediatamente. Úsalo después de arreglar una causa transitoria (DNS restaurado, firewall corregido) y considera bajar la concurrencia primero.

3) ¿Por qué deferred es enorme pero active pequeño?

Porque Postfix programa un número limitado de entregas activas y difiere el resto, especialmente cuando la entrega remota falla o está limitada por política. La cola active pequeña puede ser un signo de cortesía, no de debilidad.

4) ¿Cuál es la forma más rápida de encontrar la causa raíz?

Ordenar las razones de defer en los logs y luego validar la dependencia relevante: puerto 25 saliente para timeouts, DNS para problemas de lookup, almacenamiento para espera de IO y agotamiento de inodos. No adivines.

5) ¿Cómo sé si el cuello de botella es DNS?

Si dig caduca o es lento, y los logs muestran fallos relacionados con DNS o “no route to host” después de largos retardos. También, si las sesiones SMTP se quedan atascadas antes de siquiera conectar con MX remotos, DNS suele ser el culpable.

6) ¿Puede la propia cola agotar el disco incluso después de que el pico original termine?

Sí. La cola genera IO continuo por reintentos, escrituras de logs y bounces. Si tu backoff es agresivo o tu concurrencia demasiado alta, la cola se convierte en una carga autosostenida.

7) ¿Qué pasa si solo un proveedor me está deferiendo?

Eso es común. Aísla: limita por destino, reduce concurrencia para ese dominio y deja que el resto del correo fluya. Luego trabaja en reputación, alineación de autenticación y patrones de envío constantes.

8) ¿Por qué me importan los inodos? Tengo espacio libre en disco.

Porque la cola son muchos archivos pequeños. Si te quedas sin inodos, no puedes crear archivos de cola aunque bytes estén libres. Es un fallo clásico de “el sistema parece bien hasta que no lo está”.

9) ¿Cómo detecto si un milter es el problema?

Busca mensajes de timeout de milter, aumento de maildrop y actividad elevada de cleanup. Omitir temporalmente el milter (si está permitido) es una prueba rápida y confirmatoria.

10) ¿Debo borrar la cola para recuperarme más rápido?

Sólo si decides explícitamente pérdida de datos y tienes aprobación. Borrar colas puede violar políticas, perder correo de clientes y crear problemas legales. Hay palancas más seguras: throttling, detener entrada, arreglar dependencias.

Próximos pasos (la parte aburrida que previene el drama)

Si estás en medio de un incidente: deja de vaciar a ciegas, identifica el tipo de cola que está creciendo, ordena las razones de defer y verifica las tres grandes dependencias—almacenamiento, DNS y egress de red. Luego aplica un cambio controlado y mide la tendencia. Repite. Los incidentes terminan cuando la cola está decreciendo, no cuando alguien dice “ya debería estar bien”.

Después del incidente, haz el trabajo poco glamuroso:

• Pon monitorización de espacio e inodos del spool en dashboards con alertas.
• Monitorea la latencia y tasa de error de DNS desde el host de correo, no desde alguna sonda que siempre esté en camino feliz.
• Documenta y aplica valores por defecto sensatos de concurrencia, además de procedimientos de throttling por dominio.
• Separa rutas transaccionales vs masivas si el correo es importante para tu negocio (y lo es).
• Practica un vaciado controlado en ventana de mantenimiento para no improvisar a las 3 a.m.

Postfix es estable. Tu entorno puede no serlo. La cola es donde esa verdad se vuelve visible.