Executando verificação de segurança...
5
leonardoribeiro
2 min de leitura ·

Por que geralmente não validam os emails?

Uma dúvida que sempre tive ao criar conta em diferentes sites é por qual motivos eles não validam emails?

Em sites que não há uma preocupação em criação de inúmeras contas, onde nada é recebido por uma nova conta, acredito que não é necessário proteger a etapa de criação, mas lugares onde pode receber uma recompensa ou benefício por ter sido recém gerada, a proteção deste processo, acredito eu, é importante.
Eu não tenho nenhuma base relacionado, é so uma dúvida pessoal de uma pessoa que ja se aproveitou de benefícios de teste grátis, onde a aplicação bloqueava a geração de outro teste grátis no mesmo email, mas não da maneira "correta".
A maneira que eu faço é simples, apenas adicionar um + após o seu email que ele é interpretado como um novo email, por exemplo: [email protected]
Esta conta receberá normalmente os emails normalmente em leoribeiro, mas é um macete para não ter que criar varios novos emails para se aproveitar de um serviço.
Outro exemplo é aqui mesmo no TabNews, não que seja um problema, mas se alguém quiser,a pessoa pode criar variações de nicknames em contas diferentes usando o mesmo email para confirmação, podendo até automatizar esse processo.
A verdadeira utilidade para o símbolo de "+" após o email é para que você possa separar da sua maneira o cadastro realizado em diferentes serviços, criando filtros para direcionamento de email, etc.

O que vocês acham disso, realmente é necessário o bloqueio do uso ou isso atrapalharia a real função do símbolo "+"?

Carregando publicação patrocinada...
5
brunosierra

Não é interessante bloquear por que não há uma regra que padronize esses tokens em todos os servidores de email. As rfc que designam as notações do que seria um email, mesmo que fossem atualizadas padronizando o + como um alias, podem não sutir efeitos já que não há garantias que elas serão adotadas por todos os provedores.

então usando como base o +, se você aplicasse a regra de sempre bloquear, independentemente do dominio, poderia bloquear de provedores que são realmente duas contas.

se fosse bloqueio limitados aos provedores, por exemplo apenas os + do gmail, você traria responsabilidades pra sua aplicação e ficaria a seu cargo "aprender" as regras de alias em todos provedores, e mesmo no caso do gmail, existem mais de uma forma de tratar alias, por exemplo adicionando um . (ponto) também é válido, exemplo um email [email protected] é a mesma coisa que [email protected] pro gmail.

Sendo assim o email é a camada mais simples de validação mas pra casos importantes não deveria ser a unica, usar combinações como vinculação a cpf ou mesmo numero de telefone podem restrigir bastante isso.

3
cleitonmedeiros

Acho que seria bom bloquear, não sabia que dava para fazer este macete para criar várias contas diferentes apenas com um e-mail, mas fiz o teste aqui e deu certo mesmo.

Acho que pelo fato do username ser único era válido tratar melhor essa validação.

3
joao

Acredito que quando o teste grátis é vinculado ao e-mail não fez sentido validar, já que de qualquer forma o usuário poderia usar algum gerador de e-mail temporário para usar o serviço várias vezes.
Eu não sabia desse macete, pesquisei e aparentemente é uma feature que alguns provedores de e-mail dão, não funciona em todos.

3
leonardoribeiro
Autor
Autor

Até poderia ser utilizado um serviço de email temporário e aleatório, mas acredito que na grande parte das vezes eles bloqueam a criação de acordo com o domínio do email, mas acabam esquecendo do +, pelo menos nas experiências que tive foram assim.

1
filipedeschamps

Leonardo, eu fico muito feliz em ver sua preocupação com o projeto, é realmente muito legal isso e nunca podemos perder esse carinho 🤝

Minhas considerações:

  1. [email protected] é um email válido, assim como qualquer outro email com o caractere +.
  2. Eu, inclusive aqui no TabNews, fiz o meu cadastro utilizando um +algumacoisa por medida de segurança e sugiro você fazer isso em todos os sites que se cadastrar (cada site uma variação nova), pois com isso você tem uma combinação única entre email e senha para todos os serviços.
  3. Quem quiser abusar com cadastros, vai sempre conseguir fazer isso por outras vias, como por exemplo usando disposable emails. Esse serviço é um exemplo https://temp-mail.org/ tem outros que a cada refresh você ganha um email que varia caracteres antes e depois do @ e fica difícil de achar um padrão.
  4. Então uma medida seria primeiro usar listas de disposable emails, como por exemplo esse módulo: https://www.npmjs.com/package/disposable-email-domains
  5. Uma segunda medida seria usar rate-limiting por ip. No exemplo de criar uma conta você poderia barrar esse ip de criar outra conta por, por exemplo, 1 dia. Daí o atacante teria que se dar o trabalho de usar múltiplos ips.
  6. No fim do dia, é uma corrida de gato e rato que não termina, mas precisamos cuidar muito com estratégias que não irão barrar atacantes, mas que irão barrar pessoas que genuinamente querem usar um recurso.
3
gabrielabpedro

Eu acredito que este assunto é um daqueles que sempre vai longe e quase sempre não chegamos a um consenso, pois como supracitado existe "N" maneiras de burlar a criação de um e-mail. Geralmente eu uso regexp para validar se pelo menos o formato é correto.

A confirmação de e-mail já seria algo para "validar", mas existe essa feature do +algo.

o regexp que eu utilizo é:

 /^(([^<>()[\]\\.,;:\s@"]+(\.[^<>()[\]\\.,;:\s@"]+)*)|(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2**,}))$/