Re: Cancel-Key et Cancel-Lock ne fonctionnent pas sur dodin.fr.nf

Bonsoir Franck,

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é".

 Je suis tout à fait d'accord avec toi, mais il me semble que pour en être certain, il faudrait que le serveur puisse affirmer seul ces deux conditions, ce qui me semble difficilement réalisable.

Le serveur ne peut clairement pas le savoir, effectivement.
L'administrateur est le plus sachant, et configure son serveur en conséquence. Libre à lui de s'affranchir du respect strict des RFCs. Il le fait en toute connaissance de cause (au même titre qu'à travers les filtres Perl, un administrateur peut utiliser la syntaxe qu'il souhaite, pas forcément conforme, dans tous les en-têtes des messages injectés).

Je pense, qu'au mieux, le serveur peut "envisager" mais pas "affirmer", sauf à ce qu'il se soit réellement identifié avec AUTHINFO. Non ?

Le serveur n'envisage ni n'affirme, il applique la configuration demandée.
Et si l'on veut aller plus loin, on pourrait considérer comme réellement authentifiés que les utilisateurs avec des mots de passe d'un certain niveau de complexité :-)
Si l'utilisateur "toto" a aussi "toto" comme mot de passe, il pourrait être légitime de débrayer le mécanisme de Cancel-Lock ^^ bien que non précisé par la RFC :-)

dans le cas d'un feed qui ne dispose pas d'une IP fixe, il faut configurer le feed avec un mot de passe (avec n'importe quel nom d'utilisateur, ce qui avait d'ailleurs motivé un ajout dans ta doc). Sans ce préalable INN n'est pas en mesure de l'identifier formellement. Non?

Oui, c'est bien cela. Et dans ce cas de configuration où toutes les connexions entrantes arrivent en mode transit, les lecteurs devront envoyer un MODE READER, et le pair sans IP fixe devra s'authentifier avec AUTHINFO.
Une telle configuration pourrait d'ailleurs utiliser avec profit le port 119 pour les lecteurs et le port 433 pour les feeds, ça me semble plus propre. (Le feed sans IP fixe devra toujours bien s'authentifier.)

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.

 Décider ou envisager? :-)

Je dirai que l'administrateur estime que le groupe est sûr, et décide de le paramétrer ainsi.

Tout comme une IP fixe peut être utilisée par plusieurs personnes derrière un VPN ou un routeur NAT, raison pour laquelle je pense qu'un serveur ne peut pas être affirmatif et simplement envisager que le groupe est sûr.
 Sauf à ce que l'utilisateur s'identifie formellement.

Je suis d'accord avec toi, le serveur ne peut lui-même être affirmatif sur le sujet... et le groupe n'est pas forcément sûr même si tous les utilisateurs s'identifient formellement ^^
Ils pourraient tous avoir le même mot de passe "mot2passe" :-)
--
Julien ÉLIE
« – Connaissez-vous la différence entre l'ignorance et l'apathie ?
   – J'en sais rien et je m'en fous. »