最近、多くのアップデートがありました。1つのアップデートで件名（カテゴリが含まれなくなった）が壊れ、現在メールが一切送信されなくなっています。ユーザーは非常に不満を持っています。この問題のデバッグをどこから始めたらよいかわかりません。エラーログはどこにあり、Sidekiqキューなどに関するページがあったことを覚えているのですが、見つけられません。どんな助けでも大変ありがたいです。
はい、昨日アップデートした後、メール通知が発火していないようです。ただし、ダイジェスト/要約はまだ機能しています。私たちだけでしょうか？
「いいね！」 2
これは、sidekiq がスケジュールされたジョブを処理すべきときに処理できていないことが原因である可能性があります。
本日、当社の CD サイトでも同じ問題を確認しました。少なくとも以下のコミットにいることを確認してください。
（コミットはこれだと思いますが、100%確実ではありません）
問題が同じかどうかを確認するには、/sidekiq でスケジュールされたジョブを確認し、過去のジョブがないかどうかを確認してください。
「いいね！」 3
ええ、私たちはそれに巻き込まれました。アップデートで修正されました。
「いいね！」 2
4件の投稿が新しいトピックに分割されました: Email From: ヘッダーから「via SITENAME」テキストが失われた
latest-release +103で数百件の sidekiq ジョブの失敗を確認しました。
latest-release +153で修正されました。
最新版にアップデートしましたが、サイトの1つでメール送信の問題がまだ発生しています。テストメールを送信するとエラーメッセージが表示されるだけです。
ERROR - end of file reached
現在モバイルなので、コンピューターに戻ったらSidekiqとログを確認します。他に確認すべき点はありますか？
トビアスさん、こんにちは！
あなたの問題は異なります。接続は初期の接続成功直後に応答を待ってハングアップしています。
間違ったポートに対して間違ったプロトコルで通信しようとしているのではないでしょうか… どのような設定を使用していますか？
最近更新されたロジックとエラーメッセージを持つ rake emails:test タスクでは、何か異なるエラーが表示されますか？
マイケルさん、こんにちは！お返事ありがとうございます。皆さんにとても会いたいです！
うーん… サイトをDOからHetznerに移行したばかりで、数週間は問題なく動作していました。もう一つのサイトも正常に動作しています。謎ですね。約1週間前に動作しなくなり、確認したところエラーが見つかりました。Hetzner（支援を拒否されました）とMailgunに連絡しました。Mailgunによると：
ご返信ありがとうございます。最後に認証されたイベントが確認されたのは1月11日で、SMTP経由で送信されました。
何か変更が加えられたか確認していただけますか？送信アプリケーションの設定画面のスクリーンショットと、送信アプリケーション/SMTP送信ログの関連するエラーをご提供ください。
念のためMailgunのパスワードを変更して再試行しましたが、だめでした。
rake emails:test の出力：
root@ubuntu-4gb-nbg1-1-app:/var/www/discourse# rake emails:test
smtp.mailgun.org:587、ユーザー名:postmaster@domain、プレーン認証を使用して送信をテストしています。
====================================================================================== エラー =======================================================================================
不明なエラー！
EOFError: end of file reached
===================================================================================== 解決策 =====================================================================================
これは一般的なエラーではありません。推奨される解決策はありません！
上記の正確なエラーメッセージを https://meta.discourse.org/ に報告してください。
（そして、もし見つけたら解決策も！）
====================================================================================================================================================================================
「いいね！」 1
ログインを試みる前に失敗していると思われます。
Discourse を要因から除外するために、ホストからとコンテナ内からの両方で以下を試してください。
$ openssl s_client -connect smtp.mailgun.org:587 -starttls smtp
多くの出力が表示され、その後認証を試みることができるはずです。
○ → openssl s_client -connect smtp.mailgun.org:587 -starttls smtp
Connecting to 34.160.63.108
CONNECTED(00000003)
…
SSL-Session:
…
---
read R BLOCK
EHLO localhost
250-2ed1d46f4d7dec773e2a97b59f3a3bf8a2d6db54f94eead5dcf49e3ea1caac18
250-AUTH PLAIN LOGIN
250-SIZE 52428800
250-8BITMIME
250-SMTPUTF8
250 PIPELINING
AUTH PLAIN bWljaGFlbABtaWNoYWVsAHBhc3N3b3Jk
501 Username used for auth is not valid email address
535 Authentication failed
closed
入力する文字列は次のとおりです。
EHLO localhost
AUTH PLAIN bWljaGFlbABtaWNoYWVsAHBhc3N3b3Jk
（その文字列は認証情報 michael/password なので、当然機能しませんが、実際の認証情報のための文字列の構築方法についてはこちらの投稿を参照して、手動で試すことができます）
何が機能し、何が失敗するかを直接見ることで、問題解決に役立つことを願っています。
また、利用可能であれば swaks を試すことも検討してください。これはおそらくインストールできる OS パッケージです。
これはもう少し簡単で、例えば次のように実行できます。
swaks --to frodo@shire.net --from bilbo@shire.net --auth PLAIN --auth-user bilbo --auth-password ring --server smtp.mailgun.org:587 --tls
ただし、実際の認証情報を使用できます。
その出力も問題の特定に役立つかもしれません。
swaksを試したところ、以下のような結果になりました。
=== Trying smtp.mailgun.org:587...
=== Connected to smtp.mailgun.org.
*** Remote host closed connection unexpectedly.
これに触発されて、別のサーバーから確認したところ、swaksは「Great success」と表示されました。このメッセージはかなり可愛らしいです！
<~ 250 Great success
~> QUIT
<~ 221 See you later. Yours truly, Mailgun
=== Connection closed with remote host.
したがって、問題はMailgunが私のサーバーをブロックしているか、私のサーバーが何らかの形で設定ミスをしているかのどちらかです。Mailgunに確認し、それで解決しない場合は、サーバーを破棄して再構築するつもりです。
「いいね！」 1
その通りです。これは、実質的に次のエラーと同じです。
ご推察の通り、最も可能性の高い原因は、接続に干渉している何らかの外部要因です。
「いいね！」 1
2525ポートを使う必要があるのではないかと疑っています。587ではなく。
Hetzner は、ポート 587 をブロックしていないと明示的に述べています。
また、もしブロックしていたとしても、接続確立に失敗したとして表示されるでしょう。
これで Discourse と Mailgun の設定の可能性はほぼ除外されました。
この時点で最も役立つ診断は、影響を受けているサーバーから別の Mailgun 投稿ポートを試すことです。
openssl s_client -connect smtp.mailgun.org:2525 -starttls smtp
(または swaks で同じテストを行います)。
Mailgun は、ファイアウォール、送信フィルタリング、またはプロバイダーレベルのネットワークルールによって 587 が妨害される環境向けに 2525 を特にサポートしています。
もし：
- 2525 は機能し、587 は機能しない → ネットワーク/IP/ルーティングの干渉の可能性が非常に高い
- 両方とも失敗する → 外部から接続がブロックまたは終了されていることを示す、より強力な根拠となる
いずれにしても、この動作は Discourse や Sidekiq のリグレッションよりも「外部接続の干渉」とより密接に一致しています。
まだMailgunからの返信がありません。彼らが助けてくれない場合の私の計画は、新しいHetznerサーバーで最初からやり直すことです。
他のポートでswaksを試しましたが、興味深いことに、2525でも同じエラーが即座に、遅延なく発生しました。
=== smtp.mailgun.org:2525に接続中...
=== smtp.mailgun.orgに接続しました。
*** リモートホストが予期せず接続を閉じました。
しかし、25と465では異なるエラーが発生し、応答が来るまでに数秒かかりました。
=== smtp.mailgun.org:25に接続中...
*** smtp.mailgun.org:25への接続エラー:
*** 接続がタイムアウトしました
=== smtp.mailgun.org:465に接続中...
*** smtp.mailgun.org:465への接続エラー:
*** 接続がタイムアウトしました
その意味するところはよくわかりません。サーバー上のファイアウォールが一部のポートをブロックするように誤設定されているのかもしれません。
それは意図的であり、想定された動作です。
Hetznerはデフォルトでそれらのポートをブロックします。
「いいね！」 1
なるほど…しかし、ポート25と465が他のポートよりもフェイルするのに時間がかかったのは興味深いですね。いずれにせよ、これは緊急ではないので、Mailgunからの返答を待ちます。これは私の家族のサイト用なので、メールを待つだけでなく、皆にログインして通知を確認するように促しています！
明日、家族のお見舞いと葬儀のためにドイツへ向かいます。来週、もう一度これを確認し、おそらく新しいサーバーで最初からやり直すことになるでしょう。
ご指導ありがとうございました！このプロセスを通じて多くを学びました。swaksツールは本当に気に入りました。
タイミングは確かに役立つ情報です。
ポート（より一般的にはトラフィック）がブロックされる場合、それはドロップ（サイレントリジェクト）によってブロックされるか、リジェクト（「到達不能」メッセージ（例：ポート到達不能）が送信元に返送される）によってブロックされる可能性があります。
サイレントドロップは、25/465で確認される現象です。接続試行が行われますが、タイムアウトに達するまで何も起こりません。
リジェクトは、「接続が拒否されました」や「ポート到達不能」などのメッセージを引き起こします。
それは意図された動作を示しています。接続は確立されますが、すぐに切断されています。
送信元を変更したので、次に試せるのは宛先を変更することです。同じコマンドを、例えば smtp.gmail.com や smtp.office365.com に対して試してみてください。認証エラーになるはずであり、それがMailgunがあなたを特定して拒否している強い証拠となります。
「いいね！」 1
@supermathie の説明は的確です 
タイミングの違いはノイズではなく、実際には有用なシグナルです。
現在見えていることを要約すると次のようになります。
- 25/465 がタイムアウト → サイレントドロップ（Hetzner のポリシーレベルでのブロック、想定内）
- 2525 が接続後すぐに切断 → TCP パスは問題ないが、リモート側がセッションを終了させている
この最後の点が重要な詳細です。
なぜなら：
- TCP ハンドシェイクは成功する
- TLS ネゴシエーションは実際には始まらない
- そして即座に発生する
…これは、Discourse、Sidekiq、Ruby ではなく、Mailgun が接続を早期に拒否していることを強く示唆しています。
これは、最近確認されたいくつかの事柄と一致します。
- IP の評判/地域ベースのフィルタリング
- まだ信頼されていない新しい Hetzner の IP 範囲
- または SMTP バナー交換前の Mailgun 側のポリシーチェック
Discourse 内の何かが、即座にリモートソケットを閉じるようなことを引き起こすことはありません。Sidekiq はメッセージを Net::SMTP に渡して待機するだけです。
後でさらに強力な確認が必要な場合は（全く急ぐ必要はありません）：
openssl s_client -connect smtp.gmail.com:587 -starttls smtp
適切な SMTP バナーが表示され、その後認証エラーになるはずです。これは、送信 SMTP 自体は問題なく、Mailgun だけが異なる動作をしていることをほぼ証明します。
そして、特に現在の状況を考えると、一時停止することについては完全に理解しています。
他のすべてのことに加えて、それに対処していることをお見舞い申し上げます 
Mailgun から何か有用な情報が得られれば良いのですが、正直なところ、SMTP の評判修正を待つよりも、新規開始またはプロバイダーの切り替え（Brevo、Postmark など）の方が速いことが多いです。
あなたはすでにこれを完全に正しい方法でデバッグしています。ここで何かを見落としたり、Discourse を誤って設定したりしたことを示すものは何もありません。
ドイツへの安全なご旅行と、お体を大切にしてください。
「いいね！」 1