우리는 자체 이메일 서버를 구축했고, Discourse Docker 컨테이너와 이를 가장 효율적으로 사용하는 방법에 대해 궁금했습니다.
물론 SMTP 세부 정보와 자격 증명을 설정하는 것만으로 충분하지만, SMTP 서버가 동일한 머신에서 실행되고 있으므로 불필요한 오버헤드처럼 느껴집니다.
sendmail은 작동하지만, Discourse는 컨테이너 내에서 실행되므로 호스트의 sendmail에 접근할 수 없습니다.
이 포럼에서 검색해 보면, DISCOURSE_SMTP_DOMAIN을 자격 증명 없이 사용한 예시가 하나 있습니다. 컨테이너 내에서 swaks를 사용하여 동일한 작업을 수행하면 작동합니다: How to get Discourse to work with Postfix - #18 by sonmicrosystems
아마도 그 경우에도 기본 포트에서 정상적인 SMTP 제출이 이루어지고, 요청이 localhost에서 온다는 이유로 Postfix가 인증 없이 이를 수용하는 것 같습니다.
GUI에서 이 설정을 변경할 수 없는데, 아마도 컨테이너 YAML이 DISCOURSE_SMTP_ADDRESS 등을 통해 이를 강제하기 때문인 것 같습니다. 하지만 전달 방법에 대한 변수는 찾을 수 없습니다.
아마도 다른 방법을 아는 사람이 있을 것입니다. 그 때까지 저는 정상적인 SMTP 제출 포트 인증을 설정할 예정입니다.顺便说一下, 최근에 추가되었지만 아직 샘플에 포함되어 있지 않은(포함되어야 하지만) DISCOURSE_SMTP_FORCE_TLS에 감사드립니다. 저는 STARTTLS를 허용할 의도는 없으며, 암시적/즉시 TLS만 허용할 계획입니다.
Unnecessary Overhead how? You gotta send the data from Discourse to the SMTP server somehow? No?
Ps: if it is another container, You could in theory use bridge network and use the smtp container name instead of hostname if that’s what You’re after but it won’t give you any performance advantages.
There are two ways to send out emails through a local SMTP server:
connect to and authenticate at the submission port, like 587 with STARTTLS or 465 with implicit/immediate TLS => network request, checks and restrictions applied via smtpd
use sendmail or similar, which invokes the local pickup command (in case of Postfix), not doing any network connection, and bypassing all checks and restrictions configured for smtpd submission service.
The latter is simpler and faster, implemented into common runtime systems and frameworks, like PHP mailer and this Ruby mail library used by Discourse. And authentication is bypassed, no plain text credentials need to be stored anywhere. Or in other words: the SMTP server is not used at all in this case, but only the SMTP client.
I mean yeah, the submission port connection stuff should not have any significant impact on server load, compared to what Discourse otherwise does. The latter point can be solved with e.g. smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject rule at the submission port, to permit submissions from loopback IPs (default, mynetworks setting) before doing any authentication. If the request from the container is seen with another IP, it can be added to mynetworks. I guess this is how it worked in case of the topic I linked before.
Will see next time we update/rebuild our Discourse, when hence changed SMTP settings are applied. Will report back how it works.
But would be still interesting to know whether there are other ways, and what this “Delivery method” setting is about.
Postfix runs on the host, not inside a container, but it would not make much difference, as it remains a network-based authentication.
Yeah, a thought later, it just makes sense that sendmail etc from host/other container cannot work inside a container, as it requires direct access to vast parts of Postfix executables, libraries, and configs, I suppose. Unless there is sort of a magic socket which can be bind-mounted into the container or so .
It has been a while since I have gone this deep into micro managing sendmail. I have mailcow stack on one VM and Discourse on another. I don’t know if it will ever be worth digging that deep besides just for the fun of it.
I wish you all the best with your adventures, report back what you learned.
Probably not . But I am perfectionist in certain context, and I enjoy digging deep and learning all details. Took me several evenings to setup Dovecot, Postfix, rspamd, dkimpy-milter, PostSRSd, … step by step, learning about almost every setting available, why defaults are like this, whether and why we might want it differently etc. But hey, now I seem to understand most things better than most authors of arbitrary email server guides around .
I am moving this topic to #installation:hosting. We don’t recommend trying to host your own email server, as you know if you read the official install instructions. Email is hard!
Not sure what Discourse has to do with whether the system may additionally hosts an email server or not? Aside of that fact that this theoretically opens another way to send out emails, of course.
For receiving emails (other topic) however it has an effect, since one cannot host the email receiver container then, at least not to listen on port 25 directly. But using the email receiver API of Discourse directly turned out to be just a 2-3 lines in the Postfix config: Is there a way to only IMAP polling for incoming emails - #2 by MichaIng
But I agree, setting up the email server properly was not exactly an easy task, as mentioned above. But super interesting to learn .
Yes! It is challenging and interesting, for sure. I’ve been through my own adventures installing all kinds of services and trying to run them myself, in a former life!
Happy to have you update this topic with your learnings for the benefit of intrepid future travelers, including yourself. But keep in mind that the Support category is for supported installs, discourse core and official plugins and components.
Postfix에는 어떤 문제가 있는 것일까요? 제가 처음 읽은 메일 서버 설정 가이드에 포함되어 있었고, 파이프라인 초기 단계에서 스팸과 봇 접근을 줄이기 위한 내부 필터 옵션이 좋은 근거로 보였기 때문입니다.
자, 약간 주제에서 벗어난 이야기이지만, Discourse의 sendmail/pickup 사용에 대해 말씀드리자면.
이 문제를 해결/답변 완료로 표시하겠습니다. 어떤 서버를 사용하든 Discourse 컨테이너가 호스트의 sendmail에 접근할 수 없다는 것은 당연한 일입니다. 따라서 SMTP 제출(submission)을 사용해야 하며, 이를 위해 Postfix에서 Docker 컨테이너 IP 범위로 인증을 수행할 수 있고, Dovecot에서는 passdb/userdb 인증을 건너뛸 수 있습니다.
.
. But I am perfectionist in certain context, and I enjoy digging deep and learning all details. Took me several evenings to setup Dovecot, Postfix, rspamd, dkimpy-milter, PostSRSd, … step by step, learning about almost every setting available, why defaults are like this, whether and why we might want it differently etc. But hey, now I seem to understand most things better than most authors of arbitrary email server guides around 
.
.