Path: ...!news.mixmin.net!proxad.net!feeder1-2.proxad.net!usenet-fr.net!pasdenom.info!usenet.ovh!alfanet.usenet.ovh!.POSTED!not-for-mail From: llp Newsgroups: fr.comp.usenet.serveurs Subject: Re: =?utf-8?Q?Refus_d'annulations_l?= =?utf-8?Q?=C3=A9gitimes?= Date: Thu, 10 Aug 2023 22:08:02 +0200 Organization: Alfa Network En Travaux Message-ID: References: <1a8cci9liv6tepnbrs44u09t3tt5cmnbvf@consensus-omnium> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: alfanet.usenet.ovh; posting-account="llp"; logging-data="908279"; mail-complaints-to="abuse@usenet.ovh" User-Agent: ForteAgent/8.00.32.1272 Cancel-Lock: sha256:cEYCR9CGiYkZnkr6NPdE7uKzKl0E2ohBGgGpGXWBtQ8= Bytes: 3439 Lines: 45 Julien ÉLIE composa la prose suivante: >Bonjour Olivier, > >>> Path: ...!from-devjntp!cyberspam!usenet >>> Injection-Info: news2.nemoweb.net; posting-host="43d157f9437411bd9c60ee58b39a513a2d9d2b85"; logging-data="2023-07-30T08:20:15Z/8105225"; posting-account="3@news2.nemoweb.net"; mail-complaints-to="newsmaster@news2.nemoweb.net" >> >> Le second problème, le plus grave, et celui qui est la cause de cette >> erreur 439, c'est qu'il ne devrait pas y avoir de champ Injection-Info, ou >> au moins que celui-ci ne contienne pas de paramètre posting-host. >[...] >> c'est de la faute >> du développeur du serveur (et un peu aussi de la config par défaut d'INN ou >> cleanfeed qui se base sur les champs Path et Injection-Info pour refuser >> certaines annulations pourtant légitimes). > >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. > >Je n’ai pas d'avis particulier sur le bien-fondé de cette règle. Si >besoin de l'adapter ou de la supprimer, il faudrait ouvrir un rapport de >bogue (https://github.com/crooks/cleanfeed/issues). > >Le souci toutefois est qu'il n'y a plus vraiment de mainteneur actif de >Cleanfeed. C'est un package orphelin depuis 3 ans. Steve fusionnera >simplement un patch complet qui lui serait fourni par PR (onglet Pull >Request) mais je ne pense pas qu'il passera du temps à corriger quoi que >ce soit. > >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 ! > >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. 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. Pourquoi changer ce qui marche bien ? Pourquoi faudrait-il s'adapter à Nemo ?