O problema é que forçar e-mails canônicos é praticamente o mesmo, exceto por ser muito menos hostil ao usuário.
Nenhum Sam.sam@gmail.com é permitido; Sa.msam+123@gmail.com já está registrado.
De qualquer forma, podemos implementar regex na próxima versão.
É, mas na prática é inútil, e é por isso que estamos tendo essa discussão. Assim que eles tiverem armas nucleares, você também precisará ter.
“Hostil ao usuário” é um conceito sem sentido assim que seu público tem armas nucleares e está disposto a usá-las.
Eu discordo disso, a solução funcionou perfeitamente para @markersocial, e então eu reverti a alteração porque fui forçado a fazê-lo.
Não há lacunas conhecidas com a abordagem de canonização que implementei e depois reverti; ela resolve o problema do Gmail mencionado acima em 100%.
Bem, eu discordo, porque isso transfere a carga de código e esforço para o nosso lado, em vez do deles. “Normalizar” e-mails é bastante complicado, varia conforme o provedor de e-mail, e eu não quero entrar nesse ramo.
Em outras palavras, deixe que eles construam e gerenciem os dispositivos nucleares por conta própria; não precisamos enviar protótipos nucleares para todos os países e em cada instalação do Discourse “apenas por precaução”.
(Além disso, poder bloquear e-mails via regex é bastante poderoso, especialmente porque e-mail = identidade no Discourse.)
Podemos permitir que eles normalizem com suas próprias regras de regex como uma espécie de meio-termo, assim não estaremos envolvidos no processo de normalização.
Dito isso, sim, o bloqueio por regex ou, pelo menos, o bloqueio por curinga ocorrerá na próxima versão.
Posso confirmar que a implementação anterior funcionou perfeitamente e resolveu completamente o problema do Gmail. Tanto a lista de permissão quanto a de bloqueio de domínios de e-mail são medidas bastante eficazes. No entanto, bloquear o Gmail simplesmente não é viável.
@codinghorror Entendo o ponto de vista contra a normalização para diferentes provedores de e-mail. Mas acho que faria sentido ser capaz de cobrir pelo menos o Gmail (~43% de todos os endereços de e-mail em 2020, 53% nos EUA) de forma não destrutiva. Isso poderia ser comparável ao suporte nativo a OAuth de grandes provedores.
@sam ^ Essa é uma ótima ideia para uma alternativa. 
Talvez isso, com um exemplo para a correspondência de gmail/googlemail, pudesse ser bastante amigável ao usuário e poderoso.
Temos agora um usuário que criou vários milhares de contas usando um único endereço do Gmail (com pontos) e está fazendo spam para promover seu site concorrente, a fim de desviar usuários. Vamos atualizar para a versão 2.8 e bloquear todos os e-mails que contenham um ponto ou um símbolo de mais assim que for lançada. Gostaria que a implementação anterior estivesse disponível, mas agradeço que isso esteja sendo resolvido e que uma solução estará disponível. Isso fará uma diferença enorme, obrigado
Então, pensei um pouco sobre isso e imaginei uma solução que talvez faça sentido.
Poderia haver uma opção de administrador para processar e armazenar uma versão normalizada do e-mail (processando apenas a parte do nome de usuário, ou seja, nome@..).
Mas aplicar isso apenas para domínios especificados pelo administrador.
Ou seja, uma lista semelhante às listas de permissão/bloqueio de domínios de e-mail, com duas caixas de seleção por domínio:
Em seguida, usar esses registros como referência para impedir registros adicionais usando versões alternativas desse e-mail (sem afetar o registro principal do e-mail, que ainda pode conter + e pontos).
Dessa forma, a responsabilidade de escolher quais domínios armazenar um registro normalizado e como normalizá-los ficaria apenas com o administrador, permitindo que ele responda a domínios de e-mail problemáticos conforme eles surgem.
De qualquer forma, só estou deixando isso aqui para que possa ser considerado em algum momento.
Abraços.
Eu mesclei o PR:
Ele adiciona uma nova configuração de site normalizar emails que removerá pontos e a parte +… de um email e, em seguida, verificará sua exclusividade. Por exemplo, se houver um usuário test+1@gmail.com e test+2@gmail.com tentar se registrar, eles não serão permitidos se a configuração do site estiver habilitada.
Fantástico, acho que isso resolve 100% o problema do @markersocial e é uma ótima configuração para habilitar se você acabar sendo um alvo para este ataque específico.
Informe-nos como você se sai, @markersocial
Muito obrigado por implementar isso, esta é uma grande vitória - muito feliz que isso foi adicionado. Eu o ativei ontem e estou monitorando.
Até agora, parece estar funcionando 100% como pretendido e resolve este problema inteiramente. As pessoas ainda podem se registrar com pontos em seus e-mails (e presumivelmente +, não vi esses registros recentemente). Mas não podem continuar criando contas com variações do mesmo gmail. Pela leitura da discussão no GitHub, foi definitivamente a melhor escolha manter o e-mail original como está.
Dito isso, deixarei sugestões aqui que acho que melhorariam este recurso sem se tornar excessivamente complicado:
Em vez de ter uma caixa de seleção para ativar/desativar normalizar e-mails. Tenha duas listas, semelhantes ao estilo da lista de bloqueio de domínio de e-mail.
Por exemplo:
O administrador adiciona gmail.com a ambas as listas de normalização de domínio.
e.mai.l+123@gmail → email@gmail.com
O usuário adiciona outlook.com apenas à lista de normalização de +:
us.er+123@outlook.com → us.er@outlook.com
E-mails us.er@email.com e user@email.com sendo o mesmo endereço/conta é específico para alguns provedores e não é realmente padrão. Enquanto + parece ser um padrão (para qualquer provedor que o permita).
Isso permitiria aos administradores aplicar seletivamente essas regras individualmente a domínios de e-mail problemáticos à medida que surgem, em vez de aplicar a normalização (de ambos os tipos) a todos os domínios de e-mail.
Não tenho expectativas para o acima, apenas deixando a sugestão caso seja útil.
De qualquer forma, obrigado novamente, realmente muito grato por isso ter sido implementado. É um divisor de águas.
No entanto, eu me pergunto se este é um problema teórico versus um problema do mundo real. Entendo o desejo por fidelidade, mas preferiria ouvir sobre alguns casos específicos em que isso está causando um problema.
O problema de introduzir uma configuração como essa seria reaplicar as regras de normalização ao mexer na lista de permissões de sites, o que tornaria a mudança muito complexa.
Agora normalizamos incondicionalmente (independentemente da configuração do site), então ativá-la é instantâneo e se aplica a todo o histórico.
Incrível 
Todos os créditos para @nbianca
Incrível! Eu não percebi que isso se aplicaria retroativamente. Eu estava pensando que um endereço normalizado estava sendo salvo apenas para novos registros.
Sim, a principal chance de um problema seria para casos de endereços de e-mail que permitem aliases de ‘+’ mas não consideram períodos em diferentes posições como iguais.
Todas as instâncias de ‘+’ em e-mails podem ser tratadas da mesma forma, sem problemas, pois é tratado da mesma forma para todos os provedores que o permitem, até onde sei. Períodos são os únicos onde há alguma diferença entre provedores.
Se bem me lembro, acho que e-mails de trabalho do Google (usando domínios personalizados), Yandex e Outlook considerarão diferentes posições de período como endereços diferentes, mas os aliases ‘+’ ainda podem ser usados.
Portanto, os únicos casos seriam como deles@email.com existente bloquearia os.seus@email.com de se registrar (quando estas são na verdade duas contas/endereços únicos de acordo com esse domínio/provedor de e-mail). O que provavelmente deveria ser muito raro de ocorrer no mundo real. 
Este tópico foi fechado automaticamente após 16 horas. Novas respostas não são mais permitidas.