Imaginez que votre téléphone sonne. Sur l’écran, le numéro de votre meilleur ami s’affiche. Vous prenez votre téléphone en main, vous décrochez et vous le portez à votre oreille. Là, à votre plus grande surprise, ce n’est pas votre meilleur ami qui vous dit bonjour, mais la voix suave d’un serveur téléphonique commercial qui vous propose d’acheter le tout dernier modèle d’un appareil électroménager dont vous n’avez absolument pas besoin.
Impossible me direz-vous ! En effet, avec votre téléphone, à moins de faire face à un pirate très ingénieux, c’est impossible.
Par contre, en matière d’email, rien de plus simple, vous pouvez envoyer un email au nom de barack@whitehouse.gov à tous vos amis. Ou plutôt, vous pouviez. En fait, à la base, le protocole SMTP ne prévoit pas de mécanisme d’authentification, tout le monde peut envoyer un email au nom de… tout le monde !
Evidemment, avec l’augmentation du nombre d’emails envoyés, et surtout du nombre de spams (et autres phishing), il fallait trouver une solution. C’est au début des années 2000 que des discussions sont engagées, celles-ci aboutiront à la publication en 2006 de SPF et l’année suivante de DKIM.
SPF = Sender Policy Framework
On ne va malheureusement pas pouvoir continuer avec notre exemple du coup de téléphone… l’analogie serait trop bancale 
Lors de l’envoi d’un email, la principale source d’identification de l’expéditeur est l’adresse email contenue dans le champ FROM:. Cette adresse email est constituée de deux parties, la partie située à droite du signe “@”, le nom de domaine, et la partie située à gauche, le nom de l’utilisateur. SPF est une technique qui va définir quels sont les serveurs qui ont le droit d’émettre un email pour le nom de domaine (donc la partie droite de l’adresse).
Prenons par exemple… “example.net”. Example.net est un gros site de paiement en ligne, et donc, ils n’ont pas trop envie que l’on essaye de se faire passer pour eux, c’est mauvais pour leur réputation. Le site a donc décidé de publier en enregistrement SPF sur son serveur DNS, voici ce que ça donne (c’est un exemple, tout est fictif) :
example.net. IN TXT "v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 a -all" example.net. IN SPF "v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 a -all"
Ici, on a deux enregistrements DNS similaires, l’un est de type SPF et l’autre de type TXT pour une question de rétrocompatibilité. Qu’est-ce que ces enregistrements veulent dire ? Que les serveurs ayant pour adresse IP 198.51.100.123 et toutes les adresses IP du bloc 192.0.2.0/24 ont le droit d’envoyer des emails au nom de Example.net. Le “a” signifie que toutes les adresses IP de l’enregistrement A ont aussi le droit d’envoyer des emails pour ce nom de domaine. De son côté, le “-all” signifie que toutes les autres IP doivent être rejetées (“SPF=FAIL”).
Mais attention, un email qui ne passerait pas le test du SPF ne sera pas pour autant considéré comme un SPAM. Par contre, un nom de domaine ayant un enregistrement SPF bien configuré aura moins de chance d’être exploité par des spammeurs.
DKIM = DomainKeys Identified Mail
DKIM est la fusion de deux technologies, l’une développée par Yahoo! (DomainKeys) et l’autre développée par Cisco (Identified Internet Mail). Là où SPF essaye de lier un nom de domaine à l’adresse IP émetrice du message, DKIM tente d’associer un nom de domaine à un message en y aposant une signature numérique. La vérification de la signature se fait via une clef cryptée située dans un enregistrement DNS. Ce faisant, DKIM permet de vérifier si un message a été altéré durant son transport entre les différents serveurs SMTP et de garantir que le contenu arrivera intact jusqu’au destinataire.
Tout comme SPF, DKIM n’évite en rien le SPAM, mais permet d’être vu comme plus légitime par les serveurs recevant les messages. Les filtres peuvent alors se concentrer sur les messages non signés et leur infliger un filtrage plus agressif.
Exemple de signature par DKIM contenu dans le header d’un email :
DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane; c=relaxed/simple; q=dns/txt; l=1234; t=1117574938; x=1118006938; h=from:to:subject:date:keywords:keywords; bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=; b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ VoG4ZHRNiYzR
DMARC = Domain-based Message Authentication, Reporting and Conformance
DMARC joue sur la synthèse entre SPF et DKIM, pas en les remplaçant, mais en les unissant et en les rendant plus intelligents.
On peut distinguer deux grandes utilisations de DMARC :
- Indiquer ce que le FAI/Webmail doit faire avec le message si l’authentification échoue (le laisser passer, le supprimer, le classer comme spam, …).
- Permettre à l’expéditeur d’être averti lorsque l’authentification échoue.
DMARC a été conçu par plusieurs grands noms du secteur de l’email (Return Path, Gmail, AOL, Microsoft, …) afin de lutter plus efficacement contre le Phishing dont le nombre d’attaques ne cesse d’augmenter. C’est d’ailleurs pour cette raison que des entreprises comme Paypal, Facebook ou LinkedIn se sont aussi associées à cette initiative.
Remarque
J’ai bien conscience que le sujet est très technique, n’hésitez donc pas à demander plus de précisions dans les commentaires, je me ferai un plaisir d’y répondre. De plus, je reviendrai probablement plus en détail sur ces différentes technologies dans le futur.
Cet article Délivrabilité : SPF, DKIM, DMARC, … ce qu’il faut savoir sur l’authentification de vos emails ! est apparu en premier sur Badsender.
