Path: ...!news.mixmin.net!proxad.net!feeder1-2.proxad.net!usenet-fr.net!pasdenom.info!.POSTED.2a01:e0a:21:ea80:2bcd:1898:8c71:814c!not-for-mail
From: yamo' <yamo@beurdin.invalid>
Newsgroups: fr.comp.usenet.serveurs
Subject: Re: Lutte anti-spam, Cancel vs NoCeM
Date: Thu, 15 Jun 2023 10:32:57 +0200
Organization: <https://pasdenom.info/news.html>
Message-ID: <AABkisy51KYAANfC.A3.flnews@yamo.pasdenom.info>
References: <u6bj8t$mqg$1@shakotay.alphanet.ch> <u6bu2b$kuh$2@shakotay.alphanet.ch> <FxgVYW1WToIzdDEeTXhf-LljPu0@jntp> <u6c3gu$pb3$4@shakotay.alphanet.ch> <ca6TWucoiDpxX4Dn1-dZlM5S7WQ@jntp> <u6cta1$1hhge$1@news.trigofacile.com> <W68jVP7-QFuKkDsvjWSkmLy3qgU@jntp> <u6d1d9$1hhge$2@news.trigofacile.com> <7oeQrQYPZeqBll4kqIRmXXeCPTk@jntp> <u6d3ev$1hhge$3@news.trigofacile.com> <1UwPlorbSW1lSEU_apFjPpGjKRc@jntp> <u6db4c$1hhge$4@news.trigofacile.com> <u6eg68$26bm$1@cabale.usenet-fr.net>
Reply-To: yamo' <yamo@groumpf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 15 Jun 2023 08:32:57 -0000
Injection-Info: rasp.pasdenom.info; posting-account="stephane@usenet"; posting-host="2a01:e0a:21:ea80:2bcd:1898:8c71:814c";
	logging-data="29591"; mail-complaints-to="abuse@pasdenom.info"
User-Agent: flnews/1.2.0 (for GNU/Linux)
Cancel-Lock: sha1:EDQEB/R19OuIvc8/1W1zQK89lS8= sha256:UIBtLq4WbxIECjIl7iFPAvg1/I9NnYhmU/w1LBe3T7k= sha256:JhTg+I+tLSpoeb0RHqLBbZNXarUlDxZ5CubUb+ILksU=
Bytes: 4096
Lines: 59

Salut, 

Olivier Miakinen a tapoté :
> [diapublication, suivi vers fr.comp.usenet.serveurs]

Oui flnews m'a alerté sur ce point!

> 
> Le 14/06/2023 23:23, Julien ÉLIE a écrit :
> > 
> > Je dis juste qu'il n'est pas forcément judicieux d'honorer les Cancel 
> > non authentifiés (avec une méthode comme Cancel-Lock) car il est en fait 
> > "facile" d'annuler en masse tous les articles de Usenet des 5 dernières 
> > années par exemple. Les Message-IDs sont simples à sortir. Et une fois 
> > que les annulations sont envoyées, en quelques minutes, c'est trop tard 
> > pour venir dire "ah mais il n'avait pas le droit, c'est un abus"...
> 
> Soit un acteur de usenet reconnu pour lutter contre le spam, et ayant la
> possibilité à la fois d'émettre des NoCeM (authentifiés par sa clé de
> chiffrement) et d'émettre des Cancel (authentifiés par le champ Path
> du serveur émetteur, reconnu lui aussi). On va se placer du côté d'un
> serveur recevant ces NoCeM et ces Cancel, et reconnaissant la légitimité
> des deux.
> 
> Y a-t-il alors une différence de traitement entre un NoCeM visant un MID
> donné et un Cancel visant le même MID ? Par exemple, est-ce que l'article
> est forcément supprimé du serveur dans le cas d'un Cancel, et forcément
> conservé sur le serveur (mais seulement caché) dans le cas d'un NoCeM ?
> 

La grosse différence est dans la configuration du serveur...

Dans le cas NoCeM, il faut juste le configurer et c'est bon*.
Pour les cancels, il y a plusieurs possibilités :
 On refuse tout.
 On accepte tout.
 Il y avait la possibilités désormais abandonnée pour INN 2.7, car
 inefficace, de filtrer selon la norme du cancel..
 On se casse la binette pour avoir une configuration
 spéciale dans cleanfeed.local

À terme, le plus simple c'est de refuser tous les cancels...


> Note : il me semble avoir lu que, dans le cas de free.fr, un article supprimé
> par un Cancel n'est en fait que caché, et qu'il est toujours possible de le
> récupérer depuis free.fr par une requête sur son MID.


Free est un cas vraiment à part d'architecture complexe avec des
 serveurs ayant des rôles différents. 
Dans le cas classique c'est un serveur qui assume tous les rôles.

* J'oublie la possibilité crée par Marc car elle demande actuellement 
 trop de complexité de mise en œuvre pour moi...

-- 
Stéphane 🔗<http://pasdenom.info/fortune/>
Se moquer de la philosophie, c'est vraiment philosopher. 
	-+- Blaise Pascal  (1623-1662), Pensées I.4 -+-