로컬 SMTP 서버를 통해 이메일을 보내는 방법에는 두 가지가 있습니다:
- 587 포트의 STARTTLS 또는 465 포트의 암시적/즉시 TLS와 같이 제출(submission) 포트에 연결하고 인증을 수행합니다. => 네트워크 요청이 발생하며
smtpd를 통해 검사 및 제한이 적용됩니다. sendmail또는 유사한 도구를 사용하여 로컬pickup명령(Postfix의 경우)을 호출합니다. 이는 네트워크 연결을 수행하지 않으며smtpd제출 서비스에 구성된 모든 검사 및 제한을 우회합니다.
후자의 방식이 더 단순하고 빠르며, PHP 메일러와 Discourse에서 사용하는 이 Ruby 메일 라이브러리 같은 일반적인 런타임 시스템 및 프레임워크에 구현되어 있습니다. 또한 인증이 우회되므로 어디에도 평문 자격 증명을 저장할 필요가 없습니다. 다시 말해, 이 경우 SMTP 서버는 전혀 사용되지 않고 SMTP 클라이언트만 사용됩니다.
제 생각에는 제출 포트 연결 관련 작업이 Discourse가 일반적으로 수행하는 작업과 비교할 때 서버 부하에 상당한 영향을 미치지 않을 것입니다. 후자의 문제는 제출 포트에서 smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject 규칙을 사용하여 인증을 수행하기 전에 루프백 IP(기본값, mynetworks 설정)로부터의 제출을 허용함으로써 해결할 수 있습니다. 컨테이너에서 온 요청이 다른 IP로 식별된다면 mynetworks에 추가할 수 있습니다. 이전에 링크한 토픽의 경우 이것이 작동하는 방식이었을 것으로 추정합니다.
다음에 Discourse를 업데이트/재빌드하여 변경된 SMTP 설정이 적용될 때 확인해 보겠습니다. 작동 방식을 보고하겠습니다.
하지만 여전히 다른 방법이 있는지, 그리고 이 “전달 방식(Delivery method)” 설정이 무엇에 관한 것인지 궁금합니다.
Postfix는 컨테이너 내부가 아니라 호스트에서 실행되지만, 네트워크 기반 인증이므로 큰 차이는 없을 것입니다.
잠시 생각해보니, sendmail 등이 컨테이너 내부에서 작동할 수 없는 것은 당연합니다. 이는 Postfix 실행 파일, 라이브러리, 설정의 광범위한 부분에 대한 직접적인 접근을 필요로 하기 때문입니다. 컨테이너에 바인드 마운트할 수 있는 일종의 마법 소켓이 있는 경우를 제외하고는 말입니다. 