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!
Wir werden mit diesen Arten von Registrierungen und dem dazugehörigen Spam regelrecht überrollt. 
mycoolgmailaddress4spam+unlimitedcombinationslol@gmail.com
m.ycoo.lgm.ailaddress4s.pam@gmail.com
Leider sind wir gegen diese Registrierungen machtlos. Die einzige Verteidigung besteht darin, nicht von Spammern mit nennenswerten Fähigkeiten ins Visier genommen zu werden.
Es gibt objektiv keine Möglichkeit, einen Spammer mit ausreichender Anzahl an IP-Adressen daran zu hindern, auf einem Standard-Discourse-Forum 100.000 Konten mit einer einzigen Gmail-Adresse unter Verwendung dieser Tricks zu erstellen.
Alle Einstellungen zur Drosselung von Spam und Beiträgen sind nutzlos, wenn Spammer Zugriff auf unbegrenzte Konten mit einer einzigen Gmail-Adresse haben.
Es ist seltsam, dass Ihre Website ein derart schwerwiegendes Problem damit hat, wenn ich mich in den letzten 4 Jahren bei unseren rund 1.000+ gehosteten Kunden nicht an einen einzigen solchen Vorfall erinnern kann.
@codinghorror Schreibst du das ausreichend starken Abwehrmaßnahmen gegen diese gängige Spam-Technik zu, oder liegt es daran, dass diese Seiten von Spam-Akteuren nicht ins Visier genommen werden? Bekommen diese Seiten regelmäßig große Mengen an Spam-Registrierungsversuchen jeglicher Art, die von den Abwehrsystemen blockiert werden?
Das hängt stark von der Nische, den Traffic-Volumen und der Eignung für ihre Direct-Response-Spam-Kampagnen ab. Ein Spammer, der Beiträge nahe oben in der Beitragsliste halten kann, erhält im Grunde fantastische Werbeplätze für einen Bruchteil des Preises. Werbeplätze auf der Startseite oberhalb des „Fold“ können je nach Nische und Traffic-Volumen häufig zwischen xxx und x.xxx pro Tag wert sein.
Spammer, die durch das Versenden ihrer Direct-Response-Kampagnen auf einem bestimmten Forum monatlich beträchtliche Gewinne erzielen und möglicherweise in Entwicklungsländern mit extrem niedrigen durchschnittlichen lokalen Gehältern leben, könnten motiviert sein.
Ich betreibe mehrere weitere Discourse-Foren, die seit 2015–2016 laufen, und sie haben aufgrund der fehlenden Zielsetzung praktisch keine Probleme mit Spam-Registrierungen oder -Beiträgen. Nicht ins Visier genommen zu werden ist eine nette Verteidigung, bis man es doch wird. Soweit ich weiß, wird Discourse in den meisten kommerziell erhältlichen Forum-Spam-Softwarelösungen wie Xrumer standardmäßig nicht unterstützt.
Nun, es gibt eine Regel, die ich gerne zitiere.
Wenn du vom Mossad einzeln ins Visier genommen wirst, bist du erledigt.
Stimmt, ein professioneller Spammer wird immer durchkommen. Wir haben gesehen, wie sie eigene Mailserver aufsetzen und Tausende von E-Mail-Adressen generieren – da hat man kaum eine Chance.
Trotzdem erscheint es doch vernünftig, doppelte Registrierungen mit diesen Gmail-Tricks zu verhindern, oder?
@codinghorror - Haha, toll. Ich würde mich aber nicht einfach ergeben und aufgeben. 
Ich glaube nicht, dass dies ein Randfall ist. Viele soziale Netzwerke erlauben die Registrierung mit derselben Gmail-Adresse nicht, wegen Missbrauchs durch Spammer. Soweit ich weiß, erlauben dies die meisten großen Anbieter nicht.
@bartv - Ja, bei denen, die ihre eigenen Mailserver haben, können wir zumindest deren Domains auf eine Blacklist setzen, was eine recht wirksame Verteidigung darstellt (obwohl die Konten, die vor dem Blacklisting erstellt wurden, weiterhin nutzbar sind). Sie können weitere Domains beschaffen, aber das kostet sie zumindest Ressourcen – im Gegensatz zu den Gmail-Tricks.
Bei diesen Gmail-Tricks gibt es wirklich keine Verteidigungsmöglichkeit, und zusätzliche Adressvariationen kosten den Spammer nichts. Der „Levenshtein-Abstand
Es sei denn, du hast mächtige genug Freunde, die dir helfen können. Und das ist hier das Entwicklungsteam von Discourse (und vielleicht auch die Community, wenn wir an Plugins denken).
Es tut mir leid, aber wäre es nicht gut, wenn Discourse alle Gmail-Adressen so behandeln würde, dass Punkte und alles, was nach einem Pluszeichen kommt, ignoriert werden? Das scheint technisch nicht sehr kompliziert zu sein. Es sind nur ein paar ziemlich einfache Zeilen Code. Registrierung => erkennt gmail.com nach dem @-Zeichen => entfernt alle Punkte und alles nach einem Pluszeichen bis zum @-Zeichen und verwendet diese Adresse => Bereits verwendet? => Gibt eine Fehlermeldung zurück: „E-Mail-Adresse bereits verwendet“.
Erledigt. Oder übersehe ich etwas?
Wenn Spammer merken, dass dies bei Discourse funktioniert, werden sie mit dieser Technik immer mehr Discourse-Foren ins Visier nehmen. Ich meine, warum sollten sie das nicht tun?
Wir haben für neue Benutzer festgelegt, dass alle Themen/Beiträge für die ersten X Male manuell genehmigt werden müssen. Das Problem war damit fast über Nacht behoben. Einige haben herausgefunden, dass das nachträgliche Bearbeiten ihrer Beiträge funktioniert, bis wir dies auch für das Vertrauenslevel 0/1 angepasst haben.
Obwohl dies nichts speziell mit irgendeinem bestimmten Domain-Trick zu tun hat, unterbricht es das eigentliche Problem: einen motivierten Menschen, der versucht, Ihre Gegenmaßnahmen zu umgehen. Wenn sie keinen Gmail-„Trick
Nun, mal sehen. Welche Zeichen können hier überhaupt verwendet werden?
Einige E-Mail-Dienste unterstützen ein Tag im lokalen Teil, sodass die Adresse ein Alias für einen Präfix des lokalen Teils ist. Zum Beispiel bezeichnet die Adresse
joeuser+tag@example.comdieselbe Zustelladresse wiejoeuser@example.com. RFC 5233 bezeichnet diese Konvention als Sub-Addressing, sie ist jedoch auch als Plus-Addressing, getaggtes Addressing oder Mail-Erweiterungen bekannt.Adressen dieser Form, die verschiedene Trennzeichen zwischen dem Basisnamen und dem Tag verwenden, werden von mehreren E-Mail-Diensten unterstützt, darunter Runbox (Plus), Gmail (Plus), Rackspace Email (Plus), Yahoo! Mail Plus (Bindestrich), Apples iCloud (Plus), Outlook (Plus), ProtonMail (Plus), FastMail (Plus und Subdomain-Addressing), MMDF (Gleichheitszeichen), Qmail und Courier Mail Server (Bindestrich). Postfix und Exim erlauben die Konfiguration eines beliebigen Trennzeichens aus dem zulässigen Zeichensatz.
Wir haben also: Plus, Bindestrich, Gleichheitszeichen, Punkt und Raute/Hashtag.
Das Einzige, was mir einfällt, das hier funktionieren würde, ist eine super strenge Einstellung, die alle Zeichen außerhalb von A-Z a-z 0-9 in E-Mail-Adressen verhindert.
Das wird definitiv einige Nutzer daran hindern, sich anzumelden, aber das könnte ein gangbarer Kompromiss sein, wenn man von.. äh.. Elitespezialisten des Mossad ins Visier genommen wird, schätze ich 
Was denkst du, @eviltrout?
Das könnte zu streng sein; der Punkt hier ist, die mehrfache Verwendung solcher E-Mail-Varianten zu verhindern, nicht sie ganz zu verbieten. Stattdessen könntest du für jedes Konto eine ‘kanonische’ E-Mail-Adresse hinzufügen, die die bereinigte Version der tatsächlichen E-Mail-Adresse des Benutzers enthält. Du vergleichst dann die bereinigte Version der E-Mail-Adressen bei neuen Registrierungen mit diesem Wert. Es ist wahrscheinlich leichter gesagt als getan, aber…
Ja, ich bevorzuge Barts vorgeschlagene Änderung hier.
[ ] Verwende eine kanonische Form für die interne Speicherung von E-Mail-Adressen (entfernt +ALLES, entfernt Kommentare usw.)
Bietet eine Ruby-Implementierung, die wir übernehmen könnten, aber wir müssten sehr, sehr, sehr vorsichtig sein (Beispiel 1 ist ein Sicherheitsrisiko laut: 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"
Ich schlage also vor, dass unser „Kanonicalisieren“ folgendes tut:
+ALLES entfernen
Kleinschreibung (wir erzwingen dies bereits)
WENN gmail oder googlemail oder in einer benutzerdefinierten Whitelist: Punkte entfernen
Kommentare entfernen. (...) sind auch ein Vektor für Missbrauch.
Die Adresse unicode-normalisieren, was technisch gemäß Email address - Wikipedia erlaubt ist.
Dann eine versteckte Site-Einstellung mit einer Whitelist von Domains für die Entfernung von . hinzufügen.
Das gesagt, es gibt viele Möglichkeiten, dies zu missbrauchen. Schließlich kann jemand einen Cache von 10.000 Spam-Gmail-Adressen haben und sich einfach mit allen über irgendeinen Bot anmelden. Wenn du ins Visier genommen wirst, kannst du genauso gut eine Weile jede neue Anmeldung genehmigen. Vielleicht ist dies einer der seltenen Fälle, in denen du ein reCAPTCHA bei der Anmeldung in einem Plugin möchtest.