Re: [sympa-fr] SPAM sur listes en intranet

[LALOT Dominique <adresse@cachée>]

Lucien GENTIS a écrit :
> Serge Aumont a écrit :
> > Jean-Hugues BELPOIS wrote:
> > > Bonjour,
> > >
> > > On parlait de spam il y a quelques temps sur cette liste, et des 
> > > abonnés (étudiants) nous font remonter que certaines listes 
> > > justement sont spammées.
> > > Ce qui est un peu retors, c'est que toutes les listes d'étudiants 
> > > sont en mode "intranet", donc sympa rejette tout ceux qui tentent 
> > > d'y écrire et ne sont pas de notre domaine (@univ-brest.fr). Mais 
> > > les spammeurs se forgent une adresse bidon fonction de ce domaine, 
> > > ex : adresse@cachée, et donc ne sont pas rejetés.
> > >
> > > Voyez vous une autre solution que de passer ces listes en "privée", 
> > > ce qui va malheureusement empêcher les scolarités et enseignants d'y 
> > > publier ?
> > Il y a pas d'autres solutions, toutes imparfaites. Si la partie 
> > domaine seulement est usurpées, mais pas  la partie locale, il est 
> > possible de faire un scénario qui vérifie  que l'adresse du sender 
> > est dans votre annuaire (ldap) ou présente dans la table subscribers 
> > de sympa (abonné à au moins une liste) voir  
> > :http://www.sympa.org/manual/authorization-scenarios#named_filters
> >
> >
> > Mettre un bon anti-spam en amont du serveur de listes et inclure dans 
> > le scenario send un test des entêtes ajoutées par ce filtre semble 
> > aussi une bonne optique.
> >
> > Pourquoi pas faire les 2.
> >
> > Serge
> >
> > ps : éviter d'utiliser des scénario qui retourne request_auth (sympa 
> > demande au sender du message de confirmer qu'il en est l'auteur). En 
> > effet, cela fait de votre serveur de listes un "backscatter" et cela 
> > vous conduira à être blacklisté un jour. 
> > http://en.wikipedia.org/wiki/Backscatter_(e-mail)
> Bonjour,
>
> Je réponds au postscriptum de Serge :
>
> Je pense que le problème de "backscatting" ne se pose pas dans le cas 
> de Jean-Hugues, car soit le domaine de l'émetteur ne fait pas partie 
> de l'intranet et le message sera rejeté, soit il fait partie de 
> l'intranet et le message de confirmation ne sortira pas du domaine.
>
> Par contre, d'une manière générale, je trouve qu'il est dommage de ne 
> pas utiliser ce type de scénario qui demande une confirmation à 
> l'expéditeur. C'est à mon avis une parade efficace car seul le vrai 
> propriétaire de l'adresse électronique expéditrice est censé pouvoir 
> ouvrir sa boîte de réception.
>
> Le risque de passer pour un "backscatter" n'existe, je pense, que dans 
> le cas où on renvoie le spam d'origine à une adresse extérieure 
> usurpée ; pourquoi dans ce cas ne pas simplement configurer Sympa de 
> manière à ne pas joindre le message d'origine au message de 
> confirmation ? (idem pour les messages de rejet)
>
> Il suffit de modifier un peu le texte du message de confirmation dans 
> le style "Vous venez d'envoyer un message à la liste . . . . . . . . . 
> . Pour le diffuser, suivez le lien ci-dessous". L'expéditeur est censé 
> savoir ce qu'il a envoyé à la liste et il n'est pas nécessaire de le 
> lui rappeler (au pire, il peut vérifier son message dans sa boîte 
> d'envoi).
Oui mais si quelqu'un a usurpé au même moment.., il serait bon de savoir 
ce qu'il va valider. On peut aussi penser aux fausses manip, plusieurs 
mails envoyés et tu ne sais plus trop lequel. Tu veux te raviser, mais 
tu ne sais plus. Pb sur sympa et message débloqué longtemps après..
Une solution serait de lui envoyer un lien html vers le message à 
valider. Ainsi dans la demande de confirmation, tu ne renverrais jamais 
un SPAM

Mais bon, probablement plus facile à dire qu'à faire, et tout le monde 
n'utilise pas wwsympa. Ceci dit, ça pourrait être un option de 
configuration?

Dom
> Lucien

--
Dominique LALOT
Ingenieur Systeme et Reseaux
http://annuaire.univmed.fr/showuser.php?uid=lalot