...

Actualización de Dovecot: novedades de la versión CE 2.4 y estado actual de Dovecot 3

Para un Actualización de Dovecot CE 2.4.5 es el punto de referencia fiable y estable, no una hoja de ruta anunciada para Dovecot 3. Quien migre desde la versión 2.3 debe comprobar por separado la configuración, los componentes eliminados, los formatos de almacenamiento y los servicios adicionales, como Sieve o la búsqueda de texto completo. Es especialmente importante la activación gradual de las versiones de configuración y almacenamiento, así como la realización de pruebas con buzones representativos. Las declaraciones procedentes de la rama de desarrollo no sustituyen ni a una versión publicada ni a un plan de migración sólido.

Dovecot 3: cómo situar el estado de las versiones y la hoja de ruta

Quien tenga previsto actualizar Dovecot no debe interpretar las denominaciones de las versiones como una promesa de una próxima versión principal. A fecha de 21 de octubre de 2026, Dovecot CE 2.4.5 es la versión estable publicada en el repositorio oficial Core. Sin embargo, no hay constancia allí de una versión 3.0 de Dovecot CE ni de una hoja de ruta oficial para la versión CE 3.0.

Versión confirmada y afirmaciones que no se derivan de ella
DeclaraciónClasificación a fecha de referenciaConsecuencia práctica
Dovecot CE 2.4.5Versión estable publicada en el repositorio oficial.La planificación de la actualización puede basarse en la línea 2.4 documentada.
Documentación sobre modificaciones posteriores a la versión 2.4Puede describir los cambios en el desarrollo sin necesidad de lanzar una nueva versión estable.No debe considerarse una versión final instalable ni una fecha de entrega prometida.
Dovecot 3No se ha encontrado ninguna hoja de ruta confirmada de CE 3.0 en el material revisado.No hay que tener en cuenta ni el alcance funcional ni la fecha de migración.
principalRama de desarrollo; no sustituye a una versión estable del producto.Adecuado para la observación y la evaluación preliminar, pero no para compromisos firmes sobre el producto.

En concreto, un título como „de la v2.4.5 a la v2.4.6“ en la documentación no indica que se haya publicado una versión 2.4.6. Este tipo de contenidos pueden ayudar a detectar a tiempo los cambios en la rama de desarrollo. Sin embargo, no permiten determinar cuándo, si es que lo harán, ni de qué forma se incorporarán a un paquete estable. Esto es aún más cierto en el caso de las versiones derivadas de Dovecot 3.

Para las decisiones en el Alojamiento de correo electrónico Además, las ramas de productos deben mantenerse separadas. Dovecot CE hace referencia a la edición comunitaria, mientras que Dovecot Pro es una oferta comercial independiente. Por lo tanto, una función, un modelo operativo o una indicación de la documentación no se pueden transferir automáticamente de una a otra. Asimismo, los contenidos de la rama «main» deben distinguirse de las versiones publicadas de la CE; lo determinante para una actualización son la versión y la documentación que se vayan a utilizar realmente.

Qué cambia en el modelo de versiones de Dovecot 2.4

Dovecot 2.4 distingue entre tres niveles que, a menudo, se confunden al realizar una actualización: la versión instalada del programa, dovecot_config_version y dovecot_storage_version. El paquete instalado determina qué código puede ejecutar el servidor IMAP. Por su parte, estos dos ajustes controlan de forma deliberada a partir de qué versión se utilizan los valores predeterminados modificados o los nuevos formatos de almacenamiento.

El Versión de configuración De este modo, se evita que un cambio de paquete active tácitamente todos los nuevos valores predeterminados. Los administradores pueden actualizar primero Dovecot a la versión 2.4 y, a continuación, ajustar la semántica de configuración de forma específica, tras haber comprobado el inicio de sesión, el TLS, los complementos y los ajustes existentes. Esto reduce las sorpresas derivadas de los cambios en los valores predeterminados, pero no sustituye a la necesaria migración de una configuración de la versión 2.3.

El Versión almacenada Por el contrario, se refiere a los formatos de datos que Dovecot crea en sus índices u otras áreas de almacenamiento. Un valor más alto puede activar formatos que las versiones anteriores de Dovecot no reconocen. Por ello, solo debe configurarse cuando ya no forme parte del plan de recuperación la posibilidad de volver a una versión anterior del programa. La reversión del paquete por sí sola no restaura automáticamente los formatos de índice utilizados anteriormente.

Servidor de correo compacto con almacenamiento externo instalado en un banco de trabajo de segunda mano.
Imagen ilustrativa generada por IA: el estado del programa y los formatos de almacenamiento deben planificarse por separado durante la actualización.

Para una migración de la versión 2.3 a la 2.4, ambos ajustes deben estar presentes en la configuración principal; dovecot_config_version Para ello, el primer ajuste debe ser en dovecot.conf . Establece la versión de configuración en el nivel de destino previsto solo después de haber adaptado y comprobado la sintaxis 2.4. La versión de memoria se mantiene inicialmente en el nivel compatible requerido hasta ahora y no se actualiza automáticamente al nivel del paquete.

El segundo paso explícito es el Autorización crítica para la reversión nuevos formatos de almacenamiento. Solo cuando todas las instancias utilicen la nueva versión, ya no esté prevista la vuelta a versiones anteriores de Dovecot y se disponga de una ventana de mantenimiento programada, se podrá dovecot_storage_version aumentarse hasta el nivel objetivo seleccionado, por ejemplo, a 2.4.5 para el formato de índice de hilos documentado allí. Las versiones anteriores pueden volver a crear este índice en su propio formato; sin embargo, esto supone un trabajo adicional y un cambio entre formatos de índice que no son compatibles entre sí. Por lo tanto, esta indicación no constituye una configuración estándar lista para copiar: los valores de partida y de destino dependen de la versión utilizada y del plan de contingencia.

Este enfoque por etapas se asemeja al principio de evaluar por separado el estado del programa y los cambios de comportamiento implementados. También en el caso de otros componentes del servidor, un número de versión elevado no basta como prueba de compatibilidad; el artículo sobre Decisiones sobre la actualización a Redis 8 Explica esta distinción para otro servicio. En el caso de Dovecot, también son relevantes los formatos de buzón, los datos de índice y la estrategia de respaldo.

Nuevas funciones y su grado de madurez

Una novedad importante en Dovecot 2.4 es fts-flatcurve como backend local de búsqueda de texto completo basado en Xapian. El controlador almacena los datos de búsqueda por buzón en la ruta de índice de Dovecot y requiere Xapian a partir de la versión 1.4. Admite la valoración de relevancia y también permite realizar búsquedas de subcadenas, pero no ofrece búsqueda difusa. Sin un índice de texto completo, Dovecot debe buscar secuencialmente en los datos de los mensajes para realizar las búsquedas correspondientes.

La búsqueda de subcadenas no está activada automáticamente en Flatcurve: la configuración predeterminada documentada de fts_flatcurve_substring_search es no. Si se activa deliberadamente para consultas de búsqueda IMAP adecuadas, hay que prever espacio de almacenamiento adicional para el índice. Por lo tanto, Flatcurve sigue siendo una opción para los servidores IMAP en los que se realiza búsqueda de mensajes con regularidad, pero no es una actualización obligatoria sin condiciones. El crecimiento del índice, la supervisión y la reindexación forman parte de la planificación operativa.

SMTPUTF8 e IMAP deben clasificarse de otra manera UTF8=ACCEPT e IMAP4rev2. La información sobre la versión indica que estas opciones son experimentales. SMTPUTF8 y UTF8=ACCEPT crear una compilación con --enable-experimental-mail-utf8 y a continuación mail_utf8_extensions = yes en la configuración. IMAP4rev2 utiliza opciones independientes: durante la compilación, se establece --enable-experimental-imap4rev2 es necesario; a continuación, hay que imap4rev2_enabled = yes se puede configurar.

En este contexto, «experimental» no significa que la función sea inadecuada en general. Más bien se trata de que no es un estándar general para todas las ofertas de alojamiento web. Antes de activarla, los operadores deberían comprobar si los clientes de correo utilizados, toda la cadena de entrega y los sistemas conectados realmente necesitan y pueden gestionar el procesamiento UTF-8 o IMAP4rev2 deseados. Las pruebas deben realizarse en un entorno que reproduzca adecuadamente la autenticación real, los nombres de los buzones de correo y los perfiles de los clientes.

Los mecanismos SCRAM, el enlace de canal TLS y el procesamiento avanzado de SNI y ALPN de TLS también merecen una evaluación por separado. No solo afectan al proceso de Dovecot, sino también a la interacción con clientes, certificados, proxies y fuentes de autenticación. El criterio más adecuado es una necesidad clara con compatibilidad verificable, no la mera disponibilidad de una nueva opción en una versión de Dovecot.

Preparar sistemáticamente la actualización a la versión 2.4

La actualización de Dovecot 2.3 a 2.4 comienza con un análisis del estado actual del sistema, no con el gestor de paquetes. Registra la versión instalada del programa, la configuración vigente y el formato de los buzones de correo, como Maildir o mdbox. Documenta además las fuentes de autenticación, las reglas Sieve, las cuotas, la búsqueda de texto completo, la replicación y los proxies intermedios. Solo así se podrá ver qué servicios y rutas de datos se ven realmente afectados por la migración.

Los siguientes comandos son adecuados para realizar un inventario de lectura. No modifican ni la configuración ni los datos de correo; no obstante, su salida debe mostrarse en un entorno de trabajo protegido, ya que puede permitir extraer conclusiones sobre el entorno del servidor.

Terminal
dovecot --version
doveconf -n

dovecot --version muestra el estado del programa. Con doveconf -n comprueba la configuración efectiva que difiere de los valores predeterminados. La opción -v de doveadm Por el contrario, no se trata de una consulta de versión, sino que activa una salida más detallada, incluida una barra de progreso, y solo corresponde a un subcomando adecuado. Trata la salida de configuración de forma confidencial: puede contener nombres de host, estructuras de directorios, direcciones de backend u otros detalles de la infraestructura. Para el análisis de errores, la documentación de Dovecot recomienda utilizar una configuración reducida en lugar de un volcado público completo.

Comprueba además si la versión actual es ya la última versión 2.3 disponible. La ruta de migración documentada conduce primero a esta versión y, solo después, a la 2.4. No transfieras la configuración directamente a un sistema de producción, sino a un sistema de pruebas con cuentas, permisos y tamaños de buzones representativos. Al igual que en un Actualización del núcleo para servidores de alojamiento En este caso tampoco basta con el número de versión: la configuración del paquete, los módulos activados y la arquitectura determinan el resultado práctico.

Planificar la migración de la versión 2.3 a la 2.4

La migración a la versión 2.4 es un paso de configuración independiente. Dovecot 2.4 requiere una sintaxis adaptada, así como dovecot_config_version y dovecot_storage_version; la versión de configuración debe ser el primer valor de dovecot.conf Por lo tanto, no copies los archivos antiguos tal cual. Compara cada configuración utilizada con la documentación de migración específica de cada versión y valídala en el sistema de pruebas antes de programar una ventana de mantenimiento.

Puntos clave de la migración de Dovecot 2.3 a Dovecot 2.4
GamaModificación en la versión 2.4Posible enfoqueComprobación previa a la conversión
Configuración básicaEs necesario indicar la versión y la sintaxis modificadaRevisar la configuración para la versión 2.4Comprobación del analizador y inicio de la prueba
DirectorSe ha eliminado la arquitectura de Dovecot DirectorPara entornos pequeños, se puede probar Lua Director; la documentación lo indica como no compatible. La antigua función de Director se sustituye en Dovecot Pro por Palomar.Evaluar por separado el enrutamiento, los escenarios de fallo y la responsabilidad operativa
ReplicadorComponente eliminadoEstudiar NFS u otro sistema de archivos compartido como enfoque arquitectónicoProbar los accesos a la memoria, la conmutación por error y los procesos de consistencia
Comando dsyncSe ha eliminado el enlace simbólico «dsync»Ajustar los procesos de sincronización o migración programados con «doveadm sync» o «doveadm backup»Comprobar las llamadas a funciones y los valores de retorno durante la ejecución de la prueba
quota-dict y quota-dirsizeSe han eliminado los backends de cuotasEvaluar «quota-count» como posible alternativaCalcular la cuota y comprobar los casos límite
fts-lucene y fts-squatSe han eliminado los backends de búsquedaValorar fts-flatcurve o SolrProbar la búsqueda, la creación de índices y los requisitos de memoria

La tabla no incluye recetas alternativas. El Director y el Replicator eliminados se refieren a tareas diferentes: según la documentación, Lua Director es solo una solución no compatible para implementaciones pequeñas, mientras que para Replicator se menciona un sistema de archivos compartido como enfoque. doveadm sync es, en cambio, el sucesor del eliminado dsync-Enlaces simbólicos, y puede utilizarse para procesos de sincronización o migración planificados deliberadamente; de ello no se deriva ningún sustituto directo documentado para Director o Replicator.

También en lo que respecta a las cuotas y la búsqueda, el conjunto de datos disponible es determinante. Compatibilidad Esto no solo significa que Dovecot se inicie: las alertas de cuota, las acciones Sieve, las búsquedas IMAP y el acceso de varios clientes deben funcionar con cuentas de prueba realistas. Anota, para cada componente eliminado, dónde está configurado, qué datos utiliza y cuál es el procedimiento de reversión. Solo así se podrá programar de forma adecuada la migración de paquetes.

Valorar de forma específica los formatos de búsqueda y almacenamiento

En Dovecot 2.4, la versión del programa, la configuración y el estado de la memoria se pueden desarrollar de forma deliberadamente independiente. Aumenta dovecot_storage_version solo cuando ya no esté prevista la posibilidad de volver a una versión anterior de Dovecot. Con el nivel de almacenamiento 2.4.5, el índice de subprocesos para el comando IMAP THREAD un nuevo formato v2. Los índices de hilos existentes se reconstruirán en la próxima operación de organización en hilos; esto puede suponer un esfuerzo adicional en la primera consulta, sobre todo en el caso de buzones de correo de gran tamaño.

Una versión anterior de Dovecot no reconoce este formato de índice de hilos y vuelve a generar el índice en el formato antiguo. El Nivel de almacenamiento Por lo tanto, se trata de una decisión operativa, no de un mero cambio estético de la versión. Planifica las posibles reestructuraciones de los índices dentro de un intervalo de tiempo controlado y no las realices al mismo tiempo que otros cambios difíciles de revertir en la búsqueda, el almacenamiento o la topología del proxy.

Enfoques de búsqueda en el entorno de Dovecot según el modelo operativo
Acérquese aLugar de referenciaInfraestructura adicionalLímite de usoLínea de productos
Sin FTSNo hay índice de búsquedaNingunoLas búsquedas de texto y de cuerpo se realizan de forma secuencialDovecot CE
fts-flatcurvePor cada buzón en la ruta de índice de DovecotXapian a partir de la versión 1.4Programar el almacenamiento local de índices, la supervisión y la reindexación; la búsqueda de subcadenas está desactivada de forma predeterminadaDovecot CE
SolrServicio de búsqueda independienteFuncionamiento de SolrGestionar servicios adicionales y su disponibilidadDovecot CE
Dovecot Pro FTSDiseñado para el almacenamiento de objetosPro-EntornoNo debe confundirse con CE-FlatcurveDovecot Pro

Para los índices de búsqueda locales, es fts-flatcurve una opción si el entorno proporciona Xapian 1.4 o una versión posterior. El controlador almacena los datos de índice por buzón en la ruta de índice de Dovecot y admite la ponderación por relevancia. Las búsquedas por subcadena se pueden activar y se realizan con fts_flatcurve_substring_search = no Sin embargo, están desactivadas por defecto y, si se activan, requieren una cantidad considerable de memoria de índice adicional. Flatcurve no admite la búsqueda difusa.

Por lo tanto, evalúa la Arquitectura de búsqueda en función del tamaño de los buzones de correo, el tipo de almacenamiento y el modelo operativo, en lugar de según una clasificación general. doveadm fts flatcurve stats proporciona datos de estado almacenados sobre los índices Flatcurve. Hay que distinguir esto de doveadm fts flatcurve check: Este comando comprueba las bases de datos de Xapian e intenta corregir errores básicos, por lo que puede alterar su estado. La rotación y la eliminación de índices también son medidas de mantenimiento específicas. Antes de realizar estas intervenciones, planifica el alcance, los buzones afectados y la posible reconstrucción de los índices.

Comprobar filtros, servidores proxy y límites de seguridad

Los filtros Sieve constituyen un punto de comprobación independiente en la actualización de Dovecot, ya que esta extensión no forma parte del núcleo de Dovecot: Sieve y ManageSieve los proporciona el proyecto independiente Pigeonhole. En el caso de instalaciones compiladas por uno mismo, es necesario volver a compilar Pigeonhole junto con la nueva versión de Dovecot. De lo contrario, el complemento del intérprete no se podrá cargar debido a un conflicto de versiones.

En las instalaciones basadas en distribuciones, lo fundamental es que los paquetes de Dovecot y Pigeonhole procedan de fuentes de paquetes compatibles entre sí. Antes de la ventana de mantenimiento, comprueba qué scripts de usuario activos, scripts globales y accesos a ManageSieve hay disponibles. Tras la actualización, se debe comprobar el envío, el redireccionamiento, las respuestas de «fuera de la oficina» y cualquier modificación realizada a través de ManageSieve utilizando una cuenta de prueba destinada a tal fin; los filtros en producción no sustituyen a esta prueba.

En las arquitecturas de proxy, la Compresión IMAP especial atención. Cuando la versión de configuración se actualice a la 2.4.5, el valor predeterminado para imap_compress_on_proxy yes. De este modo, el procesamiento de la compresión se traslada al proxy; según la documentación, esta configuración debe realizarse en el backend. Es imprescindible que estén correctamente definidas login_trusted_networks así como límites de confianza bien definidos entre el proxy y el backend.

Una técnica comprueba las conexiones de los servidores en un entorno compacto de servidores proxy y de correo electrónico.
Imagen ilustrativa generada por IA: las rutas de proxy y los límites de confianza forman parte de la comprobación de actualizaciones.

Por lo tanto, antes de aplicar la nueva configuración predeterminada, aclara lo siguiente: ¿qué conexiones terminan en el proxy?, ¿qué direcciones IP debe considerar el backend como de confianza? y ¿en qué sistema deben generarse la carga de la CPU y el tráfico de datos derivados de la compresión? Solo se puede evaluar adecuadamente un cambio si estas cuestiones se ajustan a la arquitectura real de la red. Este cambio no sustituye ni a una verificación TLS ni a un control de acceso fiable entre los sistemas implicados.

Tampoco deben activarse de forma generalizada las nuevas funciones de autenticación y los protocolos experimentales. La información sobre la versión menciona mecanismos SCRAM, incluido el enlace de canal TLS, así como SMTPUTF8, IMAP UTF8=ACCEPT y IMAP4rev2. SMTPUTF8 y UTF8=ACCEPT son necesarios durante la compilación --enable-experimental-mail-utf8 y en la configuración mail_utf8_extensions = yes. Por otra parte, IMAP4rev2 establece el parámetro de compilación --enable-experimental-imap4rev2 y imap4rev2_enabled = yes antes. Comprueba la compatibilidad con los clientes, la cadena de entrega y el comportamiento en caso de fallo para cada función por separado antes de implementarla en el Alojamiento de correo electrónico ofreces.

Funcionamiento seguro tras la actualización

Una actualización no se da por concluida hasta que se hayan realizado las comprobaciones técnicas pertinentes, no solo tras la ejecución satisfactoria de los paquetes. Durante la ventana de mantenimiento, comprueba en primer lugar si el servicio se inicia y si los registros muestran errores de configuración, de complementos o de permisos. A continuación, inicia sesión y accede al buzón con una cuenta de prueba. Comprueba, como mínimo, la lista de carpetas, la selección de mensajes, la lectura y una entrega controlada, para asegurarte de que el servidor IMAP no solo sea accesible, sino también utilizable.

Comprueba que Sieve y Quota funcionen como funciones independientes. El hecho de que el inicio de sesión en IMAP se realice con éxito no garantiza que Pigeonhole se haya cargado ni que los límites de cuota se calculen correctamente. Por lo tanto, prueba una regla de filtrado inofensiva y un envío que se acerque a un límite de cuota previsto en un buzón de prueba aislado. De este modo, se pueden detectar errores en los complementos, los permisos y la conexión con el backend de cuotas correspondiente, sin sobrecargar deliberadamente los buzones de los clientes.

Cuando la búsqueda de texto completo está activada, el seguimiento del estado del índice y de las consultas de búsqueda se realiza en la fase posterior. Para obtener una visión general de los datos existentes en el índice Flatcurve, se utiliza doveadm fts flatcurve stats. El subcomando check Hay que diferenciarlo claramente: comprueba las bases de datos de Xapian e intenta corregir errores básicos, por lo que no se trata de un diagnóstico que garantice un modo de solo lectura. Utilízalo, al igual que la rotación o la eliminación de índices, únicamente como medida de mantenimiento planificada para buzones específicos y ten en cuenta los posibles cambios de estado, así como la necesidad de volver a crear los índices.

Si hay proxies intermedios, también controlas todo el vía de tráfico: ¿Llega el registro al backend previsto, se gestionan correctamente la IP del cliente y la red de confianza, y no surgen problemas inesperados de compresión o TLS? Para comprobarlo, compara cronológicamente los registros de los componentes implicados. No basta con que se produzcan algunos inicios de sesión correctos si intervienen varios backends, diferentes redes de clientes o terminaciones TLS independientes.

Para la resolución de errores, la documentación de Dovecot recomienda una configuración reducida al mínimo. Para ello, en un entorno seguro, ve reduciendo paso a paso los componentes hasta identificar aquellos que reproducen el error, en lugar de publicar toda la configuración de producción. Advertencia: Los documentos, como la configuración efectiva, pueden contener detalles de la infraestructura o información confidencial. Por lo tanto, no los compartas íntegramente ni en tickets, ni en foros, ni en documentos públicos, sino que elimínales la información sensible de forma selectiva.

Cuándo merece la pena actualizar Dovecot

La actualización de Dovecot a la versión CE 2.4.5 no es solo una decisión relacionada con las funciones y la arquitectura. Las notas de la versión recogen numerosas correcciones de seguridad críticas que afectan, entre otras cosas, a los comandos IMAP, Submission, las verificaciones OAuth, dsync, la autenticación y la compresión. Por lo tanto, los administradores deberían comprobar lo antes posible si su instalación se ve afectada y qué versión de paquete o backport ofrece la distribución utilizada para aplicar las correcciones. La versión original por sí sola no implica ni que un paquete de la distribución no esté parcheado, ni que una actualización inmediata genérica sin comprobación de migración sea segura.

Además de esta evaluación de seguridad, una actualización puede justificarse si se basa en una necesidad de compatibilidad, un requisito operativo concreto o una modernización que pueda someterse a pruebas verificables. Entre estos pueden figurar los controladores de versión verificables para la configuración y el almacenamiento. Sin embargo, el estado del paquete por sí solo no es un criterio suficiente para tomar una decisión: el formato del buzón, la autenticación, la cuota, Sieve, la búsqueda y la topología del proxy determinan cuál es realmente el esfuerzo que supone la migración.

La priorización de las instalaciones en la versión 2.3 resulta especialmente recomendable cuando la situación de seguridad y el estado de la distribución disponible aconsejan una actualización, y la migración puede realizarse en un sistema de pruebas. En este sentido, en lo que respecta al almacenamiento se mantiene una actitud deliberadamente cautelosa: los nuevos formatos de almacenamiento solo deben activarse cuando ya no esté prevista la posibilidad de volver a versiones anteriores de Dovecot. Esto afecta, entre otras cosas, al índice de hilos modificado en la versión 2.4.5, cuya reconstrucción se lleva a cabo en la siguiente consulta de hilos.

Las funciones adicionales son decisiones arquitectónicas independientes. Flatcurve Es recomendable valorarlo si se utiliza habitualmente la búsqueda de noticias y si el almacenamiento local de índices, la dependencia de Xapian, la supervisión y la reindexación se ajustan al modelo operativo. La documentación clasifica el controlador como un índice de búsqueda de texto completo local basado en Xapian; de ello no se deriva una recomendación general frente a Solr ni la renuncia a la búsqueda de texto completo.

Las opciones experimentales UTF8 e IMAP4rev2 solo se justifican si existe una necesidad demostrada a lo largo de toda la cadena, desde el cliente de correo electrónico hasta el envío o la entrega y el acceso IMAP. Sin este requisito previo, su activación solo aumenta la carga de trabajo de verificación. Lo mismo se aplica a los nuevos mecanismos de autenticación: el hecho de que una versión incluya esta funcionalidad no exime de comprobar los clientes utilizados, la configuración de TLS y la fuente de autenticación.

En cuanto a Dovecot 3, a partir de la información publicada sobre la versión CE, no es posible confirmar ni una fecha, ni un conjunto de funciones, ni una ruta de migración. La versión estable confirmada es la CE 2.4.5; las indicaciones en la documentación de desarrollo o en la rama main No se trata de una versión publicada del producto ni de una hoja de ruta. Por lo tanto, planifica basándote en la versión 2.4 que está realmente disponible, distíngela de Dovecot Pro y evalúa los anuncios posteriores solo cuando se hayan publicado oficialmente.

Fuentes y estado actual de los conocimientos

Estado de la investigación:

Estado de la investigación: 21 de octubre de 2026. Dovecot CE 2.4.5 es la versión estable confirmada en las fuentes oficiales disponibles. No se ha confirmado la publicación de ninguna hoja de ruta para la versión CE 3.0.

https://github.com/dovecot/core/releases

https://doc.dovecot.org/2.4.2/installation/upgrade/2.3-to-2.4.html

https://doc.dovecot.org/2.4.5/installation/upgrade/2.4-to-2.4.x.html

https://doc.dovecot.org/2.4.2/installation/upgrade/overview.html

https://doc.dovecot.org/2.4.0/core/plugins/fts_flatcurve.html

https://doc.dovecot.org/2.4.5/issues.html

https://doc.dovecot.org/2.4.5/core/man/doveadm-fts.1.html

https://doc.dovecot.org/2.4.0/core/plugins/fts.html

https://doc.dovecot.org/2.4.5/installation/sieve.html

https://doc.dovecot.org/2.4.5/core/summaries/settings.html

Artículos de actualidad

Pequeño armario de red situado en una sala de servidores de segunda mano, como símbolo de la protección de los servicios Linux accesibles
Seguridad

Alternativas a Fail2Ban para servidores Linux modernos

CrowdSec, SSHGuard y nftables adoptan diferentes enfoques de protección. Los factores decisivos son la superficie de ataque, las fuentes de registro, el nivel de aplicación y los costes operativos que se pueden asumir a largo plazo.

Una persona comprueba el miniordenador y el router para verificar el acceso al túnel de salida.
computación en la nube

Cloudflare Tunnel como alternativa a la apertura de puertos

Cloudflare Tunnel permite acceder a aplicaciones web internas y a determinados servicios de administración sin necesidad de abrir puertos de entrada. Siguen siendo fundamentales las reglas de acceso, la autenticación multifactorial (MFA), los permisos locales y un límite claro en el registro de actividades.