왜 여기에서 복잡한 의존성을 가져오는 것이죠? 단순한 이메일 주소 잠금 모드가 구현하고 이해하기 훨씬 간단하기 때문입니다. 게다가 이렇게 하면 새로운 공격 벡터가 열리게 되나요? 사양합니다!
이러한 불만이 드물고 그 상황도 예외적인 점을 고려할 때, 좀 더 엄격한 단순한 접근 방식을 선호합니다.
/a-zA-Z0-9/가 아닌 모든 것을 금지하는 이 간단한 방식은 작동은 하지만, 상당한 사용성 문제를 가지고 있습니다. 많은 사용자가 가입 방법을 알지 못할 것이며, 새로운 오류 메시지가 필요합니다. Gmail을 사용하는 많은 사용자는 jane.doe@gmail.com이 자신의 이메일이라고 생각했지만, 실제로는 janedoe@gmail.com이 이메일로 기능한다는 사실을 모릅니다. 이 금지 조치는 OAuth에 영향을 미쳐 Gmail 로그인에 실패하게 만들 수 있습니다.
이메일 주소:
sam.s@gmail.com
오류: 이메일 주소에.은 허용되지 않습니다 (새 메시지)
규격화(Normalizing)는 사용자에게 덜 적대적이며 새로운 UX가 필요하지 않습니다.
더 단순한 선택적 규격화 도구(태그 제거, Gmail용 마침표 제거)로 시작할 수 있습니다.
그러나 명확히 하자면, 저는 여기서 의존성(dependency)을 제안하는 것이 아닙니다. email_address는 깨져 있고 우리가 원하는 용도에 적합하지 않습니다.
여기서 서두른 halfway 조치(반쪽짜리 조치)는 단순히 “내 사이트에서 이메일을 깨뜨리는” 사이트 설정을 만들게 될 것이며, 저는 이를 추가하는 것을 별로 좋아하지 않습니다.
1개의 좋아요
맞아요, 하지만 그의 사이트는 포위 상태에 있습니다. 매일 수천 개의 중복된 계정이 가입하고 있으니, 이메일 주소에 대한 단순한 잠금 모드가 있어야 한다는 건 당연합니다. 모사드와 전쟁을 벌이고 있고 크게 지고 있는 사이트들에게 말입니다.
전쟁에는 희생을 감수해야 합니다. 민간인 피해도 발생할 것입니다. 그의 사이트는 이미 엉망진창으로 깨져 있습니다.
1개의 좋아요
이상적으로는 각 이메일 제공업체별로 주소를 어떻게 '정리’해야 하는지를 보여주는 표가 필요합니다(실제로 인용하신 내용 그대로 말이죠). Bart가 잘 설명했듯이, 특정 문자 때문에 어떤 이메일 주소를 사용해서는 안 된다는 문제가 아니라, 실제로 동일한 주소인지를 식별할 수 있어야 한다는 것입니다.
네, 정말 원한다면 스팸 발송자는 항상 그럴 수 있습니다. 이는 경보/잠금장치와 도둑의 관계와 비슷합니다. 그 아이디어는 그런 행위를 더 어렵게 만드는 것입니다.
Gmail 주소를 여러 개 만드는 것은 Gmail에 대한 스팸이며, 이는 그들이 해결해야 할 문제입니다(그것이 나중에 당신에게 스팸을 보내는 데 사용될 수 있더라도).
1개의 좋아요
잘 이해가 되지 않습니다.
스위치가 켜져 있을 때 내부적으로 bob.test+100@gmail.com을 bobtest@gmail.com으로 취급하고 그렇게 저장한다면, 여기서 정확히 어떤 희생을 말하는 건가요?
이 버그는 구체적으로 gmail과 관련되어 있으므로, 구글이 스펙을 발명하고 정규화를 결정했다는 이유로 모든 곳에서 마침표를 금지하는 것은 과잉 반응으로 보입니다. 정리 로직은 실제로 매우 직관적이고, 이는 기본적으로 꺼져 있는 옵션일 것입니다.
@Mevo 여기서 100% 명확히 하고 싶은 것은, 제프의 제안이 '재난 모드’를 추가하자는 것이며, 이 재난 모드에서는 bob.test@gmail.com이 사용 불가능한 유효하지 않은 이메일이 된다는 것입니다.
3개의 좋아요
단순화된 형태와 비교하는 것을 제안하지만, 여전히 원래 지정된 주소로 이메일을 저장하고 전달하는 데 주의해야 합니다.
사용자가 다른 변형 주소로 메시지를 보내는 데 동의한 것이 아니며, 사용자가 지정하지 않은 주소를 사용하면 메시지를 받지 못할 수 있습니다.
예를 들어, 저는 Gmail 서비스 초기에 생성한 Gmail 주소를 하나 가지고 있습니다. 기본 별칭으로 보내는 이메일은 사실상 폐기됩니다. 특정 플러스 주소로만 전송된 이메일만 수신됩니다.
가정에도 주의해야 합니다. 많은 Gmail 사용자가 마침표가 선택 사항인 줄 모르고 있으며, 플러스 어드레싱에 대해 들어본 적 없는 사용자가 대다수입니다. 후자(플러스 어드레싱)의 남용을 방지하기 위한 분류 작업은 전자(마침표)로 인해 피해를 입는 사용자를 발생시킬 위험이 있습니다.
4개의 좋아요
@sam 제프가 무슨 말을 하려는지는 잘 이해했고, 당신과 마찬가지로 그가 제안하는 내용에 반대합니다(그에게 의도가 있는 것은 아니며, 의견 충돌은 흔히 일어나는 일입니다).
아마도 지나치게 꼼꼼하게 따지는 것일 수 있지만, 단순히 “정리된” 이메일 주소만 저장하면 일부 합법적인 사용자가 의도적으로 하던 일이 사라지게 됩니다. 예를 들어, 사용자가 bob+meta@example.com 또는 bob+forums@example.com으로(완전히 합법적이고 단 한 번만) 가입한다고 가정해 보겠습니다. 이 경우 사용자가 시도했던 목적이 무의미해집니다. 문제는 bob@example.com으로만 이메일을 수신하게 되며, 이는 사용자가 원했던 것이 아니라는 점입니다(예를 들어, "태그"를 사용하여 수신된 이메일을 특정 폴더로 분류할 수 있었을 텐데 말이죠).
이 점을 고려하면 시스템이 다소 복잡해질 수 있다는 점은 충분히 이해합니다. 사용자가 입력한 버전(이메일 전송용)과 정리된 버전 모두를 저장해야 합니다. 정리된 버전은 현재 이메일 주소를 사용하는 방식과 동일하게(사용자와 관련된 모든 내부 작업 및 해당 사용자가 이미 가입되어 있는지 확인하는 용도) 사용할 수 있습니다. 또한, 그 작은 문제를 피하기 위해, 이메일 전송을 위해 사용자의 입력 내용을 추가로 저장해야 합니다. 이는 이메일의 "답장 주소"와 동일한 개념입니다.
이해가 되길 바랍니다.
수정: @Stephen과 동시에 작성함(전체적으로 동일한 아이디어)
2개의 좋아요
매우 좋은 지적입니다. 이로 인해 구현이 다소 복잡해집니다.
아마도 “새 계정 생성” 시에만 확인을 수행할 것 같습니다:
이 정규화된(canonical) 형태로 이미 시스템에 이메일 주소가 존재합니까? 있다면, 죄송하지만 새 계정을 만들 수 없습니다.
구글 OAuth(이것도 정규화된 이메일을 확인하는가)와 비정규화에서 정규화로의 전환이라는 부수적인 문제가 있습니다.
제가 아는 바로는 OAuth는 플러스 어드레싱(plus addressing)과 함께 작동하지 않습니다. 그렇다면 이 문제는 범위 밖이 아닌가요?
즉, Google 계정으로 새 계정을 만들고, 다른 별칭을 지정하고, 이 과정을 반복할 수 없다는 뜻입니다.
같은 문제 영역입니다.
sam+hi@gmail.com으로 가입한 후 구글 로그인 버튼을 클릭하면 어떻게 될까요?
-
현재: 새 계정이 생성됩니다
-
제안:
-
옵션 A: 에러 화면이 표시되며 이 계정을 생성할 수 없습니다
-
옵션 B: 사용자가
sam+hi@gmail.com으로 로그인합니다
-
원래 제안된 잠금 모드에서는 sam.test@gmail.com으로 구글 로그인 버튼을 통해 로그인할 수 없습니다.
플러스 주소와 불필요한 점을 제거할 수 있는 견고한 번역(정규화) 방법을 고안할 수 있다면, 중복 제거된 이메일의 해시를 저장해 두었다가 계정 생성 시 이를 비교하는 방식으로 처리할 수 있습니다.
그게 바로 옵션 B입니다. 그래서 Google OAuth의 부수적인 문제가 있습니다라고 한 거죠 
또한 마이그레이션 문제도 까다롭지만, 아마 건너뛸 수도 있을 겁니다.
그러나 이 문제가 실제로 얼마나 광범위하게 퍼져 있는지 고려해 보면, 앞으로 몇 달 동안 여기에 대한 변경 작업을 진행할 것으로 기대하지는 않습니다.
위에서 언급했듯이, 내부적으로 '정규화’된 버전만 사용하고 사용자가 입력한 내용을 추가로 저장하여(이메일 전송을 위해) 사용하는 것이 해결책이 되지 않을까요?
이 문제는 충분히 해결할 수 있으며, 이러한 새로운 전환 기능을 테스트하고 디버깅하는 데 2~6일 정도가 소요될 것으로 추정됩니다. 주의해야 할 사소한 부분들이 많기 때문입니다.
여기서 문제는 @codinghorhor가 이 기능에 대해 해당 시간만큼의 예산을 정당화할 수 없다는 점입니다.
break a big pile of email logins는 1일 만에 구현할 수 있지만, 저는 Discourse에 그런 설정을 두고 싶지 않습니다.
따라서 @Mevo님, 상황이 다소 난감합니다. 이 문제를 경험하고 보고하는 사람이 더 많아져야 이 작업에 시간을 투입할 수 있는 근거를 마련할 수 있습니다.
3개의 좋아요
@sam 잘 이해하고 있어요.
(참고로, 이건 처음 보는 거예요. 게시물이 자동으로 수정되었더라고요: " [system] — 이전 게시물의 인용이 자동으로 제거되었습니다". 와! 정말 멋진 기능이에요!)
정규화된(canonical) 버전을 저장하지 않도록 매우 주의해야 합니다. 사용자가 이를 제공하기로 동의하지 않았으며, 사용자 테이블이 유출되더라도 어떤 서비스에서 그들의 데이터가 유출되었는지 쉽게 파악할 수 없도록 해야 합니다.
페이스북은 사용자가 제공하지 않았거나 계정과 연관되도록 동의하지 않은 개인정보(PII)를 저장한 문제로 여러 차례 큰 논란에 휩싸인 바 있습니다.
4개의 좋아요
개인적으로 이 설정에 아무런 문제가 없다고 봅니다. 저는 그저 '그 한 사람이 한 번 문제를 겪었다’는 이유로 이 기능을 구현하는 것을 극도로 꺼릴 뿐입니다.
음, Discourse에 추가하라고 제안하는 것은 _최악_입니다. 이 기능을 추가하는 것에 강력히 반대할 것입니다. 게다가 주소 지정(addressing)은 원래부터 있던 기능이며, 사용자 친화적입니다.
만약 모사드(Mossad)의 공격을 받고 있다면 .. 모사드 공격 모드를 활성화하세요. 그냥 모사드가 더 많은 사람들을 공격하게 하면 되는 것 같습니다? 
저는 이 설정을 Discourse에 추가하는 것에 대해 극구 반대합니다. 플러그인으로 만들어주는 것은 전혀 문제없습니다. 플러그인 몇 줄의 코드면 충분하니까요. 정말로 이 기능이 꼭 필요하시다면, 오늘은 잠시 쉬는 시간을 갖고 플러그인을 만들어 드리겠습니다. 알려주시면 됩니다.
문제가 있는 그 한 사람이 이미 이 기능을 사용하지 않겠다고 말하고 있으니, 굳이 만들어 봐야 무의미할 것 같습니다.
"내 Discourse를 망쳐라"라는 설정은 근본적으로 나쁘며, 제 생각에 제품 내에 포함되어서는 안 됩니다.
더 많은 사람들이 같은 문제를 겪고 있다면, 이메일 잠금 모드가 더 정당화될 수 있을 거예요. 하지만 지금은 그 사이트에서 그 한 명뿐이니까요.
그래서 일단 지켜보는 거죠…
1개의 좋아요
그 기능을 사용하지 않을 한 사이트의 한 사람
이 표현이 더 정확합니다…