Path: ...!weretis.net!feeder8.news.weretis.net!news.mixmin.net!aioe.org!E7Ganzi5qIyvPRgjwKvdkg.user.46.165.242.91.POSTED!not-for-mail From: Franck 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: References: 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