E-Mail-Zustellung: das authentifizierte SMTP-Relay

E-Mail-Verifizierung, Passwort-Wiederherstellung und MFA-Einrichtung hängen alle an einer Sache: Sicherheitskritische Mails müssen tatsächlich ankommen. Öffentliche Cloud-Anbieter blockieren häufig ausgehenden Port 25, sodass ein in der Cloud laufendes Keycloak oder eine Anwendung nicht direkt zustellen kann. Als Übergangslösung betreibt die Plattform ihr eigenes gehärtetes Ausgangs-Relay auf einer Infrastruktur ohne Einschränkung beim Mailversand, und alle Anwendungen übermitteln ihre Mails über authentifiziertes TLS dorthin.

Bewusst nur eine Übergangslösung

Dieses Relay ist ein gewollter Zwischenschritt. Anwendungen kennen nur „einen SMTP-Submission-Endpunkt mit Zugangsdaten“, sodass er später durch einen Transaktions-Mail-Anbieter ersetzt werden kann, indem man nur die Konfiguration ändert — ohne Änderung am Anwendungscode.

Architektur

flowchart LR
    subgraph Cloud["Cloud-Umgebungen (Port 25 blockiert)"]
        KC[Keycloak]
        APP[Anwendungen]
    end

    subgraph Relay["Relay-Host (uneingeschränkter Ausgang)"]
        SUB["Postfix<br/>Submission :587<br/>TLS Pflicht + SASL"]
    end

    MX[Mailserver der Empfänger]

    KC -- "STARTTLS + SASL-Login" --> SUB
    APP -- "STARTTLS + SASL-Login" --> SUB
    SUB -- "Direktzustellung über den MX des Empfängers" --> MX

Das Relay ist eine einzelne Postfix-Instanz mit Cyrus SASL, bereitgestellt durch eine Ansible-Rolle, die deaktiviert bleibt, solange ein Deployment sie nicht aktiviert. Nichts in der Rolle nennt einen Kunden: Jeder Aufrufer ist nur ein weiterer Eintrag in einer Liste.

Sicherheitseigenschaften

Eigenschaft	Wie sie durchgesetzt wird
Kein Open Relay	`smtpd_relay_restrictions = permit_sasl_authenticated, reject` — kein `permit_mynetworks` und kein offener Fallback. Selbst eine Loopback-Verbindung muss sich anmelden
Kein Server für eingehende Mail	Der einfache `smtp`-Listener (Port 25) ist aus `master.cf` entfernt; der Host stellt nur den Dienst `submission` auf 587 bereit
Verschlüsselung ist Pflicht	`smtpd_tls_security_level = encrypt` — Zugangsdaten werden nie auf einer unverschlüsselten Sitzung akzeptiert; SSLv2/3 und TLS 1.0/1.1 sind deaktiviert
Anonymer Zugriff unmöglich	`smtpd_sasl_security_options = noanonymous`
Identität pro Aufrufer	Ein SASL-Konto pro Aufrufer. Jede Sitzung ist zuordenbar, und eine geleakte Zugangsdate wird durch Löschen genau dieses Kontos widerrufen
Vertrauenswürdiges Zertifikat	Let's-Encrypt-Zertifikat, automatisch ausgestellt und erneuert (HTTP-01), mit Reload-Hook, der Postfix bei der Erneuerung neu startet
Geheimnisse bleiben aus Logs	Kontopasswörter werden in der Automatisierung mit `no_log` behandelt und nie im Repository gespeichert
Sichere Rotation	Kontoanlage ist create-if-missing; eine Rotation ist entfernen → anwenden → neu hinzufügen, nie ein stilles Überschreiben

Einen Aufrufer anbinden

Ein Aufrufer (z. B. ein Identity Provider) benötigt vier Werte: den Relay-Hostnamen, Port 587, STARTTLS sowie einen eigenen Benutzernamen/ein eigenes Passwort. In Keycloak stehen diese in den E-Mail-Einstellungen des Realms:

Keycloak-Feld	Wert
Host	der öffentliche Hostname des Relays
Port	`587`
Enable StartTLS	an
Authentication	an, mit dem eigenen Konto des Aufrufers
From	eine Adresse in einer Domain, die Sie kontrollieren

Einen Aufrufer hinzuzufügen ist eine einzeilige Änderung an der Benutzerliste des Relays, gefolgt von einem Apply:

fab provide --env deployment --tags smtp_relay[smtp_relay] Install postfix + Cyrus SASL ... ok
[smtp_relay] Deploy main.cf / master.cf ... changed
[smtp_relay] Create missing SASL accounts ... changed
[smtp_relay] Issue Let's Encrypt cert for the relay hostname ... ok
[smtp_relay] Enable and start postfix ... ok

Das Relay prüfen

Prüfen Sie die Sicherheitslage von außen und senden Sie dann eine echte Nachricht.

nc -zv -w 3 mail-relay.example.com 25nc: connect to mail-relay.example.com port 25 (tcp) failed: Connection refused# nichts lauscht auf eingehende Mailopenssl s_client -starttls smtp -connect mail-relay.example.com:587 -brief </dev/null 2>&1 | grep -E "Protocol|Verification"Protocol version: TLSv1.3
Verification: OK
swaks --server mail-relay.example.com --port 587 --tls \ --to [email protected] --from [email protected]<~ 530 5.7.0 Authentication required# nicht authentifizierte Übermittlung wird abgewiesenswaks --server mail-relay.example.com --port 587 --tls \ --auth LOGIN --auth-user "$SMTP_USER" --auth-password "$SMTP_PASS" \ --to [email protected] --from [email protected]<~ 250 2.0.0 Ok: queued as 4F1C0A2B3D

Checkliste zur Zustellbarkeit

Ein Relay hilft nur, wenn Empfänger seiner Mail vertrauen. Halten Sie die Absender-Domain konsistent mit:

SPF — autorisieren Sie die Adresse des Relays im SPF-Eintrag der Domain.
DKIM — signieren Sie ausgehende Mails für die Absender-Domain.
DMARC — veröffentlichen Sie eine Richtlinie, damit Empfänger die Übereinstimmung prüfen können.
Reverse-DNS — die IP des Relays sollte auf seinen Hostnamen zurückauflösen.

Sicherheits-Mails sind ein Ziel

Verifizierungs- und Reset-Mails sind genau das, was Phisher nachahmen. Halten Sie die From-Domain fest, lassen Sie Links nur auf Ihren Keycloak-Host zeigen und nehmen Sie nie ein Geheimnis in den Nachrichtentext auf — die Links sind bewusst signiert und laufen ab (siehe E-Mail-Verifizierung & MFA).