Verbindung zu einem SMTP-Server auf localhost:25 ohne Authentifizierung?

Unterstützung Installation
1

Welche sind die korrekten Einstellungen für ./discourse-setup, um eine Verbindung zu einem SMTP-Server auf localhost:25 ohne Authentifizierung herzustellen?

Ich bin sehr überrascht, dass dies nicht standardmäßig (OOTB) unterstützt wird; es ist die Standardkonfiguration bei den meisten Linux-Installationen.

Mein Server führt lokal Postfix aus; er ist nicht aus dem Internet erreichbar. Er funktioniert beispielsweise einwandfrei, wenn ich den Befehl mail ausführe. Ich habe ein paar inoffizielle Anleitungen im Internet gefunden, die Änderungen an /var/discourse/containers/app.yml vorschlagen, und ich habe es schließlich geschafft, es mit den folgenden Einstellungen zu installieren und zu starten:

  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

Beachten Sie, dass das Installationsskript mich anschreit und sagt, dass die Variablen DISCOURSE_SMTP_USER_NAME oder DISCOURSE_SMTP_PASSWORD erforderlich sind, wenn ich sie weglasse (Bug?).

Und wenn ich jetzt auf die Schaltfläche „Aktivierungs-E-Mail erneut senden" in der Discourse-WUI klicke, erscheint dieser Eintrag in der Protokolldatei (/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

…Aber mein Authentifizierungstyp ist doch ‘none’. Was ist die korrekte Einstellung für keine Authentifizierung?

EDIT: Kann mir jemand außerdem das Dokument verlinken, das alle möglichen „DISCOURSE_SMTP_*"-Variablen und alle ihre gültigen Werte definiert?

EDIT2: Dies erweist sich als weitaus schwieriger, als es sein sollte. Ich vermute, dass „localhost" innerhalb des Docker-Containers auf den Discourse-Docker-Container selbst (app) aufgelöst wird – und nicht auf den Docker-Host, auf dem mein Postfix-SMTP-Server läuft. Das wird weiter durch Postfixs mynetworks und iptables (die vom discourse-setup-Skript oder seinen Kindskripten konfiguriert wurden) kompliziert. Was ist hier die korrekte Konfiguration, damit Discourse einfach den SMTP-Server verwendet, auf dem ich Discourse ausführen möchte, ohne SMTP-Authentifizierung?

2

Das stimmt seit etwa 20 Jahren nicht mehr wirklich.

Du kannst das discourse-setup-Skript für Fälle wie deinen nicht verwenden, da nur wenige Menschen SMTP-Server ohne Passwortschutz nutzen, selbst hinter einer Firewall.

Was ich tun würde, ist, SMTP-Passwörter für meinen Mailserver zu konfigurieren. Es gibt wirklich kaum Nachteile.

Wenn du das nicht tun möchtest, denke ich, dass du statt „none“ für die Authentifizierung lieber „“ (und entsprechend auch für das Passwort und den Benutzernamen) verwenden solltest.

Das denke ich auch. Du könntest versuchen, den Container-Namen zu verwenden. Ich glaube, du musst sicherstellen, dass beide im selben Docker-Netzwerk sind.

3

Im Jahr 2019 ist dies die Standardkonfiguration für Postfix auf RHEL/CentOS. Postfix bindet sich nur an die Loopback-Schnittstelle und verwirft alle SMTP-Anfragen, die nicht von 127.0.0.0/8 stammen. Keine Authentifizierung erforderlich. Bei Debian bin ich mir nicht sicher, aber ich vermute, dass exim eine ähnliche Standardkonfiguration hat.

Ein paar relevante Themen in diesen Foren von anderen Benutzern, die auf dieses Problem gestoßen sind:

Es scheint kein Thema zu geben, das erklärt, wie man dies auf RHEL/CentOS mit den notwendigen Änderungen sowohl an Discourse als auch an Postfix einrichtet, daher dokumentiere ich dies hier.

Dies scheint mit dem discourse-setup-Skript nicht möglich zu sein, aber ich habe es zum Laufen gebracht.

Zuerst musste ich die IP-Adresse des Docker-Hosts herausfinden, wie sie vom Docker-Container gesehen wird. Die Verwendung von 127.0.0.1 funktioniert nicht, weil der Docker-Container 127.0.0.1 als sich selbst interpretiert. Stattdessen müssen wir die IP-Adresse oder den Hostnamen des Docker-Hosts angeben, auf dem der Postfix-SMTP-Server läuft und der vom Docker-Container erreichbar ist (also nicht die öffentlich zugängliche IP-Adresse Ihres Docker-Hosts, wenn Sie möchten, dass Ihr SMTP-Server nicht über das Internet erreichbar ist).

Ich habe die relevante IP-Adresse des Docker-Hosts (172.17.0.1) von der docker0-Schnittstelle extrahiert, indem ich dies auf dem Docker-Host ausgeführt habe:

[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 ~]$

Dann habe ich die YAML-Datei meiner Discourse-App bearbeitet und den Wert von “DISCOURSE_SMTP_ADDRESS” auf 172.17.0.1 gesetzt, wie oben angegeben.

[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]$

Beachten Sie, dass ich zuerst versucht habe, den internen Docker-Hostnamen host.docker.internal dafür zu verwenden, aber dieser Hostname ist anscheinend für Linux-Docker-Benutzer nicht verfügbar.

Da die Standard-Postfix-Konfiguration in RHEL/CentOS nur an 127.0.0.1 bindet (was gut ist), müssen Sie /etc/postfix/main.cf so ändern, dass es auch an die docker0-Schnittstelle bindet, und dieses Subnetz zur Gruppe mynetworks hinzufügen, damit SMTP-Verkehr, der von Docker-Containern kommt, von Postfix akzeptiert wird.

[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]$

Nach diesen Änderungen Discourse neu aufbauen, und es sollte nun in der Lage sein, E-Mails über den Postfix Ihres Docker-Hosts zu versenden.

/var/discourse/launcher rebuild app

Obwohl dies funktioniert, habe ich ein paar Fragen:

  1. Gibt es eine andere Umgebungsvariable oder einen Hostnamen, der bereits auf den Docker-Host zeigt (172.17.0.1 in diesem Fall)?

Ich habe bemerkt, dass es eine Umgebungsvariable DISCOURSE_HOST_IP gibt, die von launcher „injiziert“ wird. Ist es möglich, diesen YAML-Schlüssel DISCOURSE_SMTP_ADDRESS auf denselben Wert wie den anderen YAML-Schlüssel zu setzen, so ähnlich wie:

DISCOURSE_SMTP_ADDRESS: $DISCOURSE_HOST_IP
  1. Wie stabil ist im Allgemeinen die IP-Adresse 172.17.0.1 des Docker-Hosts? Ist sie auf RHEL/CentOS-Systemen immer diese IP? Wird sie sich jemals für mich ändern?
4

@maltfield Ich wollte mich nur für die Anleitung bedanken.

Ich bin unter Debian auf das gleiche Problem gestoßen… Ich könnte zwar einen separaten Mail-Benutzer für Discourse erstellen und ihn sich mit dem Login zur Site:465 verbinden lassen, aber meiner Meinung nach ist die Verbindung zum Port 25 von innen logischer.

Übrigens: Unter Debian 10 mit docker.io aus den Repositories ist docker0 immer noch 172.17.0.1/16.

5

Vielleicht verstehst du falsch, was @maltfield sagt?

Soweit ich mich erinnern kann (das reicht weiter zurück als 20 Jahre), läuft auf Linux- (/ Unix- / BSD- / Solaris-) Systemen ein SMTP-Server, der standardmäßig so konfiguriert ist, dass er bereitwillig alles weiterleitet, was von localhost empfangen wird, ohne Fragen zu stellen. Das entlastet jede andere Anwendung auf dieser Maschine davon, sich selbst um SMTP-Einstellungen kümmern und diese konfigurieren zu müssen.

6

Ja, die meisten Linux-Server erfordern keine Authentifizierung zum Senden von E-Mails (entweder standardmäßig oder nach der Installation und Konfiguration). Dies ist auch nicht erforderlich, wenn sie keine Weiterleitung von außerhalb des lokalen Netzwerks durchführen. Die Standard-InstallationsSkripte für Discourse funktionieren für die meisten Server nicht. Sie sind für eine begrenzte Auswahl an Docker-basierten Cloud-Lösungen konzipiert.

Sie können meine vollständigen, umfassenden Anweisungen zur Installation von Discourse auf einem dedizierten Baremetal-Server mit RHEL/CentOS 7 auf der Open Source Ecology-Wiki nachlesen. Beachten Sie den Abschnitt zu SMTP hier:

7

Na ja, ich überlasse dir in solchen Angelegenheiten fast immer das letzte Wort! Ich schätze, es ist schon einige Jahre her, seit ich einen SMTP-Server auf localhost betrieben habe, also ist es ziemlich sicher, dass ich nicht genau weiß, wovon ich spreche.

Noch ein Beweis, dass ich unrecht habe! :man_shrugging:

Super!

Aber discourse-setup ist nur für Leute gedacht, die so gut wie nichts über Systemadministration wissen. Wer weiß, wie man einen SMTP-Server installiert, kann einfach eine YAML-Datei bearbeiten.

8

Wenn der Host, auf dem der Container läuft, einen über DNS abrufbaren Namen hat, reicht es aus, diesen anzugeben:

DISCOURSE_SMTP_ADDRESS: real.machine.example.com

Postfix wird dennoch erkennen, dass die Quelle der E-Mail lokal ist, und sie entsprechend behandeln.

9

Verursacht es Probleme, wenn DISCOURSE_HOSTNAME und DISCOURSE_SMTP_ADDRESS identisch sind?

Ich habe Postfix & Dovecot auf dem Docker-Host eingerichtet, um authentifizierte Anfragen über TLS zu akzeptieren. Ich habe gültige Zertifikate für meinen Server, aber egal welche Konfiguration ich versuche, ich kann Discourse nicht dazu bringen, E-Mails korrekt an Postfix zu senden, das auf dem Docker-Host läuft.

Wenn ich den Hostnamen (discourse.[myhost].com) verwende, funktioniert es nicht (es wird nicht einmal eine Verbindung hergestellt). Wenn ich die IP-Adresse des Docker-Hosts (172.17.0.1) verwende, erhalte ich

hostname "172.17.0.1" does not match the server certificate

Offensichtlich muss ich den FQDN verwenden, der zum Erstellen der Zertifikate verwendet wurde. Wenn ich versuche, DISCOURSE_SMTP_ENABLE_START_TLS auf false zu setzen, wird gesagt, dass ich einen Start-TLS-Befehl ausgeben muss. Ich möchte Postfix nicht wirklich ohne TLS öffnen, daher sehe ich dies sowieso nicht als praktikable Option an.

Die Verwendung eines externen SMTP-Relays ist ebenfalls keine Option, da ich nicht mehr bezahlen möchte, nur um sicherzustellen, dass E-Mails nicht im Spam-/Junk-Ordner landen.

Ich muss sagen, ich habe nur ein rudimentäres Verständnis von Docker-Networking und noch weniger Verständnis für die Einrichtung eines Postfix-SMTP-Servers mit Dovecot zur Authentifizierung, aber ich bin kein kompletter Anfänger. Es erweist sich als äußerst schwierig, dies auf sichere Weise einzurichten.

@maltfield Ich habe Ihren Artikel über Open Source Ecology gelesen, aber ich möchte keine unauthentifizierte Verbindung über Port 25 verwenden. Die Universität, für die ich arbeite, hat sehr strenge Protokolle bezüglich der Verwendung von unverschlüsselter, unauthentifizierter Kommunikation (selbst innerhalb eines lokalen Netzwerks wie diesem). Sie sind zu besorgt, dass dies von einem verärgerten Studenten missbraucht werden könnte.

10

Ich vermute also, dass es etwas faul war, denselben Hostnamen sowohl für den Discourse-Server als auch für den SMTP-Server zu verwenden.

Weitere Untersuchungen zeigen, dass der Docker-Container den folgenden Eintrag zur hosts-Datei hinzufügt:

172.17.0.2	discourse.[mydomain].com discourse

Jeder Versuch, denselben Hostnamen für den laufenden Container und den Docker-Host zu verwenden, führt dazu, dass alle vom Container ausgegebenen Anfragen an den Container selbst und nicht an den Docker-Host gehen.

Was für ein Fiasko! Warum stellt Discourse nicht einfach einen standardmäßigen konfigurierten SMTP-Server im Container bereit!?
ODER macht es einfacher, Discourse ohne Docker zu verwenden!

Zwei Tage meines Lebens habe ich wegen dieses Problems verloren.

11

Am Ende akzeptiere ich die Tatsache, dass ich TLS nicht zur Kommunikation mit SMTP auf dem Docker-Host verwenden kann (ohne Zertifikate mit einem anderen Hostnamen zu erhalten). Damit dies endlich funktioniert, musste ich sicherstellen, dass 172.17.0.0/16 zur Variablen mynetworks in der Postfix main.cf-Datei hinzugefügt wird:

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

Dies ermöglicht es Postfix, jeden Docker-Container, der auf diesem Server läuft, als Teil des Netzwerks zu betrachten.

Eine weitere Änderung, die ich vornehmen musste, war sicherzustellen, dass smtpd_sasl_security_options auf noanonymous gesetzt ist, um zu verhindern, dass „Fremde“ Postfix als SMTP-Relay verwenden. Stellen Sie sicher, dass die Option noplaintext hier nicht gesetzt ist, da Postfix sonst nur die Authentifizierung über TLS zulässt.

smtpd_sasl_security_options = noanonymous

Mit diesen Konfigurationseinstellungen konnte ich die folgenden Einstellungen in app.yml angeben:

  DISCOURSE_SMTP_ADDRESS: 172.17.0.1                            # IP-Adresse des Docker-Hosts (wie aus diesem Container heraus gesehen)
  DISCOURSE_SMTP_PORT: 25
  DISCOURSE_SMTP_USER_NAME: discourse
  DISCOURSE_SMTP_PASSWORD: pa$$word
  DISCOURSE_SMTP_ENABLE_START_TLS: false                        # (optional, Standard true)
  DISCOURSE_SMTP_DOMAIN: discourse.[mydomian].com                # (von einigen Anbietern erforderlich)
  DISCOURSE_NOTIFICATION_EMAIL: noreply@discourse.[mydomain].com # (Adresse, von der Benachrichtigungen gesendet werden)

Ich habe auch ein lokales Benutzerkonto auf dem Docker-Host nur für die SASL-Authentifizierung erstellt.
Mit diesen Änderungen konnte ich endlich E-Mails vom Container aus versenden, aber ich habe das Gefühl, dass dies eine suboptimale Konfiguration ist. Idealerweise sollte es möglich sein, den gewünschten Hostnamen für den Docker-Host zu verwenden und Anfragen an discourse.[mydomain].com an die richtige Stelle zu leiten.

Jetzt muss ich SPF und DKIM einrichten, damit E-Mails in den Posteingängen der Leute landen (anstatt in ihren Spam-Ordnern). Ich hoffe wirklich, dass dieser schmerzhafte Prozess eines Tages automatisierter ist. Vielleicht Anweisungen zur Konfiguration von Discourse ohne Docker (damit es z. B. mit cPanel verwendet werden kann) oder die Mail-Einrichtung weniger schmerzhaft gestalten, indem eine Art Standard-SMTP-Konfiguration direkt im Docker-Container bereitgestellt wird!

12

Wenn Sie in die frühen 1990er Jahre zurückblicken, war es, wie Sie es sich wünschen. Die Dinge, über die Sie sprechen, funktionierten einfach. Aber Spammer haben es viel komplizierter gemacht. Der Prozess wird nur noch schwieriger, weshalb die Empfehlung lautet, einen Dienst zu nutzen, der sich um viele der Komplikationen für Sie kümmert.

13

Ich freue mich, dass Ihre E-Mail-Einrichtung funktioniert!

Seit gestern gibt es einige Updates in der Anleitung zur Fehlerbehebung bei E-Mails. Wenn Sie mit Ihrer E-Mail-Einrichtung immer noch nicht zufrieden sind, versuchen Sie es vielleicht noch einmal!

Kann gelöst werden durch die Verwendung von:

… nur die Standard-DNS-Auflösung des Domainnamens zur IP.

14

Missverstehen Sie mich nicht. Ich verstehe die Bedeutung von SPF und DKIM. Es ist einfach ärgerlich. Ich wünschte nur, dies könnte auf unseren aktuellen cPanel-Servern installiert werden, wo diese Dinge bereits konfiguriert sind.

15

Das hat mir gefehlt. Es funktioniert jetzt mit TLS.

Ich habe auch DKIM zum Laufen gebracht, sodass E-Mails nicht mehr gespammt werden sollten.