Cacher l'adresse e-mail des robots - Garder mailto :

Question

Tl;dr

Cachez l'adresse électronique des robots sans utiliser de scripts et maintenez-la. mailto: fonctionnalité. La méthode doit également prendre en charge les lecteurs d'écran.

---

Résumé

• Courriel : obfuscation sans en utilisant scripts ou les formulaires de contact

• L'adresse électronique doit être complètement visible aux téléspectateurs humains et maintenir mailto: fonctionnalité

• Adresse électronique ne doit pas être sous forme d'image .

• Adresse électronique doit être "complètement" caché des robots spammeurs et des spam-bots. y tout autre type de moissonneuse

---

Effet désiré :

• Aucun script s'il vous plaît. Il n'y a pas de scripts utilisés dans le projet. J'aimerais que ça reste comme ça. .

• L'adresse électronique est soit affiché sur la page ou peuvent être facilement affichés après une certaine forme d'interaction avec l'utilisateur, comme l'ouverture d'une modale.

• El l'utilisateur peut cliquer sur l'adresse e-mail qui, à son tour, déclencherait le mailto: fonctionnalité.

• En cliquant sur l'e-mail, l'application de messagerie de l'utilisateur s'ouvre.

  En d'autres termes, mailto: La fonctionnalité doit fonctionner.

• L'adresse électronique n'est pas visible ou n'est pas identifiée comme une adresse électronique par les robots. (Cela inclut la source de la page)

• Je n'ai pas de boîte de réception pleine de spam.

---

Qu'est-ce que NO Travail

• Ajout d'un formulaire de contact - ou de tout autre élément similaire - à la place de l'adresse électronique

  Je déteste les formulaires de contact . Je remplis rarement un formulaire de contact. S'il n'y a pas d'adresse électronique, je cherche un numéro de téléphone, et s'il n'y en a pas, je commence à chercher un autre service. Je ne remplirai un formulaire de contact que si j'y suis absolument obligé.

• Remplacement de l'adresse par une image de l'adresse

  Cela crée un ÉNORME désavantage pour une personne utilisant un lecteur d'écran ( s'il vous plaît, n'oubliez pas les déf déficients visuels dans vos futurs projets )

  Il a également supprime le site mailto: à moins que vous ne rendiez l'image cliquable et que vous n'ajoutiez ensuite la fonction mailto: comme la href pour le lien, mais que va à l'encontre du but recherché et maintenant l'email est visible pour les robots.

---

Ce qui pourrait marcher :

• Utilisation intelligente de pseudo-elements en CSS

• Les solutions qui font appel à base64 codage

• La rupture l'adresse électronique et répartir les éléments dans le document, puis les rassembler dans une modale lorsque l'utilisateur clique sur un bouton. CSS et l'utilisation de anchor tags )

• Alterting html attributs via CSS

  @MortezaAsadi a gracieusement évoqué cette possibilité dans les commentaires ci-dessous. Voici le lien vers l'article complet - L'article date de 2012 :

  Et si nous pouvions utiliser les CSS pour modifier les attributs HTML ?

• D'autres solutions créatives qui dépassent le cadre de mes connaissances.

---

Questions similaires / Corrections

• JavaScript : Protégez votre adresse e-mail par Joe Maller

(Il s'agit d'un excellent correctif suggéré par Joe Maller, il fonctionne bien mais il est Basé sur script . Voici à quoi ça ressemble ;

<SCRIPT TYPE="text/javascript">

  emailE = 'emailserver.com'

  emailE = ('yourname' + '@' + emailE)

  document.write('<A href="mailto:' + emailE + '">' + emailE + '</a>')

</script>

<NOSCRIPT>

  Email address protected by JavaScript

</NOSCRIPT>

• Recherche d'une fonction d'obfuscation d'adresse électronique en php uniquement

  (Une solution astucieuse utilisant à la fois PHP y CSS au premier inverser l'email en utilisant PHP alors l'inverser de retour avec CSS) Une solution très prometteuse qui fonctionne bien ! Mais c'est trop facile à résoudre .

• Cela vaut-il la peine d'obscurcir les adresses électroniques sur le web de nos jours ?

  (correction Javascript)

• La meilleure façon d'obscurcir une adresse électronique sur un site web ?

  La réponse sélectionnée fonctionne . En fait, cela fonctionne très bien. Il s'agit de coder l'email en tant que html entities . Peut-on l'améliorer ?

  Voilà à quoi ça ressemble ;

  <A HREF="mailto:
  
  &#121;&#111;&#117;&#114;&#110;&#097;&#109;&#101;&#064;&#100;&#111;&#109;&#097;&#105;&#110;&#046;&#099;&#111;&#109;">
  
  &#121;&#111;&#117;&#114;&#110;&#097;&#109;&#101;&#064;&#100;&#111;&#109;&#097;&#105;&#110;&#046;&#099;&#111;&#109;
  
  </A>

• L'obscurcissement des adresses électroniques fonctionne-t-il vraiment ?

  (La réponse sélectionnée à cette question de SuperUser est excellente et présente une étude de la quantité de spam reçue en utilisant différentes méthodes d'obfuscation.

  Il semble que la manipulation de l'adresse e-mail avec CSS pour le faire rtl fonctionne. Il s'agit de la même méthode que celle utilisée dans la première question à laquelle j'ai fait référence dans cette section.

  Je ne suis pas sûr des effets de l'ajout de mailto: la fonctionnalité du correctif aurait sur les résultats.

• Il y a aussi beaucoup d'autres questions sur SO qui ont toutes des réponses similaires. Je n'ai rien trouvé qui corresponde mon effet désiré

---

La question :

Serait-il possible de augmenter l'efficacité (c'est-à-dire le moins de spam possible) des méthodes d'obfuscation des e-mails ci-dessus en combiner deux ou plusieurs des corrections (ou même ajouter de nouvelles corrections) alors que :

A- Maintien mailto: la fonctionnalité ; et

B- Soutien aux lecteurs d'écran

---

Editar:

De nombreux réponses et commentaires ci-dessous poser une très bonne question tout en indiquant l'impossibilité de le faire sans une sorte de js

La question qui est demandé/impliqué est :

Pourquoi ne pas utiliser js ?

La réponse est que je suis allergique à js

Blague à part, cependant,

Les trois principales raisons pour lesquelles j'ai posé cette question sont les suivantes :

• Les formulaires de contact sont de plus en plus acceptés comme un substitut à la fourniture d'une adresse électronique. pour fournir une adresse électronique - ce qui ne devrait pas être le cas.

• Si elle peut être fait sans script, alors il devrait être fait sans script.

• La curiosité : (car j'utilise en fait l'un des modèles de js fixe actuellement) je voulais voir si le fait de discuter de la question peut mener à une meilleure façon de faire.

Answer 1

Le problème de votre demande concerne spécifiquement le "soutien aux lecteurs d'écran", car par définition, les lecteurs d'écran sont des "robots" en quelque sorte. Si un lecteur d'écran doit être capable d'interpréter l'adresse électronique, alors un moteur de recherche de pages devrait être capable de l'interpréter également.

De plus, le point de la mailto doit être la norme en matière d'adresses électroniques sur le web. Demander s'il existe une deuxième façon de le faire revient à demander s'il existe une deuxième norme.

Si vous le faites par le biais de scripts, vous aurez toujours le même problème, car une fois la page chargée, le script aura été exécuté et l'adresse électronique rendue dans le DOM (à moins que vous ne remplissiez l'adresse électronique on click ou autre). Quoi qu'il en soit, les lecteurs d'écran auront toujours des problèmes avec ça, puisque ce n'est pas déjà chargé.

Honnêtement, il suffit de se procurer un service de messagerie doté d'un filtre anti-spam à moitié décent et de spécifier un objet par défaut facile à trier dans votre boîte de réception.

<a href="mailto:no-one@no-where.com?subject=Something to filter on">Email me</a>

Ce que vous demandez, c'est si la norme a deux façons de faire quelque chose, l'une pour les bots et l'autre pour les non-bots. La réponse est que ce n'est pas le cas, et qu'il faut se battre contre les bots du mieux que l'on peut.

Answer 2

Il est difficile de vaincre les robots de messagerie. Vous pouvez consulter le Section sur les contre-mesures à la collecte d'adresses électroniques sur Wikipedia.

Mon histoire est que j'ai écrit un robot de recherche. Il a exploré plus de 105 000 URL lors de son lancement il y a plusieurs années. Ce que j'ai appris de cette expérience, c'est que les robots d'exploration du web voient littéralement TOUT c'est-à-dire le texte, qui apparaît sur une page web. Les robots lisent tout sauf les images.

Pour ces raisons, le spam ne peut pas être facilement arrêté par code :

1. Les CSS et JS ne sont pas pertinents lorsqu'on utilise la balise mailto :. Les robots examinent spécifiquement les pages HTML à la recherche du mot clé "mailto :". Tout ce qui se trouve entre les deux points et le guillemet simple ou double suivant (quel que soit le premier) est considéré comme une adresse électronique. Les adresses électroniques des entités HTML - comme l'exemple ci-dessus - peuvent être rapidement traduites à l'aide d'une méthode/fonction ASCII inverse. L'exécution de l'extrait de code JavaScript ci-dessus transforme rapidement la chaîne qui commence par : votre... en... "yourname@domain.com". (Mon robot de recherche a jeté les hrefs avec des adresses mailto:email, car je voulais des URL pour des pages web & pas des adresses email).

2. Si une page fait planter un bot, l'auteur du bot le réglera pour corriger le plantage en tenant compte de cette page, afin que le bot ne plante plus sur cette page à l'avenir. Il rend ainsi son bot plus intelligent.

3. Les auteurs de robots peuvent écrire des robots qui génèrent toutes les variations connues d'adresses électroniques... sans explorer les pages et sans jamais utiliser d'adresses électroniques de départ. Bien que cela ne soit pas réalisable, ce n'est pas inconcevable avec les processeurs actuels à nombre de cœurs élevé (qui sont hyper threadés et fonctionnent à plus de 4 GHz), ainsi qu'avec la possibilité d'utiliser l'informatique distribuée en nuage et même les superordinateurs. Il est concevable que quelqu'un puisse maintenant créer une ferme de robots pour spammer tout le monde, sans connaître l'adresse électronique de personne. Il y a 20 ans, cela aurait été incompréhensible.

4. Les fournisseurs de courrier électronique gratuit ont l'habitude de vendre leurs comptes utilisateurs gratuits à leurs annonceurs. Dans le passé, le simple fait de s'inscrire à un compte de messagerie gratuit leur garantissait automatiquement le feu vert pour commencer à envoyer du spam à cette adresse électronique... sans jamais utiliser cette adresse en ligne. J'ai vu cela se produire plusieurs fois, avec des noms de sociétés célèbres. (Je ne citerai aucun nom).

5. Le mot-clé mailto : fait partie de ce processus. RFC DE L'IETF Les navigateurs sont conçus pour lancer automatiquement les clients de messagerie par défaut, à partir de liens contenant ce mot-clé. JavaScript doit être utilisé pour interrompre ce processus de lancement d'application, lorsqu'il se produit.

Je ne pense pas qu'il soit possible d'arrêter 100% des spams en utilisant des serveurs de messagerie traditionnels, sans utiliser des filtres sur le serveur de messagerie et éventuellement des images.

Il existe une alternative... Vous pouvez également créer un client de messagerie de type chat, qui fonctionne en interne sur un site Web. Ce serait comme le client de chat de Facebook. C'est "un peu comme un email", mais pas vraiment un email. Il s'agit simplement d'une messagerie instantanée 1 à 1 avec une fonction d'archivage... qui se charge automatiquement à la connexion. Puisqu'il possède des fonctions de pièces jointes et de liens, il fonctionne un peu comme le courrier électronique... mais sans le spam. Tant que vous ne construisez pas une API accessible de l'extérieur, c'est un système fermé où les gens ne peuvent pas envoyer de spam.

Si vous avez l'intention de vous en tenir à un courrier électronique strictement traditionnel, votre meilleure option est peut-être d'utiliser quelque chose comme l'application Apache SpamAssassin sur le serveur de messagerie d'une entreprise.

Vous pouvez également essayer de combiner plusieurs stratégies, comme celles que vous avez énumérées ci-dessus, afin de compliquer la tâche des moissonneurs d'adresses électroniques qui veulent glaner des adresses électroniques sur vos pages Web. Elles n'arrêteront pas 100 % du spam, 100 % du temps... tout en permettant à 100 % des lecteurs d'écran de fonctionner pour les visiteurs aveugles.

Vous avez créé un très bon point de départ à ce qui ne va pas avec l'email traditionnel ! Félicitations pour cela !

Un bon lecteur d'écran est JAWS de Freedom Scientific . Je l'ai déjà utilisé pour écouter comment mes pages Web sont lues par des utilisateurs aveugles. (Si vous entendez une voix masculine qui lit à la fois les actions [comme cliquer sur un lien] et le texte, essayez de changer la voix d'une personne pour une voix féminine afin qu'une voix lise les actions et une autre le texte. Cela permet d'entendre plus facilement comment la page Web est lue pour les malvoyants).

Bonne chance avec votre Contre-mesure à la collecte d'adresses électroniques efforts !

Answer 3

Voici une approche qui fait appel à JavaScript, mais avec une empreinte assez faible. Elle est également très "ghetto" et, en général, je ne recommanderais pas une approche avec du JS en ligne dans le HTML, sauf si vous êtes extrêmement réticent à utiliser du JS, tout court.

<a
  href="#"
  data-contact="bGUtZW1haWxAdGhlLWRvbWFpbi5jb20="
  data-subj="QW4gQW1hemluZyBTdWJqZWN0"
  onfocus="this.href = 'mailto:' + atob(this.dataset.contact) + '?subject=' + atob(this.dataset.subj || '')"
  >
  Send an email
</a>

data-contact est l'adresse électronique codée en base64. Et, data-subj est un sujet facultatif codé en base64.

La principale difficulté pour réaliser cette opération sans JS est que les CSS ne peuvent pas modifier les attributs HTML (la fonction article que vous avez liée est une rêverie et n'a aucune incidence sur ce qui est possible aujourd'hui ou dans un avenir proche).

L'approche des entités HTML que vous avez mentionnée, ou une variation de celle-ci, est probablement l'option la plus simple qui aura une certaine efficacité. De plus, le iframe approche est intelligente et le approche de redirection du serveur est assez génial. Mais, les trois sont vulnérables aux robots :

• Les entités HTML doivent simplement être converti (et détecter cela est simple)
• Le document référencé par l'iframe pourrait simplement être suivi
• La redirection du serveur pourrait être simplement suivie, ainsi que

Avec l'approche décrite ci-dessus, l'utilisation d'une adresse de courriel codée en base64 dans une data-contact est très "ponctuel" - tant que le scrapper n'est pas spécifiquement conçu pour votre site, il devrait fonctionner.

Answer 4

Simple + Beaucoup de @ + Modifiable sans outils

<a href="mailto:user@domain@@com"
   onmouseover="this.href=this.href.replace('@@','.')">
   Send email
</a>

Answer 5

Avez-vous envisagé d'utiliser le recaptcha mailhide de Google ? https://www.google.com/recaptcha/admin#mailhide

L'idée est que lorsqu'un utilisateur clique sur la case à cocher ( voir nocaptcha ci-dessous ), l'adresse électronique complète s'affiche.

Alors que le recaptcha est traditionnellement non seulement difficile pour les lecteurs d'écran mais aussi pour les humains, avec le rôle du recaptcha nocaptcha de google que vous pouvez lire sur aquí en ce qui concerne les tests d'accessibilité. Il semble prometteur en ce qui concerne les lecteurs d'écran, car il se présente comme une case à cocher traditionnelle.

Exemple #1 - Non sécurisé mais pour illustrer facilement l'idée

Voici un code à titre d'exemple, sans utiliser mailhide mais en mettant en œuvre quelque chose en utilisant recaptcha vous-même : https://jsfiddle.net/43fad8pf/36/

<div class="container">
    <div id="recaptcha"></div>
</div>
<div id="email">
    Verify captcha to get e-mail
</div>

function createRecaptcha() {
    grecaptcha.render("recaptcha", {sitekey: "6LcgSAMTAAAAACc2C7rc6HB9ZmEX4SyB0bbAJvTG", theme: "light", callback: showEmail});
}
 createRecaptcha();

function showEmail() {
    // ideally you would do server side verification of the captcha and then the server would return the e-mail
  document.getElementById("email").innerHTML = "email@something.com";
}

Note : Dans mon exemple, l'e-mail est placé dans une fonction javascript. L'idéal serait de valider le recaptcha du côté du serveur et de renvoyer l'e-mail, sinon le robot peut simplement le récupérer dans le code.

Exemple n° 2 - Validation côté serveur et renvoi de l'e-mail

Si nous utilisons un exemple plus proche de celui-ci, nous obtenons une sécurité supplémentaire : https://designracy.com/recaptcha-using-ajax-php-and-jquery/

function showEmail() {
    /* Check if the captcha is complete */
    if ($("#g-recaptcha-response").val()) {
        $.ajax({
            type: ‘POST’,
            url: "verify.php", // The file we’re making the request to
            dataType: ‘html’,
            async: true,
            data: {
                captchaResponse: $("#g-recaptcha-response").val() // The generated response from the widget sent as a POST parameter
        },
        success: function (data) {
            alert("everything looks ok. Here is where we would take 'data' which contains the e-mail and put it somewhere in the document");
        },
        error: function (XMLHttpRequest, textStatus, errorThrown) {
            alert("You’re a bot");
        }
    });
} else {
    alert("Please fill the captcha!");
}
});

Où se trouve verify.php :

$captcha = filter_input(INPUT_POST, ‘captchaResponse’); // get the captchaResponse parameter sent from our ajax

/* Check if captcha is filled */
if (!$captcha) {
    http_response_code(401); // Return error code if there is no captcha
}
$response =     file_get_contents("https://www.google.com/recaptcha/api/siteverify?secret=YOUR-SECRET-KEY-HERE&response=" . $captcha);
if ($response . success == false) {
echo ‘SPAM’;
http_response_code(401); // It’s SPAM! RETURN SOME KIND OF ERROR
} else {
// Everything is ok, should output this in json or something better, but this is an example
    echo 'email@something.com'; 
}