Operación B2B que creció durante años sobre Postfix con master.cf modificado, transport maps custom, header_checks elaborados, milters en C o Python, scripts de bounce processing que alimentan sistemas downstream. Funciona, pero el scale-up acumula complejidad inmanejable: el equipo que escribió el scripting ya no está, runbooks operacionales no existen, observabilidad es grep en logs. El upgrade a PowerMTA o KumoMTA recupera la paridad funcional con observabilidad nativa, runbooks, multi-IP rotation gestionada y queue persistente robusto. Sin lock-in entre PowerMTA y KumoMTA: la decisión se basa en variables reales del cliente, no comerciales para EMP.
Postfix funciona excelentemente para muchas operaciones. Migrar tiene sentido cuando aparecen estos cuatro signals combinados, no por moda de stack moderno. Si tu Postfix actual cubre la operación y el equipo lo opera bien, mantenerlo es la respuesta correcta.
Postfix maneja volumen alto técnicamente, pero el throttling por destination, retry backoff exponencial, multi-IP rotation requieren scripts custom que se vuelven frágiles. PowerMTA y KumoMTA tienen estas capacidades nativas con configuración declarativa.
Postfix entrega logs detallados pero sin métricas exportables nativas. Cuando el head of MailOps quiere dashboards Prometheus/Grafana de queue depth, throughput por destination, bounce rate por categoría, las opciones son scripts de parseo logs frágiles. KumoMTA exporta métricas nativas; PowerMTA tiene VMTA stats.
El master.cf con 40 modificaciones, los transport maps con regex complejos, los milters custom en Python sin documentación: cuando el SRE original se va, el conocimiento operacional se pierde. La migración a MTA enterprise traduce el scripting a configuración declarativa documentada que sobrevive cambios de equipo.
Queue stuck en 3am, bounce flood masivo, IP en blocklist súbita, complaint rate disparado: los incidentes operacionales requieren runbooks documentados. Postfix tiene documentación general, pero la documentación específica del setup custom del cliente no existe. PowerMTA y KumoMTA tienen runbooks community + custom específicos del cliente entregados con el setup.
Cuatro escenarios donde mantener Postfix es lo correcto y EMP lo dice honestamente: volumen bajo 500K/mes sin proyección de crecimiento donde el overhead de KumoMTA o el costo de licencia PowerMTA no se justifica; operación email corporativo (no marketing/transactional masivo) donde Postfix es el estándar de la industria; equipo SRE con expertise profundo en Postfix y configuración bien documentada que opera la stack sin fricción; requirement regulatorio específico que exige stack abierto auditable donde Postfix tiene historial validado vs MTAs enterprise. EMP no fuerza migraciones que no aportan valor real. Si después del discovery la conclusión es que Postfix sigue siendo correcto, cobramos solo el discovery ($2,200) sin proyecto de migración.
Tabla de los 9 elementos típicos de un Postfix legacy y su equivalente funcional en PowerMTA y KumoMTA. Esta tabla es el output del discovery: identifica qué requiere traducción simple, qué requiere trabajo manual, qué requiere reverse-engineering. KumoMTA tiende a ser más simple porque la mayoría de elementos se traducen a Lua scripts unificados; PowerMTA requiere más archivos de configuración separados.
| Elemento Postfix | Función original | PowerMTA equivalente | KumoMTA equivalente |
|---|---|---|---|
| main.cf | Configuración global del MTA | config.txt sección global | init.lua kumo.set_config() |
| master.cf | Definición de services y daemons | config.txt sección spool/listener | init.lua kumo.start_smtp_listener() |
| transport maps | Routing por destination domain | domain {} blocks en config.txt | queue.lua get_queue_config() |
| header_checks | Regex filtering/rewriting de headers | filter scripts en archivos .acl | smtp_server.lua msg_received callback |
| body_checks | Regex sobre body del mensaje | filter scripts (limitado, no recomendado) | smtp_server.lua msg_received con kumo.message API |
| milters externos | Procesos externos via libmilter protocol | Soporta libmilter via filter | Callbacks Lua nativos o subprocess |
| aliases | Local user aliasing | aliases {} block | No aplica (KumoMTA es outbound puro) |
| scripts bounce processing | Parseo de DSN para downstream | bounce_after y feedback_loop options | bounce.lua disposition callback |
| queue lifetime / retry | maximal_queue_lifetime, retry_template | retry-after, max-retries en config | queue.lua retry_interval array |
Lo que el discovery siempre encuentra: scripts custom del cliente que no encajan en ninguna fila estándar de la tabla. Ejemplos típicos vistos: re-stamping de Subject según patrón de destination (banking con compliance), inserción de headers custom para tracking interno, queue routing dinámico basado en lookup contra base de datos externa, bounce processing que invoca webhooks downstream. Estos requieren scripting custom en la plataforma destino. KumoMTA con Lua es típicamente más fácil para estos casos porque permite scripting unificado en un solo lenguaje; PowerMTA requiere combinar config.txt declarativo con filters externos en C o Python.
Fragmento real anonimizado: cliente B2B Panamá con retry policy customizado en Postfix master.cf que define backoff exponencial diferente para Gmail vs Microsoft vs Yahoo. La traducción a KumoMTA aplica Lua nativo; a PowerMTA requeriría config.txt domain blocks separados (no mostrado).
# --- main.cf snippet --- smtp_destination_concurrency_limit = 10 smtp_destination_rate_delay = 0s smtp_destination_recipient_limit = 20 # --- master.cf: services por destination --- gmail-out unix - - n - 5 smtp -o smtp_destination_concurrency_limit=8 -o smtp_destination_rate_delay=100ms -o smtp_helo_name=mta.dominio.com ms-out unix - - n - 5 smtp -o smtp_destination_concurrency_limit=5 -o smtp_destination_rate_delay=200ms yahoo-out unix - - n - 3 smtp -o smtp_destination_concurrency_limit=3 -o smtp_destination_rate_delay=500ms # --- transport map: routing por dest --- gmail.com gmail-out: googlemail.com gmail-out: outlook.com ms-out: hotmail.com ms-out: yahoo.com yahoo-out: aol.com yahoo-out:
-- queue.lua: routing + throttle unified local kumo = require('kumo') local dest_profiles = { ['gmail.com'] = 'gmail-out', ['googlemail.com'] = 'gmail-out', ['outlook.com'] = 'ms-out', ['hotmail.com'] = 'ms-out', ['yahoo.com'] = 'yahoo-out', ['aol.com'] = 'yahoo-out', } local profile_config = { ['gmail-out'] = { max_connections=8, ratelimit='10/s' }, ['ms-out'] = { max_connections=5, ratelimit='5/s' }, ['yahoo-out'] = { max_connections=3, ratelimit='2/s' }, } kumo.on('get_queue_config', function(domain, tenant) local profile = dest_profiles[domain] or 'default' return kumo.make_queue_config(profile_config[profile]) end)
Diferencia clave en mantenimiento: el Postfix requiere coordinación entre master.cf y transport map (dos archivos), reload con postfix reload que no es hot. El KumoMTA tiene todo en un solo Lua, reload hot vía kumo.reload(). Para incidentes nocturnos (queue stuck, throttle ajustment urgente) la diferencia es relevante: hot reload en KumoMTA permite cambio sin afectar mensajes en flight. El objetivo de la traducción no es código más corto sino mantenibilidad por equipos futuros.
El timeline de cutover muestra cómo se ejecuta la migración sin perder mensajes en flight. Las cinco etapas operan en paralelo y secuencial según corresponde. El drainage del Postfix toma 2-4 horas durante las cuales el queue se vacía naturalmente antes de la migración de los mensajes que quedan.
Single Server · ventana de mantenimiento ampliada con coexistencia paralela
El drainage de 4 horas (T+16h a T+20h) es la fase más crítica. Durante ese período el Postfix no acepta mensajes nuevos pero sigue entregando los que tiene en queue. Los mensajes nuevos van directo al MTA nuevo. Después de las 4 horas, los mensajes que siguen en queue del Postfix son los que tuvieron deferred (receiver temporariamente no aceptó) o están en retry pendiente. Esos se migran al queue del MTA nuevo con un exporter custom que respeta el retry_counter y next_retry_time, manteniendo el comportamiento de retry sin reseteo. Después del cutover formal el Postfix queda en standby 14-30 días con plan de rollback ejecutable en 2-4 horas si necesario. La inversión en el plan de rollback es la diferencia entre migración managed y migración ad-hoc.
Análisis main.cf, master.cf, transport maps, milters. Inventario de scripts custom. Decisión PowerMTA vs KumoMTA basada en variables del cliente.
Setup MTA nuevo en paralelo. Traducción de configuración. Adaptación de scripts custom a Lua o filters. Integración con monitoreo.
Testing exhaustivo con muestras representativas. Comparación byte-by-byte de output. Cliente firma off el documento de paridad antes del cutover.
Ejecución del cutover según plan gantt. Drainage del Postfix, migración del queue residual, switch de tráfico, validación post-cutover.
14-30 días post-cutover con Postfix en standby para rollback. Monitoreo de KPIs. Runbooks entregados. Capacitación equipo cliente. Decommission Postfix.
El discovery es contratable por separado. Si después del discovery la conclusión es "tu Postfix sigue siendo correcto", cobramos solo el discovery sin proyecto. Si avanza el proyecto, el costo del discovery se descuenta del primer servicio dentro de 90 días.
Standalone · 5-7 días · descontable.
1 servidor · 3-4 semanas.
Hasta 4 servidores · HA · 4-6 semanas.
Multi-domain · scripting complejo.
"Mi Postfix funciona desde hace años. ¿Por qué migrar realmente?"
Postfix funciona excelentemente para email corporativo, transactional de volumen moderado y casos donde la configuración estándar cubre la operación. Las razones reales para migrar a MTA enterprise aparecen cuando la operación crece a volumen sobre 500K mensajes mensuales con multi-IP rotation, requiere throttling sofisticado por mailbox provider (Gmail/Microsoft con backoff exponencial diferente), necesita observabilidad nativa con métricas Prometheus exportables, exige runbooks operacionales para incidentes específicos del scale-up. Postfix puede emular muchas de esas capacidades con scripts custom, milters, transport maps elaborados, pero el mantenimiento del scripting casero acumula complejidad inmanejable cuando el equipo original que lo escribió ya no está. Si tu Postfix funciona y el equipo lo opera bien, no necesariamente hay que migrar. EMP cobra solo el discovery si esa es la conclusión.
"¿El queue activo se preserva sin pérdida durante la migración?"
Sí, esa es una de las razones por las cuales la migración requiere planificación. Procedimiento técnico estándar: Setup del MTA nuevo en paralelo al Postfix existente, sin tráfico productivo. Validación de paridad funcional con muestras representativas. Pausa de admission de nuevos mensajes al queue Postfix (los nuevos van al MTA nuevo). Espera de drainage del queue Postfix por 2-4 horas para que los mensajes en flight se entreguen normalmente. Para mensajes que quedan en queue después del drainage (deferred por receivers temporariamente, retries pendientes), se migran al queue del MTA nuevo usando exportador custom que respeta el retry counter y next_retry_time de cada mensaje. Validación de que el queue nuevo procesó los mensajes migrados correctamente. Decommission del Postfix después de 24-48h estables con el MTA nuevo en producción.
"¿PowerMTA o KumoMTA? ¿Cuál conviene en mi caso?"
Decisión basada en tres factores reales del cliente. Si el cliente ya tiene licencia PowerMTA activa pre-2021 o relaciones legacy con Bird, mantener PowerMTA evita coste adicional de licencia. Si el cliente no tiene licencia previa, KumoMTA (Apache 2.0, sin licencia comercial) es típicamente la respuesta correcta: el equipo original de PowerMTA está detrás del proyecto, paridad funcional confirmada en producción, observabilidad nativa Prometheus, configuración como código en Git. Si la operación tiene requirement regulatorio específico de software comercial documentado (alguna auditoría compliance específica), PowerMTA puede seguir siendo argumento válido. EMP no tiene relación contractual ni co-marketing con Bird desde 2021, por lo cual la recomendación es funcional y no comercial. Recomendación típica 2026 para operaciones nuevas o migraciones: KumoMTA en 75-80% de los casos.
"¿Qué pasa con los milters externos que tengo configurados?"
Los milters (Mail Filters) son procesos externos que Postfix consulta vía protocolo libmilter. Operación común incluye OpenDKIM, OpenDMARC, SpamAssassin, ClamAV, custom milters en C o Python. La migración aborda cada milter individualmente. OpenDKIM y OpenDMARC: típicamente se reemplazan por la firma DKIM y verificación DMARC nativas del MTA destino. SpamAssassin y ClamAV: se mantienen como milters externos en PowerMTA, o se traducen a Lua callbacks en KumoMTA con integración directa. Custom milters en C: requieren reverse-engineering de la lógica y traducción a la plataforma destino. Custom milters en Python: típicamente migrables más fácil a Lua si el destino es KumoMTA. Cualquier custom milter sin documentación es costo adicional de scoping que se identifica en el discovery.
"¿Es reversible si algo sale mal en el cutover?"
Sí, el procedure incluye plan de rollback documentado antes del cutover. Durante el período de coexistencia (Postfix y MTA nuevo corriendo en paralelo), el rollback es trivial: redirigir el tráfico de vuelta al Postfix existente, drenar el queue del MTA nuevo, decommission del MTA nuevo. Después del cutover formal y decommission del Postfix, el rollback es más costoso: requiere reactivar el Postfix con su configuración congelada en backup, re-instalar dependencias si fueron retiradas. Por eso el procedure mantiene el Postfix en standby por 14-30 días post-cutover con plan de rollback ejecutable en 2-4 horas si necesario. Después de 30 días estables se decommission formal del Postfix. La inversión en el plan de rollback es la diferencia entre migración managed y migración ad-hoc.
"¿Pueden migrar si nuestro Postfix está integrado con sistemas backend custom?"
Sí, eso es exactamente el caso típico de Enterprise tier. Integraciones backend comunes que migramos: scripts de bounce processing que invocan webhooks downstream (CRM, soporte, billing), lookup queries contra base de datos para routing dinámico (clientes premium vs estándar), inserción de headers tracking interno consumidos por sistemas de analytics propios, integración con Slack/Teams para alertas operacionales, sincronización con sistemas de suppression list externos. Cada integración se documenta en el discovery, se traduce a la plataforma destino manteniendo la interfaz con el backend del cliente (mismos endpoints, mismo formato de payload). Si la integración usa libraries específicas de Postfix (libmilter, postmap APIs), se reemplaza por la API nativa del MTA destino. La paridad funcional se valida con testing exhaustivo antes del cutover, incluyendo testing end-to-end de los sistemas backend impactados.
Inventario típico que mapeamos en el discovery:
Para cada elemento generamos equivalente funcional en la plataforma destino: PowerMTA config.txt si vamos a PowerMTA, Lua scripts si vamos a KumoMTA. La paridad funcional se valida con testing exhaustivo antes del cutover.
Tiempo varía por complejidad del scripting custom y por scope:
Variables que extienden plazo: scripts custom no documentados que requieren reverse-engineering, vendor cliente externo que requiere coordinación, ventanas de change management corporativo limitadas (CAB semanal en banca), descubrimiento de dependencias upstream del cliente no comunicadas en discovery.
Testing exhaustivo en staging con muestras representativas de los flujos productivos del cliente. Para cada flujo principal (transactional, marketing, lifecycle, notificaciones) se ejecuta una baseline con el Postfix actual capturando:
La misma baseline se ejecuta contra el MTA nuevo. Las diferencias se documentan y se resuelven antes de avanzar. Específicamente validamos: paridad de routing en transport maps, headers añadidos idénticos byte-por-byte, retry timing dentro de variación aceptable (5-15% de delta es OK, 30%+ requiere ajuste), bounce categorization idéntica, output downstream idéntico. El cliente firma off del documento de paridad antes del cutover en producción.
Sí, pero con costo adicional de scoping para el reverse-engineering. Tres escenarios típicos:
Para clientes con scripting muy custom, recomendamos contratar primero el Discovery ($2,200) para entender el alcance real antes de comprometer presupuesto del proyecto completo.
Sí, esa es premisa del scope. El MTA nuevo se configura para presentar la misma interfaz externa que el Postfix:
Si hay incompatibilidad detectada durante el testing (frecuente: headers en orden diferente, timestamp en formato distinto), se ajusta la configuración del MTA destino para alinear con el comportamiento Postfix observado. El cliente no debería notar cambio funcional en sistemas downstream.
Durante la fase de coexistencia (Postfix y MTA nuevo en paralelo) hay monitoreo dual:
Después del cutover y los 14-30 días de standby, el monitoreo Postfix se decommission junto con el Postfix. El MTA nuevo queda con monitoreo nativo activado.
Para clientes regulados (banca, government, healthcare) el scope incluye consideraciones adicionales:
Para banca SBP específicamente, el plan de migración cumple con Acuerdo SBP No. 11-2018 sobre Gestión de Riesgo Tecnológico. EMP coordina con el área de riesgo tecnológico del cliente durante la migración.
Cuatro escenarios donde EMP recomienda no migrar:
EMP no fuerza migraciones que no aportan valor real. Si después del discovery la conclusión es que Postfix sigue siendo correcto, cobramos solo el discovery ($2,200) sin proyecto de migración. Para clientes con scripting Postfix complejo que solo necesitan documentación + runbooks (no migrar), ofrecemos servicio separado de Postfix audit + documentation.
Validamos en discovery el alcance real del scripting custom de tu Postfix, identificamos qué requiere reverse-engineering, decidimos PowerMTA vs KumoMTA basado en variables reales del cliente, entregamos plan de migración con presupuesto cerrado. Si después del discovery concluimos que tu Postfix sigue siendo la respuesta correcta, lo decimos honestamente y cobramos solo el discovery. Si el proyecto avanza, el costo del discovery se descuenta del primer servicio dentro de 90 días.
