Changements incompatibles
Passer de Dovecot 2.3 à 2.4 sur Debian Stable
- Publié
- Mis à jour
- (créé )
- Écrit par
- Willem L. Middelkoop
- Sujets
- données · linux · serveur · travail
- Version humaine de cet article
- https://willem.com/fr/2025-06-04_changements-incompatibles/
- English
- Breaking Changes
- Nederlands
- Brekende Wijzigingen
- Deutsch
- Änderungen mit Unterbrechungen
- Español
- Cambios importantes
- Italiano
- Modifiche incompatibili
- Português
- Alterações incompatíveis
- Papiamentu
- Breaking Changes
- Frysk
- Brekkende feroaringen
- Langues
- Traduit de l’original anglais par un modèle de langage en deux passes (traduction et relecture) avec un glossaire et un correcteur orthographique ; pas encore relu par un lecteur de langue maternelle.
Résumé
La semaine dernière, j'ai eu un problème inattendu pendant une opération de maintenance de routine sur l'infrastructure e-mail de mon entreprise. Nous traitons des milliers d'e-mails par jour et nous utilisons Dovecot pour donner à nos clients accès à leurs messages. Tout s'est arrêté net quand je suis passé à la version 2.4, qui apporte des changements incompatibles… aïe !
Texte intégral
⚠️ TL;DR : passer de Dovecot 2.3 à 2.4 sur Debian
- Dovecot 2.4 introduit des changements incompatibles : les fichiers de configuration de la 2.3 ne fonctionnent plus. Le logiciel refuse de démarrer tant que tu ne les as pas réécrits.
- Nouvelle syntaxe de configuration et nouveau système de variables : des paramètres comme `ssl_cert`, `mail_location` et `%d` ont changé de format et de sens.
- Aucun chemin de migration automatique : il faut relire et réécrire la configuration à la main, surtout si tu utilises des backends SQL, Sieve ou une authentification personnalisée.
- Recommandation : lis attentivement le guide de mise à jour officiel avant de te lancer, et teste tes configurations de façon isolée.
Une promenade de santé
Pour appliquer quelques mises à jour de sécurité en attente et régler des problèmes de compatibilité, j'ai décidé de mettre à jour quelques paquets sur un serveur Debian GNU/Linux qui gère les services e-mail de mon entreprise. Cette distribution de GNU/Linux est connue pour sa stabilité et sa fiabilité. Rien ne laissait présager un souci et j'ai lancé la mise à jour en pensant que ce serait fini en quelques minutes. Une simple « promenade de santé », qu'est-ce qui pouvait mal tourner ?
Exigence de « dovecot_config_version »
Presque tout le serveur est revenu en ligne comme prévu, quasi immédiatement, en perturbant si peu les services que même l'alarme de surveillance de disponibilité n'a détecté aucune panne. Sauf pour Dovecot. Ce logiciel s'occupe de l'accès IMAP et POP3 aux boîtes aux lettres. Il s'insère comme un rouage finement réglé dans un ensemble où d'autres programmes, comme Postfix, comptent sur lui pour accepter les e-mails entrants. Que Dovecot ne démarre pas a provoqué toute une série de problèmes.
Le premier réflexe d'un administrateur de serveur, c'est de vérifier les démons du serveur (« systemctl status dovecot »), puis de consulter les journaux, par exemple avec « journalctl -u dovecot ». Cela a vite montré que Dovecot refusait de démarrer parce qu'un paramètre de configuration manquait : « dovecot_config_version ».
Il suffit d'ajouter le paramètre dans le fichier de configuration « /etc/dovecot/dovecot.conf », penses-tu peut-être ? Eh bien… NON. Les créateurs de Dovecot ont mis cette erreur pour une bonne raison : la nouvelle version 2.4 est incompatible avec les anciens fichiers de configuration de la 2.3, ce qui veut dire qu'il faut réécrire de nombreux paramètres. Ce ne sont pas seulement les noms des variables de configuration : il y a aussi une toute nouvelle syntaxe pour l'expansion des variables de réglages. Une ancienne valeur comme « %d » devient maintenant « %{user | domain} ». La liste des changements est longue et il n'existe aucun moyen automatique de migrer ta configuration. Imagine ma tête quand j'ai mesuré l'ampleur de mon problème.
Une complexité intégrée : des rouages dans une machine
Le truc avec les services e-mail, c'est que c'est difficile. Pas parce qu'un seul composant serait compliqué, mais parce que pour faire tourner une pile e-mail complète, il faut de nombreuses pièces qui fonctionnent ensemble sans accroc. Voici quelques-unes des pièces qui composent le service e-mail de mon entreprise :
- Postfix : l'agent de transfert de courrier (MTA) SMTP principal. Il dialogue avec les autres serveurs de messagerie pour recevoir et envoyer des e-mails. Il doit savoir quelles adresses sont valides pour recevoir du courrier et qui a le droit d'envoyer de nouveaux messages.
- Filtre Amavis : tous les e-mails traités par le serveur passent par le mécanisme de filtrage d'Amavis, qui vérifie chaque message avec SpamAssassin et ClamAV.
- SpamAssassin : avec un ensemble complexe de règles et des analyses bayésiennes, les messages sont analysés automatiquement pour estimer la probabilité que ce soit du spam.
- ClamAV : les messages sont analysés à la recherche de virus. Les pièces jointes sont extraites et examinées, fichier par fichier.
- Listes noires DNS inversées : en plus d'analyser les messages, le serveur de messagerie vérifie aussi les serveurs externes avec lesquels il communique. Les en-têtes sont analysés et la réputation de chaque saut est contrôlée.
- OpenDKIM : certains messages portent une signature par « clé de domaine » qui prouve que leur expéditeur est autorisé. Les messages avec en-têtes sont vérifiés, les autres sont signés par un service de filtrage (milter) branché sur Postfix.
- Sieve : les messages entrants sont triés automatiquement avec des règles par utilisateur, par exemple pour livrer certains messages dans des dossiers précis. Il doit savoir quelles règles s'appliquent à quelles adresses.
- MariaDB / MySQL : les adresses e-mail, les identifiants valides, les noms d'utilisateur, les empreintes de mots de passe et les alias sont stockés dans une base de données centralisée. Des requêtes SQL précises sont configurées pour vérifier des choses comme « ce mot de passe est-il valide ? »
- Nginx : le serveur de messagerie a aussi un serveur web qui permet de gérer les comptes et d'accéder aux e-mails par webmail.
- NodeJS : la console de gestion utilise un backend NodeJS qui permet aux administrateurs du serveur et aux clients de configurer leurs adresses et leurs mots de passe.
- Roundcube : le serveur utilise un programme de webmail très répandu pour que les clients accèdent à leurs e-mails depuis le navigateur.
- PHP : le webmail a besoin de PHP pour tourner, avec quelques dépendances pour dialoguer avec Dovecot (via IMAP) et MariaDB (via SQL).
- Dovecot : et puis il y a Dovecot, le logiciel qui permet réellement aux utilisateurs finaux d'accéder à leurs e-mails. Il donne aux utilisateurs authentifiés l'accès aux e-mails stockés sur les disques de l'infrastructure, avec des protocoles comme IMAP ou POP3.

Ces pièces sont toutes finement réglées les unes sur les autres : comme les rouages d'une machine complexe, elles s'emboîtent avec précision. Leur configuration est adaptée à leur rôle, et elles dialoguent souvent avec plusieurs autres pièces. Tu devines qu'un changement inattendu dans l'un de ces rouages (comme Dovecot) peut tout dérégler !
Il n'y avait pas de solution rapide, pas de mise à niveau automatique de la configuration. Comme cette mise à jour était assez récente, la plupart des grands modèles de langage (IA) n'avaient pas de réponse non plus. ChatGPT proposait simplement des suggestions tirées de l'ancienne documentation 2.3. Pour résoudre le problème, j'ai dû faire appel à mes « compétences de serveur Linux à l'ancienne » : créer à la main une nouvelle configuration sur mesure pour Dovecot 2.4.
S'arrêter pour éviter la perte de données
Dès que j'ai saisi la nature du problème, j'ai tout de suite arrêté la plupart des services e-mail (autrement dit, coupé complètement le moteur). Cela évite la perte de données, puisque les e-mails ne sont plus traités. Les autres serveurs de messagerie mettent alors les e-mails en file d'attente, en renvoyant parfois des erreurs SMTP 4xx (comme 421, 451, 454 ou 455). Le protocole mondial du courrier électronique a été conçu pour tolérer les pannes temporaires, et les autres serveurs réessaieront simplement plus tard.
Réécrire la config en lisant le manuel (RTFM)
Le message d'erreur dans les journaux m'a renvoyé vers la documentation officielle de Dovecot, et là, c'était écrit : un AVERTISSEMENT surligné en jaune qui décrit les changements de configuration. Un document long : en PDF ça fait 18 pages. Un jour ordinaire, il faudrait déjà un certain effort pour en venir à bout. Imagine devoir le faire alors que la maison brûle, comme on dit !
La configuration de Dovecot se compose de plusieurs fichiers qui règlent chacun une partie du comportement du logiciel. Par exemple la façon dont l'authentification se fait, comment il s'intègre avec un filtre Sieve, ou d'où il tire les noms d'utilisateur et les empreintes de mots de passe pour la connexion. Les changements de Dovecot 2.4 touchent presque tous les paramètres, car les créateurs ont introduit une nouvelle syntaxe pour les variables du serveur.
Syntaxe de notation des variables
Avant, la configuration utilisait une notation comme « %u » en guise d'espace réservé pour un nom d'utilisateur. La nouvelle syntaxe permet de passer les variables à un modificateur, ce qui permet la normalisation et des choses comme la sélection d'une sous-chaîne. Par exemple : pour obtenir le domaine d'une adresse à partir d'un nom d'utilisateur, tu n'utilises plus « %d », mais la variable « user » comme base que tu passes au modificateur « domain » avec cette syntaxe : « %{user | domain} ».
Une fois que j'ai compris ce nouveau langage, j'ai vraiment apprécié le travail d'orfèvre que cela représente. C'est une amélioration par rapport aux anciens noms de variables abrégés, car tu n'as plus besoin d'un dictionnaire pour les déchiffrer : au lieu d'un vague « %r », tu lis maintenant « %{remove_ip} ». C'est intrinsèquement plus lisible, et j'y tiens beaucoup.
Chiffrement : « ssl_cert » devient « ssl_server_cert_file »
Autre changement : la façon dont la config pointe vers les fichiers externes utilisés pour le chiffrement. Avant, tu avais un réglage « ssl_cert » qui pouvait contenir le certificat SSL/TLS lui-même sous forme de chaîne. Dans la version 2.4, tu as la variable « ssl_server_cert_file », qui attend à la place un chemin vers le certificat dans le système de fichiers. Ce n'est pas seulement un renommage, la nature de la valeur est nouvelle, elle aussi ! Pour corriger la configuration, tu devras passer en revue chacun de ces paramètres modifiés et déterminer leur impact sur ton installation. C'est long et sujet aux erreurs.
Le réglage « mail_location » éclaté en deux
Nouveauté de la 2.4 : « mail_location » est découpé en plusieurs variables plus petites. Avant, une seule variable définissait où les e-mails étaient enregistrés sur le disque. Tu dois maintenant la scinder en deux variables, « mail_driver » et « mail_path », ET utiliser la nouvelle syntaxe des variables du serveur. Si tu te trompes sur l'une de ces deux choses, tous les e-mails disparaissent (crois-moi !). Selon ta configuration de stockage, vérifie bien la partie du nom d'utilisateur (par exemple, inclus-tu l'adresse e-mail entière ou seulement le préfixe sans le nom de domaine ?).

Dovecot avec un backend SQL : passdb et userdb
Si ton installation Dovecot s'appuie sur une base de données (ou un magasin) externe pour authentifier les noms d'utilisateur et les mots de passe, tu devras réécrire le fichier « auth-sql.conf.ext » dans « /etc/dovecot/conf.d/ », appelé (inclus) par le fichier 10-auth.conf. Dans Dovecot 2.4, il y a une nouvelle façon de segmenter les réglages passdb et userdb. Dans mon installation Dovecot 2.3, j'utilisais un fichier externe pour fournir les requêtes de base de données et la chaîne de connexion. Pendant l'authentification, les différentes requêtes servent à 1) authentifier les utilisateurs, et 2) charger des réglages propres à l'utilisateur, comme le chemin de stockage de ses e-mails.


Dans la nouvelle version 2.4, tu dois restructurer les paramètres pour qu'ils soient regroupés dans des sections qui comportent un indicateur de type de backend juste après les mots-clés « userdb » et « passdb » dans la config. Donc, si tu utilises une base MySQL comme backend, « userdb » devient « userdb sql ». Tu peux mettre les paramètres de la chaîne de connexion directement dans le fichier « auth-sql.conf.ext », de sorte que tous les paramètres utiles sont dans un seul fichier de configuration. Pour réduire la complexité, j'ai réécrit la section userdb pour utiliser le pilote de base de données « static » : il génère les variables de configuration, comme le chemin de stockage des e-mails de l'utilisateur, à partir de son nom d'utilisateur. Voir les documents dédiés.

Plugin Sieve
Si ton installation utilise Sieve pour trier les e-mails entrants, tu devras adapter ta configuration en ce qui concerne l'emplacement des scripts, leurs valeurs par défaut et leur comportement. La nouvelle version 2.4 de Dovecot introduit un concept appelé « Script Storage », qui permet d'exécuter des scripts chargés dynamiquement pour différents utilisateurs lors de divers événements. Chez nous, il y a un simple script sieve par défaut qui trie automatiquement les e-mails marqués comme spam dans un dossier appelé Spam. La nouvelle syntaxe permet une config plus compacte :


Tester la nouvelle config
Tu pourrais être tenté de simplement redémarrer le serveur après avoir redéfini la configuration 2.4. Mais fais très attention : une mauvaise configuration pourrait faire perdre aux clients l'accès à tous leurs e-mails et/ou les forcer à télécharger de nouveau l'intégralité de leurs boîtes aux lettres. J'ai donc choisi une approche progressive : j'ai remplacé les numéros de port IMAP (et POP3) par des valeurs arbitraires. Comme ça, je pouvais tester seul la nouvelle installation tout en empêchant les vrais clients de se connecter au serveur. Cela m'a permis de corriger quelques fautes de frappe, d'affiner une partie de la nouvelle syntaxe des variables du serveur et de traiter des messages de journal étranges. Tu peux contrôler les numéros de port du serveur depuis le fichier « 10-master.conf ».

Conclusion
Des pannes comme celle-ci sont rares, grâce à la stabilité de Debian GNU/Linux, mais pas impossibles. Pour le service e-mail Lemmid Online de mon entreprise, il y a des sauvegardes quotidiennes et un plan de reprise après sinistre testé. Même si un basculement complet n'a pas été nécessaire cette fois, les exercices précédents se sont avérés décisifs pour adapter rapidement la configuration.
Cet incident m'a rappelé que, même avec l'automatisation et l'IA, la connaissance approfondie des systèmes, la préparation et le débogage manuel restent des outils essentiels quand des composants critiques de l'infrastructure changent sans prévenir et sans chemin de migration automatique.
Exemple de config Dovecot 2.4
Si tu es tombé sur cet article en cherchant une solution pour ton propre serveur de messagerie en panne, ces fichiers de config d'exemple pour Dovecot 2.4 te seront peut-être utiles. Je les ai trouvés pendant ma propre réparation, et ils peuvent te faire gagner du temps pour comprendre la nouvelle syntaxe : https://source.willem.com/dovecot-2.4-sample-config/