Re: Refus d'annulations légitimes

Bonjour Olivier,

C'est une règle implémentée dans Cleanfeed depuis de nombreuses années.
Avant que le support de l'en-tête Injection-Info ne soit ajouté à
Cleanfeed, cette règle filtrait déjà les messages suivant la convention
cyberspam et comportant les en-têtes X-Trace et NNTP-Posting-Host
simultanément renseignées.

 À vrai dire je ne vois qu'une seule justification possible pour cette
règle. Ce serait qu'un outil d'annulation automatique ait été développé
par quelqu'un, puis distribué à des « script kiddies » qui pourraient
l'utiliser mais sans savoir le modifier (ne serait-ce que pour retirer
le préremplissage du champ Path ou le remplacer par autre chose).

Oui, c'est une explication très plausible. Cette règle date et avait très probablement une plus forte utilité à l'époque que maintenant.

Je ne pense pas que ce soit nécessaire, d'autant que comme tu l'écris :

>
Cette règle est par ailleurs désactivable (option
block_user_spamcancels). Elle pourrait simplement ne plus être active
par défaut. Ceci au moins est simple à changer !

Il y a tellement de possibilités de paramétrage que la configuration par défaut demeure souvent inchangée... Tous les administrateurs de news ne sont pas experts en filtrage de spam, et moi-même suis incapable de dire quelles sont les valeurs optimales de cutoff, ceiling, etc. sur chaque fonctionnalité.
De manière générale, je constate que Cleanfeed et PyClean ne sont plus maintenus alors que leur configuration nécessite quelques adaptations au fil du temps et de l'évolution des usages et des groupes dans les hiérarchies. En particulier la liste des groupes à exclure de certains filtres peut évoluer.
Ceci nécessite en revanche du temps à monitorer pour se rendre compte des faux positifs.

Ce qui serait intéressant à avoir comme stats, c'est le nombre et la
pertinence des annulations actuellement filtrées en raison de cette
règle.

 Oui. Je n'ai pas de serveur de news moi-même alors je ne peux pas
établir ce genre de stats. Avis à ceux qui peuvent le faire

Ce genre de stats ne peut en outre être fait que sur un spool non filtré... Car si l'ensemble des pairs utilise Cleanfeed dans sa configuration par défaut, le message n'arrivera pas au serveur sur lequel les stats sont faites. Pareillement si le serveur en question utilise similairement Cleanfeed !

Si des annulations manifestement abusives passent à travers les
mailles du filet de Cleanfeed en désactivant cette option, alors ce
n'est pas bon et il y a peut-être des règles complémentaires à ajouter,
en même temps que sa désactivation par défaut, pour filtrer ce qui
aurait manifestement dû l'être.

 Là je suis plutôt pessimiste. Si vraiment il y a des annulations
abusives qui sont filtrées par cette règle, alors je ne vois pas
quels critères supplémentaires on pourrait ajouter pour les filtrer
quand même en désactivant l'option.

Je suis d'accord qu'une adaptation de la règle ne soit pas forcément possible.

D'un autre côté, il y aurait peut-être moyen de convaincre Julien
Arlandis de corriger le fonctionnement de Nemo lorsque c'est un
modérateur reconnu qui demande une annulation, soit en modifiant
le Path, soit en modifiant Injection-Info.

Surtout que c'est simple à changer...
 https://github.com/Julien-Arlandis/phpNemoServer/blob/4e05b4cbad34a9247def7122fe9b070459705f2e/Applications/NemoNetwork/lib/class.nntp.php#L227
     if ($isCancel && $notSupersedes && $isSubjectCancel) {
             return "Path: from-devjntp!cyberspam!usenet\r\n".$article;
     } else {
             return "Path: from-devjntp\r\n".$article;
     }
Si l'utilisateur peut modifier le sujet par défaut du message d'annulation (je ne sais pas si c'est faisable car je n'ai pas de compte sur Nemoweb pour essayer), il n'a qu'à mettre autre chose que "cmsg " au début, et "cyberspam" ne sera plus ajouté dans le Path.
Je dis ça en voyant :
     $pos = strpos($value, "cmsg ");
     if ($pos !== false) {
         $isSubjectCancel = true;
     } else {
         $isSubjectCancel = false;
     }
Ou sinon, s'il vaut mieux ne pas mettre le posting-host dans Injection-Info, il suffit de ne pas l'insérer quand la même condition de ($isCancel && $notSupersedes && $isSubjectCancel) est détectée.
Le logging-data et le posting-account suffisent à déterminer quel est l'utilisateur émetteur.
Pas sûr qu'il faille ajouter la notion de "modérateur reconnu". Après tout, un acteur malintentionné saura bien envoyer des annulations depuis un autre serveur qui ne mettra pas "cyberspam" dans l'en-tête.
Mais bien sûr, cette notion pourrait être ajoutée. C'est un peu plus complexe à faire en revanche proprement car il faut ajouter une nouvelle donnée liée aux utilisateurs.
Ou sinon ça peut bien sûr être fait "cradement" dans le code avec un "si $user tartampion, alors pas de posting-host", et c'est plié en quelques minutes vu que c'est du PHP interprété à chaud.
     elseif ($cle === 'PostingHost') {
         $article .= "Injection-Info: " . $json{'Data'}{'OriginServer'} . '; posting-host="'.$json{'Data'}{'PostingHost'}. '"; logging-data="' . $json{'ID'} . '"; posting-account="' . $json{'Data'}{'UserID'} . '"; mail-complaints-to="' . $json{'Data'}{'ComplaintsTo'}.'"'."\r\n";
     }
Bref, plusieurs possibilités faciles existent...
Globalement, il y a beaucoup de choses mentionnées par ici sur phpNemoServer qui pourraient être très rapidement corrigées. Le code est bien structuré et bien fait. J'ai surtout l'impression que son créateur se moque bien de prendre en compte les remarques...
Stéphane pourrait même ajouter un kludge dans sa passerelle pour supprimer le posting-host de certains utilisateurs avant injection de l'article sur Usenet en NNTP ^^
Tout ce que le développeur de phpNemoServer ne souhaite pas faire peut être accompli dans la passerelle avec NNTP au titre du reformatage assuré par une gateway :-)
Mais bon, c'est quand même un peu abusé de devoir faire ce genre de choses dans une passerelle sachant que c'est simple à corriger à la source.
Franchement, sans parler de phpNemoServer (le serveur JNTP), c'est surtout NemoClient (le webnews basé sur JNTP) qui a du potentiel et qui mériterait d'être déployé à plus grande échelle. Toute la partie affichage web est bien faite, et il s'agirait d'adapter les requêtes qu'elle réalise vers le serveur. NemoClient mériterait d'avoir 2 modes de fonctionnement par paramétrage : l'administrateur active le mode web services (s'il utilise phpNemoServer en JNTP) ou le mode connexion permanente avec un serveur de news (s'il utilise un serveur NNTP quel qu'il soit). Un peu de boulot mais franchement le plus dur est fait (le design et le fonctionnement de l'interface web).

Je ne peux pas lui écrire pour le moment, car là où je suis j'ai
accès aux news mais de façon limitée à mon courriel.

C'est hautement geek en 2023 d'avoir accès à Usenet mais pas aux mails :-)
--
Julien ÉLIE
« Si l'amour est aveugle, il faut palper. »