Publié le 24/08/2023.
De nos jours, quasiment tout le monde dispose d'au moins une adresse de courrier électronique (email). Élément central pour nous contacter voir souvent élément d'identification à un service, nous sommes amenés à la confier à de nombreuses entités. Son rôle central dans nos communications modernes fait qu'elle est l'objet de nombreuses convoitises. Quelques précautions d'usage s'imposent donc si l'on souhaite éviter quelques ennuis.
Pour beaucoup trop de gens, une adresse et une boite de courrier électronique sont une même et unique chose. En réalité, il n'en est rien. On peut aisément s'en rendre compte en comparant avec le courrier physique traditionnel. Votre habitation dispose d'une boite physique dans laquelle le facteur va déposer le courrier qui vous est adressé. En parallèle de ça, votre habitation est située à une certaine adresse. Les termes de boites et d'adresse étant identiques, je ne vous ferai pas l'insulte de détailler plus que ça la comparaison.
Maintenant que vous avez cette comparaison en tête, imaginez ce qui se passe lorsque la mairie décide de changer le nom de votre rue. Votre adresse postale a donc changée et vos correspondants doivent désormais indiquer votre nouvelle adresse pour vous joindre. Cependant, votre boite, elle, n'a pas changée. C'est toujours le même cube métallique situé au même endroit.
Allons encore plus loin car, afin d'éviter de perdre du courrier, votre bureau de poste va, au moins pendant un certain temps, faire l'association entre votre ancienne adresse (avec l'ancien nom de rue) avec la nouvelle adresse (le nouveau nom de rue donc). Tant que cette association existe, vous disposez donc de deux adresses postales pointant sur une seule et même boite.
L'idée de base est de donner à chaque correspondant une adresse différente. Ceci permet, lorsque quelqu'un vous écrit à cette adresse, de savoir d'où il l'a obtenu. L'immense majorité du temps, c'est la personne ou l'organisme à qui vous avez passé votre adresse qui vous écrit dessus, ce qui est totalement normal. Mais parfois ce n'est pas le cas, et il faut alors se demander pourquoi.
Notons tout d'abord qu'il peut exister des cas légitimes pour lesquels la personne ou l'organisme à qui vous avez donné votre adresse l'ait donné à quelqu'un d'autre. Un exemple courant est un site e-commerce qui donne vos coordonnées à la société en charge de la livraison du produit que vous avez commandé afin qu'elle puisse organiser cette livraison avec vous.
Ensuite, il y a des cas illégitimes. Bien qu'ils soient plus rares, c'est là qu'avoir donné une adresse spécifique à chaque destinataire prend tout son sens. Le premier cas qui vient en tête est celui des sociétés peu scrupuleuses qui revendent vos données personnelles à d'autres, notamment des annonceurs publicitaires. C'est ainsi que j'ai découvert qu'Engie a revendu en toute illégalité mes données personnelles à au moins un annonceur publicitaire qui s'est empressé de me bombarder de pubs pour des produits divers et variés. Oui Engie, je vous expose, vous l'avez bien cherché. La prochaine fois, respectez la loi (nota : je répondrai à toute accusation en diffamation par l'exception de vérité car j'ai conservé les preuves, donc évitez si vous ne souhaitez pas vous ridiculiser encore un peu plus).
Enfin, toujours dans les cas illégitimes, il y a le cas où l'organisme à qui vous avez confié votre adresse est malheureusement victime d'une attaque et où un tiers non-autorisé a récupéré sa base de données. J'ai également rencontré ce cas en 2020 où, sur l'adresse que j'avais donné à une boutique en ligne, je me suis mis à recevoir du spam assez méchant. En analysant le spam reçu, je me suis rendu compte qu'il avait été émis par le serveur mail d'une université d'un pays d'Europe de l'Est probablement mal configuré (relai ouvert). La conduite à tenir lorsqu'on rencontre ce genre de situation est très simple : ne contactez JAMAIS les victimes vous-même (ici la boutique en ligne et l'université). Vous risqueriez de passer, à tort, pour l'attaquant ou pour un maître chanteur, ce qui peut vous exposer à des poursuites juridiques qui vous embêteront le temps que vous prouviez votre innocence. À la place, signalez le problème à l'ANSSI en incluant tous les détails techniques. C'est bien entendu ce que j'ai fait, et la réponse de l'ANSSI a été assez rapide :
Exactement deux mois après cette réponse de l'ANSSI, la boutique en ligne concernée a adressé cet email à l'ensemble de ses clients (dont moi, forcément). Bien que personne ne m’ait tenu au courant des suites de mon signalement, je pense que l'on peut aisément deviner que mon diagnostique était bon, au moins en ce qui concerne la boutique en ligne.
Point bonus : en utilisant une adresse différente par entité, vous pouvez utiliser Sieve (ou un autre système) pour automatiquement supprimer tout email sur une adresse donnée. C'est utile lorsqu'une de vos adresse a été compromise et que vous recevez plein de spam dessus.
Maintenant que nous avons vu l'intérêt de donner une adresse email différente à chaque entité, voyons donc comment faire. Une première solution, très simple, consiste à utiliser le concept de sous adresses.
Pour rappel, une adresse email est généralement composées d'une partie local suivie d'un nom de domaine, les deux étant séparés par une arobase. Pour les deux ou trois puristes qui liraient ce billet, ici je vulgarise, donc non je ne veux pas évoquer les autres cas possibles. Bref, dans l'adresse derp.derpson@example.com
, nous avons donc bien une partie locale, derp.derpson
et un nom de domaine, example.com
, les deux étant séparés par une arobase.
L'évident ayant été rappelé, je peux évoquer une chose un peu moins connue, les sous-adresses. Le principe est simple : il est possible, dans la partie locale, d'utiliser un délimiteur qui fait en sorte que tout ce qui est situé entre ce délimiteur (inclus) et l'arobase (exclue) soit « ignoré » lors de la distribution du courrier électronique. En général, ce délimiteur est le caractère +
.
Illustrons avec des exemples. Si l'on adresse un courrier à derp.derpson+toto@example.com
, il sera distribué sur l'adresse derp.derpson@example.com
car tout ce qui est entre le +
et l'arobase est « ignoré ».
Reprenons la comparaison avec le courrier postal en nous appuyant sur l'adresse suivante :
Société BIDULE
Service comptable
3 boulevard du Levant
95220 HERBLAY
Ici, les lignes Société BIDULE
et Service comptable
correspondent à la partie locale de l'adresse email et les lignes 3 boulevard du Levant
et 95220 HERBLAY
correspondent au nom de domaine. Cependant, pour distribuer le courrier dans la boite, le facteur ignore totalement la ligne Service comptable
. Ce qui importe au facteur c'est de distribuer dans la boite de la société et rien d'autre. Vous auriez d'ailleurs pu indiquer un service qui n'existe pas, le facteur aurait distribué votre courrier de la même manière dans la même boite. Cette ligne correspond donc à ce qui est indiqué entre le +
et l'arobase.
Vous devriez donc voir le principe. Dès que vous devez donner une adresse email à une entité, vous pouvez ajouter le nom de cet entité dans l'adresse, après un +
. Ainsi, lorsque vous recevez un spam sur derp.derpson+engie@example.com
, vous savez que le spammeur a eu votre adresse email via Engie. Simple, pratique et efficace.
Cette approche a cependant trois limites qu'il convient de garder en tête. La première est que bon nombre d'entités refusent les adresses emails contenant un +
, ce qui vous empêche de recourir à cette astuce. La seconde est que tout le monde sait qu'il est possible d'ignorer tout ce qui est entre le +
et l'arobase, ce qui fait que certains organismes ou spammeurs vont prennent l'initiative de les supprimer avant de les stocker en base de données. La troisième limitation est qu'il est possible de deviner les adresses que vous utiliserez pour d'autres services. Un spammeur pourra s’amuser à modifier la valeur afin de brouiller les pistes.
Si vous disposez de votre propre serveur email, il vous est facilement possible de contourner cette première limitation en le configurant de manière à utiliser un autre caractère que le +
comme délimiteur de sous-adresses. Par exemple, pour OpenSMTPD, ceci se fait avec l'option de configuration suivante :
smtp sub-addr-delim "."
Dans cet exemple, le +
est remplacé par le .
. Le .
et le -
sont les deux caractères que je vous recommande en remplacement du +
car vous pouvez être sûr qu'ils ne seront pas refusés.
Le principe des alias est simple : le serveur email est configuré de manière à lui dire qu'une partie locale donnée doit être distribuée dans la boite associée à une autre partie locale.
Reprenons l'exemple du courrier postal. Quand le facteur arrive dans votre immeuble pour distribuer le courrier, il se retrouve devant une multitude de boites aux lettres, chacune avec un nom dessus. Il regarde alors les noms indiqués sur les courriers qu'il a pour cet immeuble et les distribue dans les boites indiquant le même nom.
Le principe d'un alias est d'indiquer un autre nom sur une même boite. Ainsi, si votre boite indique à la fois les noms de Durand et de Dupont, le facteur y distribuera à la fois les courriers adressés à Durand et de Dupont. Notons que, lorsque l'on définit un alias email, il est obligatoire de veiller à ce qu'aucune boite ni aucun autre alias ne porte déjà ce nom.
Face aux limitations des sous-adresses, j'ai longtemps utilisé des alias. Mon premier usage a été de simplement définir un alias avec le nom de l'entité à qui j'ai donné mon adresse email. Ainsi, en définissant engie
comme alias sur toto
, les emails adressés sur engie@example.org
arrivent dans la boite de toto@example.org
.
C'est mieux que les sous-adresses car, contrairement à ces dernières, il est impossible de supprimer la partie comportant le nom servant à savoir à qui on a confié l'adresse. Cependant, il est toujours possible de deviner les adresses que l'on va utiliser pour d'autres services.
J'ai donc revu mes habitudes et ajouté une partie aléatoire composée généralement de 8 caractères. Ainsi, on a engie.r5pwv8fo@example.org
, impots.hqflairq@example.org
etc qui permettent la distribution sur toto@example.org
. Avec ce mode de fonctionnement, impossible de supprimer, modifier ou deviner quoi que ce soit.
Ce mode de fonctionnement avec des alias comportant une partie aléatoire m'a contenté durant assez longtemps. C'est le système le plus fiable et robuste que j'ai trouvé, et du coup je l'aime beaucoup. Cependant, il possède un énorme inconvénient : il est nécessaire d'enregistrer chaque alias auprès du serveur web. Certains fournisseurs mail ne proposent pas cette option, d'autres proposent un nombre d'alias limités et, quoi qu'il en soit, vous devez enregistrer l'alias avant que quelqu'un n'essaye de vous envoyer un email dessus. Je trouve ça très gênant lorsqu'un magasin me demande mon adresse email afin de m'y envoyer la facture car je n'ai pas accès à la configuration de mon serveur et ne suis donc pas en mesure de créer un alias pour l'occasion. Fort heureusement, les enseignes où j'ai ainsi fait des achats acceptaient toutes le +
dans les adresses, donc j'ai quand même fourni une adresse unique. Mais quand même, ça reste ennuyeux comme difficulté.
Les alias c'est génial, mais depuis peu je n'en peux plus de leur limitation. Je me suis donc mis en quête de la solution ultime, alliant les avantages des sous-adresses ainsi que ceux des alias.
Forcément, cette solution n'existe pas de base, il faut l'inventer. Et c'est ce que j'ai fait. Le serveur mail que j'utilise, OpenSMTPD, permet l'usage de ce qu'il appelle des filtres. Ces filtres peuvent prendre plusieurs formes, mais ici une seule nous intéresse : la possibilité, sur un événement donné, de dire au serveur de continuer sa vie ou bien de retourner une erreur donnée.
Ceci m'a donc donné une idée : revenir à l'utilisation des sous-adresses, mais en y insérant un code de vérification. Il suffit donc, pour OpenSMTPD, d'écrire un filtre qui soit en mesure de vérifier ce code et, s'il est mauvais ou absent, de dire que l'adresse email n'existe pas et donc de refuser le courrier. J'ai donc lancé le projet Sub-Address KEy (SAKE).
Le principe étant posé, reste la question de la génération du code de vérification. Celle-ci doit pouvoir s'effectuer totalement hors-ligne et le code résultant soit ressembler à une chaîne de caractères aléatoire d'une taille raisonnable. Cela ressemble très fortement au fonctionnement des codes à usage uniques tels que HOTP et TOTP. J'ai donc décidé d'en reprendre le principe avec quelques adaptations.
Une fois généré, le code est ajouté à la fin de la partie locale de l'adresse précédé du séparateur de sous-adresse. Il y a donc deux séparateurs de sous-adresse dans la partie locale.
Pour la vérification, on s'assure d'abord qu'il y ait bien les deux séparateurs de sous adresse et on extrait les différents éléments de la partie locale. On recalcule alors le code et on compare le résultat avec celui qui était fourni.
Bien entendu, le filtre ne doit pas effectuer une telle vérification du code de vérification sur l'ensemble des adresses. Il existe des cas où on ne donne pas des adresses uniques, par exemple à sa famille ou à ses amis. Le filtre doit donc ne faire ça que sur les adresses (potentiellement des alias) sur lesquelles on lui dit de le faire.
Une fois tous ces éléments définis, je me suis mis à les implémenter. Je suis donc plutôt fier de vous présenter mes deux parties du projet SAKE :
Pour vous donner une idée du résultat, vous pouvez désormais m'écrire à l'adresse v.blog.lmovj4ow@breard.tf
. Comme vous pouvez le constater, j'ai décidé de modifier le caractère de séparation des sous-adresses afin d'utiliser le .
au lieu du traditionnel +
. Bien entendu, v
est un alias vers ma véritable boite et blog
est pour indiquer que vous avez eu mon adresse depuis ce blog. lmovj4ow
est donc le code de vérification.
Précision importante : bien que le calcul du code de vérification utilise des primitives cryptographiques, ce dernier ne peut pas être considéré comme cryptographiquement sûr. L'absence de garantie cryptographique est principalement imposée, d'une part, par la taille nécessairement réduite du code de vérification et, d'autre part, l'impossibilité d'effectuer des rotations des clés. L'objectif ici n'est pas de réaliser un système cryptographique ultime, mais juste de quoi enquiquiner les spammeurs, les publicitaires et autres Jean-Kévin Haxxor. Ceci dit, bon courage pour dériver la partie locale de l'adresse email que je viens de vous donner en une autre qui soit valide ;)
Pour finir, comme vous l'aurez très certainement remarqué, SAKE n'est pas destiné à un usage grand public. Pour l'utiliser, vous devez disposer de votre propre serveur email et que celui-ci soit OpenSMTPD (ou alors il vous faudra développer une implémentation compatible avec votre serveur SMTP préféré).