# 사용자 차단 또는 삭제 관련 참고 사항
**URL:** https://meta.discourse.org/t/notes-on-silencing-or-deleting-users/323151
**Category:** Support
**Tags:** email
**Created:** [8월 23, 2024, 9:41오후 UTC](https://meta.discourse.org/t/notes-on-silencing-or-deleting-users/323151 "2024-08-23T21:41:53Z")
**Posts on this page:** 12
**Page:** 1
### Author:  [@TonyG](https://meta.discourse.org/u/TonyG)
#### Post date: [8월 23, 2024, 9:41오후 UTC](https://meta.discourse.org/t/notes-on-silencing-or-deleting-users/323151/1 "2024-08-23T21:41:53Z")
이 메모는 특정 사용자를 무음 처리(silence)하는 과정에서 제가 겪는 관리자 UX(사용자 경험)를 요약하기 위해 작성되었습니다. 반드시 변경을 요청하는 것은 아니며, 검토 시 요청 사항으로 이어질 수 있는 문제점들을 나열하는 것입니다.
1. 이메일 바운스(bounce)로 인해 사용자를 무음 처리해야 할 때, 해당 이벤트에 대해 사용자에게 알림 이메일이 발송되는 것을 원하지 않습니다. 🙂
2. 기존 목록에 사용자 정의 무음 사유를 추가할 수 있는 관리자 옵션을 찾을 수 없습니다. "이메일 바운스"라는 항목을 추가하고 싶습니다.
3. 사용 가능한 무음 기간 옵션 중 하나를 기본값으로 설정하고 싶습니다. 모든 이벤트마다 드롭다운에서 시간을 설정해야 하는 것을 피하고 싶습니다.
4. 사용자에게 왜 무음 처리되었는지, 1줄짜리 "사유"보다 더 자세한 정보와 함께 알려주고 싶습니다. 사용자에게 노트를 이메일로 보내는 상자(box)는 있지만, 다시 말하지만 이는 사용자에게 이메일을 발송하게 됩니다. 이메일이 작동하지 않는다는 것을 알기 때문에 메시지(메신저)로만 전달하고 싶습니다.
5. 사용자가 차단(block)되거나 무음 처리된 후에도 다른 Discourse 이메일이 발송되나요? 이 특정 시나리오와 기타 경우에 대해, 특히 사용자가 많은 알림에 구독되어 있다면 더 이상 사용자에게 메일이 발송되는 것을 원하지 않습니다.
6. 동일한 시나리오에서 사용자 삭제에 대해: 사용자를 단순히 삭제할 수도 있고, "이메일 주소와 IP 주소를 모두 삭제 및 금지(delete and ban)"할 수도 있습니다. 왜 이 두 가지가 연결되어 있나요? 이메일 주소를 금지하는 아이디어는 좋습니다. IP 주소를 금지할 일은 드물 것입니다. 그러나 IPv4를 금지하는 것은 여러 이유로 불편합니다 - IPv6라면 괜찮을 수 있지만 아직 그 단계는 아닙니다. 이 개념들이 분리되기 전까지는 단순히 이메일 주소만 금지할 수 없나요? Discourse 내부 구조에 대해 더 잘 알았다면 금지 목록에서 특정 항목을 정리하는 프로세스를 스크립트로 작성하는 것도 기꺼이 하겠지만, 해당 데이터를 어디서 찾을지 모릅니다.
7. 이 사이트에는 MaxMind가 활성화되어 있으며, IP 주소를 사용하여 위치를 파악하고 사용자가 단순히 무음 처리되어야 하는지 삭제되어야 하는지를 판단하는 데 도움이 되고 싶습니다. 예를 들어, 마지막 사용된 주소가 등록 주소에서 멀리 떨어져 있고(기타 지표와 함께) 악취(의심스러운 활동)가 난다면 계정을 삭제할 것입니다. 하지만 IP 정보를 표시하는 팝업에는 위치가 표시되지 않습니다. 이는 버그인가요, 아니면 MaxMind 설정을 다시 확인해야 하나요?
8. postmaster@ 주소로 바운스 통지를 받습니다 - 이것이 포럼에서 발송된 이메일이 바운스되고 있음을 아는 방법입니다. 누군가는 이미 기록된 바운스가 있는 사용자에게 이메일을 보내는 것을 피하기 위해 자동 차단(auto-cutoff)을 위해 Bounce Score를 살펴볼 것을 제안할 수 있습니다. 점수를 매기기 위한 바운스 데이터가 없고, Discourse를 POP3(IMAP??)에서 이러한 데이터를 폴링하도록 설정하지 않았습니다. 메타(meta)에서 확인한 것은 이를 설정하는 방법에 대한 포럼의 단편적인 이야기들뿐입니다. 이 주제에 대한 실제 전용 문서가 있나요?
다시 한번 말하지만, 이는 이 특정 영역에서의 (그다지 좋은 편이 아닌) UX를 공유하기 위한 것이며, 관심 있는 분들을 위한 것입니다.
도움이 되길 바랍니다 - 감사합니다!!!
---
### Author:  [@twofoursixeight](https://meta.discourse.org/u/twofoursixeight)
#### Post date: [8월 24, 2024, 3:58오전 UTC](https://meta.discourse.org/t/notes-on-silencing-or-deleting-users/323151/2 "2024-08-24T03:58:36Z")
> [@TonyG](#):
>
> 이메일 반송으로 인해 사용자를 침묵 상태로 전환할 때, 해당 사실을 알리기 위해 그들에게 이메일이 발송되기를 원하지 않습니다 [제가 아는 한]
침묵 사유를 비워 두면 그들에게 이메일이 발송되지 않을 것 같습니다.
> [@TonyG](#):
>
> 기존 목록에 사용자 정의 침묵 사유를 추가할 수 있는 관리자 옵션을 찾을 수 없습니다. "이메일 반송"을 추가하고 싶습니다.
이 부분은 [Custom Predefined Suspension Reasons](https://meta.discourse.org/t/custom-predefined-suspension-reasons/193088) 을 참고해 주세요.
- 이는 제가 Discourse에 대해 알고 있는 내용 기반으로 작성되었습니다(정확하지 않을 수 있지만, 도움을 드리고자 합니다!)
---
### Author:  [@TonyG](https://meta.discourse.org/u/TonyG)
#### Post date: [8월 24, 2024, 4:20오전 UTC](https://meta.discourse.org/t/notes-on-silencing-or-deleting-users/323151/3 "2024-08-24T04:20:14Z")
2468 - 정말 감사드립니다! 🙂
---
### Author:  [@Moin](https://meta.discourse.org/u/Moin)
#### Post date: [8월 24, 2024, 4:37오전 UTC](https://meta.discourse.org/t/notes-on-silencing-or-deleting-users/323151/4 "2024-08-24T04:37:43Z")
> [@TonyG](#):
>
> 이메일 바운스(bounce)로 인해 사용자를 무음 처리해야 할 때, 해당 이벤트에 대해 사용자에게 알림 이메일이 발송되는 것을 원하지 않습니다.
특히 `bounce score threshold`(바운스 점수 임계값)를 포함한 `bounce score`(바운스 점수) 사이트 설정을 어떻게 구성하셨나요?
---
### Author:  [@TonyG](https://meta.discourse.org/u/TonyG)
#### Post date: [8월 24, 2024, 5:31오후 UTC](https://meta.discourse.org/t/notes-on-silencing-or-deleting-users/323151/5 "2024-08-24T17:31:28Z")
아직 바운스 점수 임계값을 설정하지 않았습니다. 이는 Discourse가 바운스 알림을 위해 이메일을 확인하도록 구성하지 않았기 때문입니다. [이 메타 스레드](https://meta.discourse.org/t/bounced-emails-not-being-detected/293518/19)의 정보가 바운스 처리를 구성하는 방법에 대해 제가 찾은 가장 유용한 자료입니다. 앞으로 며칠 동안 더 완전한 문서를 찾는 데 주력할 예정입니다.
하지만 네, 오늘 아주 낮은 바운스 임계값을 설정할 것입니다.
---
### Author:  [@Architect](https://meta.discourse.org/u/Architect)
#### Post date: [8월 24, 2024, 7:23오후 UTC](https://meta.discourse.org/t/notes-on-silencing-or-deleting-users/323151/6 "2024-08-24T19:23:33Z")
> [@twofoursixeight](#):
>
> 침묵 사유를 비워두면 이메일이 발송되지 않는다고 추측합니다.
아니요, 그건 사실이 아닙니다.
계정을 침묵하려면 사유를 선택하거나 작성해야 합니다.
---
### Author:  [@TonyG](https://meta.discourse.org/u/TonyG)
#### Post date: [8월 24, 2024, 9:07오후 UTC](https://meta.discourse.org/t/notes-on-silencing-or-deleting-users/323151/7 "2024-08-24T21:07:42Z")
> [@Architect](#):
>
> 계정을 무음 처리하려면 반드시 그 전에 선택하거나 작성된 이유가 있어야 합니다.
이것은 사용자가 해당 이벤트에 대해 알리는 사이트 메시지가 사용자에게 전송되기 때문에 타당합니다. 하지만 그 사이트 메시지는 정확히 사용자가 무엇을 해야 하는지 명확하지 않습니다. 따라서 메시지가 전송된 후, 사용자가 이메일 문제를 수정했는지 확인하기 위해 해당 메시지에 답글을 달아 사용자에게 회신을 요청합니다.
현재 제가 직면한 초보자 수준의 문제들은 다음과 같습니다:
- 사용자에게 해당 메시지를 보내는 것은 원하지만, 텍스트를 수정하는 것이 좋습니다. 영어용 `admin/customize/email_templates/system_messages.email_revoked`를 변경해도 다른 모든 언어에는 적용되지 않습니다. 또는 system\_messages 중 하나 또는 전부를 대상으로 자동 번역을 실행하는 기능이 있나요?
- `admin/customize/email_templates/`에서 검색 기능이 없으면, 수정할 올바른 system\_messages 또는 user\_notifications 텍스트를 찾고 어떤 프로세스가 이를 트리거하는지 아는 것이 어렵습니다.
- 정의상 문제가 이메일을 받지 못하는 것이므로, 이메일을 보내고 싶지 않습니다.
- 사용자 프로필의 시스템 메시지에 답글을 달면 또 다른 이메일이 나갑니다. 해당 주소로의 발신 메일을 효과적으로 차단할 수 있다면 그런 일이 일어나지 않을 것입니다. 즉, 발신 메일 기능이 모두 바운스 임계값이 초과되었는지 먼저 확인하는 중앙 프로세스를 거치는 건가요? 아니면 바운스 임계값에 그 결정을 묶지 않고 발신 메일을 차단하는 Silence 관련 기능을 놓치고 있는 건가요?
- 이상적으로는 사용자가 이메일 주소를 유효한 것으로 교체하거나 "이제 내 주소는 정상입니다"라는 확인을 클릭할 때, 서버가 테스트 메일을 보내고 성공 시 바운스 플래그/카운트를 해제하면 좋겠습니다.
- (부수적 사항) `admin_js.admin.user.suspend_reasons`에는 고정된 수의 항목이 있으며, 다른 용도로 커스터마이징을 방지하기 위해 “경직하게” 식별되어 있습니다. 즉, `admin_js.admin.user.suspend_reasons.combative`의 텍스트는 변경할 수 있고 단일 `admin_js.admin.user.suspend_reasons.custom`이 있지만, 새로운 `admin_js.admin.user.suspend_reasons.bouncing_email`을 생성할 수 있는 것 같지 않습니다.
이 시나리오는 바운스에만 해당하지 않습니다. 사용자에게 메일을 보낼 수 없음을 지역 메시지로 알리고, 사용자가 무엇을 해야 하는지 알려주는 저장된 커스텀 메시지를 제공하고자 하는 다른 시나리오들도 생각날 수 있습니다.
이 모든 것이 아마도 우선순위 목록에 올라오지 않을 매우 세밀하게 조정된 동작을 설명하고 있다고 추정하지만, 다른 사람들이 이 문제를 어떻게 처리하는지 아직 알지 못합니다. 인내해 주셔서 감사합니다…
---
### Author:  [@TonyG](https://meta.discourse.org/u/TonyG)
#### Post date: [8월 24, 2024, 9:27오후 UTC](https://meta.discourse.org/t/notes-on-silencing-or-deleting-users/323151/8 "2024-08-24T21:27:48Z")
이 스레드에 진행 상황을 계속 업데이트하고 있습니다…
방금 바운스 처리를 설정하는 문서를 발견했습니다:
> [@Configure direct-delivery incoming email for self-hosted sites with Mail-Receiver](https://meta.discourse.org/t/configure-direct-delivery-incoming-email-for-self-hosted-sites-with-mail-receiver/49487):
>
> Discourse is all about enabling civilized discussion. While plenty of people like a web interface, e-mail is still the “hub” of many people’s online lives. That’s why sending e-mail is so important, and when you’re sending e-mail, you really want to be able to receive it, too. There are several reasons why: If e-mails “bounce” (they can’t be delivered for some reason), you need to know about that. Repeatedly sending e-mails that bounce will get your e-mails flagged as spam. Receiving e-ma…
> [@Configure VERP to handle bouncing e-mails](https://meta.discourse.org/t/configure-verp-to-handle-bouncing-e-mails/45343):
>
> Setting up bounces handling Discourse uses the [Variable envelope return path (VERP)](https://en.wikipedia.org/wiki/Variable_envelope_return_path) technique to handle bouncing e-mails. To enable VERP, set the “reply by email address” site setting with an email address template that uses the + sign. The default of replies+%{reply\_key}@discourse.example.com … works fine. If you are using your own or your company’s email server, then, that’s it tada Your discourse instance must be able to receive email sent to this address. This should work via POP, bu…
여기 있는 이미지들도 매우 유용합니다:
> [@반송된 이메일이 감지되지 않음](https://meta.discourse.org/t/bounced-emails-not-being-detected/293518/16?u=tonyg):
>
> the reply\_by\_email\_address is not used as the from address but the envelope-from, specifically so bounces work Here’s an image that demonstrates how each address is used. The addresses themselves are specific to our hosting, but should be sufficient for an example. notification\_email: notifications@hs1.discoursemail.com reply\_by\_email\_address: incoming+%{reply\_key}@hs1.discoursemail.com A notification: A replyable message:
이 기능을 구현하면 여기에서 제기된 문제의 상당 부분을 해결하여 반송된 이메일을 효과적으로 처리할 수 있을 것입니다. 이제 남은 과제는 다국어 사용자 기반에게 이메일 문제 해결 후 어떻게 효과적으로 알림을 보내고, 그들이 이메일 문제를 수정했을 때 빠르게 정상 상태로 복귀하도록 돕는 것입니다. 즉, 사용자가 효과적인 변경 사항을 적용한 경우, 본인이나 시스템이 우리에게 알림을 주어야 해당 사용자에게 설정된 차단이 해제될 수 있습니다.
---
### Author:  [@Architect](https://meta.discourse.org/u/Architect)
#### Post date: [8월 25, 2024, 4:49오전 UTC](https://meta.discourse.org/t/notes-on-silencing-or-deleting-users/323151/9 "2024-08-25T04:49:21Z")
> [@TonyG](#):
>
> 이 시나리오는 바운스(반송)에만 국한되지 않습니다. 사용자에게 메일을 보내줄 수 없음을 알리는 로컬 메시지와, 사용자가 어떻게 해야 하는지 알려주는 저장된 커스텀 메시지를 제공해야 하는 다른 시나리오들도 생각해 볼 수 있습니다.
자동화된 디스커스(Disourse) 이메일이 반송되는 경우, 스푸핑된 계정이나 유효한 이메일이 없는 계정이라고 의심되는 경우가 아니라면, 해당 계정을 무음 처리하거나 삭제할 필요는 없을 것 같습니다.
아마도 이메일이 정상적으로 작동하는지 확인하기 위해 계정을 일시적으로 보류 상태로 두는 것이 그 이유일 것입니다. 이런 유형의 사례가 많이 발생합니까, 아니면 하나씩 수동으로 처리하는 것이 현실적인가요?
이메일 알림 설정을 수동으로 변경하거나, 작동하지 않는 이메일 주소를 관리자가 임시로 제어하는 다른 정상 작동하는 주소로 변경하는 등 다른 옵션들도 있습니다. 이것이 최선의 방법은 아닐 수 있지만, 그저 떠오르는 아이디어들입니다.
계정이 삭제될 때 이메일 알림이 전송되지 않는다는 것을 마지막으로 확인했을 때 알 수 있었습니다. 이메일이 정상적으로 작동하지 않는 계정을 삭제하는 것은 단순하지만 다소 무리한 정책일 수 있습니다.
---
### Author:  [@TonyG](https://meta.discourse.org/u/TonyG)
#### Post date: [8월 27, 2024, 3:32오후 UTC](https://meta.discourse.org/t/notes-on-silencing-or-deleting-users/323151/10 "2024-08-27T15:32:32Z")
우리는 같은 의견입니다. 각 관리자가 다르게 처리하고 싶어하는 다양한 시나리오가 있습니다. 저는 이 소프트웨어가 무엇을 하는지, 어떻게 사용하도록 의도되어 있는지, 그리고 다른 사람들이 어떻게 사용하는지를 파악하기 위해 아직 탐색 단계에 있습니다.
이 이니셔티브/조사에는 두 가지 근본적인 목표가 있습니다. 첫째, 악용을 능동적으로 방지하는 것입니다. 둘째, 반송(bounce)되는 이메일을 발송하여 사이트가 전달 불가 이메일의 출처로 지정되는 것을 방지하는 것입니다. 이로 인해 RBL(Real-time Blackhole List)에 일시적으로 등재될 수 있으며, 저는 이러한 불필요한 상황을 피하고 싶습니다.
이 사이트의 트래픽은 많지 않지만, TL0-4와 유사하지만 다른 사용자 그룹이 있습니다. 이메일 관련 문제가 발생하더라도 한 그룹의 사용자는 침묵(silence) 처리되어서는 안 됩니다. 최근 온-토픽 게시글이 몇 개 있는 다른 그룹의 사용자도 침묵 처리되어서는 안 됩니다. 활동이 없거나 최근 유효한 활동이 없는 계정은 그들이 다시 돌아올 경우 주의를 끌기 위해 침묵 처리할 수 있습니다.
사람들의 주의를 끌기 위해 침묵 처리한다는 개념은 다소 어색합니다. 또한 저는 이메일 주소 자체에는 큰 관심이 없습니다. 그 진짜 의도는 잘못된 이메일 주소를 가진 계정은 악용의 출처일 가능성이 높다고 느끼기 때문입니다. 따라서 저는 사전에 침묵 처리하고, 반응을 구한 후, 오랫동안 연락이 없다면 계정을 삭제할 것입니다. 오랫동안 연락이 닿지 않았을 뿐인 참여하는 사용자(TL1?)는 장기 침묵/검토 상태로 전환할 수 있습니다.
여기까지 온 이상, 이 모든 것은 사람들이 유효하지 않은 이메일로 계정을 생성하거나 주소를 무효한 것으로 변경하고 있음을 의미합니다. 저는 #documentation을 검토하면서 자동화 기능을 만들 계획입니다. 새로운 TL0 사용자는 몇 개의 스레드를 열람한 후 침묵을 해제하고, 그 다음에 이메일을 보내는 것입니다. 이러한 특정 메시지에 대해 반송이 발생하면 검토 상태로 전환합니다. 즉, 사이트에서 활동하는 인간임을 확신할 때까지 환영 이메일을 보내지 않고, 이메일을 인증할 때까지 권한을 부여하지 않습니다.
---
### Author:  [@JammyDodger](https://meta.discourse.org/u/JammyDodger)
#### Post date: [8월 27, 2024, 3:36오후 UTC](https://meta.discourse.org/t/notes-on-silencing-or-deleting-users/323151/11 "2024-08-27T15:36:04Z")
참고로, 이메일 인증을 먼저 완료하지 않는 한 계정을 활성화할 수 없습니다(관리자가 수동으로 활성화하거나, SSO를 사용하면서 IdP 인증을 거치지 않는 경우 제외).
---
### Author:  [@Architect](https://meta.discourse.org/u/Architect)
#### Post date: [8월 27, 2024, 5:31오후 UTC](https://meta.discourse.org/t/notes-on-silencing-or-deleting-users/323151/12 "2024-08-27T17:31:50Z")
> [@TonyG](#):
>
> 이 모든 것은 또한 사람들이 유효하지 않은 이메일로 계정을 생성하거나, 자신의 주소를 유효하지 않은 것으로 변경하고 있음을 의미합니다.
반드시 그렇지는 않습니다. 이메일이 일시적으로 비활성화되었거나, 발신자를 차단한 경우(일시적인 계정 침묵과 같이 일시적일 수 있음) 등 다른 이유가 있을 수 있습니다.
말씀하신 상황에 대해 제가 먼저 추천하는 단계는, 사용자가 이메일로 메시지를 받지 못하고 있음을 알지 못하고 있을 수 있으므로 해당 사용자에게 정기적인 개인 메시지(PM)를 보내어 경고하는 것입니다. 체크박스를 사용하여 봉투 알림 아이콘을 녹색 대신 빨간색으로 만들 수 있는 공식 경고 PM으로 설정할 수 있습니다. 이렇게 하면 해당 사용자에게 공식 경고 PM을 하나 이상 보냈다는 기록이 계정에 남으므로 문서화할 수 있게 됩니다.
기본 설정에서 언급했듯이, 새 계정은 사이트 사용을 시작하기 전에 먼저 인증 이메일의 링크를 클릭하여 인증을 받아야 합니다. 이를 우회하지 않은 한 말입니다.
> [@TonyG](#):
>
> 자동화 기능을 만들어서: TL0의 새 사용자들이 몇 개의 스레드를 확인한 후에야 이메일을 받을 수 있도록 침묵(Silence) 상태에 두는 것입니다. 이 특정 메시지에 대해 바운스(bounce)가 발생하면 검토 상태로 변경합니다. 따라서 사용자가 사이트에서 활동하는 인간임을 확신할 때까지 환영 이메일을 보내지 않고, 이메일 인증이 완료되었음을 확신할 때까지 권한을 부여하지 않습니다.
기본 설정에서 기본적으로 이미 활성화되어 있는 것으로 보이지만, TL0 사용자는 공개 답변/토픽을 게시할 수 있지만, 기본 수준인 TL1로 승격될 때까지 누구에게도 개인 메시지(PM)를 보낼 수 없습니다. 이 승격에는 일정량의 읽기가 필요하며, 그 전에 이메일 인증이 완료되어야 합니다.