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 Mi Piace
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 Mi Piace
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 Mi Piace
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 Mi Piace
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 Mi Piace
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 Mi Piace
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.
Ho unito la PR:
Aggiunge una nuova impostazione del sito normalize emails che rimuoverà i punti e la parte +… di un’email e quindi ne verificherà l’unicità. Ad esempio, se esiste un utente test+1@gmail.com e test+2@gmail.com tenta di registrarsi, non sarà consentito se l’impostazione del sito è abilitata.
7 Mi Piace
Fantastico, penso che questo risolva al 100% il problema di @markersocial e sia un’ottima impostazione da abilitare se dovessi diventare un bersaglio per questo specifico attacco.
Facci sapere come va @markersocial
4 Mi Piace
Grazie mille per aver implementato questo, è una vittoria enorme - sono così felice che sia stato aggiunto. L’ho messo online ieri e sto monitorando.
Finora, sembra funzionare al 100% come previsto e risolvere completamente questo problema. Le persone possono ancora registrarsi con punti nei loro indirizzi email (e presumibilmente +, non ho visto queste registrazioni di recente). Ma non possono continuare a creare account con variazioni dello stesso gmail. Leggendo la discussione su GitHub, è stata sicuramente la scelta migliore mantenere l’indirizzo email originale così com’è.
Detto questo, lascerò qui suggerimenti che penso potrebbero migliorare questa funzionalità senza diventare eccessivamente complicati:
Invece di avere una casella di controllo per abilitare/disabilitare normalizza email. Avere due elenchi, simili allo stile dell’elenco di blocco dei domini email.
- Elenco domini per applicare la normalizzazione dei punti
- Elenco domini per applicare la normalizzazione +
Per esempio:
L’amministratore aggiunge gmail.com a entrambi gli elenchi di normalizzazione dei domini.
e.mai.l+123@gmail → email@gmail.com
L’utente aggiunge outlook.com all’elenco di normalizzazione + (solo):
us.er+123@outlook.com → us.er@outlook.com
Gli indirizzi email us.er@email.com e user@email.com che sono lo stesso indirizzo/account sono specifici per alcuni provider e non sono realmente standard. Mentre + sembra essere uno standard (per qualsiasi provider che lo consenta).
Ciò consentirebbe agli amministratori di applicare selettivamente queste regole individualmente ai domini email problematici man mano che emergono, invece di applicare la normalizzazione (di entrambi i tipi) a tutti i domini email.
Non ho aspettative per quanto sopra, lascio solo il suggerimento nel caso fosse utile.
Comunque, grazie ancora, apprezzo davvero davvero che questo sia stato implementato. Cambia le regole del gioco.
2 Mi Piace
Mi chiedo però se si tratti di un problema teorico o reale. Capisco il desiderio di fedeltà, ma preferirei sentire parlare di alcuni casi specifici in cui questo sta causando un problema.
Il problema nell’introdurre un’impostazione del genere sarebbe riapplicare le regole di normalizzazione quando si modifica la lista consentiti dei siti, rendendola una modifica molto complessa.
Ora normalizziamo incondizionatamente (indipendentemente dall’impostazione del sito), quindi attivarla è istantaneo e si applica a tutta la cronologia.
Fantastico 
Tutto merito di @nbianca
4 Mi Piace
Fantastico! Non mi ero reso conto che si applicasse retroattivamente. Pensavo che un indirizzo normalizzato venisse salvato solo per le nuove registrazioni.
Sì, la principale possibilità di un problema si presenterebbe nei casi di indirizzi email che consentono alias “+” ma non considerano i punti in posizioni diverse come uguali.
Tutte le istanze di “+” nelle email possono essere gestite allo stesso modo senza alcun problema, poiché per quanto ne so viene gestito allo stesso modo per tutti i provider che lo consentono. I punti sono gli unici per cui c’è qualche differenza tra i provider.
Se ricordo bene, penso che le email di lavoro di Google (utilizzando domini personalizzati), Yandex e Outlook considereranno posizionamenti di punti diversi come indirizzi diversi, ma gli alias “+” possono comunque essere utilizzati.
Quindi gli unici casi sarebbero come se l’esistenza di theirs@email.com bloccasse la registrazione di the.irs@email.com (quando questi sono in realtà due account/indirizzi unici secondo quel dominio/provider di posta elettronica). Il che dovrebbe essere molto raro che si verifichi nel mondo reale. 
2 Mi Piace
Questo argomento è stato chiuso automaticamente dopo 16 ore. Non sono più consentite nuove risposte.