My forum just receive a large number of spaming user registration.
He/She using Gmail dot tricks ( http://www.makeuseof.com/tag/1-awesome-gmail-tip-you-dont-know-about-seriously/) to create this large number of email account.
Can you prohibid this trick ?
My discourse is using Cloudflare at a CDN and DNS provider, Discourse can’t work fine caused the IP thing.
Couldn’t you ban their IP instead?
Hum, I’m using Cloudflare for CDN, and discourse only see Cloudflare, not user’s IP. (in Wordpress, Cloudflare has an plugin to pass the user IP to website)
At vB we used to get literally thousands of bot “seed” accounts like
aliasg.maila.ccount
alia.sgmai.laccount
ali.asg.mailacco.unt
alias.g.m.ailaccount
al.iasgmai.lacc.ount
… etc. ad nauseum
We eventually had a plugin written to deal with them
Yeah you’re going to need to turn that off, or figure out how to get CloudFlare to send proper headers for the passthrough IP.
Yes. I’m working on that by config Nginx.
Cloudflare actually sends user’s IP via header HTTP_CF_CONNECTING_IP
But prohibid gmail dot trick is useful too.
You really need to get IP passed through correctly otherwise you are really screwed. That’s about the only effective way to stop spammers, if they are clever.
While in this case banning the IP is the right thing to do, I think there is merit in being able to stop user.name@gmail.com and username@gmail.com from being both registered as two different users at any given discourse forum.
No sane administrator should allow this behaviour (from gmail) and maybe we could have an option to extend this prohibition to other email providers as well.
It would need a simple list like ‘@gmail.com’, ‘@anotherprovidder.com’ and then it would check for registered users by removing the dot or any other relevant character (could have a list as well) to avoid users that want to have two or more accounts.
Maybe a plugin with this functionality would be the best solution.
Definitely make it optional if you do it at all. I depend on this trick for troubleshooting!
¡Estamos siendo absolutamente abrumados con este tipo de registros y el spam que publican! 
mycoolgmailaddress4spam+unlimitedcombinationslol@gmail.com
m.ycoo.lgm.ailaddress4s.pam@gmail.com
Desafortunadamente, estamos indefensos ante estos registros. La única defensa es no ser objetivo de spammers con alguna habilidad.
Objetivamente, no hay forma de bloquear a un spammer con suficientes IPs para crear 100,000 cuentas usando una sola dirección de Gmail en cualquier foro estándar de Discourse con estos trucos.
Todas las configuraciones de limitación de spam/publicación son inútiles cuando los spammers tienen acceso a cuentas ilimitadas con una sola dirección de Gmail.
Es extraño que tu sitio tenga un problema tan grave con esto, cuando no recuerdo que haya ocurrido ni una sola vez en nuestros más de 1.000 clientes alojados durante los últimos 4 años.
@codinghorror ¿Crees que esto se debe a defensas suficientes contra esta técnica común de spam o a que esos sitios no son objetivo de los spammers? ¿Esos sitios reciben volúmenes regulares y grandes de intentos de registro de spam de cualquier tipo que son bloqueados por las defensas?
Depende en gran medida del nicho, los volúmenes de tráfico y si es adecuado para sus campañas de respuesta directa. Un spammer que puede mantener publicaciones cerca de la parte superior de la lista de publicaciones está esencialmente obteniendo un espacio publicitario fantástico por centavos. El espacio publicitario en la página principal, por encima del pliegue, puede valer comúnmente entre $xxx y $x,xxx por día, dependiendo del nicho y del volumen de tráfico.
Los spammers que generan ganancias significativas mensuales al realizar campañas de respuesta directa en un foro específico, y que pueden vivir en países en desarrollo con salarios locales promedio extremadamente bajos, podrían estar motivados.
Tengo varios otros foros de Discourse en funcionamiento desde 2015-2016 y prácticamente no tienen problemas con registros o publicaciones de spam, debido a que no han sido objetivo. No ser objetivo de los spammers es una buena defensa, hasta que te conviertes en objetivo. Hasta donde sé, Discourse no es compatible de forma predeterminada con la mayoría del software de spam para foros disponible comercialmente, como Xrumer.
Bueno, hay una regla que me gusta citar.
Si te conviertes en un objetivo individual del Mossad, estás jodido.
Es cierto, un spammer dedicado siempre logrará colarse. Hemos visto cómo abren sus propios servidores de correo y generan direcciones de correo electrónico por miles: buena suerte con eso.
Dicho esto, ¿no parece una precaución razonable no permitir registros duplicados utilizando estos trucos de Gmail?
@codinghorror - Hahaha, me encanta. Aunque preferiría no rendirme y morir sin más. 
No creo que esto sea un caso excepcional; muchos sitios sociales no permiten registrarse con la misma dirección de Gmail debido al abuso de spammers. Por lo que sé, la mayoría de los grandes no lo permiten.
@bartv - Sí, con aquellos que tienen sus propios servidores de correo, al menos podemos bloquear sus dominios como una defensa bastante efectiva (aunque las cuentas que lograron pasar antes del bloqueo siguen siendo utilizables). Pueden conseguir más dominios, pero al menos eso les cuesta recursos, a diferencia de los trucos con Gmail.
Con estos trucos de Gmail, realmente no hay ninguna defensa y las variaciones adicionales de direcciones no cuestan nada al spammers. Los ‘correos de spammers basados en la distancia de Levenshtein’ pueden ayudar en cierta medida con el truco de los puntos después de haber prohibido muchas veces la misma dirección de Gmail en diferentes combinaciones de puntos. Sin embargo, actualmente no podemos defendernos del truco del signo +, que permite esencialmente combinaciones ilimitadas.
A menos que tengas amigos lo suficientemente influyentes que puedan ayudarte. Y ese es el equipo de desarrollo de Discourse, aquí (y quizás la comunidad, si pensamos en complementos).
Lo siento, pero ¿no sería bueno que Discourse tratara todas las direcciones de Gmail sin los puntos y lo que viene después del signo +? No parece técnicamente muy complicado. Son solo unas pocas líneas de código bastante simples. Registro => detecta gmail.com después del signo @ => elimina todos los puntos y lo que viene después del signo + hasta el signo @, y usa esa dirección => ¿Ya está en uso? => Devuelve un mensaje de error “La dirección de correo electrónico ya está en uso”.
Listo. ¿O me estoy perdiendo algo?
Si los spammers empiezan a saber que esto funciona con Discourse, van a apuntar cada vez más a foros de Discourse con esa técnica. Quiero decir, ¿por qué no lo harían?
Establecimos que los nuevos usuarios debían tener todos sus temas/publicaciones aprobados manualmente durante las primeras X veces, y eso eliminó el problema casi de la noche a la mañana. Algunos de ellos descubrieron que editar sus publicaciones después de hecho funcionaba, hasta que ajustamos eso también para los niveles de confianza 0 y 1.
Aunque esto no tiene nada específicamente que ver con ningún truco de dominio en particular, interrumpe el problema real, que es una persona motivada tratando de eludir tus contramedidas. Si no pueden usar un “truco” de Gmail, encontrarán algún otro truco. El nivel de confianza 1 puede publicar y el nivel de confianza 1 requiere 5 minutos de tiempo de lectura es el tipo de cosa hacia la que me inclinaría personalmente.
Bueno, veamos. ¿Qué caracteres se pueden usar aquí?
Algunos servicios de correo admiten una etiqueta incluida en la parte local, de modo que la dirección es un alias de un prefijo de dicha parte. Por ejemplo, la dirección
joeuser+tag@example.comdenota la misma dirección de entrega quejoeuser@example.com. El RFC 5233 se refiere a esta convención como subdireccionamiento, pero también se conoce como direccionamiento con signo más, direccionamiento etiquetado o extensiones de correo.Las direcciones de este formato, que utilizan diversos separadores entre el nombre base y la etiqueta, son compatibles con varios servicios de correo electrónico, incluidos Runbox (signo más), Gmail (signo más), Rackspace Email (signo más), Yahoo! Mail Plus (guion), iCloud de Apple (signo más), Outlook (signo más), ProtonMail (signo más), FastMail (signo más y direccionamiento por subdominio), MMDF (signo igual), Qmail y Courier Mail Server (guion). Postfix y Exim permiten configurar un separador arbitrario del conjunto de caracteres legales.
Así que tenemos: signo más, guion, signo igual, punto y almohadilla.
Lo único que se me ocurre que podría funcionar aquí es una configuración extremadamente estricta para bloquear todos los caracteres fuera de A-Z, a-z y 0-9 en las direcciones de correo electrónico.
Definitivamente evitará que algunos usuarios se registren, pero podría ser un compromiso viable si estás siendo… eh… atacado por agentes de élite del Mossad, supongo 
¿Qué opinas @eviltrout?
Eso podría ser demasiado estricto; el punto aquí es evitar el uso múltiple de variaciones de direcciones de correo electrónico, no prohibirlas por completo. En su lugar, podrías agregar una dirección de correo electrónico «canónica» a cada cuenta que contenga la versión depurada de la dirección de correo electrónico real del usuario. Compara la versión depurada de las direcciones de correo electrónico de los nuevos registros con este valor. Aunque probablemente sea más fácil decirlo que hacerlo…
Sí, prefiero el cambio sugerido por Bart aquí.
[ ] usar una forma canónica para el almacenamiento interno de direcciones de correo electrónico (elimina +CUALQUIERA, quita comentarios, etc.).
Proporciona una implementación en Ruby de la que podríamos tomar prestado, pero tendríamos que ser muy, muy, muy cuidadosos (el ejemplo 1 es un riesgo de seguridad según: https://stackoverflow.com/a/52125295/17174)
EmailAddress.canonical("(test)sam.saffron(test)+100@gmail.com")
=> "test@gmail.com"
[3] pry(main)> EmailAddress.canonical("sam.saffron(test)+100@gmail.com")
=> "samsaffron(test)@gmail.com"
[4] pry(main)> EmailAddress.canonical("sam.saffron+100@gmail.com")
=> "samsaffron@gmail.com"
Por lo tanto, sugiero que nuestra función de «canonización»:
Elimine +CUALQUIERA
Convierta a minúsculas (ya lo hacemos cumplir)
SI es gmail, googlemail o está en una lista blanca personalizada, elimine los puntos
Elimine los comentarios. (...) que también son un vector para abusos.
Normalice en Unicode la dirección, lo cual está técnicamente permitido según: Email address - Wikipedia
Luego, agregue una configuración oculta del sitio con una lista blanca de dominios para la eliminación de ..
Dicho esto, hay muchas formas de abusar de esto; de hecho, alguien podría tener un caché de 10.000 direcciones de correo de spam de Gmail y simplemente registrarse con todas ellas usando algún tipo de bot. Si estás siendo objetivo, mejor aprueba cada nuevo registro durante un tiempo; quizás este sea uno de esos casos raros donde quieras un recaptcha en el registro mediante un plugin.