mailsystem/README-install-SRS.md

Selektives SRS – Installation und Betrieb

Stand: 23. Oktober 2026 Geltungsbereich: Aktuelle Skripte dieses Repositories; Debian 13/Postfix Status: Erfolgreicher End-to-End-Test auf e.mx.oopen.de; Fehlerfalltests offen

Siehe auch README-SRS.md fuer Architektur, Abhaengigkeiten und bewusst akzeptierte Grenzen.

1. Voraussetzungen

Die regulaere Postfix-Installation muss funktionsfaehig sein. Virtuelle Alias-Weiterleitungen und AmaViS-Reinjektion muessen bekannt und getestet sein. Die SRS-Domain braucht passende oeffentlich aufloesbare DNS-Eintraege. Die Installationspruefung kontrolliert die autoritativen Nameserver sowie SPF und MX im vorgesehenen Setup.

Die Hostkonfiguration liegt in conf/srs.conf; als Ausgangspunkt dient conf/srs.conf.sample. Beim Aufruf wird die gewaehlte SRS-Domain angezeigt und bestaetigt. Fuer den Testserver wurde srs.e.mx.oopen.de verwendet; diese Domain ist kein universeller Standard fuer andere Hosts.

Die Skripte werden in diesem Repository als root ausgefuehrt. Vor Installation oder Aktivierung Backups und einen Wartungs-/Rueckbauplan bereithalten. Keines der Skripte ersetzt die Kontrolle des Mailflusses.

2. Lesende Installationspruefung

cd /usr/local/src/mailsystem || exit 1
./install-update-srs.sh --help
./install-update-srs.sh --check

--check fragt nach der SRS-Domain, prueft Voraussetzungen und inventarisiert die Installation, ohne den Zustand des Systems zu veraendern. Fehlende DNS-Konfiguration zuerst korrigieren, nicht die Vorpruefung umgehen.

3. Installation oder Update

cd /usr/local/src/mailsystem || exit 1
./install-update-srs.sh --install

Standardversion: PostSRSd 2.4.1. Fuer eine andere Version steht --version X.Y.Z zur Verfuegung. Der Ablauf enthaelt eine Bestaetigung fuer die Vorbereitung und eine gesonderte Bestaetigung fuer die Installation der vorbereiteten Dateien. Unter anderem werden PostSRSd gebaut, die Upstream-Tests ausgefuehrt, Dateien und Dienste vorbereitet und ein Backup angelegt. Aktive SRS-Integration verhindert laut Installer-Logik ein Update.

Wichtig: --install aktiviert nicht die selektive SRS-Verarbeitung im regulaeren Postfix und startet die SRS-Dienste nicht. Die Anzeige des Backup-Pfads ist aufzubewahren. Das SRS-Secret bei Updates unveraendert erhalten, damit fruehere SRS-Adressen ueberpruefbar bleiben.

4. Selektives SRS aktivieren

cd /usr/local/src/mailsystem || exit 1
./activate-srs.sh

Das Skript prueft die Installation, Laufzeitdienste, Ports und den bisherigen Postfix-Zustand. Bei DISABLED zeigt es eine Zusammenfassung und fordert eine ausdrueckliche Bestaetigung. Erst danach werden Sicherungen erstellt, die verwalteten Konfigurationsbloecke eingesetzt, Dienste gestartet und Postfix neu geladen. Bei inkonsistentem Zustand nicht manuell fortfahren, sondern Ursache klaeren.

Kontrolle nach Aktivierung

systemctl is-active postfix.service
systemctl is-active postsrsd-srs.service srs-reverse-map.service postfix@srs-delivery.service
postconf -h default_transport
postconf -M srs-forward/unix
postqueue -j
postqueue -c /etc/postfix-srs/delivery -j

Der aktivierte Transport ist srs-forward. Die SRS-Delivery-Instanz ist gesondert zu kontrollieren. Ein erfolgreicher Service-Start beweist noch keine erfolgreiche externe Weiterleitung: Eine reale Testnachricht an eine virtuelle Alias-Adresse mit externem Ziel ist erforderlich. Im Journal sollten die PostSRSd-Umschreibung, die Reinjektion in die zweite Instanz und die SMTP-Uebergabe an den naechsten Mailserver nachvollziehbar sein.

5. Zweiphasig deaktivieren

cd /usr/local/src/mailsystem || exit 1
./deactivate-srs.sh

Die Deaktivierung ist interaktiv und prueft vor der Bestaetigung, dass der Zustand ENABLED konsistent und die SRS-Delivery-Queue leer ist.

Nach Bestaetigung:

1. Urspruengliche main.cf-Parameter und Empfangseinstellungen wiederherstellen; srs-forward zunaechst in master.cf belassen; alten Queue-Manager erfassen und Postfix neu laden.
2. Auf Beendigung des alten Queue-Managers und erkennbarer srs-forward-Arbeit sowie auf leere SRS-Delivery-Queue warten (maximal 180 Sekunden).
3. Pipe-Dienst und systemd-Abhaengigkeiten entfernen; erneut pruefen und laden; Queue erneut pruefen; alle drei SRS-Dienste stoppen und deaktivieren; Endzustand verifizieren.

Wenn beim Start bereits Nachrichten in der SRS-Delivery-Queue stehen, verweigert das Skript die Deaktivierung. Wird die Queue waehrend der Umschaltung nicht leer oder kann nicht gelesen werden, fuehrt das zu Abbruch und einem versuchten Rollback. Wartende Mails werden nicht absichtlich geloescht.

Die Installation, Binaries und /etc/postfix-srs/state.conf bleiben nach erfolgreicher Deaktivierung fuer eine spaetere Aktivierung erhalten.

Verspaetete SRS-Ruecklaeufer: Nach vollstaendiger Deaktivierung koennen spaet eintreffende Bounces an SRS-Adressen nicht mehr wie im aktiven Betrieb verarbeitet werden. Das ist eine bewusste Projektentscheidung; ein Reverse-only-Modus ist nicht vorgesehen. Der normale Postfix-Betrieb hat Vorrang. Details: README-SRS.md.

Kontrolle nach Deaktivierung

systemctl is-active postfix.service
systemctl is-active postsrsd-srs.service srs-reverse-map.service postfix@srs-delivery.service
systemctl is-enabled postsrsd-srs.service srs-reverse-map.service postfix@srs-delivery.service
postconf -h default_transport
postconf -M srs-forward/unix 2>/dev/null || true
postqueue -j

Alle SRS-Dienste sollen inactive und disabled sein; der Pipe-Dienst soll fehlen. Auf dem Testserver war default_transport danach wieder smtp (impliziter Standard). Die urspruenglichen, nicht explizit gesetzten Parameter sind nicht mehr Teil der lokalen main.cf.

Keine vermeintliche Null-Queue erzwingen: Bei gestoppter zweiter Instanz kann postqueue -c ... -j mit einer showq-Warnung scheitern. Das Kommando nicht blind mit wc -l zu einem angeblichen Erfolg zusammenfassen. Der sichere Leerstand wird waehrend der Deaktivierung bei laufender Instanz geprueft. Bei Bedarf die Queue-Dateien offline und mit Bedacht inspizieren.

Wichtiger Funktionstest nach der Deaktivierung

Eine Nachricht erneut an dieselbe externe virtuelle Alias-Weiterleitung senden. Im Mail-Log muss der regulaere postfix/smtp-Transport und der urspruengliche Envelope-Absender sichtbar sein. Auch eine lokale Zustellung sollte unveraendert funktionieren. Die erfolgreiche SMTP-Uebergabe an den naechsten Mailserver ist noch kein Beweis fuer den Postfacheingang.

6. Log- und Queue-Diagnose

journalctl --since "15 minutes ago" --no-pager |   grep -Ei 'srs-forward|postfix-srs-delivery|postsrsd|SRS0='

postqueue -j
# Nur waehrend die zweite Instanz laeuft:
postqueue -c /etc/postfix-srs/delivery -j

Bei Fehlern keine Dateien aus der SRS-Queue entfernen, um die Deaktivierung zu erzwingen. Zuerst Ursache und enthaltene Nachrichten klaeren. Die Backup-Verzeichnisse unter /root/postfix-srs-activation-* bzw. /root/postfix-srs-deactivation-* zusammen mit den Journalmeldungen sichern.

7. Getesteter Stand und ausstehende Pruefungen

Am 23. Oktober 2026 auf e.mx.oopen.de erfolgreich getestet: Installationsvorpruefung, Installation mit Upstream-CTest, Aktivierung, eine echte externe Alias-Weiterleitung mit SRS, zweiphasige Deaktivierung, anschliessend dieselbe Weiterleitung ohne SRS. Beide Postfix-Queues waren zum Zeitpunkt der abschliessenden Kontrolle leer.

Noch nicht praktisch nachgewiesen: Ein absichtlich ausgeloester Fehler mit vollstaendigem Rollback und die Deaktivierung unter anhaltender Zustelllast. Die isolierten Mock-Tests ersetzen diese Integrationstests nicht.

8. Historische Dokumentation

Die ausfuehrlichen Texte und frueheren Entwicklungsnotizen vom 20. Oktober 2026 verbleiben unveraendert in archive/selective-srs-2026/. Sie sind keine aktuelle Installationsanleitung.

Oeffentlicher MX-Hostname und SRS-Domain

Der lokale Systemhostname (hostname -f) kann vom oeffentlichen MX-Hostnamen abweichen.

Der Installer fragt deshalb den oeffentlichen MX-Hostnamen separat ab. Als Vorgabe verwendet er hostname -f. Bei einer Erstinstallation wird die SRS-Domain aus srs.<MX-Hostname> vorgeschlagen.

Beispiel fuer mail.interventionistische-linke.org:

_MX_HOST="mail.interventionistische-linke.org"
_SRS_DOMAIN="srs.mail.interventionistische-linke.org"

Beide Werte werden in conf/srs.conf gespeichert.

Bei einer bestehenden SRS-Konfiguration bleiben die bereits konfigurierten Werte erhalten. Fehlt lediglich _MX_HOST, wird dieser Parameter bei einem Wartungsupdate ergaenzt.

Erforderliche DNS-Eintraege fuer das Beispiel:

srs.mail.interventionistische-linke.org. IN MX 10 mail.interventionistische-linke.org.
srs.mail.interventionistische-linke.org. IN TXT "v=spf1 mx -all"

Der Installer prueft die oeffentlichen DNS-Eintraege ueber die autoritativen Nameserver.

Mit ./install-update-srs.sh --check kann die System- und DNS-Vorpruefung ohne Aenderung der Installation ausgefuehrt werden.