Bonjour,

j'ai installé INN-2.4.2 sur un intranet.
Je me pose plusieurs questions sur les cancels :
-quel champs d'entête est vérifié par inn pour verifier que le cancel
est envoyé par la personne qui a posté (From, Sender .... ?)
-est-ce possible (et comment) de donner des droits de cancel à une
personne sur des messages qui ne lui appartiennent pas (pour faciliter
l'administration) ?

Merci.

Gaël écrivait

> j'ai installé INN-2.4.2 sur un intranet.
> Je me pose plusieurs questions sur les cancels :
> -quel champs d'entête est vérifié par inn pour verifier que le cancel
> est envoyé par la personne qui a posté (From, Sender .... ?)

Il n'y a pas de vérification, un cancel est juste un article de control:
cancel <message-id>. Il y a une extension « Cancel lock » qui permet de
vérifier que le cancel vient bien de l'auteur. Mais ça n'est pas très
normalisé ou utilisé.

Patrick Lamaizière a écrit :
> Gaël écrivait
>>-quel champs d'entête est vérifié par inn pour verifier que le cancel
>>est envoyé par la personne qui a posté (From, Sender .... ?)
>
> Il n'y a pas de vérification, un cancel est juste un article de control:
> cancel <message-id>. Il y a une extension « Cancel lock » qui permet de
> vérifier que le cancel vient bien de l'auteur. Mais ça n'est pas très
> normalisé ou utilisé.

Au temps pour moi - ce n'est pas le serveur qui refuse l'annulation,
c'est le client.

Le 12 janvier 2006 à 15:14, Gaël a écrit :

> Patrick Lamaizière a écrit :
>> Gaël écrivait
>>>-quel champs d'entête est vérifié par inn pour verifier que le cancel
>>>est envoyé par la personne qui a posté (From, Sender .... ?)
>>
>> Il n'y a pas de vérification,

Cfr verifycancels dans inn.conf. C'est relativement inutile, mais la
vérification peut être mise en place (à ce moment, je pense que c'est
from ou sender qui doivent correspondre au from - ou sender ? -
d'origine).

>> un cancel est juste un article de control:
>> cancel <message-id>. Il y a une extension « Cancel lock » qui permet de
>> vérifier que le cancel vient bien de l'auteur. Mais ça n'est pas très
>> normalisé ou utilisé.
>
> Au temps pour moi - ce n'est pas le serveur qui refuse l'annulation,
> c'est le client.

.... Généralement.

Les gestionnaires de serveurs de news sont tout à fait libres
d'implémenter localement leurs propres politiques concernant les
annulations d'articles ou divers postages, mais, dans la veine de ce que
dit Patrick au sujet du cancel lock, ce n'est pas standardisé.

A noter qu'en fonction du type et du volume d'articles reçus, réguler
les cancels peut être réalisable ou non dans la pratique - un serveur
local qui reçoit des articles d'une seule source (par exemple qui serait
utilisé en entreprise) pourrait facilement implémenter une
vérification; a contrario, contre un feed d'une hiérarchie
(inter)nationale, c'est généralement une mauvaise idée...

Fred
--
All that is now All that is gone All that's to come
And everything under the sun is in tune
But the sun is eclipsed by the moon
(Pink Floyd, Eclipse)

F. Senault a écrit :
> Le 12 janvier 2006 à 15:14, Gaël a écrit :
>

> Cfr verifycancels dans inn.conf. C'est relativement inutile,

Pourquoi est-ce inutile ? Car inefficace ?

> Les gestionnaires de serveurs de news sont tout à fait libres
> d'implémenter localement leurs propres politiques concernant les
> annulations d'articles ou divers postages, mais, dans la veine de ce que
> dit Patrick au sujet du cancel lock, ce n'est pas standardisé.

C'est ce que je compte faire mais ne sait pas ou le faire (ou comment).

> A noter qu'en fonction du type et du volume d'articles reçus, réguler
> les cancels peut être réalisable ou non dans la pratique - un serveur
> local qui reçoit des articles d'une seule source (par exemple qui serait
> utilisé en entreprise) pourrait facilement implémenter une
> vérification ;

C'est mon cas - il ne me parait pas judicieux qu'une personne puisse
annuler les articles qu'elle n'a pas postés.
Par contre j'aimerais qu'un "administrateur" puisse supprimer facilement
certains messages (sans passer par la ligne de commande).

Le 12 janvier 2006 à 16:18, Gaël a écrit :

> F. Senault a écrit :
>> Le 12 janvier 2006 à 15:14, Gaël a écrit :
>>
>
>> Cfr verifycancels dans inn.conf. C'est relativement inutile,
>
> Pourquoi est-ce inutile ? Car inefficace ?

Lis la page de man, il y a un petit passage là dessus - en gros, c'est
consommateur de ressources, et pas fiable : ça se base sur le from et le
sender qui sont, faut-il le rappeler, pratiquement incontrôlables sur
Usenet en général.

Maintenant, en circuit fermé, si on laisse innd assigner le champ sender
(nnrpdauthsender a true), ça devient peut-être exploitable, je n'ai
jamais essayé.

>> Les gestionnaires de serveurs de news sont tout à fait libres
>> d'implémenter localement leurs propres politiques concernant les
>> annulations d'articles ou divers postages, mais, dans la veine de ce que
>> dit Patrick au sujet du cancel lock, ce n'est pas standardisé.
>
> C'est ce que je compte faire mais ne sait pas ou le faire (ou comment).

Si verifycancels est inutilisable pour toi, il reste à regarder dans les
filtres perl - filter_innd.pl et filter_nnrpd.pl et à le programmer
(peut-être, en fonction des situations, vérifier sur le
nntp-posting-host, sur le sender assigné par nnrpd, ...).

>> A noter qu'en fonction du type et du volume d'articles reçus, réguler
>> les cancels peut être réalisable ou non dans la pratique - un serveur
>> local qui reçoit des articles d'une seule source (par exemple qui serait
>> utilisé en entreprise) pourrait facilement implémenter une
>> vérification ;
>
> C'est mon cas - il ne me parait pas judicieux qu'une personne puisse
> annuler les articles qu'elle n'a pas postés.
> Par contre j'aimerais qu'un "administrateur" puisse supprimer facilement
> certains messages (sans passer par la ligne de commande).

Modère les groupes...

Sinon, tu peux débrancher le nnrpdauthsender dans un authentificateur
précis de readers.conf et forcer l'admin à positionner son champ sender
à la valeur du message à annuler...

Les autres solutions passent par du scriptage maison.

Fred
--
Je regarde le bleu profond se voiler
Parfois, un point lumineux se charge de me rappeler
Que je ne suis pas ici pour paresser
Et que quelque part on a besoin de moi pour aider (Merzhin, Par delà)

>>>Cfr verifycancels dans inn.conf. C'est relativement inutile,
>>
>>Pourquoi est-ce inutile ? Car inefficace ?
>
> Lis la page de man, il y a un petit passage là dessus - en gros, c'est
> consommateur de ressources, et pas fiable : ça se base sur le from et le
> sender qui sont, faut-il le rappeler, pratiquement incontrôlables sur
> Usenet en général.
>
> Maintenant, en circuit fermé, si on laisse innd assigner le champ sender
> (nnrpdauthsender a true), ça devient peut-être exploitable, je n'ai
> jamais essayé.
Le man, je l'ai lu, mais il est très succinct !
Comme j'ai une authentification Ldap (circuit fermé), l'idéal est que
j'utilise sender.

> Si verifycancels est inutilisable pour toi, il reste à regarder dans les
> filtres perl - filter_innd.pl et filter_nnrpd.pl et à le programmer
> (peut-être, en fonction des situations, vérifier sur le
> nntp-posting-host, sur le sender assigné par nnrpd, ...).
Effectivement, le filter_nnrpd me parait tout indiqué.

Merci

Le 13 janvier 2006 à 13:12, Gaël a écrit :

>> Maintenant, en circuit fermé, si on laisse innd assigner le champ sender
>> (nnrpdauthsender a true), ça devient peut-être exploitable, je n'ai
>> jamais essayé.
> Le man, je l'ai lu, mais il est très succinct !
> Comme j'ai une authentification Ldap (circuit fermé), l'idéal est que
> j'utilise sender.

Ca semble pas mal.

>> Si verifycancels est inutilisable pour toi, il reste à regarder dans les
>> filtres perl - filter_innd.pl et filter_nnrpd.pl et à le programmer
>> (peut-être, en fonction des situations, vérifier sur le
>> nntp-posting-host, sur le sender assigné par nnrpd, ...).
> Effectivement, le filter_nnrpd me parait tout indiqué.
>
> Merci

Bonne chance !

Fred
Newsmaster épuisé de lacave.net...
--
C'est comme la fin du siècle On aura tout compris Même les shérifs
Ceux qu'on achète On les distingue mal des bandits On a tout eu
Ce fut un siècle formidable Quelques malentendus seulement
Des histoires, des histoires (Noir Désir, Fin de siècle)