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!
이런 유형의 가입과 그들이 남기는 스팸으로 정말 시달리고 있습니다. 
mycoolgmailaddress4spam+unlimitedcombinationslol@gmail.com
m.ycoo.lgm.ailaddress4s.pam@gmail.com
불행히도 우리는 이런 가입에 대해 무방비 상태입니다. 유일한 방어 수단은 스킬이 있는 스팸머들의 표적이 되지 않는 것입니다.
이러한 트릭을 사용하여 충분한 IP를 가진 스팸머가 단일 Gmail 주소로 10만 개의 계정을 생성하는 것을 표준 Discourse 포럼에서 막을 객관적인 방법은 없습니다.
스팸머가 단일 Gmail 주소로 무제한의 계정에 접근할 수 있는 상황에서 모든 스팸/게시물 스로틀링 설정은 무용지물입니다.
지난 4년간 약 1,000명 이상의 호스팅 고객 중 이런 문제가 발생한 적이 단 한 번도 없었던 것으로 기억하는데, 왜 당신의 사이트에서는 이런 심각한 문제가 발생하는지 이상하지 않나요?
@codinghorror 이 일반적인 스팸머 기법에 대해 충분한 방어 수단을 갖췄기 때문이라고 보시나요, 아니면 해당 사이트들이 스팸머들의 표적이 되지 않기 때문이라고 보시나요? 해당 사이트들은 방어 시스템에 의해 차단되는 대규모 스팸 가입 시도가 정기적으로 발생하나요?
이는 주로 해당 사이트의 분야(니치), 트래픽 양, 그리고 스팸머들의 직접 반응(direct response) 스팸 캠페인에 적합한지에 따라 크게 달라집니다. 게시물 목록 상단에 게시물을 유지할 수 있는 스팸머는 사실상 매우 저렴한 가격에 훌륭한 광고 공간을 확보하는 셈입니다. 홈페이지의 첫 화면(above the fold) 광고 공간은 분야와 트래픽 양에 따라 하루 xxx달러에서 x,xxx달러까지의 가치를 가질 수 있습니다.
특정 포럼에서 직접 반응 스팸 캠페인을 통해 매달 상당한 수익을 올리는 스팸머들은, 특히 현지 평균 급여가 매우 낮은 개발도상국에 거주하는 경우라면 동기가 강할 수 있습니다.
저는 2015~2016년부터 운영 중인 다른 디스코urs 포럼을 여러 개 보유하고 있는데, 스팸머들의 표적이 되지 않아 스팸 가입이나 게시물 관련 문제가 거의 없습니다. 스팸머들의 표적이 되지 않는 것 자체도 좋은 방어 수단이 되지만, 결국 표적이 되면 그 한계가 드러납니다. 제가 아는 한, Xrumer와 같이 상업적으로 판매되는 대부분의 포럼 스팸 소프트웨어는 기본적으로 디스코urs를 지원하지 않습니다.
음, 내가 자주 인용하는 원칙이 하나 있거든.
모사드(Mossad)에게 개인적으로 표적이 되면, 너는 끝장난 거야.
맞아요, 전문 스팸머는 항상 방법을 찾아냅니다. 직접 메일 서버를 열어 수천 개의 이메일 주소를 생성하는 경우도 봤거든요. 그걸 막는 건 쉽지 않겠죠.
그래도, 이런 Gmail 트릭을 이용한 중복 가입을 허용하지 않는 건 합리적인 예방 조치라고 생각하지 않나요?
@codinghorror - 하하, 정말 좋아합니다. 하지만 그냥 굴러다니면서 죽지는 않겠습니다. 
이건 엣지 케이스가 아니라고 생각해요. 스팸머 악용을 방지하기 위해 같은 Gmail 주소로 가입을 허용하지 않는 소셜 사이트가 정말 많거든요. 제가 아는 한, 대형 사이트들은 대부분 이를 허용하지 않습니다.
@bartv - 네, 자체 메일 서버를 가진 사이트의 경우, 적어도 도메인을 블랙리스트에 등록하는 것이 꽤 효과적인 방어 수단이 될 수 있습니다(다만, 블랙리스트 등록 전에 통과한 계정들은 여전히 사용 가능합니다). 그들은 더 많은 도메인을 확보할 수 있겠지만, 적어도 그들에게는 자원이 소모됩니다 - Gmail 트릭의 경우와는 달리요.
이러한 Gmail 트릭의 경우, 실제로는 방어 수단이 없으며 추가적인 주소 변형에 대해 스팸머에게 비용이 전혀 들지 않습니다. 같은 Gmail 주소를 다양한 점(dot) 조합으로 여러 번 차단한 후, ‘levenshtein distance spammer emails’ 기법을 사용하면 점 트릭에 대해 어느 정도 도움이 될 수 있습니다. 하지만 현재로서는 + 트릭에 대해서는 방어할 수 없는데, 이 트릭은 사실상 무한한 조합을 가능하게 하기 때문입니다.
그렇지 않은 한, 널 도와줄 만큼 영향력 있는 친구들이 있어야 한다. 그리고 여기서는 디스코urs 개발팀(플러그인을 고려한다면 커뮤니티도 포함될 수 있다)이 그런 친구들이다.
미안하지만, 디스코urs가 모든 Gmail 주소를 마침표와 + 기호 이후의 문자를 무시하도록 처리하는 것이 좋은 일이 아닐까? 기술적으로 매우 복잡해 보이지 않는다. 아주 간단한 코드 몇 줄이면 된다. 가입 => @ 기호 뒤에 gmail.com을 감지 => @ 기호까지의 모든 마침표와 + 기호 이후의 문자를 제거하고 그 주소를 사용 => 이미 사용된 주소? => "이메일 주소가 이미 사용되었습니다"라는 오류 메시지를 반환.
끝. 아니면 내가 무언가를 놓치고 있는 건가?
스패머들이 디스코urs에서 이 방법이 작동한다는 것을 알게 되면, 그들은 이 기법을 이용해 디스코urs 포럼을 점점 더 많이 표적으로 삼을 것이다. 왜 그러지 않겠는가?
신규 사용자는 처음 X회까지는 모든 주제/게시글이 수동으로 승인되어야 한다고 설정했는데, 이 조치 덕분에 해당 문제가 거의 하룻밤 사이에 해결되었습니다. 일부 사용자는 나중에 게시글을 수정할 수 있다는 점을 알아냈고, 우리는 이를 신뢰 수준 0/1에 대해서도 조정했습니다.
이것이 특정 도메인 트릭과 직접적인 관련은 없지만, 실제 문제를 방해하는 효과가 있습니다. 즉, 동기가 있는 사용자가 여러분의 방어 조치를 우회하려는 시도입니다. Gmail "트릭"을 사용할 수 없다면 그들은 다른 트릭을 찾아낼 것입니다. 개인적으로는 신뢰 수준 1은 게시글을 작성할 수 있고, 신뢰 수준 1에는 5분간의 읽기 시간이 필요하다는 식의 방향으로 기울고 싶습니다.
음, 한번 살펴보자. 여기에서 어떤 문자들이 사용될 수 있을까?
일부 메일 서비스는 로컬 파트에 포함된 태그를 지원하여, 해당 주소가 로컬 파트의 접두어에 대한 별칭이 되도록 합니다. 예를 들어,
joeuser+tag@example.com주소는joeuser@example.com과 동일한 전달 주소를 나타냅니다. RFC 5233에서는 이 관례를 서브 어드레싱(sub-addressing)이라고 부르지만, 플러스 어드레싱, 태그드 어드레싱 또는 메일 확장이라고도 알려져 있습니다.이러한 형태의 주소는 기본 이름과 태그 사이에 다양한 구분자를 사용하여 여러 이메일 서비스에서 지원됩니다. 여기에는 Runbox(플러스), Gmail(플러스), Rackspace Email(플러스), Yahoo! Mail Plus(하이픈), Apple의 iCloud(플러스), Outlook(플러스), ProtonMail(플러스), FastMail(플러스 및 서브도메인 어드레싱), MMDF(등호), Qmail 및 Courier Mail Server(하이픈)가 포함됩니다. Postfix와 Exim은 합법적인 문자 집합에서 임의의 구분자를 구성할 수 있습니다.
즉, 우리는 플러스, 하이픈, 등호, 마침표, 파운드/해시 태그를 가지고 있습니다.
여기서 작동할 것이라고 제가 생각할 수 있는 유일한 방법은 이메일 주소에서 A-Z a-z 0-9를 제외한 모든 문자를 방지하기 위한 매우 엄격한 설정입니다.
이 설정은 일부 사용자의 가입을 막을 수 있지만, 만약 여러분이.. 음.. 엘리트 모사드 요원들의 표적이 되고 있다면, 이는 타당한 타협점이 될 수 있다고 생각합니다 
@eviltrout님은 어떻게 생각하시나요?
그건 너무 엄격할 수 있습니다. 여기서의 목적은 그러한 이메일 주소 변형의 중복 사용을 방지하는 것이지, 아예 금지하는 것이 아닙니다. 대신 각 계정에 실제 사용자 이메일 주소를 정리한 ‘정규화(canonical)’ 이메일 주소를 포함할 수 있습니다. 새로운 가입 시 이메일 주소의 정리된 버전을 이 값과 비교하면 됩니다. 다만 말처럼 쉽지만은 않을 것입니다.
네, 저는 여기서 Bart가 제안한 변경 사항을 선호합니다.
[ ] 이메일 주소의 내부 저장을 위해 정형화(canonical)된 형태 사용 (+ANYTHING 제거, 주석 제거 등.)
https://stackoverflow.com/a/19058600/17174
이를 참조하여 Ruby 구현을 빌려올 수 있지만, 매우 주의가 필요합니다 (예제 1은 보안 위험입니다: 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"
따라서 우리의 “정형화(canonicalize)” 로직은 다음과 같아야 한다고 제안합니다:
+ANYTHING 제거
소문자 변환 (이미 이를 강제하고 있음)
Gmail 또는 Googlemail이거나 사용자 정의 화이트리스트에 포함된 경우 점(.) 제거
주석 (...) 제거. 이는 또한 악용의 벡터가 될 수 있습니다.
주소를 유니코드 정규화합니다. 이는 기술적으로 허용됩니다: Email address - Wikipedia
그리고 . 제거를 위한 도메인 화이트리스트를 가진 숨겨진 사이트 설정을 추가합니다.
그럼에도 불구하고 이를 악용할 수 있는 방법은 많습니다. 누군가가 10,000개의 스팸 Gmail 주소 캐시를 가지고 있고, 어떤 종류의 봇으로 그것들을 모두 사용하여 가입할 수도 있습니다. 표적이 되고 있다면, 잠시 동안 모든 신규 가입을 승인하는 것이 나을 수 있으며, 플러그인에서 가입 시 reCAPTCHA를 원하는 희귀한 경우 중 하나일 수 있습니다.