Se hai un container di ricezione della posta che richiede una configurazione Postfix personalizzata, questo è l’argomento giusto per te. Qui vengono descritti i passaggi necessari per impostare le variabili di configurazione main.cf di Postfix a tuo piacimento.
Le variabili di configurazione di Postfix possono essere impostate tramite le variabili d’ambiente del container. Qualsiasi variabile d’ambiente che inizia con POSTCONF_ imposterà una variabile di configurazione Postfix il cui nome corrisponde al resto della variabile d’ambiente, con il valore della variabile stessa. Ad esempio, se imposti la variabile d’ambiente POSTCONF_always_bcc su bob@example.com, Postfix verrà configurato con always_bcc = bob@example.com, il che invierà una copia di tutta la posta in arrivo a Bob. Povero Bob.
Procedura
Determina quali variabili di configurazione desideri impostare e quali valori assegnare loro. Questo può essere fatto leggendo il manuale, seguendo le raccomandazioni nella documentazione di Discourse o in altro modo.
Connettiti al tuo server Discourse via SSH, acquisisci i privilegi di root e dirigiti nella directory dove risiede la configurazione discourse-docker:
ssh ubuntu@192.0.2.42
sudo -i
cd /var/discourse
Apri containers/mail-receiver.yml con il tuo editor di testo preferito e scendi alla sezione env: del file. Aggiungi in quel punto le voci per le variabili che desideri includere, facendo attenzione a non modificare nulla di altro e mantenendo un’indentazione corretta. Ad esempio, se stiamo aggiungendo l’impostazione always_bcc, il file potrebbe apparire così:
Una volta soddisfatto di quanto aggiunto, salva ed esci dall’editor.
Per caricare la configurazione, è sufficiente riavviare il container mail-receiver (non è necessario un rebuild):
./launcher restart mail-receiver
Dopo un breve riavvio, il container dovrebbe essere di nuovo in esecuzione.
Verifica le tue modifiche. Assicurati che quanto desiderato si sia effettivamente verificato e che nulla di inaspettato sia cambiato.
Aggiunta: aggiunta di file al container mail-receiver
Molti parametri di configurazione di Postfix richiedono l’accesso a “file di database”, che forniscono informazioni chiave/valore utilizzate da Postfix per prendere decisioni su come gestire la posta. Se noti che un parametro di configurazione accetta un nome file simile a hash:/some/file, hai trovato un caso d’uso per i file di database.
Il fatto è che Postfix, in esecuzione all’interno del container, deve poter accedere a questi file durante l’esecuzione. Ciò significa che devi copiare i file nel container o, preferibilmente, collocarli in una directory sull’host e montare tale directory come volume all’interno del container. Queste istruzioni descrivono il secondo metodo.
Una volta completata questa procedura, qualsiasi file posizionato in /var/discourse/shared/mail-receiver/etc sarà immediatamente visibile in /etc/postfix/shared all’interno del container, e qualsiasi modifica apportata a tali file sarà immediatamente visibile a Postfix.
Ecco come procedere.
Se non sei ancora connesso come root al tuo server Discourse, fallo di nuovo:
ssh ubuntu@192.0.2.42
sudo -i
cd /var/discourse
Apri containers/mail-receiver.yml con il tuo editor di testo preferito e, questa volta, dirigiti alla sezione volume:. Sotto la definizione esistente per la directory /var/spool/postfix, aggiungetene un’altra, in modo che la sezione volume appaia così:
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.
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.
Ho appena completato una migrazione di dominio (come da Change the domain name or rename your Discourse) che è andata benissimo. Tuttavia, sto utilizzando il container mail-receiver con record MX per la posta in arrivo su un paio di categorie…
Per quanto ne so, la configurazione predefinita del container codifica in modo fisso sia il dominio in entrata che il percorso per i certificati LetsEncrypt. È possibile consentire due domini, o nella configurazione, o tramite queste opzioni avanzate?
