install/mailsystem

Fork 0

Files

T

chris 3e525c4bde Add Readme files for Sender Rewriting Scheme (SRS).

2026-10-17 13:20:39 +02:00

9.0 KiB

Raw Blame History

README-SRS.md

Selektives SRS auf `mx.warenform.de` – Überblick

Stand: 17.10.2026

Diese Datei beschreibt bewusst nur, was eingerichtet wurde, warum es nötig ist und was im Betrieb zu beachten ist.

Für die technische Detaildokumentation siehe:

README-install-SRS.md

0. Das Grundproblem: Warum Weiterleitungen heute problematisch sein können

Mailserver wie Gmail, Microsoft, GMX oder Yahoo prüfen eingehende Nachrichten unter anderem mit SPF, DKIM und DMARC.

Bei einer klassischen Weiterleitung entsteht dabei ein grundsätzliches Problem:

ckubu@gmx.de
    |
    v
test@warenform.de
    |
    v
ckubu@gmail.com

Die ursprüngliche Nachricht kommt korrekt von einem GMX-Mailserver und besteht dort normalerweise den SPF-Test. Bei der Weiterleitung sendet anschließend aber mx.warenform.de die Nachricht weiter, während der Envelope-Absender ohne SRS weiterhin ckubu@gmx.de lautet.

Der Zielserver sieht damit vereinfacht:

Absender-Domain: gmx.de
sendender Server: mx.warenform.de

und prüft:

Darf mx.warenform.de E-Mails für gmx.de versenden?

Das ist natürlich nicht der Fall. Die weitergeleitete Nachricht kann deshalb trotz legitimer Herkunft einen SPF-Fehler erhalten.

Wenn zusätzlich die ursprüngliche DKIM-Signatur durch Änderungen an Headern oder Nachrichteninhalt ungültig wird, kann schließlich auch DMARC fehlschlagen. Bei strengen DMARC-Policies können Provider eine solche Nachricht ablehnen oder als Spam behandeln.

SRS löst das SPF-Problem, indem nur der SMTP-Envelope-Absender der weitergeleiteten Nachricht umgeschrieben wird:

ckubu@gmx.de

wird beispielsweise zu:

SRS0=...=gmx.de=ckubu@srs.warenform.de

Der sichtbare Header bleibt dagegen:

From: ckubu@gmx.de

Dadurch kann der Zielserver feststellen:

SPF   -> PASS für srs.warenform.de
DKIM  -> PASS für die ursprüngliche Absenderdomain gmx.de
DMARC -> PASS über die weiterhin gültige DKIM-Signatur

Genau dieses Verhalten wurde bei der hier dokumentierten Installation im End-to-End-Test bestätigt.

Wichtig ist dabei: SRS soll nicht pauschal auf alle ausgehenden Nachrichten angewendet werden, sondern nur auf echte externe Alias-Weiterleitungen. Daraus ergibt sich die selektive Architektur dieser Installation.

1. Ausgangssituation

mx.warenform.de ist ein produktiver Mailserver mit Postfix, AmaViS, SpamAssassin, ClamAV, OpenDKIM/OpenDMARC und Dovecot.

Der Server verwaltet auch Mail-Aliase, die teilweise an externe Empfänger weiterleiten.

Beispiel:

ckubu@gmx.de
    |
    v
test@warenform.de
    |
    +--> lokale Empfänger
    |
    +--> ckubu@oopen.de

Das Problem:

Bei einer klassischen Weiterleitung bleibt der ursprüngliche Envelope-Sender erhalten.

Dann würde mx.warenform.de eine Nachricht mit:

MAIL FROM:<ckubu@gmx.de>

an einen fremden Server weiterleiten.

Der fremde Server prüft SPF und sieht dabei:

Absenderdomain: gmx.de
sendender Server: mx.warenform.de

Da mx.warenform.de nicht zum SPF von GMX gehört, kann die legitime weitergeleitete Mail einen SPF-Fehler bekommen.

2. Lösung

Für echte externe Alias-Weiterleitungen wird der Envelope-Sender per SRS umgeschrieben.

Aus:

ckubu@gmx.de

wird beispielsweise:

SRS0=...=gmx.de=ckubu@srs.warenform.de

Dadurch prüft der Zielserver SPF gegen:

srs.warenform.de

und damit gegen eine Domain, für die mx.warenform.de tatsächlich senden darf.

3. Warum nicht einfach alle Nachrichten mit SRS umschreiben?

Weil SRS nur für Weiterleitungen benötigt wird.

Nicht umgeschrieben werden sollen:

normale ausgehende Mails,
lokale Mailbox-Zustellungen,
lokale Aliase,
root -> argus@oopen.de,
Dovecot/Sieve-Benachrichtigungen,
Bounces mit leerem Envelope-Sender.

Deshalb wurde eine selektive SRS-Lösung gebaut.

Sie entscheidet für jeden Empfänger einzeln:

SRS
oder
NO_SRS

4. Warum die Lösung relativ aufwendig ist

Mehrere technische Probleme mussten gleichzeitig gelöst werden.

Alias-Information darf nicht verloren gehen

Nach der Viren-/Spamprüfung über AmaViS muss noch erkennbar sein:

ursprünglicher Empfänger: test@warenform.de
endgültiges Ziel:         ckubu@oopen.de

Sonst könnte die SRS-Logik nicht erkennen, dass überhaupt eine Weiterleitung stattgefunden hat.

Deshalb wurde die Reihenfolge der Postfix-Adressumschreibung bewusst angepasst.

Ein Alias kann lokale und externe Ziele enthalten

Zum Beispiel:

test@warenform.de
  -> lokale Mailbox
  -> lokale Mailbox
  -> externe Adresse

Nur das externe Ziel braucht SRS.

Darum wird die Entscheidung pro Empfänger getroffen.

Bounces müssen zurückkommen können

Ein fremder Mailserver sieht als Envelope-Sender eine SRS-Adresse.

Wenn er einen Bounce erzeugt, muss diese Adresse wieder auf den ursprünglichen Absender zurückgeführt werden.

Deshalb gibt es zusätzlich einen Reverse-SRS-Pfad.

DKIM soll erhalten bleiben

SRS verändert nur den Envelope-Sender.

Der sichtbare:

From:

Header und die ursprüngliche DKIM-Signatur bleiben erhalten.

Das ist wichtig, damit DKIM und DMARC weiterhin funktionieren.

5. Produktive Komponenten

PostSRSd:

/usr/local/postsrsd -> /usr/local/postsrsd-2.4.1

Skripte:

/usr/local/sbin/srs-forward.py
/usr/local/sbin/srs-alias-decision.py
/usr/local/sbin/srs-reverse-map.py
/usr/local/sbin/srs-reverse-policy.py

Dienste:

postsrsd-srs.service
srs-reverse-map.service
postfix@srs-delivery.service
postfix.service

SRS-Delivery-Konfiguration:

/etc/postfix-srs/delivery

PostSRSd-Konfiguration:

/etc/postsrsd-srs

6. Ports

25      normaler SMTP-Eingang
10003   PostSRSd
10004   Reverse-SRS-Map
10028   SRS-Reinjection
10029   Reverse-SRS-Reinjection

Die SRS-internen Ports sind nur lokal erreichbar.

7. Postfix-Hauptkonfiguration

In /etc/postfix/main.cf gibt es einen automatisch verwalteten Bereich:

# BEGIN OOPEN-SRS-MANAGED
...
# END OOPEN-SRS-MANAGED

Dieser Block und insbesondere seine Marker sollen nicht manuell verändert werden.

Aktive SRS-Einstellungen:

default_transport = srs-forward
srs-forward_destination_recipient_limit = 1
recipient_canonical_maps = socketmap:inet:127.0.0.1:10004:reverse

Die separate SRS-Delivery-Postfix-Instanz wird nicht mit postmulti verwaltet.

Sie läuft direkt als:

postfix@srs-delivery.service

8. Verifizierter Normalfall

Test:

ckubu@gmx.de
    ->
test@warenform.de
    ->
ckubu@oopen.de

Am Ziel kam tatsächlich an:

Return-Path:
<SRS0=...=gmx.de=ckubu@srs.warenform.de>

Der Zielserver meldete:

SPF_PASS
DKIM_VALID
DMARC_PASS

Die originale GMX-DKIM-Signatur blieb also gültig.

9. Verifizierter lokaler Sonderfall

Lokaler Alias:

root -> argus@oopen.de

Ergebnis:

NO_SRS

Der Envelope-Sender bleibt:

root@mx.warenform.de

Das ist ausdrücklich so gewünscht.

10. Reboot-Test

Nach einem vollständigen Reboot waren automatisch aktiv:

postsrsd-srs.service
srs-reverse-map.service
postfix@srs-delivery.service
postfix.service

und die erwarteten Listener:

Forward- und Reverse-SRS funktionierten ebenfalls nach dem Reboot.

11. Was bei Änderungen besonders zu beachten ist

Folgende Punkte sind nicht zufällig, sondern Teil des Designs:

SRS nur für echte externe Weiterleitungen.
Entscheidung pro Empfänger.
ursprünglicher Alias-Empfänger muss erhalten bleiben.
Reverse-SRS muss erreichbar sein.
keine globale Umschreibung aller Absender.
kein postmulti.
interne SRS-Ports nur auf Loopback.
originale DKIM-Signatur möglichst unverändert lassen.
Null-Sender niemals mit SRS umschreiben.
root und andere lokale Aliase korrekt erkennen.
btree:-Maps mit postmap btree:/... erzeugen.

12. Betriebskontrolle