We set up our own email server, and I was wondering how to use it best with the Discourse Docker container. Of course I can just configure our SMTP details and credentials, but it feels like unnecessary overhead, since the SMTP server runs on the same machine. sendmail works, but Discourse is in the container, hence has no access to sendmail on its host. Searching for something here in the forum gives one example where DISCOURSE_SMTP_DOMAIN was used without credentials, where doing the same with swaks within the container works: How to get Discourse to work with Postfix - #18 by sonmicrosystems I guess in that case, it is still normal SMTP submission on default port, and Postfix accepts it without authentication, since the request comes from localhost? Is anyone aware of another method? I see the used Ruby library generally supports everything: GitHub - discourse/mail: A Really Ruby Mail Library · GitHub In Discourse settings, what caught my eyes is a field Delivery method: [image] I cannot change these settings in the GUI, I guess because the container YAML enforces them via DISCOURSE_SMTP_ADDRESS etc? But I cannot find a variable for the delivery method. Maybe someone knows another way, and until then, I’m setting up normal SMTP submission port authentication. Thanks for DISCOURSE_SMTP_FORCE_TLS btw, added more recently, but not part of any sample yet (it should). I do not intend to allow STARTTLS, but only implicit/immediate TLS.

What’s wrong with Postfix? It was part of the first mail server setup guide I read, and its internal filter options to reduce spam and bot access early in the pipeline seemed a good argument. Well, kinda off topic, regarding sendmail/pickup usage from Discourse. Marking this as solved/answered. It makes sense that the Discourse container cannot access the host’s sendmail, no matter which server. So it needs to use SMTP submission, for which one can authenticate e.g. via Docker container IP range in Postfix, skipping passdb/userdb authentication on Dovecot.

[image] MichaIng: it feels like unnecessary overhead, since the SMTP server runs on the same machine. 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.

[image] itsbhanusharma: Unnecessary Overhead how? You gotta send the data from Discourse to the SMTP server somehow? No? 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. [image] itsbhanusharma: 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. 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 :smile:.

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.

[image] itsbhanusharma: I don’t know if it will ever be worth digging that deep besides just for the fun of it. Probably not :sweat_smile:. 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 :face_with_tongue:.

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 :slightly_smiling_face:.

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! :upside_down_face: 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.

[image] MichaIng: Dovecot, Postfix what. Dovecoat good. Why then postfix? Why not dovecoat exim?

Use local email server/sendmail for outgoing emails?

Product Support Self-hosting

nineb September 29, 2025, 9:29am 9

what. Dovecoat good. Why then postfix? Why not dovecoat exim?

Topic		Replies	Views
Connecting to a SMTP server on localhost:25 without auth? Self-hosting email	14	9644	February 14, 2022
Using Postfix with Discourse Self-hosting	8	1989	July 14, 2020
How to get Discourse to work with Postfix Self-hosting	17	2812	November 4, 2021
SMTP issue with Postfix Self-hosting	2	1516	December 21, 2018
Amigo tengo una pregunta sobre correos Self-hosting email , hosting	6	273	November 9, 2025

Use local email server/sendmail for outgoing emails?

Related topics