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

[Luc Veillon <adresse@cachée>]

Bonjour,

J'avais posé une question à la liste, le 6 février dernier, concernant
le pb de traitement des DSN émis en cascade des spams utilisant nos
listes comme adresse d'émission.
J'avais promis une synthèse des réponses. J'ai un peu tardé faute de
temps pour compléter les tests.

En résumé :
* l'explication du pb que j'avais rencontré
* le test de BATV
* un aperçu des réponses que j'avais reçues
* la question initialement posée

1/ L'explication du problème
Elle était multiple mais le facteur de ralentissement essentiel était
l'appel à l'antivirus. Après mise en commentaires
#antivirus_path /usr/local/uvscan/uvscan
#antivirus_args --dat /usr/local/uvscan/dat --clean
et relance, le résultat est spectaculaire, la file se purge comme une
chasse d'eau. On constatait juste avant une CPU occupée à 30% et plus
par le processus uvscan, c'est ensuite l'antispam qui occupe la CPU à 8%
seulement :

Il faudrait creuser pour comprendre pourquoi uvscan met autant de temps
à rendre la main à sympa, mais c'est un pb mineur, car l'antispam
effectue lui même un contrôle antivirus sur le courrier. Cet appel était
donc redondant.

D'autres facteurs ont été identifiés :
* un court-circuit de notre antispam ne contrôlait pas tous les chemins
menant au serveur de listes
* la masse de dsn est toujours en cause, mais sans antivirus, postfix
est capable de les traiter au fil de l'eau.

2/ Le test de batv
Peu concluant à ce jour, le batv-proxy.pl que j'ai utilisé
(http://babel.de/batv.html) ne dispose pas de test permettant de valider
sa configuration (ça marche ou ça marche pas), n'est pas très verbeux
(il est censé clore les sessions smtp avec un reject argumenté, mais
seul l'émetteur en aura connaissance : aucun log côté serveur batv) et
le taux de dsn s'accumulant dans la queue de sympa reste toujours élevé
alors qu'il s'agit manifestement de bounce qui sont renvoyés à sympa
alors que le courrier originel ne peut venir de lui.
=> soit je l'ai mal configuré
=> soit cette implémentation ne marche pas bien
=> soit l'association du proxy batv et de nos content-filter est un peu
trop exotique pour lui

3/ Les réponses que j'avais reçues de S. Aumont, P. Garnier et D. Verdin :
* renoncer au bounces n'est pas envisageable pour certains propriétaires
de listes
* le bounce est à sympa ce que le plancton est à la baleine : il peut en
avaler plusieurs milliers par jour avec appétit
* batv est la solution la plus pratique pour éliminer les bounces ne
nous concernant pas
* les appliances antispam récentes ont toutes une option batv
* l'implémentation de cette option (dans le cas cité) a considérablement
réduit la pollution due à ces DSN égarés
* il est nécessaire de concevoir correctement son architecture pour que
tous les serveurs d'émission du domaine partagent à la fois cette option
et le jeu de clé associé : cette complexité (ou le recours à des
sous-traitants pour dissocier les fonctions émission/réception) pourrait
être le seul argument soutenant l'implémentation d'un return-path "batv
compatible" dans sympa lui même.

4/ Ma demande initiale, pour rappel :

Luc Veillon a écrit :
> 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
>
> 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 ?
>
> Merci,
>
>
> ANNEXE
>
> smtpd_recipient_restrictions = dbm:/etc/postfix/access-recipient
>                                 reject_unauth_destination
> unknown_local_recipient_reject_code = 450
> smtpd_sender_restrictions =
>         check_sender_access dbm:/etc/postfix/blacklist-sender
>         check_sender_access dbm:/etc/postfix/access-sender
>         check_sender_access dbm:/etc/postfix/null_sender
>
> header_checks = regexp:/etc/postfix/header_checks
>
> Contenu des fichiers
> ./header_checks :
> /^Content-Type: multipart\/report; report-type=delivery-status\;/      
> REJECT no third-party DSNs
> /^Content-Type: message\/delivery-status; /     REJECT no third-party DSNs
>
> ./access-recipient
> adresse@cachée REJECT
> adresse@cachée       REJECT
>
> ./null_sender
> <>      550 no third-party DSNs
>
> ./access-sender
> MAILER-DAEMON@  REJECT
> MailerDaemon@   REJECT
> abuse@          REJECT
> etc.
>
>
>   


-- 
Luc VEILLON 
RSSI - CMSD - Coord.Technique pôle SAR - DSI

tel.:+33(0)2 38 49 95 95 - Fax :+33(0)2 38 49 95 76
courriel : adresse@cachée
gpg : 0xDC6FF566 - AC signature : http://igc.cru.fr/ac-racine/
site DSI : https://www.ird.fr/dsi

IRD - INSTITUT DE RECHERCHE POUR LE DEVELOPPEMENT
5, rue du carbone
45072 ORLEANS CEDEX 2  
http://www.ird.fr