インストール後、Curlはメールを送信できますが、Discourseはできません。修正を手伝ってくれませんか?

こんにちは!

以下のテキストから <DOT> を . に置き換えてください。新しいユーザーのため、Discourse ではリンクを投稿できません。

新しく作成した Hetzner クラウドコンピュータに Discourse をインストールしました。URL の解決は正常です:forum.thewizardofosc.com

しかし、登録に使用したメールアドレスへのメールが送信されません。ログファイルには Net::ReadTimeout というメッセージが表示されていますが、何か意味があるでしょうか。

telnet は接続できます。telnet mail.thewizardofosc.com 465と入力すると、Connected to thewizardofosc.comという結果が返ります。

また、Curl は正常にメールを送信できます!

以下を入力します:
curl --ssl smtps://mail.thewizardofosc.com --mail-from discourse@thewizardofosc.com --mail-rcpt <VARIOUS WORKED> --upload-file email.txt --user 'discourse@thewizardofosc.com:<PASSWORD>'

これは正常に送信されます。

では、なぜ Discourse は送信できないのでしょうか?

以下は、私の app ファイルから抽出した関連するセクションだと思います:

## 初期登録時の例 'user1@example.com,user2@example.com'
DISCOURSE_DEVELOPER_EMAILS: 'iliasb@thewizardofosc.com'

## TODO: 新しいアカウントの認証や通知送信に使用する SMTP メールサーバー
# SMTP アドレス、ユーザー名、パスワードは必須です
# 警告:SMTP パスワードに '#' 文字が含まれていると問題が発生する可能性があります!
DISCOURSE_SMTP_ADDRESS: mail.thewizardofosc.com
DISCOURSE_SMTP_PORT: 465
DISCOURSE_SMTP_USER_NAME: discourse@thewizardofosc.com
DISCOURSE_SMTP_PASSWORD: <PASSWORD>
#DISCOURSE_SMTP_ENABLE_START_TLS: true           # (オプション、デフォルトは true)

## Lets Encrypt テンプレートを追加した場合は、以下をコメントアウトして無料の SSL 証明書を取得してください
LETSENCRYPT_ACCOUNT_EMAIL: me@example.com

メール設定で何が起きているかを確認するには、エラーログを見る必要があります。

以下の手順を試しましたが、あまり成果がありませんでした:Troubleshoot email on a new Discourse install - #2

discourse-doctor を実行すると、Net::ReadTimeout という同じエラーが表示されます。これは shared/standalone/log/rails/production.log にも記録されています。

こんにちは!

共有/スタンドアロン/log/rails/production.log のことをおっしゃっていますか?

そこには以下が表示されています:

メール配信完了 5208d56b-b84b-4de6-a13e-76b60179af46@forum.thewizardofosc.com (60142.6ms)
ジョブ例外: Net::ReadTimeout

奇妙ですね。コンテナの外から接続できるなら、コンテナ内でもその curl コマンドが機能するか確認してみてください。私の推測では、Docker に何らかのネットワーク問題があるのかもしれません。

Jay の指摘は正しいです。

論理的な次のステップとして、@onar3d さんには、コンテナ内から curl テストを試してみてください。

確認したところ、コンテナ内にはすでに curl がインストールされているようなので、少なくともインストールの手間は不要です。

docker exec -it app bash
root@hostname-app/# curl --version
curl 7.64.0 (x86_64-pc-linux-gnu) libcurl/7.64.0 OpenSSL/1.1.1d zlib/1.2.11 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.5) libssh2/1.8.0 nghttp2/1.36.0 librtmp/2.3
Release-Date: 2019-02-06
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp 
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL 

お役に立てれば幸いです。

面白い提案ですね!

ただ、私は「docker exec -it DOCKERID bash」で Docker に入り、同じ curl コマンドを実行しましたが、それも成功しました。

ありがとうございます。試してみましたが、問題なく動作しました!

つまり、Docker がブロックされているわけではないですね…

@onar3d さん、こんにちは

これは少し遠回しな提案ですが、ポート 587 ではなくポート 465 を使用されているようなので、コンテナの yml ファイルで以下を試してみてください。

DISCOURSE_SMTP_ENABLE_START_TLS: false

その後、コンテナを再構築して、うまくいくか試してみてください :slight_smile:

参考:

GMail(比較のために)が公開しているポートと認証方法は以下の通りです。

  • TLS/STARTTLS(明示的 TLSとも呼ばれる): ポート 587 を使用
  • SSL(暗黙的 TLSとも呼ばれる): ポート 465 を使用

… これに賭けてみましょう… :slight_smile: うまくいくかもしれません

もしダメでも、いつでも元に戻すことができます。

「いいね!」 1

ありがとうございます!

今すぐ試してみましたが、Discourseからメールが送信されませんでした :confused:

そうですね、これは無理な注文でしたね……お時間を無駄にしてしまい申し訳ありません!

今のところ私が思いつくもう一つの「突飛なアイデア」は、お使いのメールサーバー(どのサービスかは問いません)にログインし、ポートを 587 に設定することです(多くの SMTP プロバイダーでは選択可能です)。もちろん、その上で DISCOURSE_SMTP_ENABLE_START_TLS: true を再度試して「運試し」をしてみるというものです。

正直なところ、私は普段は「運試し」をするタイプではなく、事実に基づいて判断する方です。もし試したくないようでしたら、@onar3d さん、その気持ちも十分に理解できます!

ありがとうございます!残念ながら、その設定を変更する権限がありません。これはプロバイダーによって用意された「ターンキー」型のものの一つなのです。

@onar3d さん、こんにちは。

承知いたしました。現時点では「奇抜なアイデア」が尽きてしまい、今夜はここで一旦引き上げる時間になりました。幸運を祈ります。きっと、ここにいる優秀なチームメンバーの誰かが、より良いアイデアを持ってくれるはずです。

よろしくお願いいたします。

いくつかの試行の後(@IAmGav さん、本当にありがとうございました)、Discourse のセットアップが別のメールサーバーと正常に動作することが確認され、試すべき候補がいくつか絞り込まれました。

メールサーバープロバイダーから、彼ら側のエラーログメッセージと提案が届きました:

エンジニアがログを確認したところ、IP からのエラーは SSL 設定に関連していました。おそらく、古いバージョンまたは接続設定を使用しているのでしょう。

証拠:
[95.216.139.49]:33568 からの接続で TLS エラーが発生。SSL_accept: TCP 接続がピアによって閉じられました。

SSL モードをオフにして、動作するか確認してみてください。

上記に従って、DISCOURSE_SMTP_ENABLE_START_TLS を false に設定し、ポート 465 およびプロバイダーが非 SSL 接続用として指定しているポート 26 でも試しましたが、どちらも動作しませんでした。

thewizardofosc.com ドメインに SSL 証明書を購入していないことが原因なのでしょうか?少し調べてみて、今になって気づきました。

非 SSL オプションで動作しない場合、有料 SSL でも動作しません。メールホストから Let’s Encrypt の無料 SSL が提供されるはずです。

@onar3d さん

思い付きですが、curl テストを詳細オプション -v を有効にして実行し、正常なハンドシェイクを完全に分析してから、その分析結果から逆算して検討されることをお勧めします。

この詳細オプションを使って、何が機能するかをリバースエンジニアリングしてみてください :slight_smile:

参考になれば幸いです。