Objet : Pour les administrateurs de serveurs de listes utilisant le logiciel Sympa
Archives de la liste
Re: [sympa-fr] Quels retours sur la lutte anti-spam, version filtrage
- From: David Verdin <adresse@cachée>
- To: Serge Aumont <adresse@cachée>
- Cc: Luc Veillon <adresse@cachée>, "Liste, sympa-fr" <adresse@cachée>
- Subject: Re: [sympa-fr] Quels retours sur la lutte anti-spam, version filtrage
- Date: Fri, 06 Feb 2009 13:53:58 +0100
Serge sous-estime notre œuvre. ;) Plusieurs milliers de bounces par jour ? Franchement, le démon bounced.pl de Sympa peut sans broncher consommer plusieurs milliers de bounce par jour. Votre serveur devrait à peine les sentir passer. Vous avez constaté des ralentissements dûs à ces rapports ? Cordialement, Serge Aumont a écrit : adresse@cachée">Luc Veillon wrote:Bonjour, Nous sommes tous la cible indirect de spam massif via les DSN qui nous sont envoyés lorsque nos domaines sont utilisés comme sources usurpées. Notre serveur sympa doit désormais plusieurs milliers de courriers de ce type chaque jour, qui traversent l'antispam sans difficulté. Je teste plusieurs options assez radicales visant à éliminer les DSN, par leur domaines et adresses émetteurs ou par un header spécifique (voir plus bas pour ceux qui ont envie d'en discuter) L'effet de bord, signalé par Serge lors d'une discussion informelle, sera évidemment l'incapacité du bounced de sympa à traiter correctement les erreurs d'abonnementJ'ai la conviction que seul BATV peut régler ce pb (Bounce Address Tag Validation) Voir : http://en.wikipedia.org/wiki/Bounce_Address_Tag_Validation Le principe est un peu similaire au VERP (variable Envelopp Return Path), il consiste à modifier le return path des messages sortants pour exploiter le RCPT To enveloppe quand on reçoit des bounces. On peut alors éliminer ceux qui ne porte pas la marque apposée en sortie car ceux-là correspondent à du spoofing d'adresses email. cela suppose que 100% des messages sortant passent par le moteur de modification des Return-path : J'ai un peu tendance à penser que c'est une problématique qui doit être gérée par les MTAs et non par le serveur de liste (il existe d'ailleur un milter BATV). Cependant les architectures deviennant complexes, il peut devenir utile au sein de Sympa de postionner des Return-path: exploitable par un MTA utilisant BATV en réception car il est peut être inutile de filtrer le traffic sortant du serveuir de listes. ce serait le cas par exemple si vous "outsourcez" chez votre ISP le filtrage antispam, antivirus et BATV des messages entrants mais pas le filtrage des messages sortant. Je suis engagé dans un projet pour lequel je teste de multiples appliances antispam, je constate que toutes ou presque offre du BATV. Je pense que BATV sera requis dans le CCTP sur lequel devrait déboucher ce travail.D'où mes questions : 1/ Qui utilise déjà ces options (répondez moi directement, je ferai une synthèse) ? 2/ Dans ce cas, la perte d'information pour le bounce vous a t-elle été reprochée par vos utilisateurs ?Il y a des listes pour lesquels il serait utile d'avoir pour chaque message, la liste des abonnés qui ont généré un bounce, voir même de positionner un Return-Receipt: pour collectionner les preuves de distribution des messages. Ce ne serait pas anormal pour les listes de RSSI. D'autres utilisateurs de Sympa nous ont confié avoir de tels besoins et même voulant aller encore plus loin dans la tracabilité des messages dans le cadre d'une messagerie de commandement si j'ai bien compris. Pour eux, pas question de perdre un bounce ! Serge Aumont -- David Verdin Comité réseau des universités |
-
[sympa-fr] Quels retours sur la lutte anti-spam, version filtrage des DSN abusifs ?,
Luc Veillon, 06/02/2009
-
Re: [sympa-fr] Quels retours sur la lutte anti-spam, version filtrage,
Serge Aumont, 06/02/2009
- Re: [sympa-fr] Quels retours sur la lutte anti-spam, version filtrage, David Verdin, 06/02/2009
-
Re: [sympa-fr] Quels retours sur la lutte anti-spam, version filtrage,
Serge Aumont, 06/02/2009
Archives gérées par MHonArc 2.6.19+.