사실 정규화된 이메일을 강제하는 것은 효과적으로 동일한 결과를 가져오지만, 사용자 입장에서 훨씬 덜 불편합니다.
Sam.sam@gmail.com은 허용되지 않지만, Sa.msam+123@gmail.com은 이미 등록되어 있습니다.
어쨌든 다음 릴리스에서 정규식(regex)을 적용할 수 있습니다.
2개의 좋아요
그래도 실제 현장에서는 쓸모가 없어서 이 논쟁이 벌어지는 거야. 상대가 핵무기를 가진 순간, 우리도 핵무기가 필요해.
상대가 핵무기를 가지고 그것을 사용하려는 의지가 있다면, '사용자에게 적대적’이라는 개념은 아무런 의미가 없어.
저는 이 의견에 동의하지 않습니다. 이 솔루션은 @markersocial에게 완벽하게 작동했고, 이후 제 의지와 무관하게 변경 사항을 되돌려야 했을 뿐입니다.
제가 구현했다가 되돌린 정규화(canonicalization) 방식에는 알려진 결함이 없으며, 위의 Gmail 문제를 100% 해결합니다.
3개의 좋아요
글쎄, 나는 동의하지 않습니다. 왜냐하면 그것은 코드 작성과 노력이라는 부담을 상대방이 아닌 우리 쪽에 지우게 하기 때문입니다. 이메일을 "정상화"하는 작업은 꽤 복잡하고, 이메일 제공업체마다 다르며, 저는 그쪽 일을 하고 싶지 않습니다.
즉, 핵무기는 그들 스스로 만들어서 관리하게 두는 것이죠. 우리는 모든 국가에 원자폭탄 전단계 물질을 보내거나, 모든 Discourse 설치 환경에 "혹시 모르니"라고 해서 그것을 포함시킬 필요가 없습니다.
(게다가 정규식(Regex)을 통해 이메일을 차단 목록에 추가할 수 있는 기능은 매우 강력합니다. 특히 Discourse에서는 이메일이 곧 신원을 나타내므로 더욱 그렇습니다.)
1개의 좋아요
중간책면으로, 정규식 규칙을 사용해 정규화하도록 허용할 수 있습니다. 그러면 우리는 정규화 업무에 개입하지 않아도 됩니다.
다만, 다음 릴리스에서는 정규식 차단 또는 최소한 와일드카드 차단은 시행될 것입니다.
6개의 좋아요
이전 구현이 완벽하게 작동했으며 Gmail 문제를 완전히 해결했음을 확인합니다. 이메일 도메인 허용 목록과 차단 목록은 모두 매우 강력한 수단입니다. 하지만 Gmail을 차단하는 것은 현실적으로 불가능합니다.
@codinghorhor 다른 이메일 제공업체에 대한 정규화를 반대하는 관점은 이해할 수 있습니다. 하지만 적어도 Gmail(2020년 기준 전체 이메일 주소의 약 43%, 미국의 경우 53%로 알려짐)에 대해서는 파괴적이지 않은 방식으로 대응할 수 있도록 하는 것이 합리적이라고 생각합니다. 이는 대형 제공업체에 대한 OAuth를 기본으로 지원하는 것과 유사할 수 있습니다.
@sam ^ 이 대안 아이디어가 좋습니다. 
Gmail/googlemail 매칭에 대한 예시를 포함하면 사용자 친화적이고 강력할 수 있을 것 같습니다.
2개의 좋아요
현재 하나의 Gmail 주소(점 기호를 활용하여)로 수천 개의 계정을 생성하고, 경쟁 사이트를 홍보하며 사용자를 유인하는 스팸을 보내는 사용자가 있습니다. 2.8 버전으로 업그레이드할 예정이며, 해당 버전이 출시되는 대로 점(.)이나 플러스(+) 기호가 포함된 모든 이메일을 차단할 것입니다. 이전 구현 방식이 사용 가능했으면 좋았을 텐데, 이 문제가 해결되고 해결책이 제공될 예정이라는 점은 감사하게 생각합니다. 이번 조치는 큰 차이를 만들어 줄 것입니다. 감사합니다
1개의 좋아요
이 문제에 대해 조금 더 생각해보고, 합리적인 해결책이 될 수 있는 아이디어를 떠올렸습니다.
관리자가 이메일의 정규화된 버전을 처리하고 저장할 수 있는 관리 옵션을 추가할 수 있습니다(사용자 이름 부분만 처리, 예: username@..).
다만, 이 처리는 관리자가 지정한 도메인에 대해서만 적용되어야 합니다.
즉, 이메일 도메인 허용/차단 목록과 유사한 목록을 만들고, 각 도메인당 두 개의 체크박스를 설정하는 방식입니다:
-
- 문자열 제거
- 마침표 제거
그리고 이 기록들을 참조하여 해당 이메일의 대안 버전(예: + 문자열이나 마침표가 포함된 버전)을 사용한 추가 가입을 차단하는 데 사용할 수 있습니다(원본 이메일 기록에는 영향을 주지 않으며, 원본 기록에는 여전히 + 문자열과 마침표가 포함될 수 있습니다).
이 방식을 통해 어떤 도메인에 대해 정규화 기록을 저장할지, 그리고 어떻게 정규화할지를 선택하는 부담은 관리자만 지게 되므로, 문제가 되는 이메일 도메인이 발견될 때마다 그에 대응할 수 있습니다.
어쨌든, 이 아이디어를 여기에 남겨두어 나중에 고려해볼 수 있기를 바랍니다.
감사합니다.
PR을 병합했습니다:
이 PR은 이메일의 마침표와 +… 부분을 제거한 후 고유성을 검사하는 새로운 사이트 설정 normalize emails를 추가합니다. 예를 들어, test+1@gmail.com 사용자가 이미 존재하는 상태에서 test+2@gmail.com으로 가입을 시도하면, 해당 사이트 설정이 활성화되어 있으면 가입이 허용되지 않습니다.
7개의 좋아요
훌륭합니다. @markersocial의 문제를 100% 해결할 것 같고, 특정 공격의 대상이 될 경우 활성화하기에 아주 좋은 설정입니다.
@markersocial, 진행 상황 알려주세요.
4개의 좋아요
이 기능을 구현해 주셔서 정말 감사합니다. 이는 큰 성과이며, 추가된 것을 매우 기쁘게 생각합니다. 어제 라이브로 설정하고 모니터링 중입니다.
현재까지 의도대로 100% 잘 작동하며 이 문제를 완전히 해결하고 있습니다. 이메일에 마침표가 포함된 사용자는 여전히 등록할 수 있습니다(최근 + 기호를 사용한 등록은 확인되지 않았지만, 아마도 가능할 것입니다). 하지만 같은 Gmail의 변형으로 계정을 계속 만들 수는 없습니다. GitHub에서의 토론을 읽어본 결과, 원래 이메일을 그대로 유지하는 것이 최선의 선택이었다고 확신합니다.
그렇다고 해서, 이 기능을 과도하게 복잡하게 만들지 않으면서 개선할 수 있을 것 같은 제안을 여기에 남깁니다:
이메일 정규화를 활성화/비활성화하는 체크박스 대신, 이메일 도메인 차단 목록과 유사한 두 개의 목록을 사용하시오.
- 마침표 정규화를 적용할 도메인 목록
-
- 정규화를 적용할 도메인 목록
예를 들어:
관리자가 gmail.com을 두 도메인 정규화 목록 모두에 추가합니다.
e.mai.l+123@gmail → email@gmail.com
사용자가 outlook.com을 + 정규화 목록에만 추가합니다:
us.er+123@outlook.com → us.er@outlook.com
us.er@email.com과 user@email.com이 동일한 주소/계정인 경우는 몇몇 제공업체에만 해당되며 표준이 아닙니다. 반면 + 기호는 허용하는 모든 제공업체에서 표준으로 사용됩니다.
이렇게 하면 관리자가 정규화(두 유형 모두)를 모든 이메일 도메인에 적용하는 대신, 문제가 되는 이메일 도메인이 나타날 때마다 선택적으로 이러한 규칙을 개별적으로 적용할 수 있습니다.
위 제안에 대해 기대하지 않습니다. 유용할 경우를 대비해 제안만 남깁니다.
어쨌든, 다시 한번 감사합니다. 이 기능이 구현된 것을 정말로 감사하게 생각합니다. 이는 게임 체인저입니다.
2개의 좋아요
하지만 이것이 이론적인 문제인지, 실제 현실에서의 문제인지 의문이 듭니다. 정확성을 추구하는 마음은 이해하지만, 이것이 실제로 문제를 일으키는 몇 가지 구체적인 사례에 대해 듣고 싶습니다.
이러한 설정을 도입하는 어려움은 사이트 허용 목록을 조정할 때마다 정규화 규칙을 다시 적용해야 한다는 점이며, 이는 매우 복잡한 변경 사항이 될 것입니다.
현재 우리는 (사이트 설정과 무관하게) 무조건적으로 정규화를 수행하고 있으므로, 이를 켜는 즉시 모든 과거 데이터에 적용됩니다.
멋지네요 
@nbianca 님 덕분에 가능합니다.
4개의 좋아요
훌륭네요! 소급 적용된다는 사실을 몰랐어요. 정규화된 주소는 새로운 가입 시에만 저장되는 줄 알았거든요.
문제가 발생할 가능성이 가장 큰 경우는 + 별칭은 허용하지만, 마침표의 위치를 다르게 두는 경우를 동일한 주소로 취급하지 않는 이메일 주소일 거예요.
- 기호는 제가 아는 한 이를 허용하는 모든 제공자에서 동일하게 처리되므로, 모든 이메일에서 + 기호를 동일하게 처리해도 아무 문제가 없어요. 제공자 간에 차이가 있는 경우는 마침표뿐이에요.
기억이 정확하지는 않지만, 구글 워크스페이스 이메일(커스텀 도메인 사용), Yandex, Outlook은 마침표의 위치가 다른 경우를 서로 다른 주소로 취급하지만, + 별칭은 여전히 사용할 수 있다고 생각해요.
따라서 실제로 문제가 되는 경우는 theirs@email.com이 이미 존재할 때 the.irs@email.com의 가입이 차단되는 경우(해당 이메일 도메인/제공자에 따르면 실제로는 두 개의 고유한 계정/주소인 경우)뿐일 거예요. 현실에서 이런 일이 발생하는 경우는 아마 매우 드물겠죠. 
2개의 좋아요
이 주제는 16시간 후 자동으로 닫혔습니다. 더 이상 새 답글을 작성할 수 없습니다.