Sujet : Re: Annulation pour autrui avec Cancel-Lock
De : iulius (at) *nospam* nom-de-mon-site.com.invalid (Julien ÉLIE)
Groupes : fr.comp.usenet.serveursDate : 31. Aug 2022, 22:41:43
Autres entêtes
Organisation : Groupes francophones par TrigoFACILE
Message-ID : <teokin$133c0$1@news.trigofacile.com>
References : 1 2 3 4 5 6 7 8 9
User-Agent : Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.12.0
Bonsoir Stéphane,
Par contre inews est pointilleux il refuse le post car le cancel est pour
autrui.
C'est une règle de gestion qu'inews ne devrait pas mettre en œuvre (contraire aux RFC).
Pour info, c'est corrigé dans INN 2.7.0. En implémentant la gestion native du Cancel-Lock dans INN, j'ai fait une passe sur le fonctionnel d'inews. Extrait du journal des modifications :
The refusecybercancels and verifycancels parameters have been removed from inn.conf. Besides, inews no longer checks if the From or Sender header fields of a cancel or supersede request match the ones of the original article being withdrawn. All of these were either inefficient or inexact checks.
A new -E flag can now be given to inews to silently discard empty articles, instead of bailing out with an error. Another new -m flag permits setting the Message-ID instead of letting inews generate one. And a third new flag, -Y, forces inews to authenticate to the remote news server even if not asked to.
inews no longer adds a Sender header field nor overwrites an existing one in articles it processes if the new -P flag is used. The Path header field, if unset, no longer systematically contains the path identity of the local news server (you may want to add it manually with the -x flag, if needed). Finally, inews also no longer adds the obsolescent Lines header field.
Cet utilitaire est très pratique :-)
-- Julien ÉLIE« Les soucis d'aujourd'hui sont les plaisanteries de demain. Rions-en donc tout de suite. » (Henri Béraud)