Lokalen E-Mail-Server/sendmail für ausgehende E-Mails verwenden?

Installation Hosting
1

Wir haben unseren eigenen E-Mail-Server eingerichtet und ich habe mich gefragt, wie wir ihn am besten mit dem Discourse Docker Container nutzen können.

Natürlich kann ich einfach unsere SMTP-Details und Anmeldeinformationen konfigurieren, aber das fühlt sich wie unnötiger Mehraufwand an, da der SMTP-Server auf derselben Maschine läuft.

sendmail funktioniert, aber Discourse befindet sich im Container und hat daher keinen Zugriff auf sendmail auf seinem Host.

Wenn ich hier im Forum nach etwas suche, finde ich ein Beispiel, bei dem DISCOURSE_SMTP_DOMAIN ohne Anmeldeinformationen verwendet wurde. Wenn man dasselbe mit swaks innerhalb des Containers tut, funktioniert es: How to get Discourse to work with Postfix - #18 by sonmicrosystems. Ich nehme an, in diesem Fall ist es immer noch normale SMTP-Einreichung über den Standardport, und Postfix akzeptiert sie ohne Authentifizierung, da die Anfrage von localhost kommt?

Ist jemandem eine andere Methode bekannt? Ich sehe, dass die verwendete Ruby-Bibliothek im Allgemeinen alles unterstützt: GitHub - discourse/mail: A Really Ruby Mail Library
In den Discourse-Einstellungen ist mir ein Feld Delivery method aufgefallen:

image
image643×198 6.22 KB

Ich kann diese Einstellungen nicht in der GUI ändern, vermutlich weil der Container YAML sie über DISCOURSE_SMTP_ADDRESS usw. erzwingt? Aber ich kann keine Variable für die Zustellmethode finden.

Vielleicht kennt jemand einen anderen Weg, und bis dahin richte ich normale SMTP-Einreichungsport-Authentifizierung ein. Danke für DISCOURSE_SMTP_FORCE_TLS übrigens, wurde erst kürzlich hinzugefügt, ist aber noch nicht Teil von Beispielen (sollte es aber sein). Ich beabsichtige nicht, STARTTLS zuzulassen, sondern nur implizites/sofortiges TLS.

2

Unnötiger Overhead wie? Du musst die Daten von Discourse irgendwie an den SMTP-Server senden? Nein?

Ps: Wenn es ein anderer Container ist, könntest du theoretisch das Bridge-Netzwerk verwenden und den SMTP-Containernamen anstelle des Hostnamens verwenden, wenn das das ist, was du willst, aber es wird dir keine Leistungsvorteile bringen.

2 „Gefällt mir“
3

Es gibt zwei Möglichkeiten, E-Mails über einen lokalen SMTP-Server zu versenden:

  1. Verbindung zum Submission-Port herstellen und authentifizieren, z. B. 587 mit STARTTLS oder 465 mit implizitem/sofortigem TLS => Netzwerkanfrage, Prüfungen und Einschränkungen, die über smtpd angewendet werden
  2. sendmail oder ähnliches verwenden, das den lokalen pickup-Befehl aufruft (im Falle von Postfix), keine Netzwerkverbindung herstellt und alle für den smtpd-Submission-Dienst konfigurierten Prüfungen und Einschränkungen umgeht.

Letzteres ist einfacher und schneller, in gängige Laufzeitsysteme und Frameworks wie PHP Mailer und diese Ruby Mail-Bibliothek, die von Discourse verwendet wird, integriert. Und die Authentifizierung wird umgangen, es müssen keine Klartext-Anmeldeinformationen irgendwo gespeichert werden. Oder anders ausgedrückt: Der SMTP-Server wird in diesem Fall überhaupt nicht verwendet, sondern nur der SMTP-Client.

Ich meine, ja, die Submission-Port-Verbindungsgeschichte sollte im Vergleich zu dem, was Discourse sonst tut, keine signifikanten Auswirkungen auf die Serverlast haben. Letzterer Punkt kann mit z. B. der Regel smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject am Submission-Port gelöst werden, um Einreichungen von Loopback-IPs (Standard, mynetworks-Einstellung) zu erlauben, bevor eine Authentifizierung erfolgt. Wenn die Anfrage vom Container mit einer anderen IP gesehen wird, kann diese zu mynetworks hinzugefügt werden. Ich schätze, so funktionierte es im Fall des Themas, das ich zuvor verlinkt habe.

Das werde ich beim nächsten Update/Rebuild unseres Discourse sehen, wenn die geänderten SMTP-Einstellungen angewendet werden. Ich werde berichten, wie es funktioniert.

Aber es wäre immer noch interessant zu wissen, ob es andere Wege gibt und was es mit dieser Einstellung “Delivery method” auf sich hat.

Postfix läuft auf dem Host, nicht in einem Container, aber es würde keinen großen Unterschied machen, da es sich weiterhin um eine netzwerkbasierte Authentifizierung handelt.

Ja, ein Gedanke später: Es ist nur logisch, dass sendmail usw. vom Host/anderen Container nicht innerhalb eines Containers funktionieren können, da es direkten Zugriff auf weite Teile der Postfix-Executables, Bibliotheken und Konfigurationen erfordert, nehme ich an. Es sei denn, es gibt eine Art magischen Socket, der in den Container eingebunden werden kann oder so :smile:.

2 „Gefällt mir“
4

Es ist eine Weile her, seit ich mich so intensiv mit dem Mikromanagement von Sendmail beschäftigt habe. Ich habe den Mailcow-Stack auf einer VM und Discourse auf einer anderen. Ich weiß nicht, ob es sich jemals lohnt, so tief zu graben, außer zum Spaß.

Ich wünsche Ihnen alles Gute bei Ihren Abenteuern und berichten Sie, was Sie gelernt haben.

1 „Gefällt mir“
5

Wahrscheinlich nicht :sweat_smile:. Aber ich bin in bestimmten Kontexten perfektionistisch und genieße es, tief zu graben und alle Details zu lernen. Es hat mich mehrere Abende gekostet, Dovecot, Postfix, rspamd, dkimpy-milter, PostSRSd usw. Schritt für Schritt einzurichten, fast jede verfügbare Einstellung zu lernen, warum die Standardwerte so sind, ob und warum wir es anders haben wollen usw. Aber hey, jetzt scheine ich die meisten Dinge besser zu verstehen als die meisten Autoren von beliebigen E-Mail-Server-Anleitungen :face_with_tongue:.

6

Ich verschiebe dieses Thema nach Installation > Hosting. Wir empfehlen nicht, einen eigenen E-Mail-Server zu betreiben, wie Sie wissen, wenn Sie die offiziellen Installationsanweisungen gelesen haben. E-Mail ist schwierig!

7

Ich bin mir nicht sicher, was Discourse damit zu tun hat, ob das System zusätzlich einen E-Mail-Server hosten darf oder nicht? Abgesehen davon, dass dies theoretisch einen weiteren Weg eröffnet, E-Mails zu versenden, natürlich.

Für den Empfang von E-Mails (anderes Thema) hat es jedoch Auswirkungen, da man den E-Mail-Empfänger-Container nicht hosten kann, zumindest nicht direkt auf Port 25 lauschen. Aber die Nutzung der E-Mail-Empfänger-API von Discourse direkt stellte sich als nur 2-3 Zeilen in der Postfix-Konfiguration heraus: Is there a way to only IMAP polling for incoming emails - #2 by MichaIng

Aber ich stimme zu, die Einrichtung des E-Mail-Servers war, wie oben erwähnt, keine einfache Aufgabe. Aber super interessant zu lernen :slightly_smiling_face:.

1 „Gefällt mir“
8

Ja! Es ist sicherlich herausfordernd und interessant. Ich habe in meinem früheren Leben meine eigenen Abenteuer erlebt, indem ich alle Arten von Diensten installiert und selbst betrieben habe! :upside_down_face:

Ich freue mich, wenn Sie dieses Thema mit Ihren Erkenntnissen aktualisieren, um zukünftigen abenteuerlustigen Reisenden, einschließlich Ihnen selbst, zu helfen. Beachten Sie jedoch, dass die Kategorie Support für unterstützte Installationen, Discourse-Kern- und offizielle Plugins und Komponenten bestimmt ist.

1 „Gefällt mir“
9

was. Dovecoat gut. Warum dann Postfix? Warum nicht Dovecoat Exim?

10

Was ist los mit Postfix? Es war Teil des ersten Leitfadens zur Einrichtung von Mailservern, den ich gelesen habe, und seine internen Filteroptionen zur Reduzierung von Spam und Bot-Zugriffen frühzeitig in der Pipeline schienen ein gutes Argument zu sein.

Nun, irgendwie am Thema vorbei, bezüglich der Verwendung von sendmail/pickup durch Discourse.

Ich markiere dies als gelöst/beantwortet. Es ist sinnvoll, dass der Discourse-Container nicht auf das Sendmail des Hosts zugreifen kann, egal auf welchem Server. Daher muss er die SMTP-Zustellung verwenden, wofür man sich z. B. über den IP-Adressbereich des Docker-Containers in Postfix authentifizieren kann, wodurch die passdb/userdb-Authentifizierung bei Dovecot übersprungen wird.

11

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