皆様、こんにちは。
コミュニティごとに要約メールの送信間隔を最適化することは可能でしょうか？毎週月曜日、Discourse が 1〜2 秒の間に数千件のメールを送信するため、カスタムメールサーバーでスパム問題が発生しています。
「last_digest_time」をアカウントごとにリセットし、他の数千のアカウントと同期させるにはどうすればよいでしょうか？
目標は、月曜日の 5,000 件ではなく、1 日あたり 100〜200 件の要約メールを送信することです。Discourse は過去 4 年間使用しており、頻繁に最新リリースにアップグレードしているため、アップグレードに問題があるのかもしれません。
また、Docker イメージの PostgreSQL にアクセスする方法や、データベース内のどのレコードを更新すべきかに関するヒントがあれば教えていただけますと幸いです。
よろしくお願いいたします。
rails コンソールで実行できます。
cd /var/discourse
./launcher enter app
rails c
その後、以下のような処理が可能です。
User.all.each do |u|
任意の処理を実行
end
ただし、メールサーバーの修正を行うべきです。
ご意見はありますか？サーバーは単に宛先にメールを送っているだけで、そこでは私たちのメールがスパム扱いされています。もし誰かが1秒間に2000通のメールを送ってきたら、私も同じことをするでしょう。
信頼できるメール配信サービスを利用してください。
ご自身でSMTPをホストしている場合、一般的に発生する問題に陥ることになります。MailgunやSendGridのようなメール配信企業は、サーバーが信頼され、宛先ネットワークから評判が良いと認識されるよう、複数の技術を採用しています。そのため、ドキュメントでは、自己ホストではなく、これらのサービスのいずれかを使用することが推奨されています。
その通りです。あなたがメッセージをスパイク状にしか送信しなくても、信頼できる第三者のメール配信サービスであれば、毎時間数十万件のメールを第三者のメールボックスに確実に配信できます。
残念ながら、ご自身でメールサーバーを運用することを堅持される場合、サポートを提供することはできません。推奨事項に従わないことを選択される場合は、それによって生じる追加の複雑さを受け入れることになります。
DMARC、SPF、DKIM を含め、SMTP には問題ありません。私は 2005 年から独自 SMTP を使用しています。当時は、あの手の「金稼ぎ」サービスは存在しませんでした。明日、誰かが空気を有料化しようとしたらどうなるか想像してみてください…
さて、問題に戻りましょう。シニアテスターにとっては、私をどこか有料サービスへ誘導するのが最も簡単な方法だとわかっています。Discourse の重大なバグを修正する方法について、誰か助けをいただけますか？Discourse が 1 秒間に 1 万通のメールを送信すべきだと私はまだ考えていません。アカウント間で「last_digest_timestamp」を正規化するローテーションサービス、あるいはそれに類する仕組みが必要だと考えます。
私は CDCK に雇用されておらず、サードパーティのサービスを案内することによって金銭的な利益を得ることもありません。
もし推奨事項やドキュメントに従うことを望まない場合は、ご自由にお選びください。その場合、ここではコミュニティに提供する無料のサポートの範囲外となり、残された選択肢は Marketplace を通じてコンサルタントと契約することのみです。
これは Discourse の問題ではなく、あなたのメールサーバーの IP アドレスが信頼できるものと見なされていないことが原因です。その問題を解決するお手伝いはできず、またその目的のために存在するオプションを検討することを拒否されています。
Discourseにおいて、数秒で1万文字を処理できることに問題ないということでしょうか？
はい、私はその10倍の量を送信するコミュニティと協力しています。大規模なコミュニティを運営している人々の多くは、その規模、あるいはそれ以上の規模で活動しています。
あなたのメールに関するニーズは、大量のメールを確実に配信するためのプロトコルに関するあなたの専門知識を超えているようです。そのため、トランザクショナルメールを提供する企業が存在します。ここで誰かが「大規模メール」を売り込んでいるわけではありません。これは単に、大量のメールを配信することの課題なのです。
メールサーバーでメールを保持し、配信を分散させることができます。これは Discourse の問題というより、メールサーバー側の問題です。私は 1990 年代初めから 2005 年頃までメールサーバーを運用していましたが、スパムがひどくなり、やめました。現在はさらに難しくなっています。
幸運を祈ります
レート制限がいくつかあります。もしあなたがこれを何も行わなくても、一般的な SMTP サーバーにはあらかじめ設定されたオプションが用意されています。現在のメールサーバーは賢くなっており、送信間の遅延を容易に検出できます。
はい、それはあなたが前述したサービスを利用しているからです。それでも、それらのサービスと個人向け SMTP サービスの違いを理解していないようです。彼らは膨大な IP アドレスのプールを使用し、異なる送信者をシミュレートしています。これは「ハード」スパムを行う企業にとって良い手法です。もちろん、彼らはこのサービスに対して料金を支払います。
Discourse がスパムを送信しない以上、なぜ人々がこれらの「お金の機械」を使う必要があるのか分かりません。ああ、すみません…バグのために、@Stephensays がこれが「真の動作」だと述べているため、月曜日に 1 秒間で 10 万件ものメールを送信してしまう可能性があります。
さて、頭に 
のアイコンがついている人々と話をしても意味がないと感じます。確かに 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 日には 1 日あたり 4,000 件の last_emailed_at がありました。そのため、現在、すべてのユーザーが 30 秒間隔で 3 日間に最適化されています。
Discourseは個人用SMTPサービスとの使用を想定して設計されていません。明確に説明しなかったことをお詫びします。確かに動作はしますが、定期的なメール活動を行うコミュニティにとっては推奨されません。これはメールの現状に起因する制限であり、私たちはできる範囲でそれに対応しています。
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.