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).
J’ai vient de configurer un service d’essai Discourse en utilisant Digital Ocean et Mailgun pour les e-mails sortants. J’ai un domaine enregistré avec un enregistrement MX approprié pointant vers l’adresse IP de Digital Ocean. Les e-mails sortants et entrants fonctionnent correctement avec Discourse. Les réponses aux sujets génèrent des e-mails sortants à ceux qui ont des notifications activées et les utilisateurs de test peuvent répondre à ces e-mails et les messages apparaissent dans Discourse. Tout va bien jusqu’à présent.
J’ai essayé d’ajouter l’option POSTCONF_always_bcc : comme ci-dessus, mais cela ne semble pas fonctionner - je soupçonne que la partie ‘mail-receiver’ de Discourse est incapable d’envoyer correctement l’e-mail via Mailgun, même si la partie ‘app’ connaît le nom d’utilisateur et le mot de passe du serveur Mailgun - app.yml contient le nom d’utilisateur et le mot de passe du serveur Mailgun, mais je n’ai vu aucun exemple sur la façon de mettre ces informations dans le fichier de configuration de mail-receiver.
Je sais que l’option always_bcc est lue et traitée car si je tape :
./launcher enter mail-receiver
puis j’exécute
mailq
Je peux voir un message de test que j’ai envoyé, en attente dans la file d’attente pour être livré. Dans la colonne “-Sender/Recipient-------”, il y a l’adresse d’où provenait mon message de test, les mots “(unknown mail transport error)” et ensuite l’adresse e-mail que j’avais dans le paramètre always_bcc.
J’espérais pouvoir filtrer les messages entrants de manière à ce que si un message était envoyé à postmaster@mydomain ou admin@mydomain, il soit renvoyé sur Internet public, via Mailgun, à mon adresse Gmail et non envoyé à Discourse pour traitement. C’est peut-être ce que l’utilisateur @satonotdead essayait de faire.
Toute aide est appréciée pour savoir comment faire cela !
Hmm. Oui, vous devrez d’abord configurer le récepteur de courrier (et non plus mailgun) pour qu’il dispose d’un moyen de délivrer le courrier, car il ne connaît pas les informations d’identification ou le mécanisme de transport dans app.yml. Je pense que vous devrez ajouter une configuration plus complète, comme suggéré dans la section suivante concernant le montage de volumes, dont les détails dépassent le cadre de ce document.
La solution simple pour « comment gérer les e-mails de postmaster et admin » est de créer un groupe pour chacun et d’ajouter à ce groupe toutes les personnes qui doivent recevoir ces e-mails, et elles pourront les gérer en tant que messages de groupe.
Vouliez-vous dire « récepteur de courrier » plutôt que Mailgun ? Comme apprendre à « récepteur de courrier » à parler à Mailgun via Internet et à transmettre correctement les informations d’identification pour lui demander d’effectuer les livraisons réelles ?
Eh bien oui, cela, ou d’une autre manière, configurer le mail-receiver (c’est-à-dire Postfix) pour livrer le courrier d’une manière ou d’une autre. Je suis plutôt d’avis que si vous savez comment faire cela, vous pourriez plutôt le faire plutôt que d’utiliser le mail-receiver.
Une autre solution serait d’avoir un processus \u003cmail thing\u003e qui traite le courrier pour domain et transmet le reste au mail-receiver, peut-être sous un autre MX.
Après avoir passé la soirée à essayer de nombreuses combinaisons, j’ai réussi à installer postfix en dehors des conteneurs dans lesquels Discourse s’exécute et je peux envoyer des e-mails via Mailgun de cette façon depuis la ligne de commande. J’ai donc configuré postfix pour utiliser Mailgun avec succès. Je ne parviens toujours pas à intégrer les paramètres dans le conteneur mail-receiver qui permettront au relais de fonctionner via Mailgun. Je suis sûr qu’il doit y avoir un moyen (simple !). Je n’arrive pas à trouver de journaux pour savoir pourquoi les messages restent bloqués dans la file d’attente des e-mails. Les conteneurs n’existaient pas la dernière fois que j’ai utilisé Linux (il y a plusieurs années). Existe-t-il un moyen d’activer la journalisation afin que je puisse voir quelle communication postfix essaie de tenter pour que je puisse identifier le problème ? Conceptuellement, j’aimerais que admin@mydomain, une fois reçu, soit directement envoyé à mon compte Gmail personnel via Mailgun, tandis que category1@mydomain et category2@mydomain, etc., soient poussés localement vers Discourse pour créer des publications.
Pouvons-nous utiliser le « mail-receiver » en dehors des conteneurs Discourse, sur un autre VPS ou centre de données ?
L’idée est de changer l’adresse IP de Discourse pour plus de confidentialité et d’utiliser un « mail-receiver » externe fonctionnant/s’authentifiant avec le forum Discourse.
Oui. Je fais exactement cela. J’ai le récepteur de courrier en cours d’exécution sur DigitalOcean et Discourse sur des machines dans un autre centre de données.
Rien de spécial n’est requis pour configurer le récepteur de courrier sur un serveur, tant qu’il dispose de Docker et d’un accès aux ports nécessaires.
Normalement, la bannière EHLO doit correspondre au MAIL_DOMAIN qui, à son tour, est censé correspondre au pointeur DNS inversé (enregistrement PTR). Donc, si mon mail-receiver fonctionne sur discourse.example, alors le POSTCONF_myhostname devrait être discourse.example.
Quelle est la bonne façon de configurer la bannière EHLO ?
Ma première intuition a été d’essayer de définir HOSTNAME dans mail-receiver.yml afin qu’il remplace le host-mail-receiver.localdomain d’origine dans /etc/postfix/mail-receiver-environment.json. Mais cela ne change pas /etc/hostname et ne change pas non plus myhostname dans la configuration Postfix.
Je suis tenté d’utiliser POSTCONF_myhostname mais je crains que cela n’ait des effets secondaires indésirables car $myhostname est utilisé à plusieurs endroits et ne correspondrait alors plus à /etc/hostname.
Il y a un paramètre que Discourse-setup demande. Je ne me souviens pas de son nom et il est difficile de le trouver sur mon téléphone. Vous pouvez regarder le code source ou l’exécuter.
Le paramètre Postfix smtp_helo_name modifie le nom spécifié dans la commande HELO (ou EHLO), mais il s’agit d’un paramètre de livraison sortante, tandis que la bannière SMTP est envoyée lors de la réception de courrier. Le nom d’hôte par défaut spécifié dans celui-ci est tiré de myhostname, mais vous pouvez modifier la bannière pour afficher quelque chose de différent avec le paramètre smtpd_banner.
Je ne sais pas si cela aidera d’autres personnes, j’avais un problème similaire et cela m’a aidé à réaliser que pour une raison quelconque, j’avais révoqué la clé API. Une fois que j’ai annulé la révocation, la réception des e-mails a de nouveau fonctionné.
Merci donc de m’avoir aidé à réaliser que cela était lié à la clé API
Quelque chose a-t-il peut-être changé depuis que cela a été écrit ? Je viens de constater que l’ajout d’une valeur POSTCONF_smtpd_banner sous env: n’était absolument pas pris en compte par plusieurs redémarrages. J’ai dû reconstruire (./launcher rebuild mail-receiver) pour que cela prenne effet.
