Mailcow ha lanzado su actualización de octubre de 2025 —bautizada Mooctober 2025— con dos novedades que interesan a cualquier administrador de correo: actualización a Rspamd 3.13.2 y parche de seguridad para Redis. El proyecto mantiene así su ritmo de mantenimiento mensual, con foco en estabilidad y saneamiento de dependencias, tras un año en el que ya había introducido mejoras notables en autenticación, filtrado y búsqueda.
Qué es exactamente mailcow: dockerized
Para quien llegue de nuevas, mailcow: dockerized es una suite de servidor de correo preparada para desplegarse en contenedores. No es un “todo en uno” opaco, sino un conjunto orquestado de servicios ampliamente conocidos en entornos self-hosted:
- Postfix para MTA (envío y recepción).
- Dovecot para IMAP/POP3 y acceso a buzones.
- Rspamd como motor antispam de alto rendimiento.
- SOGo como webmail y groupware.
- Nginx como proxy y terminación TLS.
- MariaDB y Redis como almacenamiento y caché/colas.
- Integraciones de MTA-STS, opciones LDAP/OIDC para SSO, exportadores de métricas y utilidades de administración web.
La propuesta de valor es clara: paquetes conocidos, listos para producción, con actualizaciones coordinadas y panel de gestión. Al basarse en Docker, resulta relativamente sencillo migrar, respaldar y probar cambios en entornos paralelos antes de llevarlos a producción.
Qué trae “Mooctober 2025”
Rspamd 3.13.2
Se trata de un salto menor dentro de la rama 3.13 que consolida correcciones y ajustes. En la práctica, los administradores notarán comportamientos más predecibles en la clasificación de spam/ham, menor necesidad de tuning fino y mejoras de compatibilidad acumuladas frente a versiones anteriores de la serie 3.12.x/3.13.x. En dominios con alto volumen de correo o políticas estrictas (DMARC/ARC), esta clase de actualizaciones suele traducirse en menos falsos positivos y colas más limpias.
Parche de seguridad para Redis
La publicación incluye imagen actualizada de Redis para cerrar una vulnerabilidad reciente. En mailcow, Redis está pensado para uso local y autenticado, lo que reduce la exposición en instalaciones estándar; aun así, el proyecto prioriza llevar la dependencia a versión segura para eliminar riesgos residuales. Si el despliegue tiene personalizaciones (por ejemplo, contenedores expuestos en redes no filtradas o credenciales heredadas), conviene auditar tras actualizar.
Recordatorio de cambios recientes
En los meses previos se han incorporado mejoras que muchos administradores quizá no hayan activado aún: soporte MTA-STS desde la interfaz, SOGo 5.12.x, correcciones en IPv6 y ajustes en helpers y plantilla compose para escenarios cold-standby. Si el entorno viene desde una versión muy antigua, es prudente revisar la secuencia de releases y planificar un salto encadenado.
Impacto para administración y operaciones
- Estabilidad del filtro: Rspamd 3.13.2 reduce edge cases y afina reglas. Menos trabajo manual para “domesticar” falsos positivos y ham mal clasificado.
- Riesgo acotado en Redis: incluso si Redis no está expuesto, parchear ahora evita olvidos que luego complican auditorías o hardening posterior.
- Mantenimiento predecible: el ciclo de releases de mailcow facilita ventanas cortas y rollback controlado si algo no cuadra con personalizaciones.
Guía rápida para actualizar sin sobresaltos
- Planificar una ventana breve con aviso a soporte y monitorización activa (colas de Postfix, métricas de Rspamd, salud de contenedores).
- Snapshot/backup antes de tocar nada: snapshot de VM y copia de volúmenes Docker críticos (mail, MariaDB, Redis, configuración).
- Actualizar con el script oficial desde la carpeta raíz de mailcow (para mantener etiquetas de imágenes y compose coherentes).
- Verificaciones post-update:
- Comprobar la versión de Rspamd y tiempos de respuesta de
rspamc. - Validar que Redis arranca con la imagen nueva y que no hay errores de autenticación en servicios dependientes.
- Observar durante unas horas postscreen/greylisting y la curva de spam/ham.
- Comprobar la versión de Rspamd y tiempos de respuesta de
- Si se viene de meses atrás: revisar MTA-STS, SOGo 5.12.x e IPv6 para descartar regresiones en reverse proxies o reglas personalizadas.
Buenas prácticas tras la actualización
- Políticas y reputación: un repaso a SPF/DMARC/DKIM nunca está de más, especialmente si hubo tuning que dependía del comportamiento anterior de Rspamd.
- Listas y scores: documentar puntuaciones propias y reglas locales, y compararlas con el comportamiento de 3.13.2. En muchos casos se puede simplificar.
- TLS y ciphers: ya que se toca Nginx en algunos ciclos, revisar curvas y suites para mantener un nivel contemporáneo (y evitar advertencias de clientes modernos).
- Alertas y métricas: garantizar que el exportador de métricas y el token de seguridad asociados a Prometheus continúan vigentes tras el pull de imágenes nuevas.
Por qué mailcow sigue ganando adopción en 2025
- Transparencia de componentes: quien administra sabe qué stack corre y puede auditar cada pieza.
- Curva de aprendizaje razonable: la interfaz ayuda, pero no oculta lo esencial; si hace falta, se puede pasar al fichero y al shell.
- Operación contenida en Docker: aisla servicios y reduce el “roce” con el sistema base, lo que simplifica migraciones, copias y pruebas.
- Comunidad y cadencia: un flujo constante de parches menores que evita acumulaciones y facilita mantenerse al día sin esperar big-bang upgrades.
Preguntas frecuentes
¿Es urgente aplicar “Mooctober 2025” si mi sistema va bien?
Sí es recomendable. Aunque Redis se use de forma local y autenticada en despliegues típicos, cerrar la vulnerabilidad elimina riesgos y facilita auditorías. Rspamd 3.13.2 aporta estabilidad y pequeños ajustes que se notan en producción.
¿Actualizar puede romper mis reglas de Rspamd o mis scores locales?
No debería. Aun así, tras actualizar conviene vigilar métricas y revisar falsos positivos/negativos durante 24–48 horas. Muchas instalaciones aprovechan estos ciclos para limpiar reglas heredadas que ya no aportan.
¿Qué pasa si uso personalizaciones fuertes (proxies, plantillas propias, redes complejas)?
Planifique en entorno de pruebas y revise los helpers que mailcow ha ido ajustando este año (nombres de proyecto en compose, override, IPv6). El objetivo es alinear esas personalizaciones con el release actual.
¿Mailcow es un “appliance” cerrado o puedo cambiar piezas?
No es un appliance cerrado. Es un conjunto de servicios estándar en contenedores. Se puede personalizar (con cabeza) y auditar cada componente. Esa es parte de su atractivo para equipos que buscan control sin reinventar la rueda.
La conclusión: Mooctober 2025 es un paso de mantenimiento que suma seguridad (Redis corregido) y estabilidad (Rspamd 3.13.2). Para quienes operan correo propio, es el tipo de actualización que ahorra tiempo a medio plazo: menos sustos, menos tuning, más previsibilidad.
