Alias mail, reprenez le contrôle de vos courriels
Publié le 11 min de lecture
Mis à jour le
Dans cette série23 min de lecture au total
- Alias mail, reprenez le contrôle de vos courriels
- Réduire sa surface d'attaque sur Discord
- Liens utiles pour la vie privée et la sécurité
Un alias mail est une adresse publique que vous communiquez à la place de la vraie. Un service de relais reçoit le courrier envoyé à cette adresse et le transfère vers la boîte que vous consultez réellement, si bien que l’expéditeur n’apprend jamais où le message atterrit. Comme chaque alias est jetable et indépendant, une fuite, une revente de données ou une vague de spam reste confinée à une seule adresse que vous pouvez désactiver sans toucher au reste de votre identité.
La plupart des gens traitent leur adresse mail comme un numéro de téléphone : une valeur, donnée à tout le monde, impossible à changer sans douleur. Cette adresse unique devient la clé de jointure qui relie votre banque, vos forums, vos comptes marchands et toutes les fuites qui les ont touchés. Un alias casse ce lien. Cet article explique comment fonctionnent les alias au niveau du protocole, du relais de transfert aux réponses par reverse-alias et à l’authentification qui garde le courrier transféré hors du dossier spam, puis énonce clairement ce que le modèle protège et ce qu’il ne protège pas.
Comment fonctionne un alias mail
Un alias n’est pas une seconde boîte. C’est une règle de routage hébergée par un Mail Transfer Agent (MTA), le logiciel qui accepte et relaie le courrier, exploité par un fournisseur d’alias comme SimpleLogin (propriété de Proton) ou Addy.io (ex-AnonAddy). Le fournisseur publie un enregistrement Mail Exchanger (MX), l’entrée du Domain Name System qui désigne le serveur responsable du courrier d’un domaine, de sorte que tout message adressé à un alias est d’abord livré à son relais, pas à vous.
De là, le relais applique une correspondance : shop@votrealias.com transfère vers votre vraie boîte, news@votrealias.com transfère au même endroit, et ainsi de suite. Une seule boîte privée se cache derrière de nombreuses adresses publiques. Les alias existent sous deux formes. Les alias créés individuellement sont enregistrés à l’avance via l’application ou l’extension du fournisseur. Un domaine catch-all accepte n’importe quelle partie locale à la volée : avec *@votredomaine.com pointé vers le relais, vous pouvez inventer random-2026@votredomaine.com sur la page de paiement et cela fonctionne immédiatement, sans enregistrement préalable.
La valeur du modèle réside dans la correspondance elle-même. Comme chaque service reçoit sa propre adresse, une fuite s’auto-attribue : si shop@votrealias.com reçoit soudain du spam de casino, vous savez quelle entreprise a vendu ou perdu vos données, et vous pouvez révoquer cette seule adresse pendant que tous les autres alias continuent de fonctionner.
Le chemin de transfert, étape par étape
Quand quelqu’un écrit à votre alias, le message ne voyage pas directement vers vous. Il suit le relais à travers une courte séquence de transformations qu’une conversation Simple Mail Transfer Protocol (SMTP), le protocole qui déplace le courrier entre serveurs, rend possible.
Le relais ne se contente pas de copier le message. Il faut comprendre deux identités présentes dans tout courriel pour voir pourquoi. L’expéditeur d’enveloppe, l’adresse donnée dans la commande SMTP MAIL FROM, contrôle les rebonds et l’authentification ; il est invisible pour le lecteur. L’en-tête From, la ligne d’expéditeur visible, est ce que votre client mail affiche. Lorsque le relais transfère, il réécrit l’expéditeur d’enveloppe vers son propre domaine (pour que l’authentification en aval puisse passer, comme l’explique la section suivante) tout en préservant l’en-tête From d’origine afin que vous voyiez toujours qui vous a écrit. Il pose aussi un en-tête Reply-To pointant vers un reverse-alias, l’adresse de retour qui rend possibles les réponses anonymes.
Si vous l’avez activé, le relais peut aussi chiffrer le message avec Pretty Good Privacy (PGP), le standard de chiffrement de courriel à clé publique, à l’aide de votre clé publique avant le transfert. Les fournisseurs qui le font ne stockent rien de lisible : SimpleLogin chiffre chaque message entrant vers votre clé pour que seule votre clé privée puisse l’ouvrir, et Addy.io propose la même option OpenPGP par destinataire. Vous ne donnez au relais que votre clé publique, jamais la privée.
Répondre sans exposer votre adresse
Le transfert règle le courrier entrant. Les réponses sont la moitié la plus délicate : une réponse naïve depuis votre boîte partirait directement de votre vraie adresse et anéantirait tout l’intérêt. Le reverse-alias existe précisément pour l’éviter.
Le mécanisme est décrit dans la documentation reverse-alias de SimpleLogin : quand vous répondez au courriel, vous répondez en réalité au reverse-alias, et SimpleLogin envoie ensuite le courriel depuis votre alias en gardant votre vraie boîte cachée. Un reverse-alias est créé automatiquement pour chaque contact qui écrit à l’un de vos alias, et il ressemble à une adresse aléatoire telle que ra+abcdef123456@simplelogin.co ou, en option, à une adresse qui inclut le contact, comme contact_at_example_com_xyz@simplelogin.co.
Deux propriétés le rendent sûr. Il est par contact, donc un reverse-alias ne joint jamais qu’un seul correspondant. Et il est lié au propriétaire : le relais n’accepte un message vers un reverse-alias que si l’expéditeur d’enveloppe est l’une de vos boîtes vérifiées, si bien qu’un inconnu qui devinerait l’adresse ne peut pas l’utiliser pour envoyer du courrier en votre nom.
Délivrabilité : pourquoi le transfert est difficile
Le transfert entre en conflit avec les règles anti-usurpation modernes, et comprendre pourquoi explique la plupart des problèmes de livraison d’alias. Trois mécanismes protègent le domaine d’un expéditeur. Le Sender Policy Framework (SPF), défini dans la RFC 7208, liste les adresses IP autorisées à envoyer du courrier pour un domaine. DomainKeys Identified Mail (DKIM), RFC 6376, attache une signature cryptographique au message. Domain-based Message Authentication, Reporting and Conformance (DMARC), RFC 7489, indique aux destinataires quoi faire quand SPF ou DKIM échoue et, surtout, exige un alignement entre l’identité authentifiée et le domaine From visible.
Voici le problème. Le SPF compare l’IP de connexion au domaine d’enveloppe. Quand le relais transfère, l’IP de connexion est désormais celle du relais, pas celle de l’expéditeur d’origine : si le relais garde l’enveloppe d’origine, le SPF échoue à votre boîte. La solution est le Sender Rewriting Scheme (SRS), qui réécrit l’expéditeur d’enveloppe dans le domaine du relais (une forme du type SRS0=hash=horodatage=origine.com=user@relais.com) pour que le SPF évalue une IP que le relais contrôle. DKIM se comporte différemment : une signature survit à un transfert simple car elle couvre le contenu du message, mais elle se brise dès que le relais modifie le corps, par exemple en ajoutant un pied de page, d’où le fait qu’un relais soigné resigne le message sous son propre domaine. Résultat : DMARC trouve une identité alignée (celle du relais) et livre le message au lieu de le rejeter. Certains écosystèmes utilisent aussi l’Authenticated Received Chain (ARC), RFC 8617, qui permet à un transitaire d’attester des résultats d’authentification qu’il a vus avant la réécriture.
À retenir en pratique : la délivrabilité d’un alias dépend du fournisseur qui doit bien gérer le SRS et la resignature DKIM. Un fournisseur qui le fait bien atterrit dans la boîte de réception ; un relais mal configuré ou auto-hébergé qui l’omet atterrit en spam.
Le plus-adressage n’est pas un vrai alias
Un raccourci courant est le sous-adressage, décrit dans la RFC 5233 comme l’ajout d’une étiquette +detail à la partie locale : vous+shop@gmail.com est toujours livré à vous@gmail.com. Cela ressemble à un alias mais échoue comme outil de confidentialité pour deux raisons. D’abord, l’adresse de base figure telle quelle dans la chaîne : quiconque reçoit vous+shop@gmail.com peut retirer l’étiquette et retrouver vous@gmail.com, ce qui annule l’isolation que l’alias est censé fournir. Ensuite, de nombreux formulaires d’inscription rejettent purement le caractère +, ce n’est donc même pas fiable. Un vrai alias masque totalement la destination ; une étiquette plus ne fait que l’annoter.
Avantages
- Une fuite chez un service n’expose pas votre adresse principale, seulement une adresse jetable.
- Votre vraie adresse reste inconnue des destinataires, et vous détenez de nombreuses adresses faciles à gérer plutôt qu’une seule.
- N’importe quel alias peut être désactivé ou supprimé dès qu’il attire du spam.
- Le catch-all permet d’inventer des adresses sur votre domaine sans les préenregistrer.
- Un alias peut se démultiplier vers plusieurs boîtes à la fois, comme une petite liste de diffusion.
- Extensions de navigateur et gestionnaires de mots de passe génèrent des alias à la volée ; ProtonPass intègre SimpleLogin directement.
Inconvénients
- Vous dépendez du relais : s’il tombe, le transfert s’arrête et le courrier peut rebondir.
- Le relais voit chaque message qui transite par lui, il devient donc un point de confiance unique (PGP protège le contenu, pas les métadonnées).
- Les forfaits gratuits plafonnent l’envoi, la bande passante et le nombre d’alias (Addy.io en particulier).
- Les pièces jointes sont en général limitées à environ 25 Mo ; pour des fichiers plus gros, utilisez un service comme SwissTransfer.
Ce qu’un alias protège, et ce qu’il ne protège pas
Un alias est un outil de routage et de cloisonnement, pas une cape d’anonymat. Garder la frontière explicite évite d’accorder une confiance excessive.
| Enjeu | Ce que l’alias fait | Ce qu’il ne fait pas |
|---|---|---|
| Secret de la vraie adresse | Masque votre boîte aux expéditeurs derrière une adresse de transfert | Ne la masque pas au relais, qui doit savoir où livrer |
| Isolation spam et fuites | Confine une fuite à une adresse révocable et nomme la source | N’empêche pas la fuite : l’alias était tout de même exposé |
| Confidentialité du contenu | PGP entrant optionnel chiffrant le courrier vers votre clé | Ne chiffre pas vos réponses, les objets (en général) ni les métadonnées |
| Disponibilité | Permet de retirer une adresse grillée instantanément | Ajoute une dépendance : une panne du relais arrête votre courrier |
| Liaison d’identité | Casse l’adresse unique partagée qui relie vos comptes | N’anonymise pas ce que vous écrivez, ni ne protège d’une réquisition au fournisseur |
Lu dans son ensemble, un alias augmente le coût de votre profilage et vous donne un coupe-circuit par relation. Il ne rend pas votre courrier anonyme, et il déplace la confiance vers l’exploitant du relais au lieu de la supprimer.
Choisir un fournisseur
| SimpleLogin | Addy |
|---|---|
![]() | ![]() |
SimpleLogin offre le jeu de fonctions le plus large, a été racheté par Proton et est inclus pour les abonnés Proton. Addy.io est une solide alternative, entièrement open source sous AGPL-3.0 et auto-hébergeable via Docker sur une pile Laravel et Postfix si vous préférez exploiter le relais vous-même. Les deux prennent en charge les domaines personnalisés, le catch-all et le PGP par destinataire. L’auto-hébergement supprime le souci de confiance envers un tiers, mais vous rend responsable de la configuration SRS et DKIM qui garde le courrier délivrable.

Références
- IETF, RFC 5321 : Simple Mail Transfer Protocol, 2008.
- IETF, RFC 5322 : Internet Message Format, 2008.
- IETF, RFC 5233 : Sieve Email Filtering, Subaddress Extension, 2008.
- IETF, RFC 7208 : Sender Policy Framework (SPF), 2014.
- IETF, RFC 6376 : DomainKeys Identified Mail (DKIM) Signatures, 2011.
- IETF, RFC 7489 : Domain-based Message Authentication, Reporting, and Conformance (DMARC), 2015.
- IETF, RFC 8617 : The Authenticated Received Chain (ARC) Protocol, 2019.
- SimpleLogin, documentation reverse-alias et chiffrement PGP.
- SimpleLogin, code source, AGPL-3.0.
- Addy.io, FAQ et guide d’auto-hébergement.
- Addy.io, code source, AGPL-3.0.

