Instalación y configuración de KumoMTA

¿Por qué hay que abrir primero el puerto 25 saliente?

Un requisito merece resolverse primero porque sin él nada funciona: el puerto 25 saliente. Es el puerto que los servidores de correo usan para hablar entre sí —el transporte entre servidores—, mientras que la entrega desde un cliente corre por el 587 con autenticación. Las líneas residenciales suelen bloquearlo, y las grandes nubes no son más generosas: AWS bloquea el puerto 25 saliente por defecto en todas las instancias y exige el formulario «Request to remove email sending limitations», con un registro A y DNS inverso adjuntos, y una respuesta que suele tardar hasta un par de días. Otras nubes tienen barreras parecidas. La consecuencia directa para quien despliega un MTA: KumoMTA tiene que vivir en un centro de datos o una nube donde el puerto 25 saliente esté realmente abierto, con cada IP de envío portando un registro PTR que los receptores puedan verificar. Confirmarlo —y presentar la solicitud de desbloqueo pronto para que su plazo corra en paralelo con el resto de la preparación— es el paso uno de todo despliegue que hacemos, porque un motor que no puede salir por el puerto 25 sencillamente no entrega, por bien configurado que esté.

¿KumoMTA debe correr en bare metal, Docker o Kubernetes?

KumoMTA es inusualmente flexible respecto a su hogar. La ruta clásica es una instalación desde repositorio sobre un Linux soportado —Rocky y Ubuntu entre ellos—, que te deja un servicio systemd en una máquina que controlas de extremo a extremo. El proyecto también publica un contenedor oficial de Docker, y la arquitectura del motor encaja bien con Kubernetes para equipos que quieren que su MTA se despliegue, escale y ruede como el resto de su plataforma. El criterio de selección honesto no son los números de benchmark —un solo nodo bien configurado mueve millones de mensajes por hora en cualquiera de los tres— sino tu realidad operativa: lo que tu equipo pueda parchear, monitorizar y recuperar con confianza. Dos notas técnicas sí condicionan la elección. El spool quiere disco local rápido porque KumoMTA persiste los mensajes para durabilidad, así que un contenedor sin almacenamiento es una herida autoinfligida. Y el enlace de la IP de origen hay que diseñarlo a conciencia: en despliegues con contenedores y multinodo, el patrón limpio es poner las IPs de salida en un proxy que hable el protocolo HAProxy —o el propio compañero proxy de KumoMTA—, de modo que las direcciones, y la reputación atada a ellas, vivan independientes de cualquier nodo. Esta arquitectura la decidimos antes de instalar nada, porque rehacerla más tarde significa mover reputación, y la reputación se mueve mal.

¿Cómo se configura KumoMTA: init.lua y la pila de helpers?

El rasgo que define a KumoMTA es que su configuración es un programa: la política vive en Lua, ejecutada dentro del MTA, lo que da al motor condicionales, consultas contra datos en vivo y lógica que puedes versionar y revisar como cualquier otro código. Una política de producción no significa escribirlo todo a mano. El proyecto incluye una pila de helpers de política —módulos preconstruidos para shaping, gestión de colas, fuentes de salida, firma DKIM y dominios de escucha— que consumen ficheros TOML llanos, de modo que las perillas del día a día viven en ficheros de datos legibles mientras el pegamento Lua se mantiene pequeño y estable. Nuestro despliegue usa esa pila de helpers a conciencia: mantiene tu política cerca de lo que el proyecto documenta y prueba, hace las actualizaciones predecibles, y significa que quien la mantenga dentro de un año leerá TOML estructurado en vez de arqueología. Escribimos la política, la comentamos, la versionamos en tu repositorio y la validamos con la propia herramienta del proyecto —hay un validador de shaping en la línea de comandos precisamente para que una errata nunca llegue a producción—. La configuración como código es la característica que hace potente a KumoMTA; tratarla con disciplina de software es lo que la hace segura.

# Validar las reglas de shaping fuera de línea: una errata nunca llega a una cola viva
$ kumo-tsa-daemon --validate-shaping /opt/kumomta/etc/policy/shaping.toml
shaping.toml: 142 reglas analizadas · 0 errores · 0 avisos
resolve gmail.com → connection_limit=8 max_message_rate=180/min (comunidad + local)

# ¿Qué hace cada proveedor ahora mismo? (D=entregado T=tránsito C=conex Q=en cola)
$ kcli queue-summary
SITE                         D      T   C       Q
gmail.com                 4821    132   8       0
outlook.com               3940     61   5      14
yahoo.com                 2104     40   4       0

# Mover un flujo envenenado a una cola más sana, reglas reevaluadas
$ kcli rebind --domain outlook.com --reason "reset de reputación"
14 mensajes reubicados · reglas TSA reaplicadas

Fuentes de salida y pools: identidad por diseño

Lo que los operadores de PowerMTA conocen como VirtualMTAs vive en KumoMTA como fuentes de salida y pools: cada fuente es una identidad de envío —una IP con su nombre EHLO y su comportamiento— y los pools agrupan fuentes para que las clases de tráfico se enruten, regulen y reputen por separado. Acertar este diseño al principio es la mayor parte de lo que «escala limpio» significa después. El correo transaccional, que el destinatario espera y abre, no debe compartir IPs con el marketing masivo, cuyo perfil de quejas es distinto; una marca o un cliente importante puede merecer un pool aislado; y un flujo nuevo o de riesgo queda en cuarentena para que una incidencia no arrastre al resto. El helper de fuentes mapea atributos del mensaje —campaña, inquilino, clase de correo— al pool correcto, de modo que la segmentación la impone la política en vez de la costumbre. Y como las fuentes pueden enlazar a través de un proxy, el mismo diseño viaja de un nodo a un clúster sin renumerar nada. Dimensionamos el número de IPs contra tu volumen real —suficientes direcciones para que ninguna parezca agresiva, pocas para que cada una construya reputación reconocible— y documentamos qué flujo vive dónde y por qué.

Shaping por proveedor: las reglas de cada puerta

Cada gran proveedor de buzón tiene sus propias tolerancias —cuántas conexiones simultáneas, cuántos mensajes por conexión, qué ritmo por hora, cuándo TLS se tuerce— y enviarles a todos con una política genérica deja entrega sobre la mesa. KumoMTA expresa esas reglas en ficheros de shaping: valores por defecto globales sensatos, y luego entradas por dominio que afinan límites de conexión, ritmos de entrega y timeouts a lo que cada receptor tolera de verdad. Dos cosas hacen esta capa más fuerte que un throttling artesanal. El proyecto mantiene reglas de shaping aportadas por la comunidad para los grandes proveedores, destiladas por operadores con volumen real, que usamos como suelo y luego ajustamos a tu reputación y tu mezcla. Y el motor resuelve las reglas por destino con herramientas para inspeccionar exactamente qué política aplica a un dominio dado, de modo que «qué le estamos haciendo a este proveedor ahora mismo» tiene una respuesta comprobable en vez de una conjetura. El shaping no es una tabla de poner-y-olvidar —los límites respiran con tu reputación—, pero un despliegue que parte del suelo comunitario, afinado por proveedor, empieza educado. Educado es lo que la infraestructura nueva necesita ser.

¿Qué es la automatización del modelado de tráfico en KumoMTA?

La pieza que separa a KumoMTA de los motores de la generación anterior es la automatización del modelado de tráfico. Un demonio independiente observa las respuestas que recibe tu tráfico y ajusta el shaping automáticamente contra reglas que tú defines: cuando Gmail empieza a responder con su lenguaje de límite de ritmo en un umbral que fijas, la regla puede bajar el ritmo de mensajes de esa ruta durante treinta minutos; cuando un proveedor devuelve una firma de bloqueo, la regla puede suspender la cola dos horas en vez de martillear una puerta que se cierra. Las reglas comunitarias vienen con patrones para exactamente estas respuestas conocidas, y tus propias reglas las extienden. Esto es el backoff como un sistema de primera clase y observable: la automatización corre en su propio proceso para no competir nunca con la entrega, funciona a través de un clúster, y cada ajuste es política explícita en vez de un reflejo cableado. Configuramos esa automatización en cada despliegue —demonio, cableado de publicación/suscripción y reglas— porque es la diferencia entre un motor que reacciona al ceño de un proveedor en segundos y uno que espera a que un humano lea los registros por la mañana. La tormenta de diferimientos de las 3 de la mañana se gestiona a las 3 de la mañana; tú lees sobre ella a las 9.

¿Qué DNS y autenticación necesita KumoMTA antes de enviar?

Antes de que salga el primer mensaje, el DNS y la autenticación tienen que estar terminados, porque aquí se gana o se pierde la entrega frente a Gmail, Yahoo y Microsoft en 2026. Cada IP de envío necesita su registro PTR resolviendo a un nombre coherente con tu dominio de envío —una IP sin DNS inverso es una bandera roja inmediata—. El dominio publica un SPF que cubre las fuentes de envío sin reventar el límite de diez consultas, claves DKIM que el helper de firma de KumoMTA aplica por dominio en cada mensaje, y un registro DMARC que alinea por SPF o DKIM. La alineación es el detalle que tumba despliegues por lo demás correctos: no basta con que SPF y DKIM pasen, el dominio que pasa tiene que coincidir con el que el destinatario ve en el remite. Cerramos y verificamos esta capa antes de que empiece el calentamiento, incluidas las confirmaciones aburridas que se saltan: que el reenvío no rompa las firmas donde puedas evitarlo, que la política DMARC tenga un camino de la observación a la imposición, y que cada flujo que la política firma sea uno que de verdad envías. Un motor perfecto enviando correo que rebota por una autenticación a medio montar es el fallo más prevenible de este oficio.

¿Cuánto tarda el calentamiento de IPs en KumoMTA?

Las IPs nuevas no tienen reputación, y los proveedores desconfían de los desconocidos que aparecen con volumen, así que el despliegue incluye un plan de calentamiento escrito, nunca una idea de última hora. La mecánica es poco glamurosa y funciona: empezar con números diarios modestos por IP y por proveedor, multiplicar en escalones a lo largo de cuatro a ocho semanas, enviar primero a tus destinatarios más comprometidos para que las señales tempranas digan que este correo se quiere, y dejar que las respuestas de los proveedores gobiernen el ritmo en vez de un calendario rígido. KumoMTA da al calentamiento dos ventajas estructurales. El shaping expresa la rampa como límites explícitos por proveedor en vez de una disciplina del lado de campaña que alguien olvida bajo presión. Y la automatización actúa como barandilla de seguridad: si un escalón dispara diferimientos o un repunte de quejas, la automatización frena esa ruta de inmediato mientras el plan se detiene y se recupera. Saltarse o acelerar esta fase es la causa más común de que despliegues técnicamente perfectos entreguen mal sus primeros meses. Preferimos darte un arranque algo más lento y una reputación que aguanta —y ponemos ese trato por escrito el primer día, para que nadie se sorprenda de que la semana dos no sea volumen pleno—.

Rebotes, bucles de retroalimentación y monitorización desde el día uno

El envío sano se nota en cómo gestiona lo que vuelve, y esa maquinaria se configura antes de la primera campaña, no tras el primer susto. KumoMTA clasifica las respuestas con una taxonomía de rebotes rica; la cableamos para que los rebotes duros —direcciones que no existen— se supriman de inmediato y no se reintenten nunca, los fallos blandos reintenten con paciencia sensata, y los bloqueos por política se traten con los intervalos largos que merecen. Los bucles de retroalimentación de los proveedores que los ofrecen se registran para que los eventos de queja fluyan de vuelta automáticamente, y cada quejoso aterriza en la lista de supresión sin un humano en medio. Insistir en direcciones muertas o reacias está entre las formas más rápidas de enseñar a los proveedores que eres descuidado; un despliegue que suprime sin piedad desde el día uno se lee como un remitente serio desde su primera semana. La lista de supresión es también donde el cumplimiento se vuelve concreto: bajas honradas dentro de los plazos que exigen las reglas de remitentes masivos, y la línea de 0,30 % de quejas —el umbral en que los proveedores actúan sin importar tu autenticación— mantenida a distancia respetuosa por disciplina de lista en vez de por suerte.

Registros, contabilidad y webhooks fuera de banda

Todo lo que el motor hace deja rastro, y el registro de KumoMTA está hecho para los volúmenes donde los rastros se vuelven caros: registros estructurados escritos como segmentos JSONL comprimidos, con los campos, la rotación y la retención bajo tu control. Versiones recientes añadieron un módulo para leer y escribir esos segmentos directamente, lo que desbloquea un patrón de despliegue que nos gusta mucho para operaciones serias: el procesamiento de webhooks y analítica corriendo fuera de banda, como un proceso aparte y longevo con su propio checkpointing, sus reintentos y sus modos de fallo, en vez de cabalgar dentro de la ruta caliente del MTA. Tu plataforma se entera casi en tiempo real de qué se entregó, difirió y rebotó, sin que el transporte de registros pueda nunca frenar la entrega. Diseñamos esta capa en el despliegue: qué eventos se registran con qué detalle, cuánto se retienen los segmentos antes de borrarse o anonimizarse conforme a la ley de privacidad que te aplica, y cómo llegan los datos a tus paneles. Un motor sin visibilidad acaba sorprendiéndote; este está hecho para vigilarse, y lo dejamos vigilable.

Integración: SMTP, API HTTP y tu stack

KumoMTA es la capa de infraestructura, y se encuentra con tu aplicación donde ya está. La ruta clásica es la inyección SMTP desde tu capa de campaña o aplicación, aceptada en un listener que controlas y enrutada por política. Junto a ella hay una API de inyección HTTP nativa para sistemas que prefieren hablar JSON a un endpoint en vez de mantener un cliente SMTP, lo que también hace el motor agradable de usar desde productores serverless y dirigidos por colas. De salida, el flujo de eventos alimenta webhooks para el estado de entrega, y el motor se conecta con el ecosistema que una plataforma moderna espera —colas de mensajes como AMQP y Kafka para el transporte de eventos, métricas Prometheus con paneles Grafana para la operación, secretos guardados en un vault en vez de en ficheros de configuración, y consultas directas a datos desde la política cuando las decisiones de enrutado necesitan respuestas en vivo—. Diseñamos las rutas de inyección y de eventos de forma explícita: qué entra dónde, autenticado cómo, y qué eventos consumen tus sistemas. Bien hecho, el MTA deja de ser una caja negra al borde del diagrama y se vuelve una pieza ordinaria y observable de tu plataforma.

Seguridad: control de acceso, disciplina de relay y TLS

Un motor de envío es un blanco atractivo, y KumoMTA da a un despliegue primitivas modernas para cerrarlo —versiones recientes añadieron un marco completo de autenticación, autorización y contabilidad, con control granular y un rastro de auditoría sobre cada interacción con las APIs del motor—. Lo usamos. Los listeners de inyección aceptan correo solo de fuentes autenticadas y enumeradas, de modo que el clásico desastre del relay abierto queda estructuralmente fuera de la mesa; la API HTTP y los endpoints de métricas responden solo a redes de confianza; se exige TLS donde se mueven correo y credenciales; y las claves privadas DKIM viven con los permisos de fichero y la disciplina de rotación de cualquier secreto de producción. Alrededor del motor aplica el endurecimiento habitual —servicios mínimos, cortafuegos, sistema operativo parcheado— y el rastro de auditoría significa que «quién tocó qué» tiene respuesta. Un MTA comprometido o permisivo no solo te avergüenza; gasta la reputación de tu IP en el spam de otro y te mete en listas de bloqueo en horas. Esta capa rara vez sale en la demo, que es justo por qué nos negamos a tratarla como opcional.

Retención de datos y la ley que te aplica

Los registros de entrega son datos personales con un reloj encima. Las anotaciones de contabilidad llevan direcciones de destinatario y comportamiento, lo que hace de la retención una decisión legal de diseño, no de espacio en disco: bajo la legislación de protección de datos que te corresponda —el RGPD en Europa, sus equivalentes en Latinoamérica— guardas lo que necesitas durante lo que puedas justificar, y luego borras o anonimizas en plazo. El despliegue fija esto desde el principio: qué campos se registran, cómo rotan los segmentos para que el detalle nunca llene el disco, y una política de retención escrita que la rotación de verdad impone. La misma previsión cubre el consentimiento: construimos infraestructura de envío solo para programas basados en permiso, con listas de supresión que hacen que las bajas se peguen, porque ninguna configuración de motor rescata a un remitente que escribe a quien nunca lo pidió. Si tu mercado añade reglas propias —ventanas de baja en un clic, regulaciones sectoriales, códigos regionales— la política las codifica en vez de confiar en que alguien las recuerde. El cumplimiento diseñado de entrada es barato; el cumplimiento añadido bajo presión de quejas no lo es.

Escalado y alta disponibilidad

Un solo nodo bien construido carga un volumen enorme, pero el crecimiento y la tolerancia a fallos se diseñan, no se improvisan. KumoMTA hace clúster con limpieza: varios nodos kumod reparten el tráfico, el demonio de automatización del shaping puede correr como su propio subclúster pequeño para que el tráfico de registros no se entrelace por cada nodo, el estado compartido como los reguladores puede vivir en Redis, y las IPs de salida enlazadas por un proxy sobreviven al fallo de cualquier nodo con su reputación intacta en vez de congelada en una máquina muerta. El patrón que desplegamos mantiene la configuración de cada nodo idéntica —misma política, mismo shaping, selección de fuente por pool—, de modo que añadir capacidad es aprovisionar, no operar. Aunque empieces en un solo servidor, dejamos estas costuras puestas: el proxy delante de las IPs, la política en control de versiones, el cableado de la automatización listo para clúster. La versión cara del escalado es aquella en que la reputación tiene que moverse; la barata es aquella en que la arquitectura ya tenía sitio. El día uno es cuando esa elección cuesta menos.

¿KumoMTA trae un panel de control?

KumoMTA no incluye una interfaz web, y es una postura de diseño deliberada: el proyecto trata la configuración como código y la operación como APIs, métricas y herramientas, no a clics. Para muchos equipos de ingeniería eso es justo lo correcto. Para operaciones que quieren una capa visual —colas de un vistazo, estado de entrega por proveedor, una interfaz que un no operador pueda leer— construimos un panel de control sobre KumoMTA sin comprometer el modelo de código primero que hay debajo: el panel observa e instruye a través de las mismas APIs que usa tu automatización, así que nunca hay una segunda fuente de verdad. Durante el despliegue montamos la base operativa de todos modos —paneles, alertas sobre diferimientos, rechazos y señales de trampa de spam, visibilidad de colas—, porque un panel es opcional pero la observabilidad no.

¿Debería ser siquiera KumoMTA?

La pregunta honesta antes de desplegar es si KumoMTA es el motor adecuado para ti, y nuestra respuesta puede ser no. Su punto dulce es volumen saliente real con necesidad de control fino por proveedor y por IP, infraestructura propia, y un equipo —tuyo o nuestro— que trate al MTA como un sistema de producción. Para volúmenes modestos, un MTA convencional bien afinado o un relay en la nube cubre el caso con menos superficie que operar. Si ya corres PowerMTA a gusto bajo licencia, el cambio es un cálculo, no un reflejo —exponemos esa cuenta en la página de migración y estamos igual de cómodos con cualquiera de los dos resultados—. Y cuando el campo está de verdad abierto —KumoMTA, PowerMTA, Halon, MailerQ— lo tratamos como un ejercicio de selección de MTA con tu interés por delante, porque no revendemos ninguno. El despliegue más barato es el que no necesitabas; preferimos decírtelo a construirlo.

Qué aspecto tiene «terminado»

Un despliegue está terminado cuando se sostiene solo y se entiende sin nosotros. En concreto: las IPs calientan según un plan escrito a buen ritmo; el DNS y la autenticación pasan y alinean para cada flujo; las fuentes y los pools separan el correo por naturaleza, con shaping por proveedor que parte del suelo comunitario y se afina al tuyo; la automatización reacciona al empuje de los proveedores de forma automática y visible; los rebotes se procesan, las direcciones muertas se suprimen solas, los bucles de retroalimentación están cableados; los registros fluyen a tus paneles con la retención impuesta; el control de acceso y TLS están activos, con rastro de auditoría tras las APIs. Y todo está documentado —cómo está construido, por qué se tomó cada decisión, qué tocar cuando algo cambia— con la política en control de versiones. Un despliegue que solo funciona mientras su constructor esté localizable no está terminado; es un traspaso que aún no ha ocurrido. Damos el proyecto por cerrado cuando tu equipo, o nuestro servicio gestionado, puede operarlo sin folclore.

¿Cómo se desarrolla un despliegue de KumoMTA, paso a paso?

Empezamos con la auditoría gratuita de 25 puntos, que confirma que el motor encaja y fija el estado de partida del DNS, las IPs y la autenticación. De ahí, el trabajo sigue el orden que esta página describe: confirmar el puerto 25 saliente y presentar pronto el desbloqueo de la nube; preparar y endurecer el host —o la plataforma de contenedores— y decidir la arquitectura de enlace de IPs; cerrar DNS, autenticación y alineación; instalar desde repositorio o contenedor y asentar la política con la pila de helpers; diseñar fuentes, pools y shaping por proveedor desde el suelo comunitario; cablear la automatización del modelado de tráfico y validar cada fichero de shaping con la herramienta del proyecto; conectar el procesamiento de rebotes, los bucles de retroalimentación, la supresión y la monitorización; escribir el plan de calentamiento; y luego arrancar la rampa bajo vigilancia diaria. La preparación y la configuración suelen llevar días o un par de semanas según tu entorno, con el plazo del puerto 25 corriendo en paralelo; el calentamiento añade después cuatro a ocho semanas hasta el volumen objetivo con una reputación que aguanta. Al cierre, recibes la instalación documentada para que la opere tu equipo, o seguimos operándola como KumoMTA gestionado. La infraestructura es tuya en todo momento, y la relación factura por trabajo, sin un motor que vender al otro lado de la mesa.

Si estás planificando un despliegue de KumoMTA —primer MTA, capacidad nueva o la reconstrucción de algo que nunca acabó de funcionar—, el punto de partida no cuesta nada: la auditoría de 25 puntos confirma el encaje y el estado de tu DNS, tus IPs y tu autenticación antes de construir nada. De ahí, lo desplegamos como operamos el nuestro: modelado, calentado, vigilado y por escrito.