Je peux confirmer que la correction initiale fonctionnait parfaitement et a résolu ce problème avec les adresses Gmail. Ce serait une véritable bouée de sauvetage si ce mode optionnel était rétabli.
Les spammeurs apprennent constamment de nouvelles techniques et continuent à tromper avec succès de grands acteurs comme Facebook, Instagram et Twitter. Cela rend la plupart des autres plateformes « mode facile ». Pour beaucoup d’entre eux, c’est un travail à temps plein, ce qui revient essentiellement à :
Si exploitable et (ressources requises < argent gagné), alors cela sera exploité.
Ils peuvent contourner pratiquement n’importe quelle mesure ; le seul espoir est d’augmenter les coûts de telle sorte que cela ne soit plus financièrement rentable.
Être capable de spammer en masse avec presque un nombre illimité d’e-mails/comptes (avant détection et blocage rétroactif par un modérateur/admin de leur adresse Gmail canonique, suivi de la suppression manuelle de leurs publications) est très rentable. Encore plus s’il n’y a pas d’équipe de modérateurs disponible 24h/24 et 7j/7.
Le coût pour contourner les mesures anti-spam continue de diminuer. Un exemple : les proxies 4G/5G. Pour environ 30 à 50 $ par mois, les gens peuvent obtenir accès à des adresses IP mobiles réelles pratiquement illimitées, provenant de FAI/ASN légitimes qui tournent automatiquement ou manuellement et sont partagées par des villes ou états entiers d’utilisateurs légitimes de grands FAI. Les adresses IP 4G/5G sont partagées par de nombreux utilisateurs simultanément.
Bloquer ces FAI/ASN ou adresses IP n’est pas approprié (on ne peut pas simplement bloquer tout le monde utilisant Verizon, AT&T, etc.). Ils utilisent généralement l’adresse IP une seule fois avant de la jeter. Les adresses IP individuelles bloquées provenant de là bloqueront également des utilisateurs légitimes qui partagent cette adresse IP au hasard. Le blocage par adresse IP devient progressivement une pratique obsolète (à l’exception des ASN des sociétés d’hébergement connues). Vous pouvez voir le début de l’iceberg sur ces forums :
https://mpsocial.com/c/public-marketplace/61
https://www.blackhatworld.com/forums/proxies-for-sale.112/
Je pense que les spammeurs sont un mélange de bots entièrement ou partiellement développés en interne et de spam manuel. Comme Discourse gagne plus de parts de marché, ce qui est clairement le cas avec une croissance fantastique, je serais surpris qu’il ne devienne pas une cible de bots disponibles commercialement.
Dès que Xrumer prendra en charge la dernière version de reCAPTCHA, je dirais que la plupart des webmasters sur des forums anciens remarqueront une forte augmentation du spam en raison du coût extrêmement bas du spam (plus besoin d’utiliser une API de résolution de captcha, qui sont déjà très peu chères par 1 000 résolutions) :
http://botmasterlabs.net/buy1/
Les gens peuvent déjà créer leurs propres plugins/scripts pour prendre en charge pratiquement n’importe quelle plateforme en utilisant Xrumer. Mais s’ils prennent en charge Discourse nativement un jour :
Je ne peux pas prétendre être impartial sur ce sujet, car j’ai directement besoin de mesures anti-spam. Le post original sur l’astuce du point Gmail a été créé par quelqu’un d’autre en 2014 et il semble qu’un autre utilisateur ait résolu ce problème en exigeant une approbation pour les x premiers messages, donc peut-être y a-t-il au moins trois rapports d’utilisateurs ? ![]()
Désolé pour cette digression, revenons au sujet.
Concernant le blocage par expressions régulières pour les e-mails, oui vous avez raison. C’est une solution partielle, mais pas idéale pour les raisons suivantes :
Si on bloque tous les Gmail avec 1 point ou plus avant @ :
- Cela bloquera inévitablement de vrais utilisateurs légitimes de Gmail qui ont soit 1 soit plusieurs points dans leur adresse Gmail, ce qui est très courant.
- Les spammeurs peuvent encore créer un grand nombre de variations avec un seul point. Par exemple, Gmail a une longueur maximale de 30 caractères, par exemple 12345678901234567890123456789.0@gmail.com aura 30 combinaisons utilisables avec un seul point.
Bloquer tous les Gmail avec 2 points ou plus avant @ :
- Moins d’utilisateurs légitimes de Gmail bloqués, mais cela bloquera toujours des utilisateurs légitimes de Gmail ayant plus d’un point dans leur adresse e-mail.
- Les spammeurs peuvent créer beaucoup plus de variations avec un seul Gmail de 30 caractères. Je pense à environ 842 combinaisons ou plus.
Je peux confirmer que les nouveaux comptes sont passés après que le blocage ait été actif, car la date de création du blocage est le 1er février. Je surveillais la création de nouveaux comptes hier en voyant à la fois des cas où la règle de blocage avait de nouvelles correspondances récentes ainsi que de nouvelles inscriptions utilisant des combinaisons de la même adresse e-mail (points uniquement).
J’ai désactivé les inscriptions pendant la nuit et les ai réactivées ce matin. Ils ont créé 104 nouveaux comptes aujourd’hui avec des permutations de cette adresse Gmail et continuent de s’inscrire davantage. Je peux confirmer que, une fois les points supprimés des adresses e-mail de ces comptes, il s’agit d’une correspondance exacte avec l’enregistrement bloqué des e-mails filtrés.
J’ai essayé de tester les blocages dans rails c comme décrit, c’est là que cela devient un peu étrange.
Il semble donc que certains enregistrements retournent « true » comme prévu, tandis que d’autres retournent « false » même si l’e-mail testé correspond exactement à l’e-mail bloqué canonique. Pour les enregistrements qui retournent « true », cela a fonctionné entièrement comme prévu et a retourné true pour toutes les variations que j’ai testées. Mais pour les e-mails qui retournent false, toutes les variations que j’ai testées ont également retourné false.
J’essayais de trouver des corrélations. Je peux confirmer qu’il n’y a pas de corrélation (ou du moins pas de corrélation cohérente) avec :
La longueur de l’e-mail (avant @)
L’e-mail contenant des caractères et des chiffres
Le nombre de correspondances (nombre de fois bloqué)
La date de correspondance
Il semble cependant qu’il y ait une corrélation avec la date de création du blocage, les plus anciens étant moins susceptibles de fonctionner (retournent false). Les enregistrements créés il y a 9 jours ont retourné un mélange de true/false, et tous les enregistrements que j’ai testés jusqu’à présent créés avant cela (1h-8j) retournent true.
Cela pourrait peut-être être lié à « max age unmatched emails » ? Je pense que cette option est quelque peu nouvelle, je l’ai réglée sur la valeur par défaut de 365 jours.
