Alias, redirection et e-mail attrape-tout : pratique, mais pas sans risques

Module 3: Gérer votre boîte mail · Temps de lecture : 11 minutes

Objectif pédagogique : À l'issue de cette leçon, vous saurez choisir entre une boîte mail, un alias, une redirection et une adresse "attrape-tout" (catch-all), et expliquer pourquoi la redirection vers une adresse externe et le catch-all peuvent nuire à la délivrabilité de vos e-mails.

Notions clés : boîte mail, alias, forwarder (redirection), redirection interne et externe, SPF cassé par la redirection, SRS (Sender Rewriting Scheme), DKIM lors d'une redirection, ARC (RFC 8617), catch-all, attaque par dictionnaire, backscatter, envoi au nom d'une autre adresse

Quatre façons de faire fonctionner une adresse

Si vous souhaitez faire fonctionner offerte@example.com, vous avez quatre options :

Dans certains panneaux, un alias est techniquement identique à une redirection vers une adresse sur le même serveur. La différence qui compte est la suivante : le courrier reste-t-il sur le même serveur, ou repart-il vers l'extérieur ?

Redirection au sein de votre propre domaine : aucun problème

Si vous redirigez offerte@example.com vers info@example.com, et que les deux se trouvent sur le même serveur, le serveur livre simplement le courrier dans la boîte mail de info@. Rien ne transite par internet, rien n'est recontrôlé. C'est sûr et fiable.

Redirection vers l'extérieur : là où ça se complique

C'est différent si vous redirigez vers une adresse chez un autre prestataire, par exemple une adresse personnelle chez Gmail ou Outlook.com. Votre serveur envoie alors le courrier à nouveau, cette fois vers Gmail. Et Gmail contrôle le courrier comme s'il provenait de votre serveur.

Supposons que klant@example.net envoie un e-mail à info@example.com. Votre serveur le redirige vers Gmail. Que voit Gmail ?

• Expéditeur (From) : klant@example.net.
• Expéditeur d'enveloppe : toujours klant@example.net, sauf si votre serveur le réécrit.
• Serveur d'envoi : votre serveur, par exemple 192.0.2.25.

Gmail consulte l'enregistrement SPF de example.net. Votre serveur n'y figure évidemment pas. SPF échoue (fail). Si example.net applique une politique DMARC p=reject, et qu'aucune signature DKIM valide ne figure sur le courrier, Gmail refuse le message. Votre serveur reçoit alors un bounce qui est renvoyé... à l'expéditeur d'origine, qui reçoit maintenant un message d'erreur provenant de votre serveur.

Trois mécanismes atténuent ce problème :

1. DKIM survit (généralement)

Une signature DKIM (leçon 4.3) fait partie intégrante du message. Si votre serveur redirige le courrier sans le modifier, la signature de example.net reste valide. DMARC réussit alors sur le critère DKIM, même si SPF échoue. C'est pourquoi DKIM est si important : c'est le seul mécanisme qui survit à une redirection.

Mais cela échoue si le serveur de redirection modifie le message : ajout d'un texte en bas de page ("transféré par..."), modification de l'objet (ajout de [SPAM]), ou conversion de la mise en forme. La signature n'est alors plus valide.

2. SRS réécrit l'expéditeur d'enveloppe

Avec SRS (Sender Rewriting Scheme), le serveur de redirection transforme l'expéditeur d'enveloppe en une adresse de son propre domaine, par exemple :

SRS0=HHH=TT=example.net=klant@example.com

Gmail consulte alors l'enregistrement SPF de example.com, où votre serveur figure bien. SPF réussit (pass). Si un bounce se produit, votre serveur peut retraduire l'adresse et renvoyer le bounce au véritable expéditeur.

Attention : SRS résout le problème SPF, mais pas DMARC. L'alignement (leçon 4.4) compare le domaine de l'expéditeur d'enveloppe avec l'adresse From. Celui-ci est désormais example.com face à example.net : non aligné. DMARC doit donc toujours réussir sur le critère DKIM.

3. ARC : une attestation de l'intermédiaire

ARC (Authenticated Received Chain, RFC 8617, expérimental) permet à un intermédiaire de consigner ce qu'il a constaté : "lorsque ce message m'est parvenu, SPF, DKIM et DMARC ont réussi". Le serveur de redirection signe cette attestation. Le destinataire final peut décider de faire confiance à cette attestation s'il fait confiance à l'intermédiaire. De grands destinataires comme Gmail et Microsoft utilisent ARC, mais vous ne pouvez pas compter dessus : c'est une faveur, pas un droit.

Et le spam ?

Il existe un autre problème, souvent le plus important. Votre filtre antispam ne bloque pas tout. Tout le spam qui passe est désormais redirigé par votre serveur vers Gmail. Pour Gmail, tout se passe comme si votre serveur envoyait du spam. La réputation de votre serveur en pâtit (et sur un hébergement mutualisé : celle de tous les clients de ce serveur). Gmail place alors plus facilement votre courrier légitime en spam par la suite.

Quelle est la meilleure solution ?

Souhaitez-vous lire votre courrier professionnel dans l'application Gmail ou Outlook ? Ajoutez alors la boîte mail en tant que compte IMAP (module 2). L'application récupère le courrier directement depuis votre serveur. Rien n'est redirigé, rien n'échoue, et aucun spam ne sort vers l'extérieur. Si vous devez malgré tout rediriger, configurez un filtre antispam strict avant la redirection.

Catch-all : pourquoi presque jamais

Un catch-all capte tout le courrier adressé à des adresses qui n'existent pas. Une faute de frappe comme inof@example.com arrive alors quand même. Cela paraît pratique, mais :

• Spam. Les spammeurs envoient massivement du courrier à des adresses inventées sur des domaines existants (a.jansen@, sales2@, xkq7@). C'est ce qu'on appelle une attaque par dictionnaire. Sans catch-all, votre serveur refuse tout cela immédiatement. Avec un catch-all, tout arrive, souvent des centaines de messages par jour.
• Plus de message d'erreur. Celui qui se trompe dans votre adresse ne reçoit plus de bounce et pense que son message est bien arrivé. Sans catch-all, il sait immédiatement que l'adresse est incorrecte.
• La redirection aggrave les choses. Un catch-all qui redirige vers Gmail envoie tout ce spam vers Gmail.
• Backscatter. Un serveur qui accepte d'abord tout et ne découvre que plus tard qu'une adresse n'existe pas envoie un bounce à l'expéditeur (falsifié). C'est ce qu'on appelle le backscatter : des messages d'erreur envoyés à des personnes innocentes, et une raison de se retrouver sur une liste de blocage.

Vous souhaitez capter quelques adresses supplémentaires, comme une faute de frappe fréquente ou une ancienne adresse ? Créez pour cela des alias ou des redirections distincts. Utilisez-vous une adresse propre par site web ou boutique en ligne (webshop-x@), pour savoir qui revend votre adresse ? Créez alors cette adresse en tant qu'alias au moment où vous l'utilisez.

Envoyer depuis un alias

Un alias peut également servir d'expéditeur. Vous souhaitez par exemple répondre en tant que offerte@example.com alors que vous êtes connecté en tant que info@. C'est possible, mais :

• De nombreux serveurs de messagerie vérifient aujourd'hui quelle adresse d'expéditeur correspond à quel identifiant de connexion. Vous ne pouvez alors envoyer que depuis votre propre adresse et les alias ou redirections qui pointent vers votre boîte mail. Une adresse quelconque différente sera refusée ("account can not send emails from ..."). Cela protège contre les abus.
• Dans votre programme de messagerie, vous ajoutez l'alias comme identité supplémentaire (Thunderbird : Gérer les identités ; Apple Mail : adresses supplémentaires dans le compte, séparées par des virgules ; Outlook : afficher le champ De et saisir l'adresse).
• SPF, DKIM et DMARC fonctionnent normalement, tant que l'alias se trouve sur le même domaine et que vous envoyez via votre propre serveur.

En pratique : à quoi cela ressemble dans un panneau

Dans DirectAdmin, vous créez les redirections dans Gestion E-mail, Redirections. Le catch-all se trouve dans Fonctionnalités avancées, E-mail "attrape-tout" ; là, "désactiver le catch-all" est le réglage recommandé (le courrier adressé à des adresses inexistantes est refusé). Si vous avez uniquement un nom de domaine sans forfait, les redirections se trouvent dans Mon WebOké sous Mes domaines, Redirections. D'autres panneaux (cPanel, Plesk, Microsoft 365, Google Workspace) proposent des fonctionnalités similaires, parfois sous des noms comme "alias", "redirection" ou "groupes".

Résumé

• Un alias ou une redirection au sein du même serveur est sûr.
• La redirection vers l'extérieur casse SPF. SRS répare SPF, mais pas l'alignement DMARC ; seule une signature DKIM intacte sauve le courrier, et ARC peut aider.
• Le spam redirigé nuit à la réputation de votre serveur. Lisez plutôt le courrier externe via IMAP dans l'application.
• Un catch-all attire le spam, masque les fautes de frappe et peut provoquer du backscatter. Utilisez des alias distincts.
• Envoyer depuis un alias est possible, dans le respect des règles de votre serveur.

Quiz

Exercice

Exercice O3.3 : Inventaire de vos adresses. Établissez une liste de toutes les adresses de votre domaine : boîtes mail, alias, redirections, et indiquez si un catch-all est activé. Notez pour chaque redirection si elle reste au sein de votre propre domaine ou part vers l'extérieur (Gmail, Outlook.com, une autre entreprise). Répondez ensuite : quelle redirection externe pouvez-vous remplacer par un compte IMAP dans l'application, et un catch-all actif peut-il être désactivé ? Remplissez la liste de vérification.

Pour aller plus loin

Les étapes décrites dans ces articles s'appliquent aux panneaux de WebOké ; chez d'autres prestataires, le fonctionnement est comparable.

• Guide DirectAdmin 7.5: Redirections : transférer des e-mails vers une autre adresse
• Guide DirectAdmin 7.6: E-mail "attrape-tout" : courrier adressé à des adresses inexistantes
• Transfert d'e-mails vers une autre adresse (redirections, l'adresse de capture globale étant déconseillée)
• Envoyer depuis plusieurs alias, erreur : Account xxx can not send emails from
• Guide WebOké 5.9: Redirections e-mail et de domaine
• Cours DNS gratuit 4.3: SPF : qui a le droit d'envoyer des e-mails au nom de votre domaine ?
• RFC 8617 (ARC), RFC 7208 annexe D (SPF et intermédiaires tels que les services de redirection)