Limites des techniques d’authentification d’expéditeurs SPF, DKIM

L’usurpation d’identité étant une des méthodes préférées des spammeurs, une des solutions proposées ces dernières années était la mise en place de systèmes permettant d’authentifier l’identité de l’expéditeur, tel que SPF (Sender Policy Framework) ou encore : SenderId, DomainKeys et DKIM.

Face aux multiples techniques mises en œuvre par les spammeurs, la solution la plus logique est de mettre au point un système économique qui permette d’identifier rapidement et sans consommation excessive de ressources si un e-mail est un spam ou pas. Les stratégies qui recourent à une analyse du contenu du mail ne répondent pas entièrement à ce besoin car l’analyse exige du temps et de la puissance, notamment lorsque le système a affaire à un nombre extrêmement important de mails par jour. Les systèmes d’authentification semblent donc apporter une solution pratique à ce problème.

SPF permet aux propriétaires d’un domaine d’indiquer leur serveur de mail légitime dans leurs enregistrements DNS. Seuls les serveurs présents dans l’enregistrement ont le droit d’envoyer des e-mails en provenance du domaine. Le MTA destinataire effectue un DNS lookup sur le domaine d’origine supposé du message et vérifie si le serveur émetteur est bien présent dans l’enregistrement. Le tout est censé rendre impossible toute usurpation d’identité et garantir l’authenticité de l’expéditeur.

Premier problème : il n’y a pas vraiment de contrôle d’authenticité de l’expéditeur sur SPF. Il s’agit plutôt d’un contrôle d’authenticité du serveur d’envoi. Tout serveur autorisé à envoyer des messages en provenance d’un domaine peut envoyer des messages en provenance de ce domaine (c’est redondant, mais assez expressif). Cela ne dit rien sur l’identité de l’utilisateur ou sur le contenu du message. Le système comporte donc une faille logique fondamentale. Un spammeur qui arrive à prendre le contrôle d’une machine peut facilement inscrire ses propres serveurs mails dans les enregistrements DNS du système. En y réfléchissant, ils n’auront même pas besoin d’ajouter leurs serveurs de mail : il leur suffit d’utiliser le serveur de mails de la machine, puisqu’ils en ont déjà le contrôle.

Second problème : qu’est-ce qui empêche les spammeurs d’utiliser des systèmes  qui respectent parfaitement SPF ? A l’heure actuelle, absolument rien. En fait, dès le début, des spammeurs se sont conformés aux mécanismes d’authentification (voir dans le numéro de Septembre 2004 d’Information Week, l’article « Spammers hijack sender id » de T. Claburn ). Acquérir un domaine et installer SPF est extrêmement facile.

Troisième souci, qui explique pourquoi les grands fournisseurs d’accès sont réticents : lorsqu’ils transfèrent le courrier d’un serveur à un autre, il y a un risque pour que le courrier soit refusé à l’arrivée puisqu’il ne provient plus de l’adresse IP de l’expéditeur original. Et quid des organisations qui ont de multiples serveurs mails situés parfois dans des pays différents et qui doivent gérer un grand nombre d’adresses IP ? Une erreur dans le recensement de ces IP et les messages qui y transitent seront considérés comme des spams.

Dernier problème : SPF (tout comme Sender et Domain Keys) n’est pour l’heure ni unanimement appliqué ni en position dominante. Cela complique la tâche de l’utilisateur légitime qui doit configurer son serveur à la fois pour SPF, SenderId, DomainKeys et DKIM, sachant que de nombreux grands serveurs de mails ne recourent pas encore à ce type d’authentification mais s’il ne les implémente pas (ou s’il l’implémente mal), il risque de voir ses courriers se perdre. Voilà bien le problème : l’utilisateur légitime qui n’utilise pas SPF peut voir ses mails refusés, tandis que le spammeur qui s’y conforme verra ses messages acceptés.