기능 요청: 다이제스트용 별도 이메일 계정

기여 기능
1

초보자로서 오늘 모든 이메일이 사실상 shutdown되고, 주간 다이제스트가 레거시 포럼 마이그레이션 이후에 시작되면서 sidekiq 큐에 30만 건 이상의 이메일이 쌓이게 되어 사용자가 이메일로 등록, 비밀번호 복구, 로그인을 할 수 없었던 경험을 했습니다. 즉, 이메일을 통해 로그인, 등록, 비밀번호 복구 등을 시도한 사용자는 어떤 이메일도 받지 못했고, 완전히 hosed(망가진 상태)가 된 것입니다.

이 문제는 우리가 GMAIL을 메일 릴레이로 사용하고 있는데, (무료) GMAIL이 이러한 SMTP 릴레이에 한도를 설정하고 있기 때문에 발생했으며, 결국 GMAIL이 당일 우리를 차단해 버린 것입니다.

이 기능이 향후 추가되기를 요청드립니다. (다른 해결 방법이 없다면요.)

제안 사항

관리자가 다이제스트를 위해 다른 이메일 릴레이를 설정할 수 있도록 app.yml 변수 세트를 하나 더 추가해 주세요.

설정 과정에서 대화 상자에 다이제스트를 위한 다른 SMTP 서버를 설정하시겠습니까?라는 질문을 추가하고, 사용자가 원한다면 기존 SMTP 릴레이를 그대로 사용하도록 할 수 있습니다.

근거

많은 다이제스트 활동이 발생하는 대형 포럼의 경우, 비밀번호 복구, 로그인, 등록과 같은 핵심 작업에 사용되는 SMTP 릴레이와 별도로 다이제스트 이메일을 다른 SMTP 릴레이를 통해 전송할 수 있는 옵션이 있으면 좋겠습니다.

현재로서는 모든 다이제스트를 꺼 놓았습니다. 최근 X일 동안 확인된 것으로 제한할 수 있는 방법을 확인했습니다. 오늘 확인했을 때 기본값은 365일이었습니다. 어떤 이유에서인지 마이그레이션된 서버에서 30만 건 이상의 메시지가 큐에 쌓였습니다.

토론

큰 문제는 아니지만, digest(다이제스트) 이메일과 mission critical(핵심) 이메일을 분리하는 것이 좋다고 생각합니다. mission critical emails의 queuing priority(큐 우선순위)가 더 높더라도, 과도한 다이제스트로 인해 SMTP 릴레이가 차단되면 mission critical 이메일도 함께 차단되기 때문입니다.

또한, 일부 포럼에서는 SMTP 메일이 작동하지 않는 이유를 모르고 비슷한 상황을 겪고 있을 수 있습니다. 실제로는 위에서 언급한 이유로 차단된 경우일 수 있습니다.

신중한 검토 부탁드립니다.

TangentialDuck

2개의 좋아요
2

무료 Gmail을 사용하여 Discourse에서 이메일을 보내는 것은 지원되지 않는다는 점을 참고하세요. 이는 Google의 서비스 약관 문제입니다. Gmail을 이런 방식으로 사용하는 것은 #unsupported-install에 해당합니다.

이 기능 요청을 구현하는 것이 어떻게 합리적인지 이해하기 어렵습니다. 지원되는 이메일 메커니즘을 사용했다면 해당 사고는 발생하지 않았을 것이기 때문입니다.

3

그것은 사실이 아닙니다.

우리는 구글 도메인을 보유하고 있으며, 무료 이메일은 오랫동안 지원되어 왔고 현재도 지원되고 있습니다.

20년간 포럼을 운영해 온 저에게 조금은 관대해 주세요. 어제 알에서 깨어난 것은 아니니까요, @Stephen

1개의 좋아요
4

그렇습니다. 저희 이메일 가이드를 무시하는 커뮤니티들은 이런 문제에 자주 부딪힙니다.

Google은 Gmail 계정에서 거래성 이메일을 보내는 것을 허용하지 않으며, 이를 시도하다가 계정을 영구적으로 상실하는 커뮤니티를 여러 번 목격한 바 있습니다. 유료 GSuite 계정 역시 하루 거래성 이메일 전송에 대한 엄격한 한도가 적용됩니다. 이러한 상황에 처한 분이 처음이 아니며, Google이 설정한 약관을 우회하는 기술적 해결책에 대해 도움을 드릴 수 없습니다.

1개의 좋아요
5

방금 GSuite 계정에 로그인해서 TOS를 확인해 봤는데, 말씀하신 내용은 사실과 다릅니다:

@Stephen, 너무 성급하게 발포하시네요. 저는 구글 TOS를 우회하는 기능을 요청한 적이 없으니, 제 글에 없는 말을 지어내지 마시기 바랍니다.

@Steven, 너무 성급하게 발포해서 허위 의혹을 제기하고 있으니, 좀 더 감정적으로 반응하지 않는 다른 분들이 제 요청에 답하게 해 주시겠어요?

6

여기서 말씀하시는 내용에 모순이 있습니다:

Gmail은 G-Suite가 아닙니다. 유료 G-Suite 계정은 다음과 같은 한도를 가집니다:

한도 유형 한도
하루 메시지 수
일일 전송 한도* 2,000건 (시범 계정은 500건)

무료 Gmail 계정은 항상 500통의 이메일 한도를 적용받습니다.

이것은 Google의 약관(TOS)이며, 위 내용과는 아무런 관련이 없습니다. '지금까지는 작동했다’는 것과 '그렇게 하는 것이 허용된다’는 것 사이에는 확실히 차이가 있습니다. 지난 7년 동안 사용자가 이를 시도해 본 사례를 여러 번 목격했으며, 결코 성공한 적이 없습니다:

이 주제에 대한 추가 읽기 자료

New setup - errors when trying to send emails through gmail - #2 by pfaffman
Office 365 SMTP settings - #2 by codinghorror
https://meta.discourse.org/t/setup-smtp-in-discourse/79173/2
Anyone using gmail for SMTP? - #8 by sam
Gmail SMTP Relay Setup not working - #2 by justin
Can I use gmail smtp? - #2 by fefrei
POP3 polling error - #4 by pfaffman
Sidekiq queue too large - Google email provider problems - #2 by codinghorror

추천 제공자 목록이 포함된 이메일 설정 가이드가 있습니다. 이를 따를 의무는 없지만, 의도된 방식이 아닌 Gmail 또는 GSuite 사용법에 대해서는 도움을 드릴 수 없습니다.

1개의 좋아요
7

네, 제가 게시글을 올리기 전에 이미 그 사실을 알고 있었습니다 @Steven

개인적으로, 모자이크 브라우저가 등장하기도 전에 인터넷을 사용해 온 사람의 지식을 과소평가하는 것은 삼가야 하며, 답변을 작성할 때도 주의해야 한다고 생각합니다. 다른 사람에게 비난의 말을 던지는 것은 디스코스와 기술 전반의 즐거움을 해치는 일입니다.

먼저 "무료 GMAIL은 존재하지 않는다"고 말씀하셨고(그것이 틀렸다는 것은 제가 이미 알고 있었습니다), 악의적인 활동을 했다고 비난하신 후, 직접 조사해 보시더니 GSuite의 하루 2,500통 제한을 발견하셨더군요. 저는 수년간 이 GSuite 계정을 관리해 왔기 때문에 이 제한에 대해 오래전부터 알고 있었습니다.

이렇게 서둘러 판단하고, 사람들이 나쁜 일을 했다고 비난했다가 세부 사항에서 틀렸다면 사과해야 합니다.

그냥 단순한 기능 요청을 올렸을 뿐인데, 이런 부정적인 에너지에 대응해야 하는 것은 정말 즐겁지 않습니다.

8

이것은 여러분이 gsuite가 아닌 Gmail을 사용하고 있다는 것을 시사하며, 이는 규칙에 위배됩니다. 시스템 관리가 무엇인지 모르는 사람들, 특히 주제와 관련된 많은 사람들이 Gmail을 사용하려 하지만, 이는 서비스 약관에 위반됩니다. 이것이 좋은 생각이며 악의적이거나 무례한 것이 아니라고 사람들에게 말하는 것은 좋은 일입니다.

하지만 여러분은 gsuite를 사용하고 있으며, 이는 완전히 문제없습니다. 원래 게시물로는 이것이 판단할 수 없었습니다. 그래서 여러분이 부당하게 대우받는 것처럼 보이는 것입니다.

다만, 여러분이 설명한 대로 Gsuite는 트래픽이 많은 포럼에서는 실제로 작동하지 않습니다. 여러분은 Discourse가 하루 2,500건의 메시지로 제한되는 메일 서비스와 어떻게든 작동하도록 하는 새로운 기능을 요청하고 있는 것입니다.

이를 위한 플러그인을 만드는 것은 가능하지만, 매우 쉽지 않을 것입니다. Discourse 개발에 익숙한 사람이 며칠의 작업이 필요할 것으로 추정됩니다.

해결책은 여러분이 보내야 할 양의 메일을 전달할 수 있는 메일 서비스를 사용하는 것입니다.

2개의 좋아요
9

추가로 말씀드리자면, 이 주제는 중복입니다. 여러 SMTP 서비스를 사용하겠다는 요청은 이전에 이미 접수된 바 있습니다:

여기서 언급된 사용 사례는 다소 다르지만, 문제는 다이제스트 설정 오류에서 비롯되었습니다. Unix.com에는 138,062명의 사용자가 있으며, 비밀번호 재설정과 같은 긴급한 작업에서도 하루 2,000통의 이메일 한도로 인해 매일 상호작용할 수 있는 사용자는 전체의 1.8%에 불과합니다.

수정: 실제 한도를 반영하기 위해 2,500에서 2,000으로 수정했습니다.

1개의 좋아요
10

@pfaffman, 그래서 온라인에서 다른 사람들의 기술 사용이나 동기에 대해 즉흥적으로 비난하는 말을 서두르지 않는 것이 모두에게 가장 좋습니다. 보통은 먼저 질문을 한 후에 총을 쏘기 시작해야 합니다. (LOL)

네, 저는 GMAIL이라고 GSUITE라고 말하지 않았습니다. 하지만 제가 이 도메인을 수십 년 전에 만들었을 당시에는 GSUITE라는 것이 없었고, 그냥 GMAIL이라고 불렸습니다. 또한 제가 정확성을 기하지 않은 이유는, 제 기능 요청이 GMAIL과는 전혀 무관하기 때문입니다. 그것은 완전히 별개의 주제입니다.

저나 여러분이 원한다면, 여기 있는 많은 분들이 할 수 있듯이 어떤 서버에든 접속하여 apt install postfix 또는 apt install sendmail을 입력하고 15분 이내에 자체 SMTP 릴레이를 실행할 수 있습니다.

제발 주제를 무거운 트래픽을 다이제스트 프로세스에서 GMail 대 GSuite 대 그 외의 것으로 이동하는 것으로 바꾸지 맙시다. apt install postfix는 자명한 일입니다.

문제는 신뢰성입니다. 이는 기본적인 101 수준의 내용입니다.

mission critical 이메일을 digests와 동일한 SMTP 릴레이에서 실행하는 것은 제가 원하는 운영 방식이 아니므로, 이 기능 요청을 했습니다.

제가 요청하는 것에 초점을 맞춰 주십시오. 저는 mission critical 앱을 구축하는 데 있어 제가 말하는 것을 잘 알고 있기 때문입니다.

다시 한 번 말씀드립니다:

저는 mission critical email을 digest email과 동일한 SMTP 릴레이에서 실행하지 않기를 원하며, 이는 시스템의 견고성을 높이는 좋은 아이디어라고 생각합니다.

GMAIL이나 GSuite, MonkeyMail 등에 대한 매우 부수적인 논의를 그만합시다. 이메일 서버는 제 기능 요청과 무관하므로 언급한 것조차 죄송합니다.

조금 천천히 하십시오. 다른 사람에게 친절하게 대하십시오… 누군가 무언가를 게시했는데, 여러분이 이해하지 못하거나 혼란을 느끼면 질문하십시오. @Steven에게 총을 쏘지 마십시오.

저는 10분 만에 SMTP 릴레이를 구축할 수 있습니다. 우리 모두 할 수 있습니다. apt install postfix 하면 끝입니다… 제가 GSuite를 사용하든 postfix를 사용하든 donkey kong mail을 사용하든, 그것은 제 결정이지 다른 사람의 결정이 아닙니다. 말씀드렸듯이…

핵심 내용 … (다시 한 번)

mission critical email을 digest channel과 다른 서버에서 실행하는 것이 더 신뢰할 수 있습니다. 이는 매우 바쁜 서버에 있어 기본적인 사항입니다.

apt install postfix는 SMTP 릴레이를 생성합니다. 저는 mission critical email(비밀번호 재설정, 가입 이메일, 이메일 로그인)이 신뢰성과 성능의 이유로 digests와 다른 채널에서 처리되도록 하는 기능을 요청하고 있습니다.

11

@Steven

그것이 핵심이 아닙니다. 그것은 본질에서 벗어난 이야기입니다.

참고: 실제로 우리도 한때 50만 명 이상의 사용자를 보유하고 있었지만, 정리했습니다 :slight_smile:

제가 말하려는 것은 중요한 업무 이메일(mission critical email)을 다이제스트 트래픽과 다른 채널(SMTP 릴레이)로 처리하는 것입니다.

물론, 이 단순한 개념과 두 개의 채널이 왜 더 나은지에 대한 개념을 이해하는 것은 매우 쉬운 일입니다.

이 토론은 제 기능 요청의 원래 아이디어에서 완전히 벗어난 방향으로 흐르고 있습니다.

제가 글을 쓰고 질문한 것조차 죄송합니다… :frowning:

제 원래 게시물 이후의 이 토론은 제 생각에 매우 엉뚱한 방향으로 흐르고 있습니다.

12

도와주려는 모든 사람의 능력을 과소평가하지 마세요. 아무도 당신을 반대하지 않습니다.

3개의 좋아요
13

이 주제에 대해 내가 남기는 마지막 게시글입니다.

GSuite에 대해 말하자면(제 기능 요청의 핵심과는 전혀 무관한 부분이지만)

  • 사용자가 24시간 동안 보낼 수 있는 최대 메시지 수는 10,000건입니다. 그러나 이는 G Suite 계정 내 사용자 라이선스 수에 따라 달라질 수 있습니다.
  • G Suite에 등록된 사용자는 24시간 동안 10,000명 이상의 고유 수신자에게 메시지를 릴레이할 수 없습니다.

참고: Route outgoing SMTP relay messages through Google  |  Gmail  |  Google Workspace Help

그러나 제 입장에서는 이는 완전히 주제에서 벗어난 이야기입니다. GSuite가 SMTP 릴레이를 통해 하루에 10억 건 이상의 이메일을 허용하더라도, 저는 핵심 업무(mission critical) 이메일과 요약(digest) 이메일에 대해 서로 다른 SMTP 릴레이 채널을 원하기 때문입니다.

여기가 핵심입니다.

감사합니다. 향후 업그레이드 시 이 점을 고려해 주십시오. 이 기능을 추가하는 것은 비교적 쉬운 일이라고 생각합니다.

이 기능 요청은 성격(personality)에 관한 것도 아니고, 이메일 제공업체의 장단점이나 세부 사항에 관한 것도 아닙니다.

제 기능 요청은 신뢰성과, 핵심 업무 이메일을 요약 채널에서 분리해 두는 것에 관한 것입니다.

이만 마치겠습니다… :slight_smile:

14

Discourse를 개발하는 사람들은 이미 잘 작동하는 메일 시스템을 가지고 있습니다. 그들은 여러 신뢰할 수 없는 메일 시스템을 사용하려는 사람들을 위해 기능을 추가하지 않을 것입니다. 원하신다면 플러그인을 직접 개발할 수 있습니다. 개발이 어려울 뿐만 아니라 유지보수도 번거로울 것입니다.

postfix를 설치하는 것은 쉬울 수 있지만, Sendmail과 uucp를 Linux로 이식했을 때와 비교하면 현재 기능하는 메일 서버를 운영하는 것은 훨씬 더 어렵습니다. 메일 서버 운영이 쉬웠다면 이미 작동하는 메일 서버를 하나 가지고 있을 것이고, 두 개를 원하지는 않았을 것입니다.

그것이 제 생각은 아니지만, 당신은 저보다 Discourse 플러그인 개발에 대해 훨씬 더 많이 알고 있을 수 있습니다.

3개의 좋아요
15

가장 간단한 해결 방법은 그렇게 많은 문제가 발생한다면 다이제스트 이메일을 전역적으로 "비활성화"하는 것입니다. 가장 좋은 제안은 이미 제시되었을 수 있으며, 저는 제한이 없는 이메일 제공업체(예: Mailgun)를 사용하도록 제안할 수 있을 뿐입니다. 이렇게 하면 모두가 만족할 것입니다(특정 이유로 특정 이메일 제공업체만 사용해야 하는 제약이 있는 경우를 제외하고는).

4개의 좋아요
16

동의합니다. @neounix가 처음에 게시한 내용에는 많은 모순이 있으며, 후속 답변에서 세부 사항이 많이 바뀌고 있습니다.

위 인용문에서 강조한 부분은 무료 계정 제한 사항이며, 이는 이미 이 토픽의 다른 곳에서 문서화되어 있습니다. 기존에 사용 중이던 ‘무료’ GSuite 계정도 이러한 한도를 가지고 있습니다. 만약 이것이 유료 GSuite 계정이라면, 위의 언급은 오해의 소지가 있으며 이것이 제가 그렇게 반응한 이유를 설명합니다.

다시 한번 말씀드리지만, 여기서 어떤 서비스를 사용하고 있는지 명확하지 않습니다. 만약 무료 티어의 레거시 Google Apps를 사용하고 있다면 사용자당 하루 500명의 수신자 제한이 적용되며, 이는 무료 Gmail 제품과 동일합니다. 유료 GSuite 계정을 사용하고 있다면 Google SMTP 릴레이 서비스를 사용해야 하며, 한도는 사용자당 하루 10,000건입니다. 이는 더 낫지만 여전히 좋지 않은 수준이며, 특히 비밀번호 재설정을 요청해야 하는 130,000명 이상의 사용자가 있는 경우에는 더욱 그렇습니다. 마이그레이션 과정에서 일부 사용자를 정리했다는 소식을 들으니 다행이지만, 그것이 실제로 얼마나 중요한지 확실하지 않습니다.

여기서 느끼시는 좌절감을 이해할 수 있습니다. 테스트에서 큐에 쌓일 다이제스트를 포착하지 못했기 때문입니다. 이로 인해 비밀번호를 재설정하고 계정에 다시 로그인하려는 사람들에게 실질적인 서비스 불가 상태가 발생했습니다.

위에서 몇 번이나 제가 말꼬리를 잡는다고 말씀하셨지만, 제가 볼 때 답변들은 여러분이 제공한 정보와 일치합니다. 동의하지 않으신다면 죄송합니다만, 게시물을 다시 읽어봐도 정확히 어떤 제품을 사용하고 있는지 여전히 불분명합니다.

참고로 저는 @Stephen이며 @Steven이 아닙니다 - 완전히 다른 사용자를 태그하고 알림을 보내고 계십니다.

3개의 좋아요
17

그렇다면 Marketplace 채널에 예산을 명시하여 게시물을 올리고 기금을 지원해 주세요. 또한 위에서 이메일 양을 줄이는 데 도움이 되는 아주 좋은 제안들이 몇 가지 있으니 :index_pointing_up:, 그것들을 활용해 보시길 권합니다.

3개의 좋아요
18

지금은 다이제스트를 완전히 끄기로 했습니다. 그리고 업데이트된 배경 이야기는 다음과 같습니다:

우리는 스테이징 서버도 가지고 있으며, Discourse는 설치 시 기본적으로 주간 다이제스트(365일 창)를 활성화하기 때문에, 그 스테이징 서버에서도 지난 주말에 다이제스트가 시작되었습니다(우리는 이를 예상하지 못했었죠). LOL

즉, 이런 일이 일어날 것(또는 일어날 수 있을 것)을 알기 전에… 스테이징 서버에서 백업을 시도했는데 시스템이 이를 거부했습니다… 에러를 표시하며요. 관리 콘솔에서 정확한 에러 메시지를 잊어버렸지만, 메일 큐를 가리키는 단서가 있었다는 기억은 나네요.

그 단서를 가지고 이제 sidekiq를 살펴보니, '켜짐’과 '최근 365일’이라는 기본 다이제스트 설정으로 인해 큐에 30만 개 이상의 다이제스트 메시기가 있는 것을 확인했습니다.

그래서 저는 명령줄에서 메일 큐를 비우고, 다시 백업 관리 패널로 가서 백업을 수행했는데, 이번에는 잘 작동했습니다.

Discourse의 이메일 시스템은 sidekiq 기반으로 구축되어 있기 때문에, mission critical(중요 메일)과 digest(다이제스트)에 서로 다른 채널(서로 다른 이메일 서버)을 설정하는 것이 까다로울 수밖에 없는 이유입니다. 처음에는 생각했던 것만큼 단순하지 않다는 것을 깨달았습니다(environments에 두 개의 이메일 서버만 설정하면 되는 줄 알았거든요).

여기 재미있는 부분이 있습니다… LOL

처음에는 365일 로그인 창이 있는 상태로 활성화되어 있는 것보다 다이제스트를 기본적으로 꺼두는(OOTB) 것이 좋은 아이디어라고 생각했습니다. 하지만 나중에 에러의 원인이 전부 제 탓이었다는 것을 기억해냈고, meta에 그런 제안을 올리는 것은 좋은 생각이 아니었네요. LOL.

Discourse를 설치했을 때, 이전 vB3 포럼에서 마이그레이션된 모든 사용자의 last_seen_at 값이 기본적으로 약 50년 전으로 설정되어 있었습니다.

저는 데이터베이스에 들어가서 모든 사용자의 마지막 접속 시각을 10일 전으로 수동으로 변경했습니다! LOL. 당시에는 다이제스트 설정에 대해 아무것도 몰랐고, 마이그레이션 후 모든 사용자의 마지막 접속 시각이 50년 전으로 되어 있는 것은 마이그레이션 오류라고 생각했습니다. 하하… 저는 틀렸습니다. 이렇게 설정된 데에는 좋은 이유가 있습니다.

Discourse는 막대한 규모의 주간 다이제스트 프로세스를 시작하여 프로덕션과 스테이징 서버 모두의 sidekiq를 압도했습니다. 스테이징 서버에서 "마지막 접속 10일 전"이라는 DB 변경 해킹을 수행했고, 이를 프로덕션으로 내보냈기 때문입니다. 이 실수가 이 문제를 일으킨 것입니다.

대부분의 사람들은 저처럼 postgres에 들어가서 다음과 같은 작업을 하지 않기 때문에:

UPDATE users SET last_seen_at "오늘 - 10일"

… 많은 사용자가 있는 레거시 마이그레이션에서…

이러한 대규모 다이제스트 문제에 직면하지 않을 것입니다.

LOL

users 테이블에 대한 제 UPDATE 해킹으로 인해 이런 긴장감을 조성한 점 사과드립니다.

아직도 mission critical 이메일과 digest 이메일을 두 개의 다른 이메일 서버에 두는 것이 합리적이라고 생각합니다. 하지만 sidekiq를 살펴본 결과, sidekiq에 대한 경험(아직)이 없기 때문에 이를 수행하는 간단한 방법이 있는지 아직 명확하지 않습니다.

그러나 마이그레이션 담당자에게 조언을 드릴 수 있습니다. 포럼을 discourse로 마이그레이션하는 경우(이것은 훌륭한 아이디어입니다), users의 기본 last_seen_at 값을 그대로 두시기 바랍니다 :slight_smile:

1개의 좋아요
19

보통 스테이징 인스턴스와 외부 사이에는 Mailhog를 두는 것을 권장합니다. 이 유형의 시나리오에서 매우 유용합니다.

4개의 좋아요
20

스테이징 인스턴스에 DISCOURSE_DISABLE _DIGEST _EMAILS를 추가할 예정입니다. 하지만 이메일 비활성화 대상이 비스태프로 설정되어 있어 큰 문제는 아닙니다.

2개의 좋아요