### Author:  [@thoka](https://meta.discourse.org/u/thoka)
#### Post date: [March 16, 2023, 9:31pm UTC](https://meta.discourse.org/t/email-processor-does-not-expect-to-be-called-with-mail-nil/258428/1 "2023-03-16T21:31:33Z")
My error-log is full of these messages:
`Job exception: undefined method `is_bounce?’ for nil`.
> **Backtrace:**
>
> ```plaintext
> /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'
> 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.15.0/lib/mini_scheduler/manager.rb:122:in `process_queue'
> mini_scheduler-0.15.0/lib/mini_scheduler/manager.rb:70:in `worker_loop'
> mini_scheduler-0.15.0/lib/mini_scheduler/manager.rb:59:in `block (2 levels) in ensure_worker_threads'
>
> ```
I’m wondering, how `@receiver` could get nil in
>
---
### Author:  [@thoka](https://meta.discourse.org/u/thoka)
#### Post date: [March 19, 2023, 5:36am UTC](https://meta.discourse.org/t/email-processor-does-not-expect-to-be-called-with-mail-nil/258428/2 "2023-03-19T05:36:28Z")
My current understanding is, that `Email::Processor.process!` calls `Email::Receiver.new` with `mail=nil` which raises an `Email::Receiver.EmptyEmailError`, leaving `@receiver` undefined.
The following `rescue` part expects an initialized `@receiver`.
Shouldn’t `Email::Processor.initialize` raise some Error when called with `mail==nil`?
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [March 20, 2023, 5:19am UTC](https://meta.discourse.org/t/email-processor-does-not-expect-to-be-called-with-mail-nil/258428/3 "2023-03-20T05:19:11Z")
> [@thoka](#):
>
> `Email::Receiver.new`
My guess is that somehow ⏫ is exploding.
I think a PR that changes:
`@receiver.is_bounce?` to `@receiver&.is_bounce?` would be fine, at least the error would float into handle\_bounce.
---
### Author:  [@mekentosj](https://meta.discourse.org/u/mekentosj)
#### Post date: [March 29, 2023, 8:20am UTC](https://meta.discourse.org/t/email-processor-does-not-expect-to-be-called-with-mail-nil/258428/5 "2023-03-29T08:20:46Z")
We’re seeing the same issue, see [https://meta.discourse.org/t/problems-with-email-processing-undefined-method-is-bounce-for-nil-nilclass/259813/2](https://meta.discourse.org/t/problems-with-email-processing-undefined-method-is-bounce-for-nil-nilclass/259813/2). Is there any workaround, thing we can do to have email be processed again? Is this caused by a specific email or user?
**Update:** Ok, definitely confirmed that this is the problem. Thanks to @thoka’s analysis I now knew what to look for, the problem is indeed empty emails. Notice how the messages are unread exactly up to the point where an empty email appears?
Deleting it from the inbox makes the processing get unstuck again. That is, until it hit the next email that was blank:
So blank emails currently get the system stuck for us, at least beyond a certain number because it does seem to be a bit of a hit or miss whether it gets permanently stuck or not.
Guess we have to monitor things for now but would be great if this could be fixed indeed. Thanks!!
---
### Author:  [@davidb](https://meta.discourse.org/u/davidb)
#### Post date: [May 4, 2023, 2:54am UTC](https://meta.discourse.org/t/email-processor-does-not-expect-to-be-called-with-mail-nil/258428/9 "2023-05-04T02:54:37Z")
> [@mekentosj](#):
>
> Thanks to thoka’s analysis I now knew what to look for, the problem is indeed empty emails.
Hi @mekentosj, I am looking into this issue. Do you know how the blank emails are being generated currently? I am wondering if there is a root cause that I need to investigate (along with fixing the error).
---
### Author:  [@mekentosj](https://meta.discourse.org/u/mekentosj)
#### Post date: [May 4, 2023, 7:42am UTC](https://meta.discourse.org/t/email-processor-does-not-expect-to-be-called-with-mail-nil/258428/10 "2023-05-04T07:42:15Z")
Great, thank you for looking into this! I’m not entirely sure how they manage to send these emails. The examples in the screenshot seem to be replies where someone (or their email app) just removed all content from the body before they replied (it seems to occur more often with people replying in Chinese, so maybe some character encoding issue or a certain kind of email app). But other ways that I could imagine would be relevant/possible in our setup is someone emails us just an attachment without any body content and only a subject, or (some people seem to do this still), their question entirely in the email subject, with no body content.
---
### Author:  [@mekentosj](https://meta.discourse.org/u/mekentosj)
#### Post date: [May 4, 2023, 7:45am UTC](https://meta.discourse.org/t/email-processor-does-not-expect-to-be-called-with-mail-nil/258428/11 "2023-05-04T07:45:43Z")
Actually, I just found the email, will send the eml file in a DM (as it contains the user’s email address), maybe it contains more clues.
---
### Author:  [@davidb](https://meta.discourse.org/u/davidb)
#### Post date: [May 5, 2023, 7:15am UTC](https://meta.discourse.org/t/email-processor-does-not-expect-to-be-called-with-mail-nil/258428/12 "2023-05-05T07:15:04Z")
> [@mekentosj](#):
>
> I just found the email, will send the eml file in a DM (as it contains the user’s email address)
Thanks, the email appears to be generated by a third party (Tencent/China). I had a look over the email headers and spotted some unusual things (I highlighted the interesting parts below). The email doesn’t contain any body at all, but it does appear to be an automatic reply to an email sent to that qq mailbox.
I had a quick search for `X-QQ-MIME` and it appears a number of other sites are experiencing similar issues processing mail from `qq.com` addresses.
I think it’s safe for us to skip over any mail that doesn’t contain the email body. We can log it silently and prevent the error from being raised.
```plaintext
From: "=?utf-8?B?YWJjYzEwMDQwNTA3?="
Subject: =?utf-8?B?6Ieq5Yqo5Zue5aSNOiBGb2N1cyBhbmQgRmxvYXQg?=
=?utf-8?B?d2l0aCBBZ2VuZGEgMTc=?=
Content-Transfer-Encoding: base64
X-QQ-AUTO-REPLY: true
Message-ID:
X-QQ-MIME: TCMime 1.0 by Tencent
```
---
### Author:  [@mekentosj](https://meta.discourse.org/u/mekentosj)
#### Post date: [May 5, 2023, 7:43am UTC](https://meta.discourse.org/t/email-processor-does-not-expect-to-be-called-with-mail-nil/258428/13 "2023-05-05T07:43:56Z")
Cool, so yes, that confirms my feeling it was indeed affecting mostly Chinese users of our community.
> I think it’s safe for us to skip over any mail that doesn’t contain the email body. We can log it silently and prevent the error from being raised.
Yes, as long as it doesn’t skip emails that only contains attachments even if the sender hasn’t typed anything (I’m not an email expert, so perhaps that still contains a body).
The other scenario I mentioned where the user would only type in the subject but leaves the email empty I guess is currently already skipped? If not, you’d somehow have to identify those from these problem causing emails.
The alternative would be to have the `X-QQ-AUTO-REPLY: true` header field be recognised prior to the error being raised by the mechanism that detects automatically generated emails.
In addition you probably then still want this particular error be resolved by doing what Sam [suggested](https://meta.discourse.org/t/email-processor-does-not-expect-to-be-called-with-mail-nil/258428/3)
---
### Author:  [@davidb](https://meta.discourse.org/u/davidb)
#### Post date: [May 5, 2023, 10:15am UTC](https://meta.discourse.org/t/email-processor-does-not-expect-to-be-called-with-mail-nil/258428/14 "2023-05-05T10:15:16Z")
I base64 decoded the email subject and got:
`你好，我是Focus and Flat Agile 17`
I think this is due to the Chinese characters, they are base64 encoded before sending. This explains the garbled format for sender name and subject.
> [@mekentosj](#):
>
> Yes, as long as it doesn’t skip emails that only contains attachments even if the sender hasn’t typed anything (I’m not an email expert, so perhaps that still contains a body).
I am hoping the existing logic handles this already, but I will check to see how we handle attachments and email subject when processing mail from pop3.
> [@mekentosj](#):
>
> The other scenario I mentioned where the user would only type in the subject but leaves the email empty I guess is currently already skipped?
I think this would be skipped by the current mail processing logic. When there is no text within the body but everything else in place, I get:
```plaintext
Email can not be processed: Email::Receiver::NoBodyDetectedError
```
I tested this by using an empty gmail multipart body for plaintext and html:
```plaintext
Content-Type: multipart/alternative; boundary="00000000000042cfbf05faef451e"
--00000000000042cfbf05faef451e
Content-Type: text/plain; charset="UTF-8"
--00000000000042cfbf05faef451e
Content-Type: text/html; charset="UTF-8"
--00000000000042cfbf05faef451e--
```
---
### Author:  [@mekentosj](https://meta.discourse.org/u/mekentosj)
#### Post date: [May 5, 2023, 1:28pm UTC](https://meta.discourse.org/t/email-processor-does-not-expect-to-be-called-with-mail-nil/258428/15 "2023-05-05T13:28:59Z")
> [@davidb](#):
>
> I am hoping the existing logic handles this already, but I will check to see how we handle attachments and email subject when processing mail from pop3.
👍
> [@](#):
>
> I think this would be skipped by the current mail processing logic. When there is no text within the body but everything else in place, I get:
>
> ```plaintext
> Email can not be processed: Email::Receiver::NoBodyDetectedError
>
> ```
Yeah, that’s what I figured/expected.
---
### Author:  [@thoka](https://meta.discourse.org/u/thoka)
#### Post date: [May 10, 2023, 10:00am UTC](https://meta.discourse.org/t/email-processor-does-not-expect-to-be-called-with-mail-nil/258428/16 "2023-05-10T10:00:33Z")
In my case it seems that a pop3 timeout caused the empty mail:
```plaintext
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'
```
---
### Author:  [@davidb](https://meta.discourse.org/u/davidb)
#### Post date: [May 18, 2023, 4:40am UTC](https://meta.discourse.org/t/email-processor-does-not-expect-to-be-called-with-mail-nil/258428/17 "2023-05-18T04:40:38Z")
I’ve made an update to prevent the error caused by `is_bounce?`.
There is a site setting for tracking mail logs:
```plaintext
SiteSetting.log_mail_processing_failures
Log all email processing failures to /logs
```
If this is enabled, the blank email error will still appear in the mail logs but won’t cause the job to fail like it does currently. I’ve added the commit details here for reference:
[https://github.com/discourse/discourse/commit/1de8361d2e4309df097d33381d885df9cbbd3b93](https://github.com/discourse/discourse/commit/1de8361d2e4309df097d33381d885df9cbbd3b93)
---
### Author:  [@Jose\_C\_Gomez](https://meta.discourse.org/u/Jose_C_Gomez)
#### Post date: [May 19, 2023, 4:08am UTC](https://meta.discourse.org/t/email-processor-does-not-expect-to-be-called-with-mail-nil/258428/18 "2023-05-19T04:08:12Z")
I am seeing this error in the logs, is this related? It appears we haven’t received email from our POP3 in days and it is causing a lot of issues. I checked and I have no empty emails on POP3 how can I get it unstuck? I just upgraded to the latest version did not help.
750194 Email can not be processed: Email::Receiver::EmptyEmailError
```plaintext
/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'
```
---
### Author:  [@nat](https://meta.discourse.org/u/nat)
#### Post date: [May 20, 2023, 12:00am UTC](https://meta.discourse.org/t/email-processor-does-not-expect-to-be-called-with-mail-nil/258428/19 "2023-05-20T00:00:50Z")
This topic was automatically closed after 37 hours. New replies are no longer allowed.