Dispositif anti-aspiration d'e-mails

Le
Pascal
Bonjour,

Problème classique, comment empêcher au mieux l'aspiration des adresses e-
mail diffusées sur les pages web.

Il y a quelques réponses connues en javascript, mais je m'intéresse ici
aux solutions simples côté serveur, et PHP en particulier.
L'idée serait de recoder tout ou partie des adresses en fin de traitement
de la page à produire en sortie HTTP.

Quelqu'un a-t-il déjà tenté de transformer simplement le "@" en son
équivalent sous forme d'entité codée, soit "@" ?
Si oui, cela a-t-il suffit pour contraindre le spam ? (car je suis
conscient que le spider peut facilement contourner cela)

PS: la partie de code PHP correspondante est dans mon billet précédent.

--
Cordialement, Pascal.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 3
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Olivier Miakinen
Le #22768001
Bonjour,

Le 06/11/2010 01:03, Pascal a écrit :

Problème classique, comment empêcher au mieux l'aspiration des adresses e-
mail diffusées sur les pages web.

Il y a quelques réponses connues en javascript, mais je m'intéresse ici
aux solutions simples côté serveur, et PHP en particulier.



Tout de suite une remarque : si PHP ne sert qu'à générer une page HTML,
toujours la même, sans aucune interaction de la part du visiteur, alors
il ne sert à rien puisque le résultat sera indiscernable des pages HTML
statiques.

L'idée serait de recoder tout ou partie des adresses en fin de traitement
de la page à produire en sortie HTTP.

Quelqu'un a-t-il déjà tenté de transformer simplement le "@" en son
équivalent sous forme d'entité codée, soit "@" ?



Oui. En tout cas, j'ai déjà vu plusieurs fois dans les news quelqu'un
demander si ça s'était déjà fait... ;-)

Si oui, cela a-t-il suffit pour contraindre le spam ? (car je suis
conscient que le spider peut facilement contourner cela)



Je ne me rappelle pas précisément les réponses, mais j'imagine que ça a
une efficacité limitée.

En revanche, je crois bien que tous ceux qui passaient par un formulaire
(pour forcer une interaction « humaine » avant d'amener à une page
contenant des adresses de courriel) avaient de bons résultats. On est
bien dans le cas où PHP est utile, et cet article est en charte.

Le formulaire pourrait être aussi simple que « saisissez le nombre
123459 dans le champ suivant et cliquez sur Potiron » : même si le
texte à saisir ne change jamais, le spammeur devra programmer son
robot de façon spécifique à ta page pour y accéder, et dans ce cas il
aura plus vite fait de se passer de robot. Du coup, la protection est
la meilleure possible si l'on exclut le fait de ne *pas* mettre
d'adresse du tout.

Cordialement,
--
Olivier Miakinen
Pascal
Le #22774151
Le 07/11/2010 00:06, Olivier Miakinen a écrit :
Tout de suite une remarque : si PHP ne sert qu'à générer une page HTML,
toujours la même, sans aucune interaction de la part du visiteur, alors
il ne sert à rien puisque le résultat sera indiscernable des pages HTML
statiques.



Il y a un lien avec le fil précédent, à savoir que les contenus sont
générés à partir de templates, d'où l'utilisation d'un langage dynamique
côté serveur.
Pour préciser, les adresses mail seront rédigées de façon habituelle
dans les contenus, PHP se chargeant du traitement final avant envoi au
navigateur, dont la réécriture de ces adresses.

Oui. En tout cas, j'ai déjà vu plusieurs fois dans les news quelqu'un
demander si ça s'était déjà fait... ;-)



Il me vient une question très bête : quel est le moyen le plus efficace
pour faire des recherches dans un newsgroup ? Google ou une plateforme
dédiée ?

Le formulaire pourrait être aussi simple que « saisissez le nombre
123459 dans le champ suivant et cliquez sur Potiron » : même si le
texte à saisir ne change jamais, le spammeur devra programmer son
robot de façon spécifique à ta page pour y accéder, et dans ce cas il
aura plus vite fait de se passer de robot. Du coup, la protection est
la meilleure possible si l'on exclut le fait de ne *pas* mettre
d'adresse du tout.



Oui, je vois l'idée, mais je ne cherche pas un moyen de mettre un terme
définitif au spam, seulement à le limiter avec économie.
Il me faut donc un compromis entre la complexité du dispositif,
l'éventuel déficit ergonomique, et l'efficacité de la lutte anti-spam.

Si on doit utiliser un formulaire dans le dispositif, autant ne pas
mentionner de mail et se servir dudit formulaire pour envoyer la
correspondance, par exemple à un contact choisi dans une liste.
Mais cette solution ne convient pas, a priori, dans le cadre des
mentions obligatoires concernant la responsabilité éditoriale de
contenus publiés sur le web.

En tout cas merci pour la contribution, dans l'attente d'autres suggestions.

--
Cordialement,
Pascal
Denis Beauregard
Le #22775221
Le 06 Nov 2010 00:03:39 GMT, Pascal écrivait dans fr.comp.lang.php:

Bonjour,

Problème classique, comment empêcher au mieux l'aspiration des adresses e-
mail diffusées sur les pages web.

Il y a quelques réponses connues en javascript, mais je m'intéresse ici
aux solutions simples côté serveur, et PHP en particulier.
L'idée serait de recoder tout ou partie des adresses en fin de traitement
de la page à produire en sortie HTTP.

Quelqu'un a-t-il déjà tenté de transformer simplement le "@" en son
équivalent sous forme d'entité codée, soit "@" ?
Si oui, cela a-t-il suffit pour contraindre le spam ? (car je suis
conscient que le spider peut facilement contourner cela)



S'il y a plusieurs adresses différentes (comme un blogue), je pense
qu'il est préférable de ne pas afficher du tout l'adresse ou d'avoir
une adresse partielle () ou une image de l'adresse
(vu dans certains sites). Comme le but est d'abord d'afficher un
message et non une adresse, la plupart des visiteurs n'auront pas
besoin de cette adresse. Je dirais que dans ce cas, une image est
appropriée, avec une image de fond pour empêcher un robot d'analyser
ces images, avec un jeu de caractères fixes (courrier) plutôt que
proportionnels (je n'ai pas remarqué dans PHP que l'on pouvait avoir
la longueur d'un texte inscrit dans une image mais je n'ai pas fait
de recherche approfondie et je sais qu'il y a un grand nombre de
librairies en 2010).

Une autre solution, qui n'est pas en charte (donc, à discuter dans
le .auteurs), ce serait de produire une adresse en 3 parties, disons
a = "moi", b = "gmail" et c = "com", et d'avoir un script en
javascript qui fera la fusion, donc donnera a+"@"+b+"."+c. En
théorie, un petit robot (travaillant à petite échelle) peut utiliser
le rendu de Internet Explorer et donc ne ferait pas de distinction
entre cette solution et celle du &#64 puisque dans les deux cas, le
robot verrait cette adresse comme le visiteur. Par contre, un gros
robot n'utilisera pas le javascript et lira directement la page, ce
qui lui permettrait de détecter et corriger un "@" car c'est
une méthode proposée il y a longtemps.

Sur l'ensemble, je dirais que l'image est la meilleure solution
et c'est en charte :-).


Denis
DuboisP
Le #22775211
Le Mon, 08 Nov 2010 23:09:25 +0100, Pascal

Le 07/11/2010 00:06, Olivier Miakinen a écrit :

Pour préciser, les adresses mail seront rédigées de façon habituelle
dans les contenus, PHP se chargeant du traitement final avant envoi au
navigateur, dont la réécriture de ces adresses.

Oui, je vois l'idée, mais je ne cherche pas un moyen de mettre un terme
définitif au spam, seulement à le limiter avec économie.
Il me faut donc un compromis entre la complexité du dispositif,
l'éventuel déficit ergonomique, et l'efficacité de la lutte anti-spam.

En tout cas merci pour la contribution, dans l'attente d'autres
suggestions.




simplement crypter l'adresse, avec une fonction de décalage de caractéres,
ici en Pascal, comme

(**************************************)
Function Crypte( sString : String) : String;
(**************************************)

Var I : Byte;

Begin
For I := 1 To Length( sString) Do
Begin
If Ord( sString[I]) < 127 Then
sString[I] := Chr( Ord( sString[I]) + 127)
Else
sString[I] := Chr( Ord( sString[I]) - 127);
End;
Crypte := sString;
End;


dans le formulaire

<select name="receiver">
<option value="adressemailcryptee">Supervision site Web</option>
</select>
$receiver = $_REQUEST['receiver'];
// en PHP
mail(Crypte("$receiver"),"web : $subject","$content",$entetes);

dans ton cas PHP devra générer quelque chose comme

echo "<option value="Crypte($adresse)">Supervision site Web</option>";

je pense que c'est suffisant
sinon, on peut s'amuser à compliquer la fonction de cryptage


--
Utilisant le client e-mail révolutionnaire d'Opera :
http://www.opera.com/mail/
Olivier Miakinen
Le #22775291
Bonjour Patrickr.

<aparté>
Attention : ton adresse From est correctement signalée comme invalide
(avec le suffixe .invalid) mais il ne *faut* pas mettre la même adresse
invalide dans le Reply-To ! Soit tu as confiance que les spammeurs ne
récupèrent pas le Reply-To et tu y mets ta vraie adresse, soit tu ne
fais même pas confiance au Reply-To et tu ne mets rien.

Donc soit :
From: patrickr.dubois.don'
Reply-To:

soit :
From: patrickr.dubois.don'
(pas de Reply-To)
</aparté>

Le 09/11/2010, DuboisP a écrit :

simplement crypter l'adresse, avec une fonction de décalage de caractéres,
[...]

dans le formulaire

<select name="receiver">
<option value="adressemailcryptee">Supervision site Web</option>
</select>
$receiver = $_REQUEST['receiver'];
// en PHP
mail(Crypte("$receiver"),"web : $subject","$content",$entetes);
[...]



Ok, sauf que Pascal parlait des « adresses e-mail *diffusées* sur les
pages web ». Quitte à ce que l'adresse ne soit pas visible en clair sur
la page web, autant donner un numéro d'index à chaque adresse connue,
auquel cas l'appel à la fonction mail sera du genre :

switch ($_REQUEST['receiver']) {
case '1' : $receiver = ''; break;
case '2' : $receiver = ''; break;
case '3' : $receiver = ''; break;
case '4' : $receiver = ''; break;
default : die('espece de vil spammeur');
}
mail($receiver, ...);

Cordialement,

--
Olivier Miakinen
Pascal
Le #22776441
Le 09/11/2010 15:46, Denis Beauregard a écrit :
Une autre solution, qui n'est pas en charte (donc, à discuter dans
le .auteurs), ce serait de produire une adresse en 3 parties, disons
a = "moi", b = "gmail" et c = "com", et d'avoir un script en
javascript qui fera la fusion, donc donnera a+"@"+b+"."+c. [...]

Sur l'ensemble, je dirais que l'image est la meilleure solution
et c'est en charte :-).



Oui, je connais ces deux solutions que l'on voit sur pas mal de sites.
Ce qui me pousserait à les écarter, c'est la relative dégradation en
terme d'ergonomie : pour le javascript, le fait que l'adresse ne soit
plus visible si désactivé, et pour l'image, le fait que l'adresse ne
soit plus cliquable.

C'est pourquoi je cherche une solution alternative qui m'offrirait un
compromis entre sécurité et ergonomie, sachant que je ne veux pas
éliminer mais seulement limiter le risque de spam.
Donc, a priori, laisser l'adresse visible en clair pour un utilisateur
humain, mais suffisamment "cryptée" dans le codage HTML pour gêner un
spider, qu'elle reste cliquable avec le pseudo-protocole "mailto:", et
que la désactivation de javascript ne ruine pas tout.

Je sais qu'on est limite charte, mais mon idée de départ était
d'utiliser PHP pour retravailler chaque contenu HTML où se trouve une
adresse mail afin de la crypter (le terme est peut être un peu fort,
d'ailleurs).

Merci pour la contribution.

--
Cordialement,
Pascal
Pascal
Le #22777751
Le 09/11/2010 16:45, Olivier Miakinen a écrit :
Ok, sauf que Pascal parlait des « adresses e-mail *diffusées* sur les
pages web ». Quitte à ce que l'adresse ne soit pas visible en clair sur
la page web, autant donner un numéro d'index à chaque adresse connue [...]



Exact et, bien sûr, j'ai envisagé cette solution qui élimine totalement
le risque de spam par aspiration.

Mais il y a des cas où la mention d'une adresse mail correspond, si ce
n'est à une obligation légale, du moins à une information rassurante au
même titre qu'un numéro de téléphone ou une adresse physique.
C'est tout le sens, je crois, de la LCEN
[http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000000801164].
Et pardon si ceci est limite charte ! ;-)

Je reste donc avec le problème de savoir comment *mentionner* une
adresse mail, tout en *gênant* au mieux les aspirateurs, mais sans
*sacrifier* l'ergonomie de base (clic avec "mailto:").
L'équation impossible, quoi !!!

--
Cordialement,
Pascal
Thierry
Le #22777921
Pascal news:ibcih3$k8t$:

Le 09/11/2010 16:45, Olivier Miakinen a écrit :
Ok, sauf que Pascal parlait des « adresses e-mail *diffusées* sur les
pages web ». Quitte à ce que l'adresse ne soit pas visible en clair
sur la page web, autant donner un numéro d'index à chaque adresse
connue [...]



Exact et, bien sûr, j'ai envisagé cette solution qui élimine
totalement le risque de spam par aspiration.

Mais il y a des cas où la mention d'une adresse mail correspond, si ce
n'est à une obligation légale, du moins à une information rassurante
au même titre qu'un numéro de téléphone ou une adresse physique.
C'est tout le sens, je crois, de la LCEN
[http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT00000080
1164]. Et pardon si ceci est limite charte ! ;-)

Je reste donc avec le problème de savoir comment *mentionner* une
adresse mail, tout en *gênant* au mieux les aspirateurs, mais sans
*sacrifier* l'ergonomie de base (clic avec "mailto:").
L'équation impossible, quoi !!!



J'ai un script qui traine dont voici l'essence:

function hex_encode($str)
{
$encoded = bin2hex($str);
$encoded = chunk_split($encoded, 2, '%');
$encoded = '%'.substr($encoded, 0, strlen($encoded) - 1);
return $encoded;
}

$email = "";
switch ($_GET["id"])
{
case 1: $email = ""; break;
}
if ($email != "")
header("Location: mailto:".hex_encode($email));


Je ne sais pas si c'est vraiment efficace, mais j'espere qu'il y a
tellement d'email a recupere en clair pour que les robots s'amusent a
decoder les headers.
Pascal
Le #22781111
On 10 nov, 14:15, Thierry
J'ai un script qui traine dont voici l'essence:


[...]
        header("Location: mailto:".hex_encode($email));



Je sais pas si je comprends bien le principe, mais j'ai l'impression
qu'il s'agit :

1- à partir d'un lien HTML incluant une variable "id"
2- de pointer vers ce script qui prend la valeur de "id"
3- qui trouve la valeur correspondante de l'adresse mail (ici avec un
switch, mais ça pourrait être dans un tableau ou une base de données)
4- qui convertit l'adresse mail en quelque chose de moins lisible
5- qui rajoute le préfice "mailto:" et renvoie le tout sous forme
d'entête HTTP
6- qui elle-même redirige le navigateur vers cette supposée URL
7- ce qui est censé ouvrir le gestionnaire de mail local.

Bon, ok, mais la fonction "hex-encode()" donne quoi en résultat, parce
que j'ai un peu de mal à l'interpréter ?
D'ailleurs je ne savais pas qu'une entête pouvait être encodée.

Cela dit, il n'y a que l'URL du lien qui masque l'adresse, pas le
contenu textuel du lien, n'est-ce pas ?
Par exemple, ça donnerait, dans le code de la page affichée :

Hmmm, ça pourrait le faire. Il faut que j'en sache plus sur cet
encodage
qui me trouble un peu.
Tous les navigateurs comprennent cette entête trafiquée ?

Merci pour la contribution.

Cordialement,
Pascal
jcs
Le #22781121
Pascal a écrit :
Le 09/11/2010 16:45, Olivier Miakinen a écrit :
Ok, sauf que Pascal parlait des « adresses e-mail *diffusées* sur les
pages web ». Quitte à ce que l'adresse ne soit pas visible en clair sur
la page web, autant donner un numéro d'index à chaque adresse connue
[...]





......

Je reste donc avec le problème de savoir comment *mentionner* une
adresse mail, tout en *gênant* au mieux les aspirateurs, mais sans
*sacrifier* l'ergonomie de base (clic avec "mailto:").
L'équation impossible, quoi !!!



Tu peux tjs mettre une adresse dans le style ou
. Ton logiciel doit permettre de transformer cet alias
en adresse effective. Réminiscence de mes années Netscape!
Publicité
Poster une réponse
Anonyme