Ich kann bestätigen, dass die ursprüngliche Lösung perfekt funktioniert hat und dieses Problem mit Gmail-Adressen gelöst hat. Es wäre eine echte Lebensrettung, wenn dieser optionale Modus wieder eingeführt würde.
Spammer lernen ständig neue Techniken und umgehen weiterhin erfolgreich große Player wie Facebook, Instagram und Twitter. Das macht die meisten anderen Plattformen zum „Leichtmodus“. Für viele von ihnen ist dies ein Vollzeitjob, sodass es im Wesentlichen darauf hinausläuft:
Wenn etwas ausnutzbar ist und (die erforderlichen Ressourcen < der verdiente Gewinn), dann wird es ausgenutzt.
Sie können praktisch jede Maßnahme umgehen; die einzige Hoffnung besteht darin, die Kosten dafür so hoch zu treiben, dass es sich finanziell nicht mehr lohnt.
Die Möglichkeit, massenhaft Spam mit nahezu unbegrenzt vielen E-Mails/Konten zu versenden (vor der Erkennung und einer nachträglichen Blockierung der kanonischen Gmail-Adresse durch einen Moderator/Admin sowie dem manuellen Löschen ihrer Beiträge) ist sehr kosteneffizient. Noch mehr, wenn es kein 24/7-Moderatorenteam gibt.
Die Kosten, um Anti-Spam-Maßnahmen zu umgehen, sinken kontinuierlich. Ein Beispiel sind 4G/5G-Proxies: Für etwa 30–50 US-Dollar pro Monat können Menschen Zugriff auf praktisch unbegrenzte echte mobile IPs erhalten, von legitimen ISPs/ASNs, die automatisch/manuell rotieren und von ganzen Städten/Staaten legitimer Nutzer großer ISPs geteilt werden. 4G/5G-IPs werden von vielen Nutzern gleichzeitig geteilt.
Das Blockieren dieser ISPs/ASNs oder IPs ist nicht geeignet (man kann nicht einfach alle Nutzer von Verizon, AT&T usw. blockieren). Sie verwenden die IP in der Regel nur einmal und verwerfen sie dann. Die blockierten einzelnen IPs würden zudem legitime Nutzer blockieren, die zufällig dieselbe IP-Adresse teilen. IP-Blockaden werden langsam zu einer veralteten Praxis (ausgenommen ASNs bekannter Hosting-Unternehmen). Man kann die Spitze des Eisbergs in diesen Foren sehen:
https://mpsocial.com/c/public-marketplace/61
https://www.blackhatworld.com/forums/proxies-for-sale.112/
Ich glaube, die Spammer bestehen aus einer Mischung aus vollständig oder teilweise selbst entwickelten Bots und manuellem Spam. Da Discourse zunehmend Marktanteile gewinnt – was eindeutig fantastisch wächst – würde es mich wundern, wenn es nicht zum Ziel kommerziell verfügbarer Bots würde.
Sobald Xrumer die neueste Version von reCAPTCHA unterstützt, würde ich sagen, dass die meisten Webmaster in Legacy-Foren einen starken Anstieg des Spams bemerken, da die Kosten für Spamming auf ein absolutes Minimum gesunken sind (man muss keine Captcha-Lösungs-API mehr verwenden, die ohnehin bereits sehr günstig pro 1.000 Lösungen ist):
http://botmasterlabs.net/buy1/
Leute können bereits eigene Plugins/Skripte erstellen, um praktisch jede Plattform mit Xrumer zu unterstützen. Aber wenn sie Discourse eines Tages „out of the box“ unterstützen:
Ich kann nicht behaupten, dabei unparteiisch zu sein, da ich selbst dringend Anti-Spam-Maßnahmen benötige. Der ursprüngliche Beitrag über den Gmail-Punkt-Trick wurde 2014 von jemand anderem erstellt, und es scheint, dass ein anderer Benutzer dies gelöst hat, indem er eine Genehmigung für die ersten x Beiträge erforderlich machte. Vielleicht gibt es also mindestens drei Benutzerberichte? 
Entschuldigung für den Abschweif, zurück zum Thema.
Bezüglich des Regex-Blockierens für E-Mails: Ja, Sie haben recht. Es ist eine teilweise Lösung, aber aus folgenden Gründen nicht ideal:
Wenn man alle Gmail-Adressen mit einem Punkt oder mehr vor dem @ blockiert:
- Es werden unvermeidlich echte, legitime Gmail-Nutzer blockiert, die entweder einen oder mehrere Punkte in ihrer Gmail-Adresse haben, was sehr häufig vorkommt.
- Spammer können trotzdem mit nur einem Punkt viele Variationen erstellen. Beispielsweise hat Gmail eine maximale Länge von 30 Zeichen, z. B. 12345678901234567890123456789.0@gmail.com. Das ergibt 30 verwendbare Kombinationen mit einem einzigen Punkt.
Wenn man alle Gmail-Adressen mit zwei Punkten oder mehr vor dem @ blockiert:
- Weniger legitime Gmail-Adressen werden blockiert, aber es werden dennoch legitime Gmail-Nutzer blockiert, die mehr als einen Punkt in ihrer E-Mail-Adresse haben.
- Spammer können mit einer einzigen 30-Zeichen-Gmail-Adresse noch viel mehr Variationen erstellen. Ich schätze etwa 842 Kombinationen.
Ich kann bestätigen, dass die neuen Konten nach Aktivierung der Blockierung erstellt wurden, da das Blockierungsdatum der 1. Februar ist. Ich habe gestern die Erstellung neuer Konten beobachtet und dabei sowohl Fälle gesehen, in denen die Blockierungsregel neue, kürzliche Übereinstimmungen aufwies, als auch neue Registrierungen, die Kombinationen derselben E-Mail (nur Punkte) verwendeten.
Ich habe die Registrierungen über Nacht deaktiviert und heute Morgen wieder aktiviert. Bisher wurden heute 104 neue Konten mit Permutationen dieser Gmail-Adresse erstellt, und es werden weiterhin mehr registriert. Ich kann bestätigen, dass, sobald die Punkte aus den E-Mails dieser Konten entfernt werden, eine exakte Übereinstimmung mit dem blockierten Eintrag der Screened Emails vorliegt.
Ich habe versucht, die Blockierungen wie beschrieben in rails c zu testen. Hier wird es etwas seltsam.
Es scheint, dass einige Einträge wie beabsichtigt „true“ zurückgeben, während andere „false“ zurückgeben, selbst wenn die getestete E-Mail exakt mit der kanonisch blockierten E-Mail übereinstimmt. Für die Einträge, die „true“ zurückgeben, funktionierte alles wie vorgesehen, und es wurde für alle getesteten Variationen „true“ zurückgegeben. Aber bei den E-Mails, die „false“ zurückgeben, gaben alle getesteten Variationen ebenfalls „false“ zurück.
Ich habe versucht, Korrelationen zu finden. Ich kann bestätigen, dass diese nicht korreliert sind (oder zumindest nicht konsistent korreliert):
E-Mail-Länge (vor @)
E-Mail enthält Zeichen und Zahlen
Übereinstimmungen (Anzahl der Blockierungen)
Datum der Übereinstimmung
Es scheint jedoch eine Korrelation mit dem Blockierungs-Erstellungsdatum zu geben: Je älter, desto unwahrscheinlicher ist es, dass es funktioniert (gibt „false“ zurück). Einträge, die vor 9 Tagen erstellt wurden, gaben eine Mischung aus „true“ und „false“ zurück, und alle Einträge, die ich bisher getestet habe und die früher erstellt wurden (1 Stunde bis 8 Tage), geben „true“ zurück.
Vielleicht hängt das mit „max age unmatched emails“ zusammen? Ich denke, diese Option ist etwas neu; ich habe sie auf den Standardwert von 365 Tagen eingestellt.