Se você possui um contêiner de receptor de e-mail que exige configuração personalizada do Postfix, este tópico é para você. Aqui estão descritos os passos necessários para definir as variáveis de configuração do arquivo main.cf do Postfix conforme desejar.
As variáveis de configuração do Postfix podem ser definidas via variáveis de ambiente do contêiner. Qualquer variável de ambiente que comece com POSTCONF_ definirá uma variável de configuração do Postfix cujo nome corresponde ao restante da variável de ambiente, com o valor definido por ela. Por exemplo, se você definir a variável de ambiente POSTCONF_always_bcc como bob@example.com, o Postfix será configurado com always_bcc = bob@example.com, o que enviará uma cópia de todos os e-mails recebidos para o Bob. Pobre Bob.
Procedimento
Descubra quais variáveis de configuração deseja definir e quais valores atribuir a elas. Isso pode ser feito lendo o manual oficial, seguindo recomendações em outra documentação do Discourse ou por outros meios.
Conecte-se ao seu servidor Discourse via SSH, obtenha privilégios de root e vá até o diretório onde reside toda a configuração do discourse-docker:
ssh ubuntu@192.0.2.42
sudo -i
cd /var/discourse
Abra o arquivo containers/mail-receiver.yml no editor de texto de sua preferência e desça até a seção env:. Em algum lugar ali, adicione entradas para as variáveis que deseja incluir, tomando cuidado para não modificar nada além disso e mantendo a indentação adequada. Por exemplo, se estivéssemos adicionando nossa configuração always_bcc, o arquivo poderia ficar mais ou menos assim:
Assim que estiver satisfeito com o que adicionou, salve e saia do editor.
Para carregar a configuração, basta reiniciar o contêiner mail-receiver (uma rebuildnão é necessária):
./launcher restart mail-receiver
Após um breve espasmo, o contêiner deverá estar rodando novamente.
Teste suas alterações. Certifique-se de que o que você queria que acontecesse, de fato, aconteceu, e também de que nada que você não esperava que mudasse, mudou.
Adendo: adicionando arquivos ao contêiner mail-receiver
Muitos parâmetros de configuração do Postfix exigem acesso a “arquivos de banco de dados”, que fornecem informações de chave/valor que o Postfix usa para tomar decisões sobre o que fazer com os e-mails. Se você vir que um parâmetro de configuração aceita um nome de arquivo que se parece com hash:/algum/arquivo, você encontrou um uso para arquivos de banco de dados.
O problema é que o Postfix rodando dentro do contêiner precisa conseguir acessar esses arquivos enquanto estiver em execução, o que significa que você precisa ou copiar esses arquivos para dentro do contêiner, ou (preferencialmente) colocá-los em um diretório no host e, em seguida, montar esse diretório como um volume dentro do contêiner. Estas instruções descrevem o segundo método.
Uma vez que você concluiu este procedimento, qualquer arquivo que você colocar em /var/discourse/shared/mail-receiver/etc ficará imediatamente visível em /etc/postfix/shared dentro do contêiner, e quaisquer alterações que você fizer nesses arquivos serão imediatamente visíveis para o Postfix.
Veja como fazer isso acontecer.
Se você ainda não estiver logado como root no seu servidor Discourse, faça-o novamente:
ssh ubuntu@192.0.2.42
sudo -i
cd /var/discourse
Abra o arquivo containers/mail-receiver.yml no editor de texto de sua preferência e, desta vez, vá até a seção volume:. Abaixo da definição existente para o diretório /var/spool/postfix, adicione outra, de modo que sua seção volume fique assim:
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.
Acabei de concluir uma migração de domínio (conforme Change the domain name or rename your Discourse), que correu muito bem. No entanto, estou usando o contêiner mail-receiver com registros MX para e-mail de entrada para algumas categorias…
Pelo que vejo, a configuração padrão do contêiner codifica o domínio de entrada e o caminho para os certificados LetsEncrypt. É possível permitir dois domínios, seja na configuração ou através destas opções avançadas?
