SPAM

Principes et problèmes du SPAM

Le mail circule via Internet via le protocole protocole SMTP et en se basant sur IP et DNS.

Le problème: il n'y a aucune identification, et envoyer du courriel est pour ainsi dire gratuit, par conséquent toute boîte au lettre peut être remplie de spam par n'importe qui, sans la contrainte de coût du courrier postal.

Depuis plusieurs années, à mesure que ce phénomène gagne en puissance, diverses solutions ont été mises en oeuvre. Pour résumer, aucune ne fonctionne vraiment bien, et aucune n'est réellement sans douleur.

On cherchera, au passage, des solutions qui permettront de filtrer à coup quasi-sûr un spam, de manière à réaliser ce filtrage en amont, épargnant cette peine à l'utilisateur de notre service de courriel, et d'autre part afin d'éviter de devoir vérifier ce filtrage manuellement, au cas où le filtre aurait filtré un bon message ("false-positive").

On gardera enfin à l'esprit tous les types d'utilisation de SMTP, notamment les listes de diffusion, qui sont parfois jugées incompatibles avec les solutions proposées.

Principes de combat

L'évolution du spam au cours des dernières année fait penser à la lutte contre les parasites: chaque année on crée de nouveau pesticide pour l'éradiquer, et chaque année une nouvelle forme plus résistante fait son apparition. Plus on la combat sévèrement, plus la forme suivante sera résistante.

Dans ces conditions deux solutions sont envisageables:

• accepter la fatalité de l'existence du problème, et ne lutter qu'à un niveau minimum
• être sûr de détruire complètement toute souche de l'espèce (si tant est qu'il n'y a pas de réservoir)

Individuellement les solutions contre le spam tendent à vouloir définitement régler le problème du spam. Soit elles n'y parviennent que partiellement (et les spammers d'adaptent), soit elles filtrent des courriels légitimes en quantité non-négligeable, soit elles proposent des solutions qui à long terme éradiquent non seulement les spammeurs mais également un certains nombre de libertés aux particuliers et/ou aux PME/PMI - sans nécessairement garantir la fin de la publicité dite "légale".

Cependant certaines solutions peuvent être intégrées à un système de "score" tel que SpamAssassin. À la place d'éradiquer de nombreux messages légitimes, la solution fournit une heuristique qui combinées avec d'autres méthodes tendent à cerner relativement précisemment le SPAM, sans garantie toutefois.

Les bases

La FAQ de Hashcash est bien faite et aborde les points du point de vue d'un utilisateur soucieux de sa boîte aux lettres mais aussi de ses libertés.

Wikipedia décrit (en anglais) de manière générale un certain nombre de solution.

Listes noires

La solution qui vient rapidement à l'esprit est de mettre des IPs sur liste noire. Le principal défaut de cette solution est de se baser sur l'IP - utiliser une adresse IP de cette manière est une erreur qu'on ne fait logiquement plus depuis les klines IRC:

• Cela estime que toutes les IPs sont fixes. Je ne serais pas surpris si la majorité des IPs étaient plutôt dynamiques. Le listage d'adresses IP dynamiques, donc un emplacement plutôt que l'expéditeur à proprement parler, interdit aux particuliers d'utiliser leur propre serveur SMTP. Le fait qu'il s'agisse d'une pratique effectivement peu répandue 1) n'en est pas moins intéressant 2) contribue de manière importante à la rareté de cette pratique.
• Une adresse IP peut représenter plusieurs personnes (adresse IP dynamique), mais une personne peut également être représentée par plusieurs adresses IP: répartition de charge.
• Le listage d'adresses IP est souvent erroné et long à rectifier.

L'utilisation de l'IP reste une solution qui fonctionne raisonnablement en pratique, donc intégrable dans un système de score, pourvu que le poids qui est donné à cette méthode ne soit pas immédiatement déterminant.

L'attrait d'utiliser directement des listes noires au moment de la connexion est le gain en temps processeur pour traiter chaque message. Le fort taux d'erreur devrait cependant encourager à éviter cette solution, et préférer l'ajout de nouvelles machines pour traiter le courriel.

RFC-compliance

D'autres solutions confondent envoi de spam et non-respect des RFC décrivant SMTP. La plupart du temps le respect de SMTP ne présume en rien de l'origine du message (voir plutôt graylisting), mais a eu un certain succès du temps où les logiciels utilisés par les spammeurs étaient rudimentaires.

Aujourd'hui on peut se demander si spammeurs n'ont pas des systèmes plus proche des RFCs que ceux des expéditeurs légitimes. L'application aveugle des RFCs n'est pas nécessairement une bonne chose, soit dit en passant. (TODO: un lien sur la citation décrivant un système DNS parfaitement aux normes mais par conséquent non distribué)

Authentification

SMTP est un protocole sans authentification - une approche est donc de corriger ce "défaut". Le courriel peut donc être identifié à l'aide des solutions suivantes, mais l'identification d'une base d'utilisateur de potentiellement 8 milliards d'individus * une infinité de boîtes aux lettres par personnes ne permet pas directement d'affirmer quoi que ce soit sur le contenu du message. On notera enfin qu'une entreprise utilisera en général la même adresse pour communiquer à ses clients à la fois des informations cruciales (notification d'un service arrivant à expiration, mots de passe...) et du spam (publicités en tout genre).

Ces méthodes sont appuyées par de grande entreprise qui cherchent plus à éradiquer le spam illégal que le spam tout court. Il n'y a pas, à proprement parler, de spam légal: aucune personne sensée ne souhaite recevoir du spam (ou de la publicité, ou de l'information client, qu'importe le nom que l'on lui donne), et un spam reste un spam quels que soient son origine et son mode de transmission.

SPF

SPF propose une idée intéressante d'authentifier toujours au niveau IP mais en passant par un champ DNS qui indique quels noms de machine peuvent envoyer le courriel d'un domaine donné. Cela permet a priori les serveurs SMTP des particuliers, pourvu d'utiliser un service de DNS dynamiques.

Ceci permet dans un premier temps non pas de savoir si un message est ou non du spam, mais de détecter s'il a été envoyé par le possesseur du domaine. On peut donc automatiquement, avec un faible temps de traitement, éliminer tous les messages forged / falsifié d'un domaine utilisant SPF.

Les spammers peuvent eux aussi utiliser SPF. Si tout le monde est sous SPF, alors on est logiquement sûr de la provenance de chaque message, mais en aucun cas de sa teneur spam/non-spam. Les ennuis commencent ici: la base SPF donnerait naissance à un groupe de domaines "reconnus", et les nouveaux arrivants seraient suspectés d'être des spammeurs par défaut, devant alors négocier l'acceptation de leur courrier soit par l'age de leur domaine, soit en payant un des membres du groupe qu'il lui apporte son soutien.

La composition de ce groupe initial est critique; les suggestions incluent par exemple les entreprise Fortune 2000, et les exemples données impliquent souvent amazon.com ou aol.com - ce qui est discutable, ces entreprises envoyant certainement plus de messages de publicité que l'ensemble des sites persos de l'Internet.

Cette organisation élèverait également la barrière d'entrée pour les entreprises nouvelles sur Internet.

La FAQ du site mentionne fièrement que le système de mail passe d'une présomption d'innocence à une présomption de culpabilité, ce qui devrait suffire pour rendre l'approche discutable.

SPF n'est pas nécessairement mauvais en soi (mettre fin aux courriels anonymes), mais le futur qu'il nous laisse entrevoir n'est pas nécessairement enviable au présent.

À remarquer également, le principe de certification proposé nécessite une forme ou l'autre d'authentification, qui pourra sans doute facilement être contournée par les spammeurs. Comment distinguer une jeune entreprise d'un pays exotique voulant lancer un service mail, d'un spammeur?

Greylisting

(littéralement: liste grise)

Il s'agit apparemment d'un principe général étudiant les différence entre les méthodes d'envoi des spammeurs et celles des utilisateurs légitimes.

Une proposition en particulier semble attirer l'attention et s'appuie sur le fait que les spammeurs n'envoie souvent un courriel qu'une seule fois, même si le serveur distant demande de réessayer plus tard. La technique est donc de mémoriser (adresse IP + adresse d'envoi (à vérifier)) et de n'accepter un envoi qu'au bout de N connexions ou N secondes/minutes/heures.

Et si les spammeurs s'adaptent? Cela leur coûtera plus cher, d'une part, et surtout on disposera d'un délai appréciable avant l'acceptation du mail, permettant de mettre

Des personnes enthousiasmes parlent de résultats miraculeux. Cependant ce filtrage s'effectue avant le transfert du message proprement dit. Il n'est pas possible de tester son efficacité. Le système peut être tourné en dérision: rejeter tous les mails sans exception sera également miraculeux, car aucun spam ne sera délivré - mais on ne sait effectivement pas combien de mails légitimes ont été ainsi manqués.

D'autres personnes critiquent l'utilisation d'un code d'erreur (demandant de réessayer plus tard) pour un autre but que celui spécifié dans le protocole.

En pratique, on lit que certains logiciels (certaines version de Lotus Notes par exemple) ne gère par ce code correctement et considère l'échec d'envoi comme définitif. D'autres services utilisent de la répartition de charge et ne présentent pas toujours la même adresse IP d'origine, même s'il s'agit qu'envoyer le même e-mail.

La solution présentée pour ce 'bug' est nettement plus discutable puisqu'elle fait intervenir une liste blanche contenant par exemple les serveur de Yahoo. Il n'y a pas vraiment de raison de faire ainsi confiance aux utilisateurs d'un ISP, ni à l'ISP lui même. D'un autre côté, on peut être à peu près sûr que ces adresses IP ne seront pas utilisées pour envoyer du courriel via mass-mailing - sauf IP spoofing.

L'avis en cours de Sylvain est que cette technique, un peu trop manichéenne à son goût, pourrait peut-être s'avérer utile à son niveau le plus simple, disons accepter au 2e essai, et sans liste blanche.

Idée liée: utiliser greylisting avec un système de détection passive tel que p0f, de manière à ne greylister que les machines Windows (le système majoritairement utilisé par les postes utilisateurs infectés pas les spammeurs à des fins de relai; pour les serveurs, bien fait pour eux, fallait utiliser un OS libre :p).

Pour utiliser p0f dans un vserver:

echo 'RAW_NET' >> /etc/vservers/myvserver/bcapabilities

init.d pour p0f (http://postfix.state-of-mind.de/patrick.koetter/p0f):

/usr/sbin/p0f -l 'dst host <ip address of external interface> and tcp dst port 25' 2>&1 | /usr/sbin/p0f-analyzer.pl 2345 &

Les serveurs greylist en paquet dans Lenny:

• postgrey (présent dans Debian volatile, probablement pour mettre à jour la liste blanche)
• sqlgrey
• tumgreyspf

Postgrey:

• patch p0f
• doc du patch
• Le patch est vieux et ne s'applique pas proprement sur la version de Etch

p0f + amavisd-new

• http://www200.pair.com/mecham/spam/virtualp2.html#p0f
• /usr/share/doc/amavisd-new/RELEASE_NOTES.gz

Postfix greylisting filter (greylists Windows-clients only);

• pas de license?
• http://marmarek.w.staszic.waw.pl/~marmarek/download/os-greylist.pl

maRBL - http://slu.ms/code/marbl

• applique le greylisting en fonction de l'OS détecté, de listes noires ou de SPF
• pas de license? (http://freshmeat.net/projects/marbl/ indique "GPL")
• 1.0:
  • http://leander.koornneef.net/marbl/marbl+p0f
  • http://leander.koornneef.net/marbl/marbl+p0f+ptr+spf
• 1.1: http://slu.ms/files/marbl/marbl-1.21
• quelques instructions d'installation
  • dépendances:

aptitude install libnet-rblclient-perl libio-multiplex-perl

Filtres Bayesien naïfs

Articles explicatifs

La série d'articles enthousiastes de Paul Graham sur le sujet est assez intéressante. Ce ne sont pas les premiers sur le sujet, mais il s'agit des plus connus:

• http://paulgraham.com/spam.html
• http://paulgraham.com/spamfaq.html
• http://paulgraham.com/better.html
• http://paulgraham.com/wfks.html : Will filters kill spam? Questions/réponses sur les limites de l'approche.
• http://paulgraham.com/falsepositives.html

Lire aussi le fonctionnement de la commande sa-learn de SpamAssassin, avec une introduction générale et vaste.

Expérience personnelle (incomplète)

J'ai testé cette solution il y a quelques temps avec POPFile et SpamBayes, avec de ennuis techniques (POPFile s'est mis à marquer tous les mails comme spam, et SpamBayes n'arrivait pas en mode proxy à se récupérer plusieurs comptes chez le même ISP, et pas d'aide sur la mailing list).

Cette année, je réessaie plus assiduement: La solution offerte par Mozilla Thunderbird fonctionne relativement bien. Je l'essaie depuis quelques semaine, sur une adresse modéremment spammée (disons une petite dizaine par jour) avec un traffic d'environ 15-20 messages par jour. Cela fait bien une semaine que je n'ai eu aucune erreur.

Limites du modèle mathématique

Il est dit que le modèle présenté par PG est loin d'être proprement bayesien. Des améliorations un peu plus "carrées" ont été proposées:

• http://radio.weblogs.com/0101454/stories/2002/09/16/spamDetection.html

Noter notamment que dans tous ces tests où des résultats miraculeux sont présentés, les nombres de messages spam et ham sont équilibrés. En pratique, une nouvelle adresse recevra peu de spam, et pour ma part j'en reçois plus de 75% (j'ai beaucoup de vieilles adresses). D'autres techniques de filtrages pourraient être utilisées pour rétablir l'équilibre (par exemple, les messages auxquels SpamAssassin donne un score très élevé, et scores autours de 0).

Ciblage

Les filtres bayesiens naïfs réalisent des statistiques sur le contenu des courriers reçus, et sont donc d'autant plus efficaces que le contenu analysé est ciblé. Réaliser des statistiques avec SpamAssassin::Bayes sur l'ensemble du courriel d'un domaine n'est probablement pas une bonne idée, à moins que l'ensemble des correspondants d'un domaine traitent des courriers très similaires (notamment, uniquement professionnels). Creuser comment fournir un dossier spam par utilisateur.

Apprentissage

Autre problème: corriger les erreurs.

• D'une part il faut vérifier de temps à autre les messages du dossier spam et y récupérer les faux positifs
• D'autre part il faut déterminer une stratégie d'apprentissage:

Une fois encore, lancer SpamAssassin::Bayes en mode bayes_auto_learn sans aucun processus de correction risque de mal fonctionner.

http://www.garyrobinson.net/2004/02/spam_filtering_.html: Training to exhaustion, présente dans l'article "apprendre en cas d'erreur" et "apprendre jusqu'à épuisement".

http://www.bgl.nu/bogofilter/scale.html: Utiliser une même liste de mots pour tous les utilisateurs d'un site (et non une liste par utilisateur) peut peut-être rendre le filtrage moins efficace, mais ce n'est pas obligatoire. L'article pose également un autre problème: si les utilisateurs ne classent pas leur messages en spam/ham, le filtrage risque également de perdre en efficacité.

Invalidité du modèle

Même en admettant une mise en oeuvre parfaite, il est possible aux spammers de s'adapter en utilisant massivement un langage neutre, ce qui confond la limite entre spam et message légitime neutre, faisant globalement baisser la précision des filtres bayésiens:

• http://jerf.org/iri/2002/11/19.html
• http://homepages.tesco.net./~J.deBoynePollard/FGA/smtp-anti-ubm-dont-work.html#Bayesian

Hashcash

Ou l'augmentation artificielle du coût d'envoi d'un courriel, en ajoutant à chaque courriel un en-tête très long à calculer (1 ou 2s par courriel) mais rapide à vérifier. Des problèmes avec les listes de diffusions et autres envois en masse légitimes (si, si, il y en a :)).

Le but est d'augmenter le coût en temps processeur d'envoi d'un mail. Noter aussi que de nombreux utilisateurs sont atteints de virus exploités par les spammeurs, qui disposent ainsi d'une force de calcul parallèle et distribuée non-négligeable.

Les listes de diffusion, ou plus généralement les utilisations légitimes de l'envoi de courrier en masse, posent évidemment problème.

http://www.hashcash.org/faq/index.fr.php

• Ben Laurie & Richard Clayton: talks papier transparents (2004) analysent les statistiques et pensent qu'une telle mesure ne ralentira pas significativement le spam.

Tarpit

Ralentir le serveur dans certaines conditions (ex: harvest attack).

• http://www.postfix.org/rate.html

Notez que cela ne fonctionne probablement pas dans le cas du relai SMTP d'un ISP (eg. smtp.aol.com) qui envoie continuellement du courriel partout).

Liens

• SPF is harmful. Adopt it.: a series of interesting statements and links that criticizes all the current anti-spam measure and propose IM2000 as a solution. IM2000 est analysé sur cette autre page [1].

• Thèse de Shalendra Chhabra

Des black lists:

• http://www.spamhaus.org/
• Soumission des spams par les utilisateurs:
  • http://www.spamcop.net/
  • http://www.spam-rbl.com/

Des sites à éventuellement regarder:

• http://www.cauce.org/ : site d'information
• http://www.weird.com/~woods/ :

Masquage minimal de son adresse e-mail:

perl -e '$a = "your\@email.tld"; $a =~ s/(.)/"&#".ord($1).";"/eg; print "$a\n";'