Catch-all de domaine : routage, quarantaine et transfert

Vous activez un catch-all de domaine pour ne pas perdre de prospects lorsqu’une personne écrit saels@ au lieu de sales@. C’est compréhensible. Mais le serveur accepte alors des destinataires auparavant inconnus, y compris les sondes d’attaques de collecte d’adresses. Des notifications à des expéditeurs usurpés, des boucles de réponse automatique et des problèmes de livraison lors du transfert peuvent apparaître. Ces effets ne sont pas inévitables, mais l’architecture mérite d’être préparée avant l’activation.

Beaucoup de guides s’arrêtent à « activez le catch-all et envoyez tout dans une boîte ». Le travail opérationnel commence pourtant là. Ce guide traite des boîtes de quarantaine, du routage par expressions régulières dans Postfix, de la prévention des boucles et des échecs d’authentification lors du transfert. Consultez d’abord le guide de configuration du transfert d’e-mails pour les bases ; cet article se concentre sur le catch-all de domaine.

Qu’est-ce qu’un catch-all de domaine ?

Un catch-all est une règle du MTA qui accepte les messages destinés à une adresse du domaine sans correspondance avec un destinataire connu, qu’il s’agisse d’une boîte, d’un alias ou d’un groupe. Au lieu de répondre 550 User Unknown, le serveur peut répondre 250 OK et diriger le message vers une destination de secours. L’acceptation du destinataire ne vaut pas acceptation finale du message après DATA. La règle agit sur le destinataire de l’enveloppe SMTP ; elle ne rend pas l’authentification invalide à elle seule.

Enveloppe et en-têtes : pourquoi les distinguer

Comprendre ces deux couches aide à examiner le routage, l’authentification et les notifications. Tous les problèmes du catch-all ne découlent pas de cette distinction. Une correction de deux minutes une fois la cause identifiée est un exemple, pas un délai de diagnostic promis.

RFC 5321 définit l’enveloppe SMTP, notamment les commandes RCPT TO et MAIL FROM échangées pendant la conversation SMTP. RFC 5322 définit les en-têtes du message, dont les champs To: et From: affichés par le logiciel de messagerie.

Le MTA peut router un destinataire d’enveloppe inconnu vers une adresse de secours sans modifier les en-têtes. Le To visible ne détermine pas nécessairement le destinataire de l’enveloppe. SPF vérifie l’IP de connexion et le domaine de MAIL FROM ou, selon le cas, HELO ; DKIM vérifie cryptographiquement les parties signées des en-têtes et du corps ; DMARC exige qu’au moins une vérification SPF ou DKIM réussisse et soit alignée sur le From visible. Le routage local du destinataire ne casse pas ces vérifications à lui seul. Un transfert externe peut affecter SPF, et modifier des parties signées peut invalider DKIM.

Le risque lié au transfert

Transférer le catch-all vers Gmail ou Outlook.com ajoute un relais qui peut changer les résultats d’authentification :

1. Expéditeur initial : client@bank.com (IP : 1.2.3.4)
2. Votre serveur accepte typo@yourdomain.com et transfère vers you@gmail.com
3. Gmail reçoit une connexion de l’IP de votre serveur ; l’enveloppe peut encore utiliser bank.com
4. SPF échoue si cette IP n’est pas autorisée par l’enregistrement SPF de bank.com
5. Si bank.com publie DMARC p=reject et qu’aucun DKIM valide et aligné ne subsiste, le destinataire peut refuser le message ; un rejet SMTP peut entraîner une notification, sans qu’elle soit toujours visible pour l’utilisateur

Le transfert demande ses propres vérifications. SRS (Sender Rewriting Scheme) réécrit l’expéditeur de l’enveloppe : l’enregistrement SPF du domaine utilisé doit autoriser l’IP du relais. Ce domaine n’est pas automatiquement aligné sur le From initial ; une signature DKIM valide et alignée qui survit au transfert peut suffire pour DMARC. Le transfert par alias de TrekMail décrit prévoit une gestion de SRS dans les configurations compatibles ; vérifiez les fonctions et conditions actuelles. Dans le modèle Nano décrit, tous les envois, réponses comprises, nécessitent votre propre service SMTP externe ; l’envoi géré des forfaits payants dépend des droits du forfait et d’une configuration client compatible.

Trois risques du catch-all de domaine

Avant de modifier la configuration, examinez trois risques : notifications à des expéditeurs usurpés, boucles de réponse automatique et échecs d’authentification lors du transfert. Corriger un risque sans tester les autres peut transformer une intervention prévue de cinq minutes en une semaine de remise en état : c’est un exemple de travail supplémentaire, pas une durée inévitable.

1. Backscatter : un risque pour la réputation

Le backscatter peut se produire lorsque le serveur accepte un message catch-all (250 OK), puis génère un rapport de non-remise (NDR) après l’avoir rejeté. Si le MAIL FROM est usurpé, la notification atteint une personne qui n’a rien envoyé. Ces réponses non sollicitées peuvent nuire à la réputation et contribuer à des inscriptions sur des listes de blocage ; aucun délai n’est inévitable.

Rejetez pendant SMTP les destinataires qui sortent des règles d’acceptation, avant le 250 OK correspondant. Pour le trafic accepté, prévoyez quarantaine et examen lorsque nécessaire, en évitant les NDR non sollicités vers des adresses potentiellement usurpées. Il ne s’agit pas d’interdire toute notification légitime de non-remise ni de supprimer par défaut des messages légitimes.

2. Boucles de réponse automatique (erreur Exchange 5.4.14)

Le catch-all dirige les messages vers un destinataire de secours qui peut avoir une réponse d’absence (OOF). Un message à random@yourdomain.com avec un expéditeur usurpé pourrait déclencher une réponse, un retour en erreur et, si la route le renvoie vers random@yourdomain.com, une nouvelle acceptation. Cet ensemble de règles peut former une boucle. Exchange pourrait renvoyer 550 5.4.14 Hop count exceeded - possible mail loop.

Sur les systèmes compatibles, notamment Exchange, appliquez X-Auto-Response-Suppress: All au trafic routé par caractères génériques pour limiter les réponses d’absence et les confirmations, dont les accusés de lecture. Ce contrôle n’est pas universel : vérifiez les règles automatiques, Auto-Submitted et les routes de retour, puis testez le comportement réel.

3. Attaques de collecte d’adresses (DHA)

Si toutes les adresses reçoivent 250 OK, un attaquant peut essayer des milliers de combinaisons telles que admin@, hr@, ceo@ et invoice@. Un catch-all global accepte ces destinataires, mais ne confirme pas lesquels correspondent à de vraies boîtes. Il peut néanmoins accroître le trafic indésirable et le travail de tri ; des envois ciblés pourraient se prolonger pendant des années, sans que cette durée soit inévitable.

Les caractères génériques partiels de la stratégie 2 permettent de limiter la couverture, sans garantir le blocage de la majorité des attaques.

Stratégie 1 : une boîte distincte pour examen et quarantaine

Si vous avez besoin d’un catch-all, une boîte distincte permet d’examiner le trafic inconnu sans le mêler à la boîte principale. Ce n’est pas un environnement de sécurité isolé : limitez les accès, maintenez les filtres et désactivez les transferts, réponses d’absence et autres actions automatiques non autorisées. Vérifiez ces réglages dans la boîte et les règles du serveur ; un en-tête de suppression ne remplace pas ces contrôles.

Logique de mise en œuvre :

1. Accepter : le serveur accepte *@domain.com
2. Étiqueter : identifier le destinataire comme inconnu, sans correspondance avec une boîte, un alias ou un groupe autorisé
3. Isoler : diriger vers une boîte dédiée, par exemple catchall_sink@domain.com
4. Limiter les réponses : dans Exchange, déterminer s’il convient de demander avec Spam Confidence Level 9 le traitement des indésirables à forte probabilité et appliquer X-Auto-Response-Suppress: All sur les systèmes compatibles

Un examen hebdomadaire peut servir de point de départ, à adapter au volume et à l’urgence des messages. Déplacez le courrier légitime vers la bonne boîte et définissez la conservation du reste. Prévoyez capacité, stockage et supervision pour que la quarantaine ne devienne pas un autre endroit où des demandes passent inaperçues.

Règle de transport Microsoft 365 / Exchange Online

Dans M365, cet exemple nécessite un examen des domaines acceptés, des connecteurs, de l’inventaire des destinataires et des routes par un administrateur autorisé. Le mode Internal Relay désactive Directory Based Edge Blocking (DBEB), mais ne met pas en place un catch-all à lui seul et ne convient pas si tous les destinataires sont dans le service cloud. Les autres destinataires nécessitent un connecteur vérifié vers un serveur de messagerie propre et autorisé. Ne changez pas ce mode à l’aveugle : vérifiez les destinations et l’absence de boucles. La règle suivante est un schéma à adapter ; l’appartenance à un groupe ne remplace pas un inventaire complet des boîtes, alias et autres destinataires valides :

Planifiez et testez l’ordre d’activation de la règle et de toute modification du mode Internal Relay. Vérifiez au préalable les connecteurs, la validation des destinataires et les routes finales pour éviter une période d’acceptation sans contrôles ou des boucles.

Stratégie 2 : caractères génériques partiels avec PCRE dans Postfix

Une règle partielle accepte des motifs précis sans ouvrir tout le domaine. Définissez les expressions régulières attendues et configurez séparément la validation des autres destinataires. L’absence de correspondance dans une table ne provoque pas à elle seule un rejet SMTP : la classe du domaine, les autres tables et les restrictions de destinataire interviennent aussi.

Dans Postfix, vous pouvez utiliser une table d’alias virtuels PCRE (Perl Compatible Regular Expression). Avant de recharger, vérifiez que la prise en charge PCRE est installée et testez la table avec les correspondances attendues et indésirables. Le commentaire de l’exemple ne garantit ni la validation des destinataires ni la couverture de toutes les fautes citées.

# /etc/postfix/virtual_pcre

# Catch any address starting with "sales-" (sales-q1, sales-webinar, etc.)
/^sales-.*@yourdomain\.com$/    sales-team@yourdomain.com

# Catch common "support" typos (suport, supprt)
/^supp?o?rt@yourdomain\.com$/   support@yourdomain.com

# No wildcard below = hard 550 reject for everything else

Avant d’adapter /etc/postfix/main.cf, sauvegardez la configuration et examinez les tables existantes. Cette affectation remplace la valeur actuelle ; intégrez la nouvelle table sans perdre les autres routes :

virtual_alias_maps = pcre:/etc/postfix/virtual_pcre

Après validation des motifs, des destinataires et des routes, un administrateur autorisé peut recharger : postfix reload

Pour une couverture plus large, ajoutez des motifs prudents pour les adresses courantes plutôt qu’un catch-all global :

/^(info|contact|hello|team)@yourdomain\.com$/    info@yourdomain.com

Vous pouvez ainsi limiter les destinataires acceptés aux adresses nécessaires, à condition que la validation du MTA soit configurée et testée.

Quand un catch-all de domaine est pertinent

Un catch-all peut être utile dans des situations délimitées. Les usages temporaires suivants sont fréquents, mais ne sont pas les seuls usages légitimes. Son maintien dépend des contrôles et du besoin opérationnel.

Usages légitimes :

• Adresses de campagnes courtes : utiliser promo-jan@, promo-feb@ et promo-mar@ sans créer chaque destinataire manuellement
• Accueil de nouveaux clients : recevoir des messages avant la fin de la création formelle des adresses
• Migration d’un ancien système : couvrir pendant la bascule des adresses actives encore absentes de l’inventaire

Dans ces cas, réévaluez quand retirer le catch-all et créer des boîtes ou alias explicites pour les adresses connues. Si vous hésitez entre les types de destinataires, consultez alias de domaine ou boîte mail ; leurs différences aident à choisir une structure durable.

Usage peu judicieux : activer un catch-all uniquement pour éviter un supposé tarif de $6/utilisateur/mois pour trois alias. Les alias n’exigent pas automatiquement leur propre licence : vérifiez le modèle du fournisseur. Traitez le coût réel plutôt que d’ajouter une architecture difficile à maintenir six mois plus tard.

TrekMail : choisir une architecture plutôt qu’un contournement

La tarification par utilisateur peut influencer le choix d’un catch-all. Le modèle TrekMail décrit repose sur des forfaits à prix fixe et un stockage partagé au niveau du compte, également soumis aux limites applicables à chaque boîte. Ce n’est pas un tarif universel par domaine ou par boîte. Dans les limites du forfait, il peut réduire l’intérêt financier d’un catch-all utilisé à la place d’alias explicites. Vérifiez les tarifs, quotas et fonctions actuels.

Le Starter décrit ($3.50/mois) permet de créer des adresses explicites dans ses limites. Vérifiez les conditions actuelles avant de souscrire. Si un catch-all est nécessaire, examinez sa disponibilité dans les paramètres du domaine et associez-le à des destinataires définis pour les adresses régulièrement utilisées. Pour partir de zéro, le guide de configuration de l’e-mail sur votre domaine présente DNS, SPF/DKIM/DMARC et la création des boîtes.

Liste de vérification avant l’activation du catch-all

Avant l’activation, examinez ces points et testez la route complète. Les contrôles réduisent les risques, sans supprimer le travail d’exploitation :

1. Validation à l’entrée SMTP : rejeter pendant la connexion les adresses hors des motifs acceptés par le catch-all ; éviter les notifications ultérieures non sollicitées vers des expéditeurs usurpés.
2. Réponses automatiques maîtrisées : appliquer X-Auto-Response-Suppress: All sur les systèmes compatibles et vérifier OOF, Auto-Submitted et les routes pour prévenir les boucles.
3. Quarantaine prête : prévoir une boîte distincte des boîtes opérationnelles, avec capacité, examen et conservation définis.
4. Classement des indésirables vérifié : adapter la politique de quarantaine et organiser une revue régulière pour retrouver les messages légitimes, sans les supprimer par défaut.
5. SPF et DMARC vérifiés : en cas de transfert, examiner SRS, l’autorisation du domaine réécrit et au moins une voie SPF ou DKIM valide et alignée pour DMARC.
6. Motifs PCRE lorsque pertinents : préférer des caractères génériques partiels s’ils couvrent le besoin et tester la validation du MTA pour les autres adresses.
7. Notifications NDR maîtrisées : éviter les retours non sollicités vers des expéditeurs potentiellement usurpés, tout en traitant correctement le courrier légitime.

Conclusion

Un catch-all de domaine peut être utile avec des routes testées, une validation SMTP hors des motifs acceptés, une quarantaine et un contrôle des réponses automatiques. L’activer sans examiner l’architecture peut accroître les risques de backscatter, de boucles et de problèmes lors du transfert en quelques semaines, sans rendre ces problèmes ou ce délai inévitables. Testez et surveillez le fonctionnement réel.

Si vous cherchez à éviter une tarification par utilisateur, vérifiez d’abord les licences réellement nécessaires aux boîtes et aux alias. L’hébergement TrekMail à prix fixe décrit permet de choisir des destinataires explicites dans les limites du forfait, et de réserver le catch-all à un besoin opérationnel. Consultez l’essai gratuit et ses conditions actuelles avant de configurer le domaine.