Let's Encrypt 루트 인증서 변경에 따른 자체 호스팅 메일 수신기 업데이트

이번 공지 사항은 https://meta.discourse.org/t/direct-delivery-incoming-email-for-self-hosted-sites/49487를 실행 중인 셀프 호스터에만 영향을 미칩니다. 관리형 호스팅 고객과 POP3를 사용하여 수신 메일을 처리하는 셀프 호스터에는 영향을 주지 않습니다.

알고 계시듯이, Let’s Encrypt가 최근 루트 인증서를 변경했습니다. 기존 루트 인증서는 오늘 만료되었으며, 웹 전반에서 업데이트가 되지 않은 클라이언트에 여러 문제를 일으켰습니다. CDCK의 모든 시스템은 최신 상태로 유지되고 있어 오늘의 만료로 인한 영향을 받지 않았습니다. 불행히도 몇 달 동안 업데이트되지 않은 공개 메일 수신기 docker 이미지를 놓치고 말았습니다.

즉, 기존 셀프 호스팅된 메일 수신기 설치 환경은 Let’s Encrypt 보안이 적용된 사이트로 메일을 전달할 수 없게 됩니다.

새로운 루트 인증서가 포함된 업데이트된 버전을 DockerHub에 방금 배포했습니다. 공식 설치 지침을 따랐다면, 다음 명령을 실행하여 설치를 업데이트할 수 있습니다.

docker pull discourse/mail-receiver:release
cd /var/discourse
./launcher rebuild mail-receiver

고장 난 설치 환경에서 수신된 메일은 일시적으로 전송 서버에 대기열에 쌓여 있을 것입니다. 해당 서버는 주기적으로 메일 재전송을 시도하므로, 이미지를 업데이트한 직후 누락된 메일들이 도착할 것입니다.

이 단계를 따랐음에도 여전히 문제가 발생한다면, release 버전의 mail-receiver를 실행 중인지 확인해 주세요. 관련 정보는 이 토픽에서 확인할 수 있습니다.

불편을 드려 죄송합니다! 문제를 처음 보고해 주시고 수정 사항을 테스트하는 데 도움을 주신 @wlandgraf님께 감사드립니다. :heart:

수정해 주셔서 감사합니다! 업데이트가 다음과 같은 오류 메시지로 멈춰 있습니다. 이 템플릿에 대한 변경 사항은 없었기 때문에 어떻게 해야 할지 모르겠습니다.

root@ba /var/discourse # ./launcher rebuild mail-receiver
Ensuring launcher is up to date
Fetching origin
Updating Launcher...
Updating 46d899f..990519e
error: Your local changes to the following files would be overwritten by merge:
	templates/web.letsencrypt.ssl.template.yml
Please commit your changes or stash them before you merge.
Aborting
failed to update

다음과 같이 실행하면 어떻게 되나요?

cd /var/discourse
git diff

web.letsencrypt.ssl.template.yml 파일에 어떤 차이가 표시되나요?

차이가 있다면 git reset --hard를 사용하여 초기화할 수 있습니다.

아, 제가 변경 사항을 넣었네요 :innocent: 이제 업그레이드가 되네요, 감사합니다!

아래와 같이 기존 mail-receiver를 실행 중인지 테스트할 수 있습니다.

docker exec mail-receiver bash -c "cat /etc/issue|grep Alpine"

Alpine이 출력되면 기존 버전입니다.

docker exec mail-receiver bash -c "cat /etc/issue|grep 'Debian GNU/Linux 11'"

Debian이 출력되면 새 버전입니다.

@david, 아래 이슈들을 확인해 주시겠어요? 최신 메일 수신기(mail-receiver) 업데이트로 인해 이전 버전에서 매우 효과적으로 작동하던 추가적인 스팸 방지 조치를 구현할 수 없게 되었습니다. 이로 인해 마지막 변경 사항 이후 제 포럼에 다시 스팸이 계속 유입되고 있습니다.

근본적인 문제가 무엇인지 파악해 보려 했지만, postfix에 대한 지식이 충분히 깊지 않아서 해결하지 못했습니다. DNS에 PTR 레코드가 존재함에도 client=unknown으로 표시되는 유사한 보고 사항들을 chroot jail 환경의 postfix 관련해서 발견했으니, 이 문제와 관련이 있을 수 있습니다. 또한, 새로운 메일 수신기 Debian 이미지에서 dnsutils가 누락된 것 같지만, 설치해도 문제가 해결되지 않습니다?

이것은 쉽게 수정될 수 있을 것 같습니다:

@david 수정해 주셔서 감사합니다! 방금 실행해 보니 정상적으로 작동하는 것을 확인했습니다. :+1:

10월 1일 이후 전달되지 못한 이메일을 확인할 수 있는 방법이 있을까요?

아래와 같이 시도해 보았지만, 요청이 5개만 표시됩니다(가장 오래된 요청은 11월 26일에 수신됨):

/var/discourse/launcher enter mail-receiver
mailq

로그를 확인해 보기도 했는데, 여기 보고된 경고만 확인했습니다:

큐에 아직 남아 있지 않은 항목은 모두 발신자에게 되돌려졌어야 한다고 생각합니다. 컨테이너에 사용자가 찾으신 것보다 더 이전 시점까지의 로그가 있는지 확실하지 않습니다.

657번째 줄 뒤에 pull_image를 단순히 추가하면, 재빌드 전에 이미지를 명시적으로 가져오는(pull) 필요가 해결될까요? 즉,

  # If the image being bootstrapped is not the base Discourse image
  if [[ ! X"" = X"$base_image" ]]; then
    image=$base_image
    # Attempt to bring the image up to date
    pull_image
  fi

이렇게 하면 base_image가 yml 파일에 설정된 컨테이너의 부트스트랩/재빌드 시 항상 docker pull $image가 실행됩니다. 이미 최신 상태인 경우 메일 리시버(mail-receiver)에는 문제가 되지 않을 것 같지만, 다른 상황에서 문제가 될 수 있는지는 확신이 서지 않습니다.

네, 여기서는 무조건적인 pull이 합리적인 것 같습니다. 현재 메인 베이스 이미지에만 적용되는 점이 좀 이상하긴 하네요. @Falco님, 어떻게 생각하세요?

이 질문에 대한 명확한 답변을 듣고 싶습니다 :slight_smile:

incoming_emails PostgreSQL 테이블을 조회하면 확인할 수 있을 것 같습니다

불행히도 해당 시간대(2021년 10월부터 2022년 2월까지)에는 아무것도 표시되지 않습니다.

메일 수신기 컨테이너 자체에 로그가 있을까요?