Path: ...!weretis.net!feeder8.news.weretis.net!news.mixmin.net!aioe.org!E7Ganzi5qIyvPRgjwKvdkg.user.46.165.242.91.POSTED!not-for-mail
From: Franck <franck@email.invalid>
Newsgroups: fr.comp.usenet.serveurs
Subject: Re: Cancel-Key et Cancel-Lock ne fonctionnent pas sur dodin.fr.nf
Date: Mon, 12 Sep 2022 21:36:17 +0200
Organization: Aioe.org NNTP Server
Message-ID: <tfo1nj$87v$1@gioia.aioe.org>
References: <tfers7$g3o$1@ns507557.dodin.fr.nf> <tfg2ei$1ocg$1@gioia.aioe.org>
 <tfhjf7$2vm$1@ns507557.dodin.fr.nf> <tfhm4f$nvd$1@shakotay.alphanet.ch>
 <tfhq15$420$1@ns507557.dodin.fr.nf> <tfhvq7$26r$1@shakotay.alphanet.ch>
 <tfi0ls$5fv$1@shakotay.alphanet.ch> <tfibp3$19c2$1@gioia.aioe.org>
 <tfifsl$1q3an$1@news.trigofacile.com> <tfml2d$q35$1@rasp.pasdenom.info>
 <tfmm7k$mh0$1@ns507557.dodin.fr.nf> <tfnpju$1urg8$2@news.trigofacile.com>
 <tfnsm4$1pbh$1@gioia.aioe.org> <tfnv1i$1uvgc$1@news.trigofacile.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: gioia.aioe.org; logging-data="8447"; posting-host="E7Ganzi5qIyvPRgjwKvdkg.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
X-Notice: Filtered by postfilter v. 0.9.2
Content-Language: fr
Bytes: 4208
Lines: 66

Le 12/09/2022 à 20:50, Julien ÉLIE a écrit :

Salut Julien,

> 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).

C'est une excellente explication de "l'administrateur", jdd si tu nous 
lis...

> Le serveur n'envisage ni n'affirme, il applique la configuration demandée.

On est d'accord.

> 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 :-)

P**** Julien, tu me connais, çà va rajouter plein d'options inutiles 
dans mon code!!! Arrête de me filer de mauvaises idées alors que tu m'as 
sagement conseillé de faire le ménage dans mes nombreux cas qui ne se 
produiront peut-être jamais ^^

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

C'est bon ça, cela veut dire que je ne perds pas complètement la tête :)

> 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.)

Çà, je l'ai supprimé lorsque tu m'as conseillé de ne pas implémenter la 
commutation de modes. C'est passé à la trappe sans le vouloir  ;-(

>> Décider ou envisager? :-)
> 
> Je dirai que l'administrateur estime que le groupe est sûr, et décide de 
> le paramétrer ainsi.

Çà me va, tant qu'il l'affirme pas :-)

> 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" :-)

Et allez, tu insistes pour que je rajoute une condition! :-)

On peut d'ailleurs considérer que ce cas de figure existe déjà dans le 
cas où un serveur est configuré pour identifier les utilisateurs 
uniquement avec AUTHINFO USER (Et sans AUTHINFO PASS).

Ils ont tous le même mot de passe, vierge :)

Très bonne soirée,
Franck