Hébergement catch-all : 8 vérifications avant activation

L'hébergement e-mail catch-all dirige vers une destination les messages pour les destinataires inconnus du domaine. C'est une règle du serveur de messagerie, pas un enregistrement DNS générique. Elle peut récupérer des fautes de frappe, sans assurer l'acceptation ou la remise de tous les messages.

Lors de la vérification du destinataire, le serveur peut remplacer 550 5.1.1 User Unknown par 250 OK en réponse à RCPT TO. Des sondes essaient admin@, invoice@, payroll@ ou careers@. Le catch-all masque la différence entre adresses créées et inventées dans cette réponse, mais peut accroître la charge. Le seuil historique Cisco de 25 destinataires invalides par heure est un exemple de politique configurée par hôte distant ou IP, pas une limite universelle du domaine. Une attaque intense peut essayer des milliers d'adresses par minute.

Filtres, quotas et politiques du fournisseur peuvent affecter le service pendant une attaque, sans suspension automatique. Les huit contrôles suivants aident à préparer les protections et à retrouver le courrier légitime parmi les messages indésirables.

Pour comprendre destinations de révision, tables de filtrage PCRE et prévention des boucles Exchange, commencez par le catch-all de domaine sans perdre le contrôle. Appliquez ensuite cette liste à votre configuration précise.

Ce que le catch-all change en SMTP

Le catch-all modifie la validation des destinataires dans l'enveloppe SMTP. Au lieu de refuser un destinataire inconnu avant DATA avec 550, le serveur peut l'affecter à une boîte de repli. Cela n'impose pas de filtrer seulement après acceptation : un contrôle pendant DATA peut encore refuser le message avant son acceptation définitive.

Les messages passant les contrôles peuvent générer files, analyses et stockage. Si un avis de non-remise est ensuite envoyé à un MAIL FROM falsifié, il s'agit de backscatter, une notification à un tiers innocent. Sortir d'une liste de blocage peut prendre 2-4 semaines dans un cas indicatif, sans délai fixe ni effet inévitable sur toute une plage d'IP.

Le choix associe souplesse pour les destinataires inconnus, charge de traitement et contrôles. Conservez le refus SMTP lorsque pertinent et évitez les notifications ultérieures aux identités falsifiées.

Les 8 contrôles de l'hébergement catch-all

Examinez huit points : filtrage avant acceptation définitive, traçabilité SMTP, protection contre le volume, authentification du transfert, identités de réponse autorisées, contrôle du backscatter, export et stockage. Évaluez-les selon le service et le trafic réels.

1. Filtrage SMTP avant acceptation définitive

Demandez quels contrôles s'appliquent à la connexion, aux destinataires et à DATA. Un 250 OK à RCPT TO n'est pas encore une acceptation définitive. Les filtres de contenu pendant DATA peuvent aussi refuser avant que le serveur assume la responsabilité du message.

Cet exemple montre un refus pendant SMTP :

postfix/smtpd[1234]: NOQUEUE: reject: RCPT from unknown[192.0.2.1]:
  550 5.7.1 Service unavailable; Client host blocked using zen.spamhaus.org;
  from=<probe@attacker.com>, to=<random123@yourdomain.com>

Ce résultat du filtre exige davantage de contexte :

amavis: Blocked SPAM {DiscardedInbound}, [192.0.2.1]
  <probe@attacker.com> -> <random123@yourdomain.com>, Score: 17.2

La ligne Amavis ne prouve pas seule quand le message a été accepté ou mis en file. Corrélez les journaux et la réponse finale de DATA. Demandez à quelles étapes le fournisseur filtre, s'il refuse pendant SMTP et comment il traite quarantaine et notifications ultérieures. L'existence d'un antispam ne suffit pas à décrire cette architecture.

2. Un accès utile aux journaux SMTP

Le catch-all supprime certains refus de destinataires inconnus. Si un client a écrit à billing@ sans réponse, un compteur ne dit pas ce qui s'est passé. Il faut des traces permettant de relier connexion, identifiant du message, filtre et routage.

Exemple de données à corréler :

Jan 03 10:14:22 mail postfix/smtpd: connect from mail.outlook.com[40.107.100.99]
Jan 03 10:14:23 mail postfix/cleanup: message-id=<20260103.ABC@outlook.com>
Jan 03 10:14:24 mail amavis: Passed CLEAN {RelayedInbound}, [40.107.100.99]
  <client@outlook.com> -> <billing@yourdomain.com>, Hit: -1.5

Google Workspace et Microsoft 365 proposent des outils administratifs dont le détail et l'actualisation dépendent du produit et des droits. Un délai de 30-60 minutes est un exemple, pas une durée universelle. Vérifiez accès autorisé, conservation, confidentialité et assistance pour enquêter sur un message précis.

3. Des limites de volume protégeant votre activité

Des sondes peuvent générer des milliers de destinataires fictifs. La réponse générique masque ceux qui existent, mais le volume peut consommer des ressources et déclencher des politiques. Vérifiez la limitation de la source, la protection du trafic légitime et les circonstances d'une restriction de compte.

Posez une question concrète : “Si nous recevons 10,000 messages en une heure lors d'une collecte d'adresses, comment limitez-vous la source et protégez-vous notre compte ?”.

4. SRS, ARC et authentification du transfert

Si un serveur A reçoit le catch-all puis transfère vers Gmail ou Outlook, examinez deux points d'authentification. Leur effet dépend du parcours et des résultats réels.

SPF : le destinataire voit l'IP du relais. Avec un enregistrement comme v=spf1 ... -all, garder le MAIL FROM initial peut faire échouer SPF si cette IP n'est pas autorisée.

DMARC : sans SPF aligné réussi ni DKIM valide et aligné, une politique p=reject demande le refus. Le traitement dépend du destinataire et n'est pas forcément une suppression silencieuse. Des modifications de parties signées peuvent affecter DKIM, qui peut aussi échouer pour d'autres raisons.

Vérifiez comment le service applique ces mécanismes :

• SRS (Sender Rewriting Scheme) : réécrit Envelope-From ; le SPF du domaine utilisé doit autoriser l'IP du relais. Il n'aligne pas automatiquement le From initial. Consultez le fonctionnement de SRS et ses échecs possibles.
• ARC (Authenticated Received Chain) : défini dans RFC 8617, transmet les résultats antérieurs dans une chaîne signée. Le destinataire doit la valider et faire confiance à un scelleur vérifié.

Ces codes correspondent à des causes différentes, pas à une preuve commune d'absence de SRS et ARC :

550 5.7.520 Access denied, your organization does not allow external forwarding.
550 5.7.1 Unauthenticated email from domain.com is not accepted
  due to the domain's DMARC policy.

Le premier indique une politique de transfert externe ; le second nécessite d'examiner DMARC et le contexte. DKIM aligné peut permettre DMARC sans SRS ni ARC. Confirmez fonctions documentées et résultats réels, sans conclure à une absence de support parce qu'une mention manque.

5. Alias et identités de réponse autorisées

Le catch-all permet de recevoir pour billing@, support@ ou project-2026@, mais ne donne pas le droit d'envoyer sous toute identité. Dans Gmail, répondre comme billing@yourdomain.com depuis le compte principal admin@yourdomain.com nécessite une identité “Send As” et la vérification applicable. Celle-ci concerne chaque identité configurée lorsque nécessaire, pas chaque message.

Vérifiez les identités autorisées prises en charge par le client, le SMTP et les droits nécessaires. Une procédure d'assistance ou une attente de 24 heures peut illustrer une friction, sans justifier l'envoi sous une adresse non vérifiée. Préparez les expéditeurs utiles avant de les employer.

6. Contrôle du backscatter et des avis de non-remise

Si le serveur accepte un message puis génère un NDR vers un MAIL FROM falsifié à cause d'un quota, du routage ou d'un filtre, il notifie un tiers innocent. C'est du backscatter, qui peut nuire à la réputation ou contribuer à une inscription sur Backscatterer.org. Cela ne constitue pas automatiquement un relais ouvert.

Demandez comment le service refuse pendant SMTP ou conserve une quarantaine sûre sans notifier des identités falsifiées. Ne supprimez pas automatiquement du courrier légitime ou ambigu sur un seul score : prévoyez révision et conservation. La réputation du domaine expéditeur dépend aussi de ces décisions.

7. IMAP et export vérifiable

Les boîtes catch-all peuvent accumuler rapidement des données. Avant une migration, confirmez l'export et sa vérification avec un accès autorisé et des outils compatibles. Prévoyez une sauvegarde et une synchronisation finale des messages reçus pendant le changement. IMAP est une option standard, mais un export adapté du fournisseur peut aussi convenir. Examinez les données incluses par chaque méthode et prévoyez séparément le transfert des contacts et calendriers.

Vérifiez au minimum :

• L'accès IMAP sur le port 993 avec TLS, si cette méthode est retenue.
• L'export .eml ou .mbox avec vérification du contenu et des dossiers.
• Des lectures groupées coordonnées avec limites, permissions et capacité du service.

POP3 ne conserve pas une hiérarchie de dossiers comme IMAP ; la suppression dépend de DELE et des options du client, pas d'une obligation par défaut du protocole. IMAP ne garantit pas seul une migration sans perte ni la conservation de toutes les métadonnées. Comparez dossiers, nombres de messages, exclusions et résultats de l'export.

8. Stockage et comportement au quota

Vérifiez le comportement quand la destination est pleine. Une réponse temporaire 452 4.2.2 Insufficient storage peut permettre des reprises, selon la politique et la durée de la file du serveur émetteur. Elle n'assure pas une remise ultérieure. Examinez alertes, journaux ou quarantaine pour éviter les pertes silencieuses au quota.

Demandez si le stockage est affecté par boîte ou partagé par compte, domaine ou autre périmètre. Consommer 80% d'un quota partagé pendant une attaque est un scénario indicatif, pas une proportion universelle. Des limites individuelles peuvent réduire l'impact, mais ressources partagées et alertes restent à examiner.

Évaluer le modèle TrekMail

TrekMail propose du stockage mutualisé selon compte et offre. Vérifiez la facturation des domaines et boîtes ainsi que les limites ; ne supposez pas des boîtes illimitées ou un stockage distinct par domaine. Configurez jobs@, billing@, support@, archive@ et les adresses nécessaires, en comparant aussi alias et ressources partagées.

Une référence historique de $6-$12/mois par utilisateur peut inciter à chercher d'autres solutions pour une adresse recevant trois messages par mois. Alias, boîtes partagées et licences existantes peuvent toutefois éviter de nouveaux comptes. Comparez l'ensemble :

Pour un besoin de routage ancien, de compatibilité ou de contacts, vérifiez réception, traces, IMAP et SRS disponibles actuellement. La référence historique Starter est $3.50/mois pour 50 domaines avec stockage mutualisé. Vérifiez un éventuel essai de 14 jours avec carte. La référence gratuite mentionne 10 domaines, 5GB mutualisés et SMTP externe ; confirmez éligibilité et conditions Free/Nano sans carte. 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 d'un client compatible.

Conclusion

L'hébergement catch-all est un outil, pas un réglage à activer par défaut. Examinez filtrage, volume, traçabilité, transfert et quotas avec le fournisseur. Sortir d'une liste de blocage peut prendre des semaines, sans délai fixe. Préparez la réponse aux attaques et les contrôles du courrier légitime avant de dépendre de cette règle.

Identifiez l'acceptation définitive du message, la prévention du backscatter et la préservation de l'authentification. Résoudre les conséquences du backscatter peut prendre des semaines, selon l'incident et le destinataire. Comparez ensuite export, stockage et identités autorisées. Pour réduire les coûts, évaluez tarifs actuels, alias et boîtes adaptés ; changer de facturation ne supprime pas à lui seul les risques opérationnels.

Découvrez TrekMail et vérifiez tarifs, boîtes IMAP et conditions actuelles du catch-all.