· DevOps  · 3 Min. Lesezeit

Ein Mail-Relay und eine Formular-Bridge für viele statische Seiten

Statische Seiten brauchen trotzdem Kontaktformulare und zuverlässige Systemmails. Wie ich das zentral über ein Postfix-Relay und eine kleine Bridge löse, ohne Formspree und ohne SMTP-Zugangsdaten im Frontend.

Statische Seiten brauchen trotzdem Kontaktformulare und zuverlässige Systemmails. Wie ich das zentral über ein Postfix-Relay und eine kleine Bridge löse, ohne Formspree und ohne SMTP-Zugangsdaten im Frontend.

Statische Seiten sind schnell und wartungsarm, aber zwei Dinge brauchen trotzdem einen Mailweg: das Kontaktformular und die Systemmails der Dienste dahinter. Ich löse beides zentral, statt in jeder Seite SMTP-Zugangsdaten zu hinterlegen oder einen SaaS wie Formspree einzubinden. Zwei kleine Container reichen. Der erste ist der gemeinsame Ausgang, der zweite nimmt die Formulare entgegen.

Schritt 1 - Das Relay: ein Ausgang für alle

mailrelay ist ein Postfix im Null-Client-Modus. Ein Null-Client nimmt selbst keine Mail aus dem Netz an und stellt nichts lokal zu, er reicht alles an einen zentralen Relayhost weiter. Genau das brauche ich: Der Container nimmt Mail nur intern entgegen und leitet alles über einen Upstream-SMTP mit SASL-Authentifizierung und TLS nach draußen.

Die Zugangsdaten liegen so an genau einer Stelle, nicht in jeder Anwendung. Nach außen ist der Container nicht veröffentlicht, er ist nur aus dem internen Netz erreichbar.

Schritt 2 - Die Bridge: ein Endpunkt für alle Formulare

forms ist eine kleine HTTP-nach-Mail-Bridge. Ein Host bedient alle Seiten, der Empfänger und die erlaubten Herkünfte stehen als Zuordnung über den Origin-Header in der Konfiguration. Eine neue Seite ist eine Zeile, kein neuer DNS-Eintrag und keine neue Proxy-Regel:

SITES = {
  "https://example.de": {"to": "kontakt@example.de"},
  "https://andere-seite.de": {"to": "info@andere-seite.de"},
}

Dazu ein Honeypot-Feld gegen Bots, ein Reply-To aus der Absenderadresse und ein No-JS-Fallback, der nur same-origin weiterleitet, damit daraus kein offener Redirect wird.

Schritt 3 - Drei Fallen, die Mail im Container gern bereitet

Bis beides sauber lief, sind mir drei Dinge begegnet, die im Container-Betrieb typisch sind:

  • Postfix darf im Container nicht chrooten. In der chroot-Betriebsart laufen die Postfix-Prozesse in einem eigenen Wurzelverzeichnis. Dann fehlt ihnen die /etc/resolv.conf und der Relayhost lässt sich nicht auflösen. Ich habe das für alle Dienste in der master.cf abgestellt:
postconf -F '*/*/chroot=n'
  • Ein frisches Docker-Netz hatte keinen Ausgang. Unter rootless Docker kam ein neu angelegtes Extra-Netz nicht nach draußen. Die Container gehören ans bereits funktionierende Proxy-Netz.
  • DMARC hat die erste Mail geschluckt. Ein Absender ohne SPF- und DKIM-Ausrichtung lief bei einer Empfängerdomain mit p=reject ins Leere. Die Lösung war, den Absender auf eine ausgerichtete Domain umzustellen.

Ehrlich: Wer relayed, verantwortet die Zustellbarkeit

Ein eigener Mailweg heißt, dass ich selbst dafür sorge, dass die Mail auch ankommt. SPF, DKIM und DMARC müssen sauber gesetzt sein, sonst landet die freundlichste Systemmail im Spam. Wie diese drei Einträge zusammenspielen, habe ich im Beitrag E-Mail-Sicherheit mit SPF, DKIM und DMARC beschrieben. Der Vorteil bleibt: keine Zugangsdaten im Frontend, kein Formular-SaaS, ein Ausgang, den ich selbst kontrolliere.

Sie betreiben mehrere Seiten und wollen Formulare und Systemmails an einer Stelle sauber bündeln? Ich baue schlanke Mailwege ohne Fremd-Abhängigkeit, mit korrektem SPF/DKIM/DMARC. Mehr zu sicherer Kommunikation unter Sichere Kommunikation, das Erstgespräch ist unverbindlich.

Alex Jabi, Jabi IT

Alex Jabi

Ich betreue IT, Informationssicherheit und Datenschutz für KMU und Praxen an der Bergstraße und im Odenwald, persönlich, dokumentiert und ohne Cloud-Zwang.

Mehr über mich
Zurück zum Blog

Passende Artikel

Alle Artikel »