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 Me gusta
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 Me gusta
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 me gusta
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 Me gusta
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 Me gusta
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 me gusta
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.
He fusionado la PR:
Añade una nueva configuración del sitio normalize emails que eliminará los puntos y la parte +… de un correo electrónico y luego verificará su singularidad. Por ejemplo, si hay un usuario test+1@gmail.com e intenta registrarse test+2@gmail.com, no se les permitirá si la configuración del sitio está habilitada.
7 Me gusta
Fantástico, creo que esto resuelve al 100% el problema de @markersocial y es una excelente configuración para habilitar si terminas siendo un objetivo de este ataque específico.
Háganos saber cómo le va, @markersocial
4 Me gusta
Muchas gracias por implementar esto, es una gran victoria. Estoy muy contento de que se haya añadido. Lo puse en producción ayer y lo estoy monitoreando.
Hasta ahora, parece que está funcionando al 100% según lo previsto y resuelve este problema por completo. La gente todavía puede registrarse con puntos en sus correos electrónicos (y presumiblemente +, no he visto estos registros recientemente). Pero no pueden seguir creando cuentas con variaciones del mismo gmail. Leyendo la discusión en GitHub, definitivamente fue la mejor opción mantener el correo electrónico original tal cual.
Dicho esto, dejaré aquí algunas sugerencias que creo que mejorarían esta función sin ser demasiado complicadas:
En lugar de tener una casilla de verificación para activar/desactivar la normalización de correos electrónicos. Tenga dos listas, similares al estilo de la lista de bloqueo de dominios de correo electrónico.
- Lista de dominios para aplicar la normalización de puntos
- Lista de dominios para aplicar la normalización de +
Por ejemplo:
El administrador agrega gmail.com a ambas listas de normalización de dominios.
e.mai.l+123@gmail → email@gmail.com
El usuario agrega outlook.com a la lista de normalización de + (solo):
us.er+123@outlook.com → us.er@outlook.com
Los correos electrónicos us.er@email.com y user@email.com que son la misma dirección/cuenta son específicos de algunos proveedores y no son realmente estándar. Mientras que + parece ser un estándar (para cualquier proveedor que lo permita).
Esto permitiría a los administradores aplicar selectivamente estas reglas individualmente a los dominios de correo electrónico problemáticos a medida que surgen, en lugar de aplicar la normalización (de ambos tipos) a todos los dominios de correo electrónico.
No tengo expectativas para lo anterior, solo dejo la sugerencia en caso de que sea útil.
De todos modos, gracias de nuevo, realmente aprecio que esto se haya implementado. Cambia las reglas del juego.
2 Me gusta
Sin embargo, me pregunto si este es un problema teórico frente a uno del mundo real. Entiendo el deseo de fidelidad, pero preferiría escuchar sobre algunos casos específicos en los que esto está causando un problema.
El problema de introducir una configuración como esta sería volver a aplicar las reglas de normalización cuando se manipula la lista de sitios permitidos, lo que haría que fuera un cambio muy complejo.
Ahora normalizamos incondicionalmente (independientemente de la configuración del sitio), por lo que activarlo es instantáneo y se aplica a todo el historial.
Genial 
Todo gracias a @nbianca
4 Me gusta
¡Genial! No me di cuenta de que se aplicaría retroactivamente. Pensé que solo se guardaría una dirección normalizada para los nuevos registros.
Sí, la principal posibilidad de un problema sería en casos de direcciones de correo electrónico que permiten alias “+” pero no consideran los puntos en diferentes ubicaciones como iguales.
Todas las instancias de “+” en los correos electrónicos se pueden manejar de la misma manera sin ningún problema, ya que se manejan de la misma manera para todos los proveedores que lo permiten, hasta donde yo sé. Los puntos son los únicos en los que hay alguna diferencia entre proveedores.
Si mal no recuerdo, creo que los correos electrónicos de trabajo de Google (que usan dominios personalizados), Yandex y Outlook considerarán que diferentes ubicaciones de puntos son direcciones diferentes, pero los alias “+” aún se pueden usar.
Por lo tanto, los únicos casos serían como que theirs@email.com existente bloquearía el registro de the.irs@email.com (cuando estas son en realidad dos cuentas/direcciones únicas según ese dominio/proveedor de correo electrónico). Lo cual probablemente debería ser muy raro que ocurra en el mundo real. 
2 Me gusta
Este tema se cerró automáticamente después de 16 horas. Ya no se permiten nuevas respuestas.