메일 수신 컨테이너를 사용하여 이메일 답장 기능을 활성화하는 데 어려움을 겪고 있습니다. 일관되게 다음과 같은 오류가 발생합니다:
NOQUEUE: reject: RCPT from ... 454 4.7.1 <...>: Relay access denied
이유는 무엇일까요? 메일 수신 컨테이너에 접속하여 postfix 설정을 확인하고 디버깅하는 방법은 무엇일까요? 포트 25 충돌을 방지하기 위해 해당 시스템의 postfix 서버를 비활성화했는데, 이것이 잘못된 접근일까요?
DNS MX 레코드가 올바르게 설정되어 있다고 확신하며, 이 문제는 발신하는 모든 서버에서 수신 메일을 보내는 경우 발생합니다. 앱 컨테이너에서는 Amazon SES를 사용하여 발신 메일을 보내고 있으며, 이는 정상적으로 작동합니다.
저는 Discourse 초보자로 이 생태계를 디버깅하는 방법을 모릅니다. postfix에 대해서는 전문가이지만, 이 컨테이너화된 환경에서 어떻게 설정해야 하는지 모르겠습니다.
우선, 이미 postfix 인스턴스가 실행 중이라면 메일 수신 컨테이너는 실제로 필요하지 않습니다.
replies 이메일의 수신자로 postfix를 구성하고, discourse가 해당 이메일을 폴링하도록 설정할 수 있습니다.
2014년에 작성된 이 howto 글이 시작하는 데 충분한 아이디어를 제공해 줄 것이며, postfix 설정은 직접 알아낼 수 있을 것이라고 생각합니다.
이 부분에 대해서는 전혀 동의할 수 없습니다. mail-receiver의 장점은 이메일이 폴링이 아닌 API를 통해 푸시된다는 점입니다. Discourse에 이메일이 도착하는 데 걸리는 시간에서 mail-receiver를 사용할 때와 그렇지 않을 때의 차이는 상당합니다(분 단위 대 초 단위).
설정 단순성에서도 큰 차이가 있습니다. mail-receiver는 yml 파일의 3줄만 수정하면 되지만, postfix OOBE는… 더 많은 작업이 필요합니다.
이 오류는 메일 도메인이 일치하지 않음을 시사합니다.
메시지의 일부가 마스킹되어 있어, 이 문제를 쉽게 디버깅할 수 없습니다.
예상대로 메일이 정상적으로 전달되고 있다면, 이는 누군가가 당신의 메일 서버를 사용하여 다른 도메인으로 메일을 전달하려 한다는 것을 의미합니다. 예를 들어, 누군가가 MX 레코드를 당신의 IP 주소로 지정했을 경우이거나, 또는(이건 제가 한 번도 들어본 적 없지만 
) 누군가가 악의적으로 당신의 메일 서버를 통해 원치 않는 메일을 전달하려 할 때입니다.
이 모든 오류가 동일한 IP에서 발생했나요? 로그에서 해당 오류 메시지의 대상 도메인이 무엇인지 확인할 수 있나요?
가장 쉬운 해결 방법은 무시하는 것입니다.
이전에 정상적으로 작동하던 mail-receiver에 일부 변경 사항을 적용한 후 이 문제가 발생했습니다. 컨테이너를 다시 빌드하면 해결될 줄 알았는데, 분명 무언가 제대로 처리되지 않아 모든 수신자에게 ‘Relay access denied’ 오류가 여러 번 발생했습니다. DNS는 올바르게 설정되어 있었습니다.
결국 단순히 git pull을 실행하고 launcher rebuild mail-receiver 명령을 입력한 후 문제가 해결되었습니다. 다른 분들에게도 도움이 될 수 있을지 모르기에 이 내용을 공유합니다.
메일 수신자 보고서에서 동일한 오류가 발생합니다: Relay access denied (in reply to RCPT TO command).
새 설치 환경에서는 메일 수신 기능이 작동하지 않습니다. 이전에는 정상적으로 작동했던 적이 있습니다. 모든 설정이 정확한 것으로 생각하지만, 놓친 부분이 있을 수 있습니다.
이것은 일반적으로 메일이 수신자가 수신하도록 설정된 도메인이 아닌 다른 도메인으로 전달되고 있음을 의미합니다.
디스코urs 사이트와 동일한 서브도메인으로 설정해 두었습니다.
MX 레코드의 값은 "subdomain.domain"이고, 호스트는 단순히 "subdomain"이어야 하는지, 아니면 @이어야 하는지 궁금합니다.
누군가 “Relay access denied” 오류의 원인을 아시나요?
수신자 도메인이 mail-receiver.yml에 설정된 도메인과 일치하지 않을 때 발생합니다.
메일을 보내는 주소가 그 주소인가요?
같은 주소입니다. 메일 수신기를 재구성한 후 이제 정상 작동합니다.
이전에 재구성한 적이 있었는데 그때는 작동하지 않았어요. 이제 잘 작동해서 다행입니다.
mail-receiver가 제대로 작동하려면 25 포트를 추가로 허용해야 하나요?
여기서 제대로 작동한다는 것은 mail-receiver가 수신한 이메일이 .\launcher logs mail-receiver에 표시되고 Discourse 관리자 UI까지 도달하는 것을 의미합니다.
네, 포트 25를 열어야 합니다. 이 가이드에 선택적 규칙으로 추가할 수 있습니다.
글쎄, 나는 25개나 열려 있는 게 없어요. 그래서, 아니요.
다만 ufw status는 그렇게 흥미롭지 않아요. 대신 nft list ruleset가 더 유용합니다.
업데이트: ufw deny 25가 적용되었고 mail-receiver가 정상 작동합니다 (2025-02-07)
이것이 올바른 방법임을 확인합니다. 다만, 다른 오류 하나를 범했던 적이 있습니다. 이 문제는 mail-receiver를 구현하려는 제 두 번째 포럼에 관한 것입니다. 첫 번째 포럼에서는 메일을 수신하는 도메인의 MX 레코드 Value를 DISCOURSE_BASE_URL로 설정하고 있었습니다.
이제 메일이 제 첫 번째 포럼에만 오는 것이 아니라 (두 번째) 포럼 UI로도 도착하고 있습니다. 
참고: yml 파일을 변경한 후 ./launcher rebuild mail-receiver를 실행하지 않았기 때문에 이 오류가 발생했을 수 있습니다 (2015-02-06)
예를 들어 Azure나 VPS 패널의 방화벽에서 포트 25를 열 필요가 없을 것 같다는 생각입니다. Ubuntu 설치 전 단계에서 말이죠.
MX 레코드의 값은 메일 도메인이 아니라 웹사이트를 가리켜야 한다는 점이 흥미롭네요.
공식 가이드에는 포트 25가 열려 있어야 한다고 언급되어 있습니다:
저도 방화벽에서 포트 25를 열기를 잊어버려서 메일 수신기 문제를 겪었습니다. 규칙을 추가하니 문제가 해결되었습니다.
더 나은 해결책은 관련 IP 주소만 허용하는 것일 수 있죠?
이걸 내 메일 수신기에 말하지 말자
발신은 Amazon SES를 통해 이루어지고, 수신은 포럼 도메인의 mx 레코드를 통해 들어오며, 이 시점에 docker가 개입합니다.
그 이유는 docker와 그 내부 작동 방식 때문입니다. docker는 ufw를 전혀 신경 쓰지 않습니다. 정확한 세부 설명을 원하시면 잠시만 기다려 주세요 — 한 번은 왜 Discourse가 내 방화벽을 무시하는지 질문을 해본 적이 있는데, 그 이유는 패킷 트래픽 때문이었습니다. 하지만 무슨 일이 일어나고 있는지 깊이 이해하는 건 제 취향이 아닙니다. 제 입장에서는 그냥 일이 돌아주면 충분합니다. 믿어주세요: ufw는 22, 80, 443 포트만 열려 있습니다.
제가 보기에는 당신이 인용한 상황은 메일 수신기가 postfix를 사용하여 메일 발송도 담당하는 경우인 것 같습니다.