Re: [sympa-fr] rapport d'avalanche

[Robert Marchand <adresse@cachée>]

Bonjour,

      en fait mon premier essai était avec la règle suivante:

match([header->Sender],/Postmaster/)           smtp             -> 
request_auth

Cela a donné une avalanche au niveau des commandes et rapports de commande 
plutôt qu'à la liste.  Selon un collaborateur il y aurait un risque que la 
réponse de l'avis de vacance soit acceptée parce que la commande est 
recopiée dans le sujet.

Je préfère donc le 'reject'.  J'aime bien l'idée d'un mécanisme identique à 
celui des messages (numéro 5).  Cela permettrait de limiter les dégats.

Merci.

At 17:31 26-06-2002 +0200, Olivier Salaun wrote:
> Bonjour,
>
> Robert Marchand wrote:
>
> > une de nos liste est partie en boucle après avoir reçu 2 avis de
> > vacances différents mais provenant d'un même type de serveur (Novell).  Il
> > s'agit d'une liste privée non modérée avec reply-to à la
> > liste.  Malheureusement, c'est aussi une liste à haute visibilité de plus
> > de 800 abonnés.  Avant que le propriétaire de la liste désabonne les deux
> > adresses fautives, plus de 1500 messages ont été envoyés à cette
> > liste.  Évidemment le tout s'est passé dans la nuit du 23 au 24 juin (un
> > congé férié chez nous).  Nous aimerions éviter que cela se reproduise.
>
> Sympa dispose de plusieurs systèmes de détection de boucles (quoi que dans
> ton cas il ne s'agisse pas vraiment d'une boucle mais de harcellement) :
>         1/ détection des champs X-Loop
>         2/ détection de certains champs d'entête positionnés par des 
> automates
>         3/ rejet des messages dont le From: est supect 
> (postmaster,mailer-daemon,
>            sympa,...)
>         4/ rejet des messages dont le Message-ID est connu
>         5/ non-réponse au messages de commande d'une même personne, lorsque
>           un seuil max est dépassé (voir les paramètres 
> loop_command_sampling_delay,
>           loop_command_max et loop_command_decrease_factor)
>
> Dans ton cas, Sympa aurait pu bloquer les messages si :
>         * il avait recherché (3) dans le champ Sender
>         * (5) était appliqué aux messages
>
> > Je reproduis ici un des avis de vacance:
> > [...]
> > La faute semble être du côté du serveur Novell qui a continué à renvoyer
> > des avis de vacances.  Cependant, ne peut-on se prémunir contre ce genre de
> > situation?  Même en utilisant un envoi avec authentification, le problème
> > ne serait pas complètement évité.
>
> A priori ça éviterai le pb, puisque le répondeur ne confirmera pas les 
> messages.
> Seul risque : saturer le spool 'auth' de Sympa.
>
> > Pour l'instant, j'ai ajouté la ligne suivante aux scénarion 
> send.private et send.privatekey:
> >
> > match([header->Sender],/Postmaster/)           smtp             -> reject
> >
> > D'autres suggestions?
>
> Tu peux ajouter cette règle dans ~sympa/etc/scenario/include.send.header
> Ainsi il sera appliqué à toutes tes listes.
>
> Cordialement.
>
> --
> Olivier Salaün
> Comité Réseau des Universités

-------
Robert Marchand                 tél: 343-6111 poste 5210
DGTIC-SIT                       e-mail: adresse@cachée
Université de Montréal          Montréal, Canada