Vorschlag: Wildcard-E-Mail-Adresse blockieren

Es wäre gut, wenn es eine Möglichkeit gäbe, E-Mail-Adressen mit Wildcards zu blockieren. Zum Beispiel, wenn ein Spammer den Gmail-Punkt-Trick anwendet.

Zum Beispiel:

example@gmail.com
example+random12345@gmail.com
ex.a.mple+random12345@gmail.com
e.xamp.le@gmail.com

sind alles dieselbe E-Mail-Adresse. Spammer können eine einzige Gmail-Adresse nutzen, um mühelos unbegrenzt viele Konten zu erstellen.

Das Blockieren einer Adresse mit Wildcards wie unten wäre meiner Meinung nach eine gute Lösung:
e*x*a*m*p*l*e*@gmail.com

Ich bin nicht unbedingt der Meinung, dass alle Registrierungen mit diesen Gmail-Varianten blockiert werden sollten, aber es wäre nützlich, wenn bei der Blockierung einer Gmail-Adresse automatisch alle Varianten blockiert würden, oder wenn wir manuell eine Gmail-Adresse mit Wildcard zur E-Mail-Blacklist hinzufügen könnten.

1 „Gefällt mir“

Siehst du ein konkretes, spezifisches Problem, oder ist das nur eine Theorie? Falls es sich um ein konkretes Problem handelt, kannst du dann die spezifischen E-Mail-Adressen des Spammers teilen?

4 „Gefällt mir“

Ja, das ist ein echtes Problem, das ich selbst erlebe. Spammer erstellen regelmäßig Zehntausende von Konten pro einzelner Gmail-Adresse, indem sie die „Punkt-Methode

Wenn dies tatsächlich mit einem wildcard-ähnlichen Ansatz implementiert wurde (anstatt automatisch von Discourse gehandhabt zu werden), wären Sie wahrscheinlich viel spezifischer als e*x*a*m*p*l*e*@gmail.com. Eine solche Vorgehensweise könnte dazu führen, dass unschuldige Personen blockiert werden, insbesondere wenn die E-Mail-Adresse des Spammers relativ kurz ist. Das gezielte Suchen nach . und + wäre wahrscheinlich deutlich sicherer.

2 „Gefällt mir“

Auf welchem Wert ist deine Einstellung levenshtein_distance_spammer_emails – beim Standardwert 2 oder beim Maximalwert 3?

2 „Gefällt mir“

Danke für den Hinweis zu dieser Einstellung levenshtein_distance_spammer_emails. Ich habe sie noch nie gesehen oder geändert – sie steht standardmäßig auf 2.

3 „Gefällt mir“

Ich verstehe deine Mathematik nicht. Du kannst nur einen einzelnen Punkt zwischen den Zeichen hinzufügen, sodass jede N-Zeichen-Adresse nur für 2*n Adressen geeignet ist. Du könntest wahrscheinlich ein Plugin verwenden, das die Adresse ohne Punkte speichert oder vergleicht und +Adressen nicht zulässt.

2 „Gefällt mir“

@pfaffman - Ich habe mich nur an den Zahlen von Redirecting... orientiert, wonach sich die Anzahl der Adressen für jedes zusätzliche Zeichen über 2 hinaus verdoppelt (es friert jedoch bei etwa 8.000 ein).

Ich denke, 2*n, falls ich das richtig verstehe (dass also eine 26 Zeichen lange Adresse 52 Kombinationen hätte?), wäre zu niedrig. Denn man kann mehrere Punkte im gesamten Adressnamen hinzufügen.

Zum Beispiel:
constantinehamilton1337x@gmail.com
con.stantinehamilton1337.x@gmail.com
co.nst.antineh.amilton1.3.37x@gmail.com
constantineh.a.m.ilto.n13.37x@gmail.com
c.o.nsta.ntinehamil.ton1337x@gmail.com

Wie auch immer, egal wie genau die Zahl ist, es sind sehr viele. Ja, deine vorgeschlagene Lösung ergibt Sinn!

1 „Gefällt mir“

Ja. Ich habe die Mathematik nicht richtig angewendet. Ich habe nur einen Punkt zugelassen. Ich habe das früher fast verstanden, aber heute Morgen nicht. :wink:

Aber ein Plugin, das einen Treffer speichert und zusätzlich die kostenlose Version der Adresse als weitere Adresse hinzufügt, würde das tun, was du möchtest, und wäre nicht so schwer umzusetzen.

3 „Gefällt mir“

Hinweis … wenn du sam.sam@gmail.com blockierst, blockieren wir automatisch auch sam.sam+1@gmail.com und so weiter…

10 „Gefällt mir“

Diese Funktion funktioniert sehr gut, @sam :slight_smile:

Ich denke, dass die vorherige Implementierung, die du erstellt hast, immer noch als zusätzliche Anti-Spam-Funktion sehr nützlich sein könnte. Sie hat in der kurzen Zeit, in der sie verfügbar und aktiviert war (standardmäßig deaktiviert), unglaublich gut funktioniert.

Andernfalls können Spammer weiterhin Massenkonten mit einer Gmail-Adresse erstellen, bevor ein Moderator oder Administrator dies bemerkt. Zum Beispiel das Erstellen der Konten, ohne sofort etwas zu veröffentlichen.

Administratoren/Moderatoren müssen jedes einzelne Konto manuell finden und öffnen, um es zu sperren/löschen. Das kann sehr mühsam sein, besonders wenn ein Spammer hunderte oder tausende Konten mit einer einzigen Gmail-Adresse erstellen kann, bevor er gesperrt wird. Auch ist die Suche nach den E-Mail-Adressen schwierig, z. B. j.ohan.2.1@gmail und jo.ha.n21@gmail.

Wenn sie nicht manuell aufgespürt werden, behalten die Spammer einen großen Pool an Konten, um das Spiel „Whack-a-Mole

@sam Nur ein kurzes Follow-up nach weiteren Feldtests: Ich bin überzeugt, dass die frühere Implementierung, die rückgängig gemacht wurde, gegen motivierte Spammer definitiv viel effektiver ist. Ich erhalte nach wie vor eine erhebliche Anzahl von Registrierungen, die auf diesen verschleierten Gmail-Tricks basieren.

Ich bin sehr dankbar, dass der aktuelle Schutz implementiert wurde, der sich als sehr wirksam erwiesen hat. Allerdings halte ich es für eine Schwachstelle, dass unbegrenzt viele Konten mit derselben E-Mail-Adresse erstellt werden können, bis sie speziell bemerkt und manuell gesperrt werden. Das bedeutet eine zusätzliche Belastung für Moderatoren (die standardmäßig keine E-Mail-Adressen der Konten einsehen können, es sei denn, diese Funktion ist aktiviert), insbesondere wenn keine Werkzeuge zur Massenentfernung von Konten vorhanden sind (z. B. mehrere Konten aus der Suchliste der Konten mit Kontrollkästchen auswählen und alle sperren/entfernen). Das bedeutet, dass ein Moderator manuell zu jedem einzelnen Konto navigieren muss, um es zu entfernen oder zu sperren. Das ist besonders schwierig, wenn man nach Konten mit verschleierten E-Mail-Adressen sucht.

Da die frühere Implementierung optional war (standardmäßig deaktiviert), bereits entwickelt wurde, wie vorgesehen funktionierte und dann entfernt wurde, scheint es einfach schade, dass sie für Communities, die sie für zusätzlichen Spam-Schutz gegen motivierte Spammer nutzen möchten, nicht mehr zur Verfügung steht.

Deshalb habe ich gesagt, dass bestimmte Zeichen in E-Mails (optional) vollständig verboten sein müssen. Konkret sind das die Zeichen, die eine Subadressierung ermöglichen, wie Pluszeichen, Punkt, Bindestrich usw. Mit einer Regex könnte man dies auch pro Dienst blockieren, z. B. „keine E-Mail mit einem Pluszeichen, die auf @gmail.com endet, ist erlaubt“. cc @sam

1 „Gefällt mir“

Die vorherige Implementierung erlaubte weiterhin +addressing, hielt die Anzahl der Kanonischen Adressen jedoch auf eine pro Konto (was ich wahrscheinlich sicherer finde).

Man konnte also als sam+discourse-meta@gmail.com registriert sein, was praktisch ist für interne Gmail-Regeln, die man hat. Anschließend wären jedoch neue Accounts von sam@gmail.com oder sam+1@gmail.com blockiert.

Ich bin nicht gegen das Hinzufügen einer Whitelist, aber ich finde, dass die Durchsetzung kanonischer Adressen im Gmail-Fall sehr praktisch ist und eine nicht schlechte Standardeinstellung darstellt.

1 „Gefällt mir“

Sicherheit ist hier nicht wirklich das Ziel. Die betreffende Website benötigt aufgrund des Ausmaßes des Problems, dem sie gegenübersteht, eine extremere Lösung. Solange es optional ist (fügen Sie Ihre eigene „E-Mail-Schutz-Regel

1 „Gefällt mir“

Wir haben derzeit

blockierte E-Mail-Domains

Ich schätze, wir könnten hinzufügen:

blockierte E-Mail-Muster

Allerdings ist es etwas mühsam, die richtige Regex zu erstellen, angesichts aller benötigten Escaping-Operationen. Ich bin besorgt, Optionen wie diese anzubieten, da die Wahrscheinlichkeit, dass Benutzer die Regex korrekt und wie beabsichtigt erstellen, recht gering ist. Sie müssen daran denken, sowohl Punkte als auch Pluszeichen zu escapen.

.*\+.*@gmail\.com

Wir könnten vielleicht ein nicht auf Regex basierendes, vereinfachtes Muster verwenden, das nur * und ? erweitert.

*+*@gmail.com

5 „Gefällt mir“

:wave: Entschuldigung für die späte Antwort!

Wenn die vorherige Implementierung als Option wieder eingeführt würde, glaube ich, dass dies das Gmail-Problem vollständig lösen würde. Zumindest in meinem Fall. Das ist meiner Meinung nach perfekt und fügt Spammern genügend Ressourcenkosten hinzu, um die Bekämpfung überschaubar zu machen. Es wäre wirklich der Unterschied zwischen einer erforderlichen 24-Stunden-Vollzeit-Moderation mit hoher Intensität und keiner.

Ich habe mehrere Domains blockiert, die ähnliche Adressen zulassen, und nutze die Liste der erlaubten E-Mail-Domains. Das Problem ist, dass Nutzer viele Accounts erstellen können, bevor einer ihrer Accounts gebannt/blockiert wird (was das Blockieren von Permutationen dieser Gmail-Adresse für neue Accounts aktiviert, aber bestehende Accounts unberührt lässt). Das ist eine ziemliche Belastung für die Moderation und mühsam, um jeden einzelnen Account im Nachhinein zu bereinigen.

Zum Beispiel hatte ich einen Thread mit etwa 200 Antworten, wobei jeder Account nur einen Beitrag hatte, alle mit derselben Gmail-Adresse erstellt. Viele ähnliche Fälle. Dies sind Beispiele, bei denen die Accounts leicht zu finden sind, da das Suchen nach ihnen über Permutationen der ursprünglichen Gmail-Adresse als Alternative wirklich schwierig ist. Manche farmen eine große Anzahl von Accounts mit nur wenigen Gmail-Adressen und posten erst Monate später darauf.

Als Lösung für die Regex-Blockierung wäre das Blockieren von Pluszeichen (+) ziemlich harmlos. Punkte (.) würden wahrscheinlich eine erhebliche Anzahl legitimer E-Mails blockieren, z. B. john.smith@gmail.com. Das Blockieren von Adressen mit mehr als einem Punkt würde wahrscheinlich nur geringe Kollateralschäden verursachen, würde jedoch immer noch mehrere Permutationen einer Gmail-Adresse zulassen, aber deutlich weniger als bei 2 oder mehr Punkten.

Meiner Meinung nach ist die vorherige Implementierung ideal und als optionale Schutzmaßnahme nicht unvernünftig umzusetzen. Die beliebtesten Social-Media-Seiten erlauben keine Anmeldung mit mehreren Gmail-Permutationen, da dies stark von Spammern ausgenutzt wird.

Danke :slight_smile:

1 „Gefällt mir“

@sam Ich bin der festen Überzeugung, dass Websites diese optionale Ebene der E-Mail-Regex-Einschränkung implementieren dürfen sollten, falls sie sie benötigen. Andernfalls verstoßen wir gegen eines der Kernprinzipien von Discourse, nämlich „standardmäßig sicher

1 „Gefällt mir“

Das können wir für das nächste Release erledigen. Ich bleibe jedoch bei meiner ursprünglichen Umsetzung: Canonicalisierung ist die benutzerfreundlichste Lösung für Site-Betreiber. Man setzt einfach ein Häkchen, und tada – das Problem ist gelöst. Bei Regex muss man erst Regex lernen (also sind 5 Stunden weg) und landet bei einer Lösung, die entweder Spam-Accounts durchlässt, benutzerunfreundlich ist (keine Punkte, keine Pluszeichen) oder ein Kompromiss darstellt.

Aber gut, klar, wir können Regex-Unterstützung für das nächste Release einplanen.

1 „Gefällt mir“

Naja, es ist wirklich einfach: „Keine E-Mails mit Pluszeichen oder Punkt erlaubt