KeyHelp‑Mailserver härten – Weiterleitungen, Spam, Bounces & Abuse‑Schutz (updatesicher)

[Systemweb]

Viele KeyHelp‑User kennen das Problem:

• Weiterleitungen schicken Spam an GMX/Google → Bounces → Reputation leidet

• Spam‑Bounces landen im Postfach

• gehackte Postfächer können ungebremst Spam versenden

• Rspamd filtert authentifizierte User nicht

Ich habe meinen Mailserver vollständig gehärtet – ohne KeyHelp‑Core zu verändern und updatesicher.
Diese Anleitung zeigt Schritt für Schritt, wie ihr das exakt so umsetzen könnt.

1. SASL‑Rate‑Limits aktivieren (Schutz vor gehackten Postfächern)
Damit ein kompromittiertes Postfach nicht tausende Mails pro Minute versenden kann, foldende Zeilen am Ende(!) der /etc/postfix/main.cf einfügen:

Code: Select all

# Begrenzung der ausgehenden Mails pro Client
smtpd_client_message_rate_limit = 60

# Begrenzung der Empfänger pro Client
smtpd_client_recipient_rate_limit = 120

Diese Limits sind mild und bremsen Bots zuverlässig aus, lassen aber weiterhin lokale Newsletter-Systeme zu.
Ein normales Newsletter‑System (z. B. PHPMailer, Mailwizz, Sendy, eigene PHP‑Skripte) sendet typischerweise 1 Mail pro Sekunde und überschreitet damit dieses Limit nicht.

2. Authenticated‑Bypass in Rspamd deaktivieren
Standard‑Rspamd filtert keine Mails, die über ein authentifiziertes Postfach gesendet werden.
Das ist gefährlich – ein gehacktes Postfach kann sonst ungehindert Spam verschicken.

Datei erstellen: /etc/rspamd/override.d/worker-proxy.inc

Code: Select all

# Auch authentifizierte User durch Rspamd filtern
allow_authenticated = false;

3. Greylisting aktivieren (optional, aber sehr wirksam)
Bots retryen nicht – echte Mailserver schon.

Datei: /etc/rspamd/local.d/greylist.conf

Code: Select all

# Greylisting aktivieren
enabled = true;

Greylist funktioniert praktisch wie ein Faxgerät, das einen "Übertragungsfehler" zurückmeldet, damit der Sender es noch einmal versucht. Erst beim 2. Versuch wird angenommen und zugestellt. Das gilt nur bei Erstkontakt. Danach lässt Greylist sofort passieren, da der Absender bereits bekannt ist.
Spam-Schleudern versuchen es i.d.R. kein 2. Mal, gewöhnliche Mailserver wiederholen die Zustellung nach kurzer Zeit noch einmal.

4. Spam‑Weiterleitungen blockieren (sehr wichtig!)
Damit Weiterleitungen keinen Spam mehr an GMX/Google schicken:

Datei anlegen: /etc/rspamd/override.d/force_actions.conf

Code: Select all

rules {
    # Spam bei Weiterleitungen blockieren (SRS-Adressen)
    BLOCK_SPAM_FOR_FORWARDS {
        expression = "spam | high_spam";
        action = "reject";
        message = "Spam rejected before forwarding";
        require_action = "no_action";
        rcpt = "/SRS0=/"; # Nur Weiterleitungen
    }

    # Spam-Bounces verwerfen (Backscatter verhindern)
    DROP_SPAM_BOUNCES {
        expression = "BOUNCE & spam";
        action = "discard";
        message = "Spam bounce discarded";
        require_action = "no_action";
    }
}

Damit werden:

• Weiterleitungen sauber

• Spam nicht mehr weitergeleitet

• Spam‑Bounces verworfen

• legitime Bounces weiterhin zugestellt

5. Dienste neu starten

Code: Select all

systemctl restart postfix
systemctl restart rspamd

6. Ergebnis
Nach dieser Härtung:

• Weiterleitungen schicken keinen Spam mehr an GMX/Google

• Spam‑Bounces werden verworfen

• gehackte Postfächer können keinen Spam mehr versenden

• Greylisting stoppt Bot‑Spam

• KeyHelp‑Updates bleiben vollständig kompatibel

7. Originalzustand wiederherstellen (Rollback‑Anleitung)
Falls ihr die Änderungen rückgängig machen wollt, geht das sauber und vollständig so:

A) SASL‑Rate‑Limits entfernen
In /etc/postfix/main.cf die beiden Zeilen löschen:

Code: Select all

smtpd_client_message_rate_limit = 60
smtpd_client_recipient_rate_limit = 120

B) Angelegte Dateien wieder entfernen
Dateien löschen:

Code: Select all

rm /etc/rspamd/override.d/worker-proxy.inc
rm /etc/rspamd/local.d/greylist.conf
rm /etc/rspamd/override.d/force_actions.conf

Falls hier Fehler ausgegeben werden, dann wurde bei der Einrichtung ein optionaler Schritt übersprungen. Das kann ignoriert werden.

C) Dienste neu starten

Code: Select all

systemctl restart postfix
systemctl restart rspamd

Das System verhält sich exakt wieder wie vor der Härtung.

[Florian]

Hallo,

erstmal danke für Deine Ausführungen. Ich bin besonders am Punkt " Spam‑Weiterleitungen blockieren" interessiert. Hat das bei dir so funktioniert? Ich konnte nach Umsetzung keine Änderung feststellen. Soweit ich gelesen habe, werden bei den force_actions auch gewisse Elemente wie rcpt nicht beachtet. rcpt = "/SRS0=/"; weiß ich auch nicht ob das von der Logik her stimmen würde, weil es wird ja der technische Absender so umgeschrieben, nicht der Empfänger.
Ich habe verschiedenes versucht, auch mithilfe der "künstlichen Allwissenden", aber da hat nichts wirklich was gebracht.

Ich habe es dann über die Header Cheks umgesetzt:

Code: Select all

/^X-Spamd-Bar:\s*\+{8,}/   DISCARD Forwarded spam blocked by system

Wenn du da ne Lösung hast, nur her damit.

[Systemweb]

Hallo Florian,

ich konnte die abgewiesenen weitergeleiteten Mails in der Queue mit dieser Lösung zwar reduzieren, aber nicht wirklich zuverlässig ausschließen.
Was zumindest gut funktioniert ist die Limitierung des Versands bei gehackten Postfächern.
Habe noch einige Zeit weiter daran gearbeitet, konnte mittels Backscatter-Regel FORGED_RECIPIENTS & !LOCAL_OUTBOUND sämtl. Weiterleitungen von Spam vollständig stoppen, legitime Mails gingen durch.
Dann tauchte aber das Problem auf, dass ich keine ZIP/HTML-Anhänge mehr versenden konnte. Die rspamd-Module "mime_types" und "file" blockierten das strikt wegen neuer actions.conf, so dass ich das Thema erstmal auf Eis gelegt hatte.

Man müsste in override.d/ weitere Configs anlegen, damit das letztlich sauber funktioniert: actions.conf und force_actions.conf sowie in local.d/ mime_types.conf und file.conf um das Problem mit den Anhängen zu lösen.

Aktuell nutze ich obige Lösung in Kombination mit einem eigenen Subject-Blacklister, habe aber täglich noch bis zu 10 Spammails im Queue auf jedem meiner Keyhelpserver. Vorher wars mindestens das Dreifache.

Nachtrag: Neben Countryblock von Top-Ländern von Angriffen wie China, Rumänien usw. per nftables habe ich außerdem auch einen Block gegen bekannte Spammer-IPs aktiv.
Quelle: https://raw.githubusercontent.com/bores ... 0-30d.ipv4

[Systemweb]

Mein "künstlich Allwissender" meinte, dass ich insbesondere bei Google-Spam mit rspamd nicht weiterkomme. Google/GMX & Co. nutzen eigene Filter, basierend auf Deep-Learning-Modellen, Content-Fingerprinting usw. auf Basis von Milliarden erhaltener Mails.
Mir wurde deshalb empfohlen, das bevorzugt mittels Global-Sieve zu lösen, indem ich Mails filtere die Google mit Sicherheit abweisen würde und statt einer Weiterleitung nur lokal zustelle.
Rspamd kann diese Mails nicht als Spam erkennen, da in der Regel der Spamscore niedrig ist und DKIM sowie Server und Hostname etc. passen.

Dieses hier soll die endgültige, updatesichere Lösung sein.

Schritt 1: systemd‑Bug bei Dovecot‑Reload beheben
Ausführen:

Code: Select all

systemctl edit dovecot.service

Es öffnet sich eine Override‑Datei. Dort folgendes einfügen:

Code: Select all

[Service]
PrivateTmp=no

Abspeichern und schließen.

Dann:

Code: Select all

systemctl daemon-reload
systemctl reload dovecot

Jetzt funktioniert der Reload wieder zuverlässig.

Schritt 2: Globales Sieve in Dovecot aktivieren
KeyHelp aktiviert globales Sieve nicht automatisch. Konfiguration für Global Sieve ergänzen:

Code: Select all

nano /etc/dovecot/conf.d/90-sieve.conf

und am Ende hinzufügen:

Code: Select all

sieve_global_dir = /var/lib/dovecot/sieve-global

Abspeichern und schließen.

Ordner anlegen:

Code: Select all

mkdir -p /var/lib/dovecot/sieve-global

Schritt 3: Google‑Spam‑Filter als globales Sieve‑Skript
Datei anlegen:

Code: Select all

nano /var/lib/dovecot/sieve-global/90-no-forward-google-spam.sieve

Inhalt:

Code: Select all

require ["fileinto", "imap4flags", "regex"];

# Nur wenn die Mail weitergeleitet werden soll
if header :regex "X-Forwarded-For" ".*" {

    # 1) HTML-only (Google hasst das)
    if allof (
        header :contains "Content-Type" "text/html",
        not header :contains "Content-Type" "text/plain"
    ) {
        stop;
    }

    # 2) Tracking / Newsletter / Marketing
    if header :regex "List-Unsubscribe" ".*" {
        stop;
    }

    # 3) Rspamd hat Zweifel (Low-Score Spam)
    if header :regex "X-Spamd-Result" ".*(greylist|probable|suspect|unknown|neural).*" {
        stop;
    }

    # 4) Betreff enthält typische Google-Trigger
    if header :regex "Subject" "(invoice|payment|verification|security|alert|action required|package|delivery|update)" {
        stop;
    }
}

Schritt 4: Sieve‑Skript kompilieren
Ausführen:

Code: Select all

sievec /var/lib/dovecot/sieve-global/90-no-forward-google-spam.sieve

(Dadurch entsteht: /var/lib/dovecot/sieve-global/90-no-forward-google-spam.svbin)

Schritt 5: Dovecot neu laden
Ausführen:

Code: Select all

systemctl reload dovecot

Ich teste das jetzt und werde berichten.

[Ralph]

Code: Select all

/^X-Spamd-Bar:\s*\+{8,}/   DISCARD Forwarded spam blocked by system

Mit den header_checks ist schon ein guter Ansatz ... wenn der Rspamd Score vor der Weiterleitung auch bei deaktiviertem User Spam Schutz vorhanden bleibt.

Bzgl. dovecot ... greift hier nicht maildrop bei den Weiterleitungen bevor dovecot da überhaupt zum Einsatz kommt?

Momentan läuft Rspamd bei mir zwangsläufig im reject Mode mit einem Max Score der auf meine zusätzlichen Filter angepasst wurde ... vorab nimmt Postscreen das gröbste raus, ist viel Fummelei (Aufwand) von daher bin ich auch an einer milter basierenden Lösung speziell für Weiterleitungen interessiert.

[Systemweb]

...
Bzgl. dovecot ... greift hier nicht maildrop bei den Weiterleitungen bevor dovecot da überhaupt zum Einsatz kommt?
...

Nein. Maildrop greift nur bei benutzerdefinierten Filtern ein.
Weiterleitungen, die in KeyHelp gesetzt werden, laufen über Dovecot‑LMTP – und genau dort greift globales Sieve.
Maildrop kommt also nicht „davor“ und blockiert Sieve nicht.

[Ralph]

Interne Weiterleitungen (nur intern) könnten/sollten davon ausgeschlossen sein, aber auch für abuse, postmaster bzw. auch tco@domain.tld u. dsa@domain.tld sollten eventl. Ausnahmen möglich sein ...

[Systemweb]

Ich habe die Sieve-Lösung nun seit 48 Stunden im Einsatz. Mailqueue ist seitdem leer.

[Systemweb]

Ich habe die Sieve-Lösung nun seit 48 Stunden im Einsatz. Mailqueue ist seitdem leer.

Ich muss leider zurück rudern. Habe ja gesagt, dass ich teste und berichten werde. Die 48 Stunden Schonfrist gab es auch auf anderen meiner KH-Server, die diese Global-Sieve-Konfiguration gar nicht hatten.
Seit letzter Nacht tauchen wieder identische Mails im Queue auf, die wegen Spam von Googlemail nicht angenommen wurden.

Fazit: Schaden wird die Sieve Regel wohl nicht, aber das eigentliche Problem beseitigt sie nicht.

[Systemweb]

@Florian:

Code: Select all

/^X-Spamd-Bar:\s*\+{8,}/   DISCARD Forwarded spam blocked by system

wird nicht genügen. Der weitergeleitete Spam hat of nur 1 Plus, keine 8. Damit das zuverlässig gefiltert wird, muss also bereits 1 Plus genügen, aber nur sofern es sich um eine Weiterleitung handelt.
Ein Plus ist für Rspamd zwar bereits verdächtig, aber es wird bisher unbeanstandet weitergeleitet.

@Ralph:
RFC‑Pflichtadressen kann man problemlos über header_checks ausnehmen, indem man sie als erste Regel mit OK markiert. Dann werden sie von allen nachfolgenden Regeln nicht mehr betroffen.

Lösungsansatz:
Ich habe recherchiert und bin auf abuse.ch gestoßen – eine Sammlung aktueller Malware‑, Phishing‑ und Spamwellen.
In Kombination mit Postfix‑header_checks (für „X-Spamd-Bar“ + „X-Forwarded-For“) lässt sich Weiterleitungs‑Spam blockieren, ohne legitime Weiterleitungen zu beeinträchtigen.

Einbau header_checks:
Meine Datei /etc/postfix/header_checks habe ich erweitert. Das ist der aktuelle vollständige Inhalt:

Code: Select all

/^To:.*(postmaster|abuse|hostmaster|webmaster|security|tco|dsa)@/	OK
/^Content-Type:.*report-type=["']?delivery-status["']?/	WARN Bounce to probably forged sender
/^X-Failed-Recipients:/	DISCARD Bounce to probably forged sender
/^Subject:.*(failure.notice|(failure|mail).delivery|Delivery.(Status.Notification|failure)|(Undeliverable|undelivered|invalid)(:|.Mail|.message))/	WARN Looks like a bounce ($1), sender probably forged
/^X-Forwarded-For:/	HOLD forward_detected
/^X-Spamd-Bar:\s*\+/	DISCARD forwarded_spam
/^Authentication-Results:.*dmarc=fail/	DISCARD forwarded_dmarc_fail

Damit werden RFC-Adressen nicht beeinträchtigt. DMARC‑Fail (blockt Google immer!), Backscatter, und verdächtige Weiterleitungen werden gefiltert.

Aktualisieren:

Code: Select all

postmap /etc/postfix/header_checks
systemctl reload postfix

Einbau für abuse.ch:
Damit es updatefest ist, dürfen wir die multimap.conf (Keyhelp-verwaltet) nicht anrühren. Also legen wir einfach eine eigene conf-Datei an richtiger Stelle an:

Code: Select all

nano /etc/rspamd/local.d/abuse_ch.conf

mit folgendem Inhalt:

Code: Select all

URLHAUS {
  type = "url";
  map = "https://urlhaus.abuse.ch/downloads/text_online/";
  symbol = "URLHAUS_BAD_URL";
  description = "URLhaus malicious URL";
  score = 6.0;
}

THREATFOX_IP {
  type = "ip";
  map = "https://threatfox.abuse.ch/downloads/ipblocklist_recommended.txt";
  symbol = "THREATFOX_BAD_IP";
  description = "ThreatFox malicious IP";
  score = 5.0;
}

SSLBL {
  type = "hostname";
  map = "https://sslbl.abuse.ch/blacklist/sslipblacklist.txt";
  symbol = "SSLBL_BAD_SSL";
  description = "SSL Blacklist";
  score = 4.0;
}

Konfiguration testen und aktivieren:

Code: Select all

rspamadm configtest
systemctl reload rspamd

Ich habe diese Lösung jetzt testweise aktiv und werde wieder berichten.

[Florian]

Ich habs mit Absicht nicht so streng gemacht.

[Ralph]

Lösungsansatz:
Ich habe recherchiert und bin auf abuse.ch gestoßen – eine Sammlung aktueller Malware‑, Phishing‑ und Spamwellen.
In Kombination mit Postfix‑header_checks (für „X-Spamd-Bar“ + „X-Forwarded-For“) lässt sich Weiterleitungs‑Spam blockieren, ohne legitime Weiterleitungen zu beeinträchtigen.

Sieht schon ganz gut aus, bei den "failure.notice" diese sollten besser nicht durch header_checks beeinflusst werden, würde ich ganz rausnehmen ...
abuse.ch hatte ich früher auch genutzt, bis der Dienst irgendwann mal eingestellt wurde ... scheint aber wieder aktiv zu sein.
https://github.com/rspamd/rspamd/issues/2744
https://abuse.ch/

[Systemweb]

Ich habs mit Absicht nicht so streng gemacht.

Das nur 1 Plus viel zu streng wäre war auch mein Gedanke.
Mein treuer Diener meinte dann aber, dass Rspamd nicht so streng wie die Google-Filter ist. Wenn also hier bereits die Mail mit dem ersten Plus als verdächtig eingestuft wird ist es sehr sicher und die Gefahr, dass eine legitime Mail nicht weitergeleitet wird läge nahezu bei Null.

Zitat:
Ein einzelnes Plus bedeutet:

• ungewöhnlicher Inhalt

• schlechte Reputation

• Tracking‑Müll

• Spam‑ähnliche Struktur

• fragwürdige URLs

• fehlende oder schwache DKIM‑Signatur

• SPF‑Inkonsistenzen

• heuristische Treffer

Legitime Mails haben fast nie ein X-Spamd-Bar: +.
Hinzu kommt, dass diese Regel nur auf Weiterleitungen angewendet wird.

[Systemweb]

Wie angekündigt folgt mein Bericht.

Meine Mailqueue ist nun seit 4 Tagen sauber. Die header_checks in Kombination mit der abuse.ch-Spamregel sind wahrscheinlich das wirksame Mittel. Da aber 2 der 3 verwendeten Filter-Listen gar nicht erreichbar sind, habe ich es auf die einzige effektiv wirksame Regel gekürzt.

Code: Select all

nano /etc/rspamd/local.d/abuse_ch.conf

Vollständiger Inhalt:

Code: Select all

URLHAUS {
  type = "url";
  map = "https://urlhaus.abuse.ch/downloads/text_online/";
  symbol = "URLHAUS_BAD_URL";
  description = "URLhaus malicious URL";
  score = 6.0;
}

Ausführen:

Code: Select all

rspamadm configtest
systemctl reload rspamd

[Systemweb]

Die Weiterleitungen werden weiterhin erfolgreich gefiltert. Nun tauchte aber ein weiteres Phänomen auf:
Mehrere Mails landeten in der Queue, weil Gmail die Weiterleitung ablehnt. Betroffen ist ein User, der Mails von einem Gmail‑Konto auf ein lokales Konto weiterleitet und von dort aus wieder an mehrere Empfänger — u. a. erneut an ein Gmail‑Konto.

Die ARC‑Signaturen in diesen Mails stammen ausschließlich von Google.
Da der Forwarder (KeyHelp‑Server) keinen eigenen ARC‑Block hinzufügt, bleibt die ARC‑Chain unvollständig. Auf dem Rückweg zu Gmail stuft Google den Forwarder deshalb als untrusted ein und lehnt die Weiterleitung ab.

Darum habe ich folgende Lösung ergänzt, um ARC‑Signaturen korrekt zu aktivieren:
viewtopic.php?p=59186#p59186