Non-filtrage de Spam basé sur le Message-ID

Cela fait quelque temps que j'en parle, mais malheureusement j'ai la flemme de me répéter a ce sujet, aussi j'ai fait cette modeste page. Malheureusement comme j'ai pas trop le temps en ce moment c'est un peu brouillon, et ça s'adresse surtout a des gens qui connaissent déjà procmail et le fonctionnement du mail. Si ce n'est pas votre cas, je conseille d'aller faire un tour sur Linux-France, ou tout ça est expliqué. Si il y a quelque chose que vous comprenez pas (mais que vous comprenez grosso-modo le reste), n'hésitez pas a m'envoyer un mail ou à participer au forum; ma réponse sera l'occasion de compléter et d'éclaircir la page, faites de même si vous avez des infos complétant le sujet. Avec un peu de bol je trouve le temps de compléter, et cette page sera un jour complètement traduite en Français...
En fait la méthode que je vais vous présenter ne permet que de savoir de manière assez précise qu'un mail n'est pas un spam, mais ne permet pas de savoir si on a affaire à un Spam. Avec ce que vous allez lire, vous devriez diviser par 4 le nombre de mail a faire traiter a votre anti-spam (donc pas mal diminuer le temps de traitement moyen d'un mail), et par 2 les faux-positifs. C'est pour cela que je parle de "non-filtrage". Tout cela suppose que vous utilisez déjà SpamAssassin par exemple, et que vous l'appelez via procmail (ou vous adaptez ce que je raconte à maildrop ou votre MDA).
Enfin, autre intérêt de la chose : vous n'allez pas avoir les headers que rajoutent les anti-spams à ces mails, et donc économiser de la place disque, voire de la BP (vision "économie de bouts de chandelles de la chose").

Le principe

Rappel : le message-ID désigne de manière unique un mail. Lire la RFC 822 si vous voulez en savoir plus a son sujet.
Le principe a déjà été évoqué ici ou là, mais personne n'est jamais passé à l'acte : utiliser le champ "Reference" ou le champ "In-Reply-to" pour détecter les hams.
Ces champs sont utilisés par les bons MUAs pour faire du threading ; le premier contient tous les Messages-ID des mails qui le précèdent dans le thread, le second uniquement le Message-ID du mail auquel il réponds, et sont mis en place par les "bons" logiciels. Environ 95% des mails parvenus en réponse à un autre mail ont l'un des deux champs (voire les deux); parmis les logiciels qui n'en mettent pas on citera les célèbres Microsoft Exchange et Lotus Notes. Si votre MUA ne met pas en place de tels champs, je ne peux que vous conseiller de le mettre a la poubelle, et d'en changer si c'est possible. Pour plus d'informations au sujet de ces champs, vous pouvez aller voir sur la page de D. Bernstein (attention, certaines pages de son site sont un peu "faussés").
Revenons donc a ces champs : lorsque nous recevons un mail, nous pouvons parfaitement regarder si l'un de ces champs contient le Message-ID d'un ham que nous avons reçu ou envoyé précédemment. Comme nous savons qu'il est très difficile voire impossible pour le spammeur de deviner les Messages-ID des mails légitimes recus précedemment, il ne pourra pas tenter de forger ce champ. Tout au plus pourra-t-il y mettre quelque chose dedans, mais en aucun cas y mettre un Message-ID d'un de vos hams (car comment le connaitrait-il ??). Donc tous les mails dont le champ References ou In-Reply-To pointe vers un ham sera un ham !

Ainsi sur les mailing-lists auxquels vous êtes inscrits (enfin celles qui sont pas filtrés contre le spam de manière efficace), seul le premier message d'un thread aura besoin d'être filtré par votre couteux anti-spam actuel.
Sur vos courriers personnels cela arrivera moins souvent, mais si vous reconnaissiez les Message-IDs de vos mails ? Ou si vous trouviez un moyen de stocker quelque part les Message-IDs des mails que vous avez envoyé ? Et bien nous allons voir ça aussi.

Les spammeurs vont-ils réussir a contourner ça ?

Un spammeur pourra tenter de vous envoyer un mail anodin, sans HTML, sans parler de Viagra, attendre que le message-ID soit mémorisé comme ham (puisque nous allons mémoriser les Messages-ID automatiquement, hors de question de le faire a la main, ou de regarder tous les anciens mails a la recherche de ceux-ci).
Mais pour le moment, je n'ai jamais vu de tels mails, et puis s'ils se mettaient a en faire, ça doublerait le nombre de mails qu'ils vont devoir envoyer, donc divisera par 2 le nombre de spams qu'ils pourront envoyer. Et dans ce cas cette vérification pourrait être intégrée dans SpamAssassin, comme un simple règle, ou bien on pourra changer les règles de mémorisation du Message-ID...

Quand au spammeur qui parviendra a ré-utiliser les règles que vous utilisez pour reconnaitre les Messages-ID des mails que vous auriez envoyés, il sera balaise. En fait c'est même impossible si l'algorithme générateur de Messages-ID de votre MUA est compliqué, ou si vous créez la base de données de Message-IDs a partir des mails reçus ceux que vous avez employés.

Techniquement

Base de données des Messages-ID

Je parle d'une base de données des Messages-ID de hams, mais comment la créer ? Je n'utiliserait par Oracle, rassurez-vous : le format le plus simple c'est un simple fichier texte, contenant un Message-ID par ligne, et sans les caractères '<' et '>' que l'on retrouve dans tous les Message-ID.
Pourquoi un tel format ? Simplement parce que l'on va utiliser fgrep (ou grep -F).

Création d'une base de données (pour procmail)

La méthode la plus simple pour créer votre base de données, sera la règle procmail suivante, qui mémorisera les messages-ids des hams (à placer après l'anti-spam donc) :

# Mettre les spams dans une boite a part
:0:
* ^X-Spam-Status: Yes
spam

# si ce n'est pas un spam, sauver le message-id
:0E c :message-id.block
| echo `formail -x Message-ID: | tr -d '<>[:cntrl:]' ` >> $MAILDIR/.message-id

Avec ça votre fichier "$MAILDIR/.message-id" ne fera que grossir, de temps en temps vous pourrez supprimer les premières lignes de celui-ci.

A la porcho avec postfix

Cette solution consiste à parser les logs (récents) de postfix, et de stocker TOUS les Messages-ID qui y sont trouvés dans un fichier. Et bien sur, j'ai rien trouvé de mieux que de faire ça avec un script appelé toutes les 3 minutes par la crontab. Ah oui, c'est crade !!
Avec ca tous les mails envoyés et reçus par les utilisateurs du serveur seront utilisés, donc aussi tous les Spams. Dès que les spammeurs essayeront de contourner, ce sera cuit. Par contre du coup cette cochonnerie reconnait tous les Messages-IDs des mails que vous avez envoyés, sans autre effort supplémentaire.
Voici donc le code :

#!/bin/bash
sed -ne '/message-id/!d;s/.*message-id= *<\(..*\)>.*/\1/p' /var/log/mail.log* | sort -u > /tmp/message-ID

Et pour votre crontab :

*/3  * * * *  /usr/local/bin/liste-MID

Et formail ?

Les connaisseurs se demandent pourquoi ne pas utilier formail. L'option permettant de reconnaitre les doublons de formail fait a peu près ce que faisait la solution procmail !! Malheureusement il n'utilise pas un format parsable par fgrep, mais avec quelques modifications il en serait effectivement capable. Et on pourrait même imaginer lui permettre de vérifier directement si les champs References ou In-Reply-to pointent sur un des mails contenus la-dedans en une opération. J'ai pas envie de m'amuser a le patcher pour ça (en fait surtout pas le temps), mais vu que c'est la méthode la plus propre, je vous encourage a le faire (si je décide pas de le faire moi-même dès que j'ai du temps) !

Vérifier l'existance d'un Message-ID dans notre base de données

Bon, maintenant que la base de données est faite proprement, il n'y a qu'a faire le code pour vérifier si les champs References ou In-Reply-To pointent sur un de ces mails. Alors pour ça (en procmail) :

# Checker si References et In-Reply-To pointent sur un message-ID connu
REF_OK=no
REFERENCES="`formail -c -x References -x In-Reply-To: | tr -d '<>[:cntrl:]'`"
:0
* REFERENCES ?? @
* ? (echo $REFERENCES | fgrep -i -w -f /tmp/message-ID)
{ REF_OK=yes }

# Sinon, passer les anti-spams
# Ici juste un Spam-Assassin
:O E fw
| spamassassin

Je stocke dans une variable le fait que le nouveau mail ne passe pas le test, mais il faut dire que mon .procmailrc est assez complexe, avec pleins d'anti-spams et d'expériences de détection de spams dans tous les sens... D'ailleurs là j'ai simplifié pas mal l'appel aux anti-spams.

Si la votre base de données est triée (ce qui est le cas avec le script de la crontab), il est possible de se servir de cette propriété pour gagner un peu de temps CPU en faisant de la sorte (non testé):

formail -c -x References -x In-Reply-To | xargs printf "%s\n" | cut -f1 | sort -u | join Message-ID - | head -1

TODO : Faire ça proprement

Pour faire la reconnaissance et la sauvegarde des Message-ID recus personnellement, j'en ai déjà parlé, ça passerait par patcher formail (ou faire un utilitaire spécialement pour ça).
Mais là ou ça pourrait devenir intéressant, ce serait d'avoir un serveur de mail qui logue les Messages-IDs de tous les mails sortants (autrement dit s'occupe de créer la base de données), et permet a tout le monde de les utiliser (enfin, tant que le "tout le monde" n'est pas trop nombreux)... Du coup tous les mails sortants que l'on enverrait seraient inscrits dans la base, et comme ça, pas la peine d'appliquer avec ce qui va suivre.

A vos éditeurs de texte pour modifiez le code source de votre MTA préféré donc !!

Reconnaitre ses Message-IDs (ou ceux de ses amis).

Il y a plusieurs solutions pour reconnaitre ses Messages-IDs, dont entre autres :

• Vous demander à votre MTA de créer la base de données pour l'utiliser ensuite par ce dont je parle plus haut ! Bon, ben prenez son code source et votre éditeur de texte, et allez-y !!!
• Vous avez la possibilité de générer votre Message-ID personnalisé. C'est le cas de mutt notamment, en rajoutant un truc dans le genre dans votre .muttrc :

  send-hook . my_hdr Message-ID:`date "+>%Y%m%d%H%m%S.\`pwgen -1\`@sous-bock.ipv6.netlibre.info>"`

  Bien sûr, vous adapterez un peu pour avoir votre format personnalisé (pwgen, pour ceux qui connaissent pas c'est un générateur de mot de passe, ici utilisé pour rajouter de l'entropie).
  Et après ça, vous rajouterez les règles qui vont bien dans votre .procmailrc pour détecter vos Messages-IDs selon le format que vous aurez vous-même définis.
  Attention tout de même, certaines personnes se basent sur le format du Message-ID d'un mail pour faire de la détection de Spam. Ne pas utiliser le Message-ID par défaut du logiciel, peut éventuellement faire confondre avec du spam les mails que vous enverrez a vos amis qui font cette vérification. Mais c'est rare de voir ce genre de tests, en particulier avec mutt puisqu'il permet de modifier aisemment son Message-ID...
• Puisque le Message-ID finit toujours (enfin presque toujours) par le nom de la machine qui l'a générée, pourquoi ne pas regarder si la fin du Message-ID correspond a votre poste de travail ? C'est une très bonne idée, en effet, mais :
  • Si votre poste de travail est aussi la machine qui recoit les mails externes (autrement dit, MX pour votre domaine), alors c'est elle qui générera le Message-ID des Spams qui en sont dépourvus. En utilisant son nom. Donc ce sera pas exploitable.
  • Si vous envoyez des mails depuis plusieurs machines, il faudra alors vérifier avec les noms de toutes ces machines. En entreprise, vous pourriez faire de même pour toute les machines du réseau qui ne sont pas déclarés MX.
  • Evitez de mettre le nom de domaine dans la liste, car les spammeurs peuvent utiliser le nom de domaine de leurs cibles pour générer leurs Message-IDs.
  • Certains softs mals foutus pourraient ne pas fonctionner ainsi.. Ou alors être mal configurés. En fait il convient de regarder soit-même les messages-ID et tenter d'en déduire des similitudes qu'un spammeur pourrait ne pas utiliser et/ou distinguer.

Un Exemple (partez pas, vous allez encore apprendre des trucs)

Prenons le cas de l'Efrei (mon école).
Je regarde les Message-ID qui me parviennent de mes camarades pour commencer (Pour faire ça facilement, vous prenez mutt, vous rajoutez 'color header green default "^Message-ID:"' dans votre .muttrc, et les Message-ID seront mis en valeur. Puis vous appuyez sur 'h' pour voir les header, et z'aurez qu'a vous déplacer avec les touches habituelles pour faire ça très vite. Ou alors vous affichez carrement le Message-ID dans l'index des mails...). De là on constate que :

• Si c'est le serveur SMTP qui a rajouté le message-ID, il fini par "@smtp.efrei.fr". J'ai facilement trouvé ça parmis les spams ;-).
• Si ça provient d'un élève : quasimment tout le monde utilise mutt... A cause de sa (mauvaise ?) configuration les message-IDs qu'il génère sont tous de la forme "@efrei.fr". Un tel Message-ID est assez facile à forger pour un spammeur (mais ce sera pour dès qu'il sauront que de tels filtres existent quand même).
• Il n'y a pas grand monde a utiliser autre chose que mutt.
• Belmakor (une machine) semble être configurée proprement. Mais pas grand monde n'envoie de mail depuis celle-ci...
• La liste des machines est facile a récupérer (il y a le script "machines" spécifique a l'Efrei, mais trichons), il suffit de pinger le broadcast, ce qui donne (testé sur une des machines Linux) :

  #!/bin/bash
  
  BROADCAST=192.168.1.255
  
  for i in `ping -c 2 $BROADCAST | sed -n "s/64 bytes from \(192\.168\.[0-9]*\.[0-9]*\):.*$/\1/p" | sort -u` ; do
      host $i | sed -e "s/.*domain name pointer \(.*\)\./\1/";
  done;
  

  A part quelques machines particulières, c'est un bon début...

Maintenant on va mixer tout ça :

• Mettons tous les nom de machines dans le fichier "$HOME/Mail/.authorized_hosts", obtenu à l'aide du script de tout à l'heure. On y rajoute aussi les absents connus éventuels (choam.efrei.fr, belmakor.efrei.fr). Mais ne laissez pas de lignes vides dans ce script !!
  Dans le .procmailrc on met ça pour faire la vérification :

  #Choper les références connues
  REFERENCES="`formail -c -x References -x In-Reply-To: | tr -d '<>[:cntrl:]'`"
  REF_OK=no
  
  # Checker si References et In-Reply-To ont une machine connue !
  :0
  * REFERENCES ?? @
  * ? (echo $REFERENCES | fgrep -i -f $HOME/Mail/.authorized_hosts)
  { REF_OK=yes }
     

• On rajoute ça, pour détecter les mutt mal configurés, les spammeurs n'iront certainement pas utiliser un mail assez proche de cette expression régulière :

  
  # Checker les mutt de l'EFREI
  :0 EH
  * ^(Message-ID|In-Reply-To|References): 20.*[0-9]*\.G[A-Z][0-9]*@efrei\.fr
  { REF_OK=yes }
     

• Et voilà comment traiter les spams :

  :0
  * REF_OK ?? no
  {
  	#Lancement divers tests de spams
  	
  	#Poubellisation
  	:0:
  	* ^X-Spam-Level: \*\*\*\*\*\*\*\*\*\**
  	Spammeux
  }
     

• On sauvegarde les Messages-IDs (a mettre juste après la partie Spam, dès qu'on est sur qu'il ne s'agit pas d'un spam) :

  
  # si ce n'est pas un spam, sauver le message-id
  :0c :message-id.block
  | echo `formail -x Message-ID: | tr -d '<>[:cntrl:]' ` >> $MAILDIR/.message-id
     

• Normalement, ça marche !! Ceux qui sont a l'efrei seront heureux d'apprendre que mon fichier .procmailrc est lisible par tout le monde...

Remerciements

Les personnes suivantes m'ont aidés a améliorer cette page :

• Jean-Michel FAYARD, qui m'a apporté correction orthographiques et grammaticales (et j'en ai bien besoin).
• Salagir qui s'est encore amusé a me refaire le code HTML pour que ce soit plus propre
• Laurent Wacrenier pour sa contribution sur fr.comp.mail.

Je viens de constater à l'instant que chez certains FAI les Messages-IDs sont réécris (merci EVC!).