# 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](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 ```bash 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 ```bash 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 ```bash 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 ```bash 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 ```bash 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](README-SRS.md). ### Kontrolle nach Deaktivierung ```bash 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 ```bash 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/`](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.` 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.