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

[Serge Aumont <adresse@cachée>]

Bonjour Luc

Merci pour ton excellente synthèse sur cette question. je voudrais y
ajouter la remarque suivante : si le VERP est utilisé systématiquement,
il devient très facile de rejeter les DSN qui ne sont pas relatifs à un
message émis par le serveur de liste. VERP serait alors utilisé comme un
BATV du pauvre.

Nous ressentons de plus en plus le besoin de personnaliser 100% des 
messages avec un lien de désabonnement autosuffisant (c'est à dire de
demandant aucune info supplémentaire à la personne qui veut se
désabonner). Ce besoin est bien entendu lié à l'intolérance grandissante
des abonnés vis à vis du spam.

Du coup, le groupage si joliment optimisé depuis la toute première
version de Sympa (merci à Christophe Wolfhugel) est un atout du passé.
Fort heureusement, la puissance des réseaux et des serveurs actuels
permet avec l'architecture de la version 6 de diffuser de grosses listes
de diffusion sans cette optimisation. La personnalisation des messages
devient possible, elle sera activable liste par liste très prochainement
(c'est l'objet du travail de Julien Jourdan en stage chez nous).

L'application du VERP à 100% des abonnés n'est plus dans ces conditions
très pénalisante.

Toujours au sujet du traitement des DSN mais aussi des rapport de remise
et de lecture, je signale que certains utilisateurs de Sympa travaillent
pour associer les DSN non seulement à un abonné d'une liste mais aussi à
chaque message diffusé de sorte qu'il soit possible, pour chaque message
d'afficher la liste des personnes qui ne l'ont pas reçu  ou qui ont
attesté l'avoir reçu.

Serge Aumont

Luc Veillon wrote:
> 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.
>>
>>
>>   
>>     
>
>
>