The thing is forcing canonical emails is effectively the same except that it is far less user hostile.
No Sam.sam@gmail.com is allowed Sa.msam+123@gmail.com is already registered
Anyway we can do regex next release
2 curtidas
Yeah, but it’s useless in actual practice, which is why we’re having this discussion… once they have nukes, you need nukes too.
“User hostile” is a meaningless concept once your audience has nukes and is willing to use them.
I disagree with this, the solution worked perfectly for @markersocial, and then I reverted the change cause my hand was forced
There are no known gaps with the canonicalization approach I implemented and reverted, it solves the above gmail problem 100%
3 curtidas
Well, I disagree, because that put the code and effort burden on our side, rather than their side. “Normalizing” emails is quite complicated, varies per email provider, and I don’t want to be in that business.
In other words, let them build and handle the nuclear devices on their own; we don’t need to ship proto-nukes to every country and in every installation of Discourse “just in case”.
(Plus being able to blocklist emails via regex is quite powerful, especially since email = identity in Discourse.)
1 curtida
We could let them normalise with their own regex rules as some sort of middle ground, then we are not in the business of normalisation
That said yes regex blocking or at least wildcard blocking will happen for the next release
6 curtidas
I can confirm that the previous implementation worked perfectly and entirely solved the gmail issue. The email domain allow list and disallow list both are quite effective nukes. But it’s just not viable to block gmail.
@codinghorror I can see the point of view against normalising for different email providers. But I think it would make sense to be able to cover at least gmail (~43% of all email addresses apparently in 2020, 53% for the US) in a non-destructive way. It might be comparable to supporting oauth from large providers out of the box.
@sam ^ This is a great idea for an alternative. 
Maybe this, with an example for the gmail/googlemail match could be quite user friendly and powerful.
2 curtidas
Have a user right now that has made several thousand accounts with a single gmail address (using periods) and spamming promoting their competing site to siphon off users. Will be upgrading to 2.8 and blocking all emails that contain a period or plus symbol as soon as it’s released. I do wish the previous implementation was available, but appreciate that this is being addressed and a solution will be available. It’s going to make a massive difference, thank you 
1 curtida
So have thought about this a bit and thought of a solution that could maybe make sense.
There could be an admin option to process and store a normalised version of the email (only processing the username part i.e. username@…)
But only apply this for domains that are specified by the admin.
So a list somewhat like the email domain allow/block lists, with two checkboxes per domain:
- Strip + string
- Strip periods
Then use these records as a reference for disallowing additional registrations using alternative versions of that email (without affecting the primary email record, which can still have + and periods).
This way, the burden of selecting which domains to store a normalise record for and how to normalise them can be on the admin only, allowing them to respond to problematic email domains as they emerge.
Anyhow, just dropping this here so it can perhaps be considered at some point.
Cheers.
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.
7 curtidas
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
4 curtidas
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.
- Lista de domínios para aplicar normalização de pontos
- Lista de domínios para aplicar normalização de +
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.
2 curtidas
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
4 curtidas
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. 
2 curtidas
Este tópico foi fechado automaticamente após 16 horas. Novas respostas não são mais permitidas.