Suggestion : Adresse e-mail de blocage générique

Would be good if there was a way to add wildcard blocked email addresses. E.g. When a spammer uses the gmail dot trick.

E.g.

example@gmail.com
example+random12345@gmail.com
ex.a.mple+random12345@gmail.com
e.xamp.le@gmail.com

Are all the same email address, spammers can use one gmail address to make unlimited accounts easily.

Blocking an address with wildcards like below I believe would be a good solution:
e*x*a*m*p*l*e*@gmail.com

I don’t necessarily think that all registrations using these gmail address variations should be blocked, just that it would be useful that if a gmail address is blocked, all variations are blocked too or that we can manually add a wildcard gmail to the email blacklist.

1 « J'aime »

Are you seeing an actual specific problem or is this just a theory? If it is a specific problem can you share the specific spammer emails?

4 « J'aime »

Yes it’s an actual problem I’m experiencing, I have spammers regularly making tens of thousands of accounts per single gmail account with the dot method and a sufficient pool of IPs.

I’m only seeing the dot trick being used, not 100% sure about if the + method works also. Last I checked it was possible to register using email addresses with + characters, so that trick should work too.

For example, this email (not a real email):
constantinehamilton1337x@gmail.com

Can make 16,777,216 unique email addresses using the dot method only and essentially unlimited using the + method. Makes it super efficient for spammers. Domain blacklist isn’t viable seeing it’s gmail.

You can see a generator here (gets laggy over 8k combinations): Gmail Dot Trick Generator

If this was actually implemented with a wildcard-like approach (instead of being handled automatically by Discourse), you’d probably want to be much more specific than e*x*a*m*p*l*e*@gmail.com. Doing it that way could result in blocking innocent people, especially if the spammer’s email address is relatively short. Looking specifically for . and + would probably be much safer.

2 « J'aime »

What is your levenshtein_distance_spammer_emails setting at, the default 2 or the max 3 ?

2 « J'aime »

Thanks for the heads up about this setting levenshtein_distance_spammer_emails. I’ve never seen or modified it before - it’s at the default of 2.

3 « J'aime »

I don’t understand your math. You can add only a single dot between characters, so each N-character address is good for only 2*n addresses. You could probably have a plugin that saved or compared against the dot-removed address and disallowed +addresses.

2 « J'aime »

@pfaffman - I was just going off the figures given from Gmail Dot Trick Generator which is for every additional character above 2 the amount of addresses is doubled (it freezes at about 8k though).

I think 2*n, if I understand what you mean by this (as in a 26 character address would have 52 combinations?) would be too low. As they can add multiple dots throughout the address.
E.g:
constantinehamilton1337x@gmail.com
con.stantinehamilton1337.x@gmail.com
co.nst.antineh.amilton1.3.37x@gmail.com
constantineh.a.m.ilto.n13.37x@gmail.com
c.o.nsta.ntinehamil.ton1337x@gmail.com

Anyhow, whatever the exact figure is, it’s a lot. Yeah, your suggested solution would make sense!

1 « J'aime »

Yeah. I wasn’t doing the math right. I was allowing just one dot. I once almost knew that math, but didn’t this morning. :wink:

But a plugin that saved a shot and plus free version of the address as an additional address would do what you want and wouldn’t be that hard.

3 « J'aime »

Remarque … lorsque vous bloquez sam.sam@gmail.com, nous bloquons désormais automatiquement sam.sam+1@gmail.com et ainsi de suite…

10 « J'aime »

Cette fonctionnalité fonctionne très bien @sam :slight_smile:

Je pense que la mise en œuvre précédente que vous avez créée pourrait toujours être très utile en tant que fonctionnalité anti-spam supplémentaire. Elle a fonctionné de manière incroyable pendant la courte période où elle était disponible et activée (désactivée par défaut).

Sinon, les spammeurs peuvent toujours créer des comptes en masse avec une seule adresse Gmail avant qu’un modérateur ou un administrateur ne s’en aperçoive. Par exemple, créer des comptes sans poster immédiatement.

Les administrateurs et modérateurs devront trouver et ouvrir manuellement chaque compte individuel pour le bannir ou le supprimer. Cela peut être assez fastidieux, surtout lorsqu’un spammeur peut créer des centaines, voire des milliers de comptes avec une seule adresse Gmail avant d’être banni. De plus, la recherche par adresse e-mail est difficile, par exemple j.ohan.2.1@gmail et jo.ha.n21@gmail.

S’ils ne sont pas traqués manuellement, les spammeurs conservent un large réservoir de comptes pour jouer à « Whac-A-Mole », tout en n’ayant besoin que d’une seule adresse Gmail pour les obtenir.

@sam Juste pour faire un point après davantage de tests sur le terrain, je pense que la mise en œuvre précédente qui a été annulée est nettement plus efficace contre les spammeurs motivés. Je reçois toujours un nombre important d’inscriptions utilisant ces astuces de permutation de Gmail.

Je suis très reconnaissant que la protection actuelle ait été mise en place, car elle est très efficace. Cependant, je pense qu’il y a une faille à permettre la création d’un nombre illimité de comptes utilisant le même e-mail jusqu’à ce qu’ils soient spécifiquement remarqués et bannis manuellement. Cela représente une charge supplémentaire pour les modérateurs (qui ne peuvent pas voir les adresses e-mail des comptes par défaut, sauf si cette option est activée, je crois), surtout en l’absence d’outils de suppression en masse des comptes (par exemple, sélectionner plusieurs comptes dans la liste de recherche avec des cases à cocher et les bannir/supprimer tous). Cela signifie qu’un modérateur devra naviguer manuellement vers chaque compte individuel pour le supprimer/bannir. C’est particulièrement difficile lors de la recherche de comptes avec des adresses e-mail permutées.

Étant donné que la mise en œuvre précédente était optionnelle (désactivée par défaut), qu’elle avait déjà été développée et fonctionnait comme prévu, puis a été retirée, il semble vraiment dommage qu’elle ne soit plus disponible pour les communautés qui souhaiteraient l’utiliser pour une protection anti-spam supplémentaire contre les spammeurs motivés.

C’est pourquoi j’ai dit que certains caractères doivent être totalement interdits dans les adresses e-mail (facultativement). Il s’agit notamment des caractères permettant le sous-adressage, comme le signe plus, le point, le tiret, etc. Avec une expression rationnelle, vous pouvez également bloquer cela par service, par exemple : « aucune adresse e-mail se terminant par @gmail.com et contenant un signe plus n’est autorisée ». cc @sam

1 « J'aime »

L’ancienne implémentation autorisait toujours le +addressing tout en maintenant un seul adresse canonique par compte (ce qui me semble probablement plus sûr).

Ainsi, vous pouviez être inscrit avec sam+discourse-meta@gmail.com, ce qui est pratique pour les règles Gmail internes que vous avez configurées. Mais cela aurait ensuite bloqué la création de nouveaux comptes depuis sam@gmail.com ou sam+1@gmail.com.

Je ne suis pas contre l’ajout d’une liste blanche, mais je pense que l’imposition des adresses canoniques est très utile dans le cas de Gmail et constitue un paramètre par défaut tout à fait raisonnable.

1 « J'aime »

La sécurité n’est pas vraiment l’objectif ici. Le site en question nécessite une solution plus radicale en raison de l’ampleur du problème auquel il est confronté. Tant que c’est optionnel (ajoutez votre propre « regex de protection des e-mails »), cela me semble parfaitement sûr. Pour les sites qui en ont besoin, ils peuvent activer le mode Verrouillage Complet.

1 « J'aime »

Nous avons actuellement des domaines d'e-mails bloqués.

Je suppose que nous pourrions ajouter des modèles d'e-mails bloqués.

Cependant, obtenir le bon regex est plutôt ennuyeux compte tenu de toutes les échappées nécessaires. Je m’inquiète de proposer ce genre d’options, car les chances que les gens obtiennent le bon regex et qu’il corresponde à l’intention sont très faibles. Ils doivent se souvenir d’échapper les points et les signes plus.

.*\+.*@gmail\.com

Nous pourrions, je suppose, utiliser un modèle simplifié non basé sur le regex qui ne fait qu’étendre * et ?.

*+*@gmail.com

5 « J'aime »

:wave: Désolé pour ma réponse tardive !

Si l’ancienne implémentation était réintégrée en tant qu’option, je crois que cela résoudrait entièrement le problème lié à Gmail. Du moins dans mon cas. C’est, à mon avis, tout à fait idéal et cela ajoute suffisamment de coûts aux spammeurs pour rendre la lutte contre eux gérable. Cela ferait vraiment la différence entre nécessiter une modération intensive à temps plein 24h/24 et ne pas en avoir besoin.

J’ai bloqué plusieurs domaines qui autorisent des adresses similaires et qui utilisent la liste des domaines d’e-mail autorisés. Le problème est que les utilisateurs peuvent créer de nombreux comptes avant que l’un d’eux ne soit banni/bloqué (ce qui active le blocage des permutations de cette adresse Gmail pour les nouveaux comptes, mais les comptes existants restent inchangés). Cela représente une lourde charge pour la modération et rend le nettoyage de chaque compte individuel fastidieux.

Par exemple, j’ai eu un fil de discussion avec environ 200 réponses, utilisant un message par compte, tous créés avec la même adresse Gmail. De nombreux cas similaires. Ce sont des exemples où les comptes sont faciles à identifier, car les rechercher via les permutations de l’adresse Gmail d’origine est très difficile en alternative. Certains font de l’élevage de comptes en grand nombre à partir d’un petit nombre d’adresses Gmail et ne publient rien dessus pendant des mois.

Pour une solution basée sur le blocage par expression régulière, bloquer les signes + serait assez inoffensif, tandis que bloquer les points (.) risquerait d’empêcher un nombre significatif d’e-mails légitimes, par exemple john.smith@gmail.com. Bloquer les adresses contenant plus d’un point causerait probablement des dégâts collatéraux minimes, bien que cela permettrait toujours plusieurs permutations d’une adresse Gmail, mais beaucoup moins que dans le cas de 2 points ou plus.

À mon avis, l’ancienne implémentation est idéale et n’est pas déraisonnable à mettre en œuvre en tant que protection optionnelle ; la plupart des sites de réseaux sociaux populaires n’autorisent pas l’inscription avec plusieurs permutations Gmail en raison de l’exploitation intensive par les spammeurs.

Merci :slight_smile:

1 « J'aime »

@sam, je suis fermement convaincu que les sites devraient pouvoir implémenter ce niveau optionnel de verrouillage regex des e-mails si nécessaire. Sinon, nous irions à l’encontre de l’un des principes fondamentaux de Discourse, qui est d’être « sûr par défaut ».

1 « J'aime »

Nous pouvons régler cela pour la prochaine version, mais je maintiens toujours ma mise en œuvre initiale : la normalisation est la solution la plus conviviale pour les administrateurs de site. Vous cochez une case et, hop, le problème est résolu. Avec les expressions rationnelles, il faut apprendre leur syntaxe (ce qui vous prend 5 heures) et vous finissez avec une correction qui laisse passer des comptes spam, qui est hostile aux utilisateurs (pas de points, pas de signes plus) ou qui est un compromis.

Cela dit, bien sûr, nous pouvons intégrer le support des expressions rationnelles pour la prochaine version.

1 « J'aime »

Bah, c’est vraiment simple : « pas d’e-mails autorisés avec un plus ou un point ». Ce qui est, il faut l’admettre, assez restrictif et, évidemment, nous ne voudrions pas que ce soit activé par défaut. Mais c’est comme pour la question du « bamwar » : il y aura toujours suffisamment de mauvais acteurs pour qu’il faille avoir le bouton de lancement nucléaire, même si vous ne voulez pas vous en servir.

C’est comme la guerre nucléaire. Une fois que les armes nucléaires sont sur la table, les options « conviviales » ne sont plus possibles ; il ne vous reste plus qu’à espérer que, la plupart du temps, vous n’aurez jamais besoin d’en arriver là.