¿Por qué asumir una dependencia tan compleja cuando un modo de bloqueo trivial basado en direcciones de correo electrónico es mucho más sencillo de implementar y de analizar? Además, ahora nos expone a nuevas vulnerabilidades. ¡No, gracias!
Dada la rareza de esta queja y las circunstancias excepcionales que la rodean, creo que es preferible optar por el camino simple y más estricto.
La solución sencilla de prohibir cualquier cosa que no sea /a-zA-Z0-9/ funciona, pero tiene graves problemas de usabilidad: muchas personas no sabrán cómo registrarse y necesitaríamos nuevos mensajes de error. Muchas personas que usan Gmail no saben que janedoe@gmail.com funciona como su correo electrónico cuando siempre pensaron que era jane.doe@gmail.com. La prohibición afectaría a OAuth y provocaría que el inicio de sesión con Gmail fallara para que funcione correctamente.
Correo electrónico:
sam.s@gmail.com
ERROR:.no está permitido en las direcciones de correo electrónico (nuevo mensaje)
La normalización es menos hostil para el usuario y no requiere ninguna nueva experiencia de usuario (UX).
Podríamos comenzar con un normalizador opcional más simple (eliminar la etiqueta, eliminar el punto para Gmail).
Dicho esto, para ser 100% claro, no estoy sugiriendo una dependencia aquí; email_address está roto y no es adecuado para lo que queremos hacer.
Una medida a medias apresurada aquí simplemente creará una configuración de sitio “romper el correo electrónico en mi sitio”, a la que no estoy particularmente interesado en añadir.
Correcto, pero su sitio está bajo asedio. Miles de estas cuentas duplicadas se registran cada día. Por lo tanto, es sensato que exista un modo de bloqueo simple para direcciones de correo electrónico, para ofrecerlo a sitios que están en guerra con el Mossad y que están perdiendo estrepitosamente.
La guerra requiere sacrificios. Habrá víctimas civiles. Su sitio ya está roto hasta la médula.
Idealmente, necesitarías una tabla con los proveedores de correo electrónico y cómo “limpiar” según cada uno (exactamente lo que citaste). Como Bart explicó bien, no se trata de impedir el uso de cualquier dirección de correo por algunos caracteres, sino de poder detectar qué direcciones son realmente las mismas.
Claro, los spammers que realmente quieran siempre podrán hacerlo. Es como con las alarmas/cerraduras y los ladrones: la idea es hacerlo más difícil.
Crear x direcciones de Gmail es spam para Gmail; eso es un problema que ellos deben resolver (incluso si luego se puede usar para enviarte spam).
No estoy siguiendo.
Si tratamos bob.test+100@gmail.com como bobtest@gmail.com internamente y lo almacenamos de esa manera (cuando el interruptor está activado), ¿qué sacrificio se está haciendo exactamente aquí?
El error es específicamente con gmail, así que para mí parece una reacción exagerada prohibir todos los puntos en todas partes porque Google decidió inventar una especificación y normalizar. La lógica para limpiar es bastante sencilla y esto sería opcional, desactivado por defecto.
@Mevo, solo para estar 100% claro aquí, la propuesta de Jeff es que agreguemos un “modo desastre”; en el modo desastre, bob.test@gmail.com es un correo electrónico inválido que no se puede usar.
Sugeriría compararlo con la forma simplificada, pero debes tener cuidado de seguir almacenando y retransmitiendo los correos electrónicos a la dirección especificada originalmente.
No tienes el consentimiento del usuario para enviar mensajes a cualquier otra variación, y usar cualquier dirección distinta a la que ellos especifican podría hacer que no reciban el mensaje.
Como ejemplo, tengo una dirección de Gmail que se creó en los primeros meses del servicio. Los correos dirigidos al alias base se descartan efectivamente. Solo los correos que llegan a direcciones con sufijo específico (plus addressing) serán vistos.
Ten cuidado también con las suposiciones: muchos usuarios de Gmail no saben que los puntos son opcionales. La gran mayoría nunca ha oído hablar del direccionamiento con sufijo (+). La clasificación para prevenir el abuso de este último corre el riesgo de causar daños a los usuarios del primero.
@sam Entendí perfectamente lo que Jeff quiere decir y, al igual que tú, me opongo a lo que propone (sin ofenderlo, los desacuerdos son normales).
Esto puede parecer un detalle minucioso, pero almacenar solo la dirección de correo electrónico “limpia” eliminará lo que algunos usuarios legítimos hacen intencionalmente. Por ejemplo: un usuario que se registra (totalmente de forma legítima y solo una vez) con bob+meta@example.com o bob+forums@example.com perderá lo que intentaba lograr. El problema es que solo recibirá correos en bob@example.com, y eso no es lo que quería (puede usar, por ejemplo, la “etiqueta” para organizar los correos recibidos en una carpeta específica).
Entiendo perfectamente que tener esto en cuenta lo haría un poco más complejo. Tendrías que almacenar AMBAS versiones: la que ingresó el usuario (para enviar correos) y la versión limpia. Podrías usar la versión limpia tal como usas las direcciones de correo electrónico ahora (para todo lo relacionado internamente con el usuario y para verificar si ese usuario ya está registrado). Además, para evitar ese pequeño problema, necesitarías almacenar lo que ingresó el usuario, además de eso (únicamente para usarlo al enviar correos). Sería el equivalente a la dirección “Responder a” en los correos electrónicos.
Espero que sea comprensible.
EDIT: Escrito al mismo tiempo que @Stephen (en líneas generales la misma idea)
Este es un punto muy válido; de hecho, hace que esto sea un poco más complicado de implementar.
Supongo que solo realizarías la verificación al “crear una nueva cuenta”:
¿Ya existe alguna dirección de correo electrónico en el sistema con esta forma canónica? Si es así, lo sentimos, no se puede crear una nueva cuenta para ti.
Existe un problema secundario relacionado con Google OAuth (¿también verificaría el correo electrónico canónico?) y la transición de una dirección no canónica a una canónica.
Según tengo entendido, OAuth no funciona con el direccionamiento con «+», ¿así que no estaría fuera del alcance?
Me refiero a que no puedo crear una cuenta nueva usando Google, especificar un alias diferente y repetir el proceso.
Mismo espacio de problema.
Me registro con sam+hi@gmail.com… luego hago clic en el botón de iniciar sesión con Google, ¿qué sucede?
Actualmente: se crea una nueva cuenta
Propuesto:
Opción A: pantalla de error, no puedes crear esta cuenta
Opción B: el usuario inicia sesión con sam+hi@gmail.com
Modo de bloqueo propuesto originalmente: sam.test@gmail.com no puede iniciar sesión con el botón de iniciar sesión con Google.
Asumiendo que puedes idear una traducción robusta para eliminar las direcciones con alias y los puntos erróneos, ¿podrías simplemente mantener un hash del correo electrónico desduplicado y compararlo con la creación de esa cuenta?
Esa es la opción B, por lo tanto Hay un problema secundario con Google OAuth 
Además, el problema de migración es complejo, pero probablemente se pueda omitir.
Dicho esto, dado el alcance del problema en la práctica, no anticipamos realizar ningún cambio en este aspecto en los próximos meses.
Como se dijo anteriormente, ¿no sería una solución utilizar únicamente la versión “canónica” internamente y almacenar además lo que el usuario ingresó (solo para enviar correos electrónicos)?
Podemos resolver esto sin problemas; calculo que se necesitan entre 2 y 6 días de trabajo en pruebas y depuración de este nuevo interruptor, ya que hay muchos detalles pequeños que considerar.
El problema aquí es que @codinghorror no puede justificar presupuestar esta cantidad de tiempo para esta función.
Podemos implementar romper un gran montón de inicios de sesión por correo electrónico en un día de trabajo, pero no quiero tener tal configuración en Discourse.
Así que estás en un aprieto, @Mevo… más personas necesitan experimentar y reportar este problema para que podamos justificar invertir el tiempo en esto.
@sam, lo entiendo.
(incidentalmente, esto es la primera vez que lo veo. Tu publicación fue editada automáticamente: " [system] — Se eliminó automáticamente la cita de la publicación anterior completa". ¡Guau! ¡Esa es una funcionalidad muy buena!)
Debes tener mucho cuidado y nunca almacenar la versión canónica. El usuario no dio su consentimiento para proporcionarla y, si se ven comprometidas tus tablas de usuarios, no podrán identificar fácilmente qué servicio ha comprometido sus datos.
Facebook ha tenido repetidamente serios problemas al almacenar información de identificación personal (PII) relacionada con usuarios que no proporcionaron dicha información ni dieron su consentimiento para que se asociara con su cuenta.
Personalmente, no veo ningún problema con esta configuración; simplemente me repugna hacerlo porque ‘ese tipo tuvo un problema en una ocasión’.
Sí, esto es algo terrible sugerir que añadamos a Discourse. Me opondría con violencia a su inclusión. Además, el direccionamiento es una característica, siempre lo ha sido, y es amigable para el usuario.
Si estás siendo atacado por el Mossad… activa el Modo de Ataque del Mossad. Supongo que solo necesitamos que el Mossad ataque a más personas, ¿no? 
Estoy totalmente en contra de agregar esta configuración a Discourse. Me parece bien que alguien cree un plugin para ello; solo son unas pocas líneas de código en un plugin. Si es absolutamente necesario, haré una pausa y desarrollaré el plugin hoy mismo; avísame.
Es un poco inútil construirlo, ya que la única persona que tiene el problema ya ha dicho que no lo usará.
Una configuración que dice «rompe mi Discourse» es fundamentalmente mala y, en mi opinión, no debería formar parte del producto.
Creo que si más personas tuvieran el problema, un modo de bloqueo por correo sería más defendible. Pero ahora mismo es solo ese tipo en ese sitio.
Así que esperamos a ver…
Un tipo, en un sitio, que no usaría la función
…es más preciso.