[gull] Spams, nombreux$

Laurent Franceschetti (SettleNext) laurent.franceschetti at settlenext.com
Mon Apr 12 09:57:02 CEST 2004


> 
> Chez Nimag (petit ISP), nous avons mis un tel système en 
> place et nous 
> avons reçu un nombre de plaintes incroyable car les gens ne 
> recevaient 
> plus les mails de la part de qqn qui était chez un provider xy et qui 
> était blacklisté dans une partie des RBL que nous utilisions.
> 

Merci beaucoup pour le texte instructif. 1 seul "faux positif", et c'est un
problème!



> 
> C'est assez de difficile de tuer le spam à la réception, par 
> contre il 
> faudrait le tuer au niveau de l'émission en mettant en place 
> des proxy 
> SMTP sur les réseau des gros providers qui filtre les virus 
> et les spams 
> quelque soit les adresses sources. (...)
> 
> Personnellement je n'aime pas vraiment que les politiques se 
> mêlent de 
> la technique, ... Mais dans ce cas là il pourrait être intéressant 
> d'obliger de faire du filtrage SMTP en sortie aux providers suisse, 
> européens, voir le monde.
>


C'est probablement juste. Cependant, il serait préférable que la pression
soit technologique ou sociale, plutôt que légale.



> Mais il ne faut pas oublier que c'est aussi le travail de 
> l'utilisateur 
> final de lutter contre le spam en se plaignant au provider source (en 
> général à abuse at provider.com) et en lui envoyant les en-tête 
> du messages 
> et le messages au complet. Si un provider reçoit énormément 
> de plaintes 
> contre l'un de ses client, il prendra normalement les mesures 
> nécessaires et si ce n'est pas le cas, il faut le dénoncer 
> auprès de RBL 
> comme spamcop (http://www.spamcop.net/). 


Oui, c'est le point central: je pense que c'est aussi à l'utilisateur final
de se responsabiliser.
Et pour le moment, c'est plutôt le contraire: souffrir en silence et se
laisser infecter!
Il y a un travail d'éducation à faire.


> Et quand 
> l'utilisateur reçoit 
> un rapport de spam/antivirus de son provider disant qu'il y'a un 
> problème dans le format du message ou qu'il n'y a pas de 
> reverse DNS il 
> faut qu'il avertisse l'expéditeur (si il le connait) qu'il y'a un 
> problème pour qu'il le résolve et pas son provider qui n'est 
> pour rien 
> dans l'oubli/l'incompétence de l'expéditeur (souvent des systèmes 
> automatisés d'envoie de mail, des formulaires web, ...) en face.
> 

Je n'ai pas compris ce point (désolé de mon ignorance!) Est-ce que tu
pourrais le clarifier?
Encore merci.

Salutations,
Laurent




More information about the gull mailing list