E‑mail : Boîte aux lettres pleine — prévenir et récupérer proprement

novembre 27, 2025 • février 3, 2026 • Lecture : 28 min • Views: 5

Cet article vous a aidé ?

« Boîte aux lettres pleine » est le type de panne qui semble mineure jusqu’à ce qu’elle bloque la signature d’un contrat, fasse perdre un reset de mot de passe,
ou renvoie en erreur des factures pendant une semaine. Personne ne remarque le premier bounce. Les gens remarquent le troisième message « Je vous ai envoyé deux courriels ».

Le pire : les incidents de boîte pleine sont généralement évitables. Le deuxième pire : lorsqu’ils surviennent, le « correctif rapide » inapproprié
peut transformer un problème de stockage en incident de perte de données. Évitons les deux.

Ce que « boîte aux lettres pleine » signifie réellement (protocole vs réalité de stockage)

« Boîte aux lettres pleine » paraît simple. Ce n’est pas le cas. Selon le système, cela peut vouloir dire :

Quota utilisateur dépassé (le plugin IMAP de quota dit « non »).
Backend de stockage de la boîte plein (disque, dataset, volume LVM, exhaustion d’inodes).
Limite interne du magasin de messages (limites par dossier, plafonds par boîte, politique de taille max par message).
Le destinataire est au quota de son fournisseur (vous ne pouvez pas le corriger ; vous ne pouvez que communiquer).
Échecs temporaires mal signalés (certains MTA rebondissent avec « mailbox full » quand le vrai problème est un échec de livraison/LMTP).

La distinction opérationnelle importante : s’agit-il d’un rejet au moment du SMTP (5xx/4xx pendant la livraison) ou d’un
report/file d’attente qui s’accumule ? Le rejet est douloureux pour l’expéditeur mais propre pour vos serveurs.
Le report est la voie qui finit par gonfler la file de mail jusqu’à en faire un incident de stockage.

Où cela apparaît dans le flux

Pipeline typique : réception SMTP (Postfix/Exim/Exchange) → file d’attente → livraison locale (LMTP/LDA) →
stockage de la boîte (Maildir/mbox/dbox, base Exchange) → accès IMAP.

« Boîte aux lettres pleine » peut provenir de l’agent de livraison local (quota) ou du système de fichiers (ENOSPC, EDQUOT, ENFILE, exhaustion d’inodes),
puis remonter jusqu’au côté SMTP comme raison de bounce.

Si vous ne retenez qu’une chose : traitez « boîte aux lettres pleine » comme un problème de stockage + politique, pas comme un problème d’email.
La partie email n’est que l’endroit où cela devient visible.

Une citation pour rester honnête

Werner Vogels (idée paraphrasée) : Vous le construisez, vous l’exploitez — la responsabilité opérationnelle revient aux créateurs.

Faits intéressants et courte histoire (parce que ce problème est plus ancien que votre pager)

Fait 1 : Le format classique mbox stocke une boîte entière dans un seul fichier ; un seul fichier énorme peut rendre les pannes « pleine » plus catastrophiques et plus longues à réparer.
Fait 2 : Maildir a été conçu en partie pour éviter les problèmes de verrouillage de mbox en utilisant un fichier par message ; il échange le nombre de fichiers/inodes contre une concurrence plus sûre.
Fait 3 : Les premiers codes d’erreur SMTP ont établi le schéma : échecs permanents (5xx) vs transitoires (4xx). « Mailbox full » correspond souvent à 552 ou 452 selon la politique.
Fait 4 : L’exhaustion d’inodes est un vrai « disque plein » même quand df annonce beaucoup d’espace — les serveurs lourds en Maildir découvrent souvent cela de façon douloureuse.
Fait 5 : Certains systèmes de mail implémentent des quotas au niveau applicatif (Dovecot quotas, limites Exchange), pas au niveau du système de fichiers. C’est pourquoi le stockage peut sembler correct alors que la livraison échoue.
Fait 6 : Les extensions IMAP QUOTA existent pour que les clients montrent aux utilisateurs qu’ils sont proches de la limite. Beaucoup d’organisations ne l’activent pas, puis s’étonnent que les utilisateurs soient surpris.
Fait 7 : Le marketing « boîte illimitée » cache souvent une limite pratique : taille max des pièces jointes, rétention, ou throttling. La boîte n’est pas infinie ; les brochures le sont.
Fait 8 : Le backscatter (rebonds vers des expéditeurs usurpés) était courant quand les MTA acceptaient le mail puis échouaient ensuite. Rejeter pendant le SMTP est plus propre et mieuxveillant.

Guide de diagnostic rapide (premières/deuxièmes/troisièmes vérifications)

Vous êtes en astreinte. Quelqu’un dit : « Les e‑mails rebondissent ; boîte pleine. » Ne perdez pas de temps. Faites ceci.

Premier : déterminer l’étendue et si c’est quota vs stockage

Est‑ce un utilisateur ou plusieurs ? Vérifiez les logs pour plusieurs destinataires en échec ou une seule boîte qui revient souvent.
Le serveur manque‑t‑il réellement d’espace ou d’inodes ? Vérifiez l’utilisation du système de fichiers et l’utilisation des inodes.
La file d’attente MTA grossit‑elle ? Si elle croît rapidement, vous risquez de transformer un problème de boîte en incident serveur.

Deuxième : identifier où la livraison échoue

Rejet SMTP au RCPT/DATA ? Regardez les logs Postfix et les codes d’état (552/452 vs message générique « unknown »).
Erreur LMTP/LDA ? Dovecot émet souvent des messages de quota clairs, et vous pouvez valider avec doveadm.
Erreur système de fichiers ? ENOSPC/EDQUOT dans les logs signifie que votre souci est une application du stockage, pas une politique mail.

Troisième : choisir la soupape de décompression la moins destructrice

Si c’est le système de fichiers plein : libérez de l’espace en toute sécurité (rotation des logs, vider soigneusement le spool des mails différés, étendre le volume). Ne supprimez pas d’emblée des fichiers de la messagerie.
Si c’est un quota utilisateur : augmentez le quota temporairement ou forcez le nettoyage/archivage (avec consentement/politique), puis traitez le backlog.
Si c’est un destinataire distant : stoppez les tempêtes de retries ; ajustez la durée de rétention en file et communiquez. Vos disques ne doivent pas payer pour leur problème de quota.

Blague #1 : Les boîtes mail sont comme des tiroirs de cuisine — personne ne sait ce qu’il y a dedans, mais il n’y a jamais de place pour une chose de plus.

Tâches pratiques : commandes, sorties et décisions (12+ actions réelles)

Les commandes ci‑dessous supposent un serveur Linux avec Postfix + Dovecot et stockage Maildir.
Si vous utilisez Exchange ou un service hébergé, beaucoup d’idées restent applicables : vérifiez le magasin, les quotas, la file, puis réparez avec le risque de données minimal.

Task 1: Confirm the error in mail logs (and whether it’s per-user)

cr0x@server:~$ sudo grep -E "quota|mailbox full|552 |452 |over quota|EDQUOT|ENOSPC" /var/log/mail.log | tail -n 20
Jan 04 10:12:19 mx1 postfix/lmtp[28177]: 3C1A12A0B3: to=<alex@example.com>, relay=imap1[10.0.2.10]:24, delay=2.1, delays=0.2/0.01/0.3/1.6, dsn=5.2.2, status=bounced (host imap1[10.0.2.10] said: 552 5.2.2 <alex@example.com> Quota exceeded (in reply to RCPT TO command))
Jan 04 10:12:20 mx1 postfix/qmgr[1123]: 3C1A12A0B3: removed

Ce que cela signifie : DSN 5.2.2 plus « Quota exceeded » pointe vers un quota applicatif côté livraison (souvent Dovecot).

Décision : N’agrandissez pas le disque tout de suite. Validez le quota utilisateur, déterminez si c’est une boîte unique ou une politique affectant beaucoup d’utilisateurs.

Task 2: Check disk usage on mail storage mount

cr0x@server:~$ df -hT /var/mail /var/vmail
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sda2      ext4   80G   79G  1.1G  99% /
/dev/sdb1      xfs   2.0T  1.3T  700G  66% /var/vmail

Ce que cela signifie : Le filesystem root est presque plein ; /var/vmail va bien. Si la file Postfix ou les logs vivent sur /, vous pouvez rater des livraisons malgré suffisamment d’espace pour les boîtes.

Décision : Traitez comme un incident d’infrastructure : libérez/étendez le FS root immédiatement, puis revérifiez le flux mail.

Task 3: Check inode exhaustion (Maildir’s favorite prank)

cr0x@server:~$ df -ih /var/vmail
Filesystem     Inodes  IUsed   IFree IUse% Mounted on
/dev/sdb1        64M    63M   850K   99% /var/vmail

Ce que cela signifie : Vous êtes pratiquement hors d’usage parce que vous êtes à court d’inodes. Maildir crée beaucoup de petits fichiers ; c’est normal… jusqu’à ce que ça ne le soit plus.

Décision : Vous avez besoin d’un soulagement d’inodes : supprimer/expirer le mail selon la politique, déplacer le mail froid vers un archive, ou reconstruire avec plus d’inodes (souvent implique un nouveau filesystem ou un backend différent).

Task 4: Check Postfix queue size (is the system accumulating damage?)

cr0x@server:~$ mailq | tail -n 5
-- 10954 Kbytes in 1423 Requests.

Ce que cela signifie : 1423 messages en file n’est pas forcément fatal, mais ça sent mauvais. Si la file grossit, votre « problème d’une boîte » devient « retard pour tout le monde ».

Décision : Si la croissance de la file est due à quelques destinataires, envisagez des transport maps temporaires ou des phases de hold pour éviter les tempêtes de retries pendant que vous réparez les quotas/stockage.

Task 5: Identify top recipients in the queue

cr0x@server:~$ sudo postqueue -p | awk '/^[A-F0-9]/{id=$1} /to=

Ce que cela signifie : Quelques destinataires dominent. C’est soit un problème de quota pour ces boîtes, soit un pattern de spam/inondation.

Décision : Réparez ces boîtes en priorité, ou mettez‑les en quarantaine pour protéger le reste du système.

Task 6: Confirm Dovecot quota status for a user

cr0x@server:~$ sudo doveadm quota get -u alex@example.com
Quota name=User quota Type=STORAGE Value=5120M Limit=5120M %
Quota name=User quota Type=MESSAGE Value=98234 Limit=0 %

Ce que cela signifie : Le quota de stockage est exactement à la limite (5120M utilisés sur 5120M). Le quota en nombre de messages est illimité (Limit=0).

Décision : Soit augmentez temporairement le quota, soit appliquez nettoyage/archivage. Préférez un nettoyage soutenu par la politique plutôt que « l’augmenter pour toujours ».

Task 7: Locate biggest folders and files in a Maildir (quick triage)

cr0x@server:~$ sudo du -h --max-depth=2 /var/vmail/example.com/alex/Maildir | sort -h | tail -n 10
1.2G    /var/vmail/example.com/alex/Maildir/.Sent
2.6G    /var/vmail/example.com/alex/Maildir/.Archive
5.1G    /var/vmail/example.com/alex/Maildir

Ce que cela signifie : Deux dossiers représentent la majeure partie de l’utilisation. C’est une bonne nouvelle : vous pouvez cibler le nettoyage sans fouiller tout le compte.

Décision : Coordonnez‑vous avec l’utilisateur (ou suivez la politique de rétention) pour archiver/supprimer d’abord les éléments Sent/Archive.

Task 8: Find unusually large messages (often attachments)

cr0x@server:~$ sudo find /var/vmail/example.com/alex/Maildir -type f -size +50M -printf "%s %p\n" | sort -nr | head
104857612 /var/vmail/example.com/alex/Maildir/cur/1704361234.M12345P6789.mx1,S=104857612:2,
73400612  /var/vmail/example.com/alex/Maildir/.Sent/cur/1704300044.M22222P1111.mx1,S=73400612:2,

Ce que cela signifie : Vous avez des messages >50MB dans la boîte. Ce sont des candidats privilégiés pour le nettoyage par l’utilisateur ou l’archivage automatique.

Décision : Si la politique le permet, déplacez les mails volumineux/anciens vers un archive. Ne supprimez pas sans précaution ; les gens stockent des PDFs « importants » dans l’email comme dans un classeur.

Task 9: Recalculate and repair Dovecot quota (after cleanup/moves)

cr0x@server:~$ sudo doveadm quota recalc -u alex@example.com

cr0x@server:~$ sudo doveadm quota get -u alex@example.com
Quota name=User quota Type=STORAGE Value=4032M Limit=5120M %

Ce que cela signifie : La comptabilité du quota reflète maintenant la réalité. Sans cela, Dovecot peut continuer à refuser les livraisons même après que vous ayez libéré de l’espace.

Décision : Si la livraison rebondit encore, vous avez affaire à une autre limite (système de fichiers, règle de quota différente, ou backend de stockage séparé).

Task 10: Check for filesystem quota enforcement (EDQUOT) vs Dovecot quota

cr0x@server:~$ sudo dmesg | tail -n 20
[123456.789012] XFS (sdb1): Quotacheck needed: Please turn quotas off and on again.
[123457.001122] XFS (sdb1): User quota exceeded. UID: 5000

Ce que cela signifie : Les quotas du système de fichiers sont actifs et appliqués. Dovecot peut être innocent ; le kernel dit « non ».

Décision : Corrigez la politique de quota au niveau kernel (augmentez, changez le mapping, ou réparez l’état des quotas), pas seulement les paramètres Dovecot.

Task 11: Verify the LMTP/LDA transport path and error codes

cr0x@server:~$ sudo postconf -n | egrep "^(myhostname|mydestination|virtual_transport|mailbox_transport|home_mailbox|virtual_mailbox_domains|virtual_mailbox_base|smtpd_recipient_restrictions)"
myhostname = mx1.example.net
virtual_transport = lmtp:imap1:24
virtual_mailbox_domains = example.com
virtual_mailbox_base = /var/vmail

Ce que cela signifie : Le mail est livré à Dovecot via LMTP. C’est bien : Dovecot produira des erreurs spécifiques de quota, et Postfix les affichera.

Décision : Concentrez‑vous sur la configuration de quota Dovecot et la santé du stockage des boîtes, pas sur des anomalies de mailbox_command.

Task 12: Inspect Dovecot logs for quota plugin behavior

cr0x@server:~$ sudo grep -E "Quota|quota|overquota|mailbox.*full" /var/log/dovecot.log | tail -n 30
Jan 04 10:12:19 imap1 dovecot: lmtp(alex@example.com)<28177>: Error: quota: Quota exceeded (mailbox for user is full)
Jan 04 10:13:02 imap1 dovecot: imap(alex@example.com)<29001>: Disconnected: Logged out in=512 out=2048

Ce que cela signifie : Dovecot rejette explicitement à cause du quota. C’est définitif.

Décision : Appliquez un soulagement de quota (nettoyage ou augmentation temporaire), puis surveillez la vidange de la file Postfix.

Task 13: Drain or requeue mail safely after fixing the constraint

cr0x@server:~$ sudo postqueue -f

cr0x@server:~$ sudo postqueue -p | tail -n 5
-- 842 Kbytes in 97 Requests.

Ce que cela signifie : La file se vide et diminue. Si elle ne diminue pas, les livraisons échouent encore et vous devez revérifier la raison d’erreur.

Décision : Si vous voyez des reports répétés pour le même utilisateur, arrêtez et corrigez la cause racine ; ne faites pas que relancer des retries.

Task 14: Confirm service health (IMAP/LMTP) after changes

cr0x@server:~$ sudo systemctl status dovecot --no-pager
● dovecot.service - Dovecot IMAP/POP3 email server
     Loaded: loaded (/lib/systemd/system/dovecot.service; enabled; preset: enabled)
     Active: active (running) since Sat 2026-01-04 09:55:22 UTC; 38min ago

Ce que cela signifie : Dovecot tourne. Cela ne prouve pas que les quotas sont corrects, mais ça élimine « service down » comme coupable.

Décision : Si le statut flirte ou échoue, vérifiez l’espace disque sur les logs/runtime, les erreurs de config et les fichiers TLS.

Task 15: Check whether the mail store is holding deleted mail (expunge/retention)

cr0x@server:~$ sudo doveadm mailbox status -u alex@example.com messages vsize deleted INBOX
messages=12450 vsize=3120M deleted=840

Ce que cela signifie : Beaucoup de messages supprimés prennent encore de la place (comportement client ou réglages serveur). C’est courant.

Décision : Ajustez la politique d’expunge ou lancez un job d’expunge selon les règles de rétention. « L’utilisateur l’a supprimé » ne signifie pas toujours « le disque l’a récupéré ».

Récupérer proprement (sans faire de dégâts)

La récupération est un problème de séquence. Faire les étapes dans le mauvais ordre et vous créez de nouveaux incidents :
index corrompus, rebonds permanents, ou une file MTA qui bouffe votre filesystem root.

Cas A : Le filesystem du serveur est plein (ou épuisement d’inodes)

C’est l’urgence car ça se propage. Quand le disque est plein, tout commence à échouer : livraisons, journalisation, handshakes TLS qui n’ont plus où écrire,
même les caches d’authentification. Votre objectif est la stabilité d’abord, puis la « correction des mails ».

Arrêter l’hémorragie : si la file est massive et grossit, envisagez de limiter temporairement le mail entrant (limits de débit, ajustement du greylisting, ou basculement MX externe si vous l’avez). Si vous n’avez pas de plan, au moins assurez‑vous de pouvoir écrire les logs.
Libérer de l’espace en sécurité : rotate/compress des logs, nettoyer les paquets anciens, vider les fichiers temporaires. Évitez de supprimer les fichiers du magasin mail en priorité ; c’est plus risqué et politiquement explosif.
Si c’est des inodes : identifiez les répertoires avec un nombre de fichiers insane (Maildir cur/new/tmp, quarantaine spam) et appliquez un nettoyage piloté par la politique (rétention sur le junk, pas sur INBOX). Étendre les inodes signifie souvent reconstruire le filesystem ; traitez‑le comme un projet, pas un exploit à 3h du matin.
Confirmer la récupération des services : Postfix, Dovecot, antivirus/milter, et tout daemon de politique.
Vider la file prudemment : une fois la contrainte levée, videz et surveillez les erreurs. Une vidange peut ressembler à un DDoS sur vos nœuds IMAP si vous n’êtes pas prudent.

Cas B : Le quota d’une boîte utilisateur est plein

Beaucoup d’équipes deviennent négligentes ici. Vous pouvez « résoudre » le problème en augmentant les quotas pour toujours, ce qui revient à réparer une fuite en achetant un sous‑sol plus grand.
Parfois vous le faites quand même — temporairement — pour que le business fonctionne. Mais faites‑le explicitement temporaire.

Valider l’autorité du quota : est‑ce Dovecot, quota système de fichiers, limite Exchange, ou politique cloud ?
Confirmer l’utilisation réelle : mesurez la taille des dossiers et identifiez les principaux responsables (Sent, Archive, « Projects_2016_FINAL_FINAL »).
Appliquer un soulagement traçable : soit purger selon la politique de rétention (préférez supprimer trash/spam d’abord) soit augmenter le quota avec un ticket et une date d’expiration.
Recalculer quota/index : ne sautez pas cette étape. Une comptabilité incorrecte mène aux « J’ai supprimé 2GB, pourquoi c’est encore plein ? ».
Livrer le backlog : vider la file et confirmer que les nouveaux mails entrants réussissent.

Cas C : Le destinataire distant est plein (pas votre serveur)

Votre travail est de protéger votre infrastructure et d’être un bon citoyen SMTP.

Confirmer le DSN distant : si vous voyez 552 5.2.2 venant du MX distant, acceptez la réalité. Vous ne pouvez pas ssh dans leur boîte.
Éviter les retries infinis : configurez des durées de file sensées. Ne gardez pas le mail des semaines sauf si la politique l’exige et si le stockage est dimensionné pour ça.
Communiquer : prévenez l’expéditeur que le destinataire est au‑dessus du quota. Proposez des alternatives : adresse alternative, renvoi plus tard, ou méthode de transfert de fichiers.
Si c’est un partenaire récurrent : envisagez de limiter les retries ou d’implémenter une file/transport séparé pour ce domaine afin qu’un partenaire ne remplisse pas vos disques.

Prévenir sérieusement : quotas, monitoring, rétention et conception du stockage

La prévention décide si la boîte pleine est une nuisance rare ou un exercice trimestriel d’incendie.
Les meilleures configurations rendent la panne difficile et la récupération facile.

Choisissez le modèle de quota intentionnellement (et documentez‑le)

Vous avez trois modèles courants :

Quotas applicatifs (Dovecot, Exchange) : flexibles par utilisateur/groupe, visibles par les clients, bonne UX quand QUOTA est activé.
Quotas système de fichiers (XFS/ext4 project/user quotas) : application stricte, fonctionne même si l’app mail se comporte mal, mais le mapping utilisateurs→UIDs/projects doit être discipliné.
Quotas par dataset (ZFS datasets, volumes LVM par tenant) : excellent pour l’isolation multi‑domaine ; associez toujours des quotas par utilisateur pour l’équité.

Opinion : utilisez des quotas au niveau appli pour les utilisateurs et des limites dataset/volume pour contrôler le blast‑radius. Compter sur une seule couche, c’est comment on se fait surprendre.

Exposez l’état du quota aux utilisateurs (ou ils le feront pour vous)

Si les clients peuvent afficher « vous êtes à 95% », les utilisateurs s’auto‑corrigent. S’ils ne le peuvent pas, ils remplissent la boîte jusqu’à ce que votre MTA commence à rebondir comme en 1999.

Activez le reporting IMAP QUOTA quand c’est supporté, et assurez‑vous que votre webmail l’affiche clairement. Ce n’est pas de la complaisance ; c’est du shedding de charge.

Politiques de rétention : le levier ennuyeux qui fonctionne

Les boîtes se remplissent parce que les organisations ne décident pas à quoi sert l’email. Est‑ce un canal de communication, ou un système d’archivage ?
Si c’est un système d’archivage, construisez une archive avec recherche et legal hold. Si c’est un canal, la rétention doit être finie.

Conseil pratique : appliquez d’abord une rétention plus courte sur Trash, Junk et les pièces jointes volumineuses. Personne ne vous poursuit pour avoir supprimé du spam.

Ingénierie du stockage : dimensionnez pour la réalité, pas pour l’espoir

Le stockage mail croît comme de la moisissure : lentement, puis soudain, puis il est partout où vous ne pensiez pas.
Concevez le stockage avec ces points en tête :

Capacité (évident) et inodes (moins évident, plus douloureux).
Patrons IOPS : beaucoup de petits fichiers, poids metadata ; les pics de latence se traduisent par des tickets « IMAP lent », pas par des alertes stockage.
Snapshots/sauvegardes : votre « mail supprimé » peut encore exister dans des snapshots. Utile pour la récupération, perturbant pour la planification de capacité.
Séparation des responsabilités : gardez spool/queue/logs hors du root si possible ; un root plein est un incident multi‑service.

Monitoring qui prévient réellement les incidents

Alerter sur « disque à 95% » est le début, pas la fin. Pour prévenir la boîte pleine, surveillez :

Espace filesystem et inodes pour le store mail, le spool, les logs.
Taille de la file Postfix et distribution d’âge de la file (les mails différés anciens sont un symptôme).
Distribution d’espace libre des quotas (combien d’utilisateurs sont >90%).
Taux de croissance des boîtes principales (compte compromis envoyant/recevant des inondations, ou workflow déposant des pièces jointes).
Taux d’erreurs (pic de 552/452, échecs LMTP, EDQUOT/ENOSPC dans les logs).

Blague #2 : Si votre monitoring ne vous dit que « disque plein », félicitations — vous avez construit un très bruyant livre d’histoire.

Trois mini-récits d’entreprise issus du terrain

Mini-récit 1 : L’incident causé par une fausse hypothèse

Une entreprise de taille moyenne a migré d’un ancien serveur unique vers un véritable split : des serveurs MX avec Postfix, des nœuds IMAP avec Dovecot,
et un NAS séparé pour /var/vmail. La migration fut faite soigneusement, connexions testées, envoi/reception testés. Tout semblait OK.

Deux semaines plus tard, des factures ont commencé à rebondir. Pas toutes — juste quelques boîtes à fort volume : finance, sales ops, et un assistant exécutif très mail‑dépendant.
Les rebonds disaient « Quota exceeded ». Tout le monde a supposé que le volume de stockage était plein, parce que c’est ce que « boîte pleine » suggère. Le stockage était à 40%.

Le coupable réel était une règle de quota Dovecot par défaut laissée dans un template : 5GB par utilisateur. Sur l’ancien serveur, les quotas étaient pratiquement illimités,
imposés seulement par la taille du disque. Sur le nouveau, les quotas étaient réels. Les utilisateurs avaient accumulé des mails pendant une décennie, et la nouvelle politique a fait office de trappe.

La récupération fut simple : augmenter temporairement les quotas pour les boîtes affectées, activer la visibilité des quotas dans le webmail,
et déployer une rétention pour Junk/Trash plus un workflow d’archivage basique pour finance. La leçon a fait plus mal que l’incident :
les quotas sont un comportement produit, pas seulement un réglage de stockage. Si vous les changez, vous changez le service.

Mini-récit 2 : L’« optimisation » qui a mal tourné

Une autre organisation a voulu « optimiser le stockage » en activant une compression agressive et la déduplication sur le volume mail.
L’idée n’était pas mauvaise : les pièces jointes se répètent, les mails sont majoritairement du texte, et le CFO adore les courbes de capacité qui baissent.

Pendant un temps, ça a paru être un succès. Puis lundi matin est arrivé avec le chœur habituel : recherches IMAP lentes, nouveaux mails arrivant en retard,
et la file de mail qui grossissait. Les alertes ont déclenché sur la taille de la file, pas sur l’utilisation disque. L’équipe a donc scruté les réglages Postfix.

Le retour de bâton venait des métadonnées et de la latence. Les workloads Maildir font beaucoup de petites lectures/écritures et d’opérations de répertoire.
La couche de stockage « optimisée » a rendu ces opérations plus coûteuses, surtout pendant la compaction. Les utilisateurs ne voyaient pas « latence stockage » ; ils voyaient « l’email est cassé ».
Entre‑temps, les reports temporaires maintenaient les messages en file plus longtemps, ce qui a augmenté le churn disque et empiré la compaction.

La correction n’était pas héroïque : réduire les réglages les plus agressifs, planifier la maintenance lourde hors heures, et poser des garde‑fous :
alarmes d’âge max de file, monitoring de latence par volume, et un disque spool séparé pour que la croissance de la file ne puisse pas affamer tout le système.
La morale : si votre optimisation change les queues de latence, ce n’est pas une optimisation — c’est un nouveau mode de panne.

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

Une entreprise réglementée gérait son propre mail. Pas par plaisir — pour conformité. Leur stack mail était sans fioritures :
Postfix, Dovecot, Maildir, snapshots périodiques, et une politique de rétention appliquée par règles serveur.

Un après‑midi, une boîte a atteint le quota pendant une fenêtre de découverte légale. L’assistante exécutive a paniqué, car de nouveaux mails rebondissaient et le dirigeant voyageait.
Mais l’équipe avait deux habitudes ennuyeuses : les quotas étaient visibles dans le webmail, et un rapport quotidien listait les boîtes >85% avec leurs dossiers principaux.

Au lieu de tâtonner, ils ont ouvert le rapport, trouvé le dossier coupable (.Sent), et appliqué une action pré‑approuvée :
déplacer les mails plus anciens qu’un seuil vers la boîte d’archive (toujours searchable, toujours conforme), puis recalculer les quotas.
Les livraisons ont repris, la file s’est vidée, et personne n’a touché au filesystem.

Rien d’« excitant » ne s’est passé, ce qui est le plus grand compliment pour une pratique opérationnelle.
L’ennui a sauvé la mise parce qu’il était répétable, autorisé et mesurable.

Erreurs fréquentes : symptômes → cause racine → correction

1) Symptom: Bounces say “mailbox full,” but disk has space

Cause racine : Quota au niveau applicatif (Dovecot/Exchange) atteint ; le disque n’est pas le goulot.
Correction : Vérifiez l’état du quota, la taille des dossiers et les règles de quota. Nettoyez ou augmentez temporairement le quota, puis recalculer quota/index.

2) Symptom: Disk usage looks fine, but everything fails with “No space left on device”

Cause racine : Exhaustion d’inodes ou un autre mount (root, spool, logs) est plein.
Correction : df -ih et vérifiez tous les mounts pertinents. Libérez des inodes (purger spam/quarantaine, appliquer rétention). Déplacez spool/logs hors du root.

3) Symptom: User deletes mail, still over quota

Cause racine : Les messages supprimés ne sont pas expungés, ou la comptabilité de quota est obsolète, ou ils ont été déplacés dans un dossier qui compte toujours.
Correction : Recalculez le quota ; vérifiez le compte deleted ; ajustez les réglages d’expunge ; assurez‑vous que le client expunge réellement (surtout avec IMAP).

4) Symptom: Queue grows rapidly, deliveries keep retrying

Cause racine : Deferrals transitoires (4xx) du backend de livraison, souvent dus à la latence de stockage, IMAP surchargé, ou timeouts d’un daemon de politique.
Correction : Identifiez les destinataires/domaines dominants ; augmentez la capacité du backend ; throttlez ; évitez les retries indéfinis ; isolez le trafic problématique.

5) Symptom: Only large attachments fail; small emails deliver

Cause racine : Limite de taille de message sur SMTP ou le magasin de boîtes ; parfois mal signalé comme « full ».
Correction : Confirmez les limites de taille dans le MTA et l’agent de livraison ; proposez des alternatives ; ne montez pas les limites sans évaluer le risque stockage/abus.

6) Symptom: After freeing space, Dovecot still rejects with quota errors

Cause racine : Le plugin de quota utilise des indexes en cache ; décalage entre l’état du filesystem et la base de quota.
Correction : Recalculez le quota ; si besoin, réparez les indexes soigneusement et en période de faible trafic. Validez aussi permissions et ownership.

7) Symptom: Only one domain or tenant is “full,” others fine

Cause racine : Quota dataset/project au niveau domaine ; isolation multi‑tenant qui s’active.
Correction : Vérifiez les limites et l’utilisation du dataset, pas seulement les quotas utilisateurs. Augmentez l’allocation domaine ou appliquez rétention/archivage par tenant.

Listes de contrôle / plan étape par étape

Checklist A: When the alert fires (15 minutes to stability)

Confirmez si les échecs sont locaux ou distants (codes d’erreur et relais dans les logs).
Vérifiez df -h et df -ih sur root, spool, et store mail.
Vérifiez la taille et la croissance de la file (mailq maintenant, puis à nouveau dans 5 minutes).
Trouvez les destinataires principaux dans la file ; décidez de les isoler ou non.
Si disque/inodes critiques : libérez d’abord de l’espace sûr (logs/temp), pas la suppression du magasin mail.
Si quota : obtenez l’état du quota ; identifiez les dossiers majeurs ; appliquez un nettoyage approuvé par la politique ou une augmentation temporaire.
Recalculez quota/index.
Videz la file et surveillez le taux d’erreurs ; confirmez que les nouveaux mails entrants réussissent.

Checklist B: Clean recovery without data loss

Avant toute suppression : confirmez ce qui compte pour le quota (Sent/Archive/Junk/Trash).
Privilégiez le déplacement vers archive plutôt que la suppression lorsque la conformité importe.
Documentez les changements : ajustements de quota, actions de rétention, modifications manuelles de boîtes.
Validez l’accès utilisateur après correction (login IMAP, liste des dossiers, arrivée de nouveaux mails).
Confirmez que les rebonds s’arrêtent et que la file différée se vide.
Backfill : si des messages ont été renvoyés en erreur de façon permanente, coordonnez une stratégie de renvoi.

Checklist C: Prevention work that pays rent every month

Définissez des quotas de boîtes par rôle (execs, boîtes partagées, comptes de service) et publiez la politique.
Activez la visibilité des quotas dans les clients/webmail.
Définissez la rétention pour Junk/Trash ; définissez une stratégie pour les pièces jointes.
Surveillez disque, inodes et distribution d’âge de la file.
Séparez spool/logs du filesystem root.
Testez la récupération trimestriellement : simulez un dépassement de quota, confirmez les alertes et la précision du runbook.

FAQ (les questions que l’on pose juste après avoir réparé)

1) Why did the sender get a bounce instead of a delay?

Parce que le chemin de livraison a renvoyé un échec permanent (5xx) comme 552/5.2.2. Les échecs permanents génèrent généralement des bounces.
Les échecs transitoires (4xx) provoquent des retries et de la mise en file.

2) Should “mailbox full” be a 4xx or 5xx?

Si vous attendez que la condition se résorbe bientôt (fenêtre temporaire), un 4xx peut être raisonnable. La plupart des dépassements de quota sont traités en 5xx parce que
le serveur refuse explicitement le stockage. Attention : 4xx encourage les tempêtes de retries et la croissance de la file.

3) Users deleted mail but quota didn’t change. Are they lying?

Pas nécessairement. La suppression IMAP marque souvent les messages comme deleted jusqu’à expunge. De plus, la comptabilité de quota peut être obsolète.
Recalculez le quota et vérifiez le comportement d’expunge côté serveur.

4) Is it safe to delete files directly from Maildir?

Ça peut être sûr si vous savez exactement ce que vous faites, mais ce n’est rarement la meilleure première action. Préférez les outils serveur (doveadm) ou des jobs de rétention contrôlés.
La suppression manuelle risque des incohérences d’index et des comportements étranges pour les utilisateurs.

5) Why is inode usage such a big deal on mail servers?

Maildir stocke chaque message comme un fichier séparé. Des centaines de milliers d’e‑mails se traduisent par des centaines de milliers d’inodes.
À court d’inodes, le système ne peut plus créer de nouveaux fichiers — même si des gigaoctets restent disponibles.

6) Can I just raise quotas and be done?

Vous pouvez, et parfois vous devriez (temporairement). Mais si c’est votre réponse par défaut, vous convertissez un problème utilisateur en un problème de croissance stockage.
Associez les augmentations de quota à la rétention et à l’archivage, sinon vous reproduirez l’incident en pire.

7) How do I stop one mailbox from filling the Postfix queue?

Identifiez les destinataires dominants et envisagez des holds temporaires ou des transports séparés pour les cibles problématiques.
L’objectif est de contrôler le blast‑radius : protéger le reste de votre pipeline de livraison pendant que vous corrigez la contrainte.

8) What’s the cleanest way to handle large attachments?

Ne traitez pas l’email comme du stockage d’objets. Fixez des limites d’attachement sensées et fournissez une voie de partage de fichiers approuvée.
Si la conformité exige la rétention, archivez les pièces jointes dans un système conçu pour cela, avec indexation et gestion du cycle de vie.

9) Why did freeing space not immediately fix mail delivery?

Parce que le système de livraison peut utiliser un état de quota/index en cache, ou la file Postfix est encore en train de retry lentement.
Recalculez le quota, videz la file, et regardez les logs pour la raison d’échec actuelle.

10) How do we prove we didn’t lose mail during the incident?

Comparez l’état de la file avant/après, vérifiez les bounces générés, regardez les logs pour les livraisons réussies, et validez l’intégrité des boîtes.
Si vous avez du journaling ou du message tracking, utilisez‑les pour confirmer la réception de bout en bout.

Conclusion : prochaines étapes pratiques

Les incidents de boîte pleine ne sont pas glamours, mais ils sont prévisibles. Bonne nouvelle : les pannes prévisibles sont celles que vous pouvez ingénierie‑r.

Choisissez une stratégie de quota (quotas appli + limites dataset est une combinaison solide) et documentez‑la comme partie du produit.
Instrumentez les bons signaux : disque, inodes, âge de la file, distribution d’espace libre par quota, et codes d’erreur de livraison.
Construisez une habitude de récupération sûre : libérez d’abord de l’espace sûr, corrigez la vraie contrainte, recalculer quota/index, puis videz les files et vérifiez.
Rendez la rétention et l’archivage réels : surtout pour Junk/Trash et les pièces jointes. C’est là que vit la plupart de la « croissance mystérieuse ».

Si vous ne faites rien d’autre, implémentez le guide de diagnostic rapide et les checklists ci‑dessus. La prochaine fois que « boîte aux lettres pleine » apparaîtra, vous la réparerez en minutes —
et vous n’aurez pas à expliquer à la finance pourquoi le serveur mail s’est mangé lui‑même.