Forums d'entraide informatique - Astuces - Conseils

Filtrer les mails avec
Exim
Quelle que soit l'utilisation de votre ou vos adresse(s) email, il est parfois utile de procéder à un tri automatique (voire à des épurations massives) des messages afin que vous et vos utilisateurs n'ayez pas à le faire manuellement. Ce filtrage est habituellement fait par l'intermédiaire de procmail qui permet de délivrer les messages dans différentes boîtes en fonction de divers critères. Mais ce travail peut être fait par le MTA (Mail Transfer Agent). L'avantage du filtrage par le MTA est évident. Vous n'avez pas à installer de programmes supplémentaires et surtout, en tant qu'administrateur du serveur SMTP, vous pouvez contrôler le contenu de chaque message. Lorsqu'il s'agit d'une installation réseau regroupant des systèmes divers, le filtrage de la part des postes clients devient rapidement difficile à gérer. Il vous faut connaître chaque système et les configurer en conséquence. Sachant que certains de ces systèmes sont particulièrement fragilisés en raison du MUA utilisé, mieux vaut faire le ménage le plus tôt possible, et donc dès la réception des messages.
Pourquoi filtrer les mails ?
Il existe plusieurs raisons légitimes parmi lesquelles on pourrait citer :
•    Limiter les risques de contamination concernant les plateformes ayant des défenses faibles ou inexistantes. Entendez par-là tous les risques liés à la réception et surtout l'exécution de scripts sous la forme de fichier VBScript ou de macros pour des applications résidentes sur des systèmes faibles. Bien sûr, les pièces jointes au format binaire exécutable entrent également dans cette catégorie et ce, pour toutes les plateformes, y compris GNU/Linux.
•    Limiter les risques de saturation des systèmes de fichiers. En effet, si l'espace disque de la machine où résident les boîtes email est physiquement limité, il est préférable de refuser les messages d'un trop grand volume. Cela entre dans les fonctionnalités offertes par le filtrage de messages.
•    La nécessité de signaler l'état d'un correspondant. On peut par exemple filtrer les messages à destination d'un utilisateur de notre système et, en cas d'absence de la personne, opter pour un comportement spécifique.
•    Le catalogage, le tri et la classification des messages. On imagine facilement ce genre de système
sur une boîte commune, comme par exemple le service à la clientèle. En fonction de mots clefs prédéfinis figurant dans le corps ou l'en-tête du message, nous pouvons replacer les messages dans les comptes spécifiques ou les rediriger vers des destinataires aptes à répondre au mieux aux messages en question. La manière la plus courante de procéder pour ce genre de chose est d'utiliser procmail, mais les MTA sont parfaitement capables d'en faire autant.
•    La surveillance de la correspondance. Il est en effet possible de faire n'importe quoi avec des filtres d'un MTA. Ceci inclut des pratiques illégales dans certaines mesures ou certaines conditions. Vous pouvez par exemple dupliquer un message arrivant ou sortant du serveur SMTP et rediriger la copie vers un autre destinataire pour analyse ou archivage. Attention, dans le cas d'une entreprise, veillez à respecter la législation de votre pays en ce qui concerne le respect de l'intimité des correspondants sur le lieu de travail.
•    Le respect des standards. Vous pouvez, à l'aide d'un filtre, sélectionner les messages entrants et sortants afin d'en vérifier la syntaxe et le formatage. Je pense par exemple aux clients mail qui ont la fâcheuse tendance d'utiliser le HTML comme s'il s'agissait d'un standard. Une fois le message repéré, vous pourrez opter pour le comportement qui vousconvient comme la redirection vers un autre comp- te, la suppression ou encore la correction du problè- me à l'aide d'un utilitaire. C'est également dans cette catégorie de filtres que nous avons choisi de placer les modifications systématiques des messages sortants. Il est ainsi possible de concevoir un systè- me qui ajoutera une signature à chaque message sans que l'utilisateur n'ait besoin de configurer son client mail pour le faire.
Quelle que soit la raison pour laquelle vous désirez filtrer vos mails ou les mails des utilisateurs de votre réseau, les fonctionnalités offertes par exim pour- ront vous satisfaire. Ce MTA possède en effet des fonctionnalités intégrées de filtrage avancés qui vous permettront sans doute de vous passer d'un utilitaire supplémentaire.
Exim
La totalité des MTA permettent aux utilisateurs d'avoir recours à un fichier spécifique de leur réper- toire personnel . f orward) leur permettant de procéder au traitement de leurs emails. Il s'agit là en quelque sorte d'un filtrage disponible pour chaque utilisateur, étant donné que par l'intermé- diaire de ce fichier, il est possible d'utiliser des utili- taires de tri et de filtrage.
Exim permet d'étendre et de déplacer vers l'admi- nistrateur les fonctionnalités de filtrage. Ceci a pour avantage de centraliser la gestion du filtrage dans un seul et même fichier. Ceci n'enlève en rien la pos- sibilité aux utilisateurs de faire usage du . forward, mais les règles de filtrage d'exim s'appliqueront avant toute chose. Il est également important de préciser que chaque utilisateur peut, dans son . forward définir des règles de filtrage d'exim.
Nous l'avons déjà dit, les règles de filtrage sont pla- cées dans un fichier séparé. Celui-ci doit IMPERA- TIVEMENT débuter la une ligne suivante. C'est également valable pour le . f orward de chaque uti- lisateur souhaitant utiliser les règles de filtrage d'exim :
# Exim filter
Ce fichier sera ensuite référencé dans le fichier de configuration principal d'exim avec la directive : message_filter    /chemin/fichier_des_filtres
Note : N'ajoutez pas cette ligne dans le fichier de configuration d'un serveur SMTP en production (en cours de fonctionnement). En effet, à chaque transaction, ce fichier sera parcouru dans le but d'appliquer les règles de filtrage. Si vous sauvegar- dez un fichier comportant des erreurs de syntaxe ou de mauvaises définitions de filtres, vous irez au- devant de gros problèmes. Nous verrons plus loin comment tester les filtres avant de les appliquer à l'ensemble des messages.
Syntaxe du fichier
Les règles de filtrage sont définies dans le fichier que vous allez désigner sous la forme de conditions if.  Voici un premier exemple simple :
# Exim filter
if $message_body contains «.vbs» and flot error_message
then
logfile /var/log/exim/exim_filterlog logwrite "Stod_log Message de $sender_address correspond au filtre !"
finish
endif
Ce filtre est sans doute le premier qui vous sera réellement utile si vous administrez un réseau com- prenant des machines Windows. Il permet en effet de détecter la présence de la chaîne de caractères «.vbs» dans le corps des messages. La condition porte donc sur un objet $message_body qui est le corps du message. Nous testons s'il contient (contains) la chaîne recherchée et ajoutons (and) dans la condition qu'il ne doit pas s'agir d'un mes- sage d'erreur (flot error_mes sage).
Suite à la condition i f, nous commençons la por- tée avec la directive then, puis nous détaillons la manière de réagir si la condition est vérifiée. Ici. nous nous contenterons de notifier la vérification de la condition dans un fichier journal. Nous spécifions donc le fichier en question avec logf il e et ■ écrivons l'information avec logwrite.
Note : Prenez garde aux permissions sur les fichiers lorsque vous utilisez la directive locf-_, L'exemple donné ici est destiné à être placé dans le fichier de définition des filtres globaux. exim possède les permissions nécessaires pour l'écriture dans /var/log, ce qui n'est pas le cas des utilisateurs

simplement qu'il contenait un fichier joint utilisant l'extension «.vbs». Par cette ligne de commande, exim traitera le mail contenu dans message_test et appliquera les filtres définis dans . forward. test. Il teste alors les conditions que nous avons spécifiées (trois premières lignes en gras). Les conditions sont ici vérifiées et les actions définies dans le fichier de filtres sont appliquées. Nous trouverons dans le fichier exim_f i 1 t er 1 og la ligne suivante :
2002-02-05 10:08:01 Message de denis@egon correspond au filtre !
Les deux dernières lignes de la sortie du test du filtre sont importantes. exim nous signale que le filtre ne définit pas d'action qui influe sur le routage du message (Filtering did not set up a significant
delivery) et que le mail en question sera traité normalement (Normal delivery will occur).
Notez qu'il existe deux variantes, l'option -bf qui s'applique aux tests de filtre d'utilisateur (ceux qui figureront dans le . forward) et -bF pour les filtres système s'appliquant à l'ensemble des messages. Ceci est important dans le sens où certaines variables (comme $recipicents) ne sont disponibles qu'avec les filtres systèmes.
Dans le cas d'un message ne vérifiant pas les conditions de filtrage, le test nous le signalerait avec les lignes suivantes :
Testing Exim filter file .forward
Sub-condition is false: $message_body contains .vbs
Condition is false: $message_body contains .vbs and not error_message
Rôle des filtres sur le routage
Le bref test que nous venons d'effectuer nous permet de voir un point important dans la rédaction de filtres exim. Certaines actions peuvent être considérées comme un routage de mail. En d'autres termes, les significant deliveries impliquent qu'exim ne continuera pas le traitement normal du message. Nous venons de le voir avec le précédent filtre. la notification dans un journal d'activité n'est pas un significant delivery. Ce n'est pas le cas pour toutes les directives définissant des actions dans les règles de filtrage. Selon Faction définie, un message peut être considéré ou non comme traité. Les actions suivantes n'influencent pas le traitement normal des mails après le filtrage :
•    add qui permet d'incrémenter un compteur
•    logf ile qui définit un fichier log ;
•    logwrite qui ajoute une ou plusieurs ligne(s) au log ;
•    mail qui permet l'envoi d'une réponse automatique ;
•    finish qui signale la fin du traitement de filtrage.
En revanche. celles-ci sont considérées comme étant un traitement de mail et aucun autre routage ne sera effectué par le système de traitement des messages :

•    deliver qui permet de «forwarder» le mail à une autre adresse
•    save qui permet d'enregistrer/ajouter le message dans un fichier passé en paramètre:
•    pipe qui permet de «tuyauter» le message vers un script ou une application quelconque pour un trai- tement plus complexe.
Bien sûr, tout cela n'est pas rigide et vous pouvez utiliser une directive d'action significative tout en laissant la main à exim pour la suite des opération. Il est donc possible d'utiliser deliver, save ou pipe sans interrompre le processus normal de livraison/routage. Voyons un exemple concret en réutilisant le message précédent. Soit le filtre
# Exim filter
if $message_body contains ".vbs" and flot error_message
then
deliver «denis <demis>"
endif
Vérifions immédiatement le comportement d'exim:
moi@egon:-$ /usr/sbin/exim -v -bf .forward.test2 < message_test
Sender from "From" line: lefinnois@monsite.com Testing Exim filter file .forward.test2 Sub-condition is true: $message_body contains .vbs Sub-condition is true: flot error message
Condition is true: Smessage_body contains .vbs and flot error message
Deliver message to: denis@egon
Filter processing endea:
Filtering set up at least one significant delivery or other action.
No other deliveries will occur.
Notre directive deliver fait effectivement son tra- vail et exim nous signale qu'il s'agit d'une action significative (deux dernières lignes). Si nous souhai- tons livrer une copie du message vérifiant les condi- tions à denis tout en laissant le système de routage faire son office normalement, nous devons modifier le filtre et ajouter une directive indiquant à exim que l'action deliver n'est pas significative
# Exim filter
if $message_body contains ".vbs" and flot error_message
then
unseen deliver "denis <denis>"
endif
Et le tour est joué
Condition is true: $message_body contains .vbs and flot error_message
Unseen deliver message to: denis@egon
Filter processing ended:
Filtering did flot set up a significànt delivery. Normal delivery will occur.
Autres sources de filtrage
Pour l'heure, nos deux exemples concernent le même critère : la présence d'une chaîne dans le corps du message. Pour mettre en oeuvre toutes les conditions de filtrage que nous avons exposées en début d'article, nous pouvons faire, bien sûr, usage de nombreuses autres sources d'information pour le filtrage. Il est possible de définir des conditions de test sur tous les éléments de l'en-tête d'un message en utilisant une variable composée de $header_ suivie du nom de la ligne dans l'en-tête. Ces noms de lignes correspondent à celles définies dans la R FC 822. On y trouvera, par exemple From, To,
Subject...
Il est ainsi possible de filtrer les messages en fonc- tion de chaînes présentes (contains) Ou non (does flot contains) dans différentes parties de l'en-tête. Voici un exemple de filtre vérifiant la présence de la chaîne «lefinnois» dans le champ From des mes- sages :
# Exim filter
if $header_From contains "lefinnois" then
logfile /home/moi/exim_filterlog logwrite "Stod_log Message de
$sender_address correspond au filtre !" finish
endif
Note : Attention, il s'agit bien d'une vérification portant sur une chaîne de caractères présente dans un champ de l'en-tête et non d'un nom d'utilisateur local.
Ce genre de filtre s'avère utile dans le cas où vous vous abonnez à différentes listes de diffusion et que

vous souhaitez placer les différents messages dans des boîtes différentes (avec la directive save) ou les rerouter vers d'autres comptes utilisateurs (avec deliver). Si le nombre de listes de diffusion est grand, le fichier de définition des filtres devient rapidement très gros et difficile à gérer. On utilisera alors un autre système pour procéder au tri. Nous créons dans un premier temps un fichier listes :
lefinnois@lefinnois.net: liste=oui boite=listel kkun@ailleur.com:    liste=oui    boite=liste2
kkundautre@site.com: liste=oui    boite=liste3
Nous pouvons ensuite composer un filtre en conséquence :
# Exim filter
if
${1ooku P{$sender_address:liste}lsearchf/home/moi/1 istel{$value}} is "oui"
then
logfile /home/moi/exim_filterlog
logwrite "Le message de $sender_address ira dans $11ookup{$sender_address:boite}lsearch{/home/moi/1 iste}{$value}1!"
endif
La condition de départ (if) recherche (lsearch) une ligne correspondant à l'adresse de l'expéditeur dans le fichier liste puis extrait la valeur associée à liste pour le test. Si la correspondance avec la chaîne «oui» est vérifiée, nous appliquons les actions prévues par le filtre. Nous faisons ici une simple notification dans un journal, mais il est clair qu'en temps normal nous utiliserions save ou deliver. Dans l'argument de la directive logwrite, nous réutilisons le fichier liste mais, cette fois, pour trouver et extraire la chaîne associée à boite. La sortie du test avec l'option -bf vous montre le résultat de l'expansion des variables :
moi@egon:-$ /usr/sbin/exim -v -bf .forward.test4 < message_test
Sender from "From" line: lefinnois@lefinnois.net Testing Exim filter file .forward.test4
Condition is true: ${1ookup{Ssender_address:liste}lsearch{/home/moi/1 iste}{$value}) is oui
Logfile /home/moi/exim_filterlog
Logwrite "Le message de lefinnois@lefinnois.net ira dans listen\n"
Filter processing ended:
Filtering did not set up a significant delivery.
Normal delivery will occur.
La directive lookup respecte ici la syntaxe suivante : ${1ookup{clef} type_de_recherche
(fichier){$value}}
Pour résumer, le filtre que nous venons de composer commence par faire une recherche de l'expéditeur dans le fichier liste. S'il trouve une correspondance, il vérifiera que nous considérons les messages de cet expéditeur comme provenant dune liste de diffusion. Enfin, nous faisons une nouvelle recherche dans le fichier pour connaître le nom de la boîte ou du destinataire à qui transférer le message. Il ne nous reste plus, ensuite, qu'à remplir le fichier liste avec les adresses d'expéditeurs. la mention informant qu'il faut les gérer comme des mails d'une liste de diffusion, et la boîte à utiliser pour l'archivage.
Informer l'expéditeur
Filtrer des messages conduit parfois à en refuser un certain nombre car ils comportent des éléments indésirables. Eliminer un message sans en informer l'expéditeur (et peut-être même le destinataire) provoque souvent davantage de problèmes que de solutions. L'expéditeur pourrait en effet s'obstiner dans ses tentatives et le destinataire, s'il est local, pourrait parfaitement «vous tomber dessus». vous reprochant de ne pas recevoir LE mail très important qu'il attend depuis des semaines (en cas de problème, le mail non reçu est toujours le plus important et le plus attendu).
Pour informer un expéditeur d'un problème lié au filtrage de son message, vous pouvez utiliser la directive mail. Cette directive permet de renvoyer un message à l'expéditeur ou à toute autre personne. Tous les éléments courants d'un message peuvent êtres utilisés (to, cc, bcc, from, subject, text, replay_to) sous la forme :
mail <option> valeur [<option> valeur]...
Ainsi, si nous refusons un message, nous pouvons, en informer l'expéditeur et par la même occasion l'administrateur système avec :
mail to $sender_address cc admin subject "Message refuse" text "Le message de $sender_address a ete refuse parce que...\n"

Attention, la directive mail n'est pas significative. De ce fait, si vous composez un filtre refusant les fichiers attachés considérés comme dangereux (fichier VBS, Word, EXE, etc.), la directive mail devra être précédée de seen afin que le destinataire ne reçoive jamais le message.
Un autre point important est le problème des boucles infinies. En principe. exim attache une grande importance à cela et tente d'éviter le problè- me en interne.
Cependant. si vous utilisez mail de manière incon- sidérée, vous pouvez provoquer une boucle infinie. Si le message envoyé par le filtre vérifie la condition du même filtre ou d'un autre, le message n'aura de cesse d'être transmis et copié.
Une autre solution pour informer un utilisateur consiste à faire usage de la directive fail pour signifier que sa demande a conduit à un échec dans le traitement des messages. Il n'est pas nécessaire alors de spécifier une adresse de retour puisque la directive le fera automatiquement. Vous pouvez néan- moins ajouter un message expliquant les raisons de l'erreur :
fail text "Votre message a    refuse parce
que...\n"
Les explications données ici devraient être suffi- santes pour vous permettre de filtrer efficacement vos messages. La meilleure source de documenta- tion sur les filtres et leur utilisation plus sélecti\ e (comme l'utilisation d'une base de données MySQL par exemple) reste la documentation officielle dis- ponible sur la homepage crexim