Reverse-Proxy für SMTP-Server

Die wichtigsten Vorteile:

• Sicherheit Es kann böswillige Anfragen blockieren, den Datenverkehr verschlüsseln,
  und Backend-Server vor direkten Angriffen schützen.
• Leistung Es verteilt den eingehenden Datenverkehr auf mehrere Server, wodurch eine Überlastung
  eines einzelnen Servers verhindert und eine höhere Verfügbarkeit gewährleistet wird.
• Skalierbarkeit Damit können Sie Backend-Server ohne Unterbrechung des Dienstes hinzufügen oder entfernen,
  wodurch Sie in der Lage sind, steigendes Datenaufkommen zu bewältigen.

HTTP-only-Reverse-Proxy (Layer 7)

Im Internet stehen verschiedene Tools zur Verfügung; nach eingehender Recherche haben wir zunächst diejenigen ausgeschlossen, die nur das HTTP-Protokoll (Schicht 7) unterstützen:

KEIN Apache-
„Oh je. Nehmen Sie sich einen Moment Zeit, um sich mit den Technologien vertraut zu machen, mit denen Sie arbeiten. E-Mails nutzen SMTP. Apache nutzt HTTP. Apache hat absolut keine Ahnung von SMTP. Wenn Sie mit E-Mail-Nachrichten arbeiten möchten, benötigen Sie eine Technologie, die SMTP versteht.“ – EEAA, kommentiert am 18. August 2016 um 2:49 Uhr

NEIN Caddy
„Caddy kann kein TCP-Proxy sein, sondern nur HTTP über TCP. Verwenden Sie einen Reverse-Proxy, der TCP-Proxy unterstützt, wie Traefik, Nginx oder haproxy, oder nutzen Sie dieses experimentelle Plugin.“ – ElevenNotes, kommentiert am 24. September 2024

Wir haben uns dann auf die drei in den Kommentaren empfohlenen Lösungen konzentriert: „Traefik, NginX oder HAProxy“, und sie nacheinander installiert und getestet.

Traefik war die erste Wahl.

Die meisten Anleitungen begannen mit Docker, einer Plattform, die ich vermeiden und stattdessen eine einfache Lösung wählen wollte, möglicherweise basierend auf einem der Linux-Paketmanager, wie beispielsweise YUM für RPM-basierte Distributionen wie Fedora und CentOS, oder APT (Advanced Package Tool), das bei Debian-basierten Distributionen wie Ubuntu und Debian zum Einsatz kommt.

Nach langer Suche sind wir auf diesen aktuellen Artikel gestoßen, der genau die Art der Installation beschreibt, nach der wir gesucht haben: Traefik als systemd-Dienst einrichten.

Ein Hinweis: Sie müssen die SELinux-Einstellungen von „Enforcing“ auf „Permissive“ ändern.

Nachdem wir erneut zwei Kurse auf Udemy ausprobiert hatten, stießen wir auf diesen hervorragenden Kurs: Traefik Crash Course (ohne Docker) Es gelang uns, das Tool zum Laufen zu bringen, indem wir die bereitgestellten Beispiele nachstellten. Gegen Ende des Videos äußerte der hervorragende Kursleiter seine völlige Ablehnung gegenüber diesem Tool: Traefik Crash Course – 53:50 Zusammenfassung.
Dies hielt uns von weiteren Tests ab, sodass wir uns entschlossen, etwas anderes auszuprobieren.

NginX war die zweite Wahl

In diesem Fall war die Installation einfacher, kurz gesagt mit YUM:
yum install epel-release nginx nginx-mod-stream nginx-mod-mail
Hinweis: In SELinux müssen Sie „relay“ aktivieren:
setsebool -P httpd_can_network_relay 1

Für die Schulung sind wir auf Nummer sicher gegangen und haben denselben Dozenten wie beim letzten Kurs engagiert: NginX-Crashkurs (der erste Teil endet nach etwa einer Stunde und zwanzig Minuten). Auch der Kursleiter ist von dieser Anwendung NICHT überzeugt, insbesondere von der Tatsache, dass sie sowohl als Webserver als auch als Reverse-Proxy fungiert: NginX-Crashkurs – 1:20:10 Zusammenfassung.
Der Bericht endet mit den Worten „Ich würde HAProxy gegenüber NginX vorziehen“, also haben wir beschlossen, auch HAProxy auszuprobieren.

Schließlich haben wir auch HAProxy ausprobiert.

Die Installation war kinderleicht, da es sich um eine sehr verbreitete Anwendung handelt, die in allen Linux-Paketmanagern verfügbar ist, zum Beispiel: yum install haproxy

Wir haben auch unseren bewährten Kursleiter zu Rate gezogen: HAProxy-Crashkurs.

Es funktioniert zwar, ist aber leider NICHT für die SMTP-Authentifizierung geeignet:
„Es ist nicht möglich, HAProxy auf diese Weise zu konfigurieren, da HAProxy SMTP überhaupt nicht unterstützt.“
– lukastribus, kommentiert am 17. August 2023

Ein Standard-SMTP-Server als Reverse-Proxy

Nach zwei Wochen Testphase haben wir festgestellt, dass
es besser ist, einen Standard-SMTP-Server als Reverse-Proxy für andere SMTP-Server zu verwenden.

Es erfüllt seinen Zweck, nutzt ausschließlich das SMTP-Protokoll, authentifiziert Verbindungen ordnungsgemäß,
und kann Anfragen über die „smarhost“-Funktion an andere SMTP-Server weiterleiten.

In Postfix, in der Datei „main.cf“, wie folgt:
relayhost = [smarthost_address]:port

In Sendmail, in der Datei „sendmail.mc“, wie folgt
define(`SMART_HOST',`mail.example.com')

Zurück zum Anfang