Une adresse e-mail catch-all dirige vers une destination les messages destinés à des adresses inconnues de votre domaine. Quelqu'un écrit slaes@yourcompany.com au lieu de sales@ : la règle peut récupérer ce contact. C'est utile, mais cela ne signifie pas accepter tout message sans filtre ni condition.
Ce filet de sécurité étend la réception à des adresses non créées. Il peut augmenter la charge de spam et nécessite de maîtriser les refus après acceptation ainsi que l'authentification en cas de transfert. La commodité doit être mise en regard du filtrage, du stockage et de la surveillance.
Ce guide explique le comportement SMTP, trois risques à examiner et des solutions pour garder la maîtrise du courrier. Pour le routage et la configuration, consultez le catch-all de domaine sans perdre le contrôle.
Qu'est-ce qu'une adresse catch-all ?
Un catch-all, parfois appelé adresse générique, affecte les destinataires inconnus d'un domaine valide à une boîte ou une route précise. Le serveur peut répondre “250 OK” à RCPT TO plutôt que “550 User unknown”. Accepter un destinataire n'est pas accepter définitivement le message après DATA : filtres et autres règles restent applicables.
Refuser un destinataire inconnu pendant SMTP, avant de recevoir son contenu, correspond à un refus par défaut. Le catch-all introduit une acceptation des destinataires inconnus, pas une obligation d'accepter spam ou logiciels malveillants. Fautes de frappe légitimes et adresses inventées peuvent partager une destination si le message passe les contrôles applicables.
Il peut aider pendant une migration ou dans un usage permanent bien délimité. Les contrôles doivent correspondre au trafic réel.
Le fonctionnement du catch-all en SMTP
La distinction intervient à RCPT TO, défini dans RFC 5321. Le serveur se prononce sur ce destinataire avant de recevoir le contenu de la transaction. Ces exemples simplifient l'échange : commandes et réponses ont déjà circulé, et l'acceptation définitive du message intervient ensuite.
Sans catch-all : refus du destinataire inconnu
SENDER: RCPT TO: <ghost@yourdomain.com>
YOUR SERVER: 550 5.1.1 User unknown
RESULT: Connection closed. Zero data transferred.Le refus concerne ce destinataire ; il n'impose pas de fermer la connexion. Le serveur émetteur décide comment prévenir l'expéditeur, sans nécessairement le faire immédiatement. Aucun contenu n'est accepté pour le destinataire refusé, mais un échange SMTP a déjà eu lieu et la transaction peut contenir d'autres destinataires valides.
Avec catch-all : destinataire inconnu admis
SENDER: RCPT TO: <ghost@yourdomain.com>
YOUR SERVER: 250 2.1.5 OK
RESULT: Server accepts headers, body, and attachments.
Routing logic directs mail to the catch-all mailbox.Cette réponse accepte le destinataire. Le serveur peut examiner le message pendant DATA et le refuser avant son acceptation définitive. S'il l'accepte, il doit gérer contenu, files, filtres et stockage. Refusez le trafic indésirable pendant SMTP lorsque pertinent, ou placez-le en quarantaine sans notification à une identité d'expéditeur falsifiée.
Trois risques opérationnels à examiner
Examinez trois domaines : la charge des sondes d'adresses, les avis de non-remise envoyés à des tiers innocents et l'authentification du transfert. Ces risques dépendent de la configuration et des contrôles.
1. Attaques de collecte d'adresses (DHA)
Des attaquants peuvent essayer des milliers de noms courants : admin, invoice, hr, accounts, david, noreply, info, billing. Ils cherchent à découvrir les adresses existantes et à envoyer aux destinataires qui semblent valides.
Sans catch-all, les réponses 550 peuvent révéler des adresses inexistantes, sans obliger l'attaquant à partir. Si chaque sonde reçoit 250 OK, il devient plus difficile de distinguer adresses créées et inventées. Cette moindre divulgation de l'annuaire peut s'accompagner d'une charge accrue de réception et de filtrage. Des milliers de messages à des destinataires fictifs peuvent compliquer la recherche du courrier utile.
2. Backscatter et réputation
Le backscatter survient lorsqu'un message accepté génère ensuite un avis de non-remise vers une identité d'enveloppe falsifiée, au détriment d'un tiers. Ce trafic peut affecter la réputation et être signalé sur des listes de blocage comme ips.backscatterer.org.
Exemple de configuration problématique :
- Un attaquant envoie un logiciel malveillant à random@yourdomain.com avec un MAIL FROM usurpant innocent@gmail.com.
- Le catch-all admet le destinataire, puis le serveur accepte le message sans le refuser pendant SMTP.
- Une analyse ultérieure détecte le logiciel malveillant et signale un échec interne.
- Si le serveur génère un avis de non-remise (NDR) vers innocent@gmail.com, il atteint une personne qui n'a pas envoyé le message.
- Le destinataire reçoit un retour non sollicité que son service peut considérer comme abusif.
Un volume élevé peut nuire à la réputation ou contribuer à un blocage. Préférez le refus pendant SMTP ou une quarantaine sécurisée sans retour ni réponse automatique à une identité falsifiée.
3. Transfert et authentification SPF
Certains administrateurs transfèrent *@company.com vers un compte Gmail personnel. Le catch-all ne casse pas SPF à lui seul : le transfert ajoute un serveur et doit être étudié à partir des identités SMTP et des résultats du destinataire.
Si l'intermédiaire conserve le MAIL FROM initial, par exemple bankofamerica.com, Gmail peut évaluer une IP non autorisée par le SPF de ce domaine. Le transfert avec SRS (Sender Rewriting Scheme) réécrit l'enveloppe ; le SPF du domaine utilisé doit autoriser l'IP du relais. Cela n'aligne pas automatiquement SPF sur le From initial. Un DKIM valide et aligné peut satisfaire DMARC sans SRS ni ARC. ARC nécessite une chaîne validée et un scelleur auquel le destinataire fait confiance ; il ne garantit pas l'acceptation. Examinez journaux, avis et classement du message.
Les solutions autres que le catch-all
Les alias explicites et l'adressage avec étiquettes peuvent couvrir de nombreux besoins sans admettre des destinataires arbitraires. Vérifiez leur compatibilité et leur comportement dans le service. Un catch-all peut aussi convenir s'il répond à un objectif clair avec des contrôles adaptés.
| Caractéristique | Catch-all | Alias explicites | Adressage avec étiquettes |
|---|---|---|---|
| Syntaxe | *@domain.com | sales@domain.com | user+tag@domain.com |
| Destinataires admis | Comprend les inconnus du domaine, sous réserve des contrôles | Adresses configurées selon le routage | Étiquettes de destinataires de base valides, si prises en charge |
| Risque de spam | Peut accroître la charge | Moins d'adresses admises ; filtres toujours nécessaires | Selon compatibilité, exposition et filtres |
| Coût chez TrekMail | Vérifier disponibilité et conditions du plan | Vérifier coûts et limites actuels | Vérifier prise en charge et conditions actuelles |
Les alias explicites définissent les adresses valides et permettent de refuser les autres selon la configuration SMTP. Ils constituent une base pratique pour de nombreux usages stables. Pour les organiser et distinguer alias et boîtes, consultez le transfert par alias e-mail et alias de domaine ou boîte mail.
Licences : comparer les besoins réels en boîtes
Une tarification par utilisateur peut inciter à chercher d'autres solutions. Dans un exemple historique à $6/utilisateur/mois chez Google Workspace, sales@, support@ et billing@ comme boîtes avec licences indépendantes coûteraient $18/mois pour trois adresses. Alias et boîtes partagées peuvent cependant avoir d'autres conditions : le catch-all n'est pas une nécessité de principe.
Le stockage mutualisé de TrekMail peut modifier ce calcul. Vérifiez la capacité partagée au niveau du compte, les quotas individuels des boîtes, les droits et les limites du plan actuel plutôt que de supposer des boîtes supplémentaires gratuites ou illimitées dans toutes les offres.
| Exemple historique de licences par utilisateur | Référence historique TrekMail | |
|---|---|---|
| 3 boîtes fonctionnelles | $18/mois (Google Workspace, exemple) | $3.50/mois au total (Starter, référence historique) |
| 50 boîtes | $300/mois dans l'exemple | $3.50/mois au total comme référence historique |
| Nécessité du catch-all | Selon conception ; alias et ressources partagées peuvent convenir | Selon besoins, fonctions et limites actuelles |
| Comportement SMTP | Peut refuser les destinataires inconnus | Vérifier validation et routes configurées |
La référence historique Starter à $3.50/mois mentionne jusqu'à 50 domaines et 100 boîtes par domaine ; vérifiez prix et limites actuels. Configurez sales@, support@, billing@, info@ et les adresses réellement nécessaires. La validation explicite limite les destinataires arbitraires, avec des filtres et contrôles à maintenir.
Une boîte de révision pour le catch-all
Pendant une migration avec annuaire incomplet, récupérer le courrier légitime d'anciennes adresses peut être utile. Choisissez une destination séparée à accès restreint. Le nom de quarantaine ne crée pas un environnement isolé sécurisé : filtres, permissions et prudence avec les pièces jointes restent nécessaires.
- Créer une boîte dédiée : catchall-quarantine@yourdomain.com, distincte de la boîte principale et à accès limité.
- Configurer le routage : n'y diriger que les destinataires inconnus du domaine autorisé.
- Éviter notifications et réponses : vérifier filtres et notifications du client, désactiver transferts et réponses automatiques de la boîte, et éviter les retours aux identités falsifiées sans supprimer les avis de non-remise légitimes requis.
- Examiner chaque semaine : repérer le courrier légitime et créer un alias après vérification du destinataire autorisé.
- Définir un critère de fermeture : 30 jours sans courrier légitime peuvent servir de repère ; décider selon cycles de trafic et besoins réels.
Le catch-all peut ainsi devenir un outil de diagnostic temporaire. Identifiez les anciennes adresses actives, créez des alias autorisés et réévaluez la règle. Un usage permanent nécessite sa propre justification et sa surveillance.
Agences : une couverture avec des adresses explicites
Pour 100+ domaines, préparer des alias standard peut être laborieux. Vérifiez si le tableau de bord et le plan TrekMail actuels proposent modèles ou opérations groupées. Une liste comme postmaster@, abuse@, accounts@, info@ doit correspondre à chaque client et à ses permissions. Contrôlez les résultats avant d'élargir une opération.
RFC 2142 décrit des boîtes de contact selon les services et responsabilités applicables. postmaster@ est obligatoire pour les domaines desservis par un service SMTP actif de remise ou de relais ; abuse@ dépend du service et du rôle concernés. Vérifiez accès, responsables et fonctionnement indépendamment du catch-all.
Quand le catch-all peut être utile
Voici trois exemples d'usages à délimiter :
- Migration active : vous quittez un ancien système sans disposer encore d'un annuaire complet.
- Acquisition de domaine : vous examinez un trafic historique inconnu avant de choisir les adresses à conserver.
- Environnements de test : des adresses fictives doivent recevoir sur un domaine de test sans création individuelle.
Dans ces trois cas, limitez le périmètre, utilisez une destination contrôlée et examinez quand arrêter la règle. D'autres usages légitimes existent : une configuration permanente bien administrée peut convenir si ses risques et objectifs sont clairs.
Évaluer le catch-all selon son utilité et ses coûts opérationnels
Récupérer une faute de frappe peut être utile, mais trois domaines demandent un suivi : charge de spam, backscatter causé par les avis ultérieurs à des identités falsifiées et authentification du transfert. Évaluez-les à partir de votre trafic et de la configuration effective.
Si le coût motive votre choix, comparez licences, alias, ressources partagées et stockage mutualisé. TrekMail peut permettre une organisation adaptée selon le plan actuel. Sales@, support@, billing@ et 47 autres adresses sont un exemple d'organisation, pas un engagement actuel de capacité ou de tarif unique.
Consultez un éventuel essai gratuit de 14 jours et les exigences actuelles de carte. Vérifiez aussi disponibilité et conditions Free/Nano, dont la formule sans carte ni essai. Seul le modèle Nano décrit nécessite votre propre SMTP externe pour tous les envois et réponses ; le SMTP géré des offres payantes dépend des droits actuels et des paramètres du client compatible.
