Esconder o endereço de E-mail dos Bots-Keep mailto:
Tl; dr
esconder o endereço de E-mail dos bots sem usar programas e manter a funcionalidade mailto:
. O método também deve suportar os leitores de tela.
resumo
e-mail ofuscação sem usar scripts ou formulários de contacto
o endereço de E-Mail tem de ser completamente visível para os telespectadores humanos e manter a funcionalidade
mailto:
o endereço de E-mail não deve estar em image form.
o endereço de E-mail deve estar "completamente" escondido dos "spam-crawlers" e dos "spam-bots" e de qualquer outro tipo de colector
Efeito Desejado:
sem guiões, por favor. Não há scripts usados no projeto e eu gostaria de mantê-lo assim .
o endereço de E-Mail é ou mostrado na página ou pode ser facilmente mostrado após algum tipo de utilizador interacção, como abrir um modal.
o utilizador pode carregar no endereço de E-mail que, por sua vez, irá activar a funcionalidade
mailto:
.-
se carregar no e-mail, irá abrir a aplicação de E-mail do utilizador.
por outras palavras, a funcionalidade
mailto:
deve funcionar. O endereço de e-mail não visível ou não, identificado como um endereço de e-mail para bots (Isto inclui o código fonte da página)
I Não tenho uma caixa de entrada cheia de spam
O que é que Não funciona
-
adicionar um formulário de contacto-ou algo semelhante-em vez do endereço de E-mail
odeio formulários de contacto.. Raramente preencho um formulário de contacto. Se não houver endereço de E-mail, procuro um número de telefone, e se não estiver lá, começo a procurar um serviço alternativo. Só preencheria um formulário de contacto se fosse preciso.
-
substituir o endereço por uma imagem do endereço
Isto cria uma enorme desvantagem para alguém que usa um leitor de ecrã. por favor, lembre-se dos deficientes visuais nos seus futuros projectos.)também remove a
mailto:
funcionalidade, a menos que você faça a imagem clicável e, em seguida, adicionar a predefiniçãomailto:
funcionalidade como ahref
para o link, mas que derrota o propósito e agora o e-mail é visível para ROBO.
o que pode funcionar:
utilização inteligente de
pseudo-elements
inCSS
soluções que fazem uso da codificação
base64
Quebrando o endereço de e-mail e de difusão de peças em todo o documento, em seguida, colocá-los novamente juntos em um modal quando o usuário clica em um botão (Isso vai envolver várias
CSS
classes e o uso deanchor tags
)-
Alterting
@MortezaAsadi graciosamente levantou a possibilidade nos comentários abaixo. Este é o link para a íntegra - o artigo é de 2012:html
atributos viaCSS
outras soluções criativas que estão além do meu alcance de conhecimento.
Perguntas / Correcções Similares
grande arranjo sugerido por Joe Maller, ele funciona bem, mas é baseado em roteiro {[[39]}. Eis o que parece:
<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>
-
à procura de uma função de ofuscador de endereço de E-mail só para o php
(uma solução inteligente usando
PHP
eCSS
para primeiro reverter o e-mail usando PHP depois reverter de volta com CSS) uma solução muito promissora que funciona muito bem! Mas é muito fácil resolve . -
vale a pena ofuscar endereços de E-mail na web hoje em dia?
(JavaScript fix)
-
a melhor maneira de ofuscar um endereço de E-mail num site?
a resposta seleccionada funciona. Funciona muito bem. Envolve codificar o e-mail como
Eis o que parece tipo:html entities
. Pode ser melhorado?<A HREF="mailto: yourname@domain.com"> yourname@domain.com </A>
-
os endereços electrónicos funcionam mesmo?
(a resposta selecionada para esta pergunta do superusuário é grande e apresenta um estudo da quantidade de spam recebida usando diferentes métodos de ofuscação.
Parece que manipular o endereço de E-mail comCSS
para torná-lortl
Funciona. Este é o mesmo método utilizado na primeira pergunta a que me referi nesta secção.não sei quais os efeitos que a adição da funcionalidade
mailto:
à correcção teria nos resultados. há também muitas outras perguntas sobre SO {168]} que todas têm respostas semelhantes. Não encontrei nada que se encaixe no meu efeito desejado.
A Pergunta:
seria possível aumentar a eficiência (ou seja, o mínimo de spam possível) dos métodos de ofuscação por e-mail acima por combinar duas ou mais correcções (ou mesmo a adição de novas correcções) enquanto:
a-manutenção da funcionalidade mailto:
; e
B-Leitores de ecrã de suporte
Editar:
Muitas das respostas e comentários abaixo apresentam uma boa pergunta, indicando a impossibilidade de fazer isso sem algum tipo dejs
a pergunta que é feita/implícita é:
Por que não utilizar
js
?
a resposta é que sou alérgico a js
Os formulários de contacto estão a tornar-se cada vez mais aceites como substituição para fornecer um endereço de E - mail-que eles não devem.
se isso pode ser feito {[39] } sem scripting então ele deve ser feito sem roteiros.
curiosidade: estou de fato usando uma das correções
js
atualmente) Eu queria ver se discutir o assunto levaria a uma melhor maneira de fazê-lo.
9 answers
O problema com o seu pedido é especificamente os "leitores de tela de suporte", como por definição os leitores de tela são um" bot " de algum tipo. Se um leitor de tela precisa ser capaz de interpretar o endereço de E-mail, então um rastreador de página seria capaz de interpretá-lo também.
Também, o ponto do atributo mailto
é ser o padrão de como fazer endereços de E-mail na web. Perguntar se existe uma segunda forma de o fazer é perguntar se existe uma segunda norma.
on click
ou algo assim). De qualquer forma, os leitores de tela ainda terá problemas com isso, uma vez que ainda não está carregado.
Honestamente, basta obter um serviço de E-mail com um filtro de spam meio decente e especificar uma linha de assunto padrão que é fácil para você ordenar na sua caixa de entrada.
<a href="mailto:[email protected]?subject=Something to filter on">Email me</a>
O que estás a pedir é se o padrão tem duas maneiras de fazer algo, uma para bots e a outra para não-bots. A resposta é que não, e tens de lutar contra os robots o melhor que puderes.
O Spam não pode ser parado facilmente via código por estas razões:
CSS & JS são irrelevantes ao usar a marca mailto:. Os Bots olham especificamente para as páginas HTML para a palavra-chave" mailto:". Tudo, desde o cólon até à próxima citação ou citação dupla (o que vier primeiro) é visto como um endereço de E-mail. Endereços de email de entidade HTML - como o exemplo acima-podem ser traduzidos rapidamente usando um método/função ASCII reverso. Executando o excerto de código JavaScript acima, roda rapidamente o texto que começa com: sua... em... "[email protected]". (meu bot de busca jogou fora hrefs com mailto:email endereços, como eu queria URLs para páginas web e não endereços de E-mail.)
Se uma página colidir com um bot, o autor do bot irá afinar o bot para corrigir o estoiro com essa página em mente, de modo que o bot não vai bater nessa página novamente no futuro. Tornando o Robot mais inteligente.
Os autores de Bot podem escrever bots, que geram todas as variações conhecidas de endereços de E-mail... sem rastejar páginas e nunca usar nenhum endereço de E-mail inicial. Embora possa não ser viável fazer isso, não é inconcebível com os CPUs de contagem de alto núcleo de hoje (que são Hyper-threaded & run at 4+ GHz), além da disponibilidade de usar computação distribuída em nuvem e até super computadores. É concebível que alguém possa agora criar uma fazenda de bots para spam todos, sem saber o endereço de E-mail de ninguém. Há 20 anos, isso teria sido incompreensível.
Os provedores de E-mail gratuitos tiveram um histórico de vender as suas contas de utilizador grátis aos seus anunciantes. No passado, simplesmente inscrever-se para uma conta de E-mail gratuito automaticamente garantiu-lhes uma luz verde para começar a entregar spam para esse endereço de E-mail... sem nunca usar esse endereço de E-Mail online. Já vi isso acontecer várias vezes, com nomes famosos de empresas. (Não mencionarei nenhum nome.)
A Palavra-chave mailto: faz parte deste IETF RFC , onde os navegadores são construídos para lançar automaticamente o valor por omissão clientes de E-mail, a partir de links com essa palavra-chave neles. JavaScript tem que ser usado para interromper o processo de lançamento da aplicação, quando isso acontece.
Eu não acho que seja possível parar 100% de spam ao usar servidores de E-mail tradicionais, sem usar filtros no servidor de E-mail e possivelmente usando imagens.
Há uma alternativa... Você também pode construir um cliente de E-mail Tipo chat, que corre internamente em um site. Seria como o cliente de chat do Facebook. É "gentil". of like email", but not really email. É apenas uma mensagem instantânea 1 para 1 com uma funcionalidade de arquivo... que carrega automaticamente no início do login. Uma vez que tem o anexo do documento + funcionalidades do link, ele funciona como um e-mail... mas sem spam. Desde que você não construa uma API acessível externamente, então é um sistema fechado onde as pessoas não podem enviar spam para ele. Se você está planejando ficar com o e-mail estritamente tradicional, então sua melhor aposta pode ser executar algo como o Apache Spamassassassin no servidor de E-mail de uma empresa.Você também pode tentar combinar várias estratégias como você listou acima, para tornar mais difícil para os colhedores de E-mail para recolher endereços de E-mail de suas páginas web. Eles não vão parar 100% do spam, 100% do tempo... ao mesmo tempo, permitindo que 100% dos leitores de tela para trabalhar para os visitantes cegos.
Você criou um bom começo para ver o que há de errado com o e-mail tradicional! Parabéns por isso! Um bom ecrã reader is JAWS from Freedom Scientific. Já usei isso antes para ouvir como as minhas páginas são lidas por utilizadores cegos. (Se ouvir uma voz masculina a ler ambas as acções [como carregar numa ligação] e texto, tente mudar uma voz para uma mulher para que uma voz leia as acções e outra leia o texto. Isso torna mais fácil ouvir como a página web é lida para os visualmente impared.) Boa sorte com os teus esforços de contra-medida de recolha de endereços de Email!Aqui está uma abordagem que faz uso de JavaScript, mas com uma pegada bastante pequena. É também muito "gueto", e geralmente eu não recomendaria uma abordagem com o inline JS no HTML, exceto que você tem uma extrema relutância em usar JS, em tudo.
<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
é o endereço de E-mail codificado base64. E {[2] } é um assunto opcional codificado por base64.
O principal desafio com isto sem JS é que o CSS não pode alterar HTML atributo. (O artigoque você ligou é um" pie-in-the-sky " musing e não tem qualquer influência sobre o que é possível hoje ou no futuro próximo.)
A abordagem de entidades HTML que mencionou, ou alguma variação dela, é provavelmente a opção mais simples que terá alguma eficácia. Além disso, a iframe
a aproximação é inteligente e a aproximação de redirecionamento do servidor é bastante impressionante. Mas, todos os três são vulneráveis aos bots:
- As entidades HTML apenas é necessário ser convertido (e detectar isso é simples)
- O documento referenciado pelo iframe pode simplesmente ser seguido
- o redireccionamento do servidor pode ser simplesmente seguido, também
Com a abordagem descrita acima, a utilização de um endereço de E-mail codificado base64 num atributo {[[1]} é muito "pontual" – desde que o scrapper não seja especificamente concebido para o seu site, deverá funcionar.
A ideia é que quando um utilizador clica na opção (ver nocaptcha abaixo), o endereço de E-mail completo é mostrado.
Enquanto o recaptcha é tradicionalmente difícil não só para os leitores de tela, mas também para os humanos, com o roleout da nocaptcha recaptcha do google que você pode ler sobre aqui Porque se relacionam com testes de acessibilidade. Ele parece mostrar a promessa com relação aos leitores de tela, uma vez que torna como uma caixa de controle tradicional de sua visão.Exemplo # 1 - não seguro, mas para uma fácil ilustração da ideia
Aqui está um código como um exemplo sem usar mailhide mas implementando algo usando recaptcha você mesmo: 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 protected]";
}
Nota: no meu exemplo, Tenho o e-mail numa função javascript. Idealmente você teria o recaptcha validado no final do servidor, e retornar o e-mail, caso contrário o bot pode simplesmente obtê-lo no código.
Exemplo #2-validação do lado do servidor e devolução do E-mail
Se usarmos um exemplo mais parecido com este, teremos segurança adicional: 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!");
}
});
Onde verificar.php is:
$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&amp;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 protected]';
}
mailto
usando CSS. Além disso, você disse especificamente que não queria definir o link usando Javascript.
Se você pensar sobre quais outros tipos de recursos existem, há também documentos externos (ou seja, documentos HTML usando iframes). Quase nenhum raspador se incomodaria a descarregar o conteúdo do iframes. Portanto, você pode simplesmente fazer:
Índice.html:
<iframe src="frame.html" style="height: 1em; width: 100%; border: 0;"></iframe>
Frame.html:
My email is <a href="mailto:[email protected]" target="_top">[email protected]</a>
Para os utilizadores humanos, o iframe parece-se com o texto normal. As Iframes são alinhadas e transparentes por padrão, então só precisamos definir sua borda e dimensões. Você não pode fazer o tamanho do iframe corresponder ao tamanho do conteúdo sem usar Javascript, então o melhor que podemos fazer é dar-lhe dimensões predefinidas.
Uma solução do lado do servidor pode estar a fazer um {[[0]} que se liga a uma nova página, que simplesmente redirecciona para o desejado mailto
:
Simples + lote de @ + editável sem ferramentas
<a href="mailto:user@domain@@com"
onmouseover="this.href=this.href.replace('@@','.')">
Send email
</a>
O único método que achei eficaz foi usá-lo com css como abaixo:
<a href="mailto:[email protected]">myemail@<span style="display:none;">ignore-</span>domain.com
E depois escrever um javascript para remover a palavra ignoreme-
do atributo href="mailto:..."
com regex. Isto irá esconder o e-mail do bot à medida que irá adicionar ignore-
palavra antes do domínio real e isto irá funcionar no leitor do ecrã e quando o Utilizador carregar na função JS personalizada da ligação irá remover a palavra ignore-
do atributo href
, de modo que irá abrir o e-mail real.
Este método tem funcionado de forma muito eficaz. para mim até à data. pode ler mais sobre isto ... http://techblog.tilllate.com/2008/07/20/ten-methods-to-obfuscate-e-mail-addresses-compared/