SPAM : comment ça marche ?

Répondre


Cette question est un moyen d’empêcher des soumissions automatisées de formulaires par des robots.
Smileys
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen: =D> #-o =P~ :^o :non: :priere: 8-|
Voir plus de smileys
  Revue du sujet
 

  Étendre la vue Revue du sujet : SPAM : comment ça marche ?

par Vurtu » 18 août 2008, 10:51

sinon il y a les adresses jetable.net pour les amis spammeurs

par hakazizi » 02 août 2008, 13:57

moi j'ai deux adresse mail une qui est our les spammeur e l'autre est reele tres proche elle n'ont qu'une seul lettre qui les separe.
quand je doi laissaer mon adresse mail .
je procede comme suit
cela n'est qu'un exemple
je laisse
[email protected]
ensuite je di de retirer le e entre mon et mail
ce qui donne
[email protected]
et sa fonctionne plutot bien.
attention cepandant l faut etre detenteur des deux adresse mail pour eviter que quelqu'un ne soit victime de spam a cause de vous.
de temps en temps je vide la boite que je donne en pature au spammeur ce qui fonctionne tres bien.
un peu archaique certe mais rudement efficace

par Victor BRITO » 22 juil. 2008, 00:02

Juste un petit bémol : unicode-bidi est supporté par Safari :P.
Tant mieux. :)

par Hywan » 21 juil. 2008, 23:41

Ok, c'est ce que je pensais.

Juste un petit bémol : unicode-bidi est supporté par Safari :P. [5 minutes plus tard] Plutôt que de faire des tests, j'ai retrouvé ceux d'Eric Meyer : CSS2 Test Suite: 9.10 unicode-bidi. J'ai refais tout de même des tests, et ça marche. Dommage que je n'ai pas conservé la version 2.x de Webkit … En tout cas, pour la version 3.1.x et supérieure, c'est tout bon de sûr (et même pour 3.0 si je n'abuse :)).

par Victor BRITO » 21 juil. 2008, 21:53

Je me questionne un peu sur l'accessibilité de la première méthode avec le CSS direction qui est changé. Victor, un indice ?
En ce qui concerne la première méthode, les propriétés direction et unicode-bidi sont implémentées par les navigateurs les plus courants (pour IE 6 et 7, le seul bémol est l'absence de prise en charge de la valeur inherit pour unicode-bidi ; autre bémol : unicode-bidi n'est pas reconnue par Safari).

En ce qui concerne la deuxième (emploi de display: none), elle marchera aussi sur bon nombre de synthèses vocales (qui comprennent les CSS).

Mais, indépendamment de l'implémentation des CSS dans les navigateurs les plus courants (et donc du résultat à l'affichage pour les humains), je reste circonspect à ce sujet (malgré le graphique posté sur le lien indiqué). Si jamais le robot spammeur connaît les CSS et comprend parfaitement les propriétés suscitées, ces deux méthodes ne servent à rien. Dans le cas inverse (et le plus probable, même s'il ne faut jamais dire que le premier est impossible), vu les exemples de code source fournis, ledit robot ne s'arrachera pas trop les cheveux pour tenter de reconstituer (quitte à obtenir une adresse bidon s'il est moins futé) l'adresse e-mail. Et puis, derrière un robot spammeur, il y a forcément un humain pour le mettre au point et l'améliorer.

Bref, si je n'étais pas parano, j'essaierais ta méthode, HyWaN. ;)

par Hywan » 21 juil. 2008, 11:32

Hey :),

Je remonte le sujet avec ce lien : Nine ways to obfuscate e-mail addresses compared. L'auteur présentente 9 techniques pour éviter le spam. C'est plutôt intéressant.

Je me questionne un peu sur l'accessibilité de la première méthode avec le CSS direction qui est changé. Victor, un indice ? Dès le moment où CSS est désactivé, c'est un peu la galère … Normalement, le support CSS est disponible sur la plupart des outils, mais il faudrait que je refasse des recherches.

par Hywan » 18 juil. 2008, 09:45

En général, le robot ne suit pas le lien car il n'estime pas que c'est un lien qui contient un email (on n'utilise pas la variable $_GET['mail'], on peut avec $_GET['toto']).
Et on peut coupler ça à un système de session, ou un truc du genre.

Comme on centralise aussi l'envoie des mails, on peut placer un script qui s'occupe de vérifier si on a à faire à un robot ou pas.

Ah oui, j'ai oublié de dire ce que j'utilisais sur Hoa. Là c'est marrant en fait, je donne mon prénom et mon nom, et je dis que l'adresse e-mail est de la forme : prénom.nom@hoa-project.net. C'est à l'utilisateur de faire la manipulation, mais ça marche bien ;-).

par Sékiltoyai » 18 juil. 2008, 01:37

Euh, mais le robot reçoit le header aussi, qu'est ce qui l'empèche d'utiliser directement cela ?

par Hywan » 17 juil. 2008, 23:23

Je ne voulais pas m'étaler sur le sujet, plus par flemme je l'avoue, mais bon … Ce soir, je me sens l'âme charitable alors voici comment je procède (et ça n'a encore jamais été cracké par un robot).

Bon, accroché vos ceintures :
on « encode » notre adresse e-mail avec un petit script perso. J'ai pour habitude de prendre une valeur aléatoire, puis je décale tous les caractères vers la droite de cette valeur aléatoire. Pour cela, je récupère la valeur ASCII d'un caractère, je lui ajoute une valeur, et je récupère le caractère. Ceci sur chaque caractère qui compose notre adresse email. Ensuite, on place la valeur quelque part dans la chaîne, un endroit que nous serons le seul à connaître. On encode la chaîne avec urlencode (ou un petit base64 avant, c'est au choix ;-)), et on obtient notre adresse email codée.
Maintenant, il suffit de faire un lien vers une page qui va prendre en paramètre notre adresse codée : http://domain.tld/page.php?mail=<address>.
Cette page va recevoir ce paramètre donc. Elle va décoder l'adresse email (on récupère le grain de sel, on décale les caractères vers la gauche, talaa), et on va envoyer une en-tête au navigateur :
header('Refresh: 0; url="mailto:' . $address . '"');
Cela aura pour effet d'ouvrir l'outil de messagerie sur le poste client, avec l'adresse email pré-remplie. On peut ajouter des variables hein, rien ne nous l'interdit.

Le robot ne sait pas décrypter l'adresse email, c'est impossible pour lui. Il ne connaît pas l'emplacement du grain de sel et ne connaît pas non plus la technique et le nombre d'encodage intermédiaire utilisé (urlencode(), base64_encode(), serialize(), et même pourquoi pas gzdeflate() :P). En plus, l'adresse n'apparaît pas en clair dans le code HTML, elle apparaît encodée. Pour le texte du lien, on peut remplacer l'arobase (@) par <em>chez</em> par exemple, ou mettre un texte du genre : nous contacter.

Je n'ai pas encore éprouvé cette technique à l'accessibilité, mais normalement, ça ne devrait pas poser de problème. Ça évite le SPAM, et c'est simple à mettre en place. En plus, ça permet de centraliser les demandes de mail, c'est pas plus mal.

par Victor BRITO » 16 juil. 2008, 23:05

En ce qui concerne les entités HTML, il est de moins en moins exclu que de plus en plus de robots spammeurs sachent les lire. Et quand je parle des entités HTML, je veux dire aussi qu'il faut y ajouter tout moyen de coder les caractères, y compris sous des formes comme courriel%40exemple.com.

Quant à la solution d'enfermer l'adresse électronique dans une image, c'est une fausse bonne idée, comme les captchas en image : à force de sophistication pour déjouer les robots spammeurs les plus "lettrés", on finit par pondre quelque chose de moins en moins accessible à certaines catégories d'utilisateurs, comme les aveugles. Et puis, pourquoi afficher du texte sous forme d'image quand on peut le faire en dur dans le code HTML ? Et je ne parle pas des solutions basées sur JavaScript, qui poseront problème à quiconque surfe sans que ce langage soit activé, voire pris en charge.

Bref, la solution la plus simple (et, sans doute, la plus efficace) est, comme il a été dit plus haut, de ne jamais afficher l'adresse électronique, sous quelque forme que ce soit. Autrement dit, remplacer les liens mailto:[email protected] par un formulaire de contact en PHP, qu'on prendra soin de verrouiller suffisamment pour éviter qu'il ne devient un serveur de spam à coup d'injections d'en-têtes (le lien date, certes, du temps où Cyrano demandait l'indulgence pour son apprentissage ; mais, il est toujours d'actualité ;) ).

par dunbar » 15 juil. 2008, 20:05

Ouais t'as raison ^^ c'est trop facile à faire le copié/collé ^^

http://fr.wikipedia.org/wiki/Pourriel :lol:
:wink:

par chrislabricole » 15 juil. 2008, 18:00

Ouais t'as raison ^^ c'est trop facile à faire le copié/collé ^^

http://fr.wikipedia.org/wiki/Pourriel :lol:

par dunbar » 15 juil. 2008, 16:31

et le SPAM dans tout ça ? |(X


=;
Le pourriel ou le spam (anglicisme) désigne une communication électronique, notamment du courrier électronique, non sollicitée par les destinataires, expédiée en masse à des fins publicitaires ou malhonnêtes. Le terme polluriel est, plus rarement, utilisé pour désigner le pourriel.

Oui bon ok je sort :arrow:

par Vurtu » 15 juil. 2008, 14:11

Pour en revenir à tes moutons ...

Le spam c'est simple : des personnes s'amusent à récupérer des adresse mail pour envoyer de la pub dessus (je ne vous apprend pas grand chose là je pense ...)

Après pour récupérer ces adresses mails, ils ont plusieurs solutions.
La plus courante est de passer par un robot qui crawle tous les sites, examines le contenu de toutes les pages (code source), et récupère tout ce qui est une adresse mail, ou y ressemble de près ou de loin ...
=> la solution, mettre son adresse mail dans une image

Certains spammeurs rachètent des bases de données à certains sites.
=> la solution, utiliser une adresse jetable quand on s'inscrit sur un site (jetable.net)

Il y a aussi le principe du robot qui vient remplir les formulaires de contact disponibles sur les sites
=> la solution, placer des capcha (l'image avec un texte à recopier) sur tous vos formulaires


L'autre solution, est d'avoir une adresse mail avec un bon antispam :)

par TiFred » 15 juil. 2008, 13:59

et le SPAM dans tout ça ? |(X


=;
Oui merci car cela ne fait pas avancer le schmilblick !