Path: ...!weretis.net!feeder8.news.weretis.net!news.trigofacile.com!.POSTED.176.143-2-105.abo.bbox.fr!not-for-mail
From: =?UTF-8?Q?Julien_=c3=89LIE?= <iulius@nom-de-mon-site.com.invalid>
Newsgroups: fr.comp.usenet.serveurs
Subject: =?UTF-8?Q?Re=3a_Refus_d=27annulations_l=c3=a9gitimes?=
Date: Sat, 12 Aug 2023 11:48:48 +0200
Organization: Groupes francophones par TrigoFACILE
Message-ID: <ub7ki0$15b6q$1@news.trigofacile.com>
References: <mnteTwnxYnUOtnToVwrHlNAYmKI@jntp>
 <1a8cci9liv6tepnbrs44u09t3tt5cmnbvf@consensus-omnium>
 <uamf8c$alo$1@cabale.usenet-fr.net> <ub3407$128qc$1@news.trigofacile.com>
 <ub63et$3cc$1@cabale.usenet-fr.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 12 Aug 2023 09:48:48 -0000 (UTC)
Injection-Info: news.trigofacile.com; posting-account="julien"; posting-host="176.143-2-105.abo.bbox.fr:176.143.2.105";
	logging-data="1223898"; mail-complaints-to="abuse@trigofacile.com"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.14.0
Cancel-Lock: sha1:eZGZIAuB2rIYQoCwMnoCj5rQUfI= sha256:6mOzjeWq4H02rwuG3TWtQOcvXszY3I5bC5lfzDh+9CU=
	sha1:xKnLFKuGnp3rvNv51/05Y6p1ik0= sha256:ApPeuatPoXzCSiiycayZhHAuUxEWOqpUMae8ExnTBS4=
In-Reply-To: <ub63et$3cc$1@cabale.usenet-fr.net>
Bytes: 8793
Lines: 159


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. »