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. L'idée est d'atteindre un certain niveau de défense contre les e-mails frauduleux, tels que le phishing et le spoofing, qui pourraient éroder la confiance d'un destinataire dans la réception des e-mails. Cela dit, l'acte d'envoyer des e-mails authentifiés n'affirme pas, en soi, que l'e-mail est un bon ou un e-mail souhaité ; cela signifie seulement que le mail 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 e-mails.
Il existe deux formes principales d'authentification par e-mail en usage aujourd'hui—Sender Policy Framework (SPF) et DomainKeys Identifed Mail (DKIM). Dans cet article de blog, je vais expliquer ce qu'est le SPF et comment cela fonctionne.
Présentation du 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 lors de l'envoi d'e-mails, mais qui fournit également un moyen pour un hôte recevant de vérifier cette autorisation.
Une fois que vous aurez fini de lire cet article, j'espère que vous aurez appris ce qui suit :
Le SPF est un système d'authentification « basé sur le chemin ».
Les politiques SPF sont déclarées dans des 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, ce qui en fait un bon contrôle à utiliser pour rejeter rapidement les e-mails non authentifiés.
Il est sujet à un pourcentage relativement élevé de faux négatifs.
Authentification « Basée sur le chemin »
Le SPF est considéré comme un système d'authentification basé sur le chemin car il est uniquement lié au chemin que le message a emprunté pour passer de son origine à sa destination. Lorsqu'un serveur d'envoi initie une transaction SMTP avec un serveur récepteur, le serveur récepteur déterminera si le serveur d'envoi 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
L'enregistrement de la 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 – Le premier jeton requis pour indiquer que l'enregistrement TXT est un enregistrement SPF (un domaine peut avoir plusieurs enregistrements TXT)
ipv4, ipv6 – Utilisé 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 – Seule ce qui est listé ici peut passer ; rejeter les échecs.
~all – Les éléments qui ne sont pas ici devraient échouer mollement ; les accepter mais les noter.
?all – Pas sûr si les éléments qui ne sont pas ici devraient passer.
+all – Nous pensons que le SPF est inutile ; passez tout.
D'autres mécanismes moins courants qui sont toujours largement utilisés sont :
include – Utilisé lorsqu'un domaine a non seulement ses propres serveurs, mais utilise également ceux de quelqu'un d'autre. Doit être utilisé judicieusement. Chaque inclusion est une autre requête DNS, et les enregistrements SPF ne peuvent pas nécessiter plus de dix requêtes DNS pour se résoudre.
redirect – Lorsque le domaine A et le domaine B sont détenus par 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 de réseau non contigus, il peut utiliser ce mécanisme pour spécifier son enregistrement SPF, au lieu de les lister tous. Utile pour rester dans la limite de taille (512 octets) pour la réponse DNS.
Une note sur le mécanisme “ptr”
Un dernier mécanisme, “ptr” existait dans la spécification originale pour le 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 au nom de domaine en question, alors cette adresse IP était autorisée à envoyer des e-mails pour le domaine.
Le statut actuel de ce mécanisme est qu'il ne doit pas être utilisé. Cependant, les sites faisant la validation SPF doivent l'accepter comme valide.
Quelques exemples d'enregistrements SPF
Voici quelques enregistrements d'exemple et leurs significations. Cet exemple montre des adresses RFC 1918, mais je reconnais que de telles adresses n'apparaîtront jamais dans de véritables enregistrements SPF.
Enregistrement MX, une adresse IP, un réseau IP, échoue mollement tout le reste :
“v=spf1 mx ipv4:10.0.0.1 ipv4:192.168.24.0/24 ~all”
Enregistrement A, deux réseaux IP, rejetez tout le reste :
“v=spf1 a ipv4:10.0.3.0/23 ipv4:192.168.55.0/26 -all”
Nous n'envoyons aucun e-mail :
“v=spf1 -all”
Nous pensons que le 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 exists 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 trouvé cela nécessaire en raison du manque de support universel pour la validation du mécanisme exists. Et jusqu'à présent, nous n'avons constaté 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 le SPF est impliqué :
Le serveur d'envoi (client) se connecte au serveur récepteur
Le serveur récepteur note l'adresse IP de connexion du client
Ils échangent des salutations, y compris le nom d'hôte HELO du client
Le client émet la commande SMTP MAIL FROM
Le serveur récepteur peut maintenant rechercher l'enregistrement SPF pour le domaine MAIL FROM ou le nom d'hôte HELO pour déterminer si l'IP de connexion est autorisée à envoyer des e-mails pour le domaine, et décider s'il faut accepter le message.
MAIL FROM ou HELO – Quel 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 se fait que sur 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.
Le SPF n'est pas infaillible
Bien qu'il semble s'agir d'un moyen relativement simple d'authentifier les e-mails, le SPF est vulnérable à l'échec sous forme de faux négatifs. Ces échecs peuvent se produire plus fréquemment que beaucoup ne le souhaitent.
Voici deux scénarios courants où des e-mails parfaitement légitimes peuvent échouer à la validation SPF et sembler donc frauduleux :
Transfert automatique, 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
Listes de diffusion, où un e-mail 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 origine, l'e-mail peut échouer aux contrôles SPF (selon le modificateur utilisé avec le mécanisme ‘all’). Cela est dû au fait qu'il arrive à sa destination finale depuis un serveur intermédiaire, et non depuis l'original, et qu'il est peu probable que ce serveur intermédiaire figure dans l'enregistrement SPF du domaine. Une technique appelée “Sender Rewriting Scheme” ou “SRS” peut atténuer ce risque, et certaines grandes entreprises l'ont adoptée, mais ce n'est pas universel.
Conclusion
C'est donc l'authentification SPF, son fonctionnement, comment déclarer une politique SPF, et quels sont les pièges d'utilisation du SPF. Le SPF a été le premier schéma d'authentification par e-mail à connaître une large adoption, mais ce n'est pas le seul. L'authentification SPF est plus efficace lorsqu'elle est déployée en combinaison avec d'autres techniques anti-fraude.