On remet tout sur l'établi

Après mes plus ou moins bonnes idées et tests qui m’ont conduit à laisser tomber la voie que j’avais prise pour développer ce petit outil d’aide à la décision, je reprends ici l’étude d’un nouveau filtre antispam basé sur la fréquence de publication (via contrôle de l’email, a minima) pour filtrer les « faux-positifs », qui dans mon cas concerne quelques uns de mes commentateurs qui se retrouvent de temps en temps marqués comme indésirables.

J’aimerais assez, de plus, ne pas casser le mécanisme actuel de l’antispam, ou tout au moins si ça s’avère impossible de le conserver en l’état d’assurer une compatibilité ascendante avec les filtres existants.

Par ailleurs, pas de nouvelle(s) table(s) dans le schéma de la base, il y a déjà tout ce qu’il faut, avec entre la table spamrule qui permet de stocker quelques informations utilisables par les filtres.

Donc je détaille l’idée :

  • À 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.

C’est tout pour le traitement à ce moment où le commentaire est soumis.

Ensuite, au moment où l’utilisateur filtre (à la main) ses spams, si un des emails enregistrés en liste grise est associé à un spam qu’on publie parce qu’il est un faux-positif, alors on supprime cet email de la liste grise. Les prochains commentaires avec cet email seront donc considérés comme bons.

Par ailleurs si au contraire un commentaire est marqué (à la main) comme spam, alors on enregistre l’email dans la liste grise.

Je ne suis pas certain de couvrir tous les cas, et il faudrait peut-être que je fasse un petit schéma pour y voir plus clair. D’autre part, il est probable qu’il faille placer ce filtre assez haut dans la liste, vu qu’il ne « coûte » pas très cher (une ou deux requêtes SQL, aucune requête HTTP).

Une remarque aussi, la longueur max d’un email est de 2083 caractères (comme toutes les URLs d’ailleurs), il faudra donc que je songe à utiliser une fonction de hachage pour stocker ça dans les 128 caractères max que me permet la table spamrule.

Vous en pensez quoi ?

Ajouter un commentaire

Les commentaires peuvent être formatés en utilisant une syntaxe wiki simplifiée.

Ajouter un rétrolien

URL de rétrolien : https://open-time.net/trackback/14012

Haut de page