El caso es que forzar correos canónicos es prácticamente lo mismo, pero mucho menos hostil para el usuario.
No se permite Sam.sam@gmail.com porque Sa.msam+123@gmail.com ya está registrado.
De todas formas, podemos implementar una expresión regular en la próxima versión.
Sí, pero es inútil en la práctica real, por eso estamos teniendo esta discusión… una vez que tienen armas nucleares, tú también necesitas tenerlas.
“Hostil para el usuario” es un concepto sin sentido una vez que tu audiencia tiene armas nucleares y está dispuesta a usarlas.
No estoy de acuerdo con esto; la solución funcionó perfectamente para @markersocial, y luego revertí el cambio porque me obligaron a hacerlo.
No hay brechas conocidas con el enfoque de canonicalización que implementé y luego revertí; resuelve el problema de Gmail mencionado anteriormente en un 100%.
Bueno, discrepo, porque eso traslada la carga de código y esfuerzo a nuestro lado en lugar del suyo. «Normalizar» correos electrónicos es bastante complicado, varía según el proveedor de correo y no quiero dedicarme a eso.
En otras palabras, dejad que ellos construyan y gestionen sus propios dispositivos nucleares; no necesitamos enviar protobombas nucleares a cada país ni en cada instalación de Discourse «por si acaso».
(Además, poder bloquear correos electrónicos mediante expresiones regulares es muy potente, especialmente porque en Discourse el correo electrónico equivale a la identidad.)
Podríamos permitirles que normalicen con sus propias reglas de expresiones regulares como una especie de punto medio, de modo que nosotros no nos ocupemos de la normalización. Dicho esto, sí, el bloqueo por expresiones regulares o al menos el bloqueo con comodines se implementará en la próxima versión.
Puedo confirmar que la implementación anterior funcionó perfectamente y resolvió por completo el problema de Gmail. Tanto la lista de dominios de correo permitidos como la de bloqueados son medidas muy efectivas. Sin embargo, bloquear Gmail simplemente no es viable.
@codinghorror Entiendo el punto de vista en contra de normalizar para diferentes proveedores de correo. Pero creo que tendría sentido poder cubrir al menos a Gmail (~43% de todas las direcciones de correo según datos de 2020, 53% en EE. UU.) de una manera no destructiva. Podría ser comparable a ofrecer soporte nativo para OAuth de grandes proveedores.
@sam ^ Esta es una excelente idea como alternativa. 
Quizás esto, junto con un ejemplo para la coincidencia de gmail/googlemail, podría ser muy amigable para el usuario y potente.
Actualmente tengo un usuario que ha creado varios miles de cuentas con una única dirección de Gmail (usando puntos) y está haciendo spam para promocionar su sitio competidor y desviar usuarios. Actualizaremos a la versión 2.8 y bloquearemos todas las direcciones de correo que contengan un punto o el símbolo + tan pronto como se lance. Ojalá la implementación anterior estuviera disponible, pero agradezco que se esté abordando este problema y que habrá una solución. Esto marcará una gran diferencia, ¡gracias!
He pensado un poco en esto y se me ocurrió una solución que podría tener sentido.
Podría haber una opción de administrador para procesar y almacenar una versión normalizada del correo electrónico (procesando solo la parte del nombre de usuario, es decir, usuario@…).
Pero aplicar esto solo a los dominios especificados por el administrador.
Entonces, una lista similar a las listas de permitidos/bloqueados de dominios de correo, con dos casillas de verificación por dominio:
Luego, usar estos registros como referencia para denegar registros adicionales que utilicen versiones alternativas de ese correo electrónico (sin afectar el registro principal del correo, que aún puede tener + y puntos).
De esta manera, la carga de seleccionar qué dominios almacenar como registros normalizados y cómo normalizarlos recae únicamente en el administrador, permitiéndole responder a los dominios de correo problemáticos a medida que surgen.
En cualquier caso, solo lo dejo aquí para que pueda ser considerado en algún momento.
Saludos.
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.
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
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.
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.
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
¡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. 
Este tema se cerró automáticamente después de 16 horas. Ya no se permiten nuevas respuestas.