メーリングリストから移行しましたが、多くのユーザーが依然としてメールを介して当フォーラムを主に利用しています。
メーリングリストモードになっているユーザーは約 300 名ですが、新しいトピックが追加された際に Discourse が送信するメールは 75〜80 通程度に留まっているようです。
複数のメンバーのメーリングリストユーザー設定を比較しましたが、すべて同じ設定でした。
スキップセクションに問題は見当たりません。
何が原因か見当がつかず、どこを確認すればよいかわかりません。
すべてのユーザーが有効になっていますか？もしかしたら、メールが届いていないかもしれません。
はい、すべて有効になっています。
残念ながら、これもランダムなようです。設定用に使用しているいくつかのアカウントでも、動作が異なります。
さて、ここではいくつかの古いトピックを確認しましたが、これは似ているようです：https://meta.discourse.org/t/mailing-list-mode-not-sending-to-more-than-just-a-couple-of-users/80486/3
同じ問題かもしれません。ただし、その投稿の解決策で提案されている設定をどのように変更すればよいかはわかりません。
以下を実行しようとしています：
User.find_by_username(‘Neuer.test’).mailing_list_mode
しかし、エラーが発生します：
NoMethodError: undefined method `mailing_list_mode’ for #User:0x00005569c4038af8
メーリングリストモードは user_options テーブルに設定されています。UserOption.where(mailing_list_mode: true) を実行してみてください。メーリングリストモードが有効になっているすべてのユーザーのユーザー ID を取得するには、UserOption.where(mailing_list_mode: true).pluck(:user_id) を実行してください。
@simon さん、ありがとうございます
ご提案いただいた方法でリストを生成しました。実際には複数のリストになっています。ユーザー ID リストが生成され、約 50 件まで表示されると :...skipping... と表示され、その後、同じユーザー ID で再び開始し、末尾に新しい ID を追加して、このプロセスが約 4〜5 回繰り返されます。その間には、空白行だけのセクションが挟まっていますが、これは通常の動作でしょうか？
いずれにせよ、これはメーリングリストモードで購読しているユーザーの完全なリストとは程遠いものです（58 件しかありませんが、約 350 件を想定していました）。
その後、いくつかの ID についてチェックを行ったところ、例えば最後の投稿を受信していない ID が含まれていました。
また、UserOption.where(mailing_list_mode: false).pluck(:user_id) を実行したところ、さらに 29 件のエントリが取得できました。
UserOption.where(mailing_list_mode: 1).pluck(:user_id) を実行すると、true と同様の件数となり、同じユーザーが返されました。
合計すると、400 人のアクティブなユーザーのうち約 90 人しか見つけることができませんでした。非常に不可解で、何が起きているのか理解できません。
ご助力いただけますと幸いです。
追伸：検索結果の下部にある最後の : の後に、別のクエリを実行できるように終了するには、どのようにすればよいでしょうか？
クエリが画面に収まらないほどのテキストを返す場合、表示が縮小されます。動作については Google で検索してください。
スペースキーで次の画面へ、/ で検索、q で終了します。
つまり、アクティブなユーザー宛にメールが配信されていると考えてよいでしょう。他のユーザーは非アクティブかもしれませんね？
ありがとう、ジェイ。
いいえ、アクティブユーザーは450人以上います。パターンは特に見当たりません。数日前の過去の投稿を確認しましたが、メール配信モードで334人のユーザーに送信されていました。
それ以降に変更があったのは、Googleへの送信に問題があったためDNSにSPFレコードを追加したことだけです。これはメールサーバー側の設定で、Discourse内のSMTP設定は変更していません。
@pfaffman Data Explorer をインストールしたばかりですが、代わりにそこで実行できるクエリはありますか？
これには本当に頭が混乱してきました 
以前、336 人のユーザーが最近の投稿をそれぞれ受け取ったので、「どうやらすべてが解決したようだ」と投稿しようとしていました。
しかし、その後、同じユーザーが短い間隔で同じ投稿に 2 つの返信をしました。181 人のメンバーが両方のメッセージを受け取り、38 人が片方のメッセージを受け取り、残りの 117 人はメールを全く受け取りませんでした。
これについて何か手がかりになるような別のログはありますか？Sidekiq には何も記録されていません。
問題は、IP アドレスからの接続が多すぎるという 421.4.7.0 エラーのようです。
奇妙なことに、これは主に 1 人のメンバーで発生しているようです。
どのように修正すればよいでしょうか？
ログによると以下の通りです：
メッセージ（1957 件のコピーが報告されました）
ジョブ例外：421 4.7.0 dd27022.xxxxxx.com エラー：xxx.xxx.xx.xxx からの接続が多すぎます
### バックトレース
/usr/local/lib/ruby/2.6.0/net/smtp.rb:969:in `check_response'
/usr/local/lib/ruby/2.6.0/net/smtp.rb:553:in `do_start'
/usr/local/lib/ruby/2.6.0/net/smtp.rb:518:in `start'
mail-2.7.1/lib/mail/network/delivery_methods/smtp.rb:109:in `start_smtp_session'
mail-2.7.1/lib/mail/network/delivery_methods/smtp.rb:100:in `deliver!'
mail-2.7.1/lib/mail/message.rb:2159:in `do_delivery'
mail-2.7.1/lib/mail/message.rb:260:in `block in deliver'
actionmailer-6.0.1/lib/action_mailer/base.rb:589:in `block in deliver_mail'
activesupport-6.0.1/lib/active_support/notifications.rb:180:in `block in instrument'
activesupport-6.0.1/lib/active_support/notifications/instrumenter.rb:24:in `instrument'
activesupport-6.0.1/lib/active_support/notifications.rb:180:in `instrument'
actionmailer-6.0.1/lib/action_mailer/base.rb:587:in `deliver_mail'
mail-2.7.1/lib/mail/message.rb:260:in `deliver'
actionmailer-6.0.1/lib/action_mailer/message_delivery.rb:114:in `block in deliver_now'
actionmailer-6.0.1/lib/action_mailer/rescuable.rb:17:in `handle_exceptions'
actionmailer-6.0.1/lib/action_mailer/message_delivery.rb:113:in `deliver_now'
/var/www/discourse/lib/email/sender.rb:212:in `send'
/var/www/discourse/app/jobs/regular/notify_mailing_list_subscribers.rb:90:in `block (2 levels) in execute'
/var/www/discourse/app/models/email_log.rb:35:in `block in unique_email_per_post'
/var/www/discourse/lib/distributed_mutex.rb:33:in `block in synchronize'
/var/www/discourse/lib/distributed_mutex.rb:29:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:29:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:14:in `synchronize'
/var/www/discourse/app/models/email_log.rb:31:in `unique_email_per_post'
/var/www/discourse/app/jobs/regular/notify_mailing_list_subscribers.rb:89:in `block in execute'
activerecord-6.0.1/lib/active_record/relation/batches.rb:70:in `block (2 levels) in find_each'
activerecord-6.0.1/lib/active_record/relation/batches.rb:70:in `each'
activerecord-6.0.1/lib/active_record/relation/batches.rb:70:in `block in find_each'
activerecord-6.0.1/lib/active_record/relation/batches.rb:136:in `block in find_in_batches'
activerecord-6.0.1/lib/active_record/relation/batches.rb:238:in `block in in_batches'
activerecord-6.0.1/lib/active_record/relation/batches.rb:222:in `loop'
activerecord-6.0.1/lib/active_record/relation/batches.rb:222:in `in_batches'
activerecord-6.0.1/lib/active_record/relation/batches.rb:135:in `find_in_batches'
activerecord-6.0.1/lib/active_record/relation/batches.rb:69:in `find_each'
/var/www/discourse/app/jobs/regular/notify_mailing_list_subscribers.rb:61:in `execute'
/var/www/discourse/app/jobs/base.rb:232:in `block (2 levels) in perform'
rails_multisite-2.0.7/lib/rails_multisite/connection_management.rb:63:in `with_connection'
/var/www/discourse/app/jobs/base.rb:221:in `block in perform'
/var/www/discourse/app/jobs/base.rb:217:in `each'
/var/www/discourse/app/jobs/base.rb:217:in `perform'
sidekiq-6.0.4/lib/sidekiq/processor.rb:196:in `execute_job'
sidekiq-6.0.4/lib/sidekiq/processor.rb:164:in `block (2 levels) in process'
sidekiq-6.0.4/lib/sidekiq/middleware/chain.rb:138:in `block in invoke'
/var/www/discourse/lib/sidekiq/pausable.rb:138:in `call'
sidekiq-6.0.4/lib/sidekiq/middleware/chain.rb:140:in `block in invoke'
sidekiq-6.0.4/lib/sidekiq/middleware/chain.rb:143:in `invoke'
sidekiq-6.0.4/lib/sidekiq/processor.rb:163:in `block in process'
sidekiq-6.0.4/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch'
sidekiq-6.0.4/lib/sidekiq/job_retry.rb:111:in `local'
sidekiq-6.0.4/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch'
sidekiq-6.0.4/lib/sidekiq.rb:37:in `block in <module:Sidekiq>'
sidekiq-6.0.4/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'
sidekiq-6.0.4/lib/sidekiq/processor.rb:257:in `stats'
sidekiq-6.0.4/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'
sidekiq-6.0.4/lib/sidekiq/job_logger.rb:13:in `call'
sidekiq-6.0.4/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'
sidekiq-6.0.4/lib/sidekiq/job_retry.rb:78:in `global'
sidekiq-6.0.4/lib/sidekiq/processor.rb:124:in `block in dispatch'
sidekiq-6.0.4/lib/sidekiq/logger.rb:10:in `with'
sidekiq-6.0.4/lib/sidekiq/job_logger.rb:33:in `prepare'
sidekiq-6.0.4/lib/sidekiq/processor.rb:123:in `dispatch'
sidekiq-6.0.4/lib/sidekiq/processor.rb:162:in `process'
sidekiq-6.0.4/lib/sidekiq/processor.rb:78:in `process_one'
sidekiq-6.0.4/lib/sidekiq/processor.rb:68:in `run'
sidekiq-6.0.4/lib/sidekiq/util.rb:15:in `watchdog'
sidekiq-6.0.4/lib/sidekiq/util.rb:24:in `block in safe_thread'
メールプロバイダーにお問い合わせください。Discourse には関係ありません。
@codinghorror
メールプロバイダーを変更し、現在は Amazon SES を経由して送信しています。これで数週間解決したように見えました。しかし、Discourse がメーリングリストの購読者への配信の途中で、再びランダムにメール送信を停止し始めています。ログにはエラーはありません。コンテナを再構築しましたが、現時点では問題なく動作しているようです。他にエラーログを確認できる場所はありませんか？
Sidekiq に滞留しているタスクはありますか？
いいえ、残念ながらありません。
ここ数日、私も同様の問題に直面しています。メーリングリストのユーザーにメールが送信されず、Sidekiq に滞留するジョブもなく、同じログエラーが表示されます。再構築を試みましたが、変化は見られません。これは私たちのユーザーにとって非常に深刻な苦痛を引き起こしています。
起こっていることは、再構築後に新しい投稿が受信されると、その投稿は送信されるものの、それ以降の投稿や返信は送信されなくなることです。
ご助力いただけますと幸いです！
Ed
これは私にとって非常にイライラする問題になっています。
今日、Discourse は 15 通のメールを送信しただけで、メーリングリストの購読者への送信を突然停止しました。これはプロバイダーの問題ではありません。すでにプロバイダーを変更済みだからです。また、ログにエラーメッセージは表示されておらず、Sidekiq にも停止したタスクもありません。
これを回避できる唯一の方法は、再構築（rebuild）を行うことだと考えています。
何か特定の時間間隔で再構築を自動的にスケジュールすることは可能でしょうか？そうすれば、少なくとも常に監視する必要がなくなります。
そのためには、cron ジョブを設定することもできます。
一部のユーザーに対して、1 日のメール送信上限に達してはいませんか？メールが無効化されていないでしょうか？（それではリビルドがなぜ機能するかが説明できません。）メモリは十分にありますか？ログに何か記録はありますか？
out of memory は非常に明確なエラーメッセージです。
編集：おっと、別のトピックと混同していました。そのため、マルチサイトに関するこの内容は、すべて事実ではあるものの、ここでは意味をなさないかもしれません。
マルチサイト専用のインスタンスは 4GB の RAM で動作していると確信していますが、その環境には MySQL や Apache、WordPress は含まれていません。(staging + production)*(discourse + wordpress) の構成では、8GB に引き上げるまで苦労しました。これには PostgreSQL、Redis、Traefik、Prometheus、MariaDB のコンテナに加え、WordPress と Discourse がそれぞれ 2 つずつ（マルチサイトではないため、ステージング環境では本番環境とは異なるプラグインを必要とするため）含まれています。
コスト削減が目的で、かつ Discourse サイトのトラフィックが低い場合、各サイトを 5 ドル（1GB）の Droplet 個別に配置するのが最適な選択でしょう。
はい、わかりました 
私は標準の共有 CPU を使用しており、 droplet 上では Discourse サイトを 1 つだけ実行しています。