Durante más de dos décadas, montar un servidor de correo propio ha significado casi siempre ensamblar varias piezas: Postfix para SMTP, Dovecot o Courier para IMAP y POP3, SpamAssassin o Rspamd para filtrado, OpenDKIM para firmas, herramientas de certificados, scripts de mantenimiento y una buena dosis de paciencia. El resultado podía ser muy sólido, pero también delicado de operar cuando se buscaba alta disponibilidad real.
La propuesta que Florian Paul Azim “gyptazy” Hoberg ha compartido en su guía técnica va justo en otra dirección: abandonar el enfoque clásico basado en múltiples servicios y montar un clúster de correo de alta disponibilidad con Stalwart Mail y FoundationDB. No es una simple sustitución de Postfix por otro demonio SMTP. Es un cambio de arquitectura.
Stalwart agrupa en una sola plataforma funciones que antes solían repartirse entre varios componentes. FoundationDB, por su parte, actúa como backend distribuido, transaccional y tolerante a fallos. La combinación permite construir un sistema de correo que no dependa de una única máquina ni de un almacenamiento local frágil, algo especialmente interesante para proyectos self-hosted avanzados, pequeñas plataformas de hosting, laboratorios de infraestructura y despliegues empresariales modestos que necesitan resiliencia sin montar una arquitectura demasiado compleja.
Por qué el stack clásico empieza a pesar
Postfix sigue siendo una pieza excelente. Es maduro, estable y está muy probado. El problema no es Postfix en sí, sino el conjunto de piezas que suelen rodearlo cuando se quiere ofrecer correo completo y disponible: SMTP, IMAP, filtrado antispam, autenticación, DKIM, DMARC, SPF, TLS, almacenamiento, réplicas, failover y administración de usuarios.
En una instalación pequeña, esa modularidad es manejable. En una plataforma con varios nodos, dominios y usuarios, empieza a aparecer el coste operativo. Hay que decidir cómo replicar buzones, cómo mantener coherencia entre nodos, cómo evitar puntos únicos de fallo, cómo gestionar certificados, cómo sincronizar configuración y cómo recuperar el servicio cuando cae una máquina.
El enfoque de Stalwart simplifica parte de ese mapa porque integra SMTP, IMAP, JMAP y otros servicios relacionados en una sola aplicación. Además, incorpora funciones modernas de seguridad y autenticación de correo como DKIM, DMARC, SPF y ARC, así como protección frente a spam y phishing. Su documentación oficial lo presenta como un servidor de correo y colaboración open source escrito en Rust, con soporte para protocolos como JMAP, IMAP4, POP3, SMTP, CalDAV, CardDAV y WebDAV.
FoundationDB aporta la otra mitad del planteamiento. Es una base de datos distribuida key-value con transacciones ACID, pensada para escalar sobre varios nodos y mantener consistencia fuerte. La propia documentación de Stalwart la recomienda como backend para despliegues distribuidos, precisamente por su tolerancia a fallos y su capacidad de escalado horizontal.
Stalwart y FoundationDB frente a Postfix y Dovecot
La comparación no debe plantearse como “lo nuevo siempre es mejor”. El stack Postfix + Dovecot ha demostrado durante años que puede operar servicios de correo muy fiables. Pero sí hay una diferencia clara de filosofía. El modelo tradicional exige montar, integrar y mantener varias piezas. El modelo Stalwart + FoundationDB intenta reducir esa dispersión y desplazar la resiliencia hacia un backend distribuido.
| Área | Stack tradicional | Stalwart + FoundationDB |
|---|---|---|
| SMTP | Postfix | Integrado en Stalwart |
| IMAP/POP3 | Dovecot, Courier u otros | Integrado en Stalwart |
| Seguridad de correo | OpenDKIM, SPF, DMARC, Rspamd, SpamAssassin y otras piezas | DKIM, DMARC, SPF, ARC y filtrado integrados |
| Almacenamiento | Maildir, mbox o backend externo | FoundationDB como store distribuido |
| Alta disponibilidad | Requiere diseño adicional con replicación, almacenamiento compartido o herramientas externas | Más natural al usar backend distribuido |
| Configuración | Varios ficheros y servicios | TOML, interfaz web y configuración centralizada |
| Complejidad operativa | Alta si se busca HA real | Menor, aunque con curva de aprendizaje nueva |
| Perfil ideal | Entornos clásicos, administradores expertos, instalaciones muy personalizadas | Self-hosting avanzado, plataformas modernas, clústeres pequeños o medianos |
La principal ventaja del nuevo enfoque está en la reducción de piezas. Menos demonios, menos configuraciones separadas y menos integraciones manuales suelen traducirse en menos puntos de rotura. También permite una experiencia de administración más moderna, especialmente para quienes no quieren vivir dentro de múltiples ficheros .cf, scripts de sincronización y reglas dispersas.
La principal desventaja es que se cambia una complejidad conocida por otra distinta. FoundationDB requiere memoria, monitorización y comprensión de su propio modelo operativo. Quien domine Postfix y Dovecot puede sentirse más cómodo con el stack tradicional. Quien busque un correo HA más integrado puede encontrar en Stalwart una vía más limpia.
Cómo sería una arquitectura básica de alta disponibilidad
La guía de gyptazy plantea una instalación sobre Debian con varios nodos FoundationDB y Stalwart instalado con soporte específico para este backend. La idea general es sencilla: primero se despliega el clúster de FoundationDB, se ajustan direcciones de red y fichero de clúster, y después se instala Stalwart en cada nodo con soporte FoundationDB desde el inicio.
A partir de ahí, la configuración se completa desde la interfaz web de Stalwart: hostname, identificador único de nodo, backend de almacenamiento, cifrado en reposo, dominios y cuentas. Al compartir FoundationDB como backend, la configuración y los datos pueden replicarse entre nodos y mantenerse disponibles ante fallos individuales.
| Componente | Función dentro del clúster |
|---|---|
| FoundationDB | Backend distribuido, transaccional y replicado |
| Stalwart Mail | Servicio de correo SMTP, IMAP, JMAP y administración |
| DNS / MX | Entrada pública del servicio de correo |
| Balanceador o reparto MX | Distribución de tráfico entre nodos |
| TLS / certificados | Cifrado de conexiones y confianza externa |
| Monitorización | Estado de nodos, colas, entregas, recursos y errores |
| Backups | Protección ante borrados, corrupción lógica o errores humanos |
Este último punto es importante. Alta disponibilidad no sustituye a una política de backup. FoundationDB puede replicar datos y mantener servicio ante fallos, pero una configuración distribuida también puede replicar errores lógicos, borrados accidentales o cambios mal aplicados. Un clúster HA sin copias de seguridad sigue siendo vulnerable.
También hay que distinguir entre disponibilidad interna y entregabilidad externa. Montar Stalwart con FoundationDB puede mejorar la resiliencia técnica, pero el correo sigue dependiendo de DNS bien configurado, SPF, DKIM, DMARC, PTR, reputación IP, listas negras, rate limits, TLS correcto y monitorización de entregas. La parte más difícil del correo moderno no es solo que el servidor funcione; es que los mensajes lleguen donde deben.
Una señal del cambio en el self-hosting empresarial
El interés por Stalwart encaja con una tendencia más amplia: administradores y pequeñas organizaciones buscan alternativas open source modernas a stacks clásicos que funcionan bien, pero que requieren mucho conocimiento acumulado. Lo mismo ha ocurrido con virtualización, almacenamiento, observabilidad o herramientas de colaboración. No se trata de abandonar lo probado por moda, sino de reducir el coste operativo cuando el diseño histórico empieza a pesar.
Para proyectos personales, Stalwart puede ser atractivo porque simplifica el despliegue y permite incorporar funciones modernas sin ensamblar demasiados componentes. Para clientes o producción, la combinación con FoundationDB abre la puerta a arquitecturas más resilientes, siempre que se diseñen con criterio y no se subestime la parte operativa.
La guía de gyptazy resulta interesante precisamente porque no se limita a decir “usa Stalwart”. Explica cómo construir un clúster, cómo preparar FoundationDB, cómo configurar direcciones, cómo iniciar servicios y cómo conectar cada instancia al backend distribuido. Es un enfoque práctico, cercano al trabajo real de sysadmin.
Postfix no va a desaparecer. Seguirá siendo una referencia y seguirá teniendo sentido en muchos entornos. Pero Stalwart demuestra que el correo autoalojado puede moverse hacia arquitecturas más integradas, con seguridad incorporada y almacenamiento distribuido desde el diseño. Para quienes llevan años manteniendo pilas de correo con varias piezas encajadas a mano, esa evolución merece atención.
El correo electrónico sigue siendo una infraestructura crítica y, paradójicamente, una de las más castigadas por configuraciones heredadas. La novedad no es que exista otro servidor de correo. La novedad es que empieza a ser viable plantear HA, cifrado, administración web, protocolos modernos y backend distribuido sin construir una torre de servicios pegados con scripts.
Preguntas frecuentes
¿Stalwart sustituye por completo a Postfix y Dovecot?
Puede hacerlo en determinados despliegues, porque integra SMTP, IMAP, JMAP, POP3 y funciones de seguridad. Aun así, Postfix y Dovecot siguen siendo opciones muy sólidas en entornos clásicos o altamente personalizados.
¿Por qué usar FoundationDB con Stalwart?
Porque FoundationDB permite usar un backend distribuido y transaccional, lo que facilita despliegues con varios nodos y mayor tolerancia a fallos frente a instalaciones basadas solo en almacenamiento local.
¿Es una buena opción para producción?
Puede serlo si se diseña bien: varios nodos, backups, monitorización, DNS correcto, TLS, seguridad, pruebas de failover y políticas claras de operación. No basta con instalar el software.
¿Qué ventajas tiene para self-hosting avanzado?
Reduce el número de componentes, centraliza funciones modernas de correo y permite montar una arquitectura más resiliente sin depender de una combinación compleja de Postfix, Dovecot y herramientas externas.
