[sympa-fr] Re: Re: Re: Modération inefficace

[David Verdin <adresse@cachée>]

Bonjour,

Bertrand Lemaitre a écrit :
> Je ne comprends plus trop.
>
> J'ai fait un fichier scenari dans /home/sympa/etc/scenari nommé 
> include.send.header
> Afin de ne pas devoir ajouter ces règles dans tous les scenarios, 
> elles sont regroupées dans le fichier 
> /home/sympa/etc/scenari/include.send.header qui est automatiquement 
> inclus en tête de tous les scenarios 'send' (fonctionnalité standard 
> de Sympa).
>
> Par contre, est-ce que cela fait donc foirer les autres scénarios 
> d'avoir :
> match([header->Content-Disposition],/attachment/) smtp,smime,md5   -> 
> reject
> match([header->X-Spam-Flag],/YES/)   smtp -> request_auth
> is_subscriber([listname],[sender]) smtp,smime,md5    -> do_it
> is_editor([listname],[sender])     smtp,smime,md5    -> do_it
> true() smtp,md5,smime -> editorkey, quiet
>
>
> faut-il supprimer le true ? Comment bien écrire ce script ?
Oui, il faut supprimer le true, et je supprimerais également le deux 
règles précédentes pour ne conserver que les deux premières (les deux 
match).
L'objet de votre include est d'éviter le spam. Il ne doit donc contenir 
que les règles servant spécifiquement à contrôler le spam. L'exemple 
fourni pour lutter contre le spam est un exemple de scénario entier, pas 
d'include de scénario.
Rappelons qu'utiliser un include revient à ajouter les règles de 
l'include *au début* de tout autre scénario (dans votre cas, étant donné 
l'emplacement du fichier d'include, il s'appliquera à tous les scénarios 
de Sympa.
Rappelons également que Sympa évalue les règles, dans un scénario, du 
haut vers le bas *et s'arrête à la première évaluée comme vraie*. Il 
exécute alors l'action associée à cette règle.
En reprenant votre include, à l'état actuel, on voit que:
- les deux premières règles ne seront vérifiées que si on a affaire à 
des messages très particuliers, sans doute du spam ;
- la suivante sera vraie pour tout abonné à la liste. Le message est 
alors envoyé sans modération ;
- la suivante est vraie pour tout modérateur de la liste. Le message est 
alors envoyé sans modération ;
- la suivante est toujours vraie. Le message est mis en modération sans 
avertissement de l'expéditeur.

Ces cinq règles sont ajoutées au début de chaque scénario "send" de 
votre installation. Puisqu'au moins la dernière sera toujours vérifiée, 
*aucun de vos scénario ne seront jamais évalués*. C'est l'include qui 
prendra le pas sur tout le reste.
> Pour le problème des mails de modération, j'ai une liste avec les 
> propriétaires en mail et les modérateurs en no mail.
> Par contre, les deux sont les mêmes : proprio et modérateur.
> Et les modérateurs reçoivent de mail de liste-request.
>
> Que faut-il faire car je suis un peu perdu !!
Si les propriétaires et les modérateurs sont les mêmes, n'est-il pas 
normal que les modérateurs reçoivent les messages normalement destinés 
aux propriétaires ?
> Merci
>
> David Verdin a écrit :
> > Bonjour,
> >
> > Je devais être fatigué, hier. ;)
> > Les include de scénario ne sont pas cumulés. Ce comportement, c'est 
> > ce que nous avons en projet. Pour le moment, donc, les include de 
> > scénario sont écrasés comme n'importe quel paramètre de liste. Voilà 
> > la vérité rétablie dans toute sa splendeur.
> >
> > Bertrand Lemaitre a écrit :
> > > Bonsoir,
> > > Et merci pour tes ces informations.
> > > Le include que je fais est global pour toutes mes mailing listes et 
> > > sert contre le spam.
> > > L'exemple est tiré d'ici, et le true() y était conseillé.
> > Je doute alors qu'il s'agisse d'un inlcude. C'est un scénario 
> > général, mais pas un include.
> > Revoir pour tout cela :
> > http://www.sympa.org/wiki/manual/authorization-scenarios
> > > Je souhaiterais garder ce script global de gestion contre le spam, 
> > > mais garder la modération activer.
> > > Une désactivation du true de l'include global permettrait-il de 
> > > résoudre le problème, sans perdre en fonctionnalités ?
> > >
> > > Enfin, question subsidiaire :
> > > les modérateurs sont en no-mail et recoivent tout de même des mails 
> > > de liste-request de modération.
> > > Est-ce lié aussi à cet include ?
> > Non.
> > Les scénario ne peuvent gérer que les possibilités d'expédition de 
> > message. Ils n'empècheront jamais l'expédition des messages 
> > liste-request.
> > Par ailleurs, un message envoyé n'est pas distribué à un utilisateur 
> > en nomail. En revanche, si tous les propriétaires d'une liste sont en 
> > nomail, on envoie les messages en "-request " au listmaster. Ceci 
> > parce qu'il est anormal que les propriétaires ne soient pas tenus au 
> > courant des demandes de modération.
> >
> > Cordialement,
> > > Merci à tous
> > >
> > > David Verdin a écrit :
> > > > Dans Sympa, un grand nombre de paramètres peuvent être redéfinis 
> > > > suivant plusieurs niveaux de spécialisation.
> > > > En règle générale, on cherchera d'abord la valeur d'un paramètre 
> > > > dans les paramètres propres à la liste qui l'exploite, puis s'ils 
> > > > n'est pas défini, dans ceux de l'hôte virtuel, puis du serveur et 
> > > > enfin, s'ils ne sont déifnis nulle part, dans les valeurs par 
> > > > défaut de la distribution de Sympa.
> > > >
> > > > Voir pour cela cette page  du manuel, où l'explication est fournie 
> > > > pour les templates. Il en va de même pour de nombreux autres 
> > > > paramètres et notamment les scénarios :
> > > > http://www.sympa.org/wiki/manual/customizing#mail_template_files
> > > >
> > > > Pour les includes de  scénarios, cependant, le mécanisme est 
> > > > légèrement différent, en ce sens qu'elles sont concaténéss les unes 
> > > > aux autres, et non substituées. Si vous avez un include au niveau 
> > > > du serveur et un au niveau d'un hôte virtuel alors tout scénario 
> > > > équivalent des listes de cet hôte virtuel contiendra (dans l'ordre) :
> > > > - les règles de l'include du serveur,
> > > > - les règles de l'include de l'hôte virtuel
> > > > - les règles du scénario effectivement utilisé.
> > > >
> > > > Je vous invite également à rejeter un œil à la doc sur les include :
> > > > http://www.sympa.org/wiki/manual/authorization-scenarios#scenario_inclusion 
> > > >
> > > >
> > > > Ceci vous aide-t-il à analyser votre situation spécifique ?
> > > >
> > > > Pour répondre à vos questions :
> > > >
> > > > Bertrand Lemaitre a écrit :
> > > > > Modifier le script global ?
> > > > Il est certain qu'un include n'a pas vocation à contenir des règles 
> > > > telles que "true()" car ceci assure que les règles des scénarios ne 
> > > > seront jamais évaluées.
> > > > Il est sans doute bon de le modifier. Gardez à lesprit qu'une règle 
> > > > dans un include est systématiquement évaluée avant toute règle de 
> > > > scénario.
> > > > > Je ne comprends pas pourquoi je n'observe pas le même phénomène 
> > > > > sur toutes les listes ?
> > > > Cela dépend sans doute du niveau où votre include est défini.
> > > > > Selon David Verdin <adresse@cachée>:
> > > > >
> > > > > > C'est certainement ça. Les include de scénario sont toujours 
> > > > > ajoutés
> > > > > > //avant// toute règle spécifique à une liste.
> > > > > > Or les règles de scénarios sont interprétées séquentiellement 
> > > > > et, dès
> > > > > > qu'une condition est vérifiée, l'action est effectuée et 
> > > > > l'évaluation
> > > > > > s'arrête.
> > > > > >
> > > > > > Par conséquent, votre inclusion revient  à avoir un scénario 
> > > > > avec le
> > > > > > contenu suivant :
> > > > > >
> > > > > > match([header->Content-Disposition],/attachment/) 
> > > > > smtp,smime,md5   -> reject
> > > > > > match([header->X-Spam-Flag],/YES/)   smtp -> request_auth
> > > > > > is_subscriber([listname],[sender]) smtp,smime,md5    -> do_it
> > > > > > is_editor([listname],[sender])     smtp,smime,md5    -> do_it
> > > > > > true() smtp,md5,smime -> editorkey, quiet
> > > > > > is_editor([listname],[sender]) md5,smime -> do_it
> > > > > > is_editor([listname],[sender]) smtp -> request_auth
> > > > > > true() smtp,smime,md5 -> editorkey
> > > > > >
> > > > > > La première règle rencontrée vérifiée pour un abonné est :
> > > > > >
> > > > > > "is_subscriber([listname],[sender]) smtp,smime,md5    -> do_it"
> > > > > >
> > > > > > La règle :
> > > > > >
> > > > > > "true() smtp,smime,md5 -> editorkey"
> > > > > >
> > > > > > n'est donc jamais évaluée, et le message est envoyé sans 
> > > > > modération.
> > > > > >
> > > > > > Cordialement,
> > > > > >
> > > > > >
> > > > > >
> > > > > > Bertrand Lemaitre a écrit :
> > > > > >>
> > > > > >> Effectivement, j'ai un scenari qui surchage (cf. un autre de 
> > > > > mes posts)
> > > > > >> :
> > > > > >>
> > > > > >> title.fr antispam ALISE
> > > > > >>
> > > > > >> match([header->Content-Disposition],/attachment/) 
> > > > > smtp,smime,md5   -> reject
> > > > > >> match([header->X-Spam-Flag],/YES/)   smtp -> request_auth
> > > > > >> is_subscriber([listname],[sender]) smtp,smime,md5    -> do_it
> > > > > >> is_editor([listname],[sender])     smtp,smime,md5    -> do_it
> > > > > >> true() smtp,md5,smime -> editorkey, quiet
> > > > > >>
> > > > > >>
> > > > > >> Est-ce qui poserait pb ?
> > > > > >> Merci
> > > > > >>
> > > > > >> Selon David Verdin <adresse@cachée>:
> > > > > >>
> > > > > >>> Re-bonjour,
> > > > > >>>
> > > > > >>> Vos scénarios sont corrects. Le problème ne vient pas de là.
> > > > > >>> Plusieurs hypothèses :
> > > > > >>>
> > > > > >>> 1- Vos scénarios n'ont pas été rechargés après modification. 
> > > > > Quand on
> > > > > >>> modifie le texte d'un scénario, le rechargement n'est pas 
> > > > > automatique.
> > > > > >>> Il faut faire un "touch config" sur la liste concernée, ou 
> > > > > redémarrer
> > > > > >>> Sympa.
> > > > > >>> 2- Vous avez un fichier include.send.header quelque part dans 
> > > > > votre
> > > > > >>> installation dont les règles ont prévalence sur celle de votre 
> > > > > scénario.
> > > > > >>>
> > > > > >>> Cordialement,
> > > > > >>>
> > > > > >>> Bertrand Lemaitre a écrit :
> > > > > >>>>
> > > > > >>>> Bonjour,
> > > > > >>>>
> > > > > >>>> Le premier scénario correspond à la visibilité de la liste, 
> > > > > en >>
> > > > > >> conceal. : /scenari/visibility.conceal
> > > > > >>>> Le second, c'est la diffusion des messages :
> > > > > >> scenari/send.editorkeyonlyauth
> > > > > >>>>
> > > > > >>>> Merci !
> > > > > >>>>
> > > > > >>>> Selon David Verdin <adresse@cachée>:
> > > > > >>>>
> > > > > >>>>> Bonjour,
> > > > > >>>>>
> > > > > >>>>> Le contenu des scénarios que vous indiquez correspondent à 
> > > > > quels
> > > > > >>>>> fichiers de scénarios ?
> > > > > >>>>> De toute évidence, le scénario "send" utilisé ne contient 
> > > > > pas le texte
> > > > > >>>>> du second bloc de texte que vous indiquez. Sinon, les 
> > > > > messages des
> > > > > >>>>> abonnés seraient modérés.
> > > > > >>>>>
> > > > > >>>>> www.alise.fr a écrit :
> > > > > >>>>>> Bonjour,
> > > > > >>>>>>
> > > > > >>>>>> Nous avons une liste avec 1000 abonnés, dont le status est 
> > > > > défini sur
> > > > > >>>>>> "conceal" (liste cachée sauf aux abonnés).
> > > > > >>>>>> Scénario : is_owner([listname],[sender])            
> > > > > smtp,smime,md5
> > > > > >>>>  -> do_it
> > > > > >>>>>> is_editor([listname],[sender])            smtp,smime,md5    
> > > > > -> do_it
> > > > > >>>>>> is_subscriber([listname],[sender])  smtp,smime,md5    -> do_it
> > > > > >>>>>> true()                                    smtp,md5,smime -> 
> > > > > reject
> > > > > >>>>>>
> > > > > >>>>>> Nous sommes en modérés, avec confirmation du modérateur : >>
> > > > > >>>> is_editor([listname],[sender])                       md5,smime
> > > > > >> >>   -> do_it
> > > > > >>>>>> is_editor([listname],[sender])                       smtp
> > > > > >>>>     -> request_auth
> > > > > >>>>>> true()                                               
> > > > > smtp,smime,md5
> > > > > >>>>       -> editorkey
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>>>>> Malgré cela, quand des membres de la liste postent des 
> > > > > messages, ils ne
> > > > > >>>>>> passent pas par la case du modérateur.
> > > > > >>>>>> J'ai l'impression que les messages passent quand c'est une 
> > > > > réponse à un
> > > > > >>>>>> message déjà validé.
> > > > > >>>>>>
> > > > > >>>>>> Je voudrais que tout message soit modéré.
> > > > > >>>>>>
> > > > > >>>>>> Merci d'avance
> > > > > >>>>>>
> > > > > >>>>>
> > > > > >>>>> --
> > > > > >>>>> David Verdin
> > > > > >>>>> Comité réseau des universités
> > > > > >>>>
> > > > > >>>
> > > > > >>> --
> > > > > >>> David Verdin
> > > > > >>> Comité réseau des universités
> > > > > >>
> > > > > >
> > > > > > --
> > > > > > David Verdin
> > > > > > Comité réseau des universités
> > >
> > > --
> > > *Bertrand Lemaitre *
> > > adresse@cachée <mailto:adresse@cachée>
> > > Ingénieur réseau ESIAL <http://www.esial.fr>
>
> --
> *Bertrand Lemaitre *
> adresse@cachée <mailto:adresse@cachée>
> Ingénieur réseau ESIAL <http://www.esial.fr>

--
David Verdin
Comité réseau des universités