これは、管理者が Discourse サイトからの送信メールのトラブルシューティングを行う方法を説明する #解説 ガイドです。
必要なユーザーレベル：管理者
Discourse は、ユーザー通知やアカウント管理タスクにおいてメールに大きく依存しています。ユーザーが Discourse サイトからのメールを受信できない場合、通知の見落としやアカウント管理の問題など、さまざまな問題が発生する可能性があります。
まとめ
このドキュメントでは、以下の内容について学びます。
- 送信メールログの確認方法
- スキップされたメールとバウンスしたメールの調査方法
- メール配信問題の一般的なトラブルシューティング手順
- 主要な設定とその場所
送信メールの確認
メール問題のトラブルシューティングを行う最初の場所は、サイト内の Admin → Emails → Sent ページ（.../admin/email/sent に位置）です。Discourse の Emails → Sent ページは、管理者がフォーラムのメール機能を監視し、トラブルシューティングを行うための貴重なリソースです。このページには、Discourse インスタンスから正常に送信されたすべてのメールの詳細なログが表示されます。
このページで確認できる送信メールに関する情報は以下の通りです。
- Sent At（送信日時）: メールが送信されてからの経過時間。
- User（ユーザー）: メールを受信したユーザー。
- To Address（宛先アドレス）: 受信者のメールアドレス。
- Email Type（メールの種類）: 送信されたメールの種類。ダイジェスト、メーリングリスト、ユーザー投稿、ユーザーのプライベートメッセージなど。
- Reply Key（返信キー）: 送信された各メールの一意の識別子。このキーにより、ユーザーが通知メールに返信した際、Discourse はその返信を適切な投稿とユーザーに正しく紐付けることができ、ユーザーはメールから直接フォーラムの議論に参加できます。
- Post（投稿）: メールが生成された投稿の ID。この ID をクリックすると、フォーラム内の実際の投稿に移動します。
- SMTP Details（SMTP 詳細）: このフィールドは、メール送信を試みた後に SMTP サーバーから受け取ったレスポンスを示します。
250 2.0.0のレスポンスは、メールが最初のメールサーバー（送信中継サーバー）によって配信のために受け入れられたことを意味します。
ユーザーが Discourse からのメールを受信しなかったと報告し、Discourse が
Post & SMTP Details下に250 2.0.0 Ok: queued as ...というメッセージを表示している場合、そのユーザーに再度受信トレイとスパムフォルダを確認し、メールを見落としていないか確認してもらうことをお勧めします。このステータスは、メールが最初のメールサーバーによって受け入れられたことを示していますが、最終的な受信トレイへの配信を保証するものではありません。メールは、後続のサーバーによってフィルタリング、遅延、または破棄される可能性があります。また、ユーザーに対して、メールサーバーを管理しているサポートチームや IT 部門に連絡し、メールがキューイングされたと報告された後に何らかの事象が発生していないか確認するよう提案することもできます。送信メールサーバーのログにアクセスできる場合（または Discourse ホスティングインフラを使用している場合）、SMTP 詳細に表示されるキュー ID を使用して、メールが配信チェーンを通過する経路を追跡できます。
メールが Discourse の Emails → Sent ページに表示されない場合、そのメールは Discourse インスタンスから正常に送信されなかったことを意味します。
次に、メールのトラブルシューティングに使用できる他のページを見てみましょう。
スキップされたメールの調査
サイトの .../admin/email/skipped ページにある Skipped Emails ページには、さまざまな理由で Discourse が送信を決定しなかったすべてのメールがリストされています。各スキップされたメールには、メールが送信されなかった理由を示す Skip Reason（スキップ理由）が隣に表示されます。
このページで確認できるスキップされたメールに関する情報は以下の通りです。
- Time（日時）: メールが送信される予定だった、しかしスキップされた日付と時刻。
- User（ユーザー）: メールを受信する予定だったユーザー。
- To Address（宛先アドレス）: 受信者のメールアドレス。
- Email Type（メールの種類）: スキップされたメールの種類。
digest（ダイジェスト）、mailing list（メーリングリスト）、user posted（ユーザー投稿）、user private message（ユーザーのプライベートメッセージ）など。 - Skip Reason（スキップ理由）: メールがスキップされた理由。一般的な理由には、ユーザーがサイトでアクティブである、ユーザーがすでに投稿を読んでいる、またはユーザーがバウンススコア閾値を超えているなどが含まれます。
Exceeded bounce_score_thresholdとは何ですか？
Discourse では、ユーザーのメールアドレス宛てに送信されたメールがバウンスするたびに、そのユーザーの「バウンススコア」が増加します。「バウンススコア」は、特定のアドレス宛てに送信されたメールの配信失敗回数を測定する指標です。
Discourse における Exceeded bounce_score_threshold メッセージは、ユーザーの「バウンススコア」が一定の制限を超えた状況を指し、Discourse からの送信メールのトラブルシューティングが必要な最も一般的な理由の一つです。
バウンスしたメールとは、受信者に配信できずに送信者に返送されたメールのことです。これはさまざまな理由で発生し、発生すると送信者のメールシステムに配信問題に関する通知が届きます。
メールのバウンスには 2 種類あります。
- ハードバウンス: 永続的な配信失敗です。通常、受信者のメールアドレスが無効、または使用されていない場合に発生します。他の理由としては、ドメイン名が存在しない、または受信者のメールサーバーが配信を完全にブロックしているなどが考えられます。
- ソフトバウンス: 一時的な配信問題です。受信者のメールボックスがいっぱいになっている、メールサーバーが一時的にダウンまたは過負荷になっている、またはメールメッセージが大きすぎるなどが原因となります。
bounce_score_thresholdを調整できますか？
はい！こちらを参照してください：Bounce Score Site Settings。
ただし、バウンススコアの設定を調整する前に、メール配信に関する根本的な問題が完全に解決されていることを確認することが重要です。
その点を踏まえて、Discourse においてバウンスしたメールについて確認できる他の情報について議論しましょう。
バウンスしたメールのトラブルシューティング
バウンスしたメールのページは .../admin/email/bounced にあり、すべてのバウンスしたメールの詳細な概要を提供します。このページで確認できるバウンスしたメールに関する情報は以下の通りです。
- Time（日時）: メールがバウンスした日付と時刻。
- User（ユーザー）: メールを受信する予定だったユーザー。
- To Address（宛先アドレス）: 受信者のメールアドレス。
- Email Type（メールの種類）: スキップされたメールの種類。ダイジェスト、メーリングリスト、ユーザー投稿、ユーザーのプライベートメッセージなど。
Bounced ページでは、 (i) アイコンをクリックして、バウンスしたメールに関する追加詳細を表示できます。
Incoming Email Details（受信メール詳細）ウィンドウには、バウンスしたメールに関する詳細情報が含まれており、通常 Body（本文）セクションには、メールがバウンスした理由の説明が記載されています。
Discourse からのメールがバウンスする理由のいくつかを以下に挙げます。
- 無効なメールアドレス: 受信者のメールアドレスが無効、存在しない、または削除されている場合、メールは返送されます。
- メールボックスがいっぱい: 受信者のメールボックスがいっぱいで新しいメッセージを受け入れられない場合、メールは返送されます。
- サーバーの問題: 受信者のメールサーバーがダウンしている、または一時的に利用できない場合、メールは返送されます。これは通常、一時的な問題です。
- 送信者のブロック: 受信者のメールサーバーが Discourse のメールアドレスをブロックしているか、特定のドメインからのみ受信メールを許可している場合があります（通常はメールセキュリティポリシーによるものです）。
- 過剰なスパムフィルター: メールコンテンツが受信者のメールサーバーによってスパムとしてフラグ付けされた場合、メールは返送されることがあります。
- 自動返信: 一部の自動返信システム（不在着信など）は、ソフトバウンスの原因となることがあります。
この状況では、メールがバウンスしているユーザーにメールサービスプロバイダーに連絡することが最善の選択肢です。メールサービスプロバイダーは、メールがブロックまたは拒否されている理由について具体的な洞察を提供でき、セキュリティ設定を調整したり、Discourse メールサービスをホワイトリストに登録したりできる可能性があります。また、進行中のメールサーバーメンテナンスや、メールがバウンスする原因となる他の問題について認識している場合もあります。
ユーザーがメールサービスを管理しており、Microsoft Hosted Exchange または Google Workspace を使用している場合は、Microsoft Hosted Exchange での CDCK ホストサイトからのメールのスパム回避 および Google Workspace での Discourse ホストサイトからのメールのスパム回避 に関する手順も用意されています。
ユーザーのバウンススコアのリセット が必要か、または問題が複数のユーザーに影響していた場合は、すべてのユーザーのバウンススコアの一括リセット を行う必要があります。バウンススコアがリセットされると、Discourse は bounce_score_threshold を超えていたユーザーへのメール配信を再開します。
追加の手順
メールの設定とトラブルシューティングは、関与する変数が多いため複雑になることがあります。サイトの Admin → Email セクションを確認してメールのトラブルシューティングを行うことに加えて、Discourse サイトからのメールが正しく配信されていない理由が依然として不明な場合は、メール配信設定チェックリスト を確認することをお勧めします。
Discourse サイトを最近セットアップした場合は、新しい Discourse インストールでのメールのトラブルシューティング（自己ホストインストールのみ）に関するガイドも用意されています。
最後に、Admin → Logs（.../logs/）に移動して、メール配信に関連するエラーがないか確認する Discourse ログページを確認することもできます。
