...

Actualités Dovecot : nouveautés de la version CE 2.4 et état d'avancement de Dovecot 3

Pour un Mise à jour de Dovecot C'est la version CE 2.4.5 qui constitue le point de référence fiable et stable, et non une feuille de route annoncée pour Dovecot 3. Quiconque effectue une migration depuis la version 2.3 doit vérifier séparément la configuration, les composants supprimés, les formats de stockage et les services supplémentaires tels que Sieve ou la recherche en texte intégral. L'activation progressive des versions de configuration et de stockage, ainsi que les tests sur des boîtes aux lettres représentatives, revêtent une importance particulière. Les informations issues de la branche de développement ne remplacent ni une version publiée, ni un plan de migration fiable.

Dovecot 3 : situer la version actuelle et la feuille de route

Si vous prévoyez une mise à jour de Dovecot, ne considérez pas les numéros de version comme une promesse d'une prochaine version majeure. À la date de cette recherche, le 21 octobre 2026, Dovecot CE 2.4.5 est la version stable publiée dans le dépôt officiel Core. En revanche, aucune version 3.0 de Dovecot CE ni aucune feuille de route officielle pour la version CE 3.0 n'y sont mentionnées.

Version confirmée et affirmations qui n'en découlent pas
TémoignageClassification à la date de référenceConséquence pratique
Dovecot CE 2.4.5Version stable publiée dans le dépôt officiel.La planification de la mise à niveau peut se référer à la version 2.4 documentée.
Documentation relative aux modifications ultérieures de la version 2.4Permet de décrire les modifications apportées au développement sans avoir à publier une nouvelle version stable.Ne pas considérer cela comme une version cible à installer ou un engagement de date.
Dovecot 3Aucune feuille de route confirmée pour la version CE 3.0 n'a été trouvée dans les documents examinés.Ne pas prévoir ni l'étendue des fonctionnalités ni la date de migration.
mainBranche de développement, ne remplace pas une version stable du produit.Convient à l'observation et à l'évaluation préliminaire, mais ne permet pas de formuler des engagements fermes concernant le produit.

En particulier, un titre tel que „ v2.4.5 à v2.4.6 “ dans la documentation ne fait pas référence à une version 2.4.6 publiée. De tels contenus peuvent aider à identifier rapidement les modifications apportées à la branche de développement. Ils ne permettent toutefois pas de déterminer quand, si ou sous quelle forme celles-ci seront intégrées dans un paquet stable. Cela vaut d'autant plus pour les dérivés de Dovecot 3.

Pour les décisions relatives à Hébergement d'e-mails Les branches de produits doivent en outre rester distinctes. Dovecot CE désigne l'édition communautaire, tandis que Dovecot Pro est une offre commerciale distincte. Une fonctionnalité, un modèle d'exploitation ou une mention dans la documentation ne peut donc pas être automatiquement transposé d'une édition à l'autre. Les contenus issus de la branche « main » doivent également être distingués des versions CE publiées ; ce sont la version et la documentation qui seront effectivement utilisées qui sont déterminantes pour une mise à niveau.

Ce qui change dans la version 2.4 de Dovecot

Dovecot 2.4 distingue trois niveaux qui sont souvent confondus lors d'une mise à jour : la version du programme installée, dovecot_config_version et dovecot_storage_version. Le paquet installé détermine le code que le serveur IMAP peut exécuter. Les deux paramètres permettent en revanche de définir précisément à partir de quelle version les valeurs par défaut modifiées ou les nouveaux formats de stockage sont utilisés.

Le Version de configuration Cela empêche ainsi qu'une mise à jour du paquet n'active tacitement toutes les nouvelles valeurs par défaut. Les administrateurs peuvent dans un premier temps mettre à jour Dovecot vers la version 2.4, puis ajuster la sémantique de configuration de manière ciblée après avoir vérifié la connexion, le protocole TLS, les plugins et les paramètres existants. Cela réduit les surprises liées à la modification des valeurs par défaut, mais ne remplace pas la migration nécessaire d'une configuration 2.3.

Le Version en mémoire concerne en revanche les formats de données que Dovecot crée dans ses index ou dans d'autres zones de stockage. Une valeur plus élevée peut activer des formats que les anciennes versions de Dovecot ne prennent pas en charge. C'est pourquoi il ne faut la définir que lorsque le retour à une version antérieure du programme ne fait plus partie du plan de restauration. Une simple restauration du paquet ne rétablit pas automatiquement les formats d’index utilisés auparavant.

Serveur de messagerie compact avec stockage externe, installé sur un établi d'occasion.
Image illustrative générée par IA : la version du programme et les formats de sauvegarde doivent être planifiés séparément lors de la mise à jour.

Pour une migration de la version 2.3 vers la version 2.4, ces deux paramètres doivent figurer dans la configuration principale ; dovecot_config_version Le premier paramètre doit alors être défini dans dovecot.conf . Ne définissez la version de configuration sur la version cible prévue qu'après avoir adapté et vérifié la syntaxe 2.4. La version de stockage reste dans un premier temps à la version compatible requise jusqu'à présent et n'est pas automatiquement mise à niveau vers la version du paquet.

La deuxième étape explicite consiste à validation critique pour la restauration nouveaux formats de stockage. Ce n’est que lorsque toutes les instances utiliseront la nouvelle version, qu’un retour à d’anciennes versions de Dovecot ne sera plus envisagé et qu’une fenêtre de maintenance aura été prévue que dovecot_storage_version être augmenté jusqu’à la valeur cible choisie, par exemple à 2.4.5 pour le format d'index de thread qui y est documenté. Les versions plus anciennes peuvent recréer cet index dans leur propre format ; cela implique toutefois un surcroît de travail et un passage entre des formats d'index incompatibles. Ces indications ne constituent donc pas une configuration standard prête à l’emploi : les valeurs de départ et cibles dépendent de la version utilisée et du plan de secours.

Cette approche par étapes s'apparente au principe consistant à évaluer séparément l'état du programme et les changements de comportement mis en œuvre. Pour d'autres composants du serveur également, un numéro de version élevé ne suffit pas à prouver la compatibilité ; l'article sur Décisions relatives à la mise à niveau vers Redis 8 explique cette distinction pour un autre service. Dans le cas de Dovecot, les formats de boîte aux lettres, les données d'indexation et la stratégie de secours sont également pris en compte.

Nouvelles fonctionnalités et leur niveau de maturité

Une nouveauté importante dans Dovecot 2.4 est fts-flatcurve en tant que backend local de recherche en texte intégral basé sur Xapian. Le pilote stocke les données de recherche par boîte aux lettres dans le chemin d'indexation de Dovecot et nécessite Xapian à partir de la version 1.4. Il prend en charge l'évaluation de la pertinence et peut également permettre des recherches par sous-chaîne, mais n'offre pas de recherche floue. En l'absence d'index plein texte, Dovecot doit parcourir séquentiellement les données des messages pour effectuer les recherches correspondantes.

La recherche de sous-chaînes n'est pas activée par défaut dans Flatcurve : le paramètre par défaut indiqué dans la documentation est fts_flatcurve_substring_search est no. Si cette fonctionnalité est activée délibérément pour répondre à des besoins de recherche IMAP spécifiques, il convient de prévoir un espace de stockage supplémentaire pour l'index. Flatcurve reste ainsi une option pour les serveurs IMAP sur lesquels la recherche de messages est fréquente, mais ne constitue pas une mise à niveau obligatoire sans condition. La croissance de l’index, la surveillance et la réindexation font partie de la planification opérationnelle.

SMTPUTF8 et IMAP doivent être classés différemment UTF8=ACCEPT et IMAP4rev2. Les notes de mise à jour précisent que ces fonctionnalités sont expérimentales. SMTPUTF8 et UTF8=ACCEPT créer une version avec --enable-experimental-mail-utf8 puis mail_utf8_extensions = yes dans la configuration. IMAP4rev2 utilise des commutateurs distincts : lors de la compilation, --enable-experimental-imap4rev2 nécessaire, puis il faut imap4rev2_enabled = yes être configuré.

Le terme « expérimental » ne signifie pas ici que la fonctionnalité soit globalement inadaptée. Il s'agit plutôt d'une norme qui ne s'applique pas de manière générale à toutes les offres d'hébergement. Avant de l'activer, les opérateurs doivent vérifier si les clients de messagerie utilisés, l'ensemble de la chaîne de distribution et les systèmes associés ont réellement besoin du traitement UTF-8 ou IMAP4rev2 souhaité et s'ils sont capables de le prendre en charge. Les tests doivent être effectués dans un environnement reproduisant de manière adéquate l’authentification réelle, les noms de boîtes aux lettres et les profils de clients.

Les mécanismes SCRAM, le « TLS Channel Binding » ainsi que le traitement avancé des en-têtes SNI et ALPN de TLS méritent également une évaluation distincte. Ils ne concernent pas seulement le processus Dovecot, mais aussi l'interaction avec les clients, les certificats, les proxys et les sources d'authentification. Le critère pertinent est un besoin clair assorti d’une compatibilité vérifiable, et non la simple disponibilité d’une nouvelle option dans une version de Dovecot.

Préparer systématiquement la mise à jour vers la version 2.4

La mise à niveau de Dovecot 2.3 vers la version 2.4 commence par un état des lieux, et non par le gestionnaire de paquets. Recensez la version du logiciel installée, la configuration en vigueur et le format des boîtes aux lettres, par exemple Maildir ou mdbox. Documentez également les sources d'authentification, les règles Sieve, les quotas, la recherche en texte intégral, la réplication ainsi que les proxys en amont. C'est la seule façon de déterminer quels services et chemins d'accès aux données sont réellement concernés par la migration.

Les commandes suivantes permettent d'effectuer un inventaire en lecture seule. Elles ne modifient ni la configuration ni les données de messagerie ; leurs résultats doivent néanmoins être affichés dans un espace de travail sécurisé, car ils peuvent permettre de tirer des conclusions sur l'environnement du serveur.

Terminal
dovecot --version
doveconf -n

dovecot --version indique l'état du programme. Avec doveconf -n vous vérifiez la configuration effective qui s'écarte des valeurs par défaut. L'option -v à partir de doveadm Il ne s'agit en revanche pas d'une requête de version, mais d'une option qui active un affichage plus détaillé, incluant une barre de progression, et qui ne s'applique qu'à une sous-commande correspondante. Traitez les informations de configuration de manière confidentielle : elles peuvent contenir des noms d'hôtes, des structures de répertoires, des adresses de backend ou d'autres détails relatifs à l'infrastructure. Pour l'analyse des erreurs, la documentation Dovecot recommande d'utiliser une configuration réduite plutôt qu'un dump public complet.

Vérifie également si la version actuelle est déjà la dernière version 2.3 disponible. La procédure de migration documentée mène d'abord à cette version, puis à la version 2.4. Ne transférez pas la configuration directement vers un système de production, mais vers un système de test comportant des comptes, des autorisations et des tailles de boîtes aux lettres représentatifs. Comme pour un Mise à jour du noyau pour les serveurs d'hébergement Ici aussi, le numéro de version ne suffit pas à lui seul : la configuration du paquet, les modules activés et l'architecture déterminent l'impact concret.

Planifier la migration de la version 2.3 à la version 2.4

La migration vers la version 2.4 constitue une étape de configuration à part entière. Dovecot 2.4 nécessite une syntaxe adaptée ainsi que dovecot_config_version et dovecot_storage_version; la version de configuration doit correspondre au premier paramètre dans dovecot.conf . Ne reprenez donc pas les anciens fichiers tels quels. Comparez chaque paramètre utilisé avec la documentation de migration spécifique à la version et validez-le dans l'environnement de test avant de planifier une fenêtre de maintenance.

Points clés de la migration de Dovecot 2.3 vers Dovecot 2.4
DomaineModification apportée à la section 2.4Approche possibleVérification avant la migration
Configuration de baseIndications de version et syntaxe modifiée requisesRéviser la configuration pour la version 2.4Vérification du parseur et lancement du test
DirecteurL'architecture Dovecot Director a été suppriméePour les petits environnements, il est possible de tester Lua Director ; la documentation précise toutefois qu’il n’est pas pris en charge. Dans Dovecot Pro, l’ancien rôle « Director » est remplacé par Palomar.Évaluer séparément le routage, les scénarios de panne et la responsabilité de l'exploitation
RéplicateurComposant suppriméEnvisager NFS ou un autre système de fichiers partagé comme approche architecturaleTester les accès à la mémoire, le basculement et les processus de cohérence
commande dsyncLe lien symbolique dsync a été suppriméPersonnaliser les processus de synchronisation ou de migration planifiés à l'aide de doveadm sync ou doveadm backupVérifier les appels de commande et les valeurs de retour au cours du test
quota-dict et quota-dirsizeSuppression des backends de quotasEnvisager « quota-count » comme alternative possibleCalcul des quotas et vérification des cas limites
fts-lucene et fts-squatBackends de recherche supprimésÉvaluer fts-flatcurve ou SolrTester la recherche, la création d'index et les besoins en mémoire

Le tableau ne propose aucune solution de remplacement. Le Director et le Replicator supprimés remplissent des fonctions différentes : selon la documentation, Lua Director n'est qu'une solution non prise en charge destinée aux petits déploiements, tandis que Replicator est présenté comme une approche basée sur un système de fichiers partagé. doveadm sync est en revanche le successeur de celui qui a été destitué dsync- des liens symboliques et peut être utilisé pour des processus de synchronisation ou de migration planifiés de manière ciblée ; il ne s'agit donc pas d'un remplacement « prêt à l'emploi » documenté pour Director ou Replicator.

En matière de quotas et de recherche, c'est également la base de données disponible qui est déterminante. Compatibilité Cela ne signifie pas seulement que Dovecot doit démarrer : les alertes de quota, les actions Sieve, les recherches IMAP et les accès de plusieurs clients doivent fonctionner avec des comptes de test réalistes. Pour chaque composant supprimé, notez où il est configuré, quelles données il utilise et comment procéder en cas de retour en arrière. Ce n’est qu’ensuite qu’il sera possible de planifier judicieusement la migration des paquets.

Évaluer de manière ciblée les formats de recherche et de stockage

Dans Dovecot 2.4, le code source, la configuration et les données de stockage peuvent être développés de manière délibérément séparée. Augmenter dovecot_storage_version uniquement lorsqu'une réversion vers une version antérieure de Dovecot n'est plus prévue. Avec la version 2.4.5 de Storage, l'index de thread utilisé pour la commande IMAP THREAD un nouveau format v2. Les index de fils existants seront recréés lors du prochain threading ; cela peut entraîner un surcroît de travail lors de la première requête, en particulier pour les boîtes aux lettres volumineuses.

Une ancienne version de Dovecot ne prend pas en charge ce format d'index de thread et recrée l'index dans l'ancien format. Le Niveau de stockage Il s'agit donc d'une décision opérationnelle, et non d'une simple modification cosmétique de la version. Prévoyez d'éventuelles restructurations d'index dans une fenêtre temporelle surveillée et ne les effectuez pas en même temps que d'autres modifications difficiles à annuler concernant la recherche, le stockage ou la topologie du proxy.

Approches de recherche dans l'environnement Dovecot selon le modèle d'exploitation
ApprocheLieu d'indexationinfrastructures complémentaireslimite d'utilisationgamme de produits
Pas de système de transport sans conducteur (FTS)Pas d'index de rechercheAucuneLes recherches dans le texte et dans le corps du document s'effectuent de manière séquentielleDovecot CE
fts-flatcurvePar boîte aux lettres dans le chemin d'indexation de DovecotXapian à partir de la version 1.4Planifier le stockage local des index, la surveillance et la réindexation ; la recherche par sous-chaîne est désactivée par défautDovecot CE
SolrService de recherche distinctFonctionnement de SolrGérer les services supplémentaires et leur disponibilitéDovecot CE
Dovecot Pro FTSConçu pour le stockage objetEnvironnement ProÀ ne pas confondre avec CE-FlatcurveDovecot Pro

Pour les index de recherche locaux, fts-flatcurve une option disponible si l'environnement fournit Xapian 1.4 ou une version plus récente. Le pilote stocke les données d'index par boîte aux lettres dans le chemin d'index Dovecot et prend en charge l'évaluation de la pertinence. Les recherches par sous-chaîne peuvent être activées ; elles sont configurées avec fts_flatcurve_substring_search = no Elles sont toutefois désactivées par défaut et, une fois activées, nécessitent nettement plus d'espace de stockage pour les index. Flatcurve ne prend pas en charge la recherche floue.

Évalue donc la Architecture de recherche en fonction de la taille des boîtes aux lettres, du type de stockage et du modèle d'exploitation, plutôt que selon un classement forfaitaire. doveadm fts flatcurve stats fournit les données d'état enregistrées concernant les indices Flatcurve. Il convient de distinguer cela de doveadm fts flatcurve check: Cette commande analyse les bases de données Xapian et tente de corriger les erreurs courantes ; elle peut donc modifier leur état. La rotation et la suppression des index font également partie des opérations de maintenance ciblées. Avant de procéder à de telles interventions, prévoyez leur ampleur, identifiez les boîtes aux lettres concernées et prévoyez une éventuelle reconstruction des index.

Vérifier les filtres, les serveurs proxy et les limites de sécurité

Les filtres Sieve constituent un point de vérification à part lors de la mise à jour de Dovecot, car cette extension ne fait pas partie du cœur de Dovecot : Sieve et ManageSieve sont fournis par le projet distinct Pigeonhole. Dans le cas d'installations compilées manuellement, Pigeonhole doit être recompilé avec la nouvelle version de Dovecot. Sinon, le plugin d'interprétation ne pourra pas se charger en raison d'un conflit de versions.

Dans le cas d'installations basées sur une distribution, il est en revanche essentiel que les paquets Dovecot et Pigeonhole proviennent de sources de paquets compatibles entre elles. Avant la fenêtre de maintenance, vérifiez quels scripts utilisateur actifs, scripts globaux et accès ManageSieve sont présents. Après la mise à jour, il convient de vérifier la distribution, le réacheminement, les réponses d'absence et toute modification effectuée via ManageSieve à l'aide d'un compte de test prévu à cet effet ; les filtres en production ne remplacent pas ce test.

Dans les architectures proxy, la Compression IMAP une attention particulière. Lorsque la version de configuration passe à 2.4.5, la valeur par défaut pour imap_compress_on_proxy yes. Le traitement de la compression est ainsi transféré au proxy ; selon la documentation, ce paramètre doit être défini au niveau du backend. Cela nécessite que les éléments suivants soient correctement définis login_trusted_networks ainsi que des limites de confiance clairement définies entre le proxy et le backend.

Une technicienne vérifie les connexions des serveurs dans un environnement compact de serveurs proxy et de messagerie.
Image illustrative générée par l'IA : les chemins de proxy et les limites de confiance font partie de la vérification des mises à jour.

Avant d'adopter la nouvelle configuration par défaut, clarifiez donc les points suivants : quelles connexions aboutissent au proxy, quelles adresses IP le backend peut-il considérer comme fiables, et sur quel système la charge CPU et le trafic liés à la compression doivent-ils être générés ? Une modification ne peut être évaluée de manière pertinente que si ces questions correspondent à l'architecture réseau réelle. Elle ne remplace ni une vérification TLS ni un contrôle d'accès fiable entre les systèmes concernés.

Les nouvelles fonctionnalités d'authentification et les protocoles expérimentaux ne devraient pas non plus être activés de manière systématique. Les informations relatives à cette version mentionnent les mécanismes SCRAM, notamment le TLS Channel Binding, ainsi que SMTPUTF8, IMAP UTF8=ACCEPT et IMAP4rev2. SMTPUTF8 et UTF8=ACCEPT sont nécessaires lors de la compilation --enable-experimental-mail-utf8 et dans la configuration mail_utf8_extensions = yes. Par ailleurs, IMAP4rev2 utilise le commutateur de compilation --enable-experimental-imap4rev2 et imap4rev2_enabled = yes au préalable. Vérifie la prise en charge par les clients, la chaîne de livraison et le comportement en cas de défaillance pour chaque fonction individuellement avant de l'intégrer dans le Hébergement d'e-mails proposes.

Fonctionnement en toute sécurité après la mise à jour

Une mise à jour n'est considérée comme terminée qu'après des vérifications techniques, et non pas simplement après la réussite du transfert des paquets. Pendant la fenêtre de maintenance, vérifiez d'abord si le service démarre et si les journaux indiquent des erreurs de configuration, de plugin ou d'autorisation. Procédez ensuite à la connexion et à l'accès à la boîte aux lettres à l'aide d'un compte test. Vérifie au minimum la liste des dossiers, la sélection des messages, la lecture et une remise contrôlée, afin de t'assurer que le serveur IMAP est non seulement accessible, mais aussi opérationnel.

Vérifiez que le filtrage et la gestion des quotas fonctionnent indépendamment l’un de l’autre. Une connexion IMAP réussie ne prouve ni que Pigeonhole a été chargé, ni que les limites de quota sont correctement déterminées. Testez donc une règle de filtrage inoffensive et une livraison proche d'une limite de quota prévue dans une boîte aux lettres de test isolée. Cela permet de détecter les erreurs au niveau des plugins, des autorisations et de la connexion au backend de quota correspondant, sans surcharger intentionnellement les boîtes aux lettres des clients.

Lorsque la recherche en texte intégral est activée, la surveillance de l'état de l'index et des requêtes de recherche doit être effectuée en arrière-plan. Pour obtenir un aperçu des données d'index Flatcurve existantes, utilisez doveadm fts flatcurve stats. La sous-commande check Il convient de bien distinguer cette opération : elle analyse les bases de données Xapian et tente de corriger les erreurs fondamentales ; il ne s'agit donc pas d'un diagnostic garantissant une lecture en mode lecture seule. Utilisez-le, tout comme la rotation ou la suppression d’index, uniquement dans le cadre d’une opération de maintenance planifiée pour des boîtes aux lettres spécifiques, et tenez compte des éventuels changements d’état ainsi que d’une nouvelle création d’index.

En cas de proxys en amont, tu contrôles également l'ensemble du voie de circulation: La connexion parvient-elle au backend prévu, l'adresse IP du client et le réseau de confiance sont-ils gérés correctement, et aucun problème inattendu de compression ou de TLS ne survient-il ? Pour le vérifier, comparez les journaux des composants concernés dans le temps. Quelques connexions réussies ne suffisent pas lorsque plusieurs backends, différents réseaux clients ou des terminations TLS distinctes sont impliqués.

Pour le dépannage, la documentation Dovecot recommande une configuration allégée. Pour ce faire, dans un environnement sécurisé, réduisez progressivement la configuration jusqu’aux composants qui reproduisent l’erreur, plutôt que de publier l’intégralité de la configuration de production. Avertissement : Les informations telles que la configuration effective peuvent contenir des détails relatifs à l'infrastructure ou des données sensibles. Ne les partagez donc pas dans leur intégralité dans les tickets, sur les forums ou dans des documents publics, mais expurgez-les de manière ciblée.

Quand est-il judicieux de mettre à jour Dovecot ?

La mise à jour de Dovecot vers la version CE 2.4.5 ne se résume pas à un simple choix en matière de fonctionnalités et d'architecture. Les notes de mise à jour mentionnent de nombreuses correctifs de sécurité critiques qui concernent notamment les commandes IMAP, la fonction « Submission », les vérifications OAuth, dsync, l'authentification et la compression. Les administrateurs devraient donc vérifier sans tarder si leur installation est concernée et à quelle version de paquet ou de backport la distribution utilisée fournit les correctifs. La version en amont ne permet pas à elle seule de conclure qu’un paquet de distribution n’est pas corrigé, ni qu’une mise à jour immédiate générique serait sûre sans vérification de la migration.

Outre cette évaluation de sécurité, une mise à jour peut se justifier si elle répond à un besoin de compatibilité, à une exigence opérationnelle concrète ou à une modernisation vérifiable par des tests. Cela peut notamment concerner les commutateurs de version contrôlables pour la configuration et le stockage. Cependant, l'état d'un logiciel ne suffit pas à lui seul à prendre une décision : le format de la boîte aux lettres, l'authentification, le quota, Sieve, la recherche et la topologie du proxy déterminent l'ampleur réelle de l'effort de migration.

La priorité à donner à une installation sous la version 2.3 se justifie tout particulièrement lorsque la situation en matière de sécurité et la version de distribution disponible recommandent une mise à jour et que la migration peut être testée dans un environnement de test. À cet égard, le niveau de stockage reste délibérément prudent : les nouveaux formats de stockage ne devraient être activés que lorsqu’un retour vers des versions antérieures de Dovecot n’est plus prévu. Cela concerne notamment l’index des threads modifié dans la version 2.4.5, dont la reconstruction s’effectue lors de la prochaine requête de threading.

Les fonctionnalités supplémentaires relèvent de choix architecturaux distincts. Flatcurve Il convient d'en évaluer la pertinence lorsque la recherche d'actualités est utilisée régulièrement et que le stockage local des index, la dépendance à Xapian, la surveillance et la réindexation s'inscrivent dans le modèle d'exploitation. La documentation classe ce pilote parmi les index de recherche en texte intégral locaux basés sur Xapian ; il n’en découle donc aucune recommandation générale en faveur de Solr ou contre l’utilisation de la recherche en texte intégral.

Les options expérimentales UTF8 et IMAP4rev2 ne se justifient qu'en cas de besoin avéré tout au long de la chaîne complète, depuis le client de messagerie jusqu'à la soumission ou la distribution, en passant par l'accès IMAP. Sans cette condition préalable, leur activation ne fait qu'alourdir la charge de vérification. Il en va de même pour les nouveaux mécanismes d'authentification : une fonctionnalité disponible dans la version ne remplace pas la vérification des clients utilisés, de la configuration TLS et de la source d'authentification.

En ce qui concerne Dovecot 3, les informations publiées par la CE ne permettent pas de donner de date, ni de liste des fonctionnalités, ni de plan de migration. La version stable confirmée est la CE 2.4.5 ; les indications figurant dans la documentation de développement ou dans la branche main Il ne s'agit ni d'une version officielle du produit ni d'une feuille de route. Prévoyez donc en vous basant sur la version 2.4 effectivement disponible, distinguez-la de Dovecot Pro et n'évaluez les annonces ultérieures qu'une fois qu'elles auront été officiellement publiées.

Sources et état des connaissances

État de la recherche :

État des recherches : 21 octobre 2026. Dovecot CE 2.4.5 est la version stable mentionnée dans les sources officielles disponibles. Aucune feuille de route publiée pour la version CE 3.0 n'a été trouvée.

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

Derniers articles

Petite armoire réseau installée dans un local technique d'occasion, symbolisant la protection des services Linux accessibles
Sécurité

Alternatives à Fail2Ban pour les serveurs Linux modernes

CrowdSec, SSHGuard et nftables adoptent des approches de protection différentes. Les facteurs déterminants sont la surface d'attaque, les sources de journaux, le niveau d'application et la charge opérationnelle supportable à long terme.

Une personne vérifie le mini-PC et le routeur pour s'assurer qu'un tunnel sortant est accessible.
informatique en nuage

Cloudflare Tunnel comme alternative à l'ouverture de ports

Cloudflare Tunnel permet d'accéder aux applications web internes et à certains services d'administration sans avoir à ouvrir de ports entrants. Les règles d'accès, l'authentification multifactorielle (MFA), les droits d'accès locaux et une limite claire en matière de journalisation restent toutefois essentiels.

Une personne vérifie une carte réseau sur un serveur ouvert afin de s'assurer qu'elle suit un chemin de transmission de paquets spécifique.
Technologie

DPDK : bien planifier le traitement des paquets dans l'espace utilisateur

DPDK traite les paquets pour certaines cartes réseau directement dans l'espace utilisateur. Cet article explique le polling, la gestion des files d'attente et la planification NUMA, la liaison sécurisée aux périphériques, ainsi que la distinction par rapport à AF_XDP et à la pile du noyau Linux.