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).
Ho appena configurato un servizio di prova Discourse utilizzando Digital Ocean e Mailgun per lâinvio di e-mail. Ho un dominio registrato con un record MX appropriato che punta allâindirizzo IP di Digital Ocean. Lâinvio e la ricezione di e-mail funzionano correttamente con Discourse. Le risposte agli argomenti generano e-mail in uscita per coloro che hanno impostato le notifiche e gli utenti di prova possono rispondere a queste e-mail e i post appaiono in Discourse. Fin qui tutto bene.
Ho provato ad aggiungere lâopzione POSTCONF_always_bcc: come sopra, ma non sembra funzionare - sospetto che la parte âmail-receiverâ di Discourse non sia in grado di inviare correttamente lâe-mail tramite Mailgun, anche se la parte âappâ conosce come farlo - app.yml contiene il nome utente e la password del server Mailgun, ma non ho visto esempi su come inserire queste informazioni nel file delle impostazioni di mail-receiver.
So che lâopzione always_bcc viene letta e applicata, poichĂŠ se digito:
./launcher enter mail-receiver
quindi eseguo
mailq
Posso vedere un messaggio di prova che ho inviato in coda in attesa di essere consegnato. Nella colonna â-Sender/Recipient-------â ha lâindirizzo da cui proveniva il mio messaggio di prova, le parole â(unknown mail transport error)â e quindi lâindirizzo e-mail che avevo nellâimpostazione always_bcc.
Speravo di poter filtrare i messaggi in arrivo in modo che se un messaggio veniva inviato a postmaster@mydomain o admin@mydomain venisse reinviato su Internet pubblico, tramite Mailgun, al mio indirizzo Gmail e non inviato a Discourse per lâelaborazione. Questo potrebbe essere ciò che lâutente @satonotdead stava cercando di fare.
Qualsiasi suggerimento è apprezzato su come fare!
Hmm. SĂŹ, prima dovrai configurare il mailgun il ricevitore di posta per avere un qualche mezzo per recapitare la posta, poichĂŠ non conosce le credenziali o il meccanismo di trasporto in app.yml. Penso che dovrai aggiungere una configurazione piĂš completa, come suggerito nella sezione successiva sul montaggio dei volumi, i cui dettagli vanno oltre lo scopo di questo documento.
La soluzione semplice per âcome gestire le e-mail di postmaster e adminâ è creare un gruppo per ciascuna e aggiungere chiunque desideri ricevere tali e-mail a quel gruppo, e potranno gestirle come messaggi di gruppo.
Intendevi âmail-receiverâ invece di Mailgun? Come insegnare a âmail-receiverâ a parlare con Mailgun tramite Internet pubblico e passare correttamente le credenziali per chiedere di effettuare le consegne effettive?
Beh sĂŹ, quello, o in qualche altro modo, configurare il mail-receiver (cioè Postfix) per consegnare la posta in qualche modo. Sono principalmente dellâopinione che se sai come farlo, potresti piuttosto farlo piuttosto che usare il mail-receiver.
Unâaltra soluzione sarebbe avere un processo \u003cmail thing\u003e che elabori la posta per domain e inoltri il resto al mail-receiver, forse sotto qualche altro MX.
Dopo aver passato la serata a provare numerose combinazioni, sono riuscito a installare postfix al di fuori dei container in cui Discourse è in esecuzione e posso inviare e-mail tramite Mailgun da riga di comando, quindi ho configurato postfix per utilizzare Mailgun con successo. Sto ancora brancolando nel buio cercando di inserire le impostazioni nel container mail-receiver che faranno funzionare lâinoltro tramite Mailgun. Sono sicuro che ci deve essere un modo (semplice!). Non riesco a trovare alcun log per capire perchĂŠ i messaggi rimangono bloccati nella coda di posta. I container non esistevano lâultima volta che ho usato Linux (diversi anni fa). Câè un modo per attivare il logging in modo da poter vedere quale comunicazione postfix sta cercando di tentare per capire qual è il problema? Concettualmente, vorrei che admin@mydomain, una volta arrivato, uscisse direttamente sul mio account Gmail personale tramite Mailgun, mentre category1@mydomain e category2@mydomain ecc. vengano inoltrati localmente a Discourse per creare post.
Possiamo usare il âmail-receiverâ al di fuori dei container Discourse in un altro VPS o data center?
Lâidea è di cambiare lâindirizzo IP di Discourse per una maggiore privacy e utilizzare un âmail-receiverâ esterno che funzioni/autentichi con il forum Discourse.
Normalmente, il banner EHLO dovrebbe corrispondere a MAIL_DOMAIN che a sua volta dovrebbe corrispondere al puntatore DNS inverso (record PTR). Quindi, se il mio mail-receiver viene eseguito su discourse.example, allora POSTCONF_myhostname dovrebbe essere discourse.example.
Qual è il modo corretto per configurare il banner EHLO?
La mia prima intuizione è stata quella di provare a impostare HOSTNAME in mail-receiver.yml in modo che sostituisse lâoriginale host-mail-receiver.localdomain in /etc/postfix/mail-receiver-environment.json. Ma questo non cambia /etc/hostname nĂŠ cambia myhostname nella configurazione di Postfix.
Sono tentato di usare POSTCONF_myhostname ma temo che avrĂ effetti collaterali indesiderati poichĂŠ $myhostname viene utilizzato in diversi punti e quindi non corrisponderebbe piĂš a /etc/hostname.
Câè unâimpostazione che Discourse-setup richiede. Non ricordo il suo nome ed è difficile da trovare sul mio telefono. Puoi guardare il codice sorgente o eseguirlo.
Lâimpostazione Postfix smtp_helo_name modifica il nome specificato nel comando HELO (o EHLO), ma questa è unâimpostazione di consegna in uscita, mentre il banner SMTP viene inviato quando si riceve posta. Lâhostname predefinito specificato in questo viene preso da myhostname, ma è possibile modificare il banner per visualizzare qualcosa di diverso con lâimpostazione smtpd_banner.
Non sono sicuro se questo aiuterĂ altri, stavo riscontrando un problema simile e questo mi ha aiutato a capire che per qualche motivo avevo revocato la chiave API. Una volta annullata la revoca, la posta in arrivo ha ricominciato a funzionare.
Quindi grazie per avermi aiutato a capire che era correlato alla chiave API
Qualcosa è forse cambiato da quando è stato scritto questo? Ho appena scoperto che lâaggiunta di un valore POSTCONF_smtpd_banner sotto env: non è stata assolutamente recepita da molteplici riavvii. Ho dovuto ricostruire (./launcher rebuild mail-receiver) per farlo entrare in vigore.
