Diagnóstico y rescate de KumoMTA

¿Qué hizo la automatización del modelado de tráfico durante el incidente?

En un parque KumoMTA hay una pregunta de diagnóstico que no existe en motores más viejos, y va primero: ¿qué ha hecho ya la automatización del modelado de tráfico al respecto? Una cola que dejó de drenar a menudo no es ningún misterio: una regla coincidió con una respuesta del proveedor y suspendió esa ruta durante dos horas, o bajó en silencio su ritmo de mensajes, exactamente como se diseñó. Eso es el sistema funcionando; el incidente, si lo hay, está aguas arriba en lo que disparó la regla, o en una regla que sobrerreacciona —suspendiendo durante horas donde una reducción corta de ritmo habría mantenido el correo en movimiento—. Así que leemos el historial de automatización junto a las colas: qué reglas se dispararon, con qué frecuencia, sobre qué texto de respuesta, con qué acción y duración. A veces el hallazgo es que nada está roto y el movimiento correcto es dejar que la suspensión expire mientras se corrige la causa; a veces es una regla de fábrica que necesita afinarse a tu tráfico. En cualquier caso, diagnosticar un parque Kumo sin leer el diario de la TSA es adivinar decisiones que el motor ya escribió.

Los registros: donde todo queda escrito

La verdad de un incidente vive en los registros de entrega, no en las impresiones. KumoMTA registra cada intento como dato estructurado —el código y el texto de respuesta, el receptor, la cola, la fuente, los tiempos— en segmentos JSONL comprimidos hechos para procesarse en volumen; los registros de rechazo capturan incluso el comando que los disparó. Dos reglas prácticas mantienen honesta la lectura. La contabilidad sale de estos registros, no de las instantáneas de cola: los contadores en vivo se reinician cuando las colas listas se recolectan, así que solo el flujo de registros te da totales fiables. Y el registro de diagnóstico —lo que el propio demonio reporta a través del journal del sistema— tiene una verbosidad ajustable que puede subirse dinámicamente mientras investigas y debe bajarse después, porque los niveles más locuaces llenan un disco con velocidad impresionante. Un parque con registros bien mantenidos se diagnostica en horas; uno que deshabilitó o mató su registro te obliga a esperar a que el problema reaparezca antes de que nadie pueda verlo. Lo primero que pedimos, siempre: acceso de lectura a este material.

La caja de herramientas: respuestas en vivo de un motor en marcha

KumoMTA trae un cliente de línea de comandos que convierte «qué está pasando ahora mismo» en preguntas respondibles, y un incidente es cuando se gana el sueldo. El resumen de cola muestra, por sitio de destino y por fuente, qué entrega, qué está en tránsito y qué espera: la forma más rápida de ver si un problema es un proveedor, una IP o todo a la vez. Un resumen por proveedor agrega la misma imagen por receptor; una vista top en vivo la observa moverse. El filtro de registro puede subirse en el acto, sin reinicios, cuando el journal necesita decir más. Y dos verbos operativos importan en un rescate: el rebind, que mueve un flujo de mensajes en cola a una cola distinta con las reglas reevaluadas —invaluable cuando una ruta está envenenada y su correo necesita una vía más sana— y el bounce o transferencia administrativa del correo en cola cuando hay que drenar un nodo. Nada de esto requiere tocar la política; es observación y cirugía sobre un motor en marcha, que es justo lo que piden las primeras horas de un incidente.

# ¿Qué cola está atascada, y cuál es la última respuesta? (Q=en cola)
$ kcli queue-summary --by-site
SITE              D       T    C       Q   última-respuesta
yahoo.com       402      0    0   28140   421 4.7.0 [TSS04] deferred

# Antes de tocar el shaping: ¿la automatización ya suspendió esta ruta?
$ kcli tsa-status --domain yahoo.com
SUSPEND activo, 47m restantes · disparador: ráfaga 421 4.7.0 · auto-aplicado

# Lee los eventos reales, no adivines — últimos 5 diferimientos de la ruta
$ kcli tail-log --domain yahoo.com --type deferral --limit 5
421 4.7.0 [TSS04] Mensajes diferidos temporalmente por volumen

# Causa hallada: la automatización hace su trabajo. Déjala expirar, no rebind.

Observar el cable: rastrear conversaciones reales

Cuando los registros dicen qué pasó y necesitas verlo pasar, el motor puede mostrarte la conversación misma. El rastreo del lado del cliente transmite el diálogo SMTP saliente en tiempo real —el banner, el EHLO, el paso TLS, el momento y la redacción exactos del rechazo del receptor— filtrado a la cola lista o la fuente que te importa, porque en un servidor ocupado el rastreo sin filtro ahoga. El rastreo del lado del servidor hace lo mismo para las conexiones entrantes, lo que despacha rápido los problemas de inyección: la aplicación que dice que envía mientras el motor no ve nada, la autenticación que falla antes del primer byte de carga, el mensaje malformado que un generador produce bajo carga. Esta es la diferencia entre deducir un problema de handshake por sus escombros y verlo ocurrir; algunas clases de fallo —un receptor rechazando el saludo de una IP específica, TLS fallando contra un MX específico— son minutos con un rastreo y días sin él. Lo usamos con cirugía, con filtros, y te dejamos sabiendo cómo.

¿Diferimientos o rebotes duros: cuál estás viendo?

Dos cosas se confunden constantemente en una crisis, y tratarlas igual es un error con interés compuesto. Un diferimiento es «ahora no, vuelve luego»: el receptor está reteniendo tu correo, y con el ritmo correcto aterrizará. Un rebote duro es «esto no existe» o «nunca»: insistir solo gasta reputación. Cuando un incidente mezcla ambos —y las tormentas de rebotes suelen hacerlo— la primera tarea es separar, porque las respuestas que exigen son opuestas: paciencia y backoff para los diferimientos, supresión inmediata para los muertos. Un motor que reintenta rebotes duros como si fueran diferimientos se hunde solo; uno que descarta diferimientos como muertos pierde correo que estaba a minutos de aterrizar. La clasificación de rebotes de KumoMTA hace bien esta separación cuando está cableada para ello; parte de cada diagnóstico es verificar que la separación de verdad ocurre, y que la lista de supresión se alimenta de ella en vez de existir como un folclore paralelo.

¿Qué significa una respuesta 421 de Gmail?

La llamada más común es también la peor gestionada. Cuando Gmail devuelve su lenguaje de ritmo 421, está aplicando un freno temporal —reputación, ritmo o engagement— y pidiéndote que bajes la velocidad; no está construyendo un muro. Gmail ajusta dinámicamente cuánto acepta de cada remitente, y cruzar tu cupo actual produce exactamente este código. La trampa es tratarlo como un fallo duro y reintentar a toda velocidad, lo que amplifica la mismísima señal que disparó el freno. El movimiento correcto es el contrario: bajar el ritmo, dejar que la automatización sostenga la ruta —esto es justo aquello para lo que están escritas las reglas de shaping de la comunidad— y reconstruir la confianza, momento en que los 421 se desvanecen solos. Si el origen fue un calentamiento apresurado o un problema de lista, lo identificamos y lo corregimos. Este casi siempre se resuelve con paciencia y método, casi nunca con fuerza, y la corrección más rápida es con frecuencia detener la «corrección» ya en marcha.

Cuando Microsoft se cierra: el S3150

Pocos errores frustran como el S3150 de Microsoft, así que lo explicamos sin barniz. Llega como un 550 5.7.1 —formalmente un rechazo permanente— diciendo que parte de tu red está en su lista de bloqueo, apuntando a un portal que a veces no carga. La experiencia de operadores a lo largo de los años lo asocia con un bloqueo a nivel de IP de su filtrado, devuelto como permanente aunque la causa subyacente suele ser temporal: reputación o ritmo. Esa contradicción es el problema operativo: un código permanente para una condición no permanente genera rebotes, supresiones y direcciones marcadas como muertas que no lo están, así que el primer movimiento defensivo en KumoMTA es asegurar que tu manejo de rebotes no deje a una tormenta de S3150 envenenar la lista de supresión. La resolución corre por sus canales de delisting y, sobre todo, por corregir la causa de reputación, porque sin eso el bloqueo vuelve. Decimos desde el primer día qué parte del calendario es nuestra y cuál es de Redmond, porque no publican los umbrales y la honestidad le gana al teatro.

5xx repentino y masivo: un bloqueo en marcha

Cuando los rechazos permanentes se disparan de golpe contra un receptor, casi siempre es un bloqueo activo, y la reacción decide el desenlace. Esto no es la llovizna normal de direcciones muertas; es un muro que un proveedor acaba de levantar contra tu IP o dominio, por reputación o política. El instinto de seguir empujando es el peor disponible: cada intento confirma el razonamiento del bloqueo. Primero, detén la presión sobre esa ruta —suspéndela deliberadamente si la automatización no lo ha hecho ya— luego identifica exactamente qué IP o dominio está bloqueado y lee la razón que da el rechazo, que en KumoMTA está literal en los registros de rechazo. De ahí la vía es corregir la causa y usar el canal de delisting donde lo haya. Un 5xx masivo repentino es una de las pocas situaciones donde la velocidad de reacción —en el sentido de detenerse, nunca de empujar— de verdad cambia cómo termina la historia.

¿Cómo funciona de verdad el delisting de listas negras?

Cuando el problema es una lista de bloqueo, la honestidad es la única política útil. Aterrizar en una lista como la de Spamhaus, o en la lista interna de un receptor, frena la entrega en todos los frentes, y salir es posible, pero no por arte de magia: la mayoría de las listas exigen primero la causa corregida —una fuente comprometida, una lista sucia, un repunte de quejas— y algunas re-listan automáticamente si detectan que el problema persiste. El delisting serio es por tanto siempre dos pasos en orden estricto: reparar el origen, luego solicitar la retirada. Cubrimos la disciplina completa en la página de delisting de listas negras, pero dentro de un incidente el principio es idéntico: hacer delisting sin reparar compra tiempo, no una solución, y el tiempo que compra suele ser corto. Y conviene saber qué lista es cuál: las públicas como Spamhaus publican su criterio y su vía de retirada, mientras que las internas de Gmail o Microsoft no exponen ni umbral ni formulario, lo que cambia por completo el calendario realista de recuperación.

¿Por qué una cola de KumoMTA no drena?

Una cola que crece asusta a la gente hacia justo el movimiento equivocado: subir ritmos para «vaciarla». Una cola que no drena es una señal, nunca la enfermedad: algo aguas arriba frena la entrega, y en KumoMTA la lista de sospechosos es corta y comprobable. Una suspensión de automatización aún activa en esa ruta. Un techo de proveedor cruzado, con los diferimientos para probarlo. Una política de reintentos demasiado paciente o demasiado ansiosa para ese receptor. Un regulador compartido entre nodos haciendo su trabajo. O —el que la gente olvida— la cola programada rellenándose más rápido de lo que la cola lista puede legalmente drenar, que es un problema del lado de inyección disfrazado del lado de entrega. El resumen de cola los separa en minutos: los conteos por sitio y por fuente muestran si el coágulo es un proveedor, una IP o sistémico, y el historial de automatización dice si el propio motor está sosteniendo la puerta. Pisar el acelerador con el freno de mano puesto quema combustible y reputación; nosotros encontramos primero el freno de mano.

¿Por qué dejaría KumoMTA de aceptar correo?

Un incidente específicamente Kumo, alarmante la primera vez e instructivo después: los listeners dejan de aceptar mensajes nuevos, los inyectores ven rechazos, y el equipo concluye que el MTA se cayó. Normalmente no lo hizo: se protegió. Bajo presión real de memoria el motor encoge los cuerpos de mensaje de vuelta al spool, purga sus cachés, y a margen cero deja deliberadamente de aceptar trabajo nuevo hasta recuperarse; el health check dice unhealthy a propósito. La misma familia incluye la saturación de E/S del spool —una capa de almacenamiento que no da abasto convirtiendo un motor rápido en uno que se atasca— y la variante autoinfligida, un registro de diagnóstico dejado en su nivel más locuaz hasta que el disco se llenó. El diagnóstico corre por las métricas que el motor publica sobre su propia memoria y spool, y la corrección es de dimensionado aguas arriba: límites de cola lista casados con la distribución de tráfico, spool en almacenamiento que aguante las escrituras, verbosidad de registro devuelta a lo sensato. La protección comportándose no es el incidente; el dimensionado que la hizo necesaria sí.

Las correcciones que lo empeoran todo

Una buena parte del trabajo de incidentes es evitar que el pánico agrave el daño, así que detenemos la hemorragia antes que nada. Reintentar un 421 a toda velocidad le grita al receptor justo lo que le molestó. Martillear un 5xx permanente malgasta recursos y proclama descuido. Subir ritmos para drenar una cola añade presión sobre un receptor que ya te retiene. Deshabilitar la automatización porque «no para de suspender cosas» quita el sistema de seguridad a mitad de incidente —la versión específica de Kumo de cortar los frenos porque el coche no para de frenar—. Y cambiar muchas cosas a la vez vuelve la causa y el efecto permanentemente incognoscibles, lo que convierte un incidente de una semana en un misterio de un mes. La primera regla de un incidente es no ahondarlo; algunos de los minutos más valiosos que facturamos son los que pasamos deteniendo las correcciones ya en marcha.

Repuntes de quejas: la causa silenciosa

Detrás de muchas caídas repentinas de entrega se esconde un repunte de quejas que nadie vio llegar. Cuando demasiados destinatarios marcan tu correo como spam —tras una campaña a un segmento rancio, un cambio de nombre de remitente, contenido que la gente no esperaba— los receptores reaccionan rápido y sin ceremonia: los diferimientos suben, la colocación resbala, los bloqueos siguen. A diferencia de un rebote, una queja no siempre deja un rastro ruidoso en tus propios registros; hay que buscarla, en los bucles de retroalimentación y en correlación con lo que se envió y a quién. Así que cada incidente incluye la pregunta: ¿explica esto un repunte de quejas? Porque si lo hace, ningún ajuste de motor arregla nada: el problema es la audiencia o el mensaje, y el umbral de 0,30 % donde los receptores actúan no negocia con la configuración. Hallar esto pronto ahorra días de cazar el fallo en un motor que nunca tuvo la culpa.

La autenticación como causa oculta

A veces los diferimientos no van de ritmo o reputación en absoluto, sino de una autenticación que se rompió sin anunciarse. Un registro SPF que se coló más allá de su límite de consultas después de que alguien añadiera un proveedor; una clave DKIM rotada de un lado y no del otro; una alineación que dejó de aguantar en silencio tras una migración de DNS; cualquiera de estas se lee, desde fuera, como correo perdiendo colocación o recogiendo diferimientos raros sin un mensaje que diga «tu autenticación falló». En cualquier incidente de colocación sin causa obvia, revisamos la capa de autenticación como sospechoso permanente: firmas activas y alineadas para cada flujo, SPF dentro de sus límites, DMARC coherente con lo que de verdad se envía. Se esconde bien porque un parque que «siempre funcionó» puede romperse aquí por un cambio hecho en ningún lugar cerca del equipo de correo. Descartarla pronto evita cazar fantasmas en ficheros de shaping mientras el fallo real está sentado en un registro DNS.

Cuando el problema es el mensaje, no el motor

Hay incidentes donde la configuración es impecable, la reputación limpia, los rebotes sin nada notable, y la colocación cayó igual, porque el correo mismo cambió. Una plantilla rediseñada pesada de imágenes y enlaces, un asunto que divergió del cuerpo, un acortador de URL que recogió mala reputación, un dominio de tracking nuevo que los filtros nunca han visto: cualquiera de estos puede caminar un flujo que siempre aterrizaba directo a la carpeta de spam. Revisamos si la caída coincide con un cambio de contenido, comparando lo que entregó con lo que dejó de entregar —los registros datan el precipicio con precisión, lo que suele datar la causa—. No somos una agencia de copy, pero las señales técnicas que los filtros castigan son legibles, y parte del diagnóstico honesto es decir cuándo la corrección es editorial y no de infraestructura. Afinar el shaping contra un problema de contenido es ajustar tornillos que ya estaban apretados mientras el fallo viaja en cada mensaje.

Parque nuevo que nunca arrancó, veterano que se rompió de golpe

Dos historias de origen necesitan forenses distintos. Un despliegue fresco que ha entregado mal desde el primer día suele cargar un pecado original: una configuración de quickstart promovida a producción —el propio proyecto es explícito en que la instalación del tutorial no es de producción—, un calentamiento saltado, una autenticación nunca terminada, un puerto 25 saliente nunca abierto de verdad en el proveedor de nube, o IPs con un historial que nadie revisó. Ahí auditamos los cimientos uno a uno, porque un arranque torcido se endereza volviendo a la base, no enviando más. Un parque veterano que funcionó años y se rompió un martes es la investigación opuesta: algo cambió, aunque nadie lo admita, y KumoMTA le da a esta caza un regalo que ningún motor heredado ofrece, porque la configuración es código en control de versiones. El diff entre «funcionaba» y «roto» está con frecuencia sentado en el historial del repositorio con una marca de tiempo y un autor. Reconstruimos la línea de tiempo, la cruzamos con lo que dicen las respuestas, y el pequeño cambio reciente de gran efecto suele rendirse rápido.

¿Qué no promete el diagnóstico de KumoMTA?

Parte del diagnóstico honesto es nombrar lo que está fuera de alcance. No tenemos un botón que borre un bloqueo controlado por completo por un receptor que no publica criterios; tenemos el método para corregir la causa, los canales para solicitar la retirada, y la franqueza de decir cuánto del calendario no es nuestro. No reconstruimos una reputación arruinada en una tarde, porque las reputaciones se reconstruyen con comportamiento a lo largo de semanas, no con un cambio de configuración. Y no hacemos que un envío sucio entregue limpio: si la causa es una lista comprada o un consentimiento que nunca existió, ninguna reparación de motor ayuda, y lo diremos en vez de vender una ficción reconfortante. Preferimos prometer menos y cumplirlo que prometer un milagro y añadir decepción a tu incidente. Saber qué no se puede hacer es parte de hacer bien lo que sí.

Qué necesitamos de ti para empezar

Cuanto más rápido podamos leer, más rápido aparece la causa, y la lista es corta. Acceso de lectura a los registros de entrega, la política y las métricas: ahí vive la evidencia. Una línea de tiempo tal como la viviste: cuándo empezó, qué notaste primero, y sobre todo qué cambió en los días alrededor —una edición de DNS, una IP nueva, una campaña inusual, una actualización, un inyector nuevo—. Esas respuestas a «¿qué cambió?» suelen ser el hilo que desenreda el nudo entero, y con la política en control de versiones, «qué cambió» a menudo tiene una respuesta literal que podemos leer. Un puñado de mensajes de rechazo reales le gana a cualquier paráfrasis de ellos. Y la versión del motor más el fichero de política, que es el mismo checklist que el propio proyecto pide cuando un problema podría ser un fallo genuino —una petición que armamos dormidos—. Tú describes lo que ves; nosotros traducimos los códigos en una causa y un plan.

Cómo trabajamos un incidente

Deliberadamente metódicos, porque las manos apresuradas son las que rompen cosas. Primero estabilizamos: detener las correcciones que empeoran, suspender deliberadamente donde la presión hace daño, contener. Luego diagnosticamos sobre evidencia —registros, historial de automatización, estado de cola, reputación— hasta tener una causa, no una sospecha. Luego la corrección correcta, que a menudo es bajar el ritmo, esperar y ajustar en vez de empujar, aplicada un cambio a la vez y validada contra los números a medida que la entrega se recupera. Y por último el informe: qué pasó, por qué, qué se cambió, y qué evitará que vuelva, confirmado junto a la política, donde el próximo que responda de verdad lo encontrará. La cobertura abarca husos horarios europeos, norteamericanos y latinoamericanos, porque los incidentes de entrega no respetan el horario de oficina. La diferencia entre un incidente gestionado y uno sufrido es alguien con el contexto y la calma para leer la situación antes de actuar sobre ella.

El reloj, y el patrón detrás del fuego

En un incidente de entrega el tiempo es dinero literal —cada hora que el correo no aterriza es ingreso que no convierte, y cada día que un problema de reputación corre lo hace más caro de revertir, porque el daño se compone—. La velocidad de diagnóstico es por tanto la palanca que importa, y no viene de actuar rápido a ciegas; viene de saber dónde mirar y reconocer el patrón a la vista, que es lo que compra operar el mismo motor en producción. Pero la pregunta que ahorra dinero más allá de esta semana es por qué empezó el fuego. Muchos incidentes son síntomas: un calentamiento que producirá más 421, un diseño de pools que mezcla reputaciones, una regla de automatización que se desbordará otra vez, una lista agriándose en silencio. Cuando cerramos un incidente te decimos si fue un evento aislado o la punta visible de un patrón, y qué haría falta para no volver a encontrarnos. Esa lectura es lo que separa un parche de una corrección, y es con frecuencia el argumento para pasar de llamarnos cuando arde a tenernos vigilando para que no arda, con las causas de fondo manejadas como optimización en vez de emergencias.

Si estás en medio de un incidente, el primer paso es entender qué ocurre: la auditoría gratuita de 25 puntos da una lectura rápida de tu envío y tu KumoMTA y nos dice dónde mirar primero. Si el origen resulta vivir por completo fuera del motor, la auditoría de entregabilidad lo persigue donde vive. En cualquier caso: evidencia primero, luego acción, nunca al revés.