Limites des solutions basées sur l'authentification


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

Dimanche 8 mars 2009 par Tsilefy

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.

Limites des techniques d’authentification d’expéditeurs SPF, DKIM 4.67/5 (93.33%) 3 votes

  • del.icio.us
  • Twitter
  • Facebook
  • LinkedIn
  • RSS
  • StumbleUpon
  • Digg


Tags : , , , , ,


Articles similaires:
- Authentifiez vos emails sortants pour une meilleure délivrabilité (50.1%)
- Fail-over ou load-balancing de serveurs de messagerie (39.9%)
- Domaine non vérifiable (39.9%)
- Principe de fonctionnement détaillé du service DNS (39.9%)
- Format des messages du protocole DNS (39.9%)

Une réponse à “Limites des techniques d’authentification d’expéditeurs SPF, DKIM”

  1. Authentification des emails « Spam, anti-spam, mta, email, fqdn écrit :

    […] Ces techniques d’authentification ont ses limites car les serveurs ou domaine des Spammeurs, peuvent très bien répondre aux normes demandées par les serveurs destinataires qui considéreront les Spams comme mails sollicités. D’autre part, ces technologies ne sauraient être efficace que si tout le monde les utiliserait contre les Spams,  mais les hébergeurs refusent  d’ajouter le champ TXT  sur un domaine, il en résulte alors que ses utilisateurs ne seront pas efficacement protégés des Spams. Ces techniques  viennent à l’aide aux autres solutions anti-spam déjà utilisées et contre le spoofing d’adresses email. […]

Laisser un commentaire

*


English Espa?ol Italiana Deutsche

Copyright © 2002-2014 OKTEY - Tous droits réservés - Accessibilité - Mentions légales - Plan du site - Google+   Flux RSS