Lorsque nous parlons de « Authentification par e-mail », nous faisons référence à une technique qui vise à fournir au destinataire d'un message un certain niveau de certitude que le message provient réellement de la source revendiquée du message.
Business in a box.
Découvrez nos solutions.
Parlez à notre équipe de vente
Quand nous parlons de « Email Authentication », nous faisons référence à une technique qui est destinée à fournir au destinataire d'un message un certain niveau de certitude que le message provient effectivement de la source revendiquée du message. L'idée est d'atteindre un certain niveau de défense contre les emails frauduleux, tels que le phishing et l'usurpation d'identité, qui pourraient éroder la confiance d'un destinataire dans la réception de courriers électroniques. Cela dit, le fait d'envoyer un email authentifié n'affirme pas, en soi, que l'email est bon ou souhaité ; cela signifie uniquement que le courrier est tel qu'une réputation pour la partie authentifiée peut être établie de manière fiable et utilisée dans les décisions d'acceptation et de placement des emails.
Il existe deux formes principales d'authentification des emails utilisées aujourd'hui — Sender Policy Framework (SPF) et DomainKeys Identified Mail (DKIM). Dans cet article de blog, je vais expliquer ce qu'est le SPF et comment il fonctionne.
Vue d'ensemble SPF
Le Sender Policy Framework (SPF), pour paraphraser RFC 7208, est un protocole qui permet non seulement à une organisation d'autoriser des hôtes et des réseaux à utiliser ses noms de domaine pour envoyer des e-mails, mais fournit également un moyen pour qu'un hôte récepteur puisse vérifier cette autorisation.
Quand vous aurez fini de lire cet article, j'espère que vous aurez appris les points suivants :
SPF est un système d'authentification « basé sur le chemin ».
Les politiques SPF sont déclarées dans les enregistrements DNS TXT.
La validation est liée au domaine Return-Path (ce que nous appelons ici chez SparkPost le « domaine de rebond ») ou au domaine HELO.
La validation peut être effectuée tôt dans la transaction SMTP, c’est donc un bon moyen de rejeter rapidement les mails non authentifiés.
Il est sujet à un pourcentage relativement élevé de faux négatifs.
« Authentification Basée sur le Chemin »
SPF est considéré comme un système d'authentification basé sur le chemin car il est lié uniquement au chemin que le message a emprunté pour aller de son origine à sa destination. Lorsqu'un serveur expéditeur initie une transaction SMTP avec un serveur récepteur, le serveur récepteur déterminera si le serveur expéditeur est autorisé ou non à envoyer ce message en fonction de la politique SPF du domaine. C'est uniquement une décision basée sur l'origine du message, sans aucun rapport avec le contenu du message.
Déclaration d'une politique SPF
Le registre de politique SPF d’un domaine est simplement un enregistrement DNS TXT spécifiquement formaté, contenant généralement un ou plusieurs des « mécanismes » suivants :
v=spf1 – Premier jeton requis pour indiquer que l'enregistrement TXT est un enregistrement SPF (un domaine peut avoir plusieurs enregistrements TXT)
ipv4, ipv6 – Utilisés pour spécifier les adresses IP et les réseaux autorisés à envoyer des e-mails pour le domaine
a – Si le domaine d'envoi a un enregistrement DNS « A » qui résout à l’IP d’envoi, l’IP est autorisée
mx – Si l’IP d’envoi est également l’un des enregistrements MX pour le domaine d’envoi, l’IP est autorisée
all – Dernier jeton requis, toujours modifié :
-all – Seuls ce qui est listé ici peut passer ; rejeter les échecs.
~all – Ce qui n'est pas ici devrait échouer doucement ; l'accepter mais le noter.
?all – Pas sûr si ce qui n'est pas ici devrait passer.
+all – Nous pensons que SPF est inutile ; tout passer.
D'autres mécanismes moins courants, mais encore largement utilisés, sont :
include – Utilisé lorsqu’un domaine n’a pas seulement ses propres serveurs, mais utilise également ceux de quelqu’un d’autre. Doit être utilisé de manière judicieuse. Chaque include est une autre requête DNS, et les enregistrements SPF ne peuvent pas nécessiter plus de dix requêtes DNS pour être résolus.
redirect – Lorsque le domaine A et le domaine B appartiennent à la même entité et utilisent la même infrastructure. Les propriétaires souhaitent généralement maintenir une seule copie de l'enregistrement SPF pour les deux et configurer B pour rediriger les requêtes vers A.
exists – Si un domaine a beaucoup de petits blocs réseau non contigus, il peut utiliser ce mécanisme pour spécifier son enregistrement SPF, au lieu de tous les lister. Utile pour rester dans la limite de taille (512 octets) pour la réponse DNS.
Une remarque sur le mécanisme « ptr »
Un dernier mécanisme, « ptr » existait dans la spécification originale de SPF, mais a été déclaré « à ne pas utiliser » dans la spécification actuelle. Le mécanisme ptr était utilisé pour déclarer que si l'adresse IP d'envoi avait un enregistrement DNS PTR qui résolvait le nom de domaine en question, alors cette adresse IP était autorisée à envoyer des e-mails pour le domaine.
L'état actuel de ce mécanisme est qu'il ne devrait pas être utilisé. Cependant, les sites effectuant une validation SPF doivent l'accepter comme valide.
Quelques exemples de SPF Records
Voici quelques exemples de dossiers et leurs significations. Cet exemple montre des adresses RFC 1918, mais je reconnais que de telles adresses n'apparaîtront jamais dans de vrais enregistrements SPF.
Enregistrement MX, une adresse IP, un réseau IP, softfail tout le reste :
“v=spf1 mx ipv4:10.0.0.1 ipv4:192.168.24.0/24 ~all”
Enregistrement A, deux réseaux IP, rejeter tout le reste :
“v=spf1 a ipv4:10.0.3.0/23 ipv4:192.168.55.0/26 -all”
Nous n'envoyons pas de courrier :
“v=spf1 -all”
Nous pensons que SPF est stupide :
“v=spf1 +all”
L'enregistrement SPF pour le domaine sparkpostmail.com (mécanisme de redirection utilisé)
“v=spf1 redirect=_spf.sparkpostmail.com”
L'enregistrement SPF pour _spf.sparkpostmail.com (mécanismes exist et ptr utilisés) :
“v=spf1 exists:%{i}._spf.sparkpostmail.com ptr:sparkpostmail.com ptr:spmta.com ptr:flyingenvelope.com ~all”
Chez SparkPost, nous utilisons actuellement le mécanisme ptr dans notre enregistrement SPF. Nous avons jugé cela nécessaire en raison d'un manque de soutien universel pour valider le mécanisme exists. Et à ce jour, nous n'avons observé aucun échec SPF résultant de notre utilisation du mécanisme ptr.
Comment fonctionne l'authentification SPF ?
Voici à quoi ressemble une transaction SMTP typique lorsque SPF est impliqué :
Le serveur expéditeur (client) se connecte au serveur récepteur
Le serveur récepteur note l'adresse IP du client se connectant
Ils échangent des salutations, y compris le nom d'hôte HELO du client
Client émet la commande SMTP MAIL FROM
Le serveur récepteur peut maintenant rechercher l'enregistrement SPF soit pour le domaine MAIL FROM soit pour le nom d'hôte HELO afin de déterminer si l'IP de connexion est autorisée à envoyer des emails pour le domaine, et décider ou non d'accepter le message.
MAIL FROM ou HELO – Lequel vérifier ?
La spécification SPF stipule que les sites récepteurs DOIVENT vérifier le SPF pour le domaine MAIL FROM, et RECOMMANDENT de le vérifier pour le nom d'hôte HELO. En pratique, la vérification ne s'effectue que pour le domaine MAIL FROM, sauf peut-être dans les cas où l'adresse MAIL FROM est l'expéditeur NULL (c'est-à-dire, “<>”), auquel cas le nom d'hôte HELO est la seule identité disponible.
SPF n'est pas infaillible
Bien qu'il semble être une méthode relativement simple pour authentifier les e-mails, SPF est vulnérable aux échecs sous forme de faux négatifs. Ces échecs peuvent se produire plus fréquemment que ce que beaucoup sont prêts à accepter.
Voici deux scénarios courants où un courrier parfaitement légitime peut échouer à la validation SPF et apparaître ainsi comme frauduleux :
Le transfert automatisé, où un message envoyé à jsmith@alumni.university.edu, une boîte aux lettres configurée pour transférer automatiquement tous les e-mails à jsmith@isp.com
Les listes de diffusion, où le courrier envoyé à talk-about-stuff@listserv.foo.com est « explosé » et envoyé à chaque abonné
Dans ces deux cas, si le Return-Path reste inchangé par rapport à son original, le courrier peut échouer aux vérifications SPF (en fonction du modificateur utilisé avec le mécanisme « all »). C'est parce qu'il arrive à sa destination finale depuis un serveur intermédiaire, pas l'original, et ce serveur intermédiaire n'est probablement pas dans l'enregistrement SPF du domaine. Une technique appelée « Sender Rewriting Scheme » ou « SRS » peut atténuer ce risque, et certains grands sites l'ont adoptée, mais elle n'est pas universelle.
Wrap Up
C'est donc l'authentification SPF, comment cela fonctionne, comment déclarer une politique SPF et quels sont les pièges de l'utilisation de SPF. SPF a été le premier schéma d'authentification par email à être largement adopté, mais ce n'est pas le seul. L'authentification SPF est la plus efficace lorsqu'elle est déployée en combinaison avec d'autres techniques anti-fraude.
