Pourquoi le SPF est si complexe dans le monde moderne d'aujourd'hui

Sender Policy Framework (SPF) existe depuis longtemps et possède une histoire riche remontant à 1997, le projet SPF lui-même ayant débuté en juin 2003. Cependant, il existe des défis liés au fonctionnement de SPF, entraînant confusion, incompréhension et conseils trompeurs. Dans cet article, nous examinons ces problèmes ainsi que les obstacles qui empêchent SPF d'être meilleur.

SPF manque de retour d'information

Un problème notable avec SPF est que les personnes qui le déploient doivent le faire avec très peu d'informations provenant de l'extérieur. SPF ne dispose pas de fonctionnalités similaires aux mécanismes de retour d'information des rapports RUA et RUF de DMARC. Sans rapports provenant de l'extérieur, les enregistrements SPF doivent être construits et maintenus en utilisant uniquement les données issues des connaissances immédiates d'un administrateur.

À l'ère pré-DMARC, les gens créaient d'abord des enregistrements SPF basés sur leur propre connaissance de leur infrastructure. Les enregistrements SPF publiés n'étaient pas toujours très précis quant à l'autorisation de toutes les infrastructures légitimes envoyant au nom d'un domaine, mais ces enregistrements SPF autorisaient au moins l'infrastructure que l'administrateur connaissait. Du point de vue des personnes et des machines traitant les e-mails entrants, des enregistrements SPF imprécis signifiaient que les décisions de délivrer ou non un e-mail ne pouvaient pas être basées uniquement sur le traitement SPF.

Avec le temps, les administrateurs et autres personnes ayant accès aux enregistrements SPF ajoutaient davantage d'infrastructure aux enregistrements SPF existants. Très rarement quelqu'un supprimait quoi que ce soit, car le risque de perturber accidentellement un flux d'e-mails légitime était présent. Personne ne savait si une entrée existante dans un bloc SPF était toujours utilisée, et retrouver cette information était souvent peu pratique et parfois impossible.

SPF – Pour les opérateurs de messagerie, par les opérateurs de messagerie

Les enregistrements SPF – listes de serveurs autorisés – existent en tant que ressources textuelles d'un domaine Internet. Cela signifie que les opérateurs de messagerie se différencient, ainsi que leur infrastructure, en utilisant différents domaines Internet.

Les opérateurs de messagerie qui partagent le même domaine transforment effectivement un domaine Internet en un pool de réputation indifférencié et partagé, ce qui force les récepteurs d'e-mails à traiter tous les e-mails du domaine de la même manière.

Les e-mails marketing indésirables restent indifférenciés des e-mails d'entreprise interpersonnels, qui à leur tour restent indifférenciés des e-mails envoyés par un fournisseur compromis.

Les opérateurs de messagerie utilisent SPF basé sur le domaine pour s'identifier/se différencier et différencier leur infrastructure.

SPF vérifie le chemin inverse de l'e-mail

Le fonctionnement de SPF et ce qu'il vérifie dans un e-mail est souvent mal compris. Cette confusion a conduit à la publication de nombreux articles au fil des ans, fournissant des conseils incorrects à des personnes non techniques qui essayaient simplement de mettre en place SPF.

Voici comment cela fonctionne : Lorsqu'un serveur délivre un e-mail, le serveur d'envoi partage une adresse e-mail où les rapports d'erreur et les notifications concernant l'e-mail peuvent être envoyés. Cette adresse est appelée le chemin inverse (reverse-path) et est utilisée principalement par les opérateurs de messagerie.

Le serveur de réception utilise le domaine du reverse-path pour rechercher un enregistrement SPF. Si cet enregistrement SPF répertorie le serveur d'envoi, alors le reverse-path est légitime.

Aujourd'hui, le reverse-path est désigné par de nombreux noms : adresse de rebond, RFC5321.MailFrom, « SMTP MAIL FROM », Return-Path, adresse d'enveloppe, et bien d'autres encore. Ces nombreuses conventions de dénomination peuvent être assez déroutantes.

Une autre erreur courante consiste à confondre l'adresse « From: » — l'adresse visible dans un e-mail — avec le reverse-path. Cette imprécision conduit les utilisateurs à ajouter des infrastructures à leurs enregistrements SPF en se basant sur l'adresse « From: » au lieu du reverse-path.

Il en résulte que les enregistrements SPF deviennent incroyablement volumineux, autorisant souvent de vastes sections d'Internet à envoyer au nom d'un domaine Internet et conduisant à un enregistrement SPF surchargé. Ensuite, les utilisateurs recherchent des solutions pour gérer des enregistrements SPF incroyablement volumineux — tout cela basé sur une mauvaise compréhension du fonctionnement de SPF.

Combiné au fait qu'il existe désormais de nombreux services qui envoient des e-mails au nom du domaine d'un tiers (par exemple, un service de newsletter, des fournisseurs de boîtes aux lettres hébergées comme Google Suite ou Microsoft Office 365, et des applications SaaS), obtenir une compréhension claire du fonctionnement de SPF et de la manière de maintenir les enregistrements SPF est devenu une affaire complexe.

Le résultat final pour l'ère pré-DMARC était que les utilisateurs publiaient des enregistrements SPF souvent gonflés en autorisant des parties d'Internet qui ne devraient pas l'être et en dépassant les limites de traitement de SPF. Cette erreur est souvent signalée par la notification « Trop de requêtes DNS » popularisée par le SPF Surveyor de dmarcian ; elle est également inexacte en raison de la confusion sur le fonctionnement de SPF.

DMARC change la façon dont les utilisateurs perçoivent et déploient SPF

Lorsque DMARC est apparu en 2012, la situation a commencé à changer. Pour la première fois, les administrateurs ont eu accès à des données précises sur la manière dont les domaines sont utilisés avec les e-mails exposés à Internet. Avec un enregistrement DMARC en place, les administrateurs ont pu vérifier l'exactitude de leurs enregistrements SPF par rapport aux données de rapport DMARC et recevoir des conseils sur le déploiement correct de SPF. Cette capacité a provoqué une petite révolution dans le monde de SPF, les utilisateurs commençant à constater à quel point il avait été mal mis en œuvre et pris en charge.

DMARC a également introduit l'exigence d'« alignement de domaine ». L'alignement contraint les opérateurs de messagerie à s'identifier à l'aide d'un sous-domaine afin qu'ils puissent à la fois s'identifier et identifier l'infrastructure qu'ils gèrent. L'exigence de DMARC modifie SPF de manière significative, entraînant des défis de déploiement et un affinement de SPF.

Le nettoyage à l'échelle d'Internet des mauvaises pratiques SPF se poursuit encore aujourd'hui. Les utilisateurs rencontrent toujours l'erreur « Trop de requêtes » sans recevoir de conseils clairs sur la manière de les résoudre. Les expéditeurs d'e-mails tiers manquent toujours de directives sur la manière d'envoyer des e-mails au nom d'autres personnes d'une manière compatible avec l'administration et la maintenance de SPF. Et les administrateurs DNS ont toujours du mal à rendre SPF accessible aux personnes non techniques.

En savoir plus : Bonnes pratiques SPF

Obstacles à un meilleur SPF

Avec des directives claires disponibles aujourd'hui, l'assainissement de SPF est désormais en grande partie un effort d'éducation, d'offre de meilleurs conseils et d'ajout de fonctionnalités pour dissiper certains des mystères qui entourent SPF.

Chez dmarcian, nous aimons réfléchir aux problèmes à l'échelle d'Internet et à la manière de les résoudre. Une approche qui nous a beaucoup aidés est de considérer quels sont les obstacles au déploiement pour un meilleur Internet.

Dans le cas de SPF, certains des obstacles que nous avons identifiés sont :

• Éducation : Les utilisateurs ont reçu des informations incorrectes de sources pourtant faisant autorité sur le fonctionnement de SPF. Il faut beaucoup de travail pour « corriger le tir ».
• Intérêts acquis : Il existe des entités commerciales qui pourraient être menacées par une couche SPF à l'échelle d'Internet entièrement adoptée et maintenue. Les entreprises qui prospèrent grâce à des « sauces secrètes » de filtrage d'e-mails devraient faire face à un besoin moindre de ces solutions propriétaires. Les entreprises qui tirent profit de la difficulté actuelle à comprendre et à maintenir SPF verraient une menace directe pour leur modèle économique.
• Gestion DNS : La plupart des logiciels DNS exigent un niveau d'expertise qui échappe à la majorité des utilisateurs. Ce n'est pas parce que quelqu'un peut acheter un domaine Internet qu'il connaît les enregistrements TXT et les constructions SPF.
• Infrastructure héritée : Les personnes qui gèrent SPF aujourd'hui ignorent souvent qu'elles peuvent utiliser DMARC pour éclairer leurs activités SPF. Lorsqu'une personne novice en SPF est confrontée à un héritage problématique remontant à plus de 15 ans, elle peut trouver la tâche intimidante.

SPF existe depuis longtemps. dmarcian existe depuis la publication de la spécification DMARC, et nous utilisons DMARC pour faciliter SPF pour ceux qui travaillent à l'amélioration de l'e-mail.

Si vous avez besoin d'aide pour comprendre SPF, essayez nos ressources.

Vous souhaitez poursuivre la conversation ? Rendez-vous sur le Forum dmarcian