Utiliser un serveur de messagerie local/sendmail pour les e-mails sortants ?

Installation Hébergement
1

Nous avons configuré notre propre serveur de messagerie et je me demandais comment l’utiliser au mieux avec le conteneur Docker de Discourse.

Bien sûr, je peux simplement configurer nos détails et identifiants SMTP, mais cela semble être une surcharge inutile, puisque le serveur SMTP s’exécute sur la même machine.

sendmail fonctionne, mais Discourse est dans le conteneur, il n’a donc pas accès à sendmail sur son hôte.

Une recherche ici sur le forum donne un exemple où DISCOURSE_SMTP_DOMAIN a été utilisé sans identifiants, où faire de même avec swaks dans le conteneur fonctionne : How to get Discourse to work with Postfix - #18 by sonmicrosystems suppose que dans ce cas, il s’agit toujours d’une soumission SMTP normale sur le port par défaut, et que Postfix l’accepte sans authentification, puisque la requête provient de localhost ?

Quelqu’un connaît-il une autre méthode ? Je vois que la bibliothèque Ruby utilisée prend généralement en charge tout : https://github.com/discourse/mail\nDans les paramètres de Discourse, ce qui a attiré mon attention est un champ Delivery method :

image
image643×198 6.22 KB

Je ne peux pas modifier ces paramètres dans l’interface graphique, je suppose parce que le YAML du conteneur les impose via DISCOURSE_SMTP_ADDRESS etc ? Mais je ne trouve pas de variable pour la méthode de livraison.

Peut-être que quelqu’un connaît un autre moyen, et en attendant, je configure une authentification normale sur le port de soumission SMTP. Merci pour DISCOURSE_SMTP_FORCE_TLS au passage, ajouté plus récemment, mais pas encore inclus dans d’autres exemples (il devrait l’être). Je n’ai pas l’intention d’autoriser STARTTLS, mais uniquement TLS implicite/immédiat.

2

Surcharge inutile comment ? Vous devez envoyer les données de Discourse au serveur SMTP d’une manière ou d’une autre ? Non ?

Ps : s’il s’agit d’un autre conteneur, vous pourriez en théorie utiliser le réseau bridge et utiliser le nom du conteneur smtp au lieu du nom d’hôte si c’est ce que vous recherchez, mais cela ne vous donnera aucun avantage en termes de performances.

2 « J'aime »
3

Il existe deux façons d’envoyer des e-mails via un serveur SMTP local :

  1. se connecter et s’authentifier au port de soumission, comme le 587 avec STARTTLS ou le 465 avec TLS implicite/immédiat => requête réseau, vérifications et restrictions appliquées via smtpd
  2. utiliser sendmail ou similaire, qui invoque la commande locale pickup (dans le cas de Postfix), sans établir de connexion réseau, et contourne toutes les vérifications et restrictions configurées pour le service de soumission smtpd.

Ce dernier est plus simple et plus rapide, implémenté dans les systèmes d’exécution et les frameworks courants, comme PHP mailer et cette bibliothèque de courrier Ruby utilisée par Discourse. Et l’authentification est contournée, aucun identifiant en texte brut ne doit être stocké quelque part. Autrement dit : le serveur SMTP n’est pas du tout utilisé dans ce cas, mais seulement le client SMTP.

Je veux dire oui, la connexion au port de soumission ne devrait pas avoir d’impact significatif sur la charge du serveur, par rapport à ce que fait Discourse par ailleurs. Ce dernier point peut être résolu avec par exemple la règle smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject au port de soumission, pour autoriser les soumissions depuis les adresses IP de bouclage (par défaut, réglage mynetworks), avant toute authentification. Si la requête du conteneur est vue avec une autre adresse IP, elle peut être ajoutée à mynetworks. Je suppose que c’est ainsi que cela fonctionnait dans le cas du sujet que j’ai lié précédemment.

Nous verrons la prochaine fois que nous mettrons à jour/reconstruirons notre Discourse, lorsque les paramètres SMTP modifiés seront appliqués. Je ferai un retour sur le fonctionnement.

Mais il serait toujours intéressant de savoir s’il existe d’autres moyens, et à quoi sert ce réglage “Méthode de livraison”.

Postfix s’exécute sur l’hôte, pas à l’intérieur d’un conteneur, mais cela ne ferait pas beaucoup de différence, car cela reste une authentification basée sur le réseau.

Ouais, une pensée plus tard, il est logique que sendmail etc. de l’hôte/d’un autre conteneur ne puissent pas fonctionner à l’intérieur d’un conteneur, car cela nécessite un accès direct à de vastes parties des exécutables, bibliothèques et configurations de Postfix, je suppose. À moins qu’il n’y ait une sorte de socket magique qui puisse être monté en bind dans le conteneur ou quelque chose comme ça :smile:.

2 « J'aime »
4

Cela fait un moment que je ne me suis pas plongé aussi profondément dans la microgestion de sendmail. J’ai le stack Mailcow sur une VM et Discourse sur une autre. Je ne sais pas si cela vaudra jamais la peine de creuser si profondément, à part pour le plaisir.

Je vous souhaite bonne chance dans vos aventures, faites-nous part de ce que vous avez appris.

1 « J'aime »
5

Probablement pas :sweat_smile:. Mais je suis perfectionniste dans certains contextes, et j’aime creuser en profondeur et apprendre tous les détails. Il m’a fallu plusieurs soirées pour configurer Dovecot, Postfix, rspamd, dkimpy-milter, PostSRSd, … étape par étape, en apprenant presque tous les paramètres disponibles, pourquoi les valeurs par défaut sont ainsi, si et pourquoi nous pourrions vouloir les modifier, etc. Mais bon, maintenant, je semble comprendre la plupart des choses mieux que la plupart des auteurs de guides arbitraires sur les serveurs de messagerie :face_with_tongue:.

6

Je déplace ce sujet vers Installation > Hosting. Nous ne recommandons pas d’essayer d’héberger votre propre serveur de messagerie, comme vous le savez si vous avez lu les instructions d’installation officielles. La messagerie, c’est compliqué !

7

Je ne suis pas sûr de ce que Discourse a à voir avec le fait que le système puisse ou non héberger un serveur de messagerie ? Outre le fait que cela ouvre théoriquement une autre façon d’envoyer des e-mails, bien sûr.

Pour la réception des e-mails (autre sujet), cela a cependant un effet, car on ne peut pas héberger le conteneur de réception des e-mails, du moins pas pour écouter directement sur le port 25. Mais utiliser directement l’API de réception des e-mails de Discourse s’est avéré n’être que 2-3 lignes dans la configuration Postfix : Is there a way to only IMAP polling for incoming emails - #2 by MichaIng

Mais je suis d’accord, la mise en place correcte du serveur de messagerie n’a pas été une tâche facile, comme mentionné ci-dessus. Mais super intéressant à apprendre :slightly_smiling_face:.

1 « J'aime »
8

Oui ! C’est un défi et c’est intéressant, c’est sûr. J’ai vécu mes propres aventures en installant toutes sortes de services et en essayant de les gérer moi-même, dans une vie antérieure ! :upside_down_face:

Je suis heureux que vous mettiez à jour ce sujet avec vos apprentissages pour le bénéfice des futurs voyageurs intrépides, y compris vous-même. Mais gardez à l’esprit que la catégorie Support est destinée aux installations prises en charge, au cœur de Discourse et aux plugins et composants officiels.

1 « J'aime »
9

quoi. Dovecoat bien. Pourquoi alors postfix? Pourquoi pas dovecoat exim?

10

Qu’est-ce qui ne va pas avec Postfix ? Il faisait partie du premier guide de configuration de serveur de messagerie que j’ai lu, et ses options de filtrage internes pour réduire le spam et l’accès des bots tôt dans le pipeline semblaient un bon argument.

Eh bien, un peu hors sujet, concernant l’utilisation de sendmail/pickup par Discourse.

Je marque cela comme résolu/répondu. Il est logique que le conteneur Discourse ne puisse pas accéder au sendmail de l’hôte, quel que soit le serveur. Il doit donc utiliser la soumission SMTP, pour laquelle on peut s’authentifier par exemple via la plage d’adresses IP du conteneur Docker dans Postfix, en omettant l’authentification passdb/userdb sur Dovecot.

11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.