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 « J'aime »
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 « J'aime »
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 « J'aime »
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 « J'aime »
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 « J'aime »
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 « J'aime »
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.
J’ai fusionné la PR :
Elle ajoute un nouveau paramètre de site normalize emails qui supprimera les points et la partie +… d’un e-mail, puis vérifiera son unicité. Par exemple, s’il existe un utilisateur test+1@gmail.com et que test+2@gmail.com tente de s’inscrire, ils ne seront pas autorisés si le paramètre du site est activé.
7 « J'aime »
Fantastique, je pense que cela résout à 100 % le problème de @markersocial et constitue un excellent paramètre à activer si vous devenez la cible de cette attaque spécifique.
Faites-nous savoir comment cela se passe @markersocial
4 « J'aime »
Merci beaucoup d’avoir implémenté cela, c’est une victoire énorme - tellement heureux que cela ait été ajouté. Je l’ai mis en ligne hier et je surveille.
Jusqu’à présent, cela semble fonctionner à 100% comme prévu et résoudre entièrement ce problème. Les gens peuvent toujours s’inscrire avec des points dans leurs e-mails (et présumablement des +, je n’ai pas vu ces inscriptions récemment). Mais ils ne peuvent pas continuer à créer des comptes avec des variations du même gmail. D’après la discussion sur GitHub, c’était certainement le meilleur choix de conserver l’e-mail d’origine tel quel.
Cela dit, je vais laisser ici des suggestions qui, je pense, amélioreraient cette fonctionnalité sans devenir trop compliquée :
Au lieu d’avoir une case à cocher pour activer/désactiver la normalisation des e-mails. Avoir deux listes, similaires au style de la liste de blocage des domaines de messagerie.
- Liste de domaines pour appliquer la normalisation des points
- Liste de domaines pour appliquer la normalisation des +
Par exemple :
L’administrateur ajoute gmail.com aux deux listes de normalisation de domaines.
e.mai.l+123@gmail → email@gmail.com
L’utilisateur ajoute outlook.com à la liste de normalisation des + (uniquement) :
us.er+123@outlook.com → us.er@outlook.com
Les e-mails us.er@email.com et user@email.com étant la même adresse/le même compte sont spécifiques à quelques fournisseurs et pas vraiment standard. Alors que le + semble être une norme (pour tout fournisseur qui le permet).
Cela permettrait aux administrateurs d’appliquer sélectivement ces règles individuellement aux domaines de messagerie problématiques au fur et à mesure qu’ils apparaissent, au lieu d’appliquer la normalisation (des deux types) à tous les domaines de messagerie.
N’ayez aucune attente pour ce qui précède, je laisse juste la suggestion au cas où elle serait utile.
Quoi qu’il en soit, merci encore, j’apprécie vraiment vraiment que cela ait été implémenté. C’est un game changer.
2 « J'aime »
Je me demande cependant s’il s’agit d’un problème théorique ou réel. Je comprends le désir de fidélité, mais je préférerais entendre parler de quelques cas spécifiques où cela pose un problème.
Le problème avec l’introduction d’un tel paramètre serait de réappliquer les règles de normalisation lorsque vous modifiez la liste des sites autorisés, cela en ferait un changement très complexe.
Nous normalisons maintenant inconditionnellement (indépendamment du paramètre du site), donc l’activer est instantané et s’applique à tout l’historique.
Génial 
Tous nos remerciements à @nbianca
4 « J'aime »
Génial ! Je ne savais pas que cela s’appliquerait rétroactivement. Je pensais qu’une adresse normalisée était enregistrée uniquement pour les nouvelles inscriptions.
Oui, le principal risque de problème concernerait les adresses e-mail qui autorisent les alias “+” mais ne considèrent pas les points à des emplacements différents comme identiques.
Toutes les occurrences de “+” dans les e-mails peuvent être traitées de la même manière sans aucun problème, car elles sont traitées de la même manière pour tous les fournisseurs qui l’autorisent, à ma connaissance. Les points sont les seuls pour lesquels il existe une certaine différence entre les fournisseurs.
Si ma mémoire est bonne, je pense que les e-mails professionnels de Google (utilisant des domaines personnalisés), Yandex et Outlook considéreront les différents placements de points comme des adresses différentes, mais les alias “+” pourront toujours être utilisés.
Les seuls cas seraient donc comme si theirs@email.com existait, cela bloquerait l’enregistrement de the.irs@email.com (alors qu’il s’agit en fait de deux comptes/adresses uniques selon ce domaine/fournisseur d’e-mail). Ce qui devrait probablement être très rare dans le monde réel. 
2 « J'aime »
Ce sujet a été automatiquement fermé après 16 heures. Les nouvelles réponses ne sont plus autorisées.