KeyHelp: E-Mail-Weiterleitungen mit SRS zuverlässig zustellen

Weiterleitungen gehören zu den häufigsten Wünschen in kleinen Firmen: Die Adresse info@ der Firmendomain soll im privaten Postfach des Chefs landen, die Bewerbungsadresse bei einem externen Dienstleister. Genau diese Mails kommen beim Ziel aber oft nicht an oder landen im Spam. Der Grund ist SPF: Der Zielserver sieht eine Mail mit dem Absender einer fremden Domain, die von Ihrem Server kommt, und Ihr Server steht nicht im SPF-Eintrag dieser Domain. Seit Version 24.1 vom Juni 2024 löst KeyHelp das mit dem Sender Rewriting Scheme (SRS). Diese Anleitung erklärt, was SRS auf einem KeyHelp-Server technisch macht, wie Sie Weiterleitungen einrichten und wie Sie die Umschreibung selbst nachweisen. Grundlage ist ein Server nach unserer Anleitung KeyHelp installieren und absichern.

Voraussetzungen

• KeyHelp ab 24.1: Laut Keyweb ist SRS bei Neuinstallationen ab dieser Version aktiv, bei aktualisierten Servern muss es eingeschaltet werden. Wir haben KeyHelp 26.1.1 auf Debian 12 getestet.
• Admin-Zugang zum Panel für den Schalter und Root per SSH für die Prüfbefehle.
• DNS-Zugriff auf den Hostnamen des Servers. SRS-Adressen enden auf den Hostnamen, nicht auf die Kundendomain. Der Hostname braucht deshalb einen eigenen SPF-Eintrag.
• Ein externes Testpostfach, an das Sie weiterleiten, um den Header beim Empfänger zu prüfen.
• Optional das Werkzeug swaks für Testmails (apt install swaks).

Schritt 1: Verstehen, was SRS umschreibt

Eine Mail hat zwei Absender: den sichtbaren im Header From: und den Umschlag-Absender aus dem SMTP-Befehl MAIL FROM, der später als Return-Path im Header steht. SPF prüft nur den Umschlag-Absender. Leitet Ihr Server eine Mail von absender@fremd.example weiter, steht dort weiterhin fremd.example, obwohl Ihre Server-IP sendet. Hat fremd.example ein striktes SPF mit -all, schlägt die Prüfung fehl.

SRS ersetzt nur diesen Umschlag-Absender. Der sichtbare Absender bleibt unverändert, der Empfänger sieht wie gewohnt absender@fremd.example. Die neue Adresse enthält einen Prüfwert (Hash), einen Zeitstempel, die Originaldomain und den Originalnamen. Dadurch kann Ihr Server einen Rückläufer später wieder der ursprünglichen Adresse zuordnen, und fremde Server können keine gültigen SRS-Adressen erfinden.

SRS behebt SPF, nicht DMARC: Weil die Umschlag-Domain danach nicht mehr zur From:-Domain passt, hängt ein DMARC-Ergebnis beim Empfänger von der DKIM-Signatur des Absenders ab. Bleibt die Mail beim Weiterleiten unverändert, bleibt diese Signatur gültig. DMARC und DKIM haben wir im Test nicht geprüft.

Verifizieren: Im Test kam die weitergeleitete Mail beim Zielserver so an (gekürzt):

X-Mail-Args: <SRS0=BW/V=HX=fremd.example=absender@kh.example.com>
X-Rcpt-Args: <extern@ziel.example> ORCPT=rfc822;info@testkunde.example
From: absender@fremd.example
To: info@testkunde.example

Schritt 2: SRS im Panel einschalten

Öffnen Sie im Admin-Bereich „Konfiguration“ → „E-Mail-Server“. Weiter unten steht der Eintrag „Sender Rewriting Scheme (SRS)“ mit der Beschreibung „Durch Aktivieren dieser Einstellung wird das Sender Rewriting Scheme (SRS) aktiviert, eine Methode zum Umschreiben des Absender-Envelopes einer E-Mail, damit das Sender Policy Framework (SPF) auch für E-Mail-Weiterleitungen funktioniert.“ Setzen Sie den Haken bei „Aktiviert“ und klicken Sie auf „Speichern“.

Das Panel meldet „Die Einstellungen wurden aktualisiert. Die Änderungen werden in wenigen Augenblicken wirksam.“ Die Konfiguration schreibt der KeyHelp-Cronjob, der jede Minute läuft. Im Test war die Änderung nach etwa einer Minute aktiv.

Verifizieren: Prüfen Sie die Postfix-Werte, die KeyHelp setzt:

postconf default_transport recipient_canonical_maps
systemctl is-active postsrsd

default_transport = smtp:127.0.0.1:10027
recipient_canonical_maps = tcp:127.0.0.1:10002
active

Ist SRS aus, steht dort default_transport = smtp und recipient_canonical_maps ist leer.

Schritt 3: Was KeyHelp intern einrichtet

KeyHelp nutzt das Debian-Paket postsrsd (im Test Version 1.10). Es läuft als eigener Dienst und bietet zwei Nachschlagetabellen an: Port 10001 schreibt Absender um, Port 10002 macht das rückgängig. Die Einstellungen stehen in /etc/default/postsrsd:

SRS_DOMAIN=kh.example.com
SRS_SEPARATOR==
SRS_SECRET=/etc/postsrsd.secret
SRS_HASHLENGTH=4
SRS_FORWARD_PORT=10001
SRS_REVERSE_PORT=10002

In Postfix leitet KeyHelp jede ausgehende Mail über einen zweiten, internen SMTP-Dienst auf 127.0.0.1:10027. Dieser nutzt einen eigenen Cleanup-Dienst cleanup-srs mit zwei Tabellen für den Umschlag-Absender. Die erste fragt in der KeyHelp-Datenbank nach, ob die Absenderdomain auf dem Server angelegt ist. Wenn ja, bleibt der Absender unverändert. Nur fremde Domains gehen an postsrsd. Ein Kommentar in /etc/postfix/mysql-virtual-srs-local-domains.cf begründet die Prüfung auf Domainebene: Kunden können aus PHP auch mit nicht existierenden Absenderadressen ihrer Domain senden.

Auf dem internen Dienst sind die Milter abgeschaltet (-o smtpd_milters=), Rspamd prüft die Mail also nicht ein zweites Mal. Die Datei /etc/postsrsd.secret enthält den Schlüssel für den Hash. Sichern Sie sie mit, wenn Sie den Server umziehen: Ein neuer Schlüssel macht alle noch laufenden Rückläufer ungültig.

Verifizieren: Eine Mail mit Absender Ihrer eigenen Domain bleibt unverändert, eine fremde wird umgeschrieben. Im Test:

from chef@testkunde.example   -> MAIL FROM:<chef@testkunde.example>
from absender@fremd.example   -> MAIL FROM:<SRS0=BW/V=HX=fremd.example=absender@kh.example.com>

Schritt 4: SPF-Eintrag für den Hostnamen prüfen

Nach der Umschreibung prüft der Zielserver SPF gegen den Hostnamen, im Beispiel kh.example.com. Verwaltet KeyHelp die DNS-Zone des Hostnamens, legt es v=spf1 a mx -all an. Liegt die Zone beim Domain-Anbieter, müssen Sie den Eintrag dort selbst setzen, sonst bringt SRS nichts.

dig +short TXT kh.example.com

Im Test haben wir die SPF-Prüfung mit dem Python-Paket python3-spf nachgestellt: einmal für den Originalabsender, einmal für die SRS-Adresse, jeweils mit der IP-Adresse des weiterleitenden Servers. Als Originaldomain diente example.com, die öffentlich v=spf1 -all veröffentlicht.

python3 -c 'import spf; print(spf.check2(i="SERVER-IP", s="absender@example.com", h="kh.example.com"))'

Verifizieren: Ohne SRS fiel die Prüfung durch, mit SRS bestand sie (die SRS-Adresse über den Nameserver des Testservers, der die Zone des Hostnamens hält):

absender@example.com                              ('fail', 'SPF fail - not authorized')
SRS0=7cRs=HX=example.com=absender@kh.example.com  ('pass', 'sender SPF authorized')

Schritt 5: Weiterleitung für ein Postfach einrichten

Weiterleitungen legen Sie pro Postfach an, als Kunde unter „E-Mail-Adressen“ beim jeweiligen Konto, Reiter „Weiterleitungen“. Dort gibt es zwei Einstellungen:

• „Weitergeleitete E-Mails auch im Postfach speichern“: Ohne Haken landet die Mail nur beim Ziel. Im Test lag sie dann nicht im Postfach.
• „Weiterleitungen“: eine oder mehrere Zieladressen, getrennt durch Leerzeichen, Komma, Semikolon oder Zeilenumbruch.

Unter dem Feld steht der Hinweis „Wenn Sie eine externe E-Mail-Adresse verwenden, die nicht von diesem Server verwaltet wird, müssen Sie diesen Server möglicherweise in den SPF-Einstellungen (SPF = Sender Policy Framework) des externen Servers auf die Whitelist setzen.“ Mit aktivem SRS ist das in der Regel nicht nötig. Weiterleitungen lassen sich auch per API setzen (Feld forwardings), wie unsere Anleitung zur KeyHelp-REST-API zeigt.

Verifizieren: Senden Sie eine Mail von einer fremden Adresse an das Postfach und prüfen Sie das Mail-Log:

journalctl -u postfix@- --since "-5min" | grep -E "SRS0|orig_to"

postfix/smtp: B28BD42663: to=<extern@ziel.example>, orig_to=<info@testkunde.example>, relay=127.0.0.1[127.0.0.1]:10027, status=sent
postfix/qmgr: 1F4F7428CD: from=<SRS0=BW/V=HX=fremd.example=absender@kh.example.com>, nrcpt=1 (queue active)

Beim Empfänger steht die SRS-Adresse im Header Return-Path.

Schritt 6: Rückläufer und Missbrauchsschutz prüfen

Kann das Ziel die Mail nicht zustellen, schickt es den Rückläufer an die SRS-Adresse. postsrsd prüft den Hash und setzt die Originaladresse wieder ein. Im Test wurde ein Rückläufer korrekt an absender@fremd.example weitergereicht:

postsrsd: srs_reverse: <SRS0=BW/V=HX=fremd.example=absender@kh.example.com> rewritten as <absender@fremd.example>
postfix/smtp: to=<absender@fremd.example>, orig_to=<SRS0=BW/V=HX=fremd.example=absender@kh.example.com>

Eine erfundene SRS-Adresse mit falschem Hash weist der Server ab. So kann niemand Ihren Server als offenes Relay für Rückläufer missbrauchen.

Verifizieren: Im Test mit dem Hash XXXX von außen:

postsrsd: srs_reverse: <srs0=xxxx=hx=fremd.example=absender@kh.example.com> not rewritten: Hash invalid in SRS address.
NOQUEUE: reject: RCPT from ziel.example[198.51.100.20]: 550 5.1.1 <SRS0=XXXX=...@kh.example.com>: Recipient address rejected: User unknown in local recipient table

Typische Fehler

Weiterleitungen landen trotz SRS im Spam

Prüfen Sie den SPF-Eintrag des Hostnamens (Schritt 4). Fehlt er, bekommt die SRS-Adresse kein SPF-Ergebnis. Bei uns lieferte die Prüfung über einen Resolver, der die Zone des Testhostnamens nicht kannte, nur none.

Rückläufer kommen beim Server an und werden verzögert

Im Test bekam ein gültiger Rückläufer von außen zunächst „4.7.1 Try again later“. Das ist das Greylisting von Rspamd, nicht SRS. Der sendende Server stellt später erneut zu. Wie Sie Greylisting steuern, steht in unserer Anleitung zum Rspamd-Spamfilter in KeyHelp.

SRS ausgeschaltet, Dienst läuft trotzdem

Nach dem Abschalten im Panel lief postsrsd im Test weiter, Postfix nutzte ihn aber nicht mehr. Maßgeblich ist die Ausgabe von postconf default_transport.

Weiterleitung an eine fremde Domain wird abgewiesen

Postfix prüft eingehende Absender mit reject_unknown_sender_domain. Existiert die Absenderdomain nicht im DNS, wird die Mail schon beim Eingang mit „450 4.1.8 Sender address rejected: Domain not found“ abgelehnt und gar nicht erst weitergeleitet.

Häufige Fragen

Ändert SRS den Absender, den der Empfänger sieht?

Nein. Nur der Umschlag-Absender ändert sich. From: blieb im Test unverändert.

Werden auch normale Mails meiner Kunden umgeschrieben?

Nein, solange die Absenderdomain auf dem Server angelegt ist. Umgeschrieben werden nur Mails mit fremder Absenderdomain, also vor allem Weiterleitungen.

Sollte ich SRS abschalten?

Nur mit gutem Grund. Ohne SRS fiel die nachgestellte SPF-Prüfung im Test durch, weil die Originaldomain SPF mit -all nutzt. Mit abgeschaltetem SRS ging die weitergeleitete Mail mit dem unveränderten Absender absender@fremd.example hinaus.

Testumfang

Wir haben SRS auf KeyHelp 26.1.1 unter Debian 12 in einer virtuellen Maschine mit einem simulierten externen Zielserver geprüft: Umschreibung, Ausnahme für lokale Domains, Rückläufer, gefälschte Hashes und das Abschalten im Panel. Auffällig war, dass der Hostname und nicht die Kundendomain in der SRS-Adresse steht. Nicht geprüft wurden echte Empfänger wie Gmail sowie DKIM und DMARC. Senden Sie nach dem Einschalten eine Testmail an ein externes Postfach.

Fazit

SRS ist in KeyHelp mit einem Haken erledigt und arbeitet im Hintergrund zuverlässig: Weiterleitungen bestehen die SPF-Prüfung, Rückläufer finden zurück, gefälschte Rückläufer werden abgewiesen. Die wichtigste Nacharbeit liegt außerhalb des Panels: Der Hostname braucht einen SPF-Eintrag, der die Server-IP erlaubt. Wer SPF, DKIM und DMARC für seine Domains insgesamt sauber aufstellen will, findet Hinweise in unserer Anleitung zum Domainumzug mit DNS, MX, SPF und DKIM.

Weiterführende Anleitungen und Quellen

• KeyHelp installieren und absichern: das kostenlose Hosting-Panel für eigene Server
• KeyHelp: Rspamd-Spamfilter einrichten und einstellen
• Keyweb: KeyHelp 24.1 mit Sender Rewriting Scheme
• PostSRSd, Projektseite
• RFC 7208: Sender Policy Framework