Il punto è che imporre indirizzi email canonici è di fatto la stessa cosa, ma è molto meno ostile per l’utente.
Non è consentito Sam.sam@gmail.com mentre Sa.msam+123@gmail.com è già registrato
Comunque, possiamo implementare un’espressione regolare nella prossima release
Sì, ma è inutile nella pratica, ed è per questo che stiamo avendo questa discussione… una volta che hanno le bombe nucleari, devi averle anche tu.
“Ostile all’utente” è un concetto privo di significato una volta che il tuo pubblico possiede armi nucleari ed è disposto a usarle.
Non sono d’accordo: la soluzione ha funzionato perfettamente per @markersocial, e poi ho annullato la modifica perché mi sono trovato costretto.
Non ci sono lacune note nell’approccio di canonizzazione che ho implementato e poi annullato: risolve al 100% il problema Gmail menzionato sopra.
Beh, non sono d’accordo, perché questo sposta l’onere del codice e dello sforzo sul nostro lato, invece che sul loro. “Normalizzare” gli indirizzi email è piuttosto complicato, varia a seconda del provider di posta, e non voglio occuparmi di questa attività.
In altre parole, lascia che costruiscano e gestiscano i dispositivi nucleari da soli; non abbiamo bisogno di spedire prototipi di armi nucleari in ogni paese e in ogni installazione di Discourse “solo nel caso”.
(Inoltre, poter bloccare gli indirizzi email tramite regex è molto potente, soprattutto perché in Discourse l’email equivale all’identità.)
Potremmo permettere loro di normalizzare con le proprie regole regex come una sorta di compromesso, così non saremo coinvolti nel processo di normalizzazione.
Detto questo, sì, il blocco tramite regex o almeno il blocco con wildcards avverrà per la prossima release.
Posso confermare che la precedente implementazione ha funzionato perfettamente e ha risolto completamente il problema di Gmail. Le liste di autorizzazione e di blocco dei domini email sono entrambe efficaci come soluzioni drastiche. Tuttavia, bloccare Gmail semplicemente non è praticabile.
@codinghorror Capisco il punto di vista contrario alla normalizzazione per i diversi provider di posta elettronica. Tuttavia, penso che abbia senso poter gestire almeno Gmail (~43% di tutti gli indirizzi email apparentemente nel 2020, 53% negli Stati Uniti) in modo non distruttivo. Potrebbe essere paragonabile al supporto nativo dell’autenticazione OAuth per i principali provider.
@sam ^ Questa è un’ottima idea per un’alternativa. 
Forse questa soluzione, con un esempio per la corrispondenza gmail/googlemail, potrebbe essere molto intuitiva e potente.
Abbiamo un utente che ha creato diverse migliaia di account con un unico indirizzo Gmail (utilizzando i punti) e sta inviando spam per promuovere il proprio sito concorrente, cercando di sottrarre utenti. Appena verrà rilasciata l’aggiornamento alla versione 2.8, bloccheremo tutti gli indirizzi email contenenti punti o il simbolo più. Vorrei che la precedente implementazione fosse ancora disponibile, ma apprezzo che la questione stia venendo affrontata e che una soluzione sarà presto disponibile. Farà una differenza enorme, grazie
Ho riflettuto un po’ su questo e ho pensato a una soluzione che potrebbe avere senso.
Potrebbe esserci un’opzione di amministrazione per elaborare e memorizzare una versione normalizzata dell’email (elaborando solo la parte del nome utente, ovvero username@..).
Ma applicare questo solo per i domini specificati dall’amministratore.
Quindi una lista simile alle liste di allow/block dei domini email, con due caselle di controllo per dominio:
Poi utilizzare questi record come riferimento per impedire registrazioni aggiuntive che utilizzano versioni alternative di quell’email (senza influenzare il record email principale, che può comunque contenere + e punti).
In questo modo, l’onere di selezionare quali domini memorizzare come record normalizzati e come normalizzarli ricade solo sull’amministratore, consentendogli di rispondere ai domini email problematici man mano che emergono.
Comunque, lascio questa idea qui in modo che possa essere presa in considerazione in un secondo momento.
Saluti.
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.
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
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.
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.
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
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. 
Questo argomento è stato chiuso automaticamente dopo 16 ore. Non sono più consentite nuove risposte.