Fetchmail + SpamAssassin + Procmail

• 1. Introduction
• 2. Fetchmail
• 3. Procmail
• 4. SpamAssassin
• 5. Conclusion rapide

1. Introduction

Une des philosophies d'Unix est que chaque outil fasse qu'une et une seule chose, et qu'il le fasse bien, le système offrant alors des mécanismes de communication inter-outil permettant d'accomplir des fonctions plus complexes. D'ailleurs, le langage C, qui a été élaboré en vue de l'écriture du système Unix, s'acquitte très bien de cette tâche ; ses avantages et son efficacité disparaient avec l'augmentation en complexité de l'application à coder.

Un agent émail est un petit outil qui accomplit une tâche très précise dans un processus d'envoie ou de réception de courriels, conformément à la philosophie Unix. Une fois sa tâche accomplie, le courriel traité est passé à autre agent ; le tout forme une chaîne. Quitte à utiliser un système Unix, pourquoi ne pas mettre en oeuvre une telle chaîne dans le rapatriement de courriels pour l'ensemble des utilisateurs ? Une chaîne qui permettra de :

• récupérer les mails distants de plusieurs boites émail pour l'ensemble des utilisateurs,
• les passer à un anti-spam,
• les répartir dans différents dossiers selon des règles de filtrage propre à chaque utilisateur.

Les outils qui composent cette chaîne ont l'avantage indéniable d'être plus efficaces et flexibles que ne sauraient l'être un client mail tout-en-un. Leur désavantage principal reste que la configuration se fait par l'édition d'un fichier texte et non par une interface graphique ; ceci pouvant rebuter plus d'un.

Dans cet article, nous utiliserons le programme Fetchmail pour le rapatriement des courriels, SpamAssassin comme outil anti-spam, et Procmail pour leur filtrage.

Avec un tel processus, il n'est vraiment plus nécessaire de laisser ouvrir continuellement son client mail et nous pouvons même prendre le luxe d'en choisir un plus léger et qui soit efficace dans la lecture et l'écriture de courriels ; bref, un client qui soit tout simplement un MUA (Mail User Agent). L'avertissement de l'arrivé de nouveaux mails peuvent être laissés à la discrétion d'une appliquette dédiée. Finalement, nous pouvons ainsi économiser les ressources de la machine pour des choses plus utiles.

2. Fetchmail

Fetchmail est un programme qui a pour tâche de rapatrier les mails des utilisateurs et de les passer à un MDA (Mail Delivery Agent) afin que celui-ci les distribue dans la boite à mails des différents utilisateurs (généralement /var/spool/mail/<identifiant utilisateur>). Si vous disposez déjà d'un agent SMTP (Simple Mail Transfert Protocol) comme Exim ou Postfix pour l'envoie de mails, c'est, par défaut, à lui que Fetchmail communiquera via le port 25 les mails rapatriés. Toutefois, transférer les mails récupérés à un tel agent est consommatrice de ressources et, parce qu'il utilise une connexion TCP/IP sur le port 25, est un mécanisme lourd.

Dans notre chaîne d'agents mails, il est prévu d'utiliser les services d'un agent dédié au filtrage du courriel, Procmail. Or, ce dernier peut aussi être utilisé comme MDA en lieu et place du serveur SMTP ; ainsi, au lieu de passer par un tel serveur pour finalement être traités par Procmail, les courriels seront directement transférés par Fetchmail à ce programme. Il est donc nécessaire d'informer Fetchmail, via son fichier de configuration, de passer les courriels à Procmail.

Pour assurer son bon fonctionnement, Fetchmail utilise un fichier de configuration pour identifier les boites mails, avec leur identifiant et mot de passe, desquelles devront être récupérés tout le courrier. Pour chacune, un MDA différent peut être déclaré. Il existe deux manières de configurer l'agent Fetchmail :

• soit chaque utilisateur dispose de leur propre fichier de configuration, .fetchmailrc, sur leur compte personnel. C'est le comportement par défaut,
• soit un fichier de configuration global, /etc/fetchmailrc, centralise l'ensemble des configurations des utilisateurs. Il est nécessaire de spécifier au programme Fetchmail le chemin d'une tel fichier.

Dans le premier cas, le mot de passe de la boite à mails chez le FAI (Fournisseur d'Accès à Internet) n'est connu que par l'utilisateur. Toutefois cette solution a le désavantage que l'utilisateur ait à positionner correctement les droits sur le fichier (600) , à connaître la syntaxe de Fetchmail et à informer correctement ce dernier d'utiliser Procmail comme distributeur de courriels. Pour contourner ceci, l'administrateur pourra toujours proposer un squelette de fichier .fetchmailrc à l'utilisateur. Celui-ci n'aura plus qu'à remplir certains champs (mot de passe, serveur POP (Post Office Protocol) ou IMAP (Internet Message Access Protocol) du FAI, etc.)

Dans le second cas, la configuration, et donc le système de distribution des courriels des utilisateurs reste transparents pour eux. Il a le désavantage que l'administrateur a la connaissance des adresses ou des noms des serveurs des FAI de chaque utilisateur, ainsi que de leur mot de passe pour accéder aux boites mails de ces serveurs.

Ci-dessous, un exemple de fichier de configuration globale :

Par défaut, Fetchmail récupère seulement les mails qui n'ont pas été marqués comme lus par le serveur. Avec l'option fetchall, le programme récupère l'ensemble des mails disponibles dans la boite mail distante. Les autres options sont keep pour laisser les mails récupérés sur le serveur et nokeep pour forcer la suppression de l'ensemble des mails sur le serveur une fois rapatriés. Les options nokeep et fetchall peuvent être combinées.

L'instruction mda permet de spécifier un MDA en lieu et place d'une éventuel serveur SMTP. Celui qui est précisé est Procmail et nous donnons la ligne de commande à exécuter pour chaque mail rapatrié. La mise en oeuvre de Procmail est décrite dans la section suivante.

Comme la plupart des options de rapatriement des mails sont identiques entre les utilisateurs, le tout peut être rassemblé sur une ligne avec l'instruction default. Dans ce cas, toute déclaration d'option dans une instruction de récupération de mails surcharge celle par défaut.

Un petit mot sur l'option spambounce. Cette option n'est utile que dans le rapatriement des mails à partir d'un serveur IMAP. Si cette option est activée, alors pour chaque mail, Fetchmail vérifie dans l'entête la présence de drapeaux pouvant le marquer comme 'spam'. Ces drapeaux ont été éventuellement rajoutés par un outil anti-spam sur le serveur IMAP. Si un tel mail est identifié, alors il n'est pas récupéré, économisant ainsi de la bande passante, et une réponse est renvoyé à l'expéditeur comme quoi son mail est refusé. Cette option a été désactivée dans notre cas puisque nous allons mettre en oeuvre notre propre outil anti-spam.

3. Procmail

Procmail est un outil puissant qui a pour tâche de filtrer les mails entrants selon des règles précises définies par l'utilisateur. Ces règles permettent de répartir les mails dans des dossiers différents selon des critères précis, d'en supprimer certains, de les transférer vers une adresse mail ou encore de les passer à un programme (comme SpamAssassin par exemple). Les règles de filtrage sont définies dans un fichier le configuration .procmailrc sur le compte de l'utilisateur. Toutefois, il faut bien faire attention à correctement écrire ces règles sous peine de perdre des mails ! Si ce fichier utilisateur n'est pas défini, Procmail utilise alors en dernier ressort le fichier /etc/procmail qui est commun à tout le monde. Ce dernier cas est évidemment à éviter.

Procmail peut-être appelé soit par le serveur SMTP, soit directement par fetchmail. Dans le premier cas, il suffit d'écrire un fichier .forward qui est utilisé par tout outil SMTP pour transférer un courriel entrant vers une destination donnée, une adresse émail ou un programme comme Procmail par exemple. Voici un exemple de fichier .forward :

Un tel fichier n'est pas nécessaire avec fetchmail si celui-ci appelle Procmail directement pour chaque mail entrant (voir la section précédente).

Dans ce qui suit est présenté quelques règles usuelles pour filtrer les mails entrants avec Procmail. Elles font usage d'expressions régulières et il est donc nécessaire d'acquérir un minimum de connaissances dans ce domaine ; d'autant plus que les expressions régulières sont monnaies courantes dans le monde Unix.

Le fichier .procmailrc est composé d'une suite d'assignation de variables et de règles de filtrage.

Les variables permettent de donner à Procmail diverses informations utiles tel que par exemple le répertoire où doivent être stocké les mails ou encore la boite à mail à utiliser en dernier ressort lorsque Procmail n'arrive pas à délivrer un courriel. L'exemple ci-dessous illustre l'utilisation des variables les plus communes :

Les règles de filtrage sont traitées par Procmail dans l'ordre d'apparition dans le fichier. Elles peuvent être de deux types distinctes :

• les règles de livraison qui sont toutes des règles qui «livrent» l'entête et/ou le corps d'un mail dans un fichier, en entrée d'un programme ou à une adresse mail,
• toutes les autres règles qui soit sont utilisées à la sortie d'un programme ou d'un filtre afin d'être exploitées par procmail, soit comportent des blocs de règles imbriquées.

Quelque soit son type, une règle est toujours découpée en trois parties :

1. un annonceur d'une règle (toujours :0) suivi éventuellement de propriétés et d'un indicateur de vérrou,
2. des expressions régulières sur l'entête ou le corps du courriel qui permettent de sélectionner le type de mails à filtrer,
3. une action à effectuer sur le courriel filtré.

telle que définie par le schéma suivant :

Les propriétés sont exprimées par des symboles dont voici les plus usitées :

• H
  Les expressions s'appliquent sur l'entête du mail (comportement par défaut).
• B
  Les expressions s'appliquent sur le corps du mail.
• D
  La casse est prise en compte dans la résolution des expressions (par défaut, non sensible à la casse).
• E
  La règle ne sera appliquée que si l'action de la règle précédente (donc au-dessus) n'a pas été exécutée.
• e
  La règle n'est appliquée que si l'exécution de l'action de la règle précédente (donc au-dessus) a échouée.
• h
  L'entête du mail est envoyé dans un tube IPC (pipe), vers une adresse mail ou dans un fichier.
• b
  Le corps du mail est envoyé dans un tube IPC, vers une adresse mail ou dans un fichier.
• c
  Une copie carbonne du mail est effectuée. Ceci est principalement utile dans les règles d'envoie de mails.
• W
  La fin d'exécution du programme utilisé dans l'action est attendu et son code de retour est vérifié. Pour un code d'erreur, le texte ne sera alors pas filtrer et un message d'erreur est affiché.
• w
  Idem que précédemment mais sans le message d'erreur.

La présence d'un double-point à la suite des propriétés indique à procmail de vérrouiller, pour cette règle, l'utilisation de la ressource (par exemple un fichier) utilisée dans l'action. En effet, une même action peut être appliquée simultanément sur plusieurs mails et il est donc nécessaire de protéger la ressource d'une écriture simultanée. Un nom de vérrou (le nom de fichier qui servira de vérrou) peut être précisé à la suite du double-point. Je recommande fortement d'utiliser le vérrouillage dès qu'il s'agit d'une règle de livraison.

Les expressions régulières dans une règle sont toujours précédées par une étoile «*» qui est un marqueur de condition. Les expressions régulières définissent le filtre proprement dit et tout mail qui respecte la condition du filtre est alors traité par l'action de la règle.

Avec les expressions, des conditionnelles peuvent être associées :

• ! pour inverser la condition,
• $ pour évaluer le reste de la condition selon les règles de substitution du shell sh,
• < pour vérifier que la longueur totale du mail est plus petite que le nombre d'octet spécifié,
• > pour vérifier que la longueur totale du mail est plus grande que le nombre d'octet spécifié,
• etc.

Voici ci-dessous quelques règles :

Ce sont les règles les plus courantes qui sont présentées et peuvent servir de point de départ pour en élaborer de plus compliqué.

4. SpamAssasin

SpamAssassin est un outil Perl écrit par la fondation Apache pour détecter des spams éventuels en utilisant un ensemble d'heuristiques sur les entêtes et le corps des mails entrants, des listes blanches automatiques, des listes noires, des catalogues de spams, etc.

SpamAssassin fournit deux programmes pour détecter un spam :

• le couple spamd/spamc : le premier est un serveur (programme réseau tournant en arrière plan) à l'écoute de mails entrants à filtrer tandis que le second est un client qui envoie le mail à traiter au serveur et lui retourne le résultat. Ce couple permet d'éviter l'exécution de SpamAssassin à chaque émail entrant,
• spamassassin qui est appelé explicitement ou par un outil externe pour traiter un courriel entrant.

A chaque mail entrant, SpamAssassin applique un certain nombre de tests afin d'y mesurer son degrès d'indésirabilité. A chacun des tests est associé un certain nombre de points ; cette association est définie dans le fichier /usr/share/spamassassin/50_scores.cf. Lorsqu'un test réussi, le nombre de points associé est ajouté au total du mail. C'est ce total qui définit au mail son degrès d'indésirabilité : au dessus de 5 points (limite par défaut), le mail est marqué comme spam.

La personnalisation de SpamAssassin peut être réalisé de façon globale avec le fichier /etc/spamassassin/local.cf ou au niveau utilisateur avec le fichier $HOME/.spamassassin/user_prefs. C'est par exemple dans ces fichiers de configuration qu'est défini le score à partir duquel un mail est considéré comme étant un spam. Ces fichiers de configurations valorisent un certain nombre de paramètres qui sont utilisés par l'ensemble de la configuration de SpamAssassin dans /usr/share/spamassassin/ ; la plupart des paramètres ont des valeurs par défaut. Par exemple, la classification bayesien est activé par défaut avec l'auto-apprentissage.

Sauf exception particulière, la configuration par défaut de SpamAssassin suffit à elle seule et ne nécessite pas de modification. Et si une modification est toutefois nécessaire, il est plus opportun de l'appliquer au niveau utilisateur. Dans ce cas, il vaut mieux se tourner vers la documentation du programme.

Avec les progrès des spammeurs à rendre indétectable leurs spams, les outils anti-spam ne suffisent plus généralement à eux seuls. C'est pourquoi l'usage de listes blanches, de listes noires et de catalogues de spams sont un support indéniable dans le combat contre les pourriels. Les listes blanches contiennent les adresses des expéditeurs de courriers valides (les hams) tandis que les listes noires contiennent les adresses des expéditeurs indésirables. Quant aux catalogues de spams, ils répértorient tous les types de spams existants ... ils sont donc condamnés à grossir en volume ! Il est indéniable que les listes blanches ont un impact plus important que celles noires dans la détéction anti-spam. En effet, les spams sont souvent envoyés à partir de fausses adresses ou d'adresses emails spoliées.

Pour répertorier les adresses des expéditeurs valides, il suffit de valoriser dans son fichier $HOME/.spamassassin/user_prefs ou dans /etc/spamassassin/local.cf la variable whitelist_from avec un filtre d'adresse :

Mais il existe aussi des commandes qui permettent de mettre à jour dynamiquement les adresses des expéditeurs valides et ceux indésirables :

ou encore :

A la réception des mails, nous pouvons donc aider SpamAssassin à améliorer sa détection de spams en lui «apprenant» les mails qui sont indésirables et ceux qui ne le sont pas. La commande sa-learn alimente SpamAssassin de données qu'il enregistre et qui ensuite sont utilisées dans sa détection de spam. Voici quelques arguments de la commange sa-learn :

• --spam
  Apprends comme indésirable.
• --ham
  Apprends comme désirable.
• --sync
  Synchronise la base de données.
• --no-sync
  Ne pas synchroniser la base de données après un apprentissage.
• --mbox
  Le mail est au format mbox.
• --mbx
  Le mail est au format mbx.
• --showdots
  Indique la progression de l'apprentissage avec des points.
• --progress
  Indique la progression de l'apprentissage avec une barre de progression.
• --backup
  Sauvegarde la base de données sur la sortie standard (donc ne pas oublier de rediriger vers un fichier).
• --restore
  Restaurer la base de données à partir d'une sauvegarde antérieure.

Par défaut, sa-learn interprête les courriels d'entrée comme étant au format MAILDIR. Donc, avec des formats mbox ou mbx, ne pas oublier de le spécifier.

Pour améliorer la détection des spams, SpamAssassin peut-être couplé avec des sites de base de données de spams connues (les catalogues de spams), les plus connus étant Razor (http://razor.sourceforge.net/) et Pyzor (http://pyzor.sourceforge.net/). Razor offre un accès aux bases de données de la société commerciale Cloudmark aux clients Unix, tandis que Pyzor est une base de données libre. Tous deux sont des systèmes de Hash-Sharing : le principe repose sur la participation des utilisateurs qui recoivent des spams par la mise à jour des bases de données avec le checksum des spams reçus ; évidemment, ceci se fait automatiquement via des outils dédiés et fournis par Razor et Pyzor. Avec Razor, il est toutefois nécessaire de s'enregistrer auprès du site avant de l'utiliser.

Pour activer le support de ces bases de données de spams, il suffit de positionner les variables suivantes dans le fichier de configuration v310.pre ou v320.pre selon la version de SpamAssassin (dans /etc/mail/spamassassin/ ou /etc/spamassassin/) :

Puis, dans le fichier de configuration local.cf de SpamAssassin, vérifiez que les lignes suivantes sont présentes :

Le fichier razor-agent.conf est créé lors de l'initialisation de Razor. Le répertoire razor/ contiendra aussi tout un tas de données qui auront été générées par Razor lui-même. Pour initialiser Razor, il est nécessaire de s'enregistrer d'abord auprès de lui, puis de créer le fichier ci-dessus avant de lancer la découverte des différentes bases de données de spams :

(Vérifiez les permissions d'accès au répertoire razor.) Vérifiez que la variable razorhome dans le fichier de configuration razor-agent.conf est correctement valorisée :

Pour alimenter les bases de données accessibles via Razor, il suffit alors d'utiliser la commande :

Cette commande peut-être configurée dans le client mail utilisé et lancée via un racourcis clavier.

Pour Pyzor, la configuration est plus simple. Il suffit d'abord de renseigner le fichier local.cf avec l'instruction suivante :

par exemple, puis de demander à Pyzor d'indiquer la bases de données de spams que doit questionner et populer SpamAssassin :

Un fichier server est alors créé dans le répertoire maison de Pyzor avec l'adresse de la base de données.

De même qu'avec Razor, on peut alimenter en spams la base de données de Pyzor via la même commande :

Mais Pyzor fournit aussi une commande dédiée pour ceci :

Pour accentuer l'efficacité de détection de spams par SpamAssassin, vous pouvez aussi préciser les langues par défaut des mails que vous recevez habituellement. Les autres mails se verront alors attribués un score plus élevé. Ceci se fait toujours dans le fichier local.cf avec les instructions ok_languages et ok_locales :

L'instruction ok_locales ci-dessus indique que vous ne recevez que des mails dans les locales occidentales (donc pas de mails en japonais ou chinois).

Maintenant, si vous utilisez SpamAssassin comme un service tournant en arrière-plan (un démon dans le jargon Unix), il suffit de relancer celui-ci pour que vos modifications soient prises en compte :

SpamAssassin peut-être utilisé de deux façons différentes : soit en exécutant explicitement la commande spamassassin, qui alors traite le mail passé en argument, soit en exécutant le démon spamd qui alors est en attente de mails entrants de la part du client spamc. Ces commandes peuvent être configurer dans votre client mail, toutefois, pour rester dans le sujet de cet article, ce sera Procmail qui exécutera la détéction anti-spam pour chaque mail entrant. L'utilisation de la commande spamassassin peut-être lourde lorsqu'il s'agit de traiter un certain nombre de mails (surtoût lorsque les mails de plusieurs utilisateurs doivent être vérifiés !), aussi le démon spamd est ici préféré. Nous utilisons donc spamc pour lancer la détéction anti-spam. Pour ce faire, il suffit de rajouter cette règle comme toute première règle dans son fichier .procmail afin que SpamAssassin puisse traiter les mails avant tout autre filtrage potentiel :

La seconde ligne spécifie que seuls les courriels de taille inférieur à 256Ko (250 * 1024 = 256000 octets) seront traités par SpamAssassin ; en effet la majorité des spam ne sont pas plus gros que quelques kilo-octets et vérifier de très gros mails peut mettre à mal SpamAssassin.

Puis, une fois le mail vérifié, il est alors nécessaire de traiter le spam éventuel avec une autre règles de filtrage Procmail. Cette dernière doit-être en seconde ligne afin d'éviter que les autres règles puissent s'appliquer sur le spam éventuel (en effet, Procmail traite les règles dans leur ordre d'apparition) :

Ceci supprime les spams une fois pour toute. Pour les garder dans une boite à mails dédiées (spam par exemple), il faut alors préférer cette règle :

5. Conclusion rapide

Voilà, maintenant toute votre chaîne de réception de courriels est prêt et ceci pour l'ensemble des utilisateurs de votre machine ou de votre petit réseau local. Et ceci de façon transparente pour les utilisateurs, si ce n'est les règles de filtrage Procmail qu'ils devront écrire (avec votre aide bien sûr ;-) ). Mais là, plus besoin d'activer l'anti-spam du client mail, et de s'embêter avec pour lui apprendre les spams ou les hams ; en général, avec SpamAssassin couplé avec Razor et Pyzor, l'efficacité de détection des spams est redoutable, d'autant plus si, avant son déploiement pour l'ensemble du système, vous avez lancé une campagne d'apprentissage des hams à SpamAssassins pour chacun des utilisateurs.