thoka
(Thomas Kalka)
1
エラーログがこれらのメッセージでいっぱいです。
Job exception: undefined method `is_bounce?’ for nil。
バックトレース:
/var/www/discourse/lib/email/processor.rb:27:in `rescue in process!'
/var/www/discourse/lib/email/processor.rb:16:in `process!'
/var/www/discourse/lib/email/processor.rb:13:in `process!'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:23:in `process_popmail'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:43:in `block (2 levels) in poll_pop3'
net-pop-0.1.2/lib/net/pop.rb:669:in `each'
net-pop-0.1.2/lib/net/pop.rb:669:in `each_mail'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:40:in `block in poll_pop3'
net-pop-0.1.2/lib/net/pop.rb:531:in `start'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:39:in `poll_pop3'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:14:in `execute'
/var/www/discourse/app/jobs/base.rb:249:in `block (2 levels) in perform'
/var/www/discourse/lib/rails_multisite/connection_management.rb:80:in `with_connection'
/var/www/discourse/app/jobs/base.rb:236:in `block in perform'
/var/www/discourse/app/jobs/base.rb:232:in `each'
/var/www/discourse/app/jobs/base.rb:232:in `perform'
/var/www/discourse/app/jobs/base.rb:297:in `perform'
/var/www/discourse/lib/mini_scheduler/manager.rb:122:in `process_queue'
/var/www/discourse/lib/mini_scheduler/manager.rb:70:in `worker_loop'
/var/www/discourse/lib/mini_scheduler/manager.rb:59:in `block (2 levels) in ensure_worker_threads'
discourse/lib/email/processor.rb at 84f590ab83b90d4c6754e247744567f75274fb69 · discourse/discourse · GitHub の @receiver が nil になるのはどのようにして起こるのか疑問に思っています。
「いいね！」 1
thoka
(Thomas Kalka)
2
私の現在の理解では、Email::Processor.process! は mail=nil で Email::Receiver.new を呼び出し、Email::Receiver.EmptyEmailError を発生させ、@receiver が未定義のままになります。
続く rescue 部分では、初期化された @receiver が期待されています。
Email::Processor.initialize は mail==nil で呼び出された際に何らかのエラーを発生させるべきではないでしょうか？
sam
(Sam Saffron)
3
が原因でエラーが発生していると推測します。
次のように変更するプルリクエストで対応できると思います。
@receiver.is_bounce? を @receiver&.is_bounce? に変更すれば、少なくともエラーは handle_bounce に渡されるはずです。
mekentosj
(Alexander Griekspoor)
5
同じ問題が発生しています。https://meta.discourse.org/t/problems-with-email-processing-undefined-method-is-bounce-for-nil-nilclass/259813/2 を参照してください。メールの処理を再度有効にするための回避策や、何かできることはありますか？特定 E メールやユーザーが原因ですか？
更新: はい、これは問題であることが確定しました。@thoka さんの分析のおかげで、何を探すべきかがわかりました。問題はまさに空の E メールです。空の E メールが表示されるまでメッセージが未読のままであることに気づきましたか？
受信トレイから削除すると、処理が再び進むようになります。つまり、次の空の E メールに当たるまでです。
したがって、現時点では空の E メールがシステムを停止させています。少なくとも、ある程度の数を超えると、恒久的に停止するかどうかは多少の当たり外れがあるようです。
現時点では監視する必要があると思いますが、これが修正されれば素晴らしいです。ありがとうございます！
davidb
(David B)
9
@mekentosj さん、この問題について調べています。現在、空のメールがどのように生成されているかご存知ですか？（エラーの修正と合わせて）調査すべき根本原因があるかどうか疑問に思っています。
「いいね！」 1
mekentosj
(Alexander Griekspoor)
10
素晴らしい、調べていただきありがとうございます！これらのメールがどのように送信されるのか、完全にはわかりません。スクリーンショットの例は、誰か（またはそのメールアプリ）が返信する前に本文のコンテンツをすべて削除した返信のように見えます（中国語で返信する人に多く見られるようです。文字コードの問題か、特定の種類のメールアプリかもしれません）。しかし、私たちのセットアップで関連性がある/可能な他の方法としては、誰かが本文なしで添付ファイルのみを送信し、件名のみがある場合、または（まだそうする人もいるようですが）本文なしで、メールの件名全体に質問がある場合が考えられます。
「いいね！」 1
mekentosj
(Alexander Griekspoor)
11
メールを見つけました。ユーザーのメールアドレスが含まれているため、DMでemlファイルを送信します。さらに手がかりがあるかもしれません。
「いいね！」 2
davidb
(David B)
12
ありがとうございます。このメールはサードパーティ（Tencent/中国）によって生成されたようです。メールヘッダーを確認したところ、いくつか異常な点が見つかりました（以下に興味深い部分をハイライトしました）。メール本文は全く含まれていませんが、そのqqメールアドレスに送信されたメールへの自動返信のようです。
X-QQ-MIMEについて簡単に検索したところ、他の多くのサイトでもqq.comアドレスからのメール処理で同様の問題が発生しているようです。
メール本文が含まれていないメールは、サイレントにログに記録し、エラーが発生しないようにすることで、スキップしても安全だと思います。
From: "=?utf-8?B?YWJjYzEwMDQwNTA3?=" <abcc10040507@qq.com>
Subject: =?utf-8?B?6Ieq5Yqo5Zue5aSNOiBGb2N1cyBhbmQgRmxvYXQg?=
=?utf-8?B?d2l0aCBBZ2VuZGEgMTc=?=
Content-Transfer-Encoding: base64
X-QQ-AUTO-REPLY: true
Message-ID: <tencent_2BE587DA387104D27A33C94B@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
「いいね！」 1
mekentosj
(Alexander Griekspoor)
13
なるほど、それは私の感覚を裏付けるもので、やはり主に私たちのコミュニティの中国のユーザーに影響していたということですね。
メール本文が含まれていないメールは、すべてスキップしても安全だと思います。サイレントにログを記録し、エラーが発生しないようにすることができます。
はい、送信者が何も入力していなくても、添付ファイルのみを含むメールをスキップしない限り（私はメールの専門家ではないので、それらはまだ本文を含んでいるかもしれませんが）。
私が言及した、ユーザーが件名のみを入力し、メール本文を空にしたままにするという別のシナリオは、おそらく現在すでにスキップされていますか？もしそうでない場合は、これらの問題を引き起こすメールからそれらを特定する方法を見つける必要があります。
代替案としては、自動生成されたメールを検出するメカニズムによってエラーが発生する前に、X-QQ-AUTO-REPLY: true ヘッダーフィールドが認識されるようにすることです。
さらに、サムが提案したこと（Email::Processor does not expect to be called with mail=nil - #3 by sam
davidb
(David B)
14
メールの件名をbase64デコードしたところ、以下のようになりました。
你好，我是Focus and Flat Agile 17
これは、中国語の文字が送信前にbase64エンコードされているためだと考えられます。これにより、送信者名と件名が文字化けした形式で表示されます。
既存のロジックでこれが処理されていることを期待していますが、pop3からのメール処理時に添付ファイルやメールの件名をどのように処理しているかを確認します。
これは現在のメール処理ロジックによってスキップされると思います。本文にテキストがなく、他のすべてが整っている場合、以下のエラーが発生します。
Email can not be processed: Email::Receiver::NoBodyDetectedError
これは、空のGmailのマルチパート本文（プレーンテキストとHTML）を使用してテストしました。
Content-Type: multipart/alternative; boundary="00000000000042cfbf05faef451e"
--00000000000042cfbf05faef451e
Content-Type: text/plain; charset="UTF-8"
--00000000000042cfbf05faef451e
Content-Type: text/html; charset="UTF-8"
<div dir="ltr"><br></div>
--00000000000042cfbf05faef451e--
「いいね！」 1
mekentosj
(Alexander Griekspoor)
15
ええ、それが私が考えたこと／期待していたことです。
thoka
(Thomas Kalka)
16
私の場合は、pop3のタイムアウトが原因でメールが空になったようです。
Job exception: Net::ReadTimeout
Backtrace
/usr/local/lib/ruby/3.2.0/net/protocol.rb:229:in `rbuf_fill'
/usr/local/lib/ruby/3.2.0/net/protocol.rb:199:in `readuntil'
/usr/local/lib/ruby/3.2.0/net/protocol.rb:377:in `each_message_chunk'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/net-pop-0.1.2/lib/net/pop.rb:958:in `block in retr'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/net-pop-0.1.2/lib/net/pop.rb:1016:in `critical'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/net-pop-0.1.2/lib/net/pop.rb:956:in `retr'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/net-pop-0.1.2/lib/net/pop.rb:810:in `pop'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:41:in `block (2 levels) in poll_pop3'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/net-pop-0.1.2/lib/net/pop.rb:669:in `each'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/net-pop-0.1.2/lib/net/pop.rb:669:in `each_mail'
「いいね！」 1
davidb
(David B)
17
is_bounce? によって引き起こされるエラーを防ぐためにアップデートを行いました。
メールログの追跡にはサイト設定があります。
SiteSetting.log_mail_processing_failures
すべてのメール処理の失敗を /logs に記録します
これが有効になっている場合、空のメールエラーは引き続きメールログに表示されますが、現在のようにジョブが失敗することはありません。参考のためにコミットの詳細をここに追加しました。
「いいね！」 1
ログでこのエラーを確認したのですが、関係ありますか？数日間、POP3からメールを受信できておらず、多くの問題が発生しています。POP3に空のメールがないことを確認しましたが、どのようにすれば解消できますか？最新バージョンにアップグレードしましたが、改善しませんでした。
750194 Email can not be processed: Email::Receiver::EmptyEmailError
/var/www/discourse/lib/email/processor.rb:183:in `log_email_process_failure'
/var/www/discourse/lib/email/processor.rb:29:in `rescue in process!'
/var/www/discourse/lib/email/processor.rb:16:in `process!'
/var/www/discourse/lib/email/processor.rb:13:in `process!'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:23:in `process_popmail'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:43:in `block (2 levels) in poll_pop3'
net-pop-0.1.2/lib/net/pop.rb:669:in `each'
net-pop-0.1.2/lib/net/pop.rb:669:in `each_mail'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:40:in `block in poll_pop3'
net-pop-0.1.2/lib/net/pop.rb:531:in `start'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:39:in `poll_pop3'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:14:in `execute'
/var/www/discourse/app/jobs/base.rb:249:in `block (2 levels) in perform'
rails_multisite-4.0.1/lib/rails_multisite/connection_management.rb:80:in `with_connection'
/var/www/discourse/app/jobs/base.rb:236:in `block in perform'
/var/www/discourse/app/jobs/base.rb:232:in `each'
/var/www/discourse/app/jobs/base.rb:232:in `perform'
/var/www/discourse/app/jobs/base.rb:297:in `perform'
mini_scheduler-0.16.0/lib/mini_scheduler/manager.rb:122:in `process_queue'
mini_scheduler-0.16.0/lib/mini_scheduler/manager.rb:70:in `worker_loop'
mini_scheduler-0.16.0/lib/mini_scheduler/manager.rb:59:in `block (2 levels) in ensure_worker_threads'
nat
(Natalie T)
クローズされました:
19
このトピックは37時間後に自動的に閉じられました。返信はもうできません。
