Plus j’y réfléchis, plus je me dis que le comportement que j’ai décrit pour le futur plugin antispam basé sur une graylist
est un peu trop « bourrin ».
L’idée en elle-même est correcte, sauf que l’algorithme est trop basique, ou plutôt devrait être effectué en deux passes.
Je reprends le détail de ce que je comptais faire :
- À la soumission d’un commentaire — les rétroliens ne seront pas gérés par ce filtre pour cause d’absence d’email dans leur métadonnées —, vérifier si l’email du commentateur a déjà été utilisé et publié dans les commentaires précédents.
- Si l’email a déjà été utilisé et publié on peut considérer que c’est a priori pas un spam et répondre que tout va bien.
- Sinon on vérifie si l’email est dans la liste grise (stockée dans la table spamrule), et si il est présent on répond que le commentaire est un spam.
- Sinon, on enregistre l’email dans la liste grise, et on passe au filtre suivant — donc pas de décision pour l’instant.
En fait, il serait opportun de placer un filtre s’occupant des deux premières étapes en haut de la liste des filtres, et par contre mettre la suite — étapes 3 et 4 — plutôt plus bas, pour laisser « travailler » les filtres qui s’occupent de l’email (Akismet, Defensio, Stop Forum Spam, …) avant de reprendre la main si besoin.
Sachant que la « sortie » d’un mail enregistré dans la liste grise se fera de toute façon dès que l’administrateur sortira le commentaire faussement marqué comme spam de la liste des spams.
Donc ce sont deux filtres qu’il me faut et pas un seul.
Ça vous parait pertinent ?
Après réflexion, comme quoi ça aide de se relire, il faudrait peut-être que je garde la 4e étape dans le 1er filtre et que je ne laisse que la 3e dans le second.
1 De saymonz -
Ce que tu décrit me paraît bien compliqué.
Sous WordPress, une option présente par défaut permet de valider automatiquement les commentaires d’auteurs connus (par adresse mail d’après la doc) et de passer tous les autres par la case modération.
C’est clair et simple. Un autre antispam peut éventuellement déclarer le commentaire comme spam par dessus.
Ce fonctionnement me paraît tout à fait pertinent. Ainsi, il ne s’agit pas de répondre “spam ou non” mais “modération ou non”, ce qui fait qu’en faire un filtre antispam dans Dotclear n’est peut-être pas la bonne solution ?
2 De Franck -
L’un n’empêche pas l’autre, à savoir qu’on peut tout à fait faire de la validation automatique d’un commentateur connu avec ce que j’appelle mon premier filtre. Ce 1er filtre, s’il ne (re)connait pas l’email passant alors le relais aux filtres suivants…
Je pourrais effectivement prévoir une option qui n’utiliserait pas la liste grise et donc désactiver le second filtre dont je parle.
Quoi qu’il en soit c’est pas encore bien « mûr » dans ma tête, compte-tenu des spécificités du fonctionnement de l’antispam de Dotclear.
3 De Bernard -
Je me demande si les étapes 3 et 4, ne peuvent pas être “regroupées”, au moins dans leur actions.
En effet, pour “enregistrer l’email dans la liste grise” on doit aussi au préalable “vérifier si l’email est dans la liste grise”, non ?
Et si l’email est enregistré dans la liste (4), il existe donc dans cette liste(3)…
Après, certes, cela signifie qu’une valeur ‘existe/ou pas’ dans la liste soit transmise du 1er filtre au second. Mais chais pô si c’est possible…
4 De Bernard -
Ceci dit il existe, sous Dc, une option de modération des commentaires par défaut.
Du coup, je me demande si cette option ne pourrait pas être aussi complétée/modifiée par une action, comme proposée “modération”, en -> modérer - sauf si l’emel est dans la “liste grise” ?
Ce qui signifierait, amha, une présentation de la liste des commentaires à modérer en deux parties: liste grise/pas dans la liste.
5 De saymonz -
En fait je ne comprend pas la nécessité d’avoir ce que tu appelles une “liste grise”. Quel besoin de créer une base de données pour stocker ce qui ne sera ni plus ni moins que “toute adresse email n’ayant pas déjà un commentaire approuvé” ?
Après soit on considère que l’adresse mail est un élément suffisamment fiable (faible risque de collision avec celles utilisées par les bots de spam) et on permet à cette seule vérification de bypasser le reste de l’antispam, soit non. Je n’ai pas d’avis sur la question.
Avec un système d’antispam à scores comme on en avait discuté, ça permettrait de moduler mais en l’absence la solution la plus pragmatique c’est de proposer un switch dans les paramètres permettant de :
Ça doit être très facile à intégrer dans Dotclear, si le système d’antispam évolue à l’avenir on pourra en faire un critère pris en compte dans le “spaminess”.
Ou alors j’ai pas compris.
6 De saymonz -
J’ai relu ton billet précédent, en fait la “liste grise” n’est ni plus ni moins qu’une liste d’adresses email interdites car considérées comme spam ?
Je ne comprends pas l’algorithme que tu décris, tu dis vérifier la présence de l’email dans ta liste grise mais l’y ajoute de toute façon ? Où ne l’y ajoute que si un autre filtre tire l’alarme ?
7 De Franck -
Yep, tout ça est mal ficelé, va falloir que je reprenne depuis le début.
Merci pour vos réflexions !
8 De Bernard -
Je viens de regarder la table dc_comment :
Cette table contient aussi le nom de l’auteur, son emel, l’IP et même trackback, etc.
Amha, rien qu’avec cette table, il y aurait de quoi “tester”, non ?
9 De Franck -
En fait l’idée de départ est d’éviter qu’un mail déjà utilisé soit marqué comme SPAM à tort.
Je vais peut-être me limiter à ça et voir ensuite comment ça se comporte…
10 De Franck -
Sinon faudrait que je cherche de la doc sur les systèmes de scoring des antispams.
11 De saymonz -
Donc il suffit de créer un filtre qui décrète le non-spam (false) si l’email est associé à au moins un commentaire publié ou passer au suivant (null) sinon ? Pas besoin de créer une liste d’adresses en plus ?
12 De Franck -
Yup !