If you have a mail receiver container which requires customised Postfix configuration, this is the topic for you. Herein are described the steps required to set Postfix main.cf configuration variables to whatever your heart desires.
Postfix configuration variables can be set via the container environment. Any environment variable starting with POSTCONF_ will set a Postfix configuration variable named for the rest of the environment variable to the value of the environment variable. For example, if you set the environment variable POSTCONF_always_bcc to bob@example.com, then Postfix will be configured with always_bcc = bob@example.com, which will send a copy of all incoming mail to Bob. Poor Bob.
Procedure
Figure out what configuration variables you want to set, and what values to set them to. This may be done by reading the fine manual, or through recommendations in other Discourse documentation, or otherwise.
Connect to your Discourse server via SSH, grab some root privileges, and head over to where all the discourse-docker configuration lives:
ssh ubuntu@192.0.2.42
sudo -i
cd /var/discourse
Open up containers/mail-receiver.yml in your text editor of choice, and swing down to the env: section of the file. Somewhere in there, add entries for the variables you want to add, being careful to not modify anything else, and maintaining appropriate indenting. For example, if we were adding our always_bcc setting, the file might look a bit like this:
Once youâre happy with what youâve added, save and exit your editor.
To load the configuration, you simply have to restart the mail-receiver container (a rebuild is not required):
./launcher restart mail-receiver
After a brief spasm, the container should be running again.
Test your changes. Ensure both that what you wanted to have happen has, indeed, happened, and also that nothing you didnât expect to change hasnât.
Addendum: adding files to the mail-receiver container
Many Postfix configuration parameters require access to âdatabase filesâ, which provide key/value information which Postfix uses to make decisions about what do with mail. If you see that a configuration parameter accepts a filename that looks like hash:/some/file, youâve found a use for database files.
The thing is, Postfix running inside the container needs to be able to get at those files while itâs running, which means you need to either copy those files into the container, or (preferably) put those files into a directory on the host, and then mount that directory as a volume inside the container. These instructions describe the second method.
Once you have completed this procedure, any file you place into /var/discourse/shared/mail-receiver/etc will immediately become visible at /etc/postfix/shared inside the container, and any changes you make to those files will be immediately visible to Postfix.
Hereâs how to make it happen.
If youâre not still logged in as root to your Discourse server, do so again:
ssh ubuntu@192.0.2.42
sudo -i
cd /var/discourse
Open up containers/mail-receiver.yml in your text editor of choice, and this time head for the volume: section. Underneath the existing definition for the /var/spool/postfix directory, add another one, so that your volume section looks like this:
Matt, do you think that could be possible to enable accounts like admin@domain or info@domain from this Postfix configuration?
I only need to have a couple of addresses for incoming e-mail and I have it working with Discourse but I canât set accounts (their seem to be blocked by default even though messages are processed).
Iâve just set up a trial Discourse service using Digital Ocean and Mailgun for outgoing e-mail. I have a domain registered with a suitable MX record pointing to the Digital Ocean IP address. Outgoing and incoming e-mail works correctly with Discourse. Replies to topics generate outgoing e-mails to those with notifications set and test users can reply to these e-mails and the posts appear in Discourse. All good so far.
I tried to add the POSTCONF_always_bcc: option as above but it doesnât seem to work - I suspect the âmail-receiverâ part of Discourse is unable to properly send the e-mail via Mailgun, even though the âappâ part knows how to - app.yml has the username and password of the Mailgun server in it but Iâve not seen any examples of how to put this information in the mail-receiver settings file.
I know the always_bcc option is being read and acted upon as if I type:
./launcher enter mail-receiver
then run
mailq
I can see a test message I sent message sitting on the queue trying to be delivered. In the â-Sender/Recipient-------â column it has the address from which my test message came, the words â(unknown mail transport error)â and then the e-mail address that I had in the always_bcc setting.
I had hoped to somehow filter incoming messages so that if a message was sent to postmaster@mydomain or admin@mydomain it would get resent out on the public internet, via Mailgun, to my gmail address and not sent to Discourse for processing. This may be what user @matenauta was trying to do.
Hmm. Yes, first youâll need to configure the mailgun the mail receiver to have some means for delivering mail, as it doesnât know about the credentials or transport mechanism in app.yml. I think youâll need to add a more complete configuration as hinted in the next section about mounting volumes, the details of which are beyond the scope of this document.
The simple solution for âhow do I deal with postmaster and admin emailsâ is to create a group for each and add whoever you want to get those emails to that group and they can deal with them as group messages.
Did you mean âmail-receiverâ rather than Mailgun? As in teach âmail-receiverâ how to speak to Mailgun via the public internet and pass credentials properly to ask it to perform the actual deliveries?
Well yes, that, or in some other fashion, configure the mail-receiver (i.e., Postfix) to deliver mail somehow. Iâm mostly of the opinion that if you know how to do that then you might rather just do that rather than use the mail-receiver.
Another solution would be to have some <mail thing> process the mail for domain and forward the rest to the mail receiver, perhaps under some other MX.
Having spent this evening trying numerous combinations Iâve managed to install postfix outside the containers that Discourse runs in and can send e-mail via Mailgun that way from the command line, so I have configured postfix to us Mailgun successfully. Iâm still drawing a blank trying to get the settings into the mail-receiver container that will make the relaying work via Mailgun. Iâm sure there must be a (simple!) way. I canât seem to find any logs to find out why messages are getting stuck on the mail queue. Containers werenât around the last time I used linux (a number of years ago). Is there a way of turning on logging so I can see what communication postfix is trying to attempt so I can figure out where the problem is? Conceptually I would like admin@mydomain, once it has come in, to go straight out to my personal gmail account via Mailgun with category1@mydomain and category2@mydomain etc to get pushed on locally to discourse to use to create posts.
Normally, the EHLO banner should match the MAIL_DOMAIN which in turn is supposed to match the reverse DNS pointer (PTR record). So if my mail-receiver runs at discourse.example, then the POSTCONF_myhostname should be discourse.example.
What is the right way to configure the EHLO banner?
My first intuition was to try setting HOSTNAME in mail-receiver.yml so it would replace the original host-mail-receiver.localdomain in /etc/postfix/mail-receiver-environment.json. But this does not change /etc/hostname nor does it change myhostname in the Postfix configuration.
Iâm tempted to use POSTCONF_myhostname but I fear it will have unwanted side-effects since $myhostname is used in several places and then it would not match /etc/hostname anymore.
There is a setting that Discourse-setup asks for. I canât remember itâs name and itâs hard to find on my phone. You can look at the source or run it.
The Postfix setting smtp_helo_name changes the name specified in the HELO (or EHLO) command, but that is an outgoing delivery setting, while the SMTP banner is sent when receiving mail. The default hostname specified in that is taken from myhostname, but you can modify the banner to display something different with the smtpd_banner setting.
Not sure if this will help others, I was getting a similar problem and this helped me realize that for some reason I had revoked the API key. Once I undid the revoke, the incoming mail was working again.
So thank you for helping me realize it was related to the API key
Has something maybe changed since this was written? I just found that adding a POSTCONF_smtpd_banner value under env: was absolutely not picked up by multiple restarts. I had to rebuild (./launcher rebuild mail-receiver) to get it to take effect.