안녕하세요,
커뮤니티 수천 단위로 다이제스트 주기를 최적화할 수 있을까요? 매주 월요일에 Discourse가 1~2초 만에 수천 통의 이메일을 보내서 자체 메일 서버에서 스팸 문제가 발생하고 있습니다.
계정별로 "last_digest_time"을 초기화하고 다른 수천 개의 계정과 동기화하는 방법은 무엇인가요?
목표는 월요일에 5,000통 대신 하루 100~200통의 다이제스트를 받는 것입니다. 지난 4년간 Discourse를 사용해 왔고, 최신 릴리스로 매우 자주 업그레이드를 해왔기 때문에 업그레이드 관련 문제가 있는 것일 수도 있습니다.
또한, Docker 이미지의 PostgreSQL에 접근하는 방법과 DB에서 레코드를 "업데이트"하는 위치를 알려줄 힌트가 있을까요?
미리 감사합니다!
rails 콘솔에서 수행할 수 있습니다.
cd /var/discourse
./launcher enter app
rails c
그런 다음 다음과 같은 작업을 수행할 수 있습니다.
User..all.each do |u|
Do whatever
end
하지만 메일 서버를 수정하는 것이 좋습니다.
당신의 생각은 어떤가요? 서버는 그냥 편지를 우리가 스팸으로 분류한 주소로 보내고 있습니다. 누군가가 1초 만에 2,000통의 편지를 보내온다면 나도 똑같이 할 거예요.
신뢰할 수 있는 메일 전송 서비스를 사용하세요.
자체 SMTP를 호스팅하는 경우, 일반적으로 연관된 문제점에 직면하게 됩니다. Mailgun이나 Sendgrid와 같은 메일 전송 업체는 수신 네트워크에서 서버가 신뢰받고 평판이 좋다고 인식될 수 있도록 다양한 기법을 사용합니다. 이것이 바로 문서에서 자체 호스팅 대신 해당 제품 중 하나를 사용할 것을 권장하는 이유입니다.
정확합니다. 스파이크 형태로만 메시지를 보내더라도, 평판 있는 제3자 메일 전송 서비스는 매시간 수십만 통의 이메일을 제3자 메일함에 안정적으로 전달할 수 있습니다.
불행히도 자체 메일 서버를 운영하려는 경우 도움을 드릴 수 없습니다. 권장 사항을 따르지 않기로 결정하신다면, 이로 인해 발생하는 추가적인 복잡성을 수용하시는 것입니다.
DMARC, SPF, DKIM을 포함한 SMTP 설정은 모두 정상입니다. 저는 2005년부터 자체 SMTP를 사용해 왔습니다. 당시에는 쓸모없는 ‘돈을 버는 기계’ 같은 서비스가 없었습니다. 내일 누군가가 공기 사용에 대해 돈을 받으려 한다고 상상해 보세요…
자, 다시 문제로 돌아가 보겠습니다. 시니어 테스터의 가장 쉬운 방법은 저를 어딘가 또는 유료 서비스로 유도하는 것임을 알고 있습니다. 누군가 Discourse의 치명적인 버그를 수정하는 방법에 대해 도움을 줄 수 있을까요? 여전히 Discourse가 1초 만에 10,000통의 메일을 보내서는 안 된다고 생각합니다. 계정 간 "last_digest_timestamp"를 정규화하는 로테이션 서비스나 이와 유사한 것이 필요합니다.
저는 CDCK에 고용되어 있지 않으며, 귀하를 제3자 서비스로 유도하는 데 어떠한 금전적 이해관계도 없습니다.
추천 사항과 문서를 따르지 않기로 하신다면 그것은 귀하의 선택입니다. 이 경우, 여기서 커뮤니티에 제공하는 무료 지원의 경로에서 벗어나게 되므로, 다른 선택지는 #marketplace를 통해 컨설턴트를 고용하는 것뿐입니다.
이것은 Discourse의 문제가 아니라, 귀하의 메일 서버 IP가 신뢰할 수 없는 것으로 인식되고 있기 때문에 발생하는 문제입니다. 우리는 이 문제를 해결하는 데 도움을 드릴 수 없으며, 귀하께서는 이를 위해 존재하는 옵션들을 고려하기를 거부하고 계십니다.
Discourse에서 몇 초 만에 1만 개의 문자를 처리하는 것이 괜찮다는 뜻인가요?
네, 저는 해당 용량의 10배를 보내는 커뮤니티들과 함께 일하고 있으며, 대규모 커뮤니티를 운영하는 많은 분들이 그 규모 이상으로 운영되고 있습니다.
이메일에 대한 여러분의 요구사항이 대량으로 이메일을 안정적으로 전달하는 프로토콜에 대한 전문 지식을 초과하는 것으로 보입니다. 바로 이것이 트랜잭션 이메일 회사가 존재하는 이유입니다. 여기서는 '빅 이메일’을 홍보하는 사람은 없습니다. 단순히 대량 이메일 전달의 도전 과제일 뿐입니다.
메일 서버가 메일을 보유하도록 하고 배포를 분산할 수 있습니다. 이것은 discourse보다는 메일 서버와 관련된 문제입니다. 저는 1990년대 초반부터 약 2005년경까지 메일 서버를 운영했는데, 스팸이 너무 심해져서 운영을 중단했습니다. 지금은 훨씬 더 어렵습니다.
행운을 빕니다.
저는 몇 가지 속도 제한(rate limits)을 설정하고 있습니다. 만약 여러분이 이를 무시하더라도, 일반적인 SMTP 서버에는 이미 기본 설정이 되어 있습니다. 요즘 메일 서버는 훨씬 지능적이어서, 메일 발송 사이의 지연 시간을 쉽게 감지할 수 있습니다.
네, 그분들은 이전에 언급했던 서비스를 사용하기 때문입니다. 여전히 그 서비스들과 개인 SMTP 서비스의 차이를 이해하지 못하고 계신 것 같습니다. 그들은 거대한 IP 풀을 사용하며 다양한 발신자를 시뮬레이션합니다. 이는 “강력한” 스팸을 보내는 기업들에게 좋은 기법입니다. 물론, 그들은 이 서비스를 위해 비용을 지불합니다.
Discourse가 스팸을 보내지 않는다면, 사람들이 이러한 "돈 버는 기계"를 Discourse에 사용해야 할 이유가 어디에 있는지 모르겠습니다. 아… 죄송합니다… 버그 때문에 월요일에 1초 동안 10만 건을 보낼 수 있는데, @Stephensays 님이 이것이 TRUE(진실)된 동작이라고 하셨기 때문입니다.
머리 위에 왕관 
이 있는 사람들과 대화를 나눌 의미가 없다고 생각합니다. 네, Discourse는 훌륭하며, 여러분의 기여에 진심으로 감사드립니다.
이 없는 평범한 사람들이 여기서 몇 가지 아이디어를 얻을 수 있기를 바랍니다.
위에서 Discourse 팀이 제공한 답변에 따르면, 그들은 Discourse에서 어떤 문제도 발견하지 못했습니다. 저는 데이터베이스를 직접 해킹하는 다소 어설픈 방식으로 이 문제를 해결했습니다. 제 해결 방법은 다음과 같습니다.
cd /var/discourse
./launcher enter app
rails c
Topic.exec_sql("UPDATE users SET last_emailed_at = now() + interval '30' second * id WHERE last_emailed_at > ('2020-03-14'::date) AND last_emailed_at < ('2020-03-17'::date)")
SQL 쿼리의 last_emailed_at 범위를 업데이트하십시오. 저는 3월 16일에 하루 동안 4,000건의 last_emailed_at 기록이 있었습니다. 따라서 이제 모든 사용자의 기록이 30초 간격으로 3일에 걸쳐 분산되도록 최적화되었습니다.
Discourse는 개인 SMTP 서비스와 함께 사용하도록 설계되지 않았습니다. 명확하게 설명하지 못한 점 죄송합니다. 확실히 작동은 하지만, 정기적인 이메일 활동이 있는 커뮤니티에는 좋은 아이디어가 아닙니다. 이는 이메일 시스템의 한계이며, 우리는 모두 가능한 범위 내에서 이에 대응하고 있습니다. 