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!
Complètement submergé par ce genre d’inscriptions et le spam qu’elles génèrent. 
mycoolgmailaddress4spam+unlimitedcombinationslol@gmail.com
m.ycoo.lgm.ailaddress4s.pam@gmail.com
Malheureusement, nous sommes sans défense contre ces inscriptions. La seule protection est de ne pas être ciblé par des spammeurs compétents.
Il n’existe objectivement aucun moyen de bloquer un spammeur disposant d’un nombre suffisant d’adresses IP pour créer 100 000 comptes à partir d’une seule adresse Gmail sur un forum Discourse standard en utilisant ces astuces.
Tous les paramètres de limitation du spam et des publications sont inutiles lorsque les spammeurs ont accès à un nombre illimité de comptes avec une seule adresse Gmail.
C’est étrange que votre site ait un problème aussi grave avec cela alors que je ne me souviens pas d’un seul cas où cela s’est produit parmi nos quelque 1 000 clients hébergés au cours des 4 dernières années ?
@codinghorror Pensez-vous que cela soit dû à des défenses suffisantes contre cette technique de spam courante, ou au fait que ces sites ne sont pas ciblés par les spammers ? Ces sites reçoivent-ils régulièrement de gros volumes de tentatives d’inscriptions spam de toute nature, qui sont bloquées par les défenses ?
Cela dépend beaucoup de la niche, des volumes de trafic et de l’adéquation avec leurs campagnes de réponse directe. Un spammeur capable de maintenir ses publications en haut de la liste obtient essentiellement un excellent espace publicitaire pour quelques centimes. L’espace publicitaire en haut de page d’accueil peut couramment valoir entre xxx et x,xxx par jour, selon la niche et le volume de trafic.
Les spammeurs qui réalisent des bénéfices mensuels importants en diffusant leurs campagnes de réponse directe sur un forum spécifique, et qui peuvent vivre dans des pays en développement avec des salaires locaux moyens extrêmement bas, peuvent être motivés.
J’ai plusieurs autres forums Discourse en fonctionnement depuis 2015-2016, et ils ne rencontrent pratiquement aucun problème d’inscriptions ou de publications spam, car ils ne sont pas ciblés. Le fait de ne pas être ciblé par les spammeurs est une bonne défense, tant que vous ne l’êtes pas. À ma connaissance, Discourse n’est pas pris en charge par défaut dans la plupart des logiciels commerciaux de spam de forum, comme Xrumer.
Eh bien, il y a une règle que j’aime citer.
Si vous êtes individuellement visé par le Mossad, vous êtes foutu.
C’est vrai, un spammeur déterminé finira toujours par passer. Nous en avons vu ouvrir leurs propres serveurs de messagerie et générer des milliers d’adresses e-mail — bonne chance pour les bloquer.
Cela dit, interdire les inscriptions dupliquées en utilisant ces astuces Gmail semble-t-il une précaution raisonnable ?
@codinghorror - Hahaha, j’adore. Je préférerais tout de même ne pas simplement me coucher et mourir. 
Je ne pense pas que ce soit un cas limite ; de nombreux sites sociaux interdisent l’inscription avec la même adresse Gmail en raison des abus des spammeurs. Pour autant que je sache, la plupart des grands sites ne l’autorisent pas.
@bartv - Oui, pour ceux qui ont leurs propres serveurs de messagerie, nous pouvons au moins bannir leurs domaines, ce qui constitue une défense assez efficace (bien que les comptes qui ont réussi à passer avant le bannissement restent utilisables). Ils peuvent obtenir d’autres domaines, mais cela leur coûte au moins des ressources, contrairement aux astuces Gmail.
Avec ces astuces Gmail, il n’y a vraiment aucune défense et les variations d’adresse supplémentaires ne coûtent rien au spammeur. La « distance de Levenshtein » sur les e-mails des spammeurs peut aider dans une certaine mesure avec l’astuce du point, après avoir banni de nombreuses fois la même adresse Gmail avec différentes combinaisons de points. On ne peut pas se défendre actuellement contre l’astuce du +, qui permet essentiellement des combinaisons illimitées.
Sauf si vous avez des amis assez puissants pour vous aider. Et c’est le cas de l’équipe de développement de Discourse, ici (et peut-être de la communauté si l’on pense aux plugins).
Je suis désolé, mais ne serait-il pas une bonne chose pour Discourse de traiter toutes les adresses Gmail sans les points et ce qui suit le signe + ? Cela ne semble pas techniquement très compliqué. Ce ne sont que quelques lignes de code assez simples. Inscription => détecte gmail.com après le signe @ => supprime tous les points et ce qui suit le signe + jusqu’au signe @, et utilise cette adresse => Déjà utilisée ? => Retourne un message d’erreur « Adresse e-mail déjà utilisée ».
Fait. Ou est-ce que je manque quelque chose ?
Si les spammeurs commencent à savoir que cela fonctionne avec Discourse, ils vont cibler de plus en plus de forums Discourse avec cette technique. Je veux dire, pourquoi ne le feraient-ils pas ?
Nous avons configuré le système pour que les nouveaux utilisateurs doivent avoir tous leurs sujets/messages approuvés manuellement pendant les X premières fois, ce qui a résolu le problème presque du jour au lendemain. Certains ont constaté que la modification de leur message a posteriori fonctionnait, jusqu’à ce que nous ajustions également cela pour les niveaux de confiance 0 et 1.
Bien que cela n’ait rien de spécifiquement lié à une astuce de domaine particulière, cela perturbe le véritable problème, à savoir un humain motivé cherchant à contourner vos contre-mesures. S’ils ne peuvent pas utiliser une astuce « gmail », ils en trouveront une autre. Le fait que le niveau de confiance 1 puisse publier et que le niveau de confiance 1 nécessite 5 minutes de temps de lecture est le genre de mesure vers laquelle je m’orienterais personnellement.
Bon, voyons voir. Quels caractères peuvent être utilisés ici ?
Certains services de messagerie prennent en charge un tag inclus dans la partie locale, de sorte que l’adresse est un alias d’un préfixe de cette partie. Par exemple, l’adresse
joeuser+tag@example.comdésigne la même adresse de livraison quejoeuser@example.com. RFC 5233 fait référence à cette convention sous le nom de sous-adressage, mais elle est également connue sous le nom d’adressage plus, adressage tagué ou extensions de messagerie.Des adresses de ce type, utilisant divers séparateurs entre le nom de base et le tag, sont prises en charge par plusieurs services de messagerie, notamment Runbox (plus), Gmail (plus), Rackspace Email (plus), Yahoo! Mail Plus (tiret), iCloud d’Apple (plus), Outlook (plus), ProtonMail (plus), FastMail (plus et adressage par sous-domaine), MMDF (égal), Qmail et Courier Mail Server (tiret). Postfix et Exim permettent de configurer un séparateur arbitraire parmi l’ensemble des caractères légaux.
Nous avons donc : plus, tiret, égal, point et dièse.
La seule chose qui me vient à l’esprit pour que cela fonctionne ici, c’est un paramètre super strict pour empêcher tous les caractères en dehors de A-Z a-z 0-9 dans les adresses e-mail.
Cela empêchera certainement certains utilisateurs de s’inscrire, mais cela pourrait être un compromis viable si vous êtes… euh… visé par des agents d’élite du Mossad, je suppose 
Qu’en pensez-vous @eviltrout ?
Cela pourrait être trop strict ; l’objectif ici est d’empêcher l’utilisation multiple de variantes d’adresses e-mail, pas de les interdire complètement. Vous pourriez plutôt ajouter une adresse e-mail « canonique » à chaque compte, contenant la version nettoyée de l’adresse e-mail réelle de l’utilisateur. Vous comparez la version nettoyée des adresses e-mail lors des nouvelles inscriptions avec cette valeur. C’est probablement plus facile à dire qu’à faire, cependant…
Oui, je préfère la modification suggérée par Bart ici.
[ ] utiliser une forme canonique pour le stockage interne des adresses e-mail (supprime +QUOIQUE_CE_SOIT, retire les commentaires, etc.)
Fournit une implémentation Ruby que nous pourrions adapter, mais nous devrions être extrêmement prudents (l’exemple 1 présente un risque de sécurité selon : 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"
Je suggère donc que notre « canonisation » :
Supprime +QUOIQUE_CE_SOIT
Passe en minuscules (nous l’appliquons déjà)
SI c’est gmail, googlemail ou dans une liste blanche personnalisée, supprime les points
Supprime les commentaires. (...) qui constituent également un vecteur d’abus.
Normalise l’Unicode de l’adresse, ce qui est techniquement autorisé selon : Email address - Wikipedia
Ensuite, ajoutez un paramètre de site caché avec une liste blanche de domaines pour la suppression des ..
Cela dit, il existe de nombreuses façons d’abuser de cela. Quoi qu’il en soit, quelqu’un pourrait avoir un cache de 10 000 adresses e-mail spam et s’inscrire avec toutes via un bot. Si vous êtes la cible, vous pourriez tout aussi bien approuver chaque nouvel inscrit pendant un certain temps. Peut-être que c’est l’un de ces rares cas où vous souhaitez un recaptcha lors de l’inscription via un plugin.