Path: ...!news.mixmin.net!weretis.net!feeder8.news.weretis.net!usenet.ovh!news.usenet.ovh!.POSTED!not-for-mail
From: Jean-Paul <contact@usenet.ovh>
Newsgroups: fr.usenet.distribution
Subject: Re: Supersedes sans cancel-key/cancel-lock
Date: Wed, 30 Oct 2024 19:44:05 +0100
Organization: NUO - News.Usenet.Ovh
Message-ID: <6gv4ijprpn6usqu28gtdo33vk651g1h02q@news.usenet.ovh>
References: <9c8a39d9-c55e-a51e-bdb3-f86e3acf18e9@miakinen.net> <vfo7rh$14v$1@cabale.usenet-fr.net> <s0eP6QKSsx3JcLOpKTCg8k2gt0w@jntp> <vfrciv$1mev$2@cabale.usenet-fr.net> <vfsrbj$2334h$1@dont-email.me> <vftnkp$bvi$1@cabale.usenet-fr.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: news.usenet.ovh; posting-account="llp";
	logging-data="1020683"; mail-complaints-to="abuse@usenet.ovh"
User-Agent: ForteAgent/8.00.32.1272
Cancel-Lock: sha256:KGGXDLaWKIVIoPMpFqMlBkO73TwGSnTueiZYJjCLiNQ=
Bytes: 2417
Lines: 38

Olivier Miakinen <om+news@miakinen.net> composa la prose suivante:

>[diapublication avec suivi]
>
>Le 30/10/2024 09:39, M.V. a écrit :
>> 
>> In message <vfrciv$1mev$2@cabale.usenet-fr.net>, on Tuesday, 29 October
>> 2024 at 20:21, Olivier Miakinen wrote:
>> 
>>> [Supersedes <vfrcf7$1mev$1@cabale.usenet-fr.net>]
>> 
>> C'est fatigant ces supersedes sans cancel-key.
>
>Sachant que j'utilise à la fois un courrielleur *et* un serveur qui ne
>génèrent pas de Cancel-Lock, il ne peut évidemment pas y avoir non plus
>de Cancel-Key lors du Supersedes.

Tu devrais suggérer au gestionnaire de ton serveur de le faire évoluer.
C'est standard depuis la version 2.7 d'inn2.


>> Lisant souvent les messages par ordre chronologique, je me tape de ce
>> fait le message remplacé qui reste sur les serveurs tel que E-S
>> puisqu'il n'y a pas de cancel-key/cancel-lock.
>
>Je comprends qu'eternal-september n'accepte pas d'annuler un article
>protégé par Cancel-Lock, si le Cancel ou le Supersedes n'a pas le bon
>Cancel-Key.

Normal.

>Mais pour un article sans aucun Cancel-Lock, il devrait s'assurer de la
>compatibilité avec ce qui se faisait avant le RFC 8315 de 2018. Et donc
>accepter d'annuler un article non protégé, au moins si l'auteur de
>l'annulation ou du remplacement est le même que l'auteur de l'article
>d'origine non protégé.

C'est la porte ouverte à tous les abus.