자체 호스팅된 이메일 답신이 최신 업데이트 후 작동하지 않음

제품 지원
1

포럼이 이메일로 보낸 답장에 더 이상 응답하지 않습니다.

이전에는 이메일로 답장하는 기능이 잘 작동했지만, 9월 29일경부터 이 기능이 작동하지 않는 것으로 보입니다.

포럼의 활동이 많지 않아 이 시점에 대한 결정적인 증거는 없지만, 현재는 확실히 작동하지 않으며 포럼 로그에는 9월 29일 이후 수신된 메시지가 표시되지 않습니다.

거절된 이메일 로그의 가장 최근 항목도 9월 29일입니다. 거절된 모든 메시지는 일회용 주소와 스팸으로 보이는 내용을 담고 있어, 이 부분은 정상적으로 작동하는 것으로 보입니다.

반송된 이메일 로그는 비어 있거나 '로그 없음’을 표시합니다.

로그인된 사용자 활동으로 포럼에서 생성된 메시지는 여전히 발송되고 있습니다(최소 저는 받고 있습니다). 다만 위의 문제로 인해 활동 수준은 평소보다 더 낮은 편입니다. 활동적인 사용자 대부분은 브라우저 기반 상호작용보다 이메일을 선호합니다.

제 마이크로소프트 호스팅 이메일 주소나 Gmail 주소에서 보낸 포럼 게시글 이메일 알림에 대한 테스트 이메일 답장은 반송 경고를 받지 않습니다. 단순히 흔적도 없이 사라집니다. 포럼 이메일 로그에는 아무것도 표시되지 않습니다.

포럼 오류 로그에는 9월 29일에 '이메일을 처리할 수 없습니다: Email::Receiver::BadDestinationAddress Received…'라는 경고(노란색 느낌표 아이콘)가 몇 건 표시되는데, 이는 무해해 보이며 이전의 유사한 기록된 이벤트와 다르지 않습니다. 단순히 거절된 스팸일 것으로 추정합니다.

10월 1일에는 다음과 같은 실제 오류가 기록되었습니다:

메시지

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’

백트레이스

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’

환경

HTTP HOSTS: nzarchitecture.net.nz

이것이 관련이 있는지 모르겠고, 이후 로그에는 추가 오류나 치명적 오류(밝은 빨간색 또는 진한 빨간색 십자 아이콘으로 표시됨)가 표시되지 않았습니다.

www.mail-tester.com에서 테스트해 본 결과 제 이메일 주소 두 곳 모두 스팸으로 분류되거나 블랙리스트에 올라 있는 것으로 보이지 않으며, 이 주소들을 통해 사람들과 소통하는 데 문제가 발생하지 않았습니다.

포럼은 Mailgun을 사용하지만, 이는 대량 이메일 발송에만 사용되는 것으로 추정되며, Mailgun 계정 또는 API 키에 문제가 있어도 수신 메시지에 영향을 주지 않아야 합니다. 실제로 Mailgun 계정에 로그인했을 때 눈에 띄는 문제나 오류 메시지는 발견되지 않았습니다.

포럼이 여전히 이메일을 정상적으로 발송하고 있으므로 Mailgun API 키에는 문제가 없을 것으로 추정합니다.

이메일로 답장이 작동하던 이후로 포럼 설정은 변경되지 않았으며, ‘이메일로 답장’ 설정의 체크박스가 여전히 체크되어 있는 것을 확인했습니다.

포럼은 Digital Ocean에 호스팅되어 있습니다. Digital Ocean 설정에서 도메인의 DNS 설정은 변경되지 않았으며, 포럼의 MX 레코드도 정상/변경되지 않은 것으로 보입니다.

문제가 시작된 이후 포럼은 2.8.0 beta 7로 업데이트되었습니다(이 과정에서 재빌드가 수행되었을 것으로 추정됩니다) 하지만 개선된 점은 없습니다.

제가 놓치고 있는 것이 무엇인가요?
무엇이 잘못되었을 가능성이 높나요?
이메일로 답장 기능이 다시 작동하게 하려면 어떻게 해야 하나요?

2

그 에러는 별개 문제인 것 같습니다.

일반적으로 "이메일 수신"을 테스트하는 것이 "이메일로 답변"을 테스트하는 것보다 쉽습니다. 수동 폴링 활성화와 이메일 수신 설정을 확인하고, 직원(staff) 범주에 이메일 주소를 추가한 후, 포럼 관리자 사용자 계정에 사용하는 동일한 이메일 주소로 해당 주소로 이메일을 보낼 수 있는지 확인해 보세요.

그 다음 관리자 - 이메일 - 반송됨 / 수신됨 / 거부됨 메뉴를 확인하여 어떤 일이 일어나고 있는지 살펴보세요.

이메일로 답변 주소가 올바르게 설정되어 있나요?

3

안녕하세요, Richard 감사합니다.

manual polling enabled 및 email in 설정이 여전히 활성화되어 있는 것을 확인했습니다.

Gmail 주소를 스태프 범주의 사용자 지정 주소로 추가했지만, 포럼을 통해 스태프에게 메시지를 보내는 방법을 찾을 수 없습니다. 모든 ‘문의하기’ 링크는 포럼 설정 텍스트에 mailto: 링크로 설정되어 있으며, 이는 제 개인 일상용 이메일 주소로만 연결됩니다. 이 링크 중 하나를 클릭하면 제 개인 이메일 주소가 미리 입력된 상태로 이메일 앱이 열리므로, 포럼에는 메시지가 전달되지 않습니다.

4

아니요, 카테고리 설정에서 staff@nzarchitecture.net.nz와 같은 주소를 설정한 후, Gmail에서 해당 주소로 메시지를 보내야 합니다.

5

아, 알겠습니다.

정말 이대로 시도해 보았지만, Bounced / Received / Rejected 로그 중 어디에도 아무것도 표시되지 않았습니다.

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

무슨 일이 일어나고 있는지 알고 있습니다. 9월 30일에 인터넷의 절반 많은 것을 망가뜨린 그 @#(($* LetsEncrypt 문제 때문이죠.

메일 리시버 Docker를 다시 빌드하면 됩니다.

10

ㅋㅋㅋㅋㅋㅋ, 그래. 그거 잊고 있었네. ㅋㅋㅋ

12

@RGJ가 게시한 주제를 따라야 합니다.

그러면 문제가 해결될 것입니다.

13

아, 알겠습니다. 유망해 보이네요!
'메일 수신기 Docker’를 다시 빌드하는 방법은 무엇인가요? 대시보드에서 포럼을 업데이트할 때 발생하는 ‘Docker Manager’ 재빌드와 다른 건가요?

이렇게 하면 되나요? How do I manually update Discourse and Docker image to latest? - howto / admins - Discourse Meta

14

사이트의 커맨드 라인 측에 로그인해야 합니다.

포럼 관리 대시보드를 통해 하는 것이 아닙니다.

15

안녕하세요, 해당 링크(Direct-delivery incoming email for self-hosted sites - howto / sysadmin - Discourse Meta)의 안내에 따라 메일 수신기 Docker를 재빌드하는 데 성공했습니다.

호스트에 저장된 모든 백업 등을 삭제한 후에도 재빌드를 위한 디스크 공간이 부족하여 Digital Ocean 드롭렛를 업그레이드/리사이즈해야 했습니다.

재빌드 후 staff@nzarchitecture.net.nz로 해당 메시지를 전송할 수 있었고, 이번에는 포럼 로그에서 이를 확인했습니다.
그러나 포럼에서 통지를 받은 기존 주제에 이메일로 답글을 보낼 때, 수신 메시지는 이제 확인은 되지만 포럼에 표시되지 않으며, 모든 메시지에 대해 이메일 로그에 메일 전달 실패(Mail Delivery Failure) 경고가 나타납니다.

수신 메시지는 반송 메일(Bounced Email) 로그에는 표시되지 않지만, 제 관리자 이메일 계정(갑자기 잘못된 수신지 주소가 될 리가 없는데)을 포함하여 모두 거부된 메일(Rejected Email) 로그에 [Email::Receiver::BadDestinationAddress] 경고와 함께 표시됩니다.

16

최근 메일 수신기를 다시 구축하셨나요?

17

네 - 약 30분 전에 그렇게 했는데, 그 결과로 위에 게시된 글이 작성되었습니다.
방금 완전한 재빌드를 한 결과 (부디 문제 없길 바라면서) 다시 잘 작동하는 것 같습니다.

18

force https가 설정되어 있지 않았던 것일 수 있고, 재빌드로 인해 해결되었을 수도 있습니다.

19

사실 저는 대시보드에서 정확히 그 문제에 대한 경고가 표시되는 것을 확인했고, 제공된 편리한 링크를 클릭하여 해당 설정으로 이동한 후 확인란에 체크를 했습니다.

수신 이메일을 받으려면 HTTPS 강제 적용이 필수라는 점을 몰랐습니다.

HTTPS 강제 적용이 누락된 것이 Facebook 로그인 사용에도 문제를 일으켰을 가능성이 있습니다. 최근 Facebook으로부터 사이트가 서비스 약관을 위반했다는 통보를 받아 일시 정지 처리되었습니다. Facebook 앱 개발자 관리 패널에는 조치 항목이 없었기 때문에 이의를 제기했고, 답변으로는 제 포럼 URL에서 발생한 특정 오류로 인해 사이트를 검증할 수 없다고 했습니다.

20

‘Force https’ 상자를 체크했는데도 Facebook 로그인 문제에는 전혀 도움이 되지 않는 것 같습니다. Facebook 기술 지원팀에서는 여전히 사이트 랜딩 페이지가 ‘your connection is not private
NET::ERR_CERT_COMMON_NAME_INVALID’ 보안 경고를 생성한다고 보고하고 있습니다.

오류 페이지에 따르면 인증서의 발급자는 'R3’로 표시되며, 구글 검색 결과 이는 Let’s Encrypt와 관련이 있는 것으로 보입니다. Let’s Encrypt는 인증서 만료로 인해 Discourse 설치 재구축이 필요했던 바로 그 회사입니다.

이것이 우연한 일치일까요? 이 상황은 최신 Discourse 빌드(2.8.0 beta 7)에 여전히 인증서 문제가 있다는 것을 시사하는 것일까요? 아니면 호스팅/Digital Ocean과 관련된 별개의 문제일까요?

21

직접 구글링을 하며 시행착오를 겪다가 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 관리자가 직접 관리해야 하는 것이 되었나요? 그렇다면 어떻게 관리해야 하나요?

지금 제 질문이 주제에서 벗어난 것이라면 알려 주십시오. 이것이 동일한 문제의 일부인지 확신이 서지 않아서요.