Mais face à l'ingéniosité des spammeurs, la solution idéale et unique ne semble pas encore exister. On arrive aujourd'hui à des taux de blocage de l'ordre de 80%, mais cela reste encore insuffisant au vue du trafic d'e-mails générés dans la plupart des entreprises.

Les principales solutions anti-spams se basent aujourd'hui sur une analyse des messages (et/ou transactions SMTP) par rapport à des critères tendant à déceler un message de type "spam" dans le flot de messages traités :

• recherche de mots-clés dans le sujet et corps du message (couplée avec des systèmes "experts" –par exemple l'analyse statistique Bayésienne),
• recherche de la légitimité de l'émetteur par rapport à la syntaxe de son adresse ou par rapport à une base de données prédéfinie,
• recherche de la validité du serveur de messagerie qui émet le message,
• ...

Ces solutions, qui permettent de réduire de manière significative le nombre de "spams" reçus, restent dépendantes de l'évolution des techniques utilisées par les "spammeurs" (ces derniers arrivant à trouver des parades aux techniques de protection connues) :

• utilisation de messages au format HTML où des mots/lettres sont insérés dans le texte dans un format quasi-transparent (en tout petit ou de même couleur que le fond du message)
• utilisation temporaire de domaines ".com", ".info", … légitimes (domaines où la réservation est très souple)
• utilisation d'un message simple suivi d'une URL,
• utilisation d'images (GIF, JPG, …) contenant le texte du message,
• ...

Afin de consolider les techniques anti-spam existantes, des solutions alternatives basées sur de nouveaux concepts tentent peu à peu de faire leur place sur le marché. Ces solutions se focalisent sur les techniques de protection contre l'usurpation d'adresse e-mail (couramment utilisées par la communauté des spammeurs et des concepteurs de vers/virus) :

• SPF (Sender Policy Framework)
• DomainKeys de Yahoo
• Caller-ID de Microsoft

Ces trois solutions viennent en compléments des solutions existantes et apportent une brique supplémentaire dans la panoplie d'outils de lutte contre le "spam".

A titre de remarque, d'autres projets existent, comme "Greylisting" (gestion automatique de listes Blanches/Noires basée sur des rejets temporaires des e-mails : http://projects.puremagic.com/greylisting/index.html ), mais ils ne seront pas abordés dans le présent article.

SPF :

Site : http://spf.pobox.com/

SPF est une technologie basée sur la collaboration de différents systèmes d'information reliés sur Internet.

Le principe de SPF repose sur l'annonce, par les sites utilisant cette technologie, des machines (serveurs de messagerie) qui peuvent légitimement envoyer des e-mails pour un nom de domaine précis. Ensuite, un filtre SPF dédié et implémenté sur les serveurs de messagerie pourra, à chaque réception d'e-mail vérifier la validité de la machine émettrice du message en consultant l'annonce de site "émetteur".

Cette technique a pour but de réduire de manière conséquente les messages de "spam" (et de vers) utilisant des adresses émettrices "spoofées".

Plusieurs grands sites ont déjà adopté SPF : http://spftools.infinitepenguins.net/earlyadopters.php

D'un point de vue technique, SPF s'appuie sur :

• Des annonces aux niveaux des serveurs de noms (DNS)
  • Champ de type "TXT" dans la configuration d'un domaine représentant les machines autorisées à émettre un message pour le domaine donné.

• Des filtres dédiés au niveau des serveurs de messagerie qui, à chaque message reçu, tente de connaître l'annonce SPF du site émetteur afin de traiter (taguer) le message ("pass", "none", "fail").

• Un message provenant d'un site émetteur n'utilisant pas SPF sera tagué comme "none" et le message transitera alors jusqu'à son destinataire final.
• Plusieurs plugins ont été développés pour les serveurs de messagerie (Sendmail, Postfix, …) afin d'implémenter le filtrage SPF : http://spf.pobox.com/downloads.html

Cependant cette technologie a pour l'instant quelques inconvénients majeurs :

• Pour fonctionner de manière réellement efficace, elle a besoin d'être adoptée par une majorité d'acteurs sur Internet afin que les contrôles sur les e-mails soient les plus pertinents possibles.

• La gestion des transferts automatiques d'e-mail vers une autre adresse "casse" la méthode de vérification et tend à taguer le message comme "à rejeter".
  • Des développements sont en cours pour tenter de résoudre ce problème.

• Cette méthode n'empêche pas l'envoie de "spam" :

• par un poste légitime (cas d'une infection virale par exemple),
• par un domaine légitime.

De plus, la sécurité et l'intégrité de ce type de solution repose, en dehors du serveur de messagerie, sur celle d'un nouvel élément qui est le serveur de noms (DNS) où sont stockées les informations concernant le(s) domaine(s) géré(s), et sur celle des transactions DNS.

Le Cert-IST utilise une annonce SPF dans son serveur de noms depuis le mois de juillet 2004 à titre expérimental. Ceci permet au site utilisant la technologie SPF et gérant de manière très rigoureuse le transfert des e-mails, de pouvoir valider les messages en provenance du Cert-IST. Nous restons également intéressé par tout retour d'expérience/problème lié à cette configuration.

Nota : La compatibilité entre "SPF" et le logiciel "SpamAssassin" sera prise en compte dans la version 3.0 de ce dernier.

DomainKeys :

Site : http://antispam.yahoo.com/domainkeys

"DomainKeys" est une technologie développée par "Yahoo" et présentée à l'IETF (http://www.ietf.org/internet-drafts/draft-delany-domainkeys-base-00.txt ). Elle s'appuie sur la même philosophie de "SPF" à savoir qu'elle utilise des annonces sur des serveurs DNS afin de contrôler la légitimité de l'expéditeur d'un e-mail.

Cependant, "DomainKeys" se différencie de "SPF" par le fait qu'elle utilise une notion de signature RSA liée au domaine expéditeur (signature contenue dans les en-têtes des messages envoyés).

D'un point de vue technique, "DomainKeys" s'appuie sur :

• Au niveau du domaine (serveur de messagerie) expéditeur :

• La génération d'une paire de clés privée/publique (RSA – SHA1 – 384 bits) dont la clé publique est disponible au travers d'une annonce DNS (champ DNS de type "TXT") et dont la clé privée est conservée sur le serveur de messagerie sortant.
• La signature de l'en-tête et du corps de chaque message sortant avec la clé privée. Cette signature est ajoutée dans l'en-tête du message.

• Au niveau du domaine (serveur de messagerie) destinataire :

• Des filtres dédiés au niveau des serveurs de messagerie qui extraient la signature "DomaiKeys" de l'en-tête de l'e-mail et qui interrogent le domaine émetteur (via une requête DNS) afin d'obtenir la clé publique rattachée à ce domaine.

• Si la vérification de la signature est correcte, le message est transmis au destinataire
• Si la signature est mauvaise, un traitement particulier est effectué (rejet, tag, …).

Cependant, la technologie "DomainKeys" a sensiblement les mêmes inconvénients que "SPF" à savoir :

• le besoin d'une adoption généralisée par les acteurs d'Internet,
• une certaine difficulté à gérer les listes de diffusion,
• l'envoi de spam par un poste ou un domaine légitime,
• une dépendance vis-à-vis de la sécurité des serveurs et transactions DNS,
• mais aussi une taille de clé de chiffrement (384 bits) un peu faible par rapport aux moyens actuels en matière de déchiffrement.

Caller-ID :

Site :

• http://www.microsoft.com/presspass/features/2004/Feb04/02-24CallerID.asp
• http://www.microsoft.com/downloads/details.aspx?FamilyID=9a9e8a28-3e85-4d07-9d0f-6daeabd3b71b&displaylang=en (spécifications)

La nouvelle technologie de Microsoft "Caller-ID", présentée en mars dernier, ressemble sensiblement à "SPF" dans la mesure où les sites devront diffuser via un enregistrement DNS de type "TXT" des informations au format XML concernant leur politique de messagerie (serveurs de messagerie légitimes, …).

Selon, ces spécifications "Caller-ID" devrait pallier les problèmes des listes de diffusions et des transferts d'e-mails.

Ce service est actuellement (durant l'été 2004) testé par Microsoft sur son service de messagerie "Hotmail".

Cependant, la relative jeunesse de ce concept et le manque d'implémentation et de référence maintiennent "Caller-ID" au rang de technologie expérimentale.

De plus, il semblerait que le dépôt de la technologie "Caller-ID" par Microsoft pose certains problèmes pour une ouverture vers le monde du logiciel libre.

Nota : Début juin 2004, Microsoft a également transmis à l'IETF une nouvelle technologie "Sender ID" qui réunit les fonctionnalités de "Caller-ID" et de "SPF" afin de combattre les problèmes d'usurpation d'adresses (http://www.microsoft.com/mscorp/twc/privacy/spam_senderid.mspx ).

Conclusion:

Ces technologies alternatives ne se présentent pas comme des solutions infaillibles dans la lutte contre le "spam". Bien qu'elles soient pour l'instant adoptées par une minorité de sites, leur développement et leur adoption à une plus grande échelle devraient à terme les amener à compléter la boite à outils "anti-spam", afin de la rendre encore plus étanche à ce phénomène.

Cependant, il serait souhaitable qu'un standard unique puisse émerger afin d'éviter la "collision" de trop nombreuses technologies au détriment du but recherché et des performances des serveurs de messagerie et des réseaux.

Pour plus d'information :

Liste de discussion "sec" de l'OSSIR : http://www.ossir.org/listes/

(Les technologies présentées dans cet article ont été discutées abondamment dans les fils de discussion [SUR] Sender Policy Framework, "[SUR] Adoptons SPF en attendant mieux" et "[SUR] SPF et SpamAssassin 3.0")