Si vous disposez d’un conteneur de réception de courriel nécessitant une configuration Postfix personnalisée, ce sujet est fait pour vous. Il décrit les étapes nécessaires pour définir les variables de configuration main.cf de Postfix selon vos souhaits.
Les variables de configuration Postfix peuvent être définies via les variables d’environnement du conteneur. Toute variable d’environnement commençant par POSTCONF_ définira une variable de configuration Postfix dont le nom correspond au reste de la variable d’environnement, avec la valeur de cette dernière. Par exemple, si vous définissez la variable d’environnement POSTCONF_always_bcc à bob@example.com, Postfix sera configuré avec always_bcc = bob@example.com, ce qui enverra une copie de tous les courriels entrants à Bob. Pauvre Bob.
Procédure
Identifiez les variables de configuration que vous souhaitez définir et les valeurs à leur attribuer. Cela peut être fait en consultant le manuel, en suivant les recommandations d’autres documentations Discourse, ou par d’autres moyens.
Connectez-vous à votre serveur Discourse via SSH, obtenez des privilèges root, puis rendez-vous dans le répertoire où sont stockées toutes les configurations discourse-docker :
ssh ubuntu@192.0.2.42
sudo -i
cd /var/discourse
Ouvrez containers/mail-receiver.yml dans votre éditeur de texte préféré, puis descendez à la section env: du fichier. Ajoutez-y les entrées pour les variables que vous souhaitez définir, en veillant à ne modifier rien d’autre et à conserver une indentation appropriée. Par exemple, si nous ajoutons notre paramètre always_bcc, le fichier pourrait ressembler à ceci :
Une fois satisfait de vos ajouts, enregistrez et quittez votre éditeur.
Pour charger la configuration, il vous suffit de redémarrer le conteneur mail-receiver (un rebuild n’est pas nécessaire) :
./launcher restart mail-receiver
Après un bref sursaut, le conteneur devrait être à nouveau en cours d’exécution.
Testez vos modifications. Assurez-vous à la fois que ce que vous souhaitiez s’est bien produit et que rien d’inattendu n’a changé.
Addendum : ajouter des fichiers au conteneur mail-receiver
De nombreux paramètres de configuration Postfix nécessitent l’accès à des « fichiers de base de données » qui fournissent des informations clé/valeur utilisées par Postfix pour prendre des décisions concernant le traitement des courriels. Si vous remarquez qu’un paramètre de configuration accepte un nom de fichier ressemblant à hash:/some/file, vous avez trouvé une utilisation pour ces fichiers de base de données.
Le problème est que Postfix, exécuté à l’intérieur du conteneur, doit pouvoir accéder à ces fichiers pendant son exécution. Cela signifie que vous devez soit copier ces fichiers dans le conteneur, soit (de préférence) les placer dans un répertoire sur l’hôte, puis monter ce répertoire en tant que volume à l’intérieur du conteneur. Ces instructions décrivent la deuxième méthode.
Une fois cette procédure terminée, tout fichier que vous placerez dans /var/discourse/shared/mail-receiver/etc sera immédiatement visible à l’adresse /etc/postfix/shared à l’intérieur du conteneur, et toute modification apportée à ces fichiers sera immédiatement visible par Postfix.
Voici comment procéder.
Si vous n’êtes toujours pas connecté en tant que root à votre serveur Discourse, reconnectez-vous :
ssh ubuntu@192.0.2.42
sudo -i
cd /var/discourse
Ouvrez containers/mail-receiver.yml dans votre éditeur de texte préféré, et cette fois, rendez-vous à la section volume:. Sous la définition existante du répertoire /var/spool/postfix, ajoutez une autre définition, de sorte que votre section volume ressemble à ceci :
Matt, penses-tu qu’il serait possible d’activer des comptes comme admin@domain ou info@domain depuis cette configuration Postfix ?
J’ai juste besoin de quelques adresses pour la réception d’e-mails, et cela fonctionne avec Discourse, mais je n’arrive pas à configurer les comptes (ils semblent être bloqués par défaut, même si les messages sont traités).
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.
Je viens de terminer une migration de domaine (selon Change the domain name or rename your Discourse ) qui s’est très bien passée. Cependant, j’utilise le conteneur mail-receiver avec des enregistrements MX pour le courrier entrant vers quelques catégories…
D’après ce que je vois, la configuration par défaut du conteneur code en dur à la fois le domaine entrant et le chemin d’accès aux certificats LetsEncrypt. Est-il possible d’autoriser deux domaines, soit dans la configuration, soit via ces options avancées ?
