Suggestion: Wildcard Block Email Address

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개의 좋아요

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개의 좋아요

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): Redirecting...

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개의 좋아요

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

2개의 좋아요

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개의 좋아요

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개의 좋아요

@pfaffman - I was just going off the figures given from Redirecting... 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개의 좋아요

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개의 좋아요

참고 … sam.sam@gmail.com을(를) 차단하면 이제 sam.sam+1@gmail.com 등이 자동으로 차단됩니다…

10개의 좋아요

이 기능이 아주 잘 작동하고 있습니다 @sam :slight_smile:

생성하신 이전 구현 방식은 여전히 추가적인 스팸 방지 기능으로 꽤 유용할 수 있다고 생각합니다. 해당 기능이 사용 가능하고 활성화되어 있던 짧은 기간 동안(default off) incredibly well 작동했기 때문입니다.

그렇지 않으면, 관리자나 아민이 이를 인지하기 전에 스팸머들이 하나의 Gmail 주소로 대량 계정을 생성할 수 있습니다. 예를 들어, 계정을 생성하지만 즉시 아무것도 게시하지 않는 경우입니다.

관리자/모드는 각 개별 계정을 수동으로 찾아서 열어야 하며, 이를 금지하거나 삭제해야 합니다. 이는 매우 번거로운 작업일 수 있으며, 특히 스팸머 한 명이 금지당하기 전에 하나의 Gmail 주소로 수백 개 또는 수천 개의 계정을 생성할 수 있는 경우 더욱 그렇습니다. 또한 이메일 검색이 어려운 경우도 있습니다. 예: j.ohan.2.1@gmail 과 jo.ha.n21@gmail.

수동으로 찾아내지 않으면, 스팸머들은 한 개의 Gmail 주소만 소모하면 되는 상태에서 큰 규모의 계정 풀을 유지하며 ‘방패 치기(whack-a-mole)’ 게임을 계속할 수 있게 됩니다.

@sam 추가 현장 테스트를 거친 후 후속으로 말씀드리자면, 되돌려진 이전 구현 방식이 의도가 있는 스팸에 훨씬 더 효과적이라고 확신합니다. 여전히 이러한 변형된 Gmail 트릭을 이용해 상당한 수의 가입이 발생하고 있습니다.

현재 적용된 보호 방식이 매우 효과적이어서 도입해 주셔서 매우 감사드립니다. 하지만, 특정 계정들이 구체적으로 발견되고 수동으로 금지되기까지 동일한 이메일로 무제한으로 계정을 생성할 수 있는 것은 다소 큰 구멍이라고 생각합니다. 이는 특히 대량 계정 삭제 도구(예: 계정/검색 목록에서 체크박스를 이용해 여러 계정을 선택하여 일괄 금지/삭제하는 기능)가 없는 상황에서 관리자(기본적으로 계정 이메일을 볼 수 없으며, 활성화해야만 볼 수 있다고 생각합니다)에게 더 큰 부담으로 작용합니다. 즉, 관리자가 각 개별 계정으로 수동으로 이동하여 금지/삭제해야 합니다. 이는 변형된 이메일을 가진 계정을 검색할 때 특히 어렵습니다.

이전 구현 방식은 선택 사항(기본적으로 비활성화)이었으며, 이미 개발되어 의도대로 작동하다가 제거되었습니다. 의도가 있는 스팸에 대한 추가적인 반스팸 보호를 위해 이를 활용하기를 원하는 커뮤니티에서 더 이상 사용할 수 없다는 점은 안타까운 일로 보입니다.

이것이 제가 특정 문자는 이메일에서 완전히 금지해야 한다고(선택적으로) 말씀드린 이유입니다. 구체적으로는 서브어드레싱을 허용하는 문자, 예를 들어 플러스, 마침표, 하이픈 등이 해당됩니다. 정규식(regex)을 사용하면 서비스별로 이를 차단할 수도 있습니다. 예를 들어 "@gmail.com으로 끝나는 이메일 중 플러스 기호가 포함된 이메일은 허용되지 않는다"는 식으로 설정할 수 있죠. @sam 에게 참조합니다.

1개의 좋아요

이전 구현에서는 +addressing을 허용하면서도 계정당 1개의 정규화된 주소만 유지하도록 했습니다(이 방식이 더 안전하다고 생각합니다).

즉, 내부 Gmail 규칙에 유용하게 사용할 수 있도록 sam+discourse-meta@gmail.com으로 등록할 수 있습니다. 하지만 이 경우 sam@gmail.com이나 sam+1@gmail.com으로의 신규 계정 생성은 차단됩니다.

허용 목록(allowlist) 추가에 반대하는 것은 아니지만, Gmail의 경우를 고려할 때 정규화된 주소를 강제하는 것이 꽤 유용하며 나쁜 기본값은 아니라고 생각합니다.

1개의 좋아요

여기서 안전이 진짜 목표는 아닙니다. 해당 사이트는 직면한 문제의 규모 때문에 더 극단적인 해결책이 필요합니다. 선택 사항(사용자가 직접 "이메일 보호 정규식"을 추가)인 한, 제 생각에는 완전히 안전해 보입니다. 필요한 사이트는 '풀 락다운 모드’를 선택적으로 활성화할 수 있으니까요.

1개의 좋아요

현재 우리는

차단된 이메일 도메인

기능을 가지고 있습니다.

차단된 이메일 패턴

을 추가할 수 있을 것 같습니다.

하지만 정규식을 올바르게 작성하는 것은 필요한 이스케이프 처리가 많아 다소 번거롭습니다. 이러한 옵션을 제공하면 사용자가 정규식을 의도대로 올바르게 작성할 가능성이 매우 낮다고 우려됩니다. 마침표와 더하기 기호를 이스케이프 처리해야 한다는 점을 기억해야 하니까요.

.*\+.*@gmail\.com

대신 정규식 기반이 아닌 단순화된 패턴을 구현하여 *와 ?만 확장하는 방식을 사용할 수 있을 것 같습니다.

*+*@gmail.com

5개의 좋아요

:wave: 늦은 답변 죄송합니다!

이전 구현 방식이 옵션으로 다시 추가된다면, Gmail 관련 문제를 완전히 해결할 수 있을 것이라고 생각합니다. 적어도 제 경우에는 그렇습니다. 제 의견으로는 매우 완벽하며, 스팸 공격자에게 충분한 자원 비용을 부과하여 대응을 관리 가능하게 만들어 줍니다. 이는 24시간 전일제 고강도 모니터링이 필요한지 아닌지를 가르는 결정적인 차이가 될 것입니다.

저는 유사한 기능을 허용하는 여러 도메인을 차단하고 허용된 이메일 도메인 목록을 활용하고 있습니다. 문제는 사용자가 자신의 계정 중 하나가 차단/차단되기 전에 여러 계정을 생성할 수 있다는 점입니다(이 경우 해당 Gmail 주소의 변형으로의 신규 계정 생성은 차단되지만, 기존 계정은 그대로 방치됩니다). 이는 모니터링에 상당한 부담을 주며, 이후 각 개별 계정을 정리하는 것이 번거롭습니다.

예를 들어, 동일한 Gmail 주소를 사용하여 1개 계정당 1개의 게시글을 작성한 약 200개 정도의 답글이 있는 스레드가 있었습니다. 유사한 사례가 많습니다. 이는 원본 Gmail의 변형을 통해 검색하는 것이 매우 어렵기 때문에 계정을 찾기 쉬운 경우의 예입니다. 일부 스팸 공격자는 소수의 Gmail 계정을 사용하여 대량의 계정을 만들어 두고, 수개월 후에야 게시글을 올립니다.

정규식(regex) 차단을 해결책으로 고려할 때, + 기호를 차단하는 것은 비교적 무해할 것입니다. 반면 마침표(.)를 차단하면 john.smith@gmail.com과 같은 상당수의 합법적인 이메일이 차단될 가능성이 높습니다. 마침표가 두 개 이상인 주소를 차단하면 부수적인 피해는 적을 것 같지만, Gmail 주소의 여러 변형은 여전히 허용될 것이며, 마침표가 두 개 이상인 경우보다는 훨씬 적지만 여전히 허용됩니다.

개인적으로 이전 구현 방식이 이상적이며, 선택적 보호 기능으로 구현하는 것은 합리적이라고 생각합니다. 가장 인기 있는 소셜 사이트들은 스팸 공격자에게 악용되는 경우가 많기 때문에 여러 Gmail 변형으로 가입을 허용하지 않습니다.

감사합니다 :slight_smile:

1개의 좋아요

@sam 사이트가 필요할 경우 이 선택적 이메일 정규식 잠금 수준을 구현할 수 있도록 허용해야 한다는 데 강한 확신을 가지고 있습니다. 그렇지 않으면 Discourse의 핵심 원칙 중 하나인 "기본적으로 안전해야 한다"는 원칙에 어긋나게 됩니다.

1개의 좋아요

다음 릴리스까지 이 작업을 완료할 수 있습니다. 다만, 여전히 제 원래 구현 방식에 동의합니다. 정규화(canonicalization)가 사이트 운영자에게 가장 친절한 해결책이기 때문입니다. 체크박스를 클릭하면 바로 문제가 해결되니까요. 반면 정규 표현식(regex)을 사용하려면 정규 표현식을 배워야 하고(그렇게 되면 5시간이 날아갑니다), 결국 스팸 계정을 놓치거나 사용자에 불친절하게(점(.)이나 플러스(+) 사용 불가) 되거나, 타협적인 결과로 끝날 수 있습니다.

그럼에도 불구하고, 다음 릴리스에 정규 표현식 지원 기능을 추가하는 것은 가능합니다.

1개의 좋아요

아니, 사실 엄청 간단해요. 그냥 '플러스 기호나 마침표가 포함된 이메일은 허용하지 않는다’는 규칙이거든요. 솔직히 꽤 제한적인 조건이고, 기본적으로 활성화해 두는 건 원치 않을 거예요. 하지만 마치 바워(BAMWAR) 사례처럼, 악의적인 사용자가 항상 존재하기 때문에 원치 않더라도 '핵 발사 버튼’을 만들어 두는 수밖에 없어요.

핵전쟁과도 비슷한 거예요. 핵무기가 테이블 위에 올라가면 더 이상 ‘사용자 친화적인’ 선택지는 불가능해지고, 대부분의 경우 그 단계까지 가지 않기를 바라는 수밖에 없거든요.