Cola de Postfix atascada: flujo seguro de limpieza (sin pérdida de datos)

Las reglas: no “limpiar”, recuperar

Cuando la gente dice “limpiar la cola de Postfix”, normalmente significa “hacer que el dolor desaparezca”. Así es como se eliminan correos, se generan rebotes masivos y su canal de incidentes se llena de capturas para legal.

Una cola atascada rara vez es un problema de cola. La cola es solo la pila visible de síntomas. La causa raíz casi siempre es una de estas:

• DNS lento o roto (las consultas expiran; las entregas se frenan).
• Salida de red bloqueada (reglas de firewall, enrutamiento, agotamiento de NAT).
• Los sitios remotos limitan o ralentizan (respuestas 421/450/451, greylisting, límites de tasa).
• Servicios de política locales caídos (milter, postscreen, rspamd, opendkim, demonio de políticas).
• Presión de disco o inodos (no se pueden crear/renombrar archivos de cola).
• Filtro de contenido lento (amavis, antivirus, DLP), causando retropresión.
• Configuración incorrecta (relayhost, políticas TLS, restricciones de remitente, SASL, transportes malos).
• Corrupción real de archivos de cola (más rara de lo que la gente piensa, pero real después de problemas de almacenamiento).

La postura segura es:

1. Congelar la escena lo suficiente para dejar de empeorar la situación.
2. Medir qué está atascado (qué cola, qué destino, qué error).
3. Arreglar la causa (DNS/red/servicio/almacenamiento).
4. Reproducir gradualmente (limitar, reencolar, vaciado dirigido).
5. Sólo entonces eliminar algo — y sólo con una razón documentada.

Una cita que mantengo pegada en la parte interior de mi cerebro: La esperanza no es una estrategia. — James Cameron. El trabajo de confiabilidad es lo que haces en lugar de esperar.

Broma corta #1: Las colas de Postfix son como montones de ropa sucia: ignorarlas no las hace más pequeñas, solo te deja con una ceguera creativa.

Guion de diagnóstico rápido (primero/segundo/tercero)

Primero: confirme qué significa “atascado” en su realidad

• ¿La cola active es enorme (se intenta enviar constantemente) o está todo en deferred (Postfix se rindió por ahora)?
• ¿Los mensajes de un remitente/dominio están atascados o es algo global?
• ¿Entran mensajes nuevos a la cola más rápido de lo que salen?

Segundo: aisle la clase de cuello de botella

• Latencia DNS: tiempos de espera largos del resolvedor en los registros, picos de carga del sistema, muchos “Host not found” que luego funcionan.
• Limitación remota: muchas respuestas 4xx, “intente más tarde”, “rate limited”, greylisting.
• Servicios locales: timeouts de milter, demonio de políticas sin responder, acumulación en el filtro de contenido.
• Almacenamiento: “No space left on device”, “File too large”, “too many files”, o directorios de cola lentos (alta iowait).
• Red: timeouts de connect(), “Network is unreachable”, fallos de handshake TLS por problemas de MITM/proxy.

Tercero: elija la palanca más segura

• Si la causa raíz no está resuelta, no vacíe todo. Amplificará la carga y hará los registros inútiles.
• Si un destino es venenoso (un dominio con timeouts), aislándolo con mapas de transporte o límites de concurrencia.
• Si su servidor se está “fundiendo” (carga, disco), reduzca la velocidad: disminuya la concurrencia, pause tráfico no esencial, proteja el host.

Datos e historia interesantes (porque explican las rarezas)

• Postfix fue diseñado como un reemplazo de Sendmail con enfoque en seguridad a finales de los 90, enfatizando el principio de menor privilegio y múltiples pequeños demonios en lugar de un monolito.
• La cola es basada en archivos por diseño. Eso es aburrido y excelente: los mensajes sobreviven reinicios de demonios e incluso algunos fallos parciales.
• “Deferred” no es un estado de error; es una decisión de planificación. Postfix retrocede intencionalmente para evitar martillar un destino roto.
• Postfix divide responsabilidades (pickup, cleanup, qmgr, smtp, local). Cuando uno de estos se atasca, la cola es su sistema de alerta temprana.
• Los ID de cola no son una decoración aleatoria. Son identificadores estables que puede usar para rastrear un mensaje en los registros y en operaciones de cola.
• El comportamiento de backoff es parte de ser un buen ciudadano de Internet. El ecosistema SMTP castiga a los reintentos agresivos con throttling y blocklisting.
• Históricamente, los sistemas de correo enseñaron a los equipos de operaciones sobre durabilidad antes de que el “event sourcing” fuera popular: aceptar, persistir, reintentar y sólo fallar con evidencia.
• Maildir vs mbox enseñó lecciones dolorosas sobre corrupción y bloqueo; el formato de cola de Postfix hereda esa mentalidad de “no apostar por un único archivo grande”.

Tareas en producción: comandos, significado de salidas y la siguiente decisión

Estos no son comandos de “ejecútelo y rece”. Cada tarea incluye qué buscar y qué decidir después. Ejecútelos como root o con los privilegios adecuados.

Tarea 1: Medir el tamaño de la cola (y qué cola)

cr0x@server:~$ postqueue -p | tail -n 20
-- 18451 Kbytes in 392 Requests.
A1B2C3D4E5*     1234 Fri Jan  3 10:41:22 sender@example.com
                                         (connect to mx.remote.tld[203.0.113.10]:25: Connection timed out)
                                         recipient@remote.tld
...

Qué significa: El resumen le indica tamaño total y número de solicitudes. La línea por mensaje muestra un error dominante: timeouts de conexión a un destino específico.

Decisión: Si ve uno o pocos destinos repitiéndose, haga una mitigación dirigida (limitación de transporte o aislamiento) en lugar de un vaciado global.

Tarea 2: Separar conteos de active vs deferred

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

Qué significa: Mayormente deferred. Postfix intentó y reculó. Eso suele apuntar a problemas remotos, DNS o timeouts de políticas — no a un bucle de envío local.

Decisión: Centre la atención en por qué las entregas están siendo aplazadas. No reinicie Postfix repetidamente; eso no hará que los MTAs remotos respondan más rápido.

Tarea 3: Comprobar si Postfix está sano como servicio

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 Fri 2026-01-03 10:12:01 UTC; 42min ago
   Main PID: 1123 (master)
      Tasks: 6 (limit: 4672)
     Memory: 34.2M
        CPU: 1min 12s

Qué significa: El proceso master está arriba. Esto no significa que el correo fluya, pero descarta “está muerto”.

Decisión: Si no está en ejecución, inícielo y luego inspeccione los registros inmediatamente para saber por qué se detuvo. Si está en ejecución, pase a las comprobaciones de cuello de botella.

Tarea 4: Encontrar la razón dominante de aplazamiento en los registros

cr0x@server:~$ journalctl -u postfix -S "1 hour ago" | egrep -i "deferred|timed out|refused|4[0-9][0-9]" | tail -n 20
Jan 03 10:43:10 server postfix/smtp[2451]: A1B2C3D4E5: to=, relay=mx.remote.tld[203.0.113.10]:25, delay=120, delays=0.1/0/120/0, dsn=4.4.1, status=deferred (connect to mx.remote.tld[203.0.113.10]:25: Connection timed out)
Jan 03 10:43:22 server postfix/smtp[2454]: F6E7D8C9B0: to=, relay=none, delay=4, delays=0.1/0.1/3.8/0, dsn=4.4.3, status=deferred (Host or domain name not found. Name service error for name=mx.other.tld type=MX: Host not found)

Qué significa: Tiene timeouts de conexión (red/remoto) y fallos de DNS (resolvedor/ruta). Eso es suficiente para elegir las dos siguientes sondas: DNS y red.

Decisión: Si los errores son mayormente 4.4.3 (DNS), repare el resolvedor primero. Si son sobre todo timeouts de conexión, verifique firewall/egreso y la alcanzabilidad remota.

Tarea 5: Comprobar latencia y corrección de resolución DNS

cr0x@server:~$ dig +tries=1 +time=2 mx remote.tld
;; ANSWER SECTION:
remote.tld.              300     IN      MX      10 mx.remote.tld.
;; Query time: 12 msec

Qué significa: DNS es rápido para este dominio al menos. Si ve 2000 msec y SERVFAIL/timeouts, esa es su cola “atascada”.

Decisión: Si DNS está lento, arregle resolvedores, cacheo o la ruta de red. No toque la cola aún; sólo generará más consultas fallidas.

Tarea 6: Verificar TCP/25 saliente y alcanzabilidad TLS

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

Qué significa: El SO no puede conectar. Eso no es Postfix. Es enrutamiento, firewall, agujero negro remoto o bloqueo del ISP en salida 25.

Decisión: Escale a red/firewall. Si la salida 25 está bloqueada por política, necesita un relayhost (submission/587) o un smart host aprobado.

Tarea 7: Inspeccionar concurrencia y controles de tasa de Postfix

cr0x@server:~$ postconf | egrep "default_destination_concurrency_limit|smtp_destination_concurrency_limit|qmgr_message_active_limit|default_process_limit"
default_destination_concurrency_limit = 20
default_process_limit = 100
qmgr_message_active_limit = 20000
smtp_destination_concurrency_limit = 20

Qué significa: Estos números dictan con qué fuerza golpea al mundo. Si vacía una cola grande con alta concurrencia, puede DDoSearse a sí mismo o ser bloqueado.

Decisión: Durante la recuperación, reduzca temporalmente la concurrencia (especialmente por destino) si está ocurriendo throttling remoto.

Tarea 8: Buscar timeouts de milter/política (el freno invisible)

cr0x@server:~$ journalctl -u postfix -S "1 hour ago" | egrep -i "milter|policy|timeout" | tail -n 20
Jan 03 10:31:07 server postfix/cleanup[1881]: warning: milter inet:127.0.0.1:8891: connect to Milter service: Connection refused
Jan 03 10:31:08 server postfix/smtpd[1876]: warning: problem talking to server 127.0.0.1:8891: Connection refused

Qué significa: Postfix está bloqueando la aceptación o el procesamiento porque un milter configurado no responde. El correo puede acumularse en incoming, active o hold según la configuración.

Decisión: Arregle el servicio milter (inícielo) o desactívelo temporalmente si la política lo permite. No borre correo en cola porque su filtro murió.

Tarea 9: Comprobar espacio en disco e inodos (la cola son archivos)

cr0x@server:~$ df -h /var/spool/postfix
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        20G   19G  600M  97% /
cr0x@server:~$ df -i /var/spool/postfix
Filesystem       Inodes  IUsed   IFree IUse% Mounted on
/dev/sda2       1310720 1299000  11720   100% /

Qué significa: Se ha quedado sin inodos. Eso es catastrófico para una cola basada en archivos: Postfix no puede crear archivos de cola aunque queden bytes libres.

Decisión: Libere inodos de forma segura (registros, cachés), amplíe el sistema de archivos o mueva el spool a un volumen más grande. No ejecute “scripts de limpieza” que rm aleatoriamente archivos de cola.

Tarea 10: Identificar destinos más problemáticos en deferred

cr0x@server:~$ postqueue -p | awk '/\(.+\)/{print}' | sed -E 's/.*\((.*)\).*/\1/' | cut -d: -f1 | sort | uniq -c | sort -nr | head
  812 connect to mx.remote.tld[203.0.113.10]
  503 Host or domain name not found. Name service error for name=mx.other.tld type=MX
  221 451 4.7.1 Try again later

Qué significa: Unos pocos modos de fallo dominan. Eso es buena noticia: arregle un número pequeño de causas y la cola se vacía de forma natural.

Decisión: Si un destino domina, aíslalo para evitar que monopolice los intentos de entrega y el volumen de registros.

Tarea 11: Inspeccionar un mensaje específico de forma segura

cr0x@server:~$ postcat -q A1B2C3D4E5 | sed -n '1,40p'
*** ENVELOPE RECORDS active ***
message_size:           1234             1234
message_arrival_time: Fri Jan  3 10:41:22 2026
sender: sender@example.com
recipient: recipient@remote.tld
*** MESSAGE CONTENTS active ***
Received: from app01.internal (app01.internal [10.0.0.12])
        by server with ESMTP id A1B2C3D4E5
        for ; Fri, 03 Jan 2026 10:41:22 +0000 (UTC)
Subject: Password reset

Qué significa: Puede verificar remitente/destinatario/encabezados sin adivinar. Así evita borrar “basura” que en realidad es crítica para el negocio.

Decisión: Si el correo es legítimo, lo conserva y arregla la entrega. Si es spam desde un host comprometido, primero detiene la fuente.

Tarea 12: Poner un mensaje en hold en lugar de eliminar

cr0x@server:~$ postsuper -h A1B2C3D4E5
postsuper: A1B2C3D4E5: placed on hold

Qué significa: El mensaje se retira de los intentos normales de entrega pero no se destruye. Esta es su palanca de “cuarentena”.

Decisión: Use hold para bucles sospechosos, mensajes envenenados que provocan fallos en filtros, o correos sensibles legalmente mientras investiga.

Tarea 13: Liberar correos en hold después de arreglar la causa raíz

cr0x@server:~$ postsuper -H A1B2C3D4E5
postsuper: A1B2C3D4E5: released from hold

Qué significa: El mensaje vuelve a ser elegible. Si el error subyacente está resuelto, se entregará en la siguiente ejecución de cola.

Decisión: Libere por lotes si retuvo muchos elementos. Observe la carga del sistema y las respuestas remotas.

Tarea 14: Forzar una ejecución controlada de la cola (no martillee)

cr0x@server:~$ postqueue -i A1B2C3D4E5

Qué significa: Esto pide a Postfix programar el ID de cola específico para un intento de entrega inmediato.

Decisión: Use esto para verificaciones quirúrgicas (“¿funcionó la corrección?”) en lugar de vaciar todo el backlog a la vez.

Tarea 15: Reencolar de forma segura (cuando cambió la configuración)

cr0x@server:~$ postsuper -r ALL
postsuper: Requeued: 392 messages

Qué significa: Postfix reescribe los archivos de cola a un estado nuevo para programarlos. Es útil después de cambiar mapas de transporte, relayhost o arreglar corrupción transitoria.

Decisión: Requeue es más seguro que borrar y reenviar. Aún así, hágalo sólo después de que la causa esté arreglada y haya limitado la concurrencia si es necesario.

Tarea 16: Verificar que no hay un stall del gestor de colas

cr0x@server:~$ ps -eo pid,comm,args | egrep "postfix/qmgr|postfix/master" | grep -v egrep
1123 master  /usr/lib/postfix/sbin/master -w
1388 qmgr    qmgr -l -t unix -u

Qué significa: qmgr existe. Si qmgr falta o está reiniciándose constantemente, la cola no se vaciará independientemente de la alcanzabilidad remota.

Decisión: Si falta, compruebe errores en master.cf y registros; arregle la configuración antes de tocar el contenido de la cola.

Flujo seguro de limpieza: paso a paso (sin pérdida de datos)

Paso 0: Decida qué significa “sin pérdida de datos” para su organización

La retención de correo es una política. Pero operativamente, “sin pérdida de datos” significa que no borra el correo en cola como primera respuesta. Conserva evidencia, preserva la entregabilidad y mantiene la capacidad de explicar lo ocurrido después.

Paso 1: Deje de empeorar la situación (sin detener el mundo)

Si la cola se dispara porque una app interna está volcando correo (bucle, error o host comprometido), debe frenar la entrada. Opciones, de menos a más disruptivas:

• Bloquee temporalmente el remitente ofensivo en el borde (restricciones smtpd).
• Limite la tasa o aplique tarpitting para una red cliente específica.
• Si está siendo inundado, rechace temporalmente con un 4xx las fuentes no esenciales para que los remitentes legítimos puedan reintentar.

Evite “postfix stop” como primera reacción. Pararlo puede estar bien, pero también detiene entregas legítimas y puede provocar que las apps reintenten creando más carga en otro lado.

Paso 2: Capture la situación (evidencia barata)

Antes de “arreglar”, capture algunos hechos rápidos para poder verificar la mejora y escribir un postmortem decente:

• Tamaño de la cola ahora y dentro de 15 minutos.
• Top 3 razones de aplazamiento.
• Top 3 destinos por volumen.
• Estado de disco/inodos.
• CPU/iowait y errores de red.

Esto no es burocracia. Es cómo evita perseguir fantasmas.

Paso 3: Arregle el cuello de botella, no la cola

Ejemplos de arreglos reales que realmente drenan colas:

• Reparar DNS: corregir resolv.conf, arreglar upstream roto, añadir resolvedor local con cache.
• Abrir TCP/25 saliente o configurar relayhost en 587 con autenticación.
• Reiniciar/arreglar milters y filtros de contenido; aumentar su capacidad si son el cuello de botella.
• Arreglar agotamiento de disco/inodos; mover el spool a un sistema de archivos dedicado si es necesario.
• Tratar el throttling remoto reduciendo concurrencia y respetando los 4xx de backoff.

Paso 4: Reproducir el correo de forma controlada

Una vez arreglada la causa, quiere un drenaje constante, no una estampida.

• Empiece entregando algunos IDs de cola conocidos (postqueue -i) para confirmar éxito.
• Reduzca la concurrencia por destino temporalmente si estaba siendo throttled.
• Use postsuper -r ALL si cambió transportes/relayhost y necesita reprogramar.
• Monitoree la profundidad de la cola y la tasa de aplazamientos mientras escala de vuelta.

Paso 5: Sólo elimine correo con una razón acotada y auditada

Borrar correo en cola a veces es correcto. Ejemplos:

• Flood de spam confirmado desde una cuenta comprometida que no debe entregarse.
• Un bucle de correo que puede demostrar que nunca tendrá éxito (expansión de direcciones que crea receptores infinitos).
• Carga maliciosa que no debe retransmitirse.

Cuando borre, hágalo de forma estrecha: por ID de cola, por remitente o por ventana temporal. Y lleve un registro.

Broma corta #2: Si alguien sugiere “simplemente borrar la cola”, pregunte qué extremidad quieren amputar para arreglar un esguince de tobillo.

Dónde se atascan las colas: cuellos de botella por subsistema

DNS: el asesino silencioso de colas

Cuando DNS está lento, Postfix no falla rápido. Espera, porque a veces DNS es inestable y reintentar ayuda. Eso significa que los procesos smtp pasan su tiempo bloqueados en consultas en lugar de entregar. Síntomas:

• Muchos aplazamientos con “Name service error” o “Host not found” que luego tienen éxito.
• Alta carga con bajo uso de CPU (procesos en espera de E/S / estados bloqueados).
• Consultas dig desde el host que se sienten lentas o inconsistentes.

Arregle DNS primero. Luego reprograme la cola con suavidad. Vaciar la cola con DNS roto solo crea una estampida de timeouts.

Egreso de red: el firewall que se comió su correo

El bloqueo de TCP/25 saliente es común en entornos corporativos y cloud. A veces es intencional. A veces una solicitud de cambio salió mal. Postfix puede encolar para siempre, pero a los usuarios no les importará que fuera “por diseño”.

Si no puede hacer entrega directa a MX, use un relayhost. La recuperación segura es configurar el relayhost, probar con un único ID de cola, luego reencolar y drenar.

Throttling remoto y greylisting: no está roto, es antipático

Los MTAs remotos envían respuestas 4xx por muchas razones: límites de tasa, reputación, recursos temporales, greylisting. Postfix trata esto como transitorio y aplaza.

No “solucione” el greylisting con reintentos a la fuerza. Respete el backoff, reduzca la concurrencia y asegúrese de que su IP y DNS inverso sean sanos. Su cola puede ser síntoma de reputación, no un problema de Postfix.

Milters y filtros de contenido: los middleboxes costosos

Los milters son geniales hasta que no lo son. Un milter caído puede bloquear la aceptación o ralentizar el procesamiento cleanup. Un escaneo AV lento puede convertirse en un problema de rendimiento global.

Operativamente: mantenga el camino de correo simple. Si debe ejecutar filtros, monitorice su latencia y modos de fallo. Trátenlos como dependencias, porque lo son.

Almacenamiento: la salud de la cola es la salud del almacenamiento

Postfix es una carga de trabajo de almacenamiento disfrazada de mensajería. Crea muchos archivos pequeños, los renombra, hace fsyncs y espera que eso sea barato. Si su disco está lleno, sin inodos o sufre picos de latencia, Postfix mostrará acumulación en la cola.

La corrupción de cola es poco común, pero ocurre después de pérdida abrupta de energía, bugs de sistemas de archivos o almacenamiento virtualizado roto. Cuando sucede, la respuesta segura es preservar el spool, reparar problemas de sistema de archivos y reencolar — no rm -rf en busca de silencio.

Tres micro-historias corporativas (errores que puede tomar prestados)

1) El incidente causado por una suposición equivocada

Una empresa mediana tenía un relay de correo que “nunca tocaba correos de usuario”, sólo notificaciones de aplicaciones. Esa frase se repitió tanto que se volvió folklore. Una mañana, la cola alcanzó decenas de miles de mensajes y el ingeniero de guardia hizo lo que el folklore sugería: borrar la cola deferred para “dejar pasar correo nuevo”.

Lo que asumieron: que el correo en cola era prescindible. Lo que no vieron: restablecimientos de contraseña, avisos de facturación y un montón de notificaciones legales provenían de esas aplicaciones. Algunos destinatarios eran reguladores externos. Esos sistemas no “simplemente reintentan” para siempre; algunos tenían flujos de trabajo de un solo disparo ligados a acciones de usuario.

Técnicamente, el problema real fue TCP/25 saliente bloqueado tras un cambio de firewall. Postfix se comportó correctamente: encolar y reintentar. Borrar la cola eliminó la única copia de esas notificaciones. No hubo reintento aguas arriba porque las apps ya habían hecho el handoff correctamente.

La recuperación fue fea y manual: re-disparar flujos donde fue posible, disculparse donde no, y auditar qué tipos de mensajes se perdieron. La corrección de la causa tardó diez minutos (restaurar la regla de firewall). El impacto duró semanas porque “borrar la cola” no es reversible.

La lección que quedó: trate a Postfix como un buffer durable. Una vez que una app ha entregado, la cola es el registro del sistema hasta que la entrega tenga éxito o usted deliberadamente reboté.

2) La optimización que rebotó

Otra organización operaba un relay saliente muy ocupado y quería mayor rendimiento. Alguien aumentó límites de concurrencia — globales y por destino — porque la cola se veía “muy lenta”. Funcionó durante aproximadamente un día. Luego los proveedores remotos empezaron a devolver más respuestas 421/451 y el greylisting se volvió constante.

Qué ocurrió bajo el capó: su relay empezó a parecer un remitente agresivo. Más conexiones paralelas, más entregas simultáneas y más intentos repetidos durante fallos transitorios. Algunos proveedores de buzones grandes tratan ese patrón como sospechoso o abusivo, independientemente del contenido.

La cola empeoró en vez de mejorar. Cada intento fallido generó más volumen de registros, más consultas DNS y más churn de sockets. El sistema pasó más tiempo fallando rápido que lo que habría pasado entregando más despacio.

Lo arreglaron revirtiendo la “optimización”, implementando límites sensatos por destino y añadiendo visibilidad: top de razones de aplazamiento, destinos principales y alertas basadas en tendencias. La clave fue aceptar que el rendimiento SMTP es una negociación, no una decisión unilateral.

La lección: no ajuste Postfix como si fuera un servidor web. El correo es un juego a largo plazo y los MTAs remotos tienen voto.

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

Una compañía de servicios financieros trató el relay de correo como infraestructura, no como proyecto particular. La configuración estaba gestionada, los cambios revisados y —lo más importante— el spool vivía en un sistema de archivos dedicado con monitorización de inodos y latencia.

Durante un incidente no relacionado, su volumen de registros se disparó y una aplicación separada empezó a generar archivos temporales masivos en el filesystem root. En muchos servidores esto llenaría el disco en silencio hasta que Postfix empezara a fallar. Aquí, el spool de correo tenía su propio margen y su propio pool de inodos.

La cola creció, pero no colapsó. Postfix siguió aceptando correo, persistiendo de forma segura y reintentando entregas. El de guardia vio alertas de inodos para el filesystem root pero no para el spool. Eso les dijo algo crítico: la durabilidad del correo estaba intacta; el cuello de botella era la capacidad de entrega, no la aceptación/persistencia.

Reducieron temporalmente la concurrencia saliente, arreglaron la aplicación ruidosa y dejaron que la cola se drenara en la siguiente hora. Sin pérdida de correo. Sin eliminaciones en pánico. Sin “notificaciones misteriosamente desaparecidas”.

La lección: un filesystem dedicado para el spool y monitorización de inodos es la póliza de seguro más aburrida que le alegrará haber comprado.

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

1) “mailq muestra miles de mensajes deferred”

Causa raíz: Throttling remoto, problemas DNS o bloqueo de red saliente.

Reparación: Identificar la razón principal de aplazamiento y el destino; reparar DNS/red; reducir concurrencia; reencolar y drenar. No reinicie Postfix como terapia.

2) “La cola nunca se vacía aunque el remoto sea alcanzable”

Causa raíz: qmgr no en ejecución, misconfiguración en master.cf o ruta cleanup/filtro de contenido atascada.

Reparación: Verificar procesos qmgr/master; inspeccionar registros por timeouts de cleanup/milter; restaurar dependencias; luego reprobar con un solo mensaje para validar.

3) “Después de arreglar el firewall, no pasó nada”

Causa raíz: Mensajes aplazados con temporizadores de backoff; Postfix no reintentará todo instantáneamente.

Reparación: Disparar reintentos controlados: postqueue -i para un ID de prueba; luego postsuper -r ALL si es necesario. Evite vaciados tipo estampida.

4) “Postfix rechaza correo nuevo con fallos temporales”

Causa raíz: Filtro de contenido/milter caído, o disco/inodos agotados, o demasiados procesos activos.

Reparación: Restaurar la dependencia, liberar inodos/espacio o ajustar límites de procesos. Use holds en lugar de borrados para elementos sospechosos.

5) “Faltan archivos de cola / IDs extraños / errores postsuper”

Causa raíz: Corrupción del sistema de archivos, eliminación manual o capa de almacenamiento rota.

Reparación: Detenga el impulso de ejecutar limpiezas aleatorias. Valide la salud del sistema de archivos, preserve el spool y use operaciones de requeue una vez el almacenamiento sea estable.

6) “Sólo un dominio está atascado; el resto funciona”

Causa raíz: El MX de ese dominio está caído, le limita la tasa o tiene un problema de enrutamiento hacia esa red.

Reparación: Aísle las entregas a ese dominio (baje la concurrencia); no permita que domine el gestor de colas. Comuníquese con ese dominio destinatario si es necesario.

7) “Los rebotes explotan; los usuarios reciben backscatter”

Causa raíz: Está generando informes de no entrega para remitentes falsificados o tratando fallos temporales como permanentes.

Reparación: Asegúrese de rechazar correo malicioso en tiempo SMTP cuando sea posible; evite devolver rebotes por spam aceptado de fuentes no autenticadas; revise políticas sobre 4xx vs 5xx.

Listas de comprobación / plan paso a paso

Lista A: Primeros 10 minutos (triage sin remordimientos)

1. Obtenga tamaño de la cola y error principal: postqueue -p, grep en registros por “deferred”.
2. Separe conteos de active vs deferred.
3. Compruebe disco e inodos para /var/spool/postfix.
4. Confirme que existen procesos Postfix (master/qmgr).
5. Compruebe velocidad DNS con dig para un dominio que falla.
6. Compruebe alcanzabilidad saliente con nc a un MX que falla.
7. Decida si la fuente de entrada está inundando (apps internas). Si sí, limite o bloquee temporalmente.

Lista B: Recuperación segura (arreglar + reproducir)

1. Arregle la causa raíz (DNS/red/filtro/almacenamiento).
2. Pruebe entrega con un único mensaje: postqueue -i QUEUEID.
3. Baje la concurrencia temporalmente si espera throttling.
4. Reencole si cambió programación/transporte: postsuper -r ALL.
5. Vigile profundidad de cola y tasa de errores por 15–30 minutos.
6. Libere mensajes en hold por lotes si puso en cuarentena alguno.
7. Sólo entonces considere borrar correos realmente no deseados, de forma acotada.

Lista C: Cuando debe borrar (controlado, auditable)

1. Pruebe que el correo es no deseado o dañino (inspeccione con postcat -q).
2. Detenga la fuente (cuenta/app comprometida) primero.
3. Prefiera hold sobre delete si hay incertidumbre.
4. Borre por ID de cola o remitente con referencia a ticket de incidente.
5. Registre qué borró y por qué. El usted del futuro hará preguntas.

Preguntas frecuentes

1) ¿Es seguro ejecutar postsuper -d ALL?

Es “seguro” en el mismo sentido que formatear un disco es seguro: hace lo que dice. No es un flujo de recuperación. Use holds, eliminaciones dirigidas y arregle la causa raíz primero.

2) ¿Debería reiniciar Postfix cuando la cola está atascada?

Reiniciar puede limpiar un proceso enquistado, pero rara vez arregla DNS, reglas de firewall o throttling remoto. Si reinicia, hágalo una vez con una razón y luego investigue registros inmediatamente.

3) ¿Por qué todo está en deferred incluso después de arreglar la red?

Los mensajes deferred obedecen temporizadores de backoff. Postfix no reintentará todo instantáneamente. Use postqueue -i para una comprobación puntual y considere postsuper -r ALL para reprogramar cuando esté seguro.

4) ¿Cuál es la diferencia entre “flush” y “requeue”?

Flush (una ejecución de cola) intenta entregar correo elegible. Requeue reescribe/reprograma el correo en la cola. Requeue es útil tras cambios de configuración; flush es lo que ocurre normalmente con el tiempo.

5) ¿Cómo evito que un dominio malo monopolice los intentos de entrega?

Reduzca la concurrencia por destino para ese dominio y considere mapas de transporte para enrutarlo de forma distinta. El objetivo es mantener el resto del correo fluyendo mientras ese dominio se recupera.

6) ¿Cómo sé si el problema de cola es almacenamiento local?

Compruebe df -h y df -i para el spool, y busque mensajes en los registros de Postfix sobre fallos de creación/rename de archivos. Alta iowait y agotamiento de inodos son señales clásicas.

7) ¿Puedo mover el spool de Postfix a otro filesystem?

Sí, y a menudo es una buena idea para durabilidad y rendimiento. Hágalo con cuidado: detenga Postfix, copie manteniendo permisos, actualice la configuración y verifique la integridad de la cola antes de arrancar.

8) ¿Cuál es la forma más segura de inspeccionar correo en cola por contenido sensible?

Use postcat -q QUEUEID y restrinja acceso a los directorios del spool. Trate el acceso al spool como acceso a una base de datos de producción: registrado, justificado y mínimo.

9) ¿Por qué hay montones de errores 4xx pero casi ningún 5xx?

4xx significa “temporal” y dispara reintentos. Muchos proveedores usan 4xx intencionalmente para controlar el comportamiento de los remitentes. Su trabajo es retroceder, no discutir con la física del SMTP.

Próximos pasos (qué hacer después de apagar el fuego)

Una vez que la cola se esté drenando y los usuarios dejen de mandarle capturas, no se aleje. Haga estos pasos prácticos mientras el dolor está fresco:

1. Añada monitorización de profundidad de cola y razones de aplazamiento (alertas por tendencia, no sólo por umbrales).
2. Monitorice inodos y latencia del spool, no sólo el porcentaje de disco.
3. Documente la regla “hold, no delete” y requiera una razón para acciones destructivas.
4. Establezca valores sensatos por defecto de concurrencia y límites por destino para su mezcla típica de correo.
5. Haga explícitas las dependencias: milters, resolvedores DNS, relayhosts. Si fallan, debe saberlo antes de que la cola sea su panel de control.
6. Ejecute un simulacro de recuperación: elija un escenario de backlog en staging y practique el flujo seguro para que producción no sea su entorno de entrenamiento.

La cola no es su enemiga. Es su archivo de evidencias y su amortiguador. Trátela como tal.