Sujet : Re: Cancel-Key et Cancel-Lock ne fonctionnent pas sur dodin.fr.nf
De : iulius (at) *nospam* nom-de-mon-site.com.invalid (Julien ÉLIE)
Groupes : fr.comp.usenet.serveursDate : 12. Sep 2022, 19:17:50
Autres entêtes
Organisation : Groupes francophones par TrigoFACILE
Message-ID : <tfnpju$1urg8$2@news.trigofacile.com>
References : 1 2 3 4 5 6 7 8 9 10 11
User-Agent : Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.2.2
Bonsoir Jean-Daniel,
la RFC dit que s'il n'y a pas d'authentification *il ne doit pas y avoir de clé inscrite dans le message" (mais je ne retrouve pas où j'ai lu ça)
Le paragraphe que tu recherchais est celui-ci :
If an injecting agent (or moderator) wants to act as a representative
for a posting agent without support for the authentication system
described in this document, then it MUST be able to positively
authenticate the poster and MUST be able to automatically add a
working Cancel-Key header field for all proto-articles with
cancelling or superseding attempts from that poster.
Attention toutefois au fait que quand on parle de "positively authenticate the poster", ce n'est pas nécessairement au sens utilisateur/mot de passe (commande AUTHINFO).
Un utilisateur possédant 1 IP fixe, et étant le seul à l'utiliser, peut aussi être considéré comme "authentifié".
Au même titre que tes feeds sont considérés comme "authentifiés" sans pour autant avoir un compte sur ton serveur.
Donc non il ne faut pas générer de Cancel-Lock pour des connections qui vraisemblablement peuvent être mutualisées. Autrement, c'est possible.
Et comme pour tout, c'est à l'administrateur qui paramètre son readers.conf de décider si un groupe d'accès est "sûr" ou non. ("localhost" pourrait typiquement ne pas l'être si plusieurs personnes ont un compte local sur la machine et utilisent inews ou autre)
-- Julien ÉLIE« Encore un peu, et cette histoire finira en queue de poisson ! » (Astérix)