Por que adotar uma dependência complexa aqui quando um modo de bloqueio trivial de endereço de e-mail é muito mais simples de implementar e analisar? Além disso, isso agora nos expõe a novas explorações? Não, obrigado!
Considerando a raridade dessa reclamação e as circunstâncias excepcionais ao seu redor, acho que seguir a rota simples e extra rigorosa é preferível.
O caminho simples de banir qualquer coisa que não seja /a-zA-Z0-9/ funciona, mas tem grandes problemas de usabilidade: muitas pessoas não saberão como se cadastrar e precisaríamos de novas mensagens de erro. Muitas pessoas que usam o Gmail não sabem que janedoe@gmail.com funciona como seu e-mail, já que sempre acharam que jane.doe@gmail.com era o correto. A proibição afetaria o OAuth e faria o login com o Gmail falhar para que funcionasse corretamente.
Endereço de e-mail:
sam.s@gmail.com
ERRO:.não é permitido em endereços de e-mail (nova mensagem)
A normalização é menos hostil ao usuário e não requer nenhuma nova experiência de usuário (UX).
Podemos começar com um normalizador opcional mais simples (remover tag, remover ponto para o Gmail).
Dito isso, para ficar 100% claro: não estou sugerindo uma dependência aqui. O email_address está quebrado e não é adequado para o que queremos aqui.
Uma medida apressada e parcial aqui apenas criará uma configuração de site “quebrar e-mail no meu site”, da qual não estou particularmente interessado em adicionar.
Certo, mas o site dele está sob cerco. Milhares dessas contas duplicadas estão se inscrevendo por dia. Portanto, faz sentido haver um modo de bloqueio simples para endereços de e-mail, oferecido a sites que estão em guerra com o Mossad e perdendo feio.
Guerra exige sacrifício. Haverá baixas civis. O site dele já está quebradíssimo.
Idealmente, você precisaria de uma tabela com os provedores de e-mail e como “limpar” de acordo com cada provedor (exatamente o que você citou). Como Bart explicou bem, não se trata de impedir o uso de qualquer endereço de e-mail por causa de alguns caracteres, mas sim de ser capaz de detectar quais endereços são realmente os mesmos.
Claro, spammers que realmente quiserem sempre conseguirão. É como com alarmes/fechaduras e ladrões: a ideia é tornar mais difícil.
Criar x contas do Gmail é spam para o Gmail, esse é problema deles de resolver (mesmo que possa ser usado para spam contra você depois).
Não estou acompanhando.
Se tratarmos bob.test+100@gmail.com como bobtest@gmail.com internamente e armazenarmos dessa forma (quando a opção estiver ativada), qual sacrifício exatamente está sendo feito aqui?
O bug é específico do gmail, então, para mim, parece uma reação exagerada banir todos os pontos em todos os lugares só porque o Google decidiu inventar uma especificação e normalizar. A lógica para a limpeza é bastante simples e isso seria opcional, desativado por padrão.
@Mevo, apenas para ficar 100% claro aqui: a proposta do Jeff é que adicionemos um “modo de desastre”. Nesse modo, bob.test@gmail.com é um e-mail inválido que não pode ser usado.
Eu sugeriria comparar com a forma simplificada, mas você precisa ter cuidado para ainda armazenar e encaminhar o e-mail para o endereço originalmente especificado.
Você não tem o consentimento do usuário para enviar mensagens a qualquer outra variação, e usar qualquer coisa além do endereço que eles especificaram pode resultar na não entrega da mensagem.
Como exemplo, tenho um endereço do Gmail que foi criado nos primeiros meses do serviço. E-mails para o alias base são efetivamente descartados. Apenas e-mails que atingem endereços específicos com o sinal de mais (+) serão vistos.
Cuidado também com suposições: muitos usuários do Gmail não sabem que os pontos são opcionais. A grande maioria nunca ouviu falar sobre endereçamento com sinal de mais (+) também. Faça a triagem para prevenir abusos do último, mas isso corre o risco de causar prejuízos ao primeiro.
@sam Entendi perfeitamente o que o Jeff quis dizer e, assim como você, sou contra o que ele propõe (sem ofensas a ele, desacordos acontecem).
Isso pode parecer exigente, mas armazenar apenas o endereço de e-mail “limpo” removerá o que alguns usuários legítimos fazem de propósito. Exemplo: um usuário que se registra (totalmente de forma legítima e apenas uma vez) com bob+meta@example.com ou bob+forums@example.com perderá o que tentava alcançar. O problema é que ele receberá e-mails apenas em bob@example.com, e não era isso que ele queria (ele pode, por exemplo, usar a “tag” para colocar os e-mails recebidos em uma pasta específica).
Entendo perfeitamente que levar isso em consideração tornaria o processo um pouco mais complexo. Seria necessário armazenar AMBAS as versões: a inserida pelo usuário (para envio de e-mails) e a versão limpa. Você pode usar a versão limpa como usa os endereços de e-mail atualmente (para tudo relacionado internamente ao usuário e para verificar se esse usuário já está registrado). Além disso, para evitar esse pequeno problema, seria necessário armazenar o que o usuário digitou, além disso (apenas para uso no envio de e-mails). Seria o equivalente ao endereço de “responder a” em e-mails.
Espero que isso seja compreensível.
EDIT: Escrito ao mesmo tempo que o @Stephen (ideia globalmente a mesma)
Este é um ponto muito válido, realmente torna a implementação um pouco mais complicada.
Acho que a verificação só seria feita ao “criar uma nova conta”:
Já existe algum endereço de e-mail no sistema com essa forma canônica? Se sim, desculpe, não será possível criar uma nova conta para você.
Há um problema secundário relacionado ao OAuth do Google (seria que ele também verificaria o e-mail canônico) e à transição de endereços não canônicos para canônicos.
O OAuth não funciona com endereçamento por alias, pelo que sei, então isso não estaria fora do escopo?
Com isso, quero dizer que não consigo criar uma nova conta usando o Google, especificar um alias diferente e repetir o processo.
Mesmo espaço de problema.
Eu me cadastro com sam+hi@gmail.com… então clico no botão de entrar com o Google. O que acontece?
Atualmente: nova conta criada
Proposta:
Opção A: tela de erro, você não pode criar esta conta
Opção B: o usuário faz login com sam+hi@gmail.com
Modo de bloqueio original proposto: sam.test@gmail.com não pode fazer login com o botão “Entrar com o Google”.
Supondo que você consiga criar uma tradução robusta para remover endereços com ‘+’ e pontos desnecessários, você poderia simplesmente manter um hash do e-mail desduplicado e compará-lo com a criação da conta?
Essa é a opção B, portanto existe um problema colateral com o OAuth do Google 
Além disso, a questão da migração é complicada, mas provavelmente pode ser ignorada.
Dito isso, dado o alcance desse problema em produção, não espero que trabalhemos em nenhuma alteração aqui nos próximos meses.
Como dito acima, usar apenas a versão “canônica” internamente e armazenar adicionalmente o que o usuário inseriu (apenas para enviar e-mails) não seria uma solução?
Podemos resolver isso sem problemas. Estimo que sejam necessários de 2 a 6 dias de trabalho para testar e depurar essa nova troca, pois há muitos detalhes pequenos para se preocupar.
O problema aqui é que o @codinghorror não pode justificar o orçamento de tanto tempo para esse recurso.
Podemos implementar quebrar um grande monte de logins por e-mail em 1 dia de trabalho, mas não quero ter uma configuração assim no Discourse.
Então você está em uma situação complicada aqui, @Mevo… Mais pessoas precisam experimentar e relatar esse problema para que possamos justificar o tempo gasto nisso.
@sam Eu entendo.
(a propósito, estou vendo isso pela primeira vez. Sua postagem foi editada automaticamente: " [system] — Citação de toda a postagem anterior removida automaticamente". Uau! Isso é uma funcionalidade muito legal!)
Você precisa ter muito cuidado para nunca armazenar a versão canônica. O usuário não consentiu em fornecê-la e, se as tabelas de usuários forem comprometidas, não será possível identificar facilmente qual serviço comprometeu os dados.
O Facebook tem repetidamente se metido em grandes problemas ao armazenar informações pessoais identificáveis (PII) relacionadas a usuários que não forneceram essas informações nem consentiram em tê-las associadas à sua conta.
Não vejo nenhum problema com essa configuração pessoalmente; só tenho relutância em fazê-lo porque “aquele cara teve um problema aquela vez”.
Sim, isso é uma coisa terrível de sugerir que adicionemos ao Discourse. Eu seria violentamente contra a sua inclusão. Além disso, o endereçamento é um recurso, sempre foi um recurso, e é amigável ao usuário.
Se você estiver sendo atacado pelo Mossad… ative o Modo de Ataque do Mossad. Acho que só precisamos que o Mossad ataque mais pessoas, né? 
Sou veementemente contra adicionar essa configuração ao Discourse. Não tenho problema nenhum em que alguém crie um plugin para isso; seriam apenas algumas linhas de código em um plugin. Se você realmente precisa disso, posso fazer uma pausa e criar o plugin hoje, é só me avisar.
É meio inútil construí-lo, já que a única pessoa que tem o problema já disse que não vai usá-lo.
Uma configuração chamada “quebrar meu Discourse” é fundamentalmente ruim e, na minha opinião, não pertence ao produto.
Acho que, se mais pessoas estivessem enfrentando o problema, um modo de bloqueio por e-mail seria mais defensável. Mas, no momento, é apenas aquele cara naquele site.
Então, esperamos e vemos…
Um cara, em um site, que não usaria o recurso
É mais preciso…