Page suivante Page précédente Table des matières 10. 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/lib/suck doit se trouver un fichier suckkillfile qui est le fichier de filtrage maître. Le mien contient les lignes suivantes (par discrétion, j'ai caché les noms des indélicats dont je ne souhaite pas récupérer les articles...). HILINES=10000 #LOWLINES=10 NRGRPS=7 From:aaaa@bbb.fr From:cccc@ddd.fr QUOTE=\ GROUP=delete fr.comp.os.linux.annonces suckkillfile.fcola 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 : Type mot-clé : HILINES, LOWLINES, QUOTE, GROUP : ils définissent un comportement « général » ; Type header : From, Subject, Path, ... (en fait, tout champ valide d'un en-tête d'article) : ils définissent un comportement « particulier ». 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.comp.os.linux.annonces, fr.usenet.logiciels et fr.comp.mail. Le premier est filtré selon les règles définies dans le fichier de filtrage suckkillfile.fcola et les deux autres selon les règles définies dans 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. Les entrées de type header décrites dans le fichier suckkillfile s'appliquent à tous les forums. Pour définir un comportement particulier pour un forum donné, on utilise une entrée GROUP. Mon fichier suckkillfile.fcola ne contient qu'une ligne : Path:fr\.howto Ce qui permet de filtrer les articles contenant fr.howto dans leur champ Path : cela me permet d'éviter la récupération des Howtos publiés mensuellement dans fcola... En fait, au départ, je me suis intéressé à suck (et donc à INN) pour cette seule raison ! Mon fichier suckkillfile.no_ms contient 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 (pas tous, malheureusement...). À 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@mail\.dotcom\.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 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, suck 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 un coup d'oeil à /tmp/suck.killlog 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 si vous avez configuré votre système pour qu'il vide /tmp à chaque redémarrage). Page suivante Page précédente Table des matières