セルフホストのメール返信が最新アップデート後に動作しなくなりました

サポート
1

メールで送信された返信が、フォーラムに反映されなくなりました。

以前はメール返信機能が正常に動作していましたが、9 月 29 日頃以降、この機能が停止したようです。

フォーラムの活動頻度が低いため、この時期を特定する決定的な証拠はありませんが、現在は明らかに機能しておらず、フォーラムのログにも 9 月 29 日以降の受信メッセージが記録されていません。

拒否されたメールのログにも、最新の記録が 9 月 29 日となっています。拒否されたすべてのメッセージは、使い捨てのアドレスからのもので、スパムと思われる内容でした。したがって、この部分は正常に動作しているようです。

弾き返されたメールのログは空で、「ログが見つかりません」と表示されています。

ログインユーザーの活動によって生成されたフォーラムからのメッセージ（私自身も受信しています）は、まだ正常に送信されています。ただし、上記の理由により、活動レベルは通常よりもさらに低下しています。アクティブなユーザーのほとんどは、ブラウザベースのやり取りよりもメールを好んでいます。

私の Microsoft ホスト型メールアドレスまたは Gmail アドレスのどちらから送信された、フォーラム投稿の通知メールに対するテスト返信も、配信失敗の警告は受け取っていません。それらはただ跡形もなく消えてしまいます。フォーラムのメールログにも何も記録されていません。

フォーラムのエラーログには、9 月 29 日付でいくつかの警告（黄色い感嘆符アイコン）が表示されています。「Email can not be processed: Email::Receiver::BadDestinationAddress Received…」という内容ですが、これは無害なものであり、以前に記録された同様のイベントと変わりません。単にスパムが拒否されただけだと推測されます。

10 月 1 日には、実際に以下のエラーがログに記録されています。

Message

ActionDispatch::Http::MimeNegotiation::InvalidType (“%{#context[‘com.opensymphony.xwork2.dispatcher.httpservletresponse’].addheader(‘cbu0psig’” is not a valid MIME type)
lib/middleware/omniauth_bypass_middleware.rb:71:in call' lib/content_security_policy/middleware.rb:12:in call’
lib/middleware/anonymous_cache.rb:353:in call' config/initializers/100-quiet_logger.rb:23:in call’
config/initializers/100-silence_logger.rb:31:in call' lib/middleware/enforce_hostname.rb:23:in call’
lib/middleware/request_tracker.rb:187:in `call’

Backtrace

actionpack (6.1.4.1) lib/action_dispatch/http/mime_negotiation.rb:31:in rescue in block in content_mime_type' actionpack (6.1.4.1) lib/action_dispatch/http/mime_negotiation.rb:24:in block in content_mime_type’
rack (2.2.3) lib/rack/request.rb:69:in fetch' rack (2.2.3) lib/rack/request.rb:69:in fetch_header’
actionpack (6.1.4.1) lib/action_dispatch/http/mime_negotiation.rb:23:in content_mime_type' actionpack (6.1.4.1) lib/action_dispatch/http/request.rb:269:in media_type’
actionpack (6.1.4.1) lib/action_dispatch/http/request.rb:355:in form_data?' rack (2.2.3) lib/rack/request.rb:445:in POST’
actionpack (6.1.4.1) lib/action_dispatch/http/request.rb:400:in block (2 levels) in POST' actionpack (6.1.4.1) lib/action_dispatch/http/parameters.rb:88:in parse_formatted_parameters’

Env

HTTP HOSTS: nzarchitecture.net.nz

これが関連するかどうかはわかりませんが、それ以降、ログにそれ以上のエラーや致命的なエラー（薄赤または濃赤の×アイコンで示される）は表示されていません。

www.mail-tester.com でテストしたところ、私のメールアドレスのいずれもスパム扱いやブラックリスト入りしているわけではなく、これらのアドレスからの人間との通信に問題も発生していません。

フォーラムは Mailgun を使用していますが、これは bulk メール送信のみに使用されていると推測されます。したがって、Mailgun アカウントや API キーに問題があっても、受信メッセージには影響しないはずです。実際、Mailgun アカウントにログインしても、Mailgun に関連する明らかな問題やエラーメッセージは見つかりませんでした。

フォーラムが正常にメールを送信できているのであれば、Mailgun の API キーは問題ないと考えられます。

メール返信機能が動作していた以降、フォーラムの設定は変更されておらず、「メールで返信する」設定のチェックボックスもまだオンになっています。

フォーラムは Digital Ocean でホストされています。ドメインの DNS 設定は Digital Ocean の設定で変更されておらず、フォーラムの MX レコードも正常で変更されていません。

問題が発生して以降、フォーラムは 2.8.0 beta 7 に更新されました（その過程で再構築が行われたと思われますが）、改善は見られませんでした。

何が不足しているのでしょうか？
何が原因で問題が起きた可能性が高いでしょうか？
メール返信機能を再び動作させるにはどうすればよいでしょうか？

「いいね！」 1
2

そのエラーは関連していないようです。

一般的に、「メール受信」のテストは「メール返信」のテストよりも容易です。「手動ポーリング有効化」と「メール受信」の設定を確認し、スタッフカテゴリにメールアドレスを追加して、フォーラムの管理者ユーザーアカウントと同じメールアドレスからそのアドレスへメールを送信できるか試してください。

その後、[管理] - [メール] - [跳ね返り / 受信 / 拒否] を確認して、何が起きているかを確認してください。

「メール返信アドレス」は正しく設定されていますか？

「いいね！」 5
3

こんにちは、リチャードさん、ありがとうございます。

「手動ポーリング有効化」と「メール受信」の設定がまだ有効になっていることを確認しました。

Gmail アドレスをスタッフカテゴリのカスタムアドレスとして追加しましたが、フォーラムを通じてスタッフにメッセージを送信する方法が見つかりません。「お問い合わせ」リンクはすべてフォーラム設定のテキストで mailto: リンクとして設定されており、単に私の個人的な普段使っているメールアドレスへ向かうようになっています。それらのリンクをクリックすると、メールアプリケーションが私の個人的な直接メールアドレスで事前入力された状態で開くため、フォーラム側でメッセージを受け取ることができません。

4

いいえ、カテゴリ設定で staff@nzarchitecture.net.nz のようなアドレスを設定し、その後、Gmail からそのアドレスにメッセージを送信してください。

5

ああ、わかりました。

まさにこれを試してみたのですが、バウンス/受信/拒否のログには何も表示されません。

6

メールサーバーは Digital Ocean に設定されています。

image
image745×151 10.5 KB

Digital Ocean でメールサーバーを利用されていますか？

7

それはメール受信機を実行しているドロプレットの IP アドレスです。

nzarchitecture.net.nz. 2727 IN A 159.65.140.176

8

過去 5 ヶ月で変更されました

image
image1123×176 3.28 KB

9

何が起きているか分かります。またあの@#(($* LetsEncryptの問題で、9月30日にインターネットの半分多くのものが壊れました。

単にメール受信用のDockerを再構築してください。

「いいね！」 6
10

ははははは、そうだったね。それを忘れてたわ。LOL

「いいね！」 3
12

@RGJ が投稿したトピックをフォローする必要があります。

これで問題が解決するはずです。

「いいね！」 4
13

ああ、わかりました。それなら有望ですね！
「メール受信コンテナの Docker」を再構築するにはどうすればよいのでしょうか？これは、ダッシュボードからフォーラムを更新する際に行われる「Docker マネージャー」の再構築とは異なるのでしょうか？

この手順に従えばよいのでしょうか？Discourse と Docker イメージを最新バージョンに手動で更新するには？ - 使い方 / 管理者 - Discourse Meta

14

サイトのコマンドライン側にログインする必要があります。

フォーラムの管理ダッシュボードからは行えません。

15

こんにちは、そのリンクの指示に従ってメール受信用 Docker を再構築できました。

Direct-delivery incoming email for self-hosted sites - howto / sysadmin - Discourse Meta

再構築を行うために、Digital Ocean の droplet をアップグレード（リサイズ）する必要がありました。ホスト上に保存されているすべてのバックアップなどを削除しても、再構築を行うのに十分なディスク容量がなかったためです。

再構築後、staff@nzarchitecture.net.nz にメッセージを送信することができました。今回はフォーラムのログがそれを認識しました。
ただし、通知を受け取った既存のトピックに対してメールで返信を試みると、受信メッセージは認識されるものの、フォーラム上には表示されず、すべてメールログで「メール配信失敗」の警告が発生します。

受信メッセージは「バウンスメールログ」には表示されませんが、「拒否されたメールログ」にはすべて [Email::Receiver::BadDestinationAddress] という警告と共に表示されています。これは、私の管理者アカウントを含めてです。私のメールアドレスが急に宛先アドレスとして無効になることはあり得ないはずですが。

16

最近、メール受信機能を再構築しましたか？

「いいね！」 3
17

はい、約30分前にその作業を行い、上記の投稿が作成されました。
さっき改めて完全なビルドを実行しましたが（木を叩いてお祈りします）、どうやら再び正常に動作しているようです。

「いいね！」 1
18

HTTPS 強制設定がなされていなかった可能性があり、再構築によってそれが修正されたのかもしれません。

「いいね！」 1
19

実際、ダッシュボードでまさにその内容に関する警告に気づき、すぐに提供された便利なリンクをクリックして適切な設定へ移動し、チェックボックスにチェックを入れました。

強制 HTTPS が受信メールの受け取りに必須であるとは、これまで気づいていませんでした。

強制 HTTPS が施されていないことが、Facebook ログインの使用にも問題を引き起こしている可能性があります。最近、Facebook から当サイトが利用規約に違反しているとして停止されたと通知されました。Facebook のアプリ開発者コントロールパネルには具体的な対応項目が表示されていなかったため、異議申し立てを行いました。その結果、当サイトの URL で発生した特定の不明なエラーにより、サイトを検証できないとの回答が返ってきました。

「いいね！」 1
20

「HTTPS を強制」オプションをオンにしても、Facebook ログインの問題は全く解決していないようです。Facebook のテクニカルサポートは、サイトのランディングページで「接続はプライベートではありません NET::ERR_CERT_COMMON_NAME_INVALID」というセキュリティ警告が表示されると報告しています。

エラーページによると、証明書の発行元は「R3」と表示されており、グーグル検索によるとこれは Let’s Encrypt に関連しています。Let’s Encrypt の証明書有効期限切れが、Discourse インストールの再構築を必要としたのと同じ発行元です。

これは偶然でしょうか？これは最新の Discourse ビルド（2.8.0 beta 7）にまだ証明書の問題があることを示唆しているのでしょうか？それとも、ホスティングや Digital Ocean に関する無関係な問題なのでしょうか？

21

自分自身の杜撰な Google 検索の結果、https://www.whynopadlock.com/ を使って自分の URL をテストすることができ、その結果から Let’s Encrypt ユーザーによるこの 投稿 へとたどり着きました。

Let’s Encrypt は最近、中間証明書を「Let’s Encrypt Authority X3」から「R3」に更新しました。

適切に動作する ACME クライアントを使用している場合、前回の更新時に自動的に新しい中間証明書が使用されるはずです。違いに気づくことはないでしょう。

あなたのケースでは、おそらく中間証明書をハードコーディングしているのでしょう。もしそうであれば、新しい中間証明書を使用する必要があります。それは Chains of Trust - Let's Encrypt で確認できます：https://letsencrypt.org/certs/lets-encrypt-r3-cross-signed.pem

現在の Discourse のバージョンは、もしかして誤って「中間証明書をハードコーディング」しているのでしょうか？

「中間証明書」は、Discourse の管理者が現在管理する必要があるものなのでしょうか？もしそうなら、どのように管理すればよいのでしょうか？

もしこれがトピックから外れているようでしたら、お知らせください。同じ問題の一部なのかどうかわかりません。