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?
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?
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!!
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).
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.
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.
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
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.
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:
Email can not be processed: Email::Receiver::NoBodyDetectedError
I tested this by using an empty gmail multipart body for plaintext and html:
I’ve made an update to prevent the error caused by is_bounce?.
There is a site setting for tracking mail logs:
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:
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
/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'
is exploding.
