My forum just receive a large number of spaming user registration.
He/She using Gmail dot tricks ( http://www.makeuseof.com/tag/1-awesome-gmail-tip-you-dont-know-about-seriously/) to create this large number of email account.
Can you prohibid this trick ?
My discourse is using Cloudflare at a CDN and DNS provider, Discourse can’t work fine caused the IP thing.
Couldn’t you ban their IP instead?
Hum, I’m using Cloudflare for CDN, and discourse only see Cloudflare, not user’s IP. (in Wordpress, Cloudflare has an plugin to pass the user IP to website)
At vB we used to get literally thousands of bot “seed” accounts like
aliasg.maila.ccount
alia.sgmai.laccount
ali.asg.mailacco.unt
alias.g.m.ailaccount
al.iasgmai.lacc.ount
… etc. ad nauseum
We eventually had a plugin written to deal with them
Yeah you’re going to need to turn that off, or figure out how to get CloudFlare to send proper headers for the passthrough IP.
Yes. I’m working on that by config Nginx.
Cloudflare actually sends user’s IP via header HTTP_CF_CONNECTING_IP
But prohibid gmail dot trick is useful too.
You really need to get IP passed through correctly otherwise you are really screwed. That’s about the only effective way to stop spammers, if they are clever.
While in this case banning the IP is the right thing to do, I think there is merit in being able to stop user.name@gmail.com and username@gmail.com from being both registered as two different users at any given discourse forum.
No sane administrator should allow this behaviour (from gmail) and maybe we could have an option to extend this prohibition to other email providers as well.
It would need a simple list like ‘@gmail.com’, ‘@anotherprovidder.com’ and then it would check for registered users by removing the dot or any other relevant character (could have a list as well) to avoid users that want to have two or more accounts.
Maybe a plugin with this functionality would be the best solution.
Definitely make it optional if you do it at all. I depend on this trick for troubleshooting!
Estamos sendo completamente bombardeados com esse tipo de registro e o spam que eles postam. 
mycoolgmailaddress4spam+unlimitedcombinationslol@gmail.com
m.ycoo.lgm.ailaddress4s.pam@gmail.com
Infelizmente, estamos indefesos contra esses registros. A única defesa é não ser alvo de spammers com alguma habilidade.
Objetivamente, não há como bloquear um spammer com IPs suficientes de criar 100.000 contas usando um único endereço do Gmail em qualquer fórum Discourse padrão, usando esses truques.
Todas as configurações de limitação de spam/postagem são inúteis quando os spammers têm acesso a contas ilimitadas com um único endereço do Gmail.
É estranho que seu site tenha um problema tão grave com isso, já que não consigo me lembrar de uma única vez em que isso tenha acontecido com nossos mais de 1.000 clientes hospedados nos últimos 4 anos.
@codinghorror Você atribui isso a defesas suficientes contra essa técnica comum de spammers ou ao fato de esses sites não serem alvos de spammers? Esses sites recebem regularmente grandes volumes de tentativas de registro de spam de qualquer tipo que são bloqueadas pelas defesas?
Depende muito do nicho, dos volumes de tráfego e se é adequado para as campanhas de resposta direta deles. Um spammer que consegue manter posts perto do topo da lista de mensagens está essencialmente obtendo espaço publicitário fantástico por centavos. Espaço publicitário na homepage acima da dobra pode frequentemente valer de $xxx a $x,xxx por dia, dependendo do nicho e do volume de tráfego.
Spammers que fazem dinheiro significativo por mês com campanhas de resposta direta em um fórum específico, e que podem morar em países em desenvolvimento com salários locais médios extremamente baixos, podem ficar motivados.
Tenho vários outros fóruns Discourse em execução desde 2015-2016 e eles praticamente não têm problemas com registros ou posts de spam, devido a não serem alvos. Não ser alvo de spammers é uma boa defesa, até que você se torne um alvo. O Discourse não é suportado por padrão na maioria dos softwares de spam de fóruns disponíveis comercialmente, pelo que sei, como o Xrumer.
Bem, há uma regra que gosto de citar.
Se você for alvo individualmente pelo Mossad, você está ferrado.
É verdade, um spammer dedicado sempre conseguirá passar. Já vimos eles abrirem seus próprios servidores de e-mail e gerarem milhares de endereços de e-mail — boa sorte com isso.
Dito isso, não permitir registros duplicados usando esses truques do Gmail parece uma precaução razoável?
@codinghorror - Hahaha, adorei. Mas preferiria não apenas me render e morrer. 
Acredito que isso não seja um caso de borda; muitos sites sociais não permitem o registro usando o mesmo endereço do Gmail devido ao abuso por spammers. Na minha opinião, a maioria dos grandes não permite.
@bartv - Sim, com aqueles que possuem seus próprios servidores de e-mail, pelo menos podemos bloquear seus domínios como uma defesa razoavelmente eficaz (embora as contas que passaram antes do bloqueio ainda possam ser usadas). Eles podem obter mais domínios, mas isso, pelo menos, custa recursos a eles — ao contrário das garras do Gmail.
Com essas garras do Gmail, realmente não há defesa, e variações adicionais de endereço não custam nada ao spammer. A ‘distância de Levenshtein em e-mails de spammers’ pode ajudar um pouco com a técnica dos pontos, após banir repetidamente o mesmo endereço do Gmail em diferentes combinações de pontos. Mas não consigo me defender atualmente da técnica do ‘+’, que permite essencialmente combinações ilimitadas.
A menos que você tenha amigos poderosos o suficiente para ajudá-lo. E esse é o time de desenvolvimento do Discourse, aqui (e talvez a comunidade, se pensarmos em plugins).
Desculpe, mas não seria bom para o Discourse tratar todos os endereços do Gmail sem os pontos e o que vem depois do sinal de +? Não parece tecnicamente muito complicado. São apenas algumas linhas de código bem simples. Registro => detecta gmail.com após o sinal de @ => remove todos os pontos e o que vem depois do sinal de + até o sinal de @, e usa esse endereço => Já usado? => Retorna uma mensagem de erro “Endereço de e-mail já utilizado”.
Pronto. Ou estou esquecendo algo?
Se os spammers começarem a saber que isso funciona no Discourse, vão mirar cada vez mais fóruns do Discourse com essa técnica. Quero dizer, por que não fariam isso?
Configuramos que novos usuários precisem de aprovação manual de todos os tópicos/posts nas primeiras X vezes, o que eliminou o problema quase da noite para o dia. Alguns deles descobriram que editar a postagem depois funciona, até que ajustamos isso também para os níveis de confiança 0 e 1.
Embora isso não tenha nada especificamente a ver com qualquer truque de domínio em particular, isso interrompe o problema real, que é um humano motivado tentando contornar suas contramedidas. Se não conseguirem usar um “truque” do Gmail, encontrarão outro truque. O nível de confiança 1 pode postar e o nível de confiança 1 precisa de 5 minutos de tempo de leitura é o tipo de coisa para a qual eu pessoalmente me inclinaria.
Bem, vamos ver. Quais caracteres podem ser usados aqui?
Alguns serviços de e-mail suportam uma tag incluída na parte local, de modo que o endereço seja um alias para um prefixo da parte local. Por exemplo, o endereço
joeuser+tag@example.comdenota o mesmo endereço de entrega quejoeuser@example.com. O RFC 5233 refere-se a essa convenção como subendereço, mas também é conhecido como endereçamento com plus, endereçamento com tag ou extensões de e-mail.Endereços nesse formato, usando vários separadores entre o nome base e a tag, são suportados por vários serviços de e-mail, incluindo Runbox (plus), Gmail (plus), Rackspace Email (plus), Yahoo! Mail Plus (hífen), iCloud da Apple (plus), Outlook (plus), ProtonMail (plus), FastMail (plus e Endereçamento por Subdomínio), MMDF (igual), Qmail e Courier Mail Server (hífen). Postfix e Exim permitem configurar um separador arbitrário do conjunto de caracteres legais.
Então temos: plus, hífen, igual, ponto e cifrão/hashtag.
A única coisa que consigo pensar que funcionaria aqui é uma configuração super rigorosa para impedir todos os caracteres fora de A-Z a-z 0-9 em endereços de e-mail.
Isso definitivamente impedirá que alguns usuários se cadastrem, mas pode ser um compromisso viável se você estiver sendo… hum… visado por agentes de elite do Mossad, eu acho 
O que você acha, @eviltrout?
Isso pode ser muito rigoroso; o ponto aqui é evitar o uso múltiplo de variações de endereço de e-mail, não banir totalmente. Você poderia, em vez disso, adicionar um endereço de e-mail ‘canônico’ a cada conta, contendo a versão limpa do endereço de e-mail real do usuário. Compare a versão limpa dos endereços de e-mail para novos cadastros com esse valor. Mas provavelmente é mais fácil dizer do que fazer…
Sim, prefiro a mudança sugerida pelo Bart aqui.
[ ] usar uma forma canônica para armazenamento interno de endereços de e-mail (remove +QUALQUER COISA, remove comentários e assim por diante.)
Oferece uma implementação em Ruby que poderíamos aproveitar, mas precisaríamos ter muito, muito, muito cuidado (o exemplo 1 é um risco de segurança conforme: https://stackoverflow.com/a/52125295/17174)
EmailAddress.canonical("(test)sam.saffron(test)+100@gmail.com")
=> "test@gmail.com"
[3] pry(main)> EmailAddress.canonical("sam.saffron(test)+100@gmail.com")
=> "samsaffron(test)@gmail.com"
[4] pry(main)> EmailAddress.canonical("sam.saffron+100@gmail.com")
=> "samsaffron@gmail.com"
Portanto, eu sugeriria que nosso processo de “canonização”:
Remova +QUALQUER COISA
Converta para minúsculas (já fazemos isso)
SE for gmail, googlemail ou estiver na lista branca personalizada, remova os pontos
Remova comentários. (...) que também são um vetor para abuso.
Normalize unicode o endereço, o que é tecnicamente permitido conforme: Email address - Wikipedia
Em seguida, adicione uma configuração oculta do site com uma lista branca de domínios para remoção de ..
Dito isso, há muitas maneiras de abusar disso. Ora, alguém pode estar mantendo um cache de 10.000 endereços de e-mail do Gmail de spam e apenas se cadastrar com todos eles usando algum tipo de bot. Se você estiver sendo alvo, pode tanto aprovar cada novo cadastro por um tempo; talvez este seja um dos raros casos em que você deseja um recaptcha no cadastro em um plugin.