@sam, 제 생각에는 CAPTCHA 사용자 생성 플러그인이 더 필요한 것 같습니다. "마침표와 더표를 금지하자"는 근본적인 문제를 해결하는 것이 아니라, 문제의 증상만을 다루는 것 같아서요.
역사적으로 보면, 시간이 지날수록 100% 인간 스팸으로 전환되는 추세입니다. 그들은 사용자 프로필을 작성하고 프로필 이미지를 업로드하는 등 모든 것을 수행합니다. 자동화 스팸(단, bamwar 제외)은 Discourse에서 큰 문제가 되지 않았습니다. 우리는 완전한 보어 JavaScript 애플리케이션이기 때문에 자동화하기가 매우 어렵기 때문입니다. @neounix 님의 대부분의 코멘트는 제가 이전에 언급한 범주에 해당합니다. 1999년 HTML 1.0 웹사이트와 비교할 때, 우리는 매우 복잡하기 때문에 스크립트로 자동화하는 것이 매우 어렵습니다. 우리가 고객과 메타에서 관찰한 바에 따르면, 난이도 기준을 그렇게 높이면 대부분의 문제가 사라집니다.
어쨌든 요약하자면, "이메일에서 특정 문자를 금지"하는 간단한 설정에 반대하는 것은 아닙니다. 하지만 제 생각에는 이 경우 CAPTCHA를 제외하고는 큰 도움이 되지 않을 것 같습니다. 둘 다 할 수도 있지요?
@neounix 전설입니다. 팁을 주셔서 감사합니다. 정말 큰 도움이 되었어요. 덕분에 스팸 처리 여정을 시작하게 되었습니다. Cloudflare를 일시적으로 “공격당함”(I’m under attack) 모드로 전환했는데(이렇게 하니까 가입이 멈췄어요 - 1~2분마다 새 계정을 만들고 있었거든요), Cloudflare 방화벽 로그를 확인해 그들이 사용하던 IP 주소를 몇 개 살펴봤더니 모든 방문자에게 챌린지를 보내거나 로그를 기록하고 있었습니다. 실제로 동일한 User-Agent를 사용하고 있었네요.
해당 User-Agent를 사용하는 사용자에게 챌린지를 보내는 방화벽 규칙을 추가하고 CF의 “공격당함” 모드를 비활성화했습니다. 이로 인해 무고한 사용자가 챌린지를 받는 경우는 많지 않았을 것으로 생각되며, 그들의 스팸 가입은 완전히 중단되었습니다.
그 후 Cloudflare의 AS 번호(ASN) 차단 기능을 발견했고, User-Agent 차단 로그를 참고하여 상당수의 스팸을 차단하기 위해 추가 방화벽 규칙을 설정했습니다. 우회 방법은 분명 있을 것이며, 여러분도 잘 알고 계실 겁니다. 하지만 그들에게는 추가적인 자원 비용과 노력이 필요해집니다.
@codinghorror 캡차가 도움이 될 것이라는 의견에 동의합니다. 스팸 방지 1차 목표로, 스팸머의 전반적인 자원 비용을 높이는 것이 좋다고 생각합니다.
캡차는 이에 기여할 수 있습니다. 캡차 해결 API(예: https://anti-captcha.com)를 사용하면 1,000회당 약 2달러(오차 범위 포함)의 비용이 듭니다. 또한 그들의 봇에 필요한 추가적인 복잡성도 요구됩니다.
참고: Anti-captcha에는 캡차를 자동으로 해결해 주는 브라우저 플러그인이 있습니다. 잘 작동하며, 재미있는 편의 기능이기도 합니다.
이메일 주소는 대량 계정 생성 시 보통 또 다른 자원 비용이 됩니다. 하지만 하나의 Gmail 주소로 사실상 무제한의 계정을 만들 수 있는 경우에는 해당되지 않습니다. Gmail 계정 1,000개를 만드는 비용은 꽤 크므로, 그들은 종종 덜 엄격한 다른 제공자나 캐치올(catchall) 도메인을 사용하게 됩니다. 그래도 여전히 자원이 소모되며, 스팸으로 식별하기가 더 쉽습니다.
정말 '많을수록 좋다’는 말인 것 같습니다. 단일 방어책만으로는 충분하지 않으며, 스팸머에게 필요한 자원과 노력을 일반적으로 늘리는 것 자체가 올바른 방향입니다. 가장 좋은 시나리오는 스팸머가 Discourse 포럼에 스팸을 보내는 것보다, 관리자가 이를 차단하고 유입된 것을 대량으로 삭제하는 것이 더 적은 노력을 요구하는 상황이 되는 것입니다.
@itsbhanusharma +를 함께 사용할 수 있는 점이 정말 좋습니다. 하지만 그래서 좋은 것을 가질 수 없는 거죠, 하하. 그래도 필요할 때 이를 차단하도록 활성화할 수 있는 옵션이 있으면 좋겠습니다.
점(.)과 더하기 기호(+)를 허용하지 않으면 일부 문제(최소한 일부 사용자에게)가 발생할 가능성이 높습니다. 원래 의도는 이메일의 "정형화(canonical)"된 버전(즉, “정리된” 버전)을 저장하고, Gmail의 특수한 규칙 덕분에 실제로는 동일한 이메일인 경우를 위해 같은 정형화된 버전으로 추가 사용자를 등록하는 것을 금지하는 것이었습니다.
샘(Sam)이 이렇게 말한 것이 바로 그 의미일 수 있습니다:
아마 @codinghorhor 님도 "허용하지 않는 것"이 아니라 그런 의미였을 것입니다.
하지만 동의하는 바입니다. 이는 Gmail에 대해서만 문제를 "해결"할 뿐입니다(예: 도메인의 “catch-all” 사용 같은 경우는 제외).
이메일에서 플러스 기호(+)는 모든 이메일 도메인에서 대략 동일하게 처리될 수 있다고 생각합니다. 큰 문제는 없을 것입니다.
sp.a.mmer.king@gmail.com, s.pa.mmerking@gmail.com 같은 이메일의 경우, Gmail에서는 동일한 이메일 주소로 처리됩니다. 하지만 다른 일부 제공자의 경우 그렇지 않을 수 있으며, 두 이메일은 각각 고유한 사용자로 간주될 수 있습니다.
–
장기적으로 좋은 구현 방식은 이메일 도메인 블랙리스트 기능과 유사한 형태가 될 것입니다.
중복 등록 트릭을 허용하지 않으려는 사용자 지정 도메인을 추가합니다. 그런 다음 두 유형의 중복 등록을 개별적으로 차단하도록 활성화/비활성화할 수 있도록 합니다. 즉, 플러스 기호(+) 트릭 이메일 중복을 금지하는 것과 마침표(.) 트릭 이메일 중복을 금지하는 것을 별도의 옵션으로 제공합니다.
등록된 이메일은 그대로 저장하되(사용자의 로그인 및 이메일 전송 주소 기준), 동일한 이메일로 판정되는 추가 등록은 차단합니다.
약간의 효과를 높일 수 있는 또 다른 방법은 여러 도메인을 하나의 사용자 지정 도메인 레코드에 넣어 동일한 도메인으로 취급하는 것입니다. 예를 들어 gmail.com과 googlemail.com처럼요. 이렇게 하면 누군가가 example@gmail.com과 example@googlemail.com을 사용하여 두 번 등록하는 것이 차단될 수 있습니다. 여러 상호 교환 가능한 도메인을 가진 다른 제공자들도 있으며, 저는 Sam에게 몇 가지 예를 보내 놓았습니다. 이 방법은 조금 더 많은 보호 기능을 제공할 수 있지만, 전반적으로 주요 악용 가능한 문제는 플러스 기호와 마침표 트릭을 이용한 등록입니다.
–
대안으로, 잠재적으로 더 단순한 구현 방식은 위와 유사하지만 각 사용자 지정 이메일 도메인당 두 가지 옵션을 제공하는 것입니다. 즉, 플러스 기호와/또는 마침표가 포함된 모든 등록을 차단하는 것입니다. 사용자가 해당 도메인을 사용하여 플러스 기호나 마침표를 포함한 이메일로 등록을 시도하면, 이메일에서 마침표와/또는 플러스 기호를 제거하고 다시 시도하도록 지시하는 오류 메시지를 표시합니다(자동으로 처리해 주는 것도 가능합니다). 완벽하지는 않지만, 여전히 매우 효과적일 것입니다.
가입 과정에서 마침표와 더하기 기호가 제거된 이메일을 요구해야 한다면, 클라이언트 측에서 동의(폼 유효성 검사와 유사하게)를 받아 이를 계정 이메일로 저장하는 것은 괜찮습니다.
이상적이거나 완벽하지는 않지만, 몇몇 사용자에게 불편을 주거나 전체 포럼에 스팸으로 인한 불편을 주는 것 중 선택해야 하는 경우, 더 간단한 방법이자 가치 있는 타협안이 될 수 있습니다.
주요 정규화된 이메일에 마침표가 포함된 Gmail 계정이 있습니다. 이들은 가입 시 마침표를 강제로 제거하는 조치에 가장 큰 영향을 받고 혼란을 겪을 사용자들입니다.
이것이 최선의 구현 방식이라고 생각하지도 않으며, 확실히 기본 옵션으로서 사용자 친화적이지도 않습니다.
네, 제가 말한 것은 이미 존재하는 이메일 도메인 블랙리스트와 유사한 옵션 메뉴를 만들어, 어떤 이메일 도메인이 적용 대상인지 입력하고, 이 스레드에서 논의되고 있는 이메일 주소의 고유성/정규화 판단에 사용해야 할/사용하지 말아야 할 매개변수를 설정하는 것입니다. 잠재적으로 gmail/googlemail과 같이 동일한 호스트로 간주되어야 하는 도메인도 지정할 수 있습니다.
gmail과 googlemail에 대해서는 의견이 일치하는 것 같습니다. 마침표와 + 기호에 대해서도 마찬가지입니다.
본질적으로, 첫 번째 가입은 허용하되, 동일한 이메일로 여러 계정을 만들 수 없도록 하는 것입니다. 또는 적어도 합리적인 범위 내에서 이를 최소화하는 것입니다.
john@googlemail.com이 먼저 가입 → 허용 john@gmail.com이 나중에 가입 → 거부
matthew+{randomstring}@gmail.com이 먼저 가입 → 허용 matthew@gmail.com이 나중에 가입 → 거부 matthew@googlemail.com이 나중에 가입 → 거부 m.att.he.w@gmail.com이 나중에 가입 → 거부 matthew+{randomstring}@gmail.com이 나중에 가입 → 거부 m.a.tt.ew+{randomstring}@googlemail.com이 나중에 가입 → 거부
googlemail과 gmail(그리고 여러 대체 도메인을 가진 다른 제공업체)의 문제는 마침표와 + 주소 문제보다는 훨씬 중요도가 낮습니다. 그런 경우를 처리할 수 있다면 좋겠지만요.
이것은 정말로 사용자에게 불친절한 변경 사항이며, 전혀 필요하지 않습니다. 이러한 기능이 처음부터 존재하는 이유는 이메일의 출처를 식별하기 위해서입니다. stephen+meta@gmail.com이라는 이메일 주소로 가입하면, 해당 주소로 발송된 모든 이메일에 라벨을 붙이는 규칙을 설정할 수 있습니다. meta가 해킹되어 해당 별칭으로 스팸이 들어오게 되면, 이제 어디에서 유출이 발생했는지 알 수 있습니다. 제가 이메일을 사용하는 방식을 훼손하는 것은 해결책이 아니며, 이메일 주소를 비교를 위해 정규화된(canonical) 버전으로 압축하는 것이 사용자에게 어떠한 불편함도 주지 않으면서 동일한 결과를 달성할 수 있습니다.
네, 그리고 그것은 정규화 주소(canonical address)라는 개념과 연결되어 있습니다. 이 기능이 원래 논의되었던 대로 진행되었다면, 도메인을 연관시키는 기능은 우리에게 정말로 유용할 것입니다. 모든 마침표와 더 기호의 조합 및 도메인 변형은 아무런 마찰 없이 해당 메일박스의 '유일한 진짜 이메일’과 비교될 것입니다.
사용자에게 불편함을 주지 않는 한, 이 기능이 기본적으로 활성화된 상태로 출시될 수 없는 이유는 없습니다.
동의합니다. 불완전한 해결책은 불완전합니다. 저는 이것이 구현하기 잠재적으로 더 간단한 대안이라는 의미로만 말씀드린 것입니다. 이것은 제 게시물의 마지막 부분으로, 이 스레드의 많은 논의와도 일치하며 +와 점을 허용하되 중복 계정은 허용하지 않는다는 제 주요 제안들과 동의하는 대안으로 제시한 것입니다.
그럼에도 불구하고, 제 경험상 비기술적인 포럼/사이트에서 이메일에 +를 사용하는 합법적인 사용자는 일반적으로 가장자리 사례(edge case)입니다.
정말 환상적으로 들립니다.
제 게시물의 주된 목적은 다른 이메일 도메인에 대해 정규화된 주소가 어떻게 계산되는지에 대한 것이었습니다. 따라서 Gmail/Googlemail 사용으로만 제한되지 않습니다. 본질적으로 도메인별로 정규화된 주소가 계산되는 방법에 대해 사용자 옵션을 가질 수 있는 것이 장기적인 구현으로 좋을 수 있다고 말하려 했던 것입니다.
다른 일부 제공업체는 +는 허용하지만 점(.)의 조합은 허용하지 않습니다. 즉, 점의 조합은 고유한 이메일을 의미합니다.
Gmail/Googlemail 전용 구현도 훌륭할 것이며, 기본적으로 켜져 출시될 수 없는 이유도 보이지 않습니다.
그런 예시를 하나 알려 주실 수 있나요? 대부분의 Gmail 사용자가 마침표 트릭(dot trick)에 대해 잘 모른다는 점이 궁금해서요. 마침표가 포함된 주소로 가입한 후, 그 버전의 이메일 주소를 모든 사람에게 공유하는 경우가 많습니다. 만약 "본인의 이메일"이 유효하지 않다고 알려주면 매우 혼란스러워할 것입니다.
마침표를 제거한 별칭으로도 여전히 메일을 받을 수 있다는 사실조차 인지하는 사람을 거의 만나지 못합니다.
이 보호 기능을 활성화하려면 사이트 설정인 enforce_canonical_emails(기본값: false)를 사용하세요.
활성화되면 googlemail.com과 gmail.com에서 . 해킹을 사용하는 사용자와 전역에서 + 해킹을 사용하는 사용자의 중복 가입이 차단됩니다.
이 수정은 매우 안전하며, 비활성화 상태에서는 기본 구성에 어떠한 영향도 미치지 않습니다.
구현 방식의 부수적 효과로, 설정을 활성화할 때 정규화된 이메일 주소를 사용자 이메일 테이블에 저장하지 않기 때문에 중복 계정이 1건 더 통과할 수 있습니다. 저희가 호스팅하는 여러 사이트에서 이 특정 악용 사례를 거의 찾아볼 수 없으므로, 저의 의견으로는 이는 완전히 허용 가능한 수준입니다.
늦게 답변드려 죄송합니다. 다른 작업으로 바빴습니다… 이제야 메타(Meta) 관련 내용들을 정리하고 있습니다:
스팸, 허위 등록, DDOS 공격, 침입 및 사이버 공간 상황 인식 전반과 기타 유사한 탐지 지향적이고 다중 센서 데이터 융합 사이버 보안 문제는 제가 가장 좋아하는 주제 중 하나입니다. 여러분도 잘 알고 계실 것입니다
최전선에서 실시간으로 수많은 ‘현장’ 사이버 전투를 치러온 경험으로, 이런 공격을 받을 때 두 가지 힌트를 더 드리고 싶습니다:
(1) 탐지는 순수한 과학이라기보다는 종종 예술에 가깝습니다. 그 이유는 공격자가 여러분의 탐지 및 완화 알고리즘과 기법에 대해 càng 많이 알수록, 여러분의 방어에 맞춰 변형하고 적응하기 때문입니다.
(2) 또한 "OODA 루프"를 절대 잊지 마세요. 관찰-정렬-결정-행동(Observe-Orient-Decide-Act) 사이버 전투에서 상대방의 OODA 루프 안으로 들어갈 수 있는 쪽이 일반적으로 승리합니다.
사이버 방어를 즐기고 더 큰 그림을 보고 계신다는 글을 읽게 되어 기쁩니다. (이 토론에서 빠르게 요약해서 읽은 바로는) 모든 상황을 통제하고 계시는 것 같고, 훌륭한 메타 팀도 여러분을 위해 도움이 되는 변경 사항을 적용한 것으로 보입니다.
공격을 받아 도움이 필요하시면 주저하지 말고 저에게 연락해 주세요. 저는 이윤 추구와 금고 채우기의 세계에서 은퇴한 지 오래되었습니다(감사하게도!), 따라서 저에게 자문을 구할 때 수수료는 절대 없습니다. 흥미로운 기술 문제를 가진 다른 사람들을 돕는 것, 특히 사이버 보안과 사이버전 분야에서의 도움은 더 많은 부를 축적하는 것보다 저에게 더 높은 우선순위입니다.
아이디어를 나누고 싶은 사람이 필요하시다면 저는 항상 여기 있습니다. 최근 여러분의 답변을 읽은 바로는, 상황이 통제되고 있는 것 같습니다.
