14. Annexe 3 : Filtrage des articles avec suck

Suck permet de filtrer les articles qu'il récupérera sur le serveur distant. Il utilise, pour cela un mécanisme de «kill-files» (cf. suck(1)). Dans le répertoire /usr/local/etc/suck doit se trouver un fichier suckkillfile qui est le fichier de filtrage maître. Voici un exemple de contenu :

HILINES=10000
#LOWLINES=10
NRGRPS=7
From:aaaa@bbb.fr
From:cccc@ddd.fr
QUOTE=\
GROUP=delete fr.usenet.logiciels suckkillfile.no_ms
GROUP=delete fr.comp.mail suckkillfile.no_ms

Chaque entrée de ce fichier peut être de 2 types :

On notera que les entrées de type mot-clé ont la syntaxe mot_clé=paramètre(s) alors que les entrées de type header ont la syntaxe header:valeur (en tous cas, depuis la version 3.6.0).

Les champs HILINES et LOWLINES indiquent, respectivement, qu'il ne faut pas récupérer les articles ayant plus de lignes ou moins de lignes que celles spécifiées. Ici, Suck ne récupèrera pas les articles ayant plus de 10000 lignes. J'ai commenté l'entrée LOWLINES car certains auteurs (n'est-ce pas, Nat ?) envoient des articles parfois très courts (un simple lien, par exemple).

Le champ NRGRPS indique le nombre maximal de forums autorisé pour le postage multiple d'un article. C'est une première précaution pour éviter les «spams», car tout article posté dans de trop nombreux forums est suspect. Cette entrée n'apparaît qu'à partir de la version 3.8 de Suck. Attention à ne pas vouloir trop en faire : j'avais d'abord mis cette valeur à 5 et, par analyse du fichier /tmp/suck.killlog, je me suis aperçu que certains articles avaient été rejetés car, dans certains forums (notamment ceux traitant d'emacs), le cross-postage est une coutume... Je l'ai donc ramené à 7.

Le champ QUOTE permet de définir le caractère servant à quoter les caractères spéciaux dans les expressions régulières (cf. regexp(3)).

Le champ GROUP permet de définir un comportement pour un forum particulier : ce comportement est soit delete soit keep. Il s'applique au forum dont le nom suit, selon les règles de filtrage définies dans le fichier précisé. Ici, je filtre les articles des groupes fr.usenet.logiciels et fr.comp.mail. Tous les deux sont filtrés selon les règles définies dans le fichier de filtrage suckkillfile.no_ms.

Ici, le fichier suckkillfile ne contient que deux entrées de type header : elles servent à filtrer tous les articles dont le champ From: contient une des deux adresses spécifiées, quels que soient les forums dans lesquels ils ont été postés. Cela permet, notamment, d'éliminer les «trolleurs» ou les «spammers» déjà repérés (mais cela ne filtrera pas les réponses que certains pourraient leur faire).

Les entrées de type header décrites dans le fichier suckkillfile s'appliquent à tous les forums et, pour définir un comportement particulier pour un forum donné, on utilisera une entrée GROUP. Le fichier suckkillfile.no_ms pourrait ainsi contenir les lignes suivantes :

Subject:.*Eudora
Subject:.*Forte
Subject:.*Outlook
Subject:.*\>Ms
Subject:.*Pegasus
Subject:.*Gravity
ce qui permet de filtrer les articles dont le champ Subject: concerne des logiciels Microsoft.

À la place de delete, on peut indiquer keep, qui ne conservera que les articles correspondants aux critères fixés.

Une entrée de type :

GROUP=keep fr.* suckkeepfile.moi
et un fichier suckkeepfile.moi contenant simplement :
From:.*jaco@teaser\.fr
aurait le mérite de restreindre le nombre d'articles récupérés pour les forums de la hiérarchie fr, mais je n'apprendrais plus grand chose...

À chaque fois qu'il rejette un article, Suck l'indique dans le fichier /tmp/suck.killlog (ou /usr/local/etc/suck/suck.killlog en indiquant la raison de ce rejet. Par des options passées à Suck, vous pouvez paramétrer la taille de ces informations : par défaut, il utilise le format long. On peut le forcer à utiliser un format court, mais je le trouve peu explicite... On peut même le configurer pour qu'il ne crée pas ce fichier : ce serait une mauvaise idée, selon moi. Jetez toujours un coup d'oeil à ce fichier lorsque vous ajoutez un critère de filtrage afin de vous assurer que les effets obtenus sont bien ceux escomptés. En tout cas, pensez à vider ce fichier périodiquement car il a tendance à grossir assez vite (sauf s'il se trouve dans /tmp et que vous avez configuré votre système pour qu'il vide ce répertoire à chaque démarrage).

Comme nous l'avons évoqué plus haut, ce mécanisme de filtrage s'effectue en examinant le contenu des messages, ce qui induit nécessairement un temps de traitement supplémentaire. Les dernières versions de Suck permettent d'utiliser un fichier suckxover, plus rapide à traiter car n'utilisant pas le même mécanisme d'examen. Ce dernier type de filtrage ne dispose pas de toutes les fonctionnalités du précédent mais suffit dans la plupart des cas (cf. suck(1)).