rspamd

DMS/docker-data/dms/config/rspamd/append.d/settings.conf

@@ -0,0 +1,80 @@
+# DMS-CUSTOM-APPEND
+# ===========================================================================
+# WICHTIG: Diese Datei wird von user-patches.sh an /etc/rspamd/local.d/settings.conf
+# ANGEHAENGT und nicht darueber kopiert. DMS legt in dieser Datei selbst eine
+# Regel fuer authentifizierte User ab (DMS::SED_TAG::1), die erhalten bleiben muss.
+# ===========================================================================
+#
+# Hintergrund
+# -----------
+# Externe Mail erreicht DMS nie direkt: SES -> S3/SQS -> email-worker -> SMTP.
+# Rspamd sieht als Client-IP daher immer den Worker-Container (172.x) statt des
+# echten Absender-Servers. Alle verbindungsbezogenen Pruefungen messen damit
+# unsere eigene Infrastruktur und liefern systematisch Strafpunkte:
+#
+#   HFILTER_HOSTNAME_UNKNOWN   6.0   (kein PTR fuer 172.x -> exakt die add_header-Schwelle)
+#   R_SPF_FAIL / R_SPF_SOFTFAIL 4.5 / 2.5
+#   R_DKIM_NA / R_DKIM_PERMFAIL 1.0 / 4.5
+#
+# Diese Gruppen werden fuer Einlieferungen aus dem Docker-Netz deaktiviert.
+# Inhaltsbezogene Pruefungen (Bayes, Fuzzy, URL-/Surbl-Blocklisten, MIME,
+# Attachment-Checks) bleiben vollstaendig aktiv - echter Spam wird also weiter
+# erkannt, nur eben anhand des Inhalts statt anhand einer Transportstrecke,
+# die rspamd hier gar nicht beurteilen kann.
+#
+# SPF/DKIM/DMARC gehen dadurch nicht verloren: SES prueft sie bereits mit der
+# echten Absender-IP. Das Ergebnis liegt im SQS-Payload (receipt.spamVerdict,
+# spfVerdict, dkimVerdict, dmarcVerdict). Sobald der Worker diese Verdicts als
+# Header stempelt, koennen sie hier per multimap wieder bepunktet werden.
+
+# ---------------------------------------------------------------------------
+# 1) Einlieferungen des email-workers (externe Mail + dessen Forwards/OOO)
+#
+# Der Worker setzt X-SES-Worker-Processed auf JEDER Mail, die er einliefert:
+#   delivered  = Originalmail an das lokale Postfach
+#   forwarded  = neu komponierte Weiterleitung (rules-processor.ts)
+#   ooo-reply  = Abwesenheitsantwort
+#
+# Die IP-Bedingung ist die Absicherung: ohne sie koennte ein externer Absender
+# den Header selbst setzen und die Auth-Pruefungen abschalten. Beide
+# Bedingungen werden von rspamd implizit mit UND verknuepft.
+# ---------------------------------------------------------------------------
+ses_worker_injected {
+  priority = 10;
+  ip = ["172.16.0.0/12", "127.0.0.0/8"];
+  header = {
+    "X-SES-Worker-Processed" = true;
+  }
+  apply {
+    groups_disabled = ["spf", "dkim", "dmarc", "hfilter"];
+    symbols_disabled = ["RDNS_NONE"];
+  }
+}
+
+# ---------------------------------------------------------------------------
+# 2) Lokale Re-Injection ohne Worker-Header
+#
+# Betrifft:
+#   - Sieve-Redirects fuer INTERNE Mail (accounting@ -> support@ -> Forwards).
+#     Diese Mail laeuft nie ueber SES/Worker, hat also keinen Worker-Header.
+#   - Roundcube, das ohne SASL-Auth aus dem Docker-Netz einliefert
+#     (ROUNDCUBEMAIL_SMTP_USER ist bewusst leer).
+#
+# Beides wurde bisher von der DOCKER_WL-Whitelist (-50) aufgefangen. Diese
+# Regel ersetzt sie - deutlich enger gefasst, weil sie an das Docker-Netz
+# gebunden ist statt an eine faelschbare Absenderdomain.
+#
+# Niedrigere Prioritaet als Regel 1: rspamd wertet Regeln nach Prioritaet aus
+# und nimmt den ersten Treffer, Worker-Mail landet also nie hier.
+#
+# ACHTUNG: Diese Regel setzt voraus, dass Port 25 NICHT oeffentlich erreichbar
+# ist (docker-compose.yml bindet ihn auf 127.0.0.1). Wird das je geaendert,
+# muss diese Regel weg - sonst umgeht jeder externe Absender die Pruefung.
+# ---------------------------------------------------------------------------
+local_reinjection {
+  priority = 5;
+  ip = ["172.16.0.0/12", "127.0.0.0/8"];
+  apply {
+    groups_enabled = ["dkim"];
+  }
+}