Connexion à un serveur SMTP sur localhost:25 sans authentification ?

Soutien Installation
1

Quelles sont les bonnes paramètres à passer à ./discourse-setup pour se connecter à un serveur SMTP sur localhost:25 sans authentification ?

Je suis très surpris que cela ne soit pas pris en charge par défaut (OOTB) ; c’est la configuration par défaut sur la plupart des installations Linux.

Mon serveur exécute Postfix localement ; il n’est pas accessible depuis Internet. Cela fonctionne parfaitement, par exemple, lors de l’exécution de la commande mail. J’ai trouvé quelques guides non officiels sur Internet suggérant des modifications dans /var/discourse/containers/app.yml, et j’ai finalement réussi à l’installer et à le démarrer avec les paramètres suivants :

  DISCOURSE_SMTP_ADDRESS: localhost
  DISCOURSE_SMTP_PORT: 25
  DISCOURSE_SMTP_USER_NAME: discourse@opensouceecology.org
  DISCOURSE_SMTP_PASSWORD: "none"
  DISCOURSE_SMTP_AUTHENTICATION: none
  DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none
  DISCOURSE_SMTP_ENABLE_START_TLS: false

Notez que si j’omet les variables DISCOURSE_SMTP_USER_NAME ou DISCOURSE_SMTP_PASSWORD, votre script d’installation me réprimande en indiquant qu’elles sont requises (bug ?).

Et maintenant, lorsque je clique sur le bouton « Renvoyer l’email d’activation » dans l’interface web de Discourse, cette entrée apparaît dans le fichier de journal (/var/discourse/shared/standalone/log/rails/production.log) :

Started PUT "/finish-installation/resend-email" for 127.0.0.1 at 2019-11-07 13:15:31 +0000
Processing by FinishInstallationController#resend_email as HTML
  Parameters: {"authenticity_token"=>"SzQCvRWiqdXsBKzOjIB0X7KkvXro7Od6SdP8Qa8vvrskPeNYZNos5ORHJfyDUrHiKShZR/txM6NHuqHHCQCR1w=="}
  Rendering finish_installation/resend_email.html.erb within layouts/finish_installation
  Rendered finish_installation/resend_email.html.erb within layouts/finish_installation (Duration: 0.7ms | Allocations: 103)
  Rendered layouts/_head.html.erb (Duration: 0.5ms | Allocations: 103)
Completed 200 OK in 98ms (Views: 3.0ms | ActiveRecord: 0.0ms | Allocations: 4763)
  Rendering layouts/email_template.html.erb
  Rendered layouts/email_template.html.erb (Duration: 0.5ms | Allocations: 141)
Delivered mail c4ca58ca-345e-46c4-81bc-6d0eac7afa04@discourse.opensourceecology.org (11.3ms)
Job exception: wrong authentication type none

…Mais mon type d’authentification est « none ». Quelle devrait être la bonne configuration pour aucune authentification ?

EDIT : pouvez-vous également me fournir un lien vers la documentation définissant toutes les variables possibles « DISCOURSE_SMTP_* » et toutes leurs valeurs valides ?

EDIT2 : cela s’avère beaucoup plus difficile que cela ne devrait l’être. Je pense que « localhost » se résout à l’intérieur du conteneur Docker au conteneur Docker Discourse lui-même (app) — et non à l’hôte Docker exécutant mon serveur SMTP Postfix. Cela est encore compliqué par mynetworks de Postfix et iptables (qui ont été configurés par le script discourse-setup ou ses scripts enfants). Quelle est la bonne configuration ici pour simplement que Discourse utilise le serveur SMTP sur lequel je souhaite exécuter Discourse, sans authentification SMTP ?

2

Je pense que cela n’a pas été très vrai depuis environ 20 ans.

Vous ne pouvez pas utiliser discourse-setup pour des situations comme la vôtre, car peu de gens ont des serveurs SMTP non protégés par mot de passe, même derrière un pare-feu.

Ce que je ferais, c’est configurer des mots de passe SMTP pour mon serveur de messagerie. Il n’y a vraiment pas grand inconvénient.

Si vous ne voulez pas faire cela, je pense qu’au lieu de “none” pour l’authentification, vous pourriez préférer “” (et de même pour le mot de passe et le nom d’utilisateur).

Je pense aussi. Vous pourriez essayer d’utiliser le nom du conteneur. Je pense que vous devez vérifier qu’ils sont tous deux sur le même réseau Docker.

3

En 2019, c’est la configuration par défaut de Postfix sur RHEL/CentOS. Postfix se lie uniquement à l’interface de bouclage et rejette toutes les requêtes SMTP qui ne proviennent pas de 127.0.0.0/8. Aucune authentification n’est requise. Je ne suis pas sûr pour Debian, mais j’imagine qu’exim a une configuration par défaut similaire.

Quelques sujets pertinents sur ces forums, provenant d’autres utilisateurs ayant rencontré ce problème :

Il ne semble pas y avoir de sujet expliquant comment configurer cela sur RHEL/CentOS avec les modifications nécessaires à la fois pour Discourse et Postfix, alors je documente cela ici.

Cela ne semble pas être possible avec le script discourse-setup, mais j’ai réussi à faire fonctionner cela.

Tout d’abord, j’ai dû déterminer l’adresse IP de l’hôte Docker telle que la voit le conteneur Docker. Utiliser 127.0.0.1 ne fonctionnera pas car le conteneur Docker verra 127.0.0.1 comme lui-même. Au contraire, nous devons spécifier l’adresse IP ou le nom d’hôte de l’hôte Docker qui exécute le serveur SMTP Postfix, et qui est accessible depuis le conteneur Docker (donc pas l’adresse IP publique de votre hôte Docker si vous ne voulez pas que votre serveur SMTP soit accessible depuis Internet, par exemple).

J’ai extrait l’adresse IP pertinente de l’hôte Docker (172.17.0.1) depuis l’interface docker0 en exécutant la commande suivante sur l’hôte Docker :

[maltfield@osestaging1 ~]$ ip address show docker0
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 02:42:80:35:65:a1 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:80ff:fe35:65a1/64 scope link 
       valid_lft forever preferred_lft forever
[maltfield@osestaging1 ~]$

Ensuite, j’ai édité le fichier YAML de mon application Discourse, en définissant “DISCOURSE_SMTP_ADDRESS” sur 172.17.0.1 comme indiqué ci-dessus.

[maltfield@osestaging1 ~]$ cd /var/discourse/
[maltfield@osestaging1 discourse]$ grep SMTP containers/app.yml
  DISCOURSE_SMTP_ADDRESS: 172.17.0.1
  DISCOURSE_SMTP_PORT: 25
  DISCOURSE_SMTP_AUTHENTICATION: none
  DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none
  DISCOURSE_SMTP_ENABLE_START_TLS: false
[maltfield@osestaging1 discourse]$

Notez que j’ai d’abord essayé d’utiliser le nom d’hôte interne de Docker host.docker.internal pour cela, mais apparemment, ce nom d’hôte n’est pas disponible pour les utilisateurs de Docker sur Linux :

Comme la configuration par défaut de Postfix sur RHEL/CentOS se lie uniquement à 127.0.0.1 (ce qui est bien), vous devrez modifier /etc/postfix/main.cf pour qu’il se lie également à l’interface docker0 et ajouter ce sous-réseau au groupe mynetworks afin que le trafic SMTP provenant des conteneurs Docker soit accepté par Postfix.

[maltfield@osestaging1 postfix]$ grep -ir '172.17' /etc/postfix/*
/etc/postfix/main.cf:inet_interfaces = 127.0.0.1, 172.17.0.1
/etc/postfix/main.cf:mynetworks = 127.0.0.0/8, 172.17.0.0/16
[maltfield@osestaging1 postfix]$

Après ces modifications, reconstruisez Discourse et il devrait maintenant pouvoir envoyer des e-mails via le Postfix de votre hôte Docker.

/var/discourse/launcher rebuild app

Bien que cela fonctionne, j’ai quelques questions :

  1. Existe-t-il une autre variable d’environnement ou un autre nom d’hôte qui pointe déjà vers l’hôte Docker (172.17.0.1 dans ce cas) ?

J’ai remarqué qu’il existe une variable d’environnement DISCOURSE_HOST_IP « injectée » par launcher. Est-il possible de définir cette clé YAML DISCOURSE_SMTP_ADDRESS sur la même valeur que l’autre clé YAML avec quelque chose comme ceci ?

DISCOURSE_SMTP_ADDRESS: $DISCOURSE_HOST_IP
  1. En général, combien est durable l’adresse IP 172.17.0.1 de l’hôte Docker ? Est-elle toujours cette adresse IP sur les systèmes RHEL/CentOS ? Va-t-elle un jour changer pour moi ?
4

@maltfield Je voulais juste vous remercier pour les instructions.

J’ai rencontré le même problème sur Debian… Je pourrais créer un utilisateur mail séparé pour Discourse et le faire se connecter et se connecter au site:465, mais se connecter au port 25 depuis l’intérieur me semble plus logique, à mon avis.

Et d’ailleurs, sur Debian 10 avec docker.io provenant des dépôts, docker0 est toujours 172.17.0.1/16.

5

Peut-être que vous avez mal compris ce que dit @maltfield ?

Depuis aussi loin que je me souvienne (ce qui remonte à plus de 20 ans), les systèmes Linux ( / Unix / BSD / Solaris) ont un serveur SMTP en cours d’exécution, configuré par défaut pour relayer sans poser de questions tout ce qui est reçu depuis localhost. Cela épargne à toute autre application s’exécutant sur cette machine la nécessité de s’occuper et de configurer elle-même les paramètres SMTP.

6

Oui, la plupart des serveurs Linux ne nécessitent pas d’authentification pour envoyer des courriels (soit par défaut, soit après l’installation et la configuration). Ce n’est pas non plus nécessaire s’ils ne relaient pas depuis un autre endroit que le réseau local. Les scripts d’installation par défaut de Discourse ne fonctionneront pas pour la plupart des serveurs. Ils sont conçus pour un ensemble restreint de solutions cloud basées sur Docker.

Vous pouvez consulter mes instructions complètes pour installer Discourse sur un serveur dédié et bare-metal sous RHEL/CentOS 7 sur le wiki d’Open Source Ecology. Notez la section sur SMTP ici :

7

Eh bien, je me réfère presque toujours à toi pour ce genre de questions ! Je suppose que cela fait un bon nombre d’années que je n’ai pas exécuté de serveur SMTP sur localhost, donc il est fort probable que je ne sache pas de quoi je parle.

De nouvelles preuves que j’ai tort ! :man_shrugging:

Super !

Cependant, discourse-setup ne s’adresse qu’à ceux qui ne connaissent pratiquement rien à l’administration système. Si vous savez installer un serveur SMTP, vous pouvez modifier un fichier yml.

8

Si l’hôte où le conteneur s’exécute possède un nom accessible via DNS, il suffit de le spécifier :

DISCOURSE_SMTP_ADDRESS: real.machine.example.com

Postfix continuera à considérer que l’origine du courrier est locale et le traitera en conséquence.

9

Si DISCOURSE_HOSTNAME et DISCOURSE_SMTP_ADDRESS sont identiques, cela posera-t-il des problèmes ?

J’ai configuré Postfix et Dovecot sur l’hôte Docker pour accepter les requêtes authentifiées via TLS. J’ai des certificats valides pour mon serveur, mais quelle que soit la configuration que j’essaie, je n’arrive pas à faire en sorte que Discourse envoie correctement les e-mails à Postfix fonctionnant sur l’hôte Docker.

Si j’utilise le nom d’hôte (discourse.[monhote].com), cela ne fonctionne pas (il ne se connecte même pas). Si j’utilise l’adresse IP de l’hôte Docker (172.17.0.1), j’obtiens

le nom d'hôte « 172.17.0.1 » ne correspond pas au certificat du serveur

Clairement, je dois utiliser le FQDN qui a été utilisé pour créer les certificats. Si j’essaie de définir DISCOURSE_SMTP_ENABLE_START_TLS sur false, il indique que je dois émettre une commande start TLS. Je ne souhaite pas vraiment ouvrir Postfix sans TLS, donc je ne considère pas cela comme une option viable de toute façon.

L’utilisation d’un relais SMTP externe n’est pas non plus une option car je ne veux pas payer plus cher simplement pour m’assurer que les e-mails ne finissent pas dans les dossiers spam/junk des gens.

Je dois dire que je n’ai qu’une compréhension rudimentaire du réseau Docker, et encore moins de la configuration d’un serveur SMTP Postfix avec Dovecot pour l’authentification, mais je ne suis pas un débutant complet, et réussir cette configuration de manière sûre et sécurisée s’avère extrêmement difficile.

@maltfield J’ai lu votre article sur Open Source Ecology, mais je ne veux pas utiliser de connexion non authentifiée sur le port 25. L’université pour laquelle je travaille a des protocoles très stricts concernant l’utilisation de communications non chiffrées et non authentifiées (même au sein d’une configuration de réseau local comme celle-ci). Ils craignent trop que cela puisse être abusé par un étudiant mécontent.

10

J’ai donc pensé qu’il y avait quelque chose de louche à utiliser le même nom d’hôte pour le serveur Discourse et le serveur SMTP.

Une enquête plus approfondie révèle que le conteneur Docker ajoute l’entrée suivante au fichier hosts :

172.17.0.2	discourse.[mydomain].com discourse

Ainsi, toute tentative d’utilisation du même nom d’hôte pour le conteneur en cours d’exécution et l’hôte Docker entraînera l’envoi de toutes les requêtes émises par le conteneur vers le conteneur lui-même et non vers l’hôte Docker.

Quel fiasco ! Pourquoi Discourse ne fournit-il pas un serveur SMTP configuré par défaut dans le conteneur ?!
OU rend-il plus facile l’utilisation de Discourse sans Docker !

Deux jours de ma vie perdus à cause de ce problème.

11

En fin de compte, j’accepte le fait que je ne peux pas utiliser TLS pour communiquer avec le SMTP s’exécutant sur l’hôte Docker (sans obtenir de certificats en utilisant un autre nom d’hôte). Pour que cela fonctionne enfin, j’ai dû m’assurer que 172.17.0.0/16 est ajouté à la variable mynetworks dans le fichier main.cf de Postfix :

mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 172.17.0.0/16

Cela permet à Postfix de considérer tout conteneur Docker s’exécutant sur ce serveur comme faisant partie du réseau.

Un autre changement que j’ai dû apporter a été de m’assurer que smtpd_sasl_security_options est défini sur noanonymous pour empêcher les « étrangers » d’utiliser Postfix comme relais SMTP. Assurez-vous que l’option noplaintext n’est pas définie ici, sinon Postfix n’autorisera l’authentification qu’avec TLS.

smtpd_sasl_security_options = noanonymous

Avec ces paramètres de configuration, j’ai pu spécifier les paramètres suivants dans app.yml :

  DISCOURSE_SMTP_ADDRESS: 172.17.0.1                            # IP address of the Docker host (as seen from within this container)
  DISCOURSE_SMTP_PORT: 25
  DISCOURSE_SMTP_USER_NAME: discourse
  DISCOURSE_SMTP_PASSWORD: pa$$word
  DISCOURSE_SMTP_ENABLE_START_TLS: false                        # (optional, default true)
  DISCOURSE_SMTP_DOMAIN: discourse.[mydomian].com                # (required by some providers)
  DISCOURSE_NOTIFICATION_EMAIL: noreply@discourse.[mydomain].com # (address to send notifications from)

J’ai également créé un compte utilisateur local sur l’hôte Docker dans le seul but de l’authentification SASL.
Avec ces changements, j’ai finalement pu envoyer des e-mails depuis le conteneur, mais j’ai l’impression que c’est une configuration sous-optimale. Idéalement, il devrait être possible d’utiliser le nom d’hôte souhaité pour l’hôte Docker et que les requêtes à discourse.[mydomain].com aboutissent au bon endroit.

Maintenant, je dois configurer SPF et DKIM pour que les e-mails atterrissent dans les boîtes de réception des gens (au lieu de leurs dossiers spam). J’espère vraiment qu’un jour ce processus douloureux sera plus automatisé. Peut-être fournir des instructions sur la façon de configurer Discourse sans utiliser Docker (afin qu’il puisse être utilisé avec cPanel par exemple…) ou rendre la configuration des e-mails moins pénible en fournissant une sorte de configuration SMTP par défaut directement dans le conteneur Docker !

12

Si vous revenez au début des années 1990, c’était comme vous le souhaitez. Les choses dont vous parlez fonctionnaient simplement. Mais les spammeurs ont rendu les choses beaucoup plus compliquées. Le processus ne fera que devenir plus difficile, c’est pourquoi la recommandation est d’utiliser un service qui s’occupe de nombreuses complications pour vous.

13

Je suis content que votre configuration de messagerie fonctionne !

Il y a eu des mises à jour du guide de dépannage de la messagerie depuis hier. Si vous n’êtes toujours pas satisfait de votre configuration de messagerie, essayez à nouveau !

Peut être résolu en utilisant :

… juste la résolution DNS par défaut du nom de domaine vers l’IP.

14

Ne vous méprenez pas. Je comprends l’importance de SPF et DKIM. C’est juste agaçant. J’aimerais juste que cela puisse être installé sur nos serveurs cPanel actuels où ce genre de choses est déjà configuré.

15

C’est ce qui me manquait. Ça fonctionne maintenant avec TLS.

J’ai aussi configuré DKIM, donc les e-mails ne devraient plus être marqués comme spam.