Accéder au contenu.
Menu Sympa

fr - Re: [sympa-fr] Quels retours sur la lutte anti-spam, version filtrage

Objet : Pour les administrateurs de serveurs de listes utilisant le logiciel Sympa

Archives de la liste

Chronologique Discussions  
  • 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'abonnement
  
    
J'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



Archives gérées par MHonArc 2.6.19+.

Haut de le page