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).
Acabei de configurar um serviço de teste do Discourse usando o Digital Ocean e o Mailgun para e-mails de saída. Tenho um domínio registrado com um registro MX adequado apontando para o endereço IP do Digital Ocean. E-mails de saída e de entrada funcionam corretamente com o Discourse. Respostas a tópicos geram e-mails de saída para aqueles com notificações configuradas e usuários de teste podem responder a esses e-mails e as postagens aparecem no Discourse. Tudo bem até agora.
Tentei adicionar a opção POSTCONF_always_bcc: como acima, mas não parece funcionar - suspeito que a parte ‘mail-receiver’ do Discourse não consegue enviar o e-mail corretamente via Mailgun, embora a parte ‘app’ saiba como fazer - app.yml tem o nome de usuário e a senha do servidor Mailgun nele, mas não vi nenhum exemplo de como colocar essas informações no arquivo de configurações do mail-receiver.
Sei que a opção always_bcc está sendo lida e agida, pois se eu digitar:
./launcher enter mail-receiver
então executar
mailq
Posso ver uma mensagem de teste que enviei sentada na fila tentando ser entregue. Na coluna “-Sender/Recipient-------”, ela tem o endereço de onde veio minha mensagem de teste, as palavras “(unknown mail transport error)” e, em seguida, o endereço de e-mail que estava na configuração always_bcc.
Eu esperava filtrar as mensagens de entrada de alguma forma para que, se uma mensagem fosse enviada para postmaster@mydomain ou admin@mydomain, ela fosse reenviada pela internet pública, via Mailgun, para meu endereço do Gmail e não enviada ao Discourse para processamento. Isso pode ser o que o usuário @satonotdead estava tentando fazer.
Hmm. Sim, primeiro você precisará configurar o mailgun o receptor de e-mail para ter algum meio de entregar e-mails, pois ele não sabe sobre as credenciais ou o mecanismo de transporte em app.yml. Acho que você precisará adicionar uma configuração mais completa, como sugerido na próxima seção sobre montagem de volumes, cujos detalhes estão além do escopo deste documento.
A solução simples para “como lidar com e-mails de postmaster e admin” é criar um grupo para cada um e adicionar quem você quiser que receba esses e-mails a esse grupo, e eles poderão lidar com eles como mensagens de grupo.
Você quis dizer ‘mail-receiver’ em vez de Mailgun? Como ensinar ‘mail-receiver’ a falar com o Mailgun pela internet pública e passar as credenciais corretamente para pedir que ele faça as entregas reais?
Bem, sim, isso, ou de alguma outra forma, configurar o mail-receiver (ou seja, Postfix) para entregar e-mails de alguma forma. Sou, em grande parte, da opinião de que, se você souber como fazer isso, talvez prefira fazer isso em vez de usar o mail-receiver.
Outra solução seria ter algum processo <mail thing> processando o e-mail para domain e encaminhando o restante para o mail-receiver, talvez sob algum outro MX.
Depois de passar esta noite tentando inúmeras combinações, consegui instalar o postfix fora dos contêineres em que o Discourse é executado e posso enviar e-mails via Mailgun dessa forma a partir da linha de comando, então configurei o postfix para usar o Mailgun com sucesso. Ainda não consegui fazer com que as configurações no contêiner mail-receiver funcionem para retransmitir via Mailgun. Tenho certeza de que deve haver uma maneira (simples!). Não consigo encontrar nenhum log para descobrir por que as mensagens estão ficando presas na fila de e-mail. Contêineres não existiam da última vez que usei Linux (há vários anos). Existe uma maneira de ativar o registro para que eu possa ver qual comunicação o postfix está tentando realizar para que eu possa descobrir onde está o problema? Conceitualmente, eu gostaria que admin@mydomain, depois de recebido, fosse direto para minha conta pessoal do Gmail via Mailgun, com category1@mydomain e category2@mydomain etc. sendo enviados localmente para o Discourse para serem usados para criar postagens.
Podemos usar o “mail-receiver” fora dos contêineres do Discourse em outro VPS ou Datacenter?
A ideia é alterar o Endereço IP do Discourse para maior privacidade e usar um “mail-receiver” externo funcionando/autenticando com o fórum Discourse.
Normalmente, o banner EHLO deve corresponder ao MAIL_DOMAIN que, por sua vez, deve corresponder ao ponteiro DNS reverso (registro PTR). Portanto, se o meu mail-receiver estiver em discourse.example, o POSTCONF_myhostname deve ser discourse.example.
Qual é a maneira correta de configurar o banner EHLO?
Minha primeira intuição foi tentar definir HOSTNAME em mail-receiver.yml para que substituísse o host-mail-receiver.localdomain original em /etc/postfix/mail-receiver-environment.json. Mas isso não altera /etc/hostname nem myhostname na configuração do Postfix.
Estou tentado a usar POSTCONF_myhostname, mas temo que isso tenha efeitos colaterais indesejados, pois $myhostname é usado em vários lugares e, em seguida, não corresponderia mais a /etc/hostname.
Há uma configuração que o Discourse-setup solicita. Não me lembro do nome e é difícil de encontrar no meu telefone. Você pode olhar o código-fonte ou executá-lo.
A configuração do Postfix smtp_helo_name altera o nome especificado no comando HELO (ou EHLO), mas essa é uma configuração de entrega de saída, enquanto o banner SMTP é enviado ao receber e-mail. O nome de host padrão especificado nisso é obtido de myhostname, mas você pode modificar o banner para exibir algo diferente com a configuração smtpd_banner.
Não sei se isso ajudará outras pessoas, eu estava tendo um problema semelhante e isso me ajudou a perceber que, por algum motivo, eu havia revogado a chave da API. Assim que desfiz a revogação, o e-mail de entrada voltou a funcionar.
Então, obrigado por me ajudar a perceber que estava relacionado à chave da API
Algo mudou desde que isso foi escrito? Acabei de descobrir que adicionar um valor POSTCONF_smtpd_banner em env: absolutamente não foi captado por múltiplos reinícios. Tive que reconstruir (./launcher rebuild mail-receiver) para que ele entrasse em vigor.
