Si vous gérez de l’email en production, une boîte catch‑all ressemble à un filet de sécurité propre : aucun email ne se perd, rien ne rebondit, tout le monde est content.
Puis la réputation de votre domaine chute, les vrais messages clients vont en courrier indésirable, et votre support se retrouve noyé sous des mystères « livraison échouée » qui ne sont pas de réels échecs.
Le catch‑all est l’équivalent email de dire à l’accueil d’accepter tous les colis pour « N’importe quel nom » et de les empiler dans le hall.
Vous vous sentirez très utile jusqu’à l’arrivée du contrôleur de sécurité.
Ce que fait réellement une boîte catch‑all
Une boîte catch‑all (parfois « accept-all » ou « adresse par défaut ») est une règle de routage qui accepte les messages pour n’importe quel destinataire sur votre domaine
— y compris pour des destinataires qui n’existent pas — et les remet dans une boîte (ou un pipe) que vous contrôlez.
Concrètement, votre serveur SMTP cesse de répondre « 550 5.1.1 user unknown » et se met à répondre « 250 ok » pour presque tout.
Cela change la façon dont le reste de l’écosystème email vous traite.
Pourquoi les équipes activent le catch‑all (raisons habituelles)
- Peur de perdre des mails : « Et si un client tape saless@domain.com au lieu de sales@domain.com ? »
- Pansement de migration : anciens alias, anciens services, anciennes adresses d’applications.
- Habitude héritée : quelqu’un l’a configuré il y a dix ans et personne ne veut toucher à la messagerie.
- Mauvaise compréhension de la “délivrabilité” : ils pensent que moins de rebonds = meilleure réputation.
Ce que le catch‑all vous apporte réellement
Il vous apporte plus de mails acceptés. Pas plus de mails utiles.
Il vous apporte aussi des responsabilités opérationnelles très spécifiques : amplification du spam, échecs de politique silencieux, et un profil de réputation qui ressemble à celui d’un domaine tolérant le spam.
Pourquoi le catch‑all ruine la délivrabilité (mécanismes, pas sensations)
1) Vous devenez un aimant à spam, par conception
Les spammeurs n’ont pas besoin de deviner les adresses quand un domaine accepte tout. Ils peuvent arroser des destinataires aléatoires sur votre domaine et vous l’accepterez.
Une fois qu’ils apprennent (par tests) que votre domaine est accept‑all, vous êtes placé dans un « bucket haute acceptation » dans leurs outils.
Ce n’est pas personnel ; c’est économique.
Votre volume entrant augmente. Plus important encore, votre volume « mauvais » augmente : destinataires invalides, adresses générées par des bots, attaques par dictionnaire, et domaines expéditeurs usurpés.
Cela ne reste pas « inbound-only ». Ça affecte la réputation de votre domaine de façons qui se manifestent plus tard lorsque vous envoyez des mails sortants.
2) Vous cassez une boucle de rétroaction importante : la validation des destinataires
SMTP est censé être un moment de filtrage. Si l’utilisateur n’existe pas, la bonne chose est de rejeter à RCPT TO avec un 5xx.
Le catch‑all supprime cela. Vous acceptez le message, générez une charge de stockage, et vous vous retrouvez ensuite à le gérer en aval.
Ce traitement en aval devient souvent « marquer comme spam » ou « supprimer ». C’est acceptable pour votre boîte de réception, mais cela signifie que vous n’avez pas rejeté au niveau du protocole
— l’émetteur a reçu un 250 OK et considère la livraison comme réussie.
3) Vous créez une “délivrabilité fantôme” : moins de rebonds, pire réputation
Une incompréhension courante chez les dirigeants : « Les rebonds sont mauvais, évitons‑les. » Non.
Les rebonds inutiles sont mauvais. Les rebonds précis sont de l’hygiène.
Quand vous acceptez des mails pour des destinataires inexistants, les expéditeurs n’apprennent pas que leur liste est sale. Ils continuent d’envoyer.
Finalement, leur système vous marque comme un puits d’adresses. Pendant ce temps votre filtrage entrant travaille plus, vos utilisateurs se plaignent, et votre pile mail paraît bruyante.
4) Vous augmentez la probabilité de backscatter (et vous agacez les autres opérateurs)
Le backscatter, c’est quand votre système accepte un email puis génère plus tard un bounce vers l’adresse MAIL FROM (qui est souvent usurpée).
Si vous acceptez du spam pour des destinataires aléatoires puis décidez plus tard que vous « ne pouvez pas le livrer », vous pouvez générer des notifications de non‑remise à des tiers innocents.
Beaucoup de MTAs modernes essaient d’éviter cela, mais les configurations catch‑all viennent fréquemment avec des règles de routage négligentes et des comportements de réponse automatique/vacances.
Les plaintes de backscatter peuvent marteler la réputation de votre IP ou domaine.
5) Vous brouillez votre histoire d’application DMARC/SPF/DKIM
DMARC n’est pas juste une case à cocher. C’est une politique plus un canal de rapport qui vous dit qui vous usurpe et comment les récepteurs traitent vos mails.
Le catch‑all fait que beaucoup de junk entrant « se livre avec succès » en interne, ce qui encourage de mauvais flux de travail :
transfert de mail suspect, réponse automatique, ou interaction accidentelle avec des tentatives d’usurpation.
Vous perdez aussi le signal propre dans vos rapports agrégés DMARC parce que votre volume de spam entrant augmente et que votre équipe finit par ignorer les données.
Opérationnellement : le tableau de bord devient du papier peint.
6) Le stockage et la fiabilité en prennent un coup (oui, vraiment)
Le mail, c’est du stockage. Le mail, c’est aussi une entrée utilisateur non bornée.
Une boîte catch‑all est une voie classique vers :
- Débordements de quota de boîte (puis tout rebondit, y compris les mails légitimes).
- Explosion d’indexation/recherche (les serveurs IMAP n’aiment pas des millions de messages dans un dossier).
- Croissance des sauvegardes et douleur de restauration (cette boîte devient votre pire jeu de données).
- Confusion lors de la réponse à incident (« pourquoi cette boîte fait 200GB ? »).
Blague #1 : Une boîte catch‑all, c’est comme /dev/null, sauf que c’est facturable et qu’elle envoie parfois des réponses en colère.
7) Vous augmentez le risque de fuite accidentelle de données
Un email mal adressé contient parfois des factures, des contrats, des identifiants ou des données personnelles.
Avec le catch‑all, vous acceptez silencieusement des messages destinés à d’autres organisations aussi — domaines avec fautes de frappe inclus.
Vous êtes devenu un réceptacle de données pour les erreurs d’autrui.
8) Vous détruisez la capacité à prendre des décisions de politique strictes
Quand tout converge vers un seul endroit, tout se ressemble. Cela ruine votre capacité à :
- Différencier les mails transactionnels des mails humains
- Appliquer des limites de taux et des règles de filtrage par alias
- Implémenter des politiques de rétention par boîte
- Appliquer le principe du moindre privilège (qui peut lire quoi)
La boîte catch‑all est un anti‑pattern parce que c’est un seul seau pour des risques hétérogènes.
En termes de fiabilité : vous avez fusionné plusieurs domaines de défaillance en un seul.
Faits intéressants et contexte historique
L’email n’a pas commencé comme un système d’identité global durci. Il est devenu tel. Le catch‑all avait plus de sens quand tout était plus petit, plus amical, et basé sur l’honneur.
Voici quelques faits courts qui expliquent comment on s’est retrouvé avec ça :
- SMTP ancien (années 1980) supposait des réseaux coopératifs. La vérification des destinataires n’était pas un problème hostile ; aujourd’hui si.
- Commandes VRFY/EXPN aidaient autrefois à confirmer les destinataires. Elles sont largement désactivées aujourd’hui parce qu’elles facilitent la collecte d’annuaires.
- « Accepter puis filtrer » était historiquement courant parce que le disque était moins cher que le temps d’ingénierie. Aujourd’hui, la réputation est la partie coûteuse.
- Le spam a explosé dans les années 1990, et les « attaques par dictionnaire » (essayer des noms courants) sont devenues routinières ; le catch‑all est essentiellement une permission pour cette attaque.
- SPF est arrivé pour limiter l’usurpation en autorisant des IPs d’envoi, mais c’est fragile avec le forwarding, donc on s’est tourné vers DKIM/DMARC.
- DKIM a rendu l’authentification au niveau contenu pratique, mais n’a pas résolu « ce destinataire est‑il réel ? » Le catch‑all casse toujours ce signal.
- DMARC a introduit l’alignement et la politique, et les rapports. Ces rapports ne valent que si vous ne vous noyez pas dans le junk.
- Les fournisseurs de boîtes modernes scorent domaines et IPs en utilisant l’engagement et les signaux de plainte ; accepter beaucoup de junk augmente les chances d’interactions négatives.
- Le plus‑addressing (user+tag@domain) est devenu populaire comme alternative sûre pour « adresses inconnues » sans accepter littéralement tout.
Manuel de diagnostic rapide
Quand la délivrabilité ou le spam entrant devient moche et que le catch‑all est en jeu, ne commencez pas par débattre de philosophie. Triez comme un opérateur.
Vérifiez d’abord le goulot : comportement protocolaire, indicateurs de réputation, et santé du stockage.
Première étape : confirmez que vous acceptez réellement les destinataires inconnus
- Utilisez des tests SMTP contre vos MX : accepte‑t‑il RCPT TO pour un utilisateur aléatoire ?
- Vérifiez la config du MTA pour des transports par défaut, des maps de destinataires, ou « luser_relay ».
Deuxième : quantifiez les dommages (volume, sources et modes d’échec)
- Échantillon de logs : combien de destinataires inexistants distincts par heure ?
- Top IPs/ASNs de connexion, top noms HELO, top expéditeurs d’enveloppe.
- Croissance de la queue et modèles de rebond (échecs temporaires vs permanents).
Troisième : vérifiez si le « catch‑all » cache un autre problème
- Quota de boîte plein ? Timeouts IMAP ? Latence de stockage ?
- Règles d’alias/forward mal configurées causant des boucles ?
- Le mail sortant atterrit maintenant en spam parce que votre domaine semble en désordre ?
Quatrième : décidez de la contention
- Immédiat : rejetez les destinataires inconnus au moment SMTP.
- Court terme : ajoutez des alias explicites pour les fautes de frappe critiques pour l’activité.
- Moyen terme : implémentez un traitement entrant structuré et une revue sécurité pour les mails mal adressés.
Tâches pratiques : commandes, sorties et décisions
Ci‑dessous des tâches concrètes que vous pouvez exécuter sur une pile MTA Linux typique (exemples Postfix, avec un peu d’Exim/Dovecot/outils communs).
Chaque tâche inclut une commande, ce que la sortie signifie, et la décision à prendre.
Task 1: Prove catch‑all behavior with a direct SMTP session
cr0x@server:~$ nc -v mx1.example.net 25
Connection to mx1.example.net 25 port [tcp/smtp] succeeded!
220 mx1.example.net ESMTP Postfix
ehlo testhost
250-mx1.example.net
250 PIPELINING
mail from:<probe@outside.test>
250 2.1.0 Ok
rcpt to:<this-user-should-not-exist-9f3a@example.net>
250 2.1.5 Ok
quit
221 2.0.0 Bye
Signification : Si vous obtenez « 250 2.1.5 Ok » pour un destinataire clairement aléatoire, vous acceptez des destinataires inconnus (catch‑all ou équivalent).
Décision : Si cela n’est pas explicitement requis pour un flux contrôlé, désactivez‑le. Si c’est requis, placez‑le derrière une barrière (limites de taux, MX séparé, ou liste de destinataires vérifiés).
Task 2: Check Postfix for the classic catch‑all setting (luser_relay)
cr0x@server:~$ postconf -n | egrep 'luser_relay|local_recipient_maps|virtual_alias_maps|virtual_mailbox_maps|recipient_delimiter'
luser_relay = catchall
local_recipient_maps =
recipient_delimiter = +
virtual_alias_maps = hash:/etc/postfix/virtual
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
Signification : luser_relay route les destinataires locaux inconnus vers une adresse locale. Un local_recipient_maps vide peut aussi signifier « accepter n’importe quoi ».
Décision : Supprimez luser_relay et restaurez la validation des destinataires via local_recipient_maps ou des virtual mailbox maps correctes.
Task 3: Confirm whether Postfix is validating recipients at RCPT time
cr0x@server:~$ postconf -n | egrep 'smtpd_recipient_restrictions|smtpd_relay_restrictions|smtpd_delay_reject'
smtpd_delay_reject = yes
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination
Signification : Rien ici ne rejette les destinataires inconnus. Ce n’est pas automatiquement erroné, mais c’est une lacune courante.
Décision : Ajoutez un mécanisme de validation des destinataires (par exemple, correct local_recipient_maps / virtual_mailbox_maps et reject_unlisted_recipient si approprié).
Task 4: Find “accept-all” patterns in logs (nonexistent recipients)
cr0x@server:~$ sudo grep -R "to=<.*@example.net>" /var/log/mail.log | tail -n 5
Jan 4 09:14:31 mx1 postfix/qmgr[1123]: 9A2B13C4D: to=<xyqzqj@example.net>, relay=local, delay=0.2, status=sent (delivered to mailbox)
Jan 4 09:14:32 mx1 postfix/qmgr[1123]: 7D1E22F8A: to=<billingg@example.net>, relay=local, delay=0.1, status=sent (delivered to mailbox)
Jan 4 09:14:33 mx1 postfix/qmgr[1123]: 1F3D9C0AA: to=<hr-dept@example.net>, relay=local, delay=0.1, status=sent (delivered to mailbox)
Jan 4 09:14:35 mx1 postfix/qmgr[1123]: 4C0D22B19: to=<asdkjhasd@example.net>, relay=local, delay=0.1, status=sent (delivered to mailbox)
Jan 4 09:14:36 mx1 postfix/qmgr[1123]: 55B9CC1E0: to=<customer.service@example.net>, relay=local, delay=0.1, status=sent (delivered to mailbox)
Signification : Des destinataires à l’aspect aléatoire marqués « delivered to mailbox » est un fort indicateur que la validation des destinataires ne se produit pas.
Décision : Si plus qu’une fraction triviale des destinataires sont du garbage, désactivez le catch‑all et ajoutez des alias explicites pour les variantes légitimes.
Task 5: Identify top recipient names (to spot dictionary attacks)
cr0x@server:~$ sudo awk -F'to=<' '/postfix\/(qmgr|local)/ {for (i=1;i<=NF;i++) if ($i ~ /^to=</) {gsub(/^to=<|>,.*/,"",$i); print $i}}' /var/log/mail.log | \
cut -d@ -f1 | sort | uniq -c | sort -nr | head -n 10
418 info
377 admin
265 support
201 sales
188 contact
173 test
166 hr
144 billing
121 webmaster
110 noreply
Signification : Ce sont les local parts les plus ciblées. Avoir « admin/info/support » en tête est un comportement classique d’attaque par dictionnaire.
Décision : Assurez‑vous que ces alias importants existent et pointent vers des files surveillées, mais rejetez les destinataires inconnus au‑delà de votre liste connue.
Task 6: Check queue depth (symptom of catch‑all + spam flood)
cr0x@server:~$ mailq | tail -n 3
-- 1245 Kbytes in 812 Requests.
Signification : Une queue qui croît suggère des goulots en aval (livraison, scan de contenu, I/O disque) ou un abus en amont.
Décision : Si la queue croît pendant des rafales de spam et que les destinataires sont aléatoires, priorisez le rejet des destinataires au moment SMTP pour arrêter d’alimenter la queue.
Task 7: Verify whether you’re generating backscatter (outbound bounces)
cr0x@server:~$ sudo grep -E "status=bounced|mailer-daemon|postmaster" /var/log/mail.log | tail -n 8
Jan 4 09:22:18 mx1 postfix/bounce[2219]: 6A1F2C9D3: sender non-delivery notification: 1B3C0D9AA
Jan 4 09:22:18 mx1 postfix/qmgr[1123]: 1B3C0D9AA: from=<>, size=3120, nrcpt=1 (queue active)
Jan 4 09:22:19 mx1 postfix/smtp[2281]: 1B3C0D9AA: to=<innocent@victim.tld>, relay=mx.victim.tld[203.0.113.8]:25, delay=1.2, status=sent (250 OK)
Signification : Votre serveur envoie des notifications de non‑remise à des tiers. Si le MAIL FROM original était usurpé (très courant dans le spam), c’est du backscatter.
Décision : Arrêtez d’accepter les mails que vous ne pouvez pas livrer. Rejetez au moment SMTP les destinataires invalides et envisagez de désactiver les NDRs hors bande pour les violations de politique de contenu.
Task 8: Inspect mailbox size and message counts (storage reality check)
cr0x@server:~$ sudo doveadm mailbox status -u catchall@example.net messages vsize INBOX
messages=284112
vsize=19748377291
Signification : ~284k messages et ~19.7GB dans une seule inbox, c’est là que la performance IMAP commence à coûter des incidents.
Décision : Si vous devez garder une boîte réceptacle, faites‑la tourner (dossiers quotidiens), appliquez des rétentions, et tenez‑la hors IMAP utilisateur. Préférez le rejet.
Task 9: Check filesystem capacity and inode pressure
cr0x@server:~$ df -h /var/vmail
Filesystem Size Used Avail Use% Mounted on
/dev/sdb1 500G 456G 19G 97% /var/vmail
Signification : À 97% utilisé, vous n’êtes qu’à une rafale d’échecs de livraison. Le catch‑all rend les rafales normales.
Décision : Contenez en rejetant les destinataires inconnus et en purgeant le stockage du catch‑all. Ensuite corrigez la capacité (étendre, déplacer, ou appliquer quotas/rétention).
Task 10: Look for alias loops and misroutes (catch‑all can create them)
cr0x@server:~$ sudo postmap -q catchall /etc/aliases
catchall@example.net
Signification : Ici, catchall se résout en une adresse du même domaine. Ce n’est pas automatiquement une boucle, mais c’est un piège fréquent si combiné à des règles d’alias virtuelles.
Décision : Assurez‑vous que la boîte réceptacle est une entrée de mailbox concrète, pas un autre alias qui peut rebondir. Mieux : éliminez‑la.
Task 11: Validate your virtual mailbox map behavior (Postfix)
cr0x@server:~$ sudo postmap -q realuser@example.net /etc/postfix/vmailbox
realuser@example.net example.net/realuser/
Signification : Ce destinataire existe comme destination de mailbox.
Décision : Confirmez que les utilisateurs inconnus retournent des résultats vides, et configurez Postfix pour rejeter les destinataires non listés plutôt que de les router vers un puits.
Task 12: Test unknown recipient rejection after configuration changes
cr0x@server:~$ nc -v mx1.example.net 25
Connection to mx1.example.net 25 port [tcp/smtp] succeeded!
220 mx1.example.net ESMTP Postfix
ehlo testhost
250-mx1.example.net
250 PIPELINING
mail from:<probe@outside.test>
250 2.1.0 Ok
rcpt to:<this-user-should-not-exist-9f3a@example.net>
550 5.1.1 <this-user-should-not-exist-9f3a@example.net>: Recipient address rejected: User unknown in local recipient table
quit
221 2.0.0 Bye
Signification : C’est le comportement que vous voulez. Rejetez à RCPT avec un 550 clair.
Décision : Conservez‑le. Puis ajoutez des alias explicites pour les adresses critiques qui étaient auparavant « attrapées » par le catch‑all.
Task 13: Confirm DKIM signing is applied to outbound mail (because you’re about to tighten policies)
cr0x@server:~$ sudo grep -R "DKIM-Signature" -n /var/log/mail.log | tail -n 3
Jan 4 09:40:01 mx1 opendkim[901]: 3F2AB19C0: DKIM-Signature field added (s=mail, d=example.net)
Jan 4 09:40:05 mx1 opendkim[901]: 8C1DA22A1: DKIM-Signature field added (s=mail, d=example.net)
Jan 4 09:40:07 mx1 opendkim[901]: 7A0BC11E2: DKIM-Signature field added (s=mail, d=example.net)
Signification : Le mail sortant est signé DKIM pour votre domaine. Raffermir la politique des destinataires n’altérera pas l’authentification sortante, mais cela enlève le chaos du système.
Décision : Si le DKIM n’est pas présent, corrigez‑le avant d’augmenter l’enforcement DMARC, sinon vous créerez votre propre incident de délivrabilité.
Task 14: Check DMARC policy for your domain (quick DNS sanity)
cr0x@server:~$ dig +short TXT _dmarc.example.net
"v=DMARC1; p=none; rua=mailto:dmarc-reports@example.net; ruf=mailto:dmarc-forensic@example.net; fo=1"
Signification : La politique est p=none (surveillance seulement). C’est courant, mais cela signifie que les récepteurs ne sont pas invités à quarantiner/rejeter le mail usurpé.
Décision : Continuez la surveillance pendant que vous corrigez le catch‑all. Une fois stable, passez à p=quarantine puis à p=reject avec un déploiement progressif.
Task 15: Detect mailbox quota enforcement (or lack of it)
cr0x@server:~$ sudo doveadm quota get -u catchall@example.net
Quota name=User quota Type=STORAGE Value=0 Limit=0
Quota name=User quota Type=MESSAGE Value=0 Limit=0
Signification : Pas de quotas. Une boîte catch‑all sans quotas est un incident au ralenti.
Décision : Si vous conservez temporairement une boîte puits, définissez des quotas stricts et de l’alerte. Mais traitez‑la comme un état de transition, pas comme une destination.
Task 16: Rate-limit abusive senders at the edge (mitigation while you remove catch‑all)
cr0x@server:~$ sudo postconf -n | egrep 'smtpd_client_message_rate_limit|smtpd_client_connection_rate_limit'
smtpd_client_connection_rate_limit = 30
smtpd_client_message_rate_limit = 60
Signification : Des limites basiques sont configurées. Si elles sont absentes, vous comptez sur l’espoir et le CPU.
Décision : Ajoutez des limites de taux comme bouclier temporaire. La solution permanente reste : arrêter d’accepter des destinataires inconnus.
Trois mini-récits d’entreprise (tous trop réels)
Mini‑récit 1 : L’incident causé par une mauvaise hypothèse
Une entreprise B2B de taille moyenne est passée d’un fournisseur hébergé à une gestion Postfix + Dovecot auto‑hébergée parce que « c’est juste de l’email ».
Lors de la bascule, quelqu’un a activé le catch‑all sur le domaine pour ne pas perdre de messages des boîtes décomissionnées.
L’hypothèse était simple : accepter tout maintenant, nettoyer après.
Deux semaines plus tard, les ventes se plaignaient que les prospects « disparaissaient ». En réalité, non. Les séquences sortantes atterrissaient en spam chez plusieurs gros destinataires.
Pendant ce temps, la boîte catch‑all recevait un flux régulier de spam et de mails mal adressés… plus des milliers de probes RCPT par jour.
Personne ne l’avait remarqué parce que techniquement « ça marchait » : le mail était accepté et livré quelque part.
Le SRE d’astreinte a trouvé la boîte catch‑all à plusieurs dizaines de gigaoctets et le service IMAP subissant des timeouts intermittents aux heures de pointe.
Les tickets de support montraient des messages légitimes manquants — en fait ils n’étaient pas manquants ; ils étaient enterrés sous les ordures et l’indexation lente.
La pile mail était assez saine pour ne pas générer d’alerte, assez malade pour coûter du chiffre d’affaires.
La correction n’était pas glamoureuse. Ils ont retiré le catch‑all, ajouté des alias explicites pour les fautes de frappe les plus courantes, et rejeté les destinataires inconnus au moment SMTP.
Le volume de spam a chuté immédiatement. L’IMAP s’est stabilisé. La délivrabilité s’est améliorée sur quelques semaines quand leur domaine a cessé de se comporter comme un puits d’acceptation.
Leçon : « On nettoiera plus tard » n’est pas un plan quand Internet est autorisé à écrire dans votre stockage.
Mini‑récit 2 : L’optimisation qui a mal tourné
Une firme de services globale voulait réduire la charge du helpdesk liée aux messages rebondis pendant une réorganisation.
Ils avaient des dizaines d’anciennes adresses départementales que les gens continuaient d’utiliser. Au lieu de maintenir une map d’alias, quelqu’un a proposé une « simplification intelligente » :
activer le catch‑all et utiliser des filtres pour router les mails selon des mots‑clés.
C’était astucieux en apparence. Ça a aussi changé leur profil de risque du jour au lendemain.
Soudain, toute chaîne de destinataire aléatoire était acceptée. Les filtres anti‑spam se sont retrouvés saturés. Le CPU de la passerelle mail a grimpé.
La boîte catch‑all est devenue une décharge, et — voici la partie qui a fait mal — le routage par mots‑clés a généré des faux positifs.
Des factures légitimes ont fini dans une boîte générale parce qu’elles contenaient des mots correspondant à une règle interne.
Quelques messages de fournisseurs ont été retardés à cause du tri automatisé qui a créé des contentions et des retries.
Et parce que le système ne rebondissait pas les destinataires inconnus, les expéditeurs externes ne corrigeaient pas les adresses ; le problème n’a jamais naturellement décayé.
Ils sont revenus en arrière et ont fait la chose ennuyeuse : maintenir une map d’alias correcte, garder une liste de redirections courte et temporaire, et rejeter les destinataires inconnus.
L’« optimisation » avait réduit une forme de bruit (les rebonds) en créant une forme plus large et plus coûteuse de bruit (mauvaises livraisons et charge de traitement).
Mini‑récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise
Une entreprise SaaS gérait l’email pour plusieurs marques sur une même infrastructure.
Ils avaient une règle stricte : pas de catch‑all sur les domaines primaires. Toute exception nécessitait une justification écrite et une date d’expiration.
La justification échouait généralement parce que « on pourrait rater quelque chose » n’est pas une exigence d’ingénierie ; c’est de l’anxiété.
À la place, ils utilisaient de l’aliasing structuré :
le mail transactionnel utilisait des sous‑domaines dédiés, le mail humain utilisait des comptes de rôle avec alias explicites, et toute adresse « legacy » recevait un alias temporaire avec date d’expiration.
Ils avaient aussi la validation des destinataires intégrée à leur annuaire — si l’utilisateur n’existait pas, RCPT était rejeté.
Un jour, une campagne de spam ciblée les a attaqués : d’énormes probes RCPT pour les variantes admin/info/support.
Leurs passerelles sont restées calmes. Les destinataires inconnus étaient rejetés immédiatement. Le volume de spam existait toujours, mais il ne pouvait pas se transformer en croissance de boîtes non bornée.
Plus important, leur supervision était propre : les rejets étaient visibles comme des rejets, pas comme « livré dans une boîte que personne ne lit ».
La revue post‑incident a été presque ennuyeuse. C’est un compliment.
Leur politique « correcte mais peu excitante » a empêché qu’une mauvaise journée ne devienne une baisse de délivrabilité sur un trimestre.
Alternatives plus sûres : garder le mail fiable sans le catch‑all
Principe : rejetez les destinataires inconnus, puis facilitez les destinataires connus
Vous n’avez pas besoin du catch‑all pour éviter de perdre des emails légitimes. Vous avez besoin de trois choses :
(1) des alias explicites pour ce que vous voulez réellement,
(2) un traitement sûr pour les messages mal adressés,
(3) de la visibilité sur ce que les gens ont essayé d’envoyer.
Alternative 1 : Maps d’alias explicites (avec ownership)
Maintenez une liste contrôlée d’adresses de rôle acceptées : support@, sales@, billing@, security@, etc.
Ajoutez des fautes de frappe connues (billingg@) si elles ont une vraie valeur, mais traitez‑les comme temporaires.
La propriété compte. Chaque alias doit avoir une équipe propriétaire et un engagement SLA, même si le SLA est « meilleurs efforts ».
Alternative 2 : Plus‑addressing pour utilisateurs et systèmes
Si vous avez besoin de flexibilité (tracking, adresses par service), utilisez le plus‑addressing :
user+tag@example.net. Vous pouvez accepter des tags infinis sans accepter des destinataires infinis.
Cela vous donne la sensation de « ne jamais perdre de mail » pour des adresses légitimes tout en rejetant les destinataires aléatoires.
Alternative 3 : Un puits contrôlé sur un sous‑domaine séparé
Si votre activité doit vraiment accepter des mails mal adressés pendant une migration, faites‑le sur un sous‑domaine dédié :
legacy.example.net ou oldmail.example.net.
- MX séparé et frontière de réputation séparée (dans la mesure du possible).
- Rétention stricte (par ex. 7–14 jours).
- Contrôle d’accès et audit stricts.
- Limites de taux et filtrage lourd.
Contenez le rayon d’impact.
Alternative 4 : Vérification SMTP des destinataires via intégration annuaire
Si vous avez un annuaire utilisateur réel (LDAP/AD) ou une base source de vérité, intégrez la validation des destinataires.
Pour les domaines virtuels, la source autoritaire est votre virtual_mailbox_maps ou équivalent.
C’est là que l’hygiène opérationnelle apparaît : provisioning/déprovisionnement automatisés, pas de comptes obsolètes, pas d’alias zombies.
Alternative 5 : Utiliser une adresse d’ingestion de ticketing (pas un catch‑all)
Beaucoup d’équipes activent le catch‑all parce qu’elles veulent « anything@domain arrive au support ».
Ne faites pas ça. Mettez en place un petit ensemble d’adresses d’intake (support@, help@, billing@) et routez‑les vers un système de tickets.
Pour tout le reste : rejetez.
Alternative 6 : Monitoring des « destinataires inconnus » sans accepter le mail
Une inquiétude légitime : « Comment saurons‑nous ce que les gens ont essayé d’envoyer ? »
Réponse : loggez et échantillonnez les rejets.
Agrégez les comptes de rejet RCPT TO et les top local parts rejetés. Vous obtenez de l’intel sans stocker la charge utile.
La charge utile est une entrée non fiable ; vous n’en avez pas besoin pour corriger l’hygiène des adresses.
Exigence de citation (idée paraphrasée) : Werner Vogels insiste souvent sur le fait qu’il faut concevoir pour la défaillance et automatiser la récupération ; l’email n’y échappe pas.
Erreurs fréquentes : symptôme → cause racine → fix
Voici les schémas que je vois lorsque le catch‑all est en cause. Ce ne sont pas des théories. Ce sont la liste « pourquoi mon pager hurle ».
1) Symptom: Inbound spam volume suddenly doubles
Cause racine : Votre domaine est détecté comme accept‑all ; les spammeurs augmentent le RCPT spraying.
Fix : Rejetez les destinataires inconnus à RCPT. Ajoutez des limites de taux. Maintenez des alias explicites pour comptes de rôle.
2) Symptom: Legitimate customer email “disappears”
Cause racine : Ce n’est pas disparu ; il est enterré dans une grosse boîte puits, ou retardé par l’indexation IMAP / les locks de boîte.
Fix : Supprimez le catch‑all. Si vous devez garder un puits temporairement, délivrez vers un pipeline de traitement non IMAP avec rotation et rétention.
3) Symptom: Your outbound mail lands in spam more often
Cause racine : Dégradation de la réputation de domaine due à des comportements bruyants, backscatter potentiel, et signaux opérationnels mauvais.
Fix : Arrêtez l’accept-all, assurez‑vous que DKIM est correct, publiez une politique DMARC sensée, et stabilisez l’hygiène entrante.
4) Symptom: Queue growth and high load during “random” periods
Cause racine : Des rafales de spam sont acceptées, puis s’empilent dans le scan de contenu/AV/livraison IMAP, saturant CPU ou disque.
Fix : Poussez le rejet plus tôt (vérifs RCPT), limitez le taux, et vérifiez la performance disque. Ne stockez pas ce que vous devriez rejeter.
5) Symptom: You receive complaints about bounce spam you “sent”
Cause racine : Backscatter dû à l’acceptation de messages puis renvoi de rebonds vers des expéditeurs usurpés.
Fix : Rejetez les destinataires invalides et les échecs de politique de contenu pendant le SMTP, évitez de générer des NDRs vers des expéditeurs non authentifiés/usurpés.
6) Symptom: A single mailbox consumes absurd storage
Cause racine : Catch‑all comme puits non borné, souvent sans quotas ni rétention.
Fix : Supprimez/roulez agressivement, définissez des quotas, et retirez la route catch‑all. Construisez plutôt un pipeline de monitoring des rejets.
7) Symptom: Security team finds sensitive third‑party data in your inbox
Cause racine : Des mails mal adressés provenant d’autres domaines (fautes de frappe) ont été acceptés silencieusement.
Fix : Arrêtez l’accept-all. Ajoutez un processus pour traiter les mails mal dirigés (notifier l’expéditeur, supprimer en sécurité, documenter).
8) Symptom: Internal teams rely on random addresses “because it works”
Cause racine : Le catch‑all crée des contrats internes mauvais ; les gens cessent de maintenir des adresses correctes.
Fix : Supprimez le catch‑all et forcez une interface explicite : alias définis, ownership, et gestion du changement.
Blague #2 : Le catch‑all est une excellente façon d’atteindre « zéro rebond » de la même manière que désactiver la supervision donne « zéro alerte ».
Listes de vérification / plan pas à pas
Étapes : Retirer le catch‑all sans casser le business
-
Inventoriez ce que le catch‑all attrape actuellement.
Extraites les local parts principales des logs (Task 5) et listez les 50–200 premières.
Décidez lesquelles sont des alias légitimes, lesquelles sont des fautes de frappe à conserver, et lesquelles sont du garbage. -
Créez des alias explicites pour les destinataires légitimes.
Gardez la liste courte et avec un propriétaire. Routez vers des équipes ou des systèmes de tickets, pas des boîtes personnelles par défaut. -
Implémentez le rejet des destinataires.
Faites échouer les destinataires inconnus à RCPT (Task 12). C’est la vraie solution. -
Ajoutez du monitoring pour les destinataires rejetés.
Alarmez en cas de pics. Échantillonnez les local parts rejetés. Vous voulez de la visibilité sans rétention du payload. -
Appliquez quotas/rétention sur toute boîte puits restante.
Si vous en gardez une temporairement, traitez‑la comme un déchet dangereux. Petite, scellée, et vidée selon un planning. -
Communiquez le changement.
Informez les équipes internes : les adresses inconnues rebondiront maintenant ; voici les adresses supportées. Cela évite la « roulette email ». -
Exécutez une période de grâce de migration avec des alias ciblés.
Pour les anciennes adresses, créez des redirections explicites qui expirent. Mettez la date d’expiration dans le ticket. -
Revérifiez l’authentification sortante.
Confirmez le DKIM et le statut DMARC (Tasks 13–14). Le retrait du catch‑all coïncide souvent avec un durcissement des politiques. -
Mesurez les résultats.
Suivez le volume de spam entrant, la profondeur de la queue, la croissance des boîtes, et le volume de tickets concernant des mails manquants.
Checklist : À quoi ressemble un état « bon » après le changement
- Un RCPT TO aléatoire reçoit un 550 au moment SMTP.
- Les adresses de rôle existent explicitement et sont surveillées.
- Le volume de spam entrant baisse et reste bas.
- La profondeur de la queue corrèle avec la charge réelle, pas des rafales aléatoires.
- Pas de motifs de backscatter dans les logs.
- La boîte catch‑all (si elle existe) est petite, tournée et limitée dans le temps.
- Les rapports DMARC sont examinés et actionnables (pas du papier peint).
Checklist : Si vous insistez pour garder le catch‑all (règles de confinement)
Parfois le business insiste. Très bien. Traitez‑le alors comme une fonctionnalité dangereuse :
- Limitez dans le temps : date d’expiration, propriétaire, et plan de rollback.
- Séparez‑le : idéalement un sous‑domaine et un MX séparés.
- Limitez le taux agressivement : connexions et messages.
- Ne le mettez pas sur IMAP : délivrez vers un pipeline de traitement, pas une boîte humaine.
- Rétention : supprimez rapidement. Ce n’est pas un archive.
- Revue sécurité : contrôle d’accès, audit et gestion des incidents pour les données mal dirigées.
FAQ
1) Une boîte catch‑all est‑elle toujours mauvaise ?
En production sur votre domaine principal : oui, c’est généralement un net négatif. L’usage acceptable rare est une aide de migration strictement contrôlée et limitée dans le temps,
idéalement sur un sous‑domaine séparé avec rétention et limites de taux strictes.
2) Rejeter les destinataires inconnus n’aide‑t‑il pas les spammeurs à énumérer des utilisateurs valides ?
Ça peut, mais en pratique les spammeurs essaient déjà des noms communs et des comptes de rôle. Vous mitigez l’énumération avec des limites de taux, des tarpits, et en n’exposant pas les commandes d’annuaire (VRFY/EXPN).
Accept‑all est pire : il garantit l’acceptation et invite à un abus de volume plus important.
3) Nous avons activé le catch‑all parce que des clients se trompent d’adresse. Que faire à la place ?
Créez des alias explicites pour les fautes de frappe à forte valeur (billingg@, saless@) et faites‑les expirer une fois que vous corrigez la source de l’erreur (site web, PDFs, enregistrements fournisseurs).
Utilisez les logs pour trouver les vraies fautes de frappe plutôt que de deviner.
4) Désactiver le catch‑all va‑t‑il nuire à la délivrabilité parce que nous aurons plus de rebonds ?
Vous aurez plus de rebonds précis, ce qui est positif. Cela force l’hygiène de liste chez les expéditeurs et réduit le volume de garbage entrant.
L’objectif n’est pas « zéro rebonds », c’est « ne rebondir que ce qui doit rebondir ».
5) Le plus‑addressing est‑il un risque de sécurité ?
Pas intrinsèquement. Il peut augmenter la surface d’adresses, mais reste lié à une boîte réelle et à un utilisateur.
C’est bien plus sûr que d’accepter n’importe quel local part aléatoire parce que vous rejetez toujours les utilisateurs inconnus.
6) Nous sommes sur Microsoft 365 / Google Workspace. Le catch‑all est‑il toujours un problème ?
Oui. Même les plateformes hébergées reflètent la même réalité : si vous acceptez des mails pour des destinataires inexistants, vous ingérerez plus de spam et créerez du désordre opérationnel.
La plateforme peut absorber une partie de la douleur, mais vos utilisateurs et la réputation de votre domaine en pâtiront.
7) Comment garder de la visibilité sur les mails mal adressés après la désactivation du catch‑all ?
Loggez les rejets RCPT et agrégez les local parts rejetés. Vous pouvez alerter sur des pics et maintenir un rapport « top destinataires rejetés ».
Cela vous donne l’intel sans stocker les payloads non fiables.
8) Qu’en est‑il d’un « catch‑all » qui ne capture que certains patterns ?
Le routage basé sur patterns peut être acceptable s’il est déterministe et étroit (par ex. user+tag), mais « n’importe quoi va au support » reste un catch‑all déguisé.
Si le pattern permet des noms arbitraires, vous acceptez de nouveau des entrées contrôlées par un attaquant à grande échelle.
9) Nous avons de nombreuses marques et devons tout recevoir parce que des partenaires devinent des adresses. Un compromis ?
Utilisez des comptes de rôle et un annuaire bien publicisé d’adresses. Si vous devez accepter des destinataires inconnus, faites‑le sur un sous‑domaine d’ingestion dédié avec rétention,
puis exigez que les expéditeurs corrigent l’adresse après une courte période de grâce. Ne laissez pas cela devenir permanent.
10) En combien de temps la délivrabilité se rétablit‑elle après la suppression du catch‑all ?
La réduction du volume de spam est immédiate. Les effets sur la réputation peuvent prendre des jours à des semaines selon le volume et comment les récepteurs scorent votre domaine/IP.
L’important est la cohérence : comportement stable, mail sortant authentifié, et pas de backscatter.
Étapes suivantes
Si vous avez actuellement un catch‑all sur votre domaine principal, les étapes pratiques suivantes sont simples :
- Exécutez le test SMTP (Task 1) et confirmez le comportement accept‑all.
- Extraites les top destinataires des logs (Task 5) et créez une courte liste d’alias avec propriétaire.
- Désactivez le catch‑all / restaurez la validation des destinataires (Tasks 2–3), puis retestez (Task 12).
- Contenez toute boîte puits temporaire avec quotas et rétention (Tasks 8 et 15).
- Surveillez la profondeur de la queue, l’usage disque et les signes de backscatter (Tasks 6, 9, 7).
La fiabilité email n’est pas une question d’héroïsme. C’est refuser d’accepter des absurdités, tôt, de manière cohérente, et avec des logs en qui vous pouvez avoir confiance.
Le catch‑all est l’opposé. Supprimez‑le, et votre système mail recommencera à se comporter comme un système d’ingénierie.