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 ?
1 De Bernard -
Premier test ?
D’après ce que j’ai lu, une adresse email se composerait de:
- nom expéditeur: 64 caractères max
- l’arobase
- nom de domaine: maximum 63
- et 3 sous-domaines: maximum 64 chacun, incluant les « . »
soit 64+63+(64*3)+1, soit 320 caractères…
Par ailleurs, un autre billet semble expliquer qu’ “une étude mixant les résultats de plusieurs base de données démontre que cette moyenne s’élève à 23. ” caractères, et qu’on ne devrait pas “tomber sur des adresses emails de plus de 55 caractères”
Amha, déjà le nom de l’auteur (64) + le nom de domaine (63) pourrait être un “filtre” suffisant, même si cela demande une comparaison moins simple qu’une vérification “d’égalité” d’adresse complète ?
note:
- si j’ai bien compris le “type” pour spamrule, serait ‘emel’ et non pas ‘word’ ?
- le plug fonctionnerait sur un mode “apprentissage”; dans ce cas, ce serait bien d’avoir accès, dans la gestion du plug, à la définition d’adresses mail, comme pour les mots
- comme pour les mots, une expression rationnelle pourrait être utile?
2 De Franck -
Je vais vérifier pour la longueur, mais en tout cas ça ne rentre pas dans les 128 caractères dispos, donc il faudra hacher.
Par ailleurs, je vais, pour l’instant, ne m’intéresser qu’à l’adresse email et voir ensuite comment se comporte le filtre ; je changerai peut-être mon fusil d’épaule si ce n’est pas concluant.
Le type pour spamrule sera effectivement un truc du genre greylist ou greyemail.
Je ne prévois pas d’accès à cette liste, qui se mettra à jour en fonction des arrivées de commentaires et de la gestion dans faux-positifs et faux-négatifs par l’utilisateur. Je ne pense pas qu’il soit utile d’aller plus loin.
Pas d’expression rationnelle non plus, en tout cas pour l’instant, ça finirait pas devenir lourd, surtout si on décidait d’ajouter l’accès à la liste. Peu d’entre les utilisateurs sont en mesure d’écrire des expressions rationnelles.
Je pense qu’il faut rester sur une gestion simple : sortir un commentaire des spams, ou en mettre un dans les spams, est à la portée de la plupart, c’est probablement suffisant en l’état.