The thing is forcing canonical emails is effectively the same except that it is far less user hostile.
No Sam.sam@gmail.com is allowed Sa.msam+123@gmail.com is already registered
Anyway we can do regex next release
2 „Gefällt mir“
Yeah, but it’s useless in actual practice, which is why we’re having this discussion… once they have nukes, you need nukes too.
“User hostile” is a meaningless concept once your audience has nukes and is willing to use them.
I disagree with this, the solution worked perfectly for @markersocial, and then I reverted the change cause my hand was forced
There are no known gaps with the canonicalization approach I implemented and reverted, it solves the above gmail problem 100%
3 „Gefällt mir“
Well, I disagree, because that put the code and effort burden on our side, rather than their side. “Normalizing” emails is quite complicated, varies per email provider, and I don’t want to be in that business.
In other words, let them build and handle the nuclear devices on their own; we don’t need to ship proto-nukes to every country and in every installation of Discourse “just in case”.
(Plus being able to blocklist emails via regex is quite powerful, especially since email = identity in Discourse.)
1 „Gefällt mir“
We could let them normalise with their own regex rules as some sort of middle ground, then we are not in the business of normalisation
That said yes regex blocking or at least wildcard blocking will happen for the next release
6 „Gefällt mir“
I can confirm that the previous implementation worked perfectly and entirely solved the gmail issue. The email domain allow list and disallow list both are quite effective nukes. But it’s just not viable to block gmail.
@codinghorror I can see the point of view against normalising for different email providers. But I think it would make sense to be able to cover at least gmail (~43% of all email addresses apparently in 2020, 53% for the US) in a non-destructive way. It might be comparable to supporting oauth from large providers out of the box.
@sam ^ This is a great idea for an alternative. 
Maybe this, with an example for the gmail/googlemail match could be quite user friendly and powerful.
2 „Gefällt mir“
Have a user right now that has made several thousand accounts with a single gmail address (using periods) and spamming promoting their competing site to siphon off users. Will be upgrading to 2.8 and blocking all emails that contain a period or plus symbol as soon as it’s released. I do wish the previous implementation was available, but appreciate that this is being addressed and a solution will be available. It’s going to make a massive difference, thank you 
1 „Gefällt mir“
So have thought about this a bit and thought of a solution that could maybe make sense.
There could be an admin option to process and store a normalised version of the email (only processing the username part i.e. username@…)
But only apply this for domains that are specified by the admin.
So a list somewhat like the email domain allow/block lists, with two checkboxes per domain:
- Strip + string
- Strip periods
Then use these records as a reference for disallowing additional registrations using alternative versions of that email (without affecting the primary email record, which can still have + and periods).
This way, the burden of selecting which domains to store a normalise record for and how to normalise them can be on the admin only, allowing them to respond to problematic email domains as they emerge.
Anyhow, just dropping this here so it can perhaps be considered at some point.
Cheers.
Ich habe den PR zusammengeführt:
Er fügt eine neue Website-Einstellung normalize emails hinzu, die Punkte und den +…-Teil einer E-Mail entfernt und dann auf ihre Einzigartigkeit prüft. Wenn beispielsweise ein Benutzer test+1@gmail.com existiert und sich test+2@gmail.com registrieren möchte, wird dies nicht zugelassen, wenn die Website-Einstellung aktiviert ist.
7 „Gefällt mir“
Fantastisch, ich denke, das löst das Problem von @markersocial zu 100 % und ist eine großartige Einstellung, die aktiviert werden sollte, wenn Sie Ziel dieses speziellen Angriffs werden.\n\nLassen Sie uns wissen, wie es Ihnen ergeht, @markersocial
4 „Gefällt mir“
Vielen Dank für die Implementierung, das ist ein riesiger Erfolg – ich bin sehr froh, dass dies hinzugefügt wurde. Ich habe es gestern live geschaltet und beobachte es.
Bisher scheint es zu 100 % wie vorgesehen zu funktionieren und dieses Problem vollständig zu lösen. Leute können sich immer noch mit Punkten in ihren E-Mails registrieren (und vermutlich auch mit Pluszeichen, diese Registrierungen habe ich kürzlich nicht mehr gesehen). Aber sie können keine Konten mehr mit Variationen derselben Gmail-Adresse erstellen. Aus der Diskussion auf GitHub geht hervor, dass es definitiv die beste Entscheidung war, die ursprüngliche E-Mail-Adresse unverändert zu lassen.
Daher werde ich hier Vorschläge hinterlassen, die meiner Meinung nach diese Funktion verbessern würden, ohne übermäßig kompliziert zu werden:
Anstatt einer Checkbox zum Aktivieren/Deaktivieren von normalize emails. Haben Sie zwei Listen, ähnlich wie bei der Blockierliste für E-Mail-Domains.
- Domainliste für die Anwendung der Punktnormalisierung
- Domainliste für die Anwendung der Pluszeichen-Normalisierung
Zum Beispiel:
Admin fügt gmail.com zu beiden Domain-Normalisierungslisten hinzu.
e.mai.l+123@gmail → email@gmail.com
Benutzer fügt outlook.com zur Pluszeichen-Normalisierungsliste hinzu (nur):
us.er+123@outlook.com → us.er@outlook.com
E-Mails us.er@email.com und user@email.com, die dieselbe Adresse/dasselbe Konto sind, sind spezifisch für einige Anbieter und nicht wirklich Standard. Während das Pluszeichen ein Standard zu sein scheint (für jeden Anbieter, der es zulässt).
Dies würde es Administratoren ermöglichen, diese Regeln selektiv auf einzelne problematische E-Mail-Domains anzuwenden, sobald sie auftreten, anstatt die Normalisierung (beider Arten) auf alle E-Mail-Domains anzuwenden.
Ich habe keine Erwartungen an das Obige, hinterlasse den Vorschlag nur für den Fall, dass er nützlich ist.
Wie auch immer, nochmals vielen Dank, ich bin wirklich sehr dankbar, dass dies implementiert wurde. Es ist ein Game Changer.
2 „Gefällt mir“
Ich frage mich jedoch, ob dies ein theoretisches oder ein reales Problem ist. Ich verstehe den Wunsch nach Genauigkeit, würde aber lieber von einigen spezifischen Fällen hören, in denen dies ein Problem verursacht.
Das Problem bei der Einführung einer solchen Einstellung wäre die erneute Anwendung von Normalisierungsregeln, wenn man die Zulassungsliste von Websites manipuliert, was dies zu einer sehr komplexen Änderung machen würde.
Wir normalisieren jetzt bedingungslos (unabhängig von der Website-Einstellung), sodass das Einschalten sofort erfolgt und für die gesamte Historie gilt.
Großartig 
Alles dank @nbianca
4 „Gefällt mir“
Großartig! Ich wusste nicht, dass das rückwirkend angewendet würde. Ich dachte, eine normalisierte Adresse würde nur für neue Registrierungen gespeichert.
Ja, die Hauptmöglichkeit für ein Problem besteht bei E-Mail-Adressen, die + Aliase zulassen, aber unterschiedliche Platzierungen von Punkten nicht als gleich ansehen.
Alle Instanzen von + in E-Mails können ohne Probleme gleich behandelt werden, da sie meiner Meinung nach für alle Anbieter, die dies zulassen, gleich behandelt werden. Nur bei Punkten gibt es Unterschiede zwischen den Anbietern.
Wenn ich mich richtig erinnere, glaube ich, dass Google-Arbeits-E-Mails (mit benutzerdefinierten Domains), Yandex und Outlook unterschiedliche Punktplatzierungen als unterschiedliche Adressen betrachten, aber die + Aliase können immer noch verwendet werden.
Die einzigen Fälle wären also, wenn z. B. theirs@email.com existiert und the.irs@email.com von der Registrierung blockiert würde (obwohl dies laut dieser E-Mail-Domain/diesem Anbieter tatsächlich zwei eindeutige Konten/Adressen sind). Was in der realen Welt wahrscheinlich sehr selten vorkommt. 
2 „Gefällt mir“
Dieses Thema wurde nach 16 Stunden automatisch geschlossen. Neue Antworten sind nicht mehr möglich.