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

Sender Policy Framework (SPF) existe depuis longtemps et jouit d'une riche histoire qui remonte à 1997, le projet SPF lui-même ayant débuté en juin 2003. Cependant, le fonctionnement de SPF pose quelques problèmes, qui sont source de confusion, d'incompréhension et de conseils erronés. Dans cet article, nous examinons ces problèmes et les obstacles qui empêchent SPF de s'améliorer.

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 du monde extérieur. SPF ne dispose pas d'une fonctionnalité similaire aux mécanismes de retour d'informations RUA et RUF de DMARC. En l'absence d'informations provenant du monde extérieur, les enregistrements SPF doivent être construits et maintenus en utilisant uniquement des données provenant des connaissances immédiates de l'administrateur.

À l'époque pré-DMARC, les gens ont d'abord créé des enregistrements SPF en se basant sur leur propre connaissance de leur propre infrastructure. Les enregistrements SPF publiés pouvaient ou non être très précis en termes d'autorisation de tous les éléments d'infrastructure 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 qui traitent le courrier électronique entrant, des enregistrements SPF inexacts signifiaient que les décisions de délivrer ou non le courrier électronique ne pouvaient pas être basées uniquement sur le traitement SPF.

Au fil du temps, les administrateurs et les autres personnes ayant accès aux enregistrements SPF ajoutaient de l'infrastructure aux enregistrements SPF existants. Il était très rare que quelqu'un supprime quoi que ce soit, car le risque de perturber accidentellement un flux de courrier électronique légitime était présent. Personne ne savait si une entrée existante dans un bloc SPF était toujours utilisée, et la recherche de 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 eux-mêmes et 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é qui oblige les destinataires d'e-mails à traiter tous les e-mails du domaine de la même manière.

Les courriels de marketing frauduleux restent indifférenciés des courriels d'entreprise d'humain à humain, qui à leur tour restent indifférenciés des courriels envoyés par un fournisseur compromis.

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

SPF vérifie le chemin inverse du courrier électronique

Le fonctionnement du SPF et les vérifications qu'il effectue dans un courriel sont souvent mal compris. Cette confusion a conduit à la publication de nombreux articles au fil des ans, qui fournissent des conseils incorrects aux personnes non techniques qui essayaient simplement de mettre en place le SPF.

Voici comment cela fonctionne : Lorsqu'un serveur délivre un courriel, le serveur d'envoi partage une adresse électronique à laquelle les rapports d'erreur et les notifications concernant le courriel peuvent être envoyés. Cette adresse est appelée "reverse-path" et est utilisée principalement par les opérateurs de messagerie.

Le serveur récepteur utilise le domaine du chemin inverse pour rechercher un enregistrement SPF. Si cet enregistrement SPF mentionne le serveur expéditeur, alors le chemin inverse est légitime.

Aujourd'hui, le chemin inverse porte de nombreux noms : adresse de rebond, RFC5321.MailFrom, "SMTP MAIL FROM", Return-Path, adresse de l'enveloppe, etc. Ces nombreuses conventions de dénomination peuvent être assez déroutantes.

Un autre malentendu courant consiste à confondre l'adresse "From :" - l'adresse visible dans un courriel - avec le chemin inverse. Cette inexactitude amène les gens à ajouter une infrastructure à leurs enregistrements SPF sur la base de l'adresse "From :" au lieu du chemin inverse.

Il en résulte que les enregistrements SPF deviennent incroyablement volumineux, autorisant souvent de vastes sections de l'internet à envoyer des messages au nom d'un domaine internet, ce qui se traduit par un enregistrement SPF trop volumineux. Les gens cherchent alors des solutions pour gérer des enregistrements SPF incroyablement volumineux, sur la base d'une mauvaise compréhension du fonctionnement du SPF.

Si l'on ajoute à cela le fait qu'il existe désormais de nombreux services qui envoient des courriers électroniques au nom du domaine de quelqu'un d'autre (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), il est devenu compliqué de bien comprendre le fonctionnement de SPF et la manière de maintenir les enregistrements SPF.

Le résultat final pour l'ère pré-DMARC était que les gens publiaient des enregistrements SPF qui étaient souvent gonflés en autorisant des parties de l'internet qui ne devraient pas être autorisées et dépassaient les limites de traitement de SPF. Cette erreur est souvent perçue comme la notification "Too many DNS-lookups" popularisée par le SPF Surveyor de dmarcian ; elle est également inexacte en raison de la confusion sur le fonctionnement du SPF.

DMARC change la façon dont les gens voient et déploient SPF

Lorsque DMARC a fait son apparition en 2012, la situation a commencé à changer. Pour la première fois, les administrateurs ont reçu des données précises sur la façon dont les domaines sont utilisés dans le cadre de la messagerie électronique sur Internet. Avec un enregistrement DMARC en place, les administrateurs ont pu vérifier l'exactitude de leurs enregistrements SPF par rapport aux données du rapport DMARC et recevoir des conseils pour déployer correctement le SPF. Cette possibilité a provoqué une petite révolution dans le monde du SPF, car les gens ont commencé à constater à quel point il avait été mal mis en œuvre et mal supporté.

DMARC a également introduit l'exigence d'"alignement du domaine". L'alignement oblige les opérateurs de messagerie à s'identifier à l'aide d'un sous-domaine afin que l'opérateur de messagerie puisse à la fois s'identifier et identifier l'infrastructure qu'il gère. L'exigence de DMARC modifie le SPF de manière significative, ce qui entraîne des difficultés de déploiement et le perfectionnement du SPF.

Le nettoyage à l'échelle de l'internet des mauvaises indications SPF se poursuit à ce jour. Les gens rencontrent toujours l'erreur "Too many lookups" sans qu'on leur donne des indications claires sur la façon de les résoudre. Les expéditeurs tiers d'e-mails manquent toujours de conseils sur la façon d'envoyer des e-mails au nom d'autres personnes d'une manière qui soit favorable à l'administration et à la maintenance du SPF. Et les administrateurs de DNS ont encore du mal à rendre le SPF facile pour les personnes non techniques.

En savoir plus : Meilleures pratiques du FPS

Obstacles à un meilleur SPF

Grâce aux conseils clairs disponibles aujourd'hui, le nettoyage du SPF est maintenant en grande partie un effort d'éducation, d'offre de meilleurs conseils et d'ajout de fonctionnalités pour éliminer certains des mystères qui entourent le SPF.

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

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

• Éducation: Des personnes ont reçu des informations erronées de la part de sources faisant autorité sur le fonctionnement du FPS. Il faut beaucoup de travail pour "rectifier le tir".
• Intérêts particuliers: Il existe des entités commerciales qui pourraient être menacées par une couche SPF entièrement adoptée et maintenue à l'échelle de l'Internet. Les entreprises qui prospèrent grâce à une sauce secrète de filtrage des courriels devraient faire face à un besoin moindre de sauces secrètes. Les entreprises qui profitent de la difficulté actuelle à comprendre et à maintenir le SPF verraient une menace directe à leur modèle d'affaires.
• Gestion des DNS: La plupart des logiciels DNS exigent un niveau d'expertise qui échappe à la plupart des gens. Ce n'est pas parce qu'une personne peut acheter un domaine Internet qu'elle connaît les enregistrements TXT et les constructions SPF.
• Infrastructure existante: Les personnes qui s'occupent de SPF aujourd'hui ne savent souvent pas qu'elles peuvent utiliser DMARC pour informer leurs activités SPF. Lorsqu'une personne novice en matière de SPF se retrouve face à un héritage problématique remontant à plus de 15 ans, elle peut trouver la tâche décourageante.

SPF existe depuis longtemps. dmarcian existe depuis la publication de la spécification DMARC, et nous utilisons DMARC pour faciliter l'utilisation de SPF par les personnes qui travaillent à l'amélioration du courrier électronique.

Si vous avez besoin d'aide pour déterminer le FPS, essayez nos ressources.

Vous voulez poursuivre la conversation ? Rendez-vous sur le forum dmarcien