게시물에 포함된 도메인이 유효한지, 가능하면 게시 전에 확인하세요. 도메인 확인이 실패하면 게시물을 관리자 검토 대상으로 표시합니다.
이것은 링크 확인기가 아닙니다.
이것은 이메일 주소 확인기가 아닙니다.
최근 이메일 주소가 포함된 게시물을 확인했습니다. 답변이 쌓이면서 원포스터(OP)의 사실 관계가 맞지 않는 것으로 드러났습니다. 도메인 이름을 확인해 보니 등록된 도메인을 찾을 수 없었습니다. 예를 들어 ICANN 조회를 통해 확인한 결과입니다.
이에 따라 해당 게시물은 목록에서 제외되었습니다.
이 기능은 매우 구체적인 용도로 사용될 수 있지만, 게시물에 잘못된 도메인 이름을 제공하는 데에는 정당한 이유도 있습니다.
예를 들어, meta에서 구성을 공유할 때 자신의 인스턴스 주소를 공개적으로 공유하고 싶지 않을 수 있습니다. 또한 일반적이거나 존재하지 않는 도메인에 대해 URL 구조의 예시를 공유하는 것도 꽤 흔한 일입니다.
매우 구체적인 상황처럼 보이는데, 더 자세한 내용을 공유해 주실 수 있을까요?
그러나 이는 좋지 않은 관행입니다. 해당 도메인들은 실제로 존재하여 _다른 무언가_일 수 있거나, 더 나쁘게는 미래에 존재하게 될 수도 있습니다. 예시에는 example.com, example.org 또는 example.net을 사용해야 합니다. 이 도메인들은 실제로 존재하며, 해석(resolution)이 되며, 이러한 목적으로 의도된 것입니다.
최선 관행(best practice)의 문제는, 초보자들은 이 용어에 익숙하지 않다는 점입니다. 위에서 언급한 맥락에서 게시글을 작성할 때 최선 관행을 언급하는 것은 마치 عاج자탑(象牙之塔)에 갇힌 이야기처럼 느껴져서, 오히려 사용자의 진입 장벽을 높일 수 있습니다. 표준 설치 과정이 비교적 쉽기 때문에, Discourse 설치가 사용자에게는 첫 번째 ‘시스템 관리(sysadmin)’ 수준의 작업이 될 수도 있다는 점을 기억해야 합니다.
사용자가 링크를 게시하기 전에 도메인 소유권을 확인하는 것은 현실적으로 불가능합니다. 유효하지 않은 도메인이 포함된 설정을 공유하는 경우, 단순한 오타, DNS 설정 오류, 그리고 아직 전파(repllication)되지 않은 도메인 중 어느 것인지 어떻게 구별할 수 있겠습니까?
비꼬려는 의도는 아닙니다.
관리자로서 수동으로 어떻게 확인하라는 말씀이시라면, ICANN 조회가 실패할 경우 해당 사용자에게 세부 사항을 묻는 개인 메시지를 보내는 것이 제 방식입니다.
해당 게시글은 다음과 같습니다.
주제가 비공개(unlisted) 처리된 후 마지막 게시글을 남기고 바로 사이트를 떠난 것으로 보입니다. 주제가 비공개(unlisted) 처리된 대부분의 사용자는 보통 최대한 빨리 응답하는 경향이 있습니다.
해당 사용자는 게시글을 남기기 몇 시간 전에 가입했으며, 그 기간 동안 몇 가지 플래그(신고)를 받기도 했습니다.
위에 링크된 주제에서 도메인 체크어가 어떻게 도움이 되었을지 조금 더 자세히 설명해 주실 수 있을까요?
OP(첫 번째 게시자)은 도메인이 아니라 이메일 주소만 포함하고 있습니다. 11번째 게시물에서 .com을 언급하신 것은 우연히 유효한 등록된 도메인입니다 — sedo에 주차되어 있거든요. 사용자가 이를 명시하고 도메인이 확인되었다면, 유효한 whois 정보가 반환되었을 것입니다.
제가 링크한 주제에서 제안하신 해결책이 모더레이션 부담을 어떻게 줄였는지 명확하지 않습니다.
내 실수를 발견했습니다. 고무 오리 디버깅을 하게 해 주셔서 감사합니다.
인간으로서 plausibleai를 도메인으로 인식했지만, 실제로는 사용자 이름의 일부였습니다. 그래도 사용자가 잘못된 도메인을 전달하는 시도를 여전히 하므로, 도메인 체크어가 있다면 좋을 것 같습니다.
솔직히 이건 rdd보다는 xy problem에 더 가깝다고 느껴집니다.
악의적인 행동으로 인한 여파를 처리하고 싶어 하는 사람은 아무도 없으며, 사용자를 사이트 밖으로 유도하려는 시도는 분명히 그런 의도를 드러낼 수 있습니다. Discourse에는 대량 스팸봇 활동에 대한 다양한 보호 장치가 있지만, 이 kinds의 표적화된 문제는 여전히 커뮤니티 플래그와 신속하게 대응하는 모더레이터에게 맡겨지는 상황입니다.
결정론적인 문제라면 XY 문제라는 표현이 타당하지만, LLM과 학습을 고려할 때는 시도해 볼 가치가 있습니다. 아마 기능 제안보다는 Discourse AI의 제안으로 다루는 것이 더 적절할 수도 있습니다.
그래도 여전히 많은 스팸이 통과합니다. 스팸 탐지기는 주로 너무 빨리 타이핑하는 신규 사용자의 스팸을 잡아내는 경우가 많습니다.
이제는 이야기가 본론에서 벗어나고 있으니 여기서 마무리하겠습니다.