Saltar al contenido
OS Domains
MTA cara a cara

KumoMTA vs Postfix

KumoMTA y Postfix son ambos agentes de transferencia de correo gratuitos y de código abierto, así que la elección entre ellos es de encaje, no de coste. Postfix es el motor por defecto de propósito general del mundo del correo Unix — maneja entrante, saliente y relay con solvencia y corre casi en todas partes, configurado mediante archivos estáticos. KumoMTA está construido a propósito para saliente de alto volumen: escrito en Rust con la política en Lua, da el modelado de tráfico fino por destino que el envío masivo necesita, en la banda de volumen donde los controles más toscos de Postfix empiezan a tensarse. La mayoría de remitentes empieza en Postfix y se mueve a KumoMTA cuando el envío saliente a escala — más o menos pasado el medio millón de mensajes al día — se vuelve el trabajo, no porque ninguno cueste dinero.

Dos motores gratuitos y de código abierto — uno por defecto de propósito general, el otro construido para saliente a escala. La pregunta no es cuál es mejor, sino cuándo se te ha quedado pequeño el primero.

En resumen

  • Ambos son gratuitos y de código abierto, así que es una decisión de encaje: Postfix es de propósito general; KumoMTA está construido específicamente para saliente de alto volumen.
  • Postfix se configura mediante archivos estáticos (main.cf, master.cf); KumoMTA expresa el modelado y el enrutamiento como política en Lua que versionas como código.
  • La inflexión es el volumen: Postfix va cómodo hasta unos 500K/día; pasado eso, el control por destino de KumoMTA mantiene la reputación con más facilidad.
  • No es lo uno o lo otro — muchas configuraciones conservan Postfix para el correo general y ejecutan KumoMTA para el flujo saliente que necesita modelado.
  • El disparador honesto para cambiar: el trabajo saliente — diferimientos, regulación por ISP — empieza a comerte la semana en Postfix. Ahí es cuando KumoMTA rinde, no antes.
Ambos gratuitos — así que el coste no es la pregunta

La comparación honesta es propósito general frente a propósito específico

Casi todo remitente se topa primero con Postfix. Es el silencioso valor por defecto bajo una buena parte del correo de internet: gratis, fiable, documentado hasta la saciedad y capaz de manejar entrante, saliente y relay desde una sola configuración. Para la mayoría de lo que hacen la mayoría de servidores, es la respuesta correcta y no hay razón para mirar más allá. La comparación solo se vuelve interesante cuando el envío saliente crece hasta ser un trabajo en sí mismo.

KumoMTA se construyó justo para ese trabajo. No es un servidor de correo general — es un motor para empujar grandes volúmenes de correo saliente con el control por destino que protege la reputación a escala, escrito en Rust y configurado como política en Lua. Como ambos motores son gratuitos y de código abierto, elegir entre ellos nunca se reduce a una licencia. Se reduce a si tu envío se ha quedado grande para una herramienta de propósito general y necesita una moldeada para la tarea.

Ese reencuadre importa porque evita que la gente cambie por la razón equivocada. No te mueves de Postfix porque exista algo más nuevo; te mueves cuando sus controles salientes más toscos empiezan a costarte un tiempo que preferirías no gastar. Hasta entonces, quedarse es la decisión correcta — y lo decimos aunque hospedemos los dos.

Qué los separa de verdad

¿Cuál es la diferencia real?

La diferencia aparece en dos lugares: alcance y modelado. Postfix está diseñado para hacer muchos trabajos de correo de forma adecuada, lo que es una fortaleza cuando quieres una herramienta para todo y una limitación cuando uno de esos trabajos — el saliente de alto volumen — se queda grande para el resto. Sus controles por destino existen, pero son toscos al lado de un motor construido específicamente para entrega masiva. KumoMTA estrecha su alcance al saliente a propósito, y gasta ese foco en control fino: cómo marca el ritmo a cada proveedor, cómo se retira ante diferimientos, cómo aísla flujos.

La segunda diferencia es cómo se expresa ese control. Postfix lo pone en archivos de configuración estáticos — predecibles, fáciles de leer, iguales en cada ejecución. KumoMTA lo pone en política en Lua, así que una decisión de modelado o enrutamiento puede depender de la lógica que escribas y se puede revisar y versionar como cualquier otro código. Para un servidor de correo pequeño y estable el modelo estático es una virtud; para una operación de envío que cambia y crece, la política como código se gana el sueldo.

Configuración estática, ilustrada

Cómo modela cada uno el tráfico hacia un proveedor

Para marcar el ritmo del envío a un solo proveedor, Postfix usa ajustes estáticos por transport: declaras un límite de concurrencia y un retardo de tasa en la configuración, igual para cada mensaje de esa ruta. El fragmento de abajo muestra ese enfoque. KumoMTA alcanza el mismo resultado mediante política en Lua evaluada por mensaje, así que el ritmo puede adaptarse al contexto en lugar de quedar fijado en un archivo.

# Postfix main.cf — el ritmo por transport es estático
# (ilustrativo: una regla fija por clase de destino)

default_destination_concurrency_limit = 20
default_destination_rate_delay        = 1s

# un transport dedicado para un proveedor, afinado a mano
gmail_destination_concurrency_limit   = 10
gmail_destination_rate_delay          = 0s

# master.cf
# gmail   unix  -  -  n  -  -  smtp

Esto funciona, y para volumen moderado funciona bien. La tensión aparece a escala, cuando cada proveedor quiere un ritmo distinto que cambia con tu reputación y con su humor de ese día. Afinar eso editando archivos estáticos para decenas de destinos es el trabajo manual que el modelo de política de KumoMTA está diseñado para absorber — el mismo trabajo, expresado como lógica en lugar de como una lista creciente de entradas fijas.

Lado a lado

Postfix y KumoMTA en las dimensiones que deciden

Postfix KumoMTA
Licencia y coste Código abierto (IBM Public License), gratis Código abierto (Apache 2.0), gratis
Construido para Correo de propósito general: entrante, saliente, relay Envío saliente de alto volumen
Lenguaje C Núcleo en Rust, política en Lua
Configuración Archivos estáticos (main.cf / master.cf) Política como código, escrita en Lua
Modelado de tráfico saliente Tosco, por transport Fino, por destino y por política
Banda de volumen Hasta ~500K/día 500K–5M/día y escalando hacia arriba
Elígelo cuando Necesitas un MTA general fiable El saliente a escala es el trabajo de verdad
Dónde se curva el camino

El punto en el que Postfix cede el paso

Piénsalo como una sola carretera con una curva. Desde volumen bajo hasta aproximadamente medio millón de mensajes al día, Postfix te lleva cómodo y moverse sería esfuerzo desperdiciado. En torno a ese punto, el coste de mantener la reputación saliente a mano empieza a subir, y un motor construido para el trabajo — KumoMTA — te quita la carga. La curva es gradual, no un muro; el diagrama marca dónde la sienten la mayoría de remitentes.

volumen saliente al día → ~500K / día Postfix va cómodo propósito general · config estática · sin mover nada KumoMTA toma la carga para saliente · política Lua · 500K–5M+ / día

Quédate en Postfix cuando

Tu envío está cómodamente por debajo de unos cientos de miles de mensajes al día, tu configuración actual entrega, y valoras una herramienta bien entendida que lo hace todo. Postfix te pide menos para operar, su comportamiento es fácil de razonar, y la documentación responde casi cualquier pregunta que vayas a tener. Gastar esfuerzo en una migración aquí te mueve de lado.

El mejor uso de tu tiempo en esta etapa es la autenticación y la higiene de lista — SPF, DKIM y DMARC limpios, supresión de direcciones muertas —, que elevan la entregabilidad mucho más de lo que cambiar de motor lo haría.

Muévete a KumoMTA cuando

El envío saliente se ha vuelto un trabajo por derecho propio: el volumen sube pasado el medio millón, los diferimientos y la regulación por ISP te comen el tiempo, y quieres un modelado que puedas expresar como código en lugar de como un montón creciente de reglas estáticas. KumoMTA está construido para eso, y te lleva ahí sin licencia porque es código abierto como Postfix.

También puedes adoptarlo sin dejar atrás Postfix — conserva Postfix para el correo general y enruta el flujo saliente pesado a través de KumoMTA, aislando la parte que necesita el modelado.

La regla de una línea

Quédate en Postfix hasta que el modelado saliente a volumen empiece a costarte tiempo. Muévete a KumoMTA cuando lo haga — y considera ejecutar los dos en lugar de reemplazar uno.

Dónde encaja OS Domains

Ejecutamos los dos, y te diremos que te quedes cuando sea lo correcto

Como ninguno de los dos motores lleva licencia y operamos ambos como infraestructura gestionada, no ganamos nada empujándote a migrar. Un remitente de bajo volumen conserva un Postfix afinado y nuestro consejo honesto es dejarlo en paz; un remitente cuyo saliente se le ha quedado grande recibe KumoMTA en el flujo que lo necesita, a menudo junto al Postfix que sigue manejando todo lo demás. La recomendación sigue a tu volumen, no a una venta.

Lo que añadimos bajo cualquiera de las dos opciones es la parte difícil de montar por uno mismo: IPs dedicadas cuya reputación calentamos y gestionamos, e infraestructura residente en la UE bajo una entidad austriaca, de modo que la pata de envío no plantea ninguna cuestión de transferencia transfronteriza en tu revisión de cumplimiento. El motor es una elección gratuita entre dos buenas opciones de código abierto; la base dedicada, soberana y operada sobre la que corre es el diferenciador. Para ver cómo encaja esta pareja entre las demás, el hub de comparativas de MTA sitúa Postfix y KumoMTA junto a Exim, PowerMTA, Halon y MailerQ.

Las preguntas prácticas

KumoMTA vs Postfix: lo que preguntan los remitentes

¿Debería reemplazar Postfix por KumoMTA?

Solo si el envío saliente de alto volumen se ha vuelto el trabajo de verdad. Ambos motores son gratuitos y de código abierto, así que esto nunca es una decisión de coste — es de encaje. Postfix es de propósito general y maneja bien entrante, saliente y relay; KumoMTA está construido específicamente para saliente a escala, con el modelado por destino que el envío masivo necesita. Si tu envío es modesto y Postfix entrega, reemplazarlo no te aporta nada. Muchas configuraciones no lo reemplazan en absoluto y en su lugar ejecutan los dos, con KumoMTA llevando el flujo saliente.

¿A qué volumen deja de bastar Postfix?

No hay un precipicio claro, pero aproximadamente medio millón de mensajes al día es un marcador útil. La señal real no es el número — es cuándo los diferimientos por ISP, la regulación de conexiones y la gestión de reputación en el saliente empiezan a comerte el tiempo. El modelado de tráfico de Postfix es más tosco que el de un motor construido para envío masivo, así que por encima de esa banda gastas más esfuerzo manteniendo una reputación limpia a mano. KumoMTA mueve ese trabajo a una política que puedes expresar una vez y reutilizar.

¿KumoMTA es más difícil de operar que Postfix?

Es distinto más que estrictamente más difícil. Postfix se configura mediante archivos estáticos sencillos para empezar y ampliamente documentados, lo que es parte de por qué está en todas partes. KumoMTA expresa el modelado y el enrutamiento como Lua, que es más expresivo y tiene más que aprender, pero recompensa a los equipos que quieren su lógica de envío como código revisable y versionado. Para un servidor de correo general de bajo volumen, Postfix es menos que operar; para saliente de alto volumen, el modelo de KumoMTA hace más del trabajo por ti.

¿Puedo ejecutar Postfix y KumoMTA juntos?

Sí, y es una disposición habitual. Postfix sigue haciendo aquello en lo que es bueno — manejo de correo general, entrante, relay — mientras KumoMTA toma el flujo de envío saliente que necesita modelado cuidadoso a volumen. Tratarlos como complementarios en lugar de como un reemplazo suele ser el camino de menor riesgo: aíslas el envío de alto volumen en el motor específico sin perturbar el resto de tu configuración de correo.

¿Pasar a KumoMTA mejora la entregabilidad?

De forma indirecta, y solo por encima del umbral donde importa el modelado. Ningún motor fija tu llegada a la bandeja de entrada — eso lo hacen la reputación, la autenticación y la calidad de la lista. Lo que KumoMTA te da es control más fino para proteger esa reputación cuando envías a escala, de modo que los diferimientos se manejan por destino en lugar de de forma brusca. Por debajo de unos cientos de miles de mensajes al día, un Postfix bien configurado te da el mismo resultado, y la migración no compra nada.

¿Me configuráis cualquiera de los dos motores?

Sí. Ejecutamos Postfix y KumoMTA como infraestructura gestionada y recomendamos por volumen — un remitente de bajo volumen conserva un Postfix afinado, un remitente al que se le queda pequeño mueve el flujo saliente a KumoMTA. Las IPs dedicadas y la infraestructura residente en la UE de debajo son las mismas en cualquier caso, así que el consejo sigue a tu envío en lugar de a un producto que prefiriéramos colocar.

Decide con quien opera los dos

¿No tienes claro si ya se te ha quedado pequeño Postfix?

Dinos tu volumen saliente y dónde está el dolor. Te diremos si quedarte en Postfix, moverte a KumoMTA o ejecutar los dos — en infraestructura dedicada en la UE.

Teléfono +43 1 205 11 80 Lun–Vie · 9–18 CET
Email [email protected] Respuesta media 4h en horario laboral
Oficina Fleischmarkt 1, 1010 Wien Con cita previa