Email::Processor는 mail=nil로 호출되는 것을 예상하지 않습니다

[thoka (Thomas Kalka)]

오류 로그에 이 메시지가 가득합니다:

Job exception: undefined method `is_bounce?’ for nil

Backtrace:

/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' 

discourse/lib/email/processor.rb at 84f590ab83b90d4c6754e247744567f75274fb69 · discourse/discourse · GitHub 에서 @receiver가 어떻게 nil이 될 수 있는지 궁금합니다.

[thoka (Thomas Kalka)]

현재 제 이해에 따르면, Email::Processor.process!는 mail=nil을 인자로 Email::Receiver.new를 호출하며, 이로 인해 Email::Receiver.EmptyEmailError가 발생하고 @receiver가 정의되지 않은 상태가 됩니다.

그 뒤의 rescue 부분은 초기화된 @receiver를 전제로 합니다.

Email::Processor.initialize가 mail==nil로 호출될 때 어떤 에러를 발생시키는 것이 맞지 않나요?

[sam (Sam Saffron)]

@thoka

Email::Receiver.new

가 어딘가에서 오류를 일으키고 있는 것 같습니다.

@receiver.is_bounce?를 @receiver&.is_bounce?로 변경하는 PR이 적절할 것 같으며, 적어도 오류가 handle_bounce로 전달되게 될 것입니다.

[mekentosj (Alexander Griekspoor)]

저희도 동일한 문제를 겪고 있습니다. https://meta.discourse.org/t/problems-with-email-processing-undefined-method-is-bounce-for-nil-nilclass/259813/2 링크를 확인해 주세요. 이메일 처리를 다시 정상화할 수 있는 우회 방법이나 우리가 할 수 있는 조치가 있을까요? 특정 이메일이나 사용자 때문에 발생하는 문제일까요?

업데이트: 네, 확실히 이것이 문제의 원인임을 확인했습니다. @thoka 님의 분석 덕분에 무엇을 찾아봐야 할지 알게 되었고, 문제는 실제로 빈 이메일이었습니다. 빈 이메일이 등장하는 지점까지만 메시지가 읽음 처리되어 있다는 점에 주목해 보세요.

수신함에서 해당 이메일을 삭제하면 처리가 다시 정상적으로 진행됩니다. 다만, 다음 빈 이메일에 도달할 때까지는 그렇다는 뜻입니다:

즉, 현재 빈 이메일이 시스템에 막힘을 일으키고 있습니다. 특정 개수를 넘으면 문제가 발생하는 것 같지만, 영구적으로 막히는지 아닌지는 조금씩 달라지는 것 같습니다.

지금은 상황을 모니터링해야 할 것 같지만, 이 문제가 실제로 수정되길 바랍니다. 감사합니다!!

[davidb]

@mekentosj

thoka님의 분석 덕분에 무엇을 찾아봐야 하는지 알게 되었습니다. 문제는 실제로 빈 이메일이었습니다.

@mekentosj님, 이 문제를 조사하고 있습니다. 현재 빈 이메일이 어떻게 생성되고 있는지 알고 계신가요? (오류를 수정하는 것 외에도) 조사해야 할 근본 원인이 있는지 궁금합니다.

[mekentosj (Alexander Griekspoor)]

좋습니다, 이 문제를 확인해 주셔서 감사합니다! 이들이 어떻게 이런 이메일을 보내는지 정확히 알 수는 없지만, 스크린샷의 예시들은 누군가(또는 그 사람의 이메일 앱)가 답장하기 전에 본문 내용을 모두 삭제한 것처럼 보입니다. 중국어로 답장하는 사람들에게서 더 자주 발생하는 것 같으니, 문자 인코딩 문제나 특정 이메일 앱의 문제일 수도 있겠네요. 하지만 저희 환경에서 관련되거나 가능성이 있는 다른 상황으로는, 본문 내용 없이 첨부파일과 제목만 있는 이메일을 보내는 경우, 혹은 (아직도 일부 사용자가 이렇게 하는 경우가 있지만) 본문 없이 제목에만 질문 내용을 전부 넣는 경우를 꼽을 수 있습니다.

[mekentosj (Alexander Griekspoor)]

사실 방금 이메일을 찾았어요. eml 파일을 DM으로 보내드릴게요 (사용자의 이메일 주소가 포함되어 있어서요). 더 많은 단서가 있을 수도 있어요.

[davidb]

@mekentosj

방금 이메일을 찾았습니다. (이메일에 사용자 이메일 주소가 포함되어 있으므로) DM으로 eml 파일을 보내겠습니다.

감사합니다. 해당 이메일은 제3자(텐센트/중국)에 의해 생성된 것으로 보입니다. 이메일 헤더를 확인해 보니 몇 가지 비정상적인 부분이 발견되었습니다(관심 있는 부분을 아래에 강조 표시했습니다). 이메일에는 본문이 전혀 없지만, 해당 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

[mekentosj (Alexander Griekspoor)]

좋아요, 네, 우리 커뮤니티에서 주로 중국 사용자에게 영향을 미쳤다는 제 직감이 맞았다는 것을 확인해 주셨네요.

이메일 본문이 없는 메일은 건너뛰는 것이 안전할 것 같습니다. 이를 조용히 로깅하고 에러가 발생하지 않도록 방지할 수 있습니다.

네, 발신인이 아무 내용도 입력하지 않았더라도 첨부 파일만 있는 메일은 건너뛰지 않아야 합니다(저는 이메일 전문가가 아니므로, 그런 경우에도 본문이 포함될 수 있을 것 같습니다).

제가 언급했던 다른 시나리오, 즉 사용자가 제목만 입력하고 이메일 본문을 비워두는 경우는 현재 이미 건너뛰고 있을까요? 그렇지 않다면, 문제의 원인이 되는 메일과 이를 구분하는 방법을 찾아야 할 것입니다.

대안으로는, 자동으로 생성된 이메일을 감지하는 메커니즘이 에러를 발생시키기 전에 X-QQ-AUTO-REPLY: true 헤더 필드를 인식하도록 하는 것입니다.

추가로, Sam이 제안한 대로 이 특정 에러를 해결하는 것도 여전히 원하시는 것 같습니다.

[davidb]

이메일 주제를 base64로 디코딩한 결과 다음과 같습니다:
你好，我是Focus and Flat Agile 17

이것은 중국어 문자 때문이라고 생각합니다. 중국어 문자는 전송 전에 base64로 인코딩됩니다. 이것이 발신자 이름과 주제가 깨진 형태로 표시되는 이유를 설명합니다.

@mekentosj

네, 발신자가 아무것도 입력하지 않았더라도 첨부 파일만 있는 이메일은 건너뛰지 않는 한 괜찮습니다. (저는 이메일 전문가가 아니므로, 본문이 여전히 포함될 수도 있습니다.)

기존 로직이 이미 이 문제를 처리하고 있기를 바랍니다. 하지만 pop3에서 메일을 처리할 때 첨부 파일과 이메일 주제를 어떻게 처리하는지 확인해 보겠습니다.

@mekentosj

제가 언급한 다른 시나리오, 즉 사용자가 주제만 입력하고 이메일 본문을 비워 두는 경우 현재 이미 건너뛰어지는 것일까요?

이 경우 현재 메일 처리 로직에 의해 건너뛰어질 것이라고 생각합니다. 본문에 텍스트가 없지만 다른 모든 요소가 갖춰져 있는 경우, 다음과 같은 결과가 나옵니다:

Email can not be processed: Email::Receiver::NoBodyDetectedError

이것은 텍스트와 HTML을 위한 빈 gmail 멀티파트 본문을 사용하여 테스트했습니다:

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--

[mekentosj (Alexander Griekspoor)]

@davidb

기존 로직이 이 부분을 이미 처리하고 있기를 바랍니다. 하지만 pop3에서 메일을 처리할 때 첨부파일과 메일 제목을 어떻게 다루는지 확인해 보겠습니다.

현재 메일 처리 로직에서는 이 부분이 건너뛸 것 같습니다. 본문에 텍스트가 없으나 나머지는 모두 정상일 경우, 다음과 같은 결과를 얻습니다:

Email can not be processed: Email::Receiver::NoBodyDetectedError

네, 제가 예상했던 바로 그 상황입니다.

[thoka (Thomas Kalka)]

제 경우 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'

[davidb]

is_bounce?로 인한 오류를 방지하기 위해 업데이트를 적용했습니다.

메일 로그 추적을 위한 사이트 설정이 있습니다:

SiteSetting.log_mail_processing_failures
모든 이메일 처리 실패를 /logs에 기록

이 설정이 활성화되어 있으면, 빈 이메일 오류가 메일 로그에 여전히 표시되지만 현재처럼 작업이 실패하지 않습니다. 참고를 위해 커밋 세부 정보를 여기에 추가했습니다:

FIX: Prevent Email Processor errors when mail is blank or nil (#21292)

[Jose_C_Gomez]

로그에서 이 오류를 보고 있는데, 이게 관련이 있을까요? 며칠째 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'