Le problème est que forcer les emails canoniques revient essentiellement au même, sauf que c’est beaucoup moins hostile pour l’utilisateur.
Aucun Sam.sam@gmail.com n’est autorisé ; Sa.msam+123@gmail.com est déjà enregistré.
De toute façon, nous pourrons implémenter une expression rationnelle (regex) dès la prochaine version.
Oui, mais c’est inutile en pratique, ce qui explique pourquoi nous avons cette discussion… une fois qu’ils ont l’arme nucléaire, il vous faut aussi des armes nucléaires.
« Hostile à l’utilisateur » est un concept dénué de sens dès lors que votre public dispose de l’arme nucléaire et est prêt à s’en servir.
Je ne suis pas d’accord avec cela, la solution a parfaitement fonctionné pour @markersocial, puis j’ai annulé le changement car on m’y a forcé la main.
Il n’y a aucune faille connue avec l’approche de canonicalisation que j’ai mise en œuvre et ensuite annulée ; elle résout à 100 % le problème Gmail mentionné ci-dessus.
Eh bien, je ne suis pas d’accord, car cela reporte le fardeau du code et des efforts sur notre côté plutôt que sur le leur. « Normaliser » les adresses e-mail est assez complexe, cela varie selon le fournisseur d’e-mail, et je ne souhaite pas être impliqué dans ce domaine.
Autrement dit, laissons-les construire et gérer leurs propres dispositifs nucléaires ; nous n’avons pas besoin d’expédier des proto-bombes nucléaires à chaque pays et dans chaque installation de Discourse « au cas où ».
(De plus, la possibilité de bloquer des adresses e-mail via des expressions régulières est très puissante, surtout puisque l’e-mail équivaut à l’identité dans Discourse.)
Nous pourrions leur permettre de normaliser avec leurs propres règles regex, comme un compromis, ce qui nous éloignerait du domaine de la normalisation.
Cela dit, oui, le blocage par regex ou, à défaut, par jokers, sera mis en œuvre pour la prochaine version.
Je peux confirmer que la mise en œuvre précédente fonctionnait parfaitement et a résolu entièrement le problème Gmail. Les listes d’autorisation et de blocage de domaines d’e-mails sont toutes deux des mesures très efficaces. Cependant, il n’est simplement pas viable de bloquer Gmail.
@codinghorror Je comprends l’argument contre la normalisation pour les différents fournisseurs d’e-mails. Mais je pense qu’il serait logique de pouvoir couvrir au moins Gmail (~43 % de toutes les adresses e-mails en 2020, 53 % aux États-Unis) d’une manière non destructive. Cela pourrait être comparable à la prise en charge native de l’authentification OAuth auprès des grands fournisseurs.
@sam ^ C’est une excellente idée pour une alternative. 
Peut-être que cela, avec un exemple pour la correspondance gmail/googlemail, pourrait être très convivial et puissant.
J’ai actuellement un utilisateur qui a créé plusieurs milliers de comptes avec une seule adresse Gmail (en utilisant des points) et qui spamme pour promouvoir son site concurrent afin de détourner des utilisateurs. Je vais passer à la version 2.8 et bloquer toutes les adresses e-mail contenant un point ou un symbole plus dès sa sortie. J’aurais aimé que l’ancienne implémentation soit disponible, mais j’apprécie que cela soit pris en charge et qu’une solution sera disponible. Cela fera une différence énorme, merci
J’ai donc réfléchi un peu à cela et j’ai trouvé une solution qui pourrait peut-être avoir du sens.
Il pourrait exister une option d’administration pour traiter et stocker une version normalisée de l’adresse e-mail (en ne traitant que la partie nom d’utilisateur, c’est-à-dire nomdutilisateur@..).
Mais n’appliquer cela que pour les domaines spécifiés par l’administrateur.
Donc une liste un peu comme les listes de blocage/autorisation de domaines e-mail, avec deux cases à cocher par domaine :
Ensuite, utilisez ces enregistrements comme référence pour interdire les enregistrements supplémentaires utilisant des versions alternatives de cet e-mail (sans affecter l’enregistrement e-mail principal, qui peut toujours contenir des + et des points).
De cette façon, la charge de choisir quels domaines stocker dans un enregistrement normalisé et comment les normaliser revient uniquement à l’administrateur, lui permettant de réagir aux domaines e-mail problématiques au fur et à mesure qu’ils apparaissent.
Quoi qu’il en soit, je laisse simplement cette idée ici afin qu’elle puisse être prise en compte à un moment donné.
Salutations.
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é.
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
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.
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.
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
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. 
Ce sujet a été automatiquement fermé après 16 heures. Les nouvelles réponses ne sont plus autorisées.