Migration e-mail : déplacer la messagerie vers un nouveau serveur avec un temps d’arrêt minimal (étapes réelles)

Ce que signifie vraiment « temps d’arrêt minimal »

Pour la messagerie, le « temps d’arrêt » n’est pas un interrupteur unique. La livraison SMTP est du store-and-forward : les serveurs distants réessaieront pendant des heures ou des jours si votre serveur est indisponible. L’IMAP est avec état : les clients gardent des connexions ouvertes et mettent en cache des identifiants de boîte. Le DNS est mis en cache : votre changement d’MX « instantané » peut prendre un jour chez certains expéditeurs.

Donc l’objectif n’est pas « aucune perturbation ». C’est une perturbation contrôlée :

• Pas de mail perdu. Le délai est acceptable ; la perte est un événement limitant la carrière.
• Fenêtre courte où les écritures sont mono-hébergement. Pendant la bascule, le nouveau courrier doit atterrir sur un seul serveur. Tout le reste est une source d’erreurs.
• Comportement client prévisible. Les points de terminaison IMAP/Submission et les certificats doivent rester stables pour éviter la révolte des clients.
• Un rollback qui n’exige pas de prière. Le rollback doit être « remettre l’MX en place et réactiver l’entrée », pas « reconstruire l’ancien serveur depuis les cendres ».

Le schéma de migration qui fonctionne en production est la réplication en deux passes :

1. Synchronisation initiale pendant que l’ancien serveur est actif.
2. Gel court (ou double remise contrôlée) pendant la bascule, puis synchronisation finale.

Vous ne migrez pas « l’e-mail ». Vous migrez les boîtes aux lettres, les identités, la réputation cryptographique et un tas d’hypothèses opérationnelles.

Quelques faits (et éléments d’histoire) qui changent les décisions

1. SMTP est plus ancien que la plupart de vos outils. SMTP a été normalisé au début des années 1980 et suppose encore une connectivité intermittente et des réessais. Voilà pourquoi votre bascule peut être indulgente si vous gérez correctement les files.
2. Les enregistrements MX n’imposent pas la livraison. Certains expéditeurs ignorent les préférences MX ou mettent fortement en cache. Vous réduisez le risque en planifiant le TTL, mais vous n’obtenez jamais un contrôle parfait.
3. Les UID IMAP ne sont pas des IDs de message. Les clients comptent sur les séquences UID par boîte et UIDVALIDITY. Si vous les réinitialisez par erreur, les clients peuvent dupliquer ou « perdre » des messages jusqu’à une resynchronisation complète.
4. Maildir vs mbox est une vraie différence opérationnelle. Maildir, c’est de nombreux fichiers ; mbox, c’est un seul fichier. Migrer mbox avec rsync peut sembler « terminé » alors qu’il y a corruption d’état sous écritures concurrentes.
5. DMARC a changé la donne du simple « changer d’IP ». La délivrabilité moderne repose sur la réputation plus l’alignement (SPF et DKIM). Vous pouvez casser l’acceptation chez les destinataires même si votre serveur est sain.
6. Le greylisting est encore présent. Les nouveaux expéditeurs se voient parfois différer intentionnellement. Pendant la bascule, une nouvelle IP et une réputation froide peuvent entraîner plus de différés et un courrier plus lent.
7. TLS sur SMTP est devenu courant grâce au chiffrement opportuniste. La plupart des serveurs retomberont volontiers en clair si mal configurés — sauf si une politique l’impose. Votre migration peut réduire la sécurité sans que personne ne le remarque.
8. Les gros fournisseurs ont leurs propres règles. Certains destinataires maintiennent une réputation interne par IP d’envoi et par domaine ; déplacer les serveurs peut ressembler à « nouvel expéditeur » même si votre domaine est ancien.

Décider ce que vous migrez : SMTP, IMAP, auth et stockage

Choisissez la cible avant de toucher aux données

Un serveur mail n’est pas un seul démon. C’est un petit écosystème :

• SMTP entrant (port 25) : généralement Postfix. Reçoit le courrier pour vos domaines et applique la politique.
• Submission (587/465) : envoi authentifié pour les utilisateurs ; doit exiger TLS et authentification.
• IMAP/POP : typiquement Dovecot. C’est là que la douleur côté client survient.
• Auth : utilisateurs locaux, LDAP, SQL, passerelles type OAuth. Migrer l’authentification de façon incorrecte, c’est le réveil à 02:00.
• Analyse de contenu : rspamd/Amavis/ClamAV. Optionnel, mais beaucoup d’organisations en dépendent sans l’admettre.
• Signature DKIM : OpenDKIM/rspamd. Les clés doivent survivre au déplacement.
• Stockage : système de fichiers + quotas + sauvegardes + snapshots. C’est là que vous aurez soit un succès ennuyeux soit une histoire que les gens racontent.

Cessez de présumer que DNS se limite au MX

Pour une bascule propre, vous toucherez généralement :

• A/AAAA pour mail.example.com (point de terminaison IMAP/submission)
• MX pour example.com
• SPF TXT : autoriser les nouvelles IP d’envoi
• DKIM TXT : assurer que le nouveau serveur signe avec le même sélecteur/clé, ou publier d’abord la nouvelle clé
• DMARC TXT : alignement et politique ; ne resserrez pas la politique la semaine de la migration
• Reverse DNS (PTR) pour la nouvelle IP : de nombreux destinataires notent l’absence

Une citation sur la fiabilité, parce que c’est vrai

L’espoir n’est pas une stratégie. — souvent cité dans les équipes d’ingénierie ; utilisez-le comme idée paraphrasée si vous préférez. En tout cas, construisez le rollback.

Blague #1 : Le courrier est le seul produit où « il a fini par être livré » est à la fois critère de succès et modèle de menace.

Préparation avant migration qui compte réellement

1) Choisissez l’identité qui ne changera pas

Pour un temps d’arrêt minimal, conservez des noms d’hôtes visibles par les clients stables. Utilisez mail.example.com pour IMAP/submission et changez simplement l’IP derrière. Ne changez pas les noms d’hôtes et les certificats pendant la même fenêtre de maintenance, sauf si vous aimez les tickets de support.

2) Baissez les TTL DNS tôt (et confirmez)

Les changements de TTL n’aident que s’ils ont le temps de se propager avant la bascule. Abaissez-les au moins 24–48 heures avant pour :

• MX des domaines
• mail.example.com A/AAAA

Utilisez un TTL comme 300 secondes temporairement. Puis restaurez des TTL raisonnables plus tard (3600–14400) après stabilisation.

3) Décidez : rsync, dsync ou export/import ?

Si vous utilisez Dovecot et IMAP, Dovecot dsync est généralement le plus sûr car il respecte les métadonnées des boîtes et peut faire des synchronisations incrémentales proprement. Pour Maildir pur, rsync peut fonctionner, mais seulement si vous comprenez ce que signifient les « changements en cours ».

4) Planifiez la fenêtre de gel des mails

La bascule la plus propre est :

• Arrêter le SMTP entrant sur l’ancien serveur (ou rejeter temporairement avec un 4xx différé).
• Vider les files et assurer que tout nouveau courrier arrive sur le nouveau serveur.
• Synchronisation finale de l’ancien vers le nouveau pour les derniers changements de boîtes.

Cette fenêtre de gel peut durer 5–30 minutes si vous avez fait la synchronisation initiale plus tôt.

5) Ne migrez pas un bazar ; prenez un snapshot

Si votre stockage supporte les snapshots (ZFS, LVM, snapshots système de fichiers), prenez-les. Pouvoir revenir à l’état des boîtes fait la différence entre « oups » et incident.

Tâches concrètes avec commandes : vérifier, répliquer, valider, décider

Ce ne sont pas des commandes « jouet ». Ce sont celles que vous exécutez réellement lors de la migration d’un système mail de production. Chaque tâche inclut : commande, ce que la sortie signifie et la décision à prendre.

Task 1: Inventory listening services (old and new)

cr0x@server:~$ sudo ss -lntp | egrep ':(25|465|587|993|143)\b'
LISTEN 0      100          0.0.0.0:25        0.0.0.0:*    users:(("master",pid=1123,fd=13))
LISTEN 0      100          0.0.0.0:587       0.0.0.0:*    users:(("master",pid=1123,fd=14))
LISTEN 0      128          0.0.0.0:993       0.0.0.0:*    users:(("dovecot",pid=1402,fd=40))

Sens : Confirme que Postfix master est lié pour SMTP/submission et Dovecot pour IMAPS. Les ports manquants signifient que les clients échoueront ou que l’entrée entrante n’arrivera pas.

Décision : Si le nouveau serveur n’écoute pas les bons ports, arrêtez. Corrigez le pare-feu/unités de service avant de synchroniser les données ou toucher au DNS.

Task 2: Confirm DNS TTLs (what you think you set vs reality)

cr0x@server:~$ dig +nocmd +noall +answer MX example.com
example.com.  300 IN MX 10 mail.example.com.

Sens : TTL 300 est faible. Bon pour l’agilité de la bascule. Si vous voyez encore 3600/86400, vous êtes venu trop tard.

Décision : Si les TTL sont élevés et que la bascule est proche, planifiez une fenêtre de coexistence plus longue et laissez l’ancien serveur recevoir plus longtemps.

Task 3: Verify name resolves consistently (A/AAAA)

cr0x@server:~$ dig +short A mail.example.com
203.0.113.10

Sens : Montre l’IP que les clients toucheront pour IMAP/submission (si vous utilisez ce nom d’hôte). Dual-stack ? Vérifiez aussi AAAA.

Décision : Si A/AAAA ne correspond pas à votre plan, corrigez le DNS maintenant — avant de déboguer des rapports « impossible de se connecter » fantômes plus tard.

Task 4: Check TLS certificate on IMAP (clients care a lot)

cr0x@server:~$ openssl s_client -connect mail.example.com:993 -servername mail.example.com -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Peer certificate: CN = mail.example.com
Verification: OK

Sens : CN/SAN correspond au nom d’hôte ; vérification OK. Si vous voyez des erreurs de vérification, les clients peuvent afficher des avertissements ou refuser la connexion.

Décision : Corrigez la chaîne de certificats et le nom d’hôte avant la bascule. Ne dites pas « on corrigera après » ; vous ne le ferez pas.

Task 5: Confirm Postfix identity and domains (avoid accepting for wrong domains)

cr0x@server:~$ sudo postconf myhostname mydestination virtual_mailbox_domains
myhostname = mail.example.com
mydestination = $myhostname, localhost.localdomain, localhost
virtual_mailbox_domains = example.com, example.org

Sens : Vous acceptez le courrier pour les domaines souhaités comme boîtes virtuelles (configuration courante). Si mydestination inclut par erreur example.com, vous pourriez livrer localement dans des comptes système.

Décision : Corrigez le routage des domaines maintenant. Une mauvaise classification provoque une mauvaise distribution silencieuse.

Task 6: Verify mailbox format and location (Maildir vs mbox)

cr0x@server:~$ sudo doveconf -n | egrep '^(mail_location|mail_privileged_group|first_valid_uid)'
mail_location = maildir:/var/vmail/%d/%n/Maildir
first_valid_uid = 5000

Sens : Chemin Maildir et base UID. Si le nouveau serveur utilise un mail_location différent ou un mappage UID différent, les clients peuvent voir des boîtes vides ou des erreurs de permissions.

Décision : Gardez les chemins de boîtes et la stratégie UID cohérents entre serveurs sauf si vous migrez volontairement les formats (ce qui est un projet différent).

Task 7: Measure mailbox data size (so you can estimate sync time)

cr0x@server:~$ sudo du -sh /var/vmail
842G    /var/vmail

Sens : Taille approximative du stockage mail. Si c’est proche de la capacité disque du nouveau serveur, vous ne migrez pas — vous entrez dans le danger.

Décision : Assurez au moins 30–50% de marge. Les systèmes de mail grandissent et des pics surviennent (journaling, indexation, fichiers temporaires).

Task 8: Check filesystem and inode pressure (Maildir eats inodes)

cr0x@server:~$ df -h /var/vmail && df -ih /var/vmail
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1       1.8T  1.1T  680G  62% /var/vmail
Filesystem      Inodes  IUsed  IFree IUse% Mounted on
/dev/sdb1        120M   79M   41M   66% /var/vmail

Sens : Maildir peut consommer rapidement des inodes. Manquer d’inodes ressemble à « disque plein » alors que df -h semble correct.

Décision : Si l’utilisation d’inodes est élevée, choisissez un système de fichiers/ratio d’inodes adapté à des millions de petits fichiers, ou planifiez une stratégie d’archivage.

Task 9: Bulk sync Maildir with rsync (first pass)

cr0x@server:~$ sudo rsync -aHAX --numeric-ids --delete --info=stats2,progress2 /var/vmail/ root@mail-new:/var/vmail/
sending incremental file list
...
Number of files: 18,492,310 (reg: 18,491,900, dir: 310)
Total file size: 901,223,554,120 bytes
Total transferred file size: 901,223,554,120 bytes
Literal data: 210,331,112,455 bytes
Speedup is 4.28

Sens : La première passe copie presque tout. Le « literal data » et le speedup indiquent la compression et le comportement delta ; les deltas Maildir sont généralement faibles car les messages sont immuables mais nombreux.

Décision : Si les performances sont médiocres, ne « tunez » pas aveuglément. Vérifiez les IOPS disque et le réseau. Vous devrez peut-être brider, planifier hors pics ou utiliser ZFS send/receive si possible.

Task 10: Incremental sync (second pass) with rsync

cr0x@server:~$ sudo rsync -aHAX --numeric-ids --delete --info=stats2 /var/vmail/ root@mail-new:/var/vmail/
Number of files: 18,492,400 (reg: 18,492,090, dir: 310)
Number of created files: 120
Number of deleted files: 6
Total transferred file size: 87,991,230 bytes

Sens : Le delta est maintenant petit. C’est ce qu’on veut avant la bascule : une fenêtre finale courte.

Décision : Si les deltas sont encore énormes, les utilisateurs modifient activement le courrier (déplacement de dossiers, suppression). Planifiez un gel court ou utilisez dsync pour une réconciliation plus sûre.

Task 11: Dovecot dsync replication (preferred when available)

cr0x@server:~$ sudo doveadm -v dsync -u alice@example.com remote:vmail@mail-new
dsync(alice@example.com): Debug: Added connection to remote:vmail@mail-new
dsync(alice@example.com): Debug: Mailbox INBOX: GUIDs match
dsync(alice@example.com): Debug: Finished successfully

Sens : Dsync compare les GUID des boîtes et synchronise les changements en toute sécurité. « GUIDs match » rassure ; les divergences nécessitent une attention.

Décision : Si dsync signale des problèmes d’UIDVALIDITY ou de GUID, faites une pause et diagnostiquez les métadonnées de boîte avant la bascule. C’est là que naissent les doublons côté client.

Task 12: Verify Dovecot can see mailboxes on new server

cr0x@server:~$ sudo doveadm mailbox list -u alice@example.com
INBOX
Sent
Trash
Archive/2024

Sens : La hiérarchie des boîtes est présente pour un utilisateur représentatif. Si elle est vide, votre mail_location, permissions ou mappage d’authentification est incorrect.

Décision : Corrigez la structure maintenant ; ne changez pas le DNS et découvrez ensuite que tout le monde n’a « que INBOX ».

Task 13: Check permissions/ownership on migrated Maildir

cr0x@server:~$ sudo namei -l /var/vmail/example.com/alice/Maildir
f: /var/vmail/example.com/alice/Maildir
drwxr-x--- root  vmail /var
drwxr-x--- root  vmail vmail
drwxr-x--- vmail vmail example.com
drwxr-x--- vmail vmail alice
drwx------ vmail vmail Maildir

Sens : Les répertoires appartiennent à l’utilisateur/groupe mail. Si vous voyez root:root dans les répertoires de boîte, Dovecot peut renvoyer « Permission denied » et les clients verront des dossiers vides.

Décision : Corrigez avec chown -R vmail:vmail /var/vmail (avec précaution) et vérifiez que first_valid_uid/last_valid_uid correspondent.

Task 14: Validate Postfix queue state before cutover

cr0x@server:~$ sudo postqueue -p | head
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
2A1B2C3D4E*     912 Thu Jan  4 10:15:11  sender@example.net
                                         user@example.com

-- 12 Kbytes in 1 Request.

Sens : L’ancien serveur a encore du courrier en file. Une petite file est acceptable ; une file qui grossit indique des problèmes de livraison en amont.

Décision : Si la file est grande ou bloquée, enquêtez avant la bascule. Autrement vous migrez un arriéré et appelez ça « downtime ».

Task 15: Watch logs for active delivery errors (during testing)

cr0x@server:~$ sudo tail -n 30 /var/log/mail.log
Jan  4 10:21:07 mail postfix/smtpd[2201]: connect from unknown[198.51.100.77]
Jan  4 10:21:08 mail postfix/smtpd[2201]: NOQUEUE: reject: RCPT from unknown[198.51.100.77]: 450 4.7.1 Client host rejected: cannot find your hostname; from= to= proto=ESMTP helo=

Sens : Vous rejetez un expéditeur à cause d’une politique reverse DNS. Cela peut être intentionnel, mais ça vous mordra si votre politique est plus stricte que la tolérance métier.

Décision : Décidez si vous voulez être « techniquement pur » ou « recevoir du courrier ». Ajustez smtpd_client_restrictions en conséquence, surtout la semaine de bascule.

Task 16: Confirm SPF and DKIM are in place before moving sending traffic

cr0x@server:~$ dig +short TXT example.com
"v=spf1 ip4:203.0.113.10 ip4:203.0.113.20 -all"

Sens : SPF autorise temporairement les anciennes et nouvelles IP. C’est l’approche sûre pour la bascule et le rollback.

Décision : Gardez l’ancienne IP autorisée jusqu’à être sûr qu’aucun système n’envoie encore depuis elle (apps, imprimantes, relais legacy). Puis retirez-la.

Task 17: Confirm DKIM signing actually happens on the new server

cr0x@server:~$ sudo rspamc stat | egrep 'dkim|dmarc|spf'
Actions: reject: 0, add header: 120, greylist: 4, no action: 980
DKIM sign: 110
DMARC policy: 12
SPF: 940

Sens : Le compteur « DKIM sign » qui augmente indique que l’envoi sortant est signé. S’il est à zéro, vous allez avoir des problèmes de délivrabilité qui ressemblent à des « rebonds aléatoires ».

Décision : Corrigez la signature DKIM avant de déplacer le trafic sortant. La délivrabilité récupère lentement et se détruit rapidement.

Task 18: Smoke-test end-to-end mail flow (SMTP in, IMAP read)

cr0x@server:~$ swaks --to user@example.com --server mail.example.com --port 25
=== Trying mail.example.com:25...
=== Connected to mail.example.com.
<  220 mail.example.com ESMTP Postfix
>  EHLO client.local
<  250-mail.example.com
...
>  DATA
<  354 End data with <CR><LF>.<CR><LF>
>  Subject: migration test
>
>  hello
>  .
<  250 2.0.0 Ok: queued as 9F8E7D6C5B

Sens : L’acceptation SMTP fonctionne et le message est mis en file. Vous devez encore confirmer la livraison dans la boîte et la visibilité côté client.

Décision : Si SMTP accepte mais le message n’apparaît pas en IMAP, vous avez un problème de livraison/LMTP, de permissions de boîte ou de filtrage. Ne touchez pas au DNS tant que vous n’avez pas compris pourquoi.

Listes de contrôle / plan étape par étape (migration en deux passes)

Phase 0 : Contraintes et rollback (écrivez-les)

• Définir la fenêtre de maintenance et qui est de garde pour DNS, mail et stockage.
• Décidez votre déclencheur de rollback : par ex. « taux d’erreur de réception > X pendant Y minutes », ou « échec généralisé d’authentification IMAP ».
• Conservez l’ancien serveur intact et joignable jusqu’à la fin. Ne réaffectez pas l’IP le premier jour.
• Autorisez temporairement les IP d’envoi anciennes et nouvelles dans SPF.

Phase 1 : Construire le nouveau serveur sérieusement

• Installer et configurer Postfix + Dovecot + stack de filtrage pour reproduire le comportement existant.
• Copier les clés DKIM et assurer que les sélecteurs de signature correspondent aux enregistrements DNS (ou publier d’abord les nouveaux enregistrements).
• Installer les certificats TLS pour les noms d’hôtes stables (IMAP et submission en priorité).
• Faire correspondre la base utilisateurs/mappage d’auth (LDAP/SQL/local). Tester avec un utilisateur réel.
• Provisionner le stockage avec marge et densité d’inodes correcte ; activer snapshots/sauvegardes.

Phase 2 : Synchronisation initiale des données mail (première passe)

• Lancer rsync ou dsync pendant que l’ancien serveur est actif.
• Ne stoppez pas encore les services ; laissez les utilisateurs travailler.
• Mesurez la durée et le débit. Si ça prend des jours, planifiez en conséquence plutôt que de faire semblant.

Phase 3 : Validation avant tout changement DNS

• Choisir 5–10 boîtes représentatives : grosses, petites, partagées, usage IMAP intensif.
• Vérifier la connexion, la liste des dossiers et le nombre de messages sur le nouveau serveur.
• Envoyer des mails tests entrant et sortant ; vérifier les en-têtes pour la signature DKIM et la chaîne Received.
• Confirmer les quotas, règles sieve (si utilisées) et tout filtrage côté serveur.

Phase 4 : Synchronisation delta avant bascule (seconde passe)

• Lancer une synchronisation incrémentale pour réduire la fenêtre finale.
• Surveiller l’activité d’écriture sur l’ancien serveur (connexions IMAP actives et livraisons).
• Communiquer : une courte fenêtre où le courrier peut être retardé vaut mieux qu’une longue panne mystérieuse.

Phase 5 : Bascule (gel court + DNS)

1. Arrêter ou différer le SMTP entrant sur l’ancien serveur (retourner une erreur temporaire). Vous voulez que les expéditeurs réessaient, pas qu’ils rebondissent.
2. Assurer que la submission (587/465) des utilisateurs pointe vers le nouveau serveur, idéalement via le même nom d’hôte.
3. Effectuer la synchronisation finale (rsync ou dsync).
4. Basculer les MX (et A/AAAA si applicable) vers le nouveau serveur.
5. Réactiver le SMTP entrant sur le nouveau serveur et surveiller les logs comme si c’était un thriller.

Phase 6 : Surveillance post-bascule et nettoyage

• Surveillez la file Postfix, les échecs d’auth Dovecot et la latence de livraison.
• Maintenez l’ancien serveur en mode non récepteur mais disponible pour récupération d’urgence pendant un certain temps.
• Après une période stable : restaurez des TTL plus élevés, retirez l’ancienne IP du SPF et archivez l’ancien serveur en toute sécurité.

Blague #2 : L’outil de migration le plus fiable est une invitation calendrier intitulée « Synchronisation finale » à laquelle tout le monde assiste réellement.

Jour de bascule : DNS, files et impact sur les clients

Comment « geler » l’entrée sans perdre de courrier

Votre ancien serveur devrait répondre par un échec temporaire afin que les MTAs expéditeurs réessaient. Un refus contrôlé est plus sûr que fermer le port et provoquer chez certains expéditeurs un comportement hostile. Si vous ne pouvez pas router proprement la politique, arrêter Postfix reste acceptable — les mécanismes de réessai SMTP existent pour une raison.

Une approche pratique : garder l’ancien serveur en fonctionnement, mais lui faire refuser les nouveaux entrants avec un 4xx. Ainsi il reste joignable pour l’administration et la file.

Stratégie de vidage des files

Avant la bascule, vous voulez que la file sortante de l’ancien serveur soit stable ou en diminution. Si elle grossit, vous basculez et aurez toujours des envois bloqués, ce que les utilisateurs interpréteront comme « la messagerie est cassée » même si l’entrée est correcte.

Après la bascule, vous pouvez encore voir des entrées arriver sur l’ancien serveur à cause du cache MX. Gardez un plan :

• Option A (propre) : l’ancien serveur différera tout entrant avec 4xx pendant une période, forçant les réessais vers le nouvel MX lorsque les caches se rafraîchiront.
• Option B (chaotique mais praticable) : l’ancien serveur accepte et relaie l’entrée vers le nouveau serveur pour une durée limitée.

L’option B peut être utile, mais c’est aussi ainsi que l’on crée accidentellement des boucles mail et des duplications si les maps de transport sont mal configurées. Choisissez prudemment.

Impact sur les clients et comment le rendre ennuyeux

Si les utilisateurs se connectent à mail.example.com pour IMAP et submission, et que le certificat est valide sur les deux serveurs, vous pouvez déplacer l’enregistrement A/AAAA sans demander une reconfiguration client. Le comportement client visible principal devient une courte déconnexion/reconnexion.

Si vous changez de nom d’hôte, vous obtiendrez :

• Avertissements de certificat
• Discordances de mots de passe sauvegardés
• Clients mobiles bloqués sur « vérification du compte »
• Tickets disant « ma boîte est vide » alors qu’il s’agit d’une ré-indexation

Donc : conservez les noms d’hôtes stables sauf impossibilité absolue.

Playbook de diagnostic rapide (trouver le goulot en minutes)

Voici l’ordre de triage quand quelque chose semble lent ou cassé juste après la bascule. Ne soyez pas créatif ; soyez systématique.

Première étape : est-ce le DNS ou le routage ?

• Vérifiez quel MX le monde voit pour le domaine.
• Vérifiez quel A/AAAA les clients résolvent pour mail.example.com.
• Confirmez que le nouveau serveur reçoit effectivement des connexions.

cr0x@server:~$ dig +short MX example.com
10 mail.example.com.

cr0x@server:~$ sudo tail -n 20 /var/log/mail.log
Jan  4 10:31:22 mail postfix/smtpd[3122]: connect from mx.remote[198.51.100.77]
Jan  4 10:31:23 mail postfix/smtpd[3122]: NOQUEUE: reject: RCPT from mx.remote[198.51.100.77]: 550 5.1.1 <user@example.com>: Recipient address rejected: User unknown in virtual mailbox table; ...

Interprétation : Si les logs montrent des connexions, le DNS est probablement correct. L’erreur indique une discordance de lookup destinataire/auth/db.

Deuxième étape : SMTP accepte-t-il mais ne livre pas ?

• Recherchez du courrier mis en file mais non livré.
• Vérifiez LMTP/livraison locale et les logs Dovecot LDA/LMTP.
• Vérifiez les permissions système sur vmail.

cr0x@server:~$ sudo postqueue -p | head -n 20
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
9F8E7D6C5B      1043 Thu Jan  4 10:29:10  sender@example.net
                                         user@example.com

Interprétation : Si la file grossit avec des destinataires locaux, la chaîne de livraison est cassée. C’est LMTP/socket Dovecot, permissions ou maps destinataires.

Troisième étape : IMAP/auth est-ce le problème ?

• Les échecs d’authentification explosent ? LDAP/SQL, config SASL manquante ou pare-feu bloquant le backend d’auth.
• IMAP lent ? IOPS disque ou réindexation Dovecot.

cr0x@server:~$ sudo doveadm auth test alice@example.com 'CorrectHorseBatteryStaple'
passdb: alice@example.com auth succeeded
extra fields:
  user=alice@example.com

Interprétation : Le test d’auth réussit, on écarte les problèmes LDAP/mot de passe. Si les clients échouent encore, regardez un mismatch TLS hostname ou d’anciens clients essayant un port différent.

Quatrième étape : le stockage est-il le coupable caché ?

• IOWait élevé, fsync lent, pool saturé — Maildir rend cela visible rapidement.
• Vérifiez l’épuisement des inodes.

cr0x@server:~$ iostat -xm 2 3
Device            r/s     w/s   rMB/s   wMB/s  %util  await
nvme0n1          12.1   210.3    0.3     8.7   98.9   45.2

Interprétation : %util proche de 100 et await élevé signifient que le stockage est saturé. L’IMAP semblera « indisponible » alors que les services sont techniquement actifs.

Décision : Réduisez la charge (limiter la concurrence), déplacez les index vers un stockage plus rapide ou augmentez les IOPS. Ne blâmez pas toujours Postfix ; il est peut-être juste témoin.

Erreurs courantes : symptôme → cause → correction

1) Symptom: Some senders deliver to old server for hours

Cause racine : Enregistrements MX en cache ou expéditeur ignorant le TTL faible ; vous avez baissé le TTL trop tard ou certains résolveurs le clampent.

Correction : Gardez l’ancien serveur disponible. Soit différer l’entrée avec 4xx pour forcer les réessais vers le nouvel MX, soit relayer temporairement vers le nouveau serveur avec protection contre les boucles.

2) Symptom: Users see duplicate messages after migration

Cause racine : UID/UIDVALIDITY IMAP changé à cause d’une réinitialisation des métadonnées ou d’une conversion de format sans préserver l’état.

Correction : Préférez dsync. Préservez les métadonnées Dovecot (indexes, GUIDs) quand c’est possible. Si c’est déjà cassé, isolez les boîtes affectées et resynchronisez proprement en guidant les utilisateurs pour réinitialiser le cache client.

3) Symptom: “Authentication failed” everywhere right after cutover

Cause racine : Nouveau serveur pointant vers un mauvais base DN LDAP, config SASL manquante ou pare-feu bloquant le backend d’auth.

Correction : Utilisez doveadm auth test et vérifiez les logs SASL. Validez la connectivité réseau vers LDAP/SQL depuis le nouvel hôte.

4) Symptom: SMTP accepts mail but it never reaches mailboxes

Cause racine : Transport de livraison Postfix mal configuré (chemin socket LMTP incorrect), ou permissions/UID vmail mismatched.

Correction : Vérifiez virtual_transport/mailbox_transport de Postfix et le socket LMTP de Dovecot. Confirmez la propriété et que first_valid_uid correspond à l’UID vmail réel.

5) Symptom: Outbound mail goes to spam or is rejected after migration

Cause racine : SPF n’inclut pas la nouvelle IP, DKIM ne signe pas, PTR manquant, ou réputation froide de l’IP.

Correction : Publiez SPF autorisant les deux IPs ; assurez la signature DKIM ; configurez PTR et HELO pour correspondre ; montez progressivement l’envoi si possible.

6) Symptom: IMAP is “up” but feels painfully slow

Cause racine : Goulot IOPS stockage, réindexation Dovecot, ou antivirus/filtre de contenu utilisant CPU/disque.

Correction : Vérifiez iostat, la charge et le nombre de processus Dovecot. Déplacez les index sur un stockage rapide, ajustez les limites de processus et évitez l’indexation full-text pendant la fenêtre de bascule.

7) Symptom: Random 550 “User unknown” for valid users

Cause racine : Maps destinataires non chargées, identifiants SQL obsolètes ou différences de sensibilité à la casse ; parfois domaine manquant dans virtual_mailbox_domains.

Correction : Comparez les maps Postfix ancien/nouveau et rechargez. Testez les lookup directement (SQL/LDAP) et vérifiez les listes de domaines.

Trois mini-histoires d’entreprise (comment ça tourne mal et bien)

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse

Ils ont supposé que baisser le TTL sur l’enregistrement MX signifiait « tout le monde basculera en cinq minutes ». C’était une hypothèse propre, du genre qu’on fait quand on gère surtout du DNS interne et la découverte de services Kubernetes.

La bascule a eu lieu à 19:00. Ils ont changé l’MX, vu du courrier entrant frapper le nouveau serveur et déclaré victoire. À 21:30, un cadre supérieur a transféré une plainte client : « Nous avons envoyé une mise à jour de contrat urgente il y a deux heures. L’avez-vous reçue ? » Les logs du nouveau serveur ne montraient rien. Les logs de l’ancien oui.

Il s’est avéré que plusieurs organisations partenaires utilisaient des résolveurs qui ignoraient le nouveau TTL (ou gardaient l’ancienne réponse de toute façon). Ces expéditeurs ont continué à livrer vers l’ancien MX. Pendant ce temps, l’équipe avait déjà mis l’ancien Postfix en « rejeter tout » avec un 5xx parce qu’ils voulaient forcer le trafic. SMTP a fait ce que fait SMTP : les expéditeurs ont rebondi immédiatement. Certaines de ces notifications de rebond n’ont jamais été vues parce que… oui, leur e-mail était aussi en flux.

La correction n’était pas exotique. Ils ont changé l’ancien serveur en diffèrant temporairement (4xx), de sorte que les expéditeurs ont mis en file et réessayé. Ils ont aussi ajouté un relais contrôlé de l’ancien vers le nouveau pour quelques IP partenaires critiques. En moins d’un jour, tout s’est stabilisé.

La leçon : ne confondez pas « TTL réglé bas » et « Internet a obéi ». Pour la sécurité de la bascule, traitez l’ancien serveur comme une couche de compatibilité pendant au moins un cycle TTL complet plus « les gens qui se fichent du TTL ».

Mini-histoire 2 : L’optimisation qui a échoué

Une autre société a décidé d’accélérer la migration en lançant des jobs rsync parallèles par domaine. Dix domaines, dix rsyncs simultanés. Sur le tableau blanc, ça semblait efficace ; en iostat, c’était terrifiant.

Le nouveau serveur avait des CPU rapides et des SSD « décents », ils pensaient qu’il supporterait la charge. Mais les migrations Maildir ne sont pas de gros écritures séquentielles ; ce sont des millions de créations de fichiers, mises à jour de métadonnées et tempêtes de fsync. Les SSD ont vu la latence grimper, les index Dovecot ont commencé à expirer, et les livraisons Postfix se sont accumulées parce que l’écriture disque était lente.

L’équipe a répondu en ajoutant encore de la concurrence. C’est l’erreur classique : traiter un goulot stockage comme une tâche CPU-bound. La latence a empiré. Le serveur n’était pas tombé ; il était tellement lent que les clients réessayaient et amplifiaient la charge. Un thundering herd auto-infligé.

Ils ont récupéré en faisant l’inverse de ce que leur instinct voulait : ils ont réduit le parallélisme rsync à un seul job, activé la limitation de débit et planifié la synchronisation lourde en dehors des heures de travail. Ils ont déplacé le stockage des index Dovecot sur NVMe local plus rapide et gardé le stockage mail sur l’array principal. Architecture ennuyeuse, soudain excellente.

La leçon : quand vous créez des millions de fichiers, « plus rapide » signifie souvent « moins de concurrence ». Votre goulot est l’I/O métadonnées, pas la bande passante.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une organisation avait une politique : chaque migration doit inclure un plan de rollback écrit et un test de rollback en direct pour une boîte. Les gens se plaignaient que c’était bureaucratique. C’était aussi la raison pour laquelle ils dormaient sereinement.

Pendant leur migration e-mail, ils ont remarqué que le mail sortant du nouveau serveur était parfois différé par un grand destinataire. L’entrée était correcte. Les utilisateurs pouvaient lire le courrier. Mais le sortant était un filet lent de « pourquoi mon e-mail n’a-t-il pas été reçu ? ».

Grâce au plan de rollback, ils n’ont pas paniqué. Ils ont simplement renvoyé le trafic de submission vers l’ancien serveur pour l’outbound tout en gardant l’inbound sur le nouveau. SPF autorisait déjà les deux IPs, les clés DKIM étaient cohérentes, et le nom d’hôte client n’avait pas changé. Les utilisateurs ont à peine remarqué, sauf que le courrier a recommencé à circuler.

Sur la journée suivante, ils ont corrigé le problème de délivrabilité : mismatch reverse DNS et un nom HELO trop strict. Puis ils ont remis progressivement l’outbound sur le nouveau serveur. Pas d’héroïsme. Pas de rituels nocturnes « on va juste le redémarrer ».

La leçon : le travail d’ingénierie le plus précieux est souvent le moins glamour. La planification du rollback n’est pas du pessimisme ; c’est de la compétence.

FAQ

1) Can I really do an email migration with “zero downtime”?

Vous pouvez vous en approcher : disruption visible minimale et aucun mail perdu. Mais vous ne pouvez pas arrêter le cache DNS ni garantir le comportement de chaque expéditeur. Prévoyez une courte fenêtre de gel et une période de coexistence.

2) Should I move MX first or move the IMAP/submission hostname first?

Dans la plupart des organisations : stabilisez d’abord IMAP/submission (même nom d’hôte, TLS valide), puis coupez l’MX. Les utilisateurs remarquent immédiatement une rupture IMAP ; les retards SMTP entrants sont souvent tolérés car SMTP réessaye.

3) Is rsync safe for Maildir?

Plutôt oui, si vous le faites en deux passes et acceptez que les changements concurrents puissent créer des courses. Pour la synchronisation finale, un court gel est plus propre. Si vous avez Dovecot des deux côtés, dsync est typiquement plus sûr pour la cohérence des métadonnées.

4) What about mbox mail storage?

Mbox en écriture concurrente est risqué à copier avec rsync parce que vous pouvez capturer des écritures partielles ou des états de lock étranges. Préférez une migration au niveau applicatif ou convertissez en Maildir avec une procédure contrôlée et une fenêtre d’indisponibilité.

5) Do I need to migrate Dovecot indexes?

Pas strictement, mais les reconstruire peut causer une forte I/O et ralentir l’IMAP après la bascule. Si vous pouvez migrer les index en toute sécurité et qu’ils sont compatibles, cela réduit les douleurs post-bascule. Testez d’abord.

6) How do I handle mail that arrives at the old server after cutover?

Soit différer avec 4xx pour que les expéditeurs réessaient vers le nouvel MX, soit relayer temporairement vers le nouveau serveur. Si vous relayez, implémentez une prévention de boucle et limitez la durée.

7) Should I keep the same DKIM key or rotate it?

Conservez la même clé/sélecteur DKIM pendant la migration si possible. Faites la rotation plus tard. La semaine de migration n’est pas le bon moment pour « améliorer l’hygiène de sécurité » à moins d’aimer les modes d’échec combinés.

8) How long should I keep the old server around?

Au moins le temps de couvrir les caches DNS et tout système retardataire envoyant ou livrant vers l’ancien hôte. Couramment une à deux semaines pour les organisations prudentes, plus court si vous avez une observabilité et un contrôle complets.

9) What’s the most common cause of “mailbox is empty” reports?

Mauvaises permissions/propriété, mail_location incorrect ou mappage d’auth qui envoie les utilisateurs vers un chemin différent. Moins fréquent : changement d’UIDVALIDITY provoquant la confusion côté client.

10) How do I know it’s safe to restore high TTL values?

Quand les logs montrent un trafic entrant négligeable vers l’ancien serveur, que l’outbound est stable depuis la nouvelle IP et que vous ne voyez pas de connexions clientes retardataires vers les anciens endpoints.

Étapes suivantes (pratiques, pas motivationnelles)

1. Baissez les TTL pour les MX et les noms d’hôte mail 24–48 heures à l’avance, et vérifiez avec dig.
2. Construisez le nouveau serveur pour reproduire le comportement ancien : ports, TLS, auth, domaines, filtres, quotas.
3. Lancez une synchronisation initiale, puis une synchronisation incrémentale, et mesurez les deltas pour prédire la fenêtre finale.
4. Validez avec de vraies boîtes et des tests bout en bout SMTP/IMAP avant de toucher au DNS.
5. Basculez avec un gel court, préférez les différés 4xx aux rejets permanents sur l’ancien serveur.
6. Surveillez comme un professionnel : files, échecs d’auth, latence stockage et comportement DKIM/SPF.
7. Gardez le rollback simple : ancien serveur intact, SPF incluant temporairement les deux IPs, et ne supprimez rien avant une semaine calme.

Si vous suivez ces étapes, la migration devient agréablement ennuyeuse. Et ennuyeux est le compliment le plus élevé qu’on puisse faire à un système de messagerie.