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: Re: Erreur bizarre INN2
Date: Sun, 22 May 2022 15:13:25 +0200
Organization: Groupes francophones par TrigoFACILE
Message-ID: <t6dctl$18147$1@news.trigofacile.com>
References: <t4p4q8$hpj$1@shakotay.alphanet.ch>
 <t4p70v$33ooe$1@news.trigofacile.com> <t4p91a$3k1$1@shakotay.alphanet.ch>
 <t4pccu$33sk1$1@news.trigofacile.com> <t67gib$kcp$1@rasp.pasdenom.info>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 22 May 2022 13:13:25 -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="1311879"; mail-complaints-to="abuse@trigofacile.com"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.9.0
Cancel-Lock: sha1:TcGAC6AQrrMtZbGJ9L4GA0ke9+I= sha256:ymFecoVKUg9mDMxjlE4ViZ1umz6J9jr4JxjC94EZnCM=
	sha1:9GixZ5bSXlZgggeMQv+iHtn4AJg= sha256:DKP+kp8Rq+GUU5KGfk5UAuYvOQxvlUCtTrXlGTUBhEI=
In-Reply-To: <t67gib$kcp$1@rasp.pasdenom.info>
Bytes: 3467
Lines: 47

Bonjour Stéphane,

>> Ton rejet "Cancel of non-existing ID" ne provient-il vraiment pas de ton
>> cleanfeed.local ??
>>
>>       https://home.gegeweb.org/rfc8315.html
>>
>>     return "$descr of non-existing ID $target";
> 
> Serait-ce gênant en cas de cleanfeed gérant le cancel-Lock de ne pas
> rejeter ce type de post?

Le cas d'usage est de pouvoir annuler un article avant même que 
l'original ne parvienne au serveur. Par exemple lorsqu'un robot 
anti-spam détecte un spam, envoie un cancel associé et que tu reçoives 
ce cancel avant l'article initial. Ton serveur pourra directement 
refuser le Message-ID proposé par un feed, et ainsi économiser un peu de 
bande passante.
Je pense que de nos jours, avec les connexions actuelles, ce cas ne se 
produit que rarement. Les spams sont reçus avant leur annulation. (Je 
peux me tromper, je n'ai pas de stats là dessus, mais ça ne me semble 
pas déraisonnable.)

Et donc ici, on serait dans le cas d'une annulation avec un Cancel-Key. 
Je doute encore plus qu'un article d'annulation envoyé par le *même* 
serveur/client ou qui a envoyé l'article originel avant, parvienne plus 
tôt... (car c'est bien le même serveur qui a la clef d'annulation à 
envoyer, et non un autre)


> Dans ce cas comment ne pas traiter ce message mais ne pas faire de
> reject qui l'exclue des feeds?

Je ne pense pas qu'il faille s'en soucier. Autant accepter l'annulation 
et la retransmettre.
Soit l'article initial te parvient après, et il sera rejeté par ton 
serveur (je ne suis pas persuadé que ce cas se produira, surtout si 
l'original a un Cancel-Lock). À moins d'une attaque par un serveur, qui 
annule à vue tous les messages avec un Cancel-Key forgé... et dans ce 
cas il faut traiter cette attaque à la source (UDP).
Soit il ne te parvient pas, et ça ne changeait rien d'accepter son 
annulation préventive ou non.

-- 
Julien ÉLIE

« Tout homme devrait un jour se marier ; après tout, le bonheur n'est
   pas la seule chose dans la vie. »