localhost:25의 SMTP 서버에 인증 없이 연결하는 방법?

제품 지원 자체 호스팅
1

./discourse-setup에 로컬호스트의 25번 포트에서 인증 없이 SMTP 서버에 연결하기 위해 전달해야 하는 올바른 설정은 무엇인가요?

이것이 기본(OOTB)으로 지원되지 않는다는 사실에 매우 놀랐습니다. 대부분의 Linux 설치 환경에서는 이것이 기본 설정이거든요..

저희 서버는 로컬에서 postfix를 실행하고 있으며 인터넷에서 접근할 수 없습니다. 예를 들어 mail 명령을 실행할 때는 잘 작동합니다. 인터넷에서 /var/discourse/containers/app.yml 파일을 수정하라는 몇 가지 비공식 가이드를 찾았고, 마침 다음과 같은 설정으로 설치 및 시작에 성공했습니다:

  DISCOURSE_SMTP_ADDRESS: localhost
  DISCOURSE_SMTP_PORT: 25
  DISCOURSE_SMTP_USER_NAME: discourse@opensouceecology.org
  DISCOURSE_SMTP_PASSWORD: "none"
  DISCOURSE_SMTP_AUTHENTICATION: none
  DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none
  DISCOURSE_SMTP_ENABLE_START_TLS: false

참고로, DISCOURSE_SMTP_USER_NAME 또는 DISCOURSE_SMTP_PASSWORD 변수를 생략하면 설치 스크립트에서 해당 변수가 필수라고 경고합니다(버그?).

그리고 이제 Discourse WUI에서 “활성화 이메일 재전송” 버튼을 클릭하면 로그 파일(/var/discourse/shared/standalone/log/rails/production.log)에 다음과 같은 항목이 나타납니다:

Started PUT "/finish-installation/resend-email" for 127.0.0.1 at 2019-11-07 13:15:31 +0000
Processing by FinishInstallationController#resend_email as HTML
  Parameters: {"authenticity_token"=>"SzQCvRWiqdXsBKzOjIB0X7KkvXro7Od6SdP8Qa8vvrskPeNYZNos5ORHJfyDUrHiKShZR/txM6NHuqHHCQCR1w=="}
  Rendering finish_installation/resend_email.html.erb within layouts/finish_installation
  Rendered finish_installation/resend_email.html.erb within layouts/finish_installation (Duration: 0.7ms | Allocations: 103)
  Rendered layouts/_head.html.erb (Duration: 0.5ms | Allocations: 103)
Completed 200 OK in 98ms (Views: 3.0ms | ActiveRecord: 0.0ms | Allocations: 4763)
  Rendering layouts/email_template.html.erb
  Rendered layouts/email_template.html.erb (Duration: 0.5ms | Allocations: 141)
Delivered mail c4ca58ca-345e-46c4-81bc-6d0eac7afa04@discourse.opensourceecology.org (11.3ms)
Job exception: wrong authentication type none

…하지만 제 인증 유형은 ‘none’ 입니다. 인증이 없을 때 올바른 설정은 무엇이어야 하나요?

수정: 또한, 가능한 모든 “DISCOURSE_SMTP_*” 변수와 그 유효한 값을 정의하는 문서 링크를 알려주실 수 있나요?

수정2: 이것은 생각보다 훨씬 더 어렵습니다. 'localhost’가 Discourse 도커 컨테이너(app) 자체로 해석되는 것 같고, postfix SMTP 서버를 실행 중인 도커 호스트가 아닙니다. 이는 discourse-setup 스크립트나 그 하위 스크립트에서 설정된 postfix의 mynetworks와 iptables로 인해 더 복잡해집니다. 여기서 SMTP 인증 없이 제가 Discourse를 실행하려는 SMTP 서버를 Discourse가 사용하도록 하려면 올바른 설정은 무엇인가요?

2

약 20년 전부터는 그 말이 크게 맞지 않았던 것 같습니다.

discourse-setup은 이러한 상황에 사용할 수 없습니다. 방화벽 뒤에서조차도 비밀번호가 없는 SMTP 서버를 사용하는 사람이 매우 적기 때문입니다.

제 제안은 메일 서버에 SMTP 비밀번호를 설정하는 것입니다. 실제로 큰 단점은 없습니다.

그렇게 하기 원하지 않는다면, 인증(authentication)에 “none” 대신 “” (빈 문자열)을 사용하는 것이 더 나을 수 있습니다 (사용자 이름과 비밀번호도 마찬가지입니다).

저도 그렇게 생각합니다. 컨테이너 이름을 사용해 보는 것을 권장합니다. 두 컨테이너가 동일한 Docker 네트워크에 있는지 확인해야 합니다.

3

2019년 기준, RHEL/CentOS에서 postfix의 기본 설정입니다. Postfix는 루프백 인터페이스에만 바인딩되며, 127.0.0.0/8에서 시작되지 않는 모든 smtp 요청을 드롭합니다. 인증은 필요하지 않습니다. Debian에 대해서는 확실하지 않지만, exim도 유사한 기본 설정을 가지고 있을 것이라 추정합니다.

이 문제를 경험한 다른 사용자들의 포럼 관련 주제 몇 가지입니다:

RHEL/Cent OS에서 Discourse 및 postfix 모두에 필요한 변경 사항을 적용하여 설정하는 방법에 대한 주제는 없어 보입니다. 그래서 여기에서 이를 문서화합니다.

discourse-setup 스크립트로는 이것이 가능해 보이지 않지만, 저는 성공적으로 설정했습니다.

먼저, docker 컨테이너가 docker 호스트의 IP 주소를 어떻게 보는지 파악해야 했습니다. 127.0.0.1을 사용하면 작동하지 않습니다. docker 컨테이너는 127.0.0.1을 자기 자신으로 인식하기 때문입니다. 대신, postfix SMTP 서버를 실행 중인 docker 호스트의 IP 주소 또는 호스트명을 지정해야 합니다. 또한 docker 컨테이너에서 접근 가능한 주소여야 합니다(예: SMTP 서버가 인터넷에 노출되지 않기를 원한다면 docker 호스트의 인터넷 연결용 IP 주소는 사용하면 안 됩니다).

docker 호스트에서 다음을 실행하여 docker0 인터페이스에서 관련 docker 호스트 IP 주소(172.17.0.1)를 추출했습니다:

[maltfield@osestaging1 ~]$ ip address show docker0
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 02:42:80:35:65:a1 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:80ff:fe35:65a1/64 scope link 
       valid_lft forever preferred_lft forever
[maltfield@osestaging1 ~]$

그런 다음 Discourse 앱의 yaml 파일을 편집하여 위의 172.17.0.1로 "DISCOURSE_SMTP_ADDRESS"를 설정했습니다.

[maltfield@osestaging1 ~]$ cd /var/discourse/
[maltfield@osestaging1 discourse]$ grep SMTP containers/app.yml
  DISCOURSE_SMTP_ADDRESS: 172.17.0.1
  DISCOURSE_SMTP_PORT: 25
  DISCOURSE_SMTP_AUTHENTICATION: none
  DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none
  DISCOURSE_SMTP_ENABLE_START_TLS: false
[maltfield@osestaging1 discourse]$

참고로, 처음에는 이를 위해 내부 docker 호스트명 host.docker.internal을 사용하려고 했지만, apparently 이 호스트명은 linux docker 사용자에게 사용 가능하지 않은 것으로 보입니다.

RHEL/Cent OS의 기본 postfix 설정은 127.0.0.1에만 바인딩하므로(이것은 좋은 점입니다), docker 컨테이너에서 오는 SMTP 트래픽이 postfix에 의해 수락되도록 /etc/postfix/main.cf를 수정하여 docker0 인터페이스에도 바인딩하고 해당 서브넷을 mynetworks 그룹에 추가해야 합니다.

[maltfield@osestaging1 postfix]$ grep -ir '172.17' /etc/postfix/*
/etc/postfix/main.cf:inet_interfaces = 127.0.0.1, 172.17.0.1
/etc/postfix/main.cf:mynetworks = 127.0.0.0/8, 172.17.0.0/16
[maltfield@osestaging1 postfix]$

이 변경 사항 이후에 Discourse를 다시 빌드하면 이제 docker 호스트의 postfix를 통해 이메일을 보낼 수 있어야 합니다.

/var/discourse/launcher rebuild app

이것이 작동하지만, 몇 가지 질문이 있습니다:

  1. docker 호스트(172.17.0.1)를 이미 가리키는 다른 환경 변수나 호스트명이 있습니까?

launcher에 의해 "주입"되는 DISCOURSE_HOST_IP 환경 변수가 있다는 것을 알게 되었습니다. 이 DISCOURSE_SMTP_ADDRESS yaml 키를 다른 키의 값과 동일하게 설정할 수 있을까요? 예를 들어 다음과 같이?

DISCOURSE_SMTP_ADDRESS: $DISCOURSE_HOST_IP
  1. 일반적으로 docker 호스트의 172.17.0.1 IP는 얼마나 안정적입니까? RHEL/Cent OS 시스템에서 항상 이 IP일까요? 나중에 변경될 수 있을까요?
4

@maltfield 설명해 주셔서 감사합니다.

Debian에서도 동일한 문제를 겪었습니다… Discourse를 위해 별도의 메일 사용자를 만들고 site:465에 연결하여 로그인할 수는 있겠지만, 제 생각에는 내부에서 포트 25로 연결하는 것이 더 논리적입니다.

그리고 참고로, 저장소의 docker.io를 사용한 Debian 10에서는 docker0이 여전히 172.17.0.1/16입니다.

5

@maltfield 님이 하신 말씀을 오해하고 계신 것 아닌가요?

내가 기억하는 한(20년보다 더 거슬러 올라가는 기간), Linux( / Unix / BSD / Solaris) 시스템에는 기본적으로 로컬호스트에서 받은 모든 것을 아무 질문 없이 릴레이하도록 구성된 SMTP 서버가 실행되고 있습니다. 이는 해당 머신에서 실행되는 다른 애플리케이션들이 SMTP 설정을 직접 걱정하거나 구성할 필요가 없도록 해줍니다.

6

네, 대부분의 리눅스 서버는 메일 전송에 인증이 필요하지 않습니다(기본 설정이거나 설치 및 구성 후). 또한 로컬 네트워크 외의 어디에서도 릴레이하지 않는다면 인증이 필요하지 않습니다. 기본 Discourse 설치 스크립트는 대부분의 서버에서 작동하지 않습니다. 이는 제한된 범위의 도커 기반 클라우드 솔루션을 위해 설계되었습니다.

RHEL/CentOS 7이 설치된 전용 베어메탈 서버에서 Discourse를 설치하는 방법에 대한 제 전체 종합 지침은 Open Source Ecology 위키에서 읽을 수 있습니다. 여기의 SMTP 섹션을 참고하세요:

7

글쎄, 이런 문제에서는 거의 항상 당신에게 맡기고 있어요! 로컬호스트에서 SMTP 서버를 직접 구동해 본 지 꽤 오래됐으니, 제가 아는 게 틀렸을 가능성이 높겠죠.

제가 틀렸다는 또 다른 증거네요! :man_shrugging:

좋네요!

하지만 discourse-setup은 시스템 관리에 대해 거의 아무것도 모르는 사람들을 위한 것일 뿐입니다. SMTP 서버를 설치하는 방법을 안다면 yml 파일을 수정할 수 있을 테니까요.

8

컨테이너가 실행 중인 호스트에 DNS를 통해 조회할 수 있는 이름이 있다면, 해당 이름을 지정하기만 하면 됩니다:

DISCOURSE_SMTP_ADDRESS: real.machine.example.com

Postfix는 여전히 메일의 출처가 로컬임을 인식하여 그에 따라 처리합니다.

9

DISCOURSE_HOSTNAME와 DISCOURSE_SMTP_ADDRESS가 동일할 경우 문제가 발생할까요?

Docker 호스트에 Postfix와 Dovecot를 설정하여 TLS를 통한 인증된 요청을 받도록 했습니다. 서버에 유효한 인증서가 있지만, 어떤 설정을 시도해도 Docker 호스트에서 실행 중인 Postfix로 Discourse가 메일을 올바르게 보내지 못합니다.

호스트명(discourse.[myhost].com)을 사용하면 작동하지 않습니다(연결조차 되지 않음). Docker 호스트 IP 주소(172.17.0.1)를 사용하면 다음과 같은 오류가 발생합니다.

hostname "172.17.0.1" does not match the server certificate

분명하게도, 인증서를 생성할 때 사용된 FQDN을 사용해야 합니다. DISCOURSE_SMTP_ENABLE_START_TLS를 false로 설정하면 start TLS 명령을 내려야 한다는 메시지가 표시됩니다. Postfix를 TLS 없이 열기 원하지 않으므로, 이는 현실적인 옵션이 아닙니다.

외부 SMTP 중계기를 사용하는 것도 옵션이 아닙니다. 메일이 사람들의 스팸/잘못된 메일 폴더로 가지 않도록 하려고 더 많은 비용을 지불하고 싶지 않기 때문입니다.

솔직히 말씀드리면, Docker 네트워킹에 대한 이해도는 기초 수준이고, Dovecot 인증을 위한 Postfix SMTP 서버 설정에 대한 이해도는 그보다 더 낮습니다. 하지만 완전한 초보자는 아니며, 이 설정을 안전하고 보안이 보장되는 방식으로 구성하는 것이 매우 어렵다는 것을 깨닫고 있습니다.

@maltfield 님, Open Source Ecology에 작성하신 글을 읽었습니다만, 포트 25를 통한 비인증 전송을 사용하고 싶지 않습니다. 제가 일하는 대학은 비암호화되고 비인증된 통신(이처럼 로컬 네트워크 환경에서도)에 대해 매우 엄격한 프로토콜을 적용하고 있습니다. 불만 있는 학생에 의해 악용될 수 있다는 우려 때문입니다.

10

결국 Discourse 서버와 SMTP 서버에 동일한 호스트명을 사용하는 것이 뭔가 이상하다는 것을 깨달았습니다.

추가 조사를 해보니 Docker 컨테이너가 hosts 파일에 다음 항목을 추가하고 있었습니다:

172.17.0.2	discourse.[mydomain].com discourse

따라서 실행 중인 컨테이너와 Docker 호스트에 동일한 호스트명을 사용하려고 하면, 컨테이너에서 발생한 모든 요청이 Docker 호스트가 아닌 컨테이너 자체로 전송됩니다.

정말 엉망이네요! 왜 Discourse는 컨테이너에 기본 SMTP 서버 설정을 제공하지 않는 걸까요?!
아니면 Docker 없이 Discourse를 사용하는 방법을 더 쉽게 만들어 주세요!

이 문제로 인해 제 인생의 이틀이 사라졌습니다.

11

결국, Docker 호스트에서 실행 중인 SMTP와 TLS를 사용하여 통신할 수 없다는 사실(다른 호스트명을 사용하여 인증서를 발급받지 않는 한)을 받아들였습니다. 마침내 이 문제를 해결하기 위해 Postfix의 main.cf 파일에서 mynetworks 변수에 172.17.0.0/16이 추가되었는지 확인해야 했습니다:

mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 172.17.0.0/16

이 설정을 통해 Postfix는 이 서버에서 실행 중인 모든 Docker 컨테이너를 네트워크의 일부로 인식할 수 있습니다.

또한 적용해야 했던 변경 사항은 smtpd_sasl_security_options가 noanonymous로 설정되어 있는지 확인하여 "낯선 사람들"이 Postfix를 SMTP 릴레이로 사용하지 못하도록 하는 것이었습니다. noplaintext 옵션이 여기에서 설정되어 있지 않도록 주의하십시오. 그렇지 않으면 Postfix는 TLS를 사용한 인증만 허용하게 됩니다.

smtpd_sasl_security_options = noanonymous

이러한 설정으로 인해 app.yml에 다음 설정을 지정할 수 있었습니다:

  DISCOURSE_SMTP_ADDRESS: 172.17.0.1                            # Docker 호스트의 IP 주소(이 컨테이너 내부에서 본 것)
  DISCOURSE_SMTP_PORT: 25
  DISCOURSE_SMTP_USER_NAME: discourse
  DISCOURSE_SMTP_PASSWORD: pa$$word
  DISCOURSE_SMTP_ENABLE_START_TLS: false           	             # (선택 사항, 기본값 true)
  DISCOURSE_SMTP_DOMAIN: discourse.[mydomian].com                # (일부 제공업체에서 요구)
  DISCOURSE_NOTIFICATION_EMAIL: noreply@discourse.[mydomain].com # (알림을 보내는 주소)

SASL 인증을 목적으로 Docker 호스트에 로컬 사용자 계정도 생성했습니다.
이러한 변경 사항 덕분에 마침내 컨테이너에서 이메일을 보낼 수 있게 되었지만, 이것이 최선의 구성이 아니라는 느낌이 듭니다. 이상적으로는 Docker 호스트에 원하는 호스트명을 사용하고 discourse.[mydomain].com에 대한 요청이 올바른 위치로 향하게 하는 것이 가능해야 합니다.

이제 SPF와 DKIM을 설정하여 이메일이 사람들의 스팸 폴더가 아닌 수신함으로 전달되도록 해야 합니다. 이 고통스러운 과정이 언젠가 더 자동화되기를 진심으로 바랍니다. Docker를 사용하지 않고 discourse를 구성하는 방법에 대한 지침을 제공하거나(예: cPanel과 함께 사용할 수 있도록) Docker 컨테이너 내에 기본 SMTP 구성을 직접 제공하여 메일 설정의 고통을 줄이는 방법도 고려해 볼 수 있습니다!

12

1990년대 초로 돌아가면 원하시는 대로였습니다. 말씀하신 것들은 모두 자동으로 작동했습니다. 하지만 스팸 메일 발송자들이 이 과정을 훨씬 더 복잡하게 만들었습니다. 이 과정은 점점 더 어려워질 것이므로, 이러한 복잡성 중 많은 부분을 대신 처리해 주는 서비스를 사용하는 것이 권장됩니다.

13

메일 설정이 정상적으로 작동하게 되어 기쁩니다!

어제 이후 이메일 문제 해결 가이드에 몇 가지 업데이트가 있었습니다. 여전히 메일 설정에 만족하지 못하신다면, 다시 한번 시도해 보시는 것을 추천합니다!

다음 방법으로 해결할 수 있습니다:

… 단지 도메인 이름에서 IP 주소로의 기본 DNS 해석 문제일 뿐입니다.

14

오해하지 마세요. SPF와 DKIM의 중요성은 충분히 이해하고 있습니다. 다만, 귀찮을 뿐입니다. 이런 것들이 이미 설정되어 있는 현재 cPanel 서버에 이걸 설치할 수 있으면 좋겠어요.

15

이것이 제가 빠져 있던 부분이었네요. 이제 TLS로 작동하고 있습니다.

DKIM도 설정을 마쳤으므로 더 이상 스팸 메일로 분류되지 않을 것입니다.