Rspamd gegen Phishing und Markenmissbrauch härten

Mailserver

SPF, DKIM und DMARC sind wichtige Bestandteile einer sicheren E-Mail-Infrastruktur. Sie reichen jedoch nicht aus, um moderne Phishing-Mails zuverlässig zu erkennen.

In der Praxis werden zunehmend echte oder kompromittierte Mailkonten, regulär registrierte Domains und korrekt konfigurierte Versandserver verwendet. Eine Phishing-Mail kann deshalb gleichzeitig folgende Eigenschaften besitzen:

  • SPF: bestanden
  • DKIM: bestanden
  • DMARC: bestanden oder nicht vorhanden
  • Versand über authentifiziertes SMTP
  • formal korrekte MIME-Struktur
  • unauffällige oder sogar positive Absenderreputation

Die Nachricht ist damit technisch authentisch – allerdings nur in Bezug auf die missbrauchte Absenderdomain. Eine korrekt signierte Mail von truecare.co.in beweist beispielsweise lediglich, dass die Nachricht tatsächlich über eine für truecare.co.in autorisierte Infrastruktur versendet wurde. Sie beweist nicht, dass eine im Anzeigenamen genannte Volksbank der Absender ist.

Die Härtung muss deshalb mehrere Signale kombinieren:

  1. Erkennung bekannter Marken im Anzeigenamen
  2. Prüfung der tatsächlichen Absenderdomain
  3. Erkennung typischer Phishingformulierungen
  4. Erkennung verdächtiger Rollenbezeichnungen
  5. Kombination der Einzelsignale über Composite-Regeln
  6. Pflege lokaler Sperrlisten
  7. Korrektur fehlerhafter Bayes-Klassifizierungen
  8. regelmäßige Tests mit echten Beispielnachrichten

Rspamd ist für diesen Ansatz gut geeignet: Multimap-Regeln erzeugen einzelne Symbole aus gepflegten Listen, während Composite-Regeln daraus kontextabhängige Entscheidungen bilden. Maps können unabhängig von der eigentlichen Regelkonfiguration gepflegt und von Rspamd dynamisch aktualisiert werden.

1. Warum SPF, DKIM und DMARC nicht genügen

Bei mehreren untersuchten Phishing-Mails waren SPF und DKIM gültig. Teilweise bestand zusätzlich die DMARC-Prüfung.

Typische Beispiele waren:

From: "N26App" <support@novapro.ro>

From: "Consorbank IT-Koordination" <t.yanagawa@fine-net.biz>

From: "Volksbank SecureGO-Alarmdienst" <skthakur@truecare.co.in>

Die Angreifer fälschten dabei nicht zwingend die technische Absenderdomain. Stattdessen wurde eine fremde Marke im sichtbaren Anzeigenamen verwendet.

Rspamd erkannte die gültige technische Authentifizierung korrekt:

R_SPF_ALLOW
R_DKIM_ALLOW
DMARC_POLICY_ALLOW

Diese Symbole dürfen deshalb nicht als Nachweis für die inhaltliche Legitimität der Nachricht verstanden werden. Sie bestätigen lediglich die Authentizität der tatsächlich verwendeten Domain.

Eine wirksame Erkennung muss daher den sichtbaren Markennamen mit der tatsächlichen Absenderdomain in Beziehung setzen.

2. Zielstruktur der Konfiguration

Für die lokale Erweiterung werden folgende Dateien verwendet:

/etc/rspamd/local.d/multimap.conf
/etc/rspamd/local.d/composites.conf

/etc/rspamd/maps.d/brand_spoof.map
/etc/rspamd/maps.d/bank_phish_words.map
/etc/rspamd/maps.d/bank_it_display.map
/etc/rspamd/maps.d/legit_bank_domains.map
/etc/rspamd/maps.d/sender_domain_blacklist.map

Die Trennung hat einen praktischen Vorteil:

  • multimap.conf definiert, wie geprüft wird.
  • composites.conf definiert, wie Treffer kombiniert werden.
  • Die Dateien unter maps.d enthalten die veränderlichen Daten.
  • Neue Marken, Domains und Textmuster können ergänzt werden, ohne die eigentliche Regellogik umzubauen.

Rspamd empfiehlt Multimaps insbesondere für Whitelists, Blacklists und umfangreichere Listenprüfungen. Für Kombinationen bereits vorhandener Symbole sind Composites vorgesehen.

3. Multimap-Regeln

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

Diese Datei erzeugt die einzelnen Prüfsymbole.

BRAND_SPOOF_DISPLAY {
  type = "header";
  header = "From";
  filter = "email:display";
  map = "/etc/rspamd/maps.d/brand_spoof.map";
  regexp = true;
  score = 4.0;
  description = "Bekannte Marke im Anzeigenamen erkannt";
}

BANK_PHISH_WORDS_SUBJECT {
  type = "header";
  header = "Subject";
  map = "/etc/rspamd/maps.d/bank_phish_words.map";
  regexp = true;
  score = 3.0;
  description = "Phishingtypische Formulierung im Betreff";
}

BANK_PHISH_WORDS_BODY {
  type = "content";
  map = "/etc/rspamd/maps.d/bank_phish_words.map";
  regexp = true;
  score = 3.0;
  description = "Phishingtypische Formulierung im Nachrichteninhalt";
}

BANK_IT_DISPLAY {
  type = "header";
  header = "From";
  map = "/etc/rspamd/maps.d/bank_it_display.map";
  regexp = true;
  score = 1.5;
  description = "Verdächtige Support- oder Sicherheitsrolle im Anzeigenamen";
}

LEGIT_BANK_SENDER {
  type = "from";
  filter = "email:domain";
  map = "/etc/rspamd/maps.d/legit_bank_domains.map";
  score = -6.0;
  description = "Bekannte legitime Absenderdomain";
}

SENDER_DOMAIN_LOCAL_BLACKLIST {
  type = "from";
  filter = "email:domain";
  map = "/etc/rspamd/maps.d/sender_domain_blacklist.map";
  score = 8.0;
  description = "Lokal als schädlich eingestufte Absenderdomain";
}

Die Einzelsymbole sollen noch keine endgültige Entscheidung treffen. Ein Begriff wie „Systemwartung“ oder „Kundenportal“ kann auch in einer legitimen Nachricht vorkommen.

Die eigentliche Entscheidung erfolgt deshalb erst über die Kombination mehrerer Signale.

4. Marken im Anzeigenamen erkennen

Datei: /etc/rspamd/maps.d/brand_spoof.map

Diese Datei enthält bekannte Marken und Produktnamen, die häufig für Phishing missbraucht werden.

/N26/i
/ING/i
/DKB/i
/PayPal/i
/Sparkasse/i
/Volksbank/i
/VR[- ]?Bank/i
/Commerzbank/i
/Deutsche Bank/i
/Postbank/i
/Consorsbank/i
/Consorbank/i
/BNP Paribas/i
/SecureGO/i
/SecureGO plus/i
/VR Banking/i

Dabei sollten auch typische Schreibfehler und absichtliche Abwandlungen berücksichtigt werden.

Beispiel:

Consorsbank
Consorbank

Die Schreibweise ohne zweites „s“ kann ein absichtlicher Täuschungsversuch sein. Gleichzeitig muss jedoch bedacht werden, dass auch legitime Absendernamen Schreibfehler enthalten können. Der Treffer allein erhält deshalb noch keinen blockierenden Score.

5. Phishingtypische Formulierungen erkennen

Datei: /etc/rspamd/maps.d/bank_phish_words.map

Die Liste sollte möglichst spezifische Formulierungen enthalten.

/Adresse.*aktualisieren/i
/persönliche Referenznummer/i
/Unzustellbarkeit/i
/Ihre letzte Adresse/i
/Konto.*gesperrt/i
/Zugang.*eingeschränkt/i
/Zugang.*reaktivieren/i
/Banking.*reaktivieren/i
/Sicherheitsverfahren.*reaktivieren/i
/SecureGO.*reaktivieren/i
/reaktivieren.*Deadline/i
/Deadline.*nicht.*verpassen/i
/Alarmdienst/i
/ungewöhnliche Anmeldung/i
/Sicherheitsprüfung.*erforderlich/i
/innerhalb.*Werktage.*aktualisieren/i

Zu generische Einzelbegriffe sollten vermieden werden.

Folgende Begriffe haben sich als zu unspezifisch erwiesen:

Login
Kundenportal
verifizieren
Bestätigung erforderlich
TAN

Solche Wörter kommen regelmäßig in legitimen geschäftlichen Nachrichten vor. In einem Test löste eine normale Mail aus einer Microsoft-365-Umgebung die Inhaltsregel aus, obwohl SPF, DKIM, DMARC, ARC und Bayes eindeutig für eine legitime Nachricht sprachen.

Das war aufgrund der vorhandenen Schwellenwerte zwar noch kein unmittelbares Zustellproblem, erzeugte aber unnötiges Rauschen im Ergebnis.

Die Regel lautet daher:

Spezifische Formulierungen verwenden, nicht allgemeine Einzelwörter.

6. Verdächtige Support- und Sicherheitsrollen erkennen

Datei: /etc/rspamd/maps.d/bank_it_display.map

Angreifer verwenden häufig vermeintlich offizielle Funktionsbezeichnungen:

/\bIT[- ]?(Koordination|Support|Service|Sicherheit)\b/i
/\bKundenservice\b/i
/\bSicherheitsabteilung\b/i
/\bTechnischer Support\b/i
/\bSystemwartung\b/i
/\bAlarmdienst\b/i

Beispiele aus beobachteten Nachrichten:

Consorbank IT-Koordination
Volksbank SecureGO-Alarmdienst

Diese Regel erhält nur einen niedrigen Einzelwert von 1.5, weil Begriffe wie „IT-Support“ auch in legitimen Nachrichten vorkommen können.

Erst in Verbindung mit einer bekannten Marke und einer nicht passenden Absenderdomain entsteht ein starker Phishingindikator.

7. Legitime Domains hinterlegen

Datei: /etc/rspamd/maps.d/legit_bank_domains.map

In dieser Datei stehen verifizierte Domains legitimer Absender.

Beispiel:

n26.com
ing.de
dkb.de
paypal.com
sparkasse.de
commerzbank.de
deutsche-bank.de
postbank.de
consorsbank.de
vr.de
volksbank.de

Jede Domain muss vor Aufnahme anhand offizieller Hersteller- oder Unternehmensangaben geprüft werden.

Nicht aufgenommen werden sollten:

  • Domains, die nur ähnlich aussehen
  • Trackingdomains unbekannter Herkunft
  • Domains aus einer einzelnen erhaltenen Nachricht
  • Domains, die lediglich SPF und DKIM bestanden haben
  • vermeintliche Servicedomains ohne bestätigte Zugehörigkeit

Einschränkung einer globalen Allowlist

Die beschriebene Allowlist prüft nur, ob die Absenderdomain grundsätzlich zu einer bekannten Bank oder Marke gehört.

Sie prüft nicht, ob die konkrete Marke im Anzeigenamen zur konkreten Domain passt.

Dadurch wäre theoretisch folgender Fall möglich:

From: "Volksbank Sicherheit" <service@paypal.com>

Da paypal.com in der globalen Liste enthalten ist, könnte LEGIT_BANK_SENDER ausgelöst werden, obwohl der Anzeigename nicht zur Domain passt.

Für eine kleine private Umgebung ist die globale Liste zunächst praktikabel. Für eine strengere Produktionsumgebung sollte langfristig eine paarweise Zuordnung umgesetzt werden:

N26          -> n26.com
PayPal       -> paypal.com
Volksbank    -> vr.de, verifizierte regionale Domains
Consorsbank  -> consorsbank.de

Eine solche markenspezifische Zuordnung lässt sich bei wachsender Regelbasis sauberer über getrennte Symbole oder eine Lua-Regel umsetzen.

8. Bekannte schädliche Absenderdomains sperren

Datei: /etc/rspamd/maps.d/sender_domain_blacklist.map

Hier werden Domains eingetragen, von denen tatsächlich Spam oder Phishing empfangen wurde.

Beispiel:

novapro.ro
valicloud.net
fine-net.biz
truecare.co.in

Eine Aufnahme sollte nicht ausschließlich aufgrund des Länderkennzeichens, des Firmennamens oder einer einzelnen verdächtigen Eigenschaft erfolgen.

Vor der dauerhaften Sperrung muss geprüft werden:

  • Wurde die Domain mehrfach missbraucht?
  • Wird legitime Kommunikation von dieser Domain erwartet?
  • Handelt es sich möglicherweise nur um ein kompromittiertes einzelnes Konto?
  • Ist eine Sperrung der vollständigen Domain vertretbar?
  • Reicht alternativ eine Sperrung der konkreten Absenderadresse?

Eine Domain-Blacklist ist ein ergänzendes Instrument. Sie löst das grundlegende Problem des Markenmissbrauchs nicht, weil Angreifer ihre Domains regelmäßig wechseln.

9. Composite-Regeln als eigentliche Entscheidungslogik

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

Die Composite-Regeln kombinieren die zuvor erzeugten Einzelsymbole.

FAKE_BANK_BRAND {
  expression = "BRAND_SPOOF_DISPLAY & !LEGIT_BANK_SENDER";
  score = 8.0;
  description = "Bekannte Marke von nicht legitimierter Domain";
}

FAKE_BANK_IT_SENDER {
  expression = "BRAND_SPOOF_DISPLAY & !LEGIT_BANK_SENDER & BANK_IT_DISPLAY";
  score = 8.0;
  description = "Markenmissbrauch mit angeblicher IT- oder Sicherheitsfunktion";
}

FAKE_BANK_PHISHING {
  expression = "BRAND_SPOOF_DISPLAY & !LEGIT_BANK_SENDER & (BANK_PHISH_WORDS_SUBJECT | BANK_PHISH_WORDS_BODY)";
  score = 12.0;
  description = "Markenmissbrauch mit phishingtypischen Formulierungen";
}

KNOWN_BAD_SENDER_WITH_PHISH_WORDS {
  expression = "SENDER_DOMAIN_LOCAL_BLACKLIST & (BANK_PHISH_WORDS_SUBJECT | BANK_PHISH_WORDS_BODY)";
  score = 15.0;
  description = "Bekannte schädliche Domain mit Phishinginhalt";
}

Die wichtigste Regel ist:

FAKE_BANK_PHISHING {
  expression = "BRAND_SPOOF_DISPLAY & !LEGIT_BANK_SENDER & (BANK_PHISH_WORDS_SUBJECT | BANK_PHISH_WORDS_BODY)";
  score = 12.0;
}

Sie bedeutet:

  1. Im sichtbaren Absendernamen steht eine bekannte Marke.
  2. Die tatsächliche Absenderdomain ist nicht als legitime Markendomain hinterlegt.
  3. Im Betreff oder Nachrichtentext befindet sich mindestens eine phishingtypische Formulierung.

Erst wenn alle notwendigen Bedingungen erfüllt sind, wird der hohe Score vergeben.

Rspamd-Composites können die Gewichte der auslösenden Symbole standardmäßig ersetzen oder – abhängig von Präfixen beziehungsweise der gewählten Policy – zusätzlich bestehen lassen. Deshalb muss beim Test geprüft werden, ob der resultierende Gesamtwert der gewünschten Berechnung entspricht. Mit policy = "leave" können die ursprünglichen Symbole und ihre Gewichte ausdrücklich erhalten bleiben.

Soll der Composite-Score ausdrücklich zusätzlich zu den Einzelsymbolen gelten, kann beispielsweise ergänzt werden:

FAKE_BANK_PHISHING {
  expression = "BRAND_SPOOF_DISPLAY & !LEGIT_BANK_SENDER & (BANK_PHISH_WORDS_SUBJECT | BANK_PHISH_WORDS_BODY)";
  score = 12.0;
  policy = "leave";
}

Das sollte nur nach einem Test mit den tatsächlich eingesetzten Schwellenwerten aktiviert werden, da es zu deutlich höheren Gesamtwerten führt.

10. Bewertung anhand der vorhandenen Schwellenwerte

Im beschriebenen System gelten:

ab 10 Punkten: Betreff umschreiben
ab 15 Punkten: als Spam behandeln

Eine legitime geschäftliche Nachricht kann beispielsweise folgende Bewertung erhalten:

BAYES_HAM                  -4.0
ARC_ALLOW                  -1.0
DMARC_POLICY_ALLOW         -0.5
R_SPF_ALLOW                -0.2
MIME_GOOD                  -0.1
RCPT_COUNT_ONE             +0.5

Selbst ein einzelner falsch positiver Inhaltstreffer von +3 würde in diesem Fall noch keine Aktion auslösen.

Problematisch wird es erst, wenn mehrere positive Signale zusammenkommen. Genau deshalb werden hohe Scores nicht auf allgemeine Einzelbegriffe gelegt, sondern auf Composite-Regeln.

Rspamd bildet aus den Symbolgewichten einen Gesamtwert und empfiehlt anhand der konfigurierten Schwellenwerte eine Aktion. Die konkreten Schwellenwerte werden üblicherweise in local.d/actions.conf festgelegt.

11. Bayes-Fehlklassifizierungen korrigieren

Bei mehreren eindeutigen Phishing-Mails erschien:

BAYES_HAM(-4.00)[99.99%]

oder:

BAYES_HAM(-3.93)[99.79%]

Bayes arbeitete damit massiv gegen die übrigen Spamindikatoren.

Das bedeutet nicht zwingend, dass Bayes defekt ist. Der Klassifikator hatte wahrscheinlich ähnliche Nachrichten zuvor als Ham gelernt oder noch keine ausreichende Anzahl passender Spam-Beispiele erhalten.

Eine solche Mail muss ausdrücklich als Spam trainiert werden:

rspamc learn_spam < phishing.eml

Eine fälschlich als Spam erkannte legitime Mail kann entsprechend als Ham gelernt werden:

rspamc learn_ham < legitime-mail.eml

Rspamd stellt dafür eigene Lernendpunkte und die entsprechenden rspamc-Funktionen bereit. Für eine dauerhafte Rückmeldung aus Benutzeraktionen kann Dovecot beziehungsweise IMAPSieve so angebunden werden, dass das Verschieben in den Junk-Ordner learn_spam und das Zurückverschieben learn_ham auslöst.

Wichtig ist eine saubere Trainingshygiene:

  • Nur eindeutig bewertete Nachrichten trainieren.
  • Newsletter nicht pauschal als Spam lernen.
  • Erwünschte Werbemails und Phishing nicht vermischen.
  • Fehlerhafte Ham-Lernvorgänge zeitnah korrigieren.
  • Den Klassifikator nicht mit identischen Nachrichtenvarianten überfüttern.
  • Spam und Ham möglichst ausgewogen zuführen.

Redis ist für die statistischen Funktionen und das Bayes-Lernen ein zentraler Bestandteil des üblichen Rspamd-Setups.

12. RBL-, URL- und Reputationssignale berücksichtigen

In einer untersuchten Volksbank-Phishing-Mail erkannte Rspamd bereits:

RECEIVED_SPAMHAUS_SBL(3.00)
DMARC_NA(2.50)
MANY_INVISIBLE_PARTS(0.30)
SUBJECT_ENDS_SPACES(0.50)

Die Nachricht blieb trotzdem unterhalb der Spamgrenze, weil Bayes fast vier negative Punkte vergab.

DNSBL- und Reputationssignale sollten deshalb nicht isoliert betrachtet werden. Sie sind zusätzliche Bausteine für die Gesamtbewertung.

Sinnvolle Prüfbereiche sind:

  • Absender-IP-Reputation
  • URLs und Trackingdomains
  • Redirect-Ziele
  • Spamhaus- und vergleichbare DNSBL-Ergebnisse
  • Pyzor oder Fuzzy-Hashes
  • MIME-Anomalien
  • unsichtbare HTML-Bestandteile
  • ungewöhnliche Zeichen und Leerzeichen im Betreff
  • authentifizierter Versand über fremde oder kompromittierte Konten

Rspamd kombiniert standardmäßig eine Vielzahl solcher Prüfungen, darunter DNS-Blacklists, Fuzzy-Prüfungen, Inhaltsanalyse, Authentifizierungsverfahren und statistische Klassifikatoren.

13. Warum Greylisting allein nicht genügt

Greylisting kann einfache Spam-Bots und schlecht konfigurierte Versandsoftware ausbremsen. Gegen die hier untersuchten Kampagnen ist die Wirkung jedoch begrenzt.

Die Nachrichten wurden über reguläre Plattformen versendet, unter anderem:

  • authentifizierte SMTP-Konten
  • gehostete Mailplattformen
  • korrekt arbeitende Postfix- oder Exchange-Systeme
  • reguläre TLS-Verbindungen

Solche Systeme führen Zustellversuche normalerweise korrekt erneut aus. Greylisting bleibt als zusätzliche Schutzschicht sinnvoll, ist aber kein Ersatz für Marken- und Inhaltsprüfung.

14. Konfiguration prüfen und laden

Nach Änderungen an den Konfigurationsdateien:

rspamadm configtest

Nur bei erfolgreichem Test sollte die Konfiguration geladen werden:

systemctl reload rspamd

Änderungen an reinen Map-Dateien können von Rspamd dynamisch erkannt werden. Ein vollständiger Neustart ist dafür normalerweise nicht erforderlich. Die Hauptkonfiguration sollte trotzdem nach jeder strukturellen Änderung getestet werden. Rspamd besitzt eigene Überwachungsintervalle für Maps und unterstützt deren Aktualisierung ohne vollständigen Dienstneustart.

15. Nachrichten reproduzierbar testen

Eine gespeicherte EML-Datei kann mit rspamc geprüft werden:

rspamc < phishing.eml

Bei einer gefälschten Volksbank-Mail sollte das Ergebnis mindestens folgende Symbole enthalten:

BRAND_SPOOF_DISPLAY
BANK_PHISH_WORDS_SUBJECT
FAKE_BANK_PHISHING

Bei einer Mail mit angeblicher IT- oder Sicherheitsfunktion zusätzlich:

BANK_IT_DISPLAY
FAKE_BANK_IT_SENDER

Bei einer legitimen Geschäfts- oder Microsoft-365-Mail sollten diese Symbole fehlen:

BRAND_SPOOF_DISPLAY
FAKE_BANK_PHISHING
FAKE_BANK_IT_SENDER

Nach jeder Änderung sollten mindestens folgende Testfälle geprüft werden:

Test 1: legitime geschäftliche Mail

Erwartung:

  • SPF, DKIM und DMARC bestehen
  • kein Brand-Spoof-Treffer
  • kein Phishing-Composite
  • Score deutlich unter 10

Test 2: echte Marke mit fremder Domain

Beispiel:

From: "Volksbank Sicherheit" <test@example.net>

Erwartung:

BRAND_SPOOF_DISPLAY

Kein LEGIT_BANK_SENDER.

Test 3: Marke, fremde Domain und Phishingtext

Beispiel:

From: "Volksbank Sicherheit" <test@example.net>
Subject: SecureGO reaktivieren – Deadline nicht verpassen

Erwartung:

BRAND_SPOOF_DISPLAY
BANK_PHISH_WORDS_SUBJECT
FAKE_BANK_PHISHING

Test 4: echte Markendomain

Beispiel nur mit einer zuvor verifizierten Domain.

Erwartung:

BRAND_SPOOF_DISPLAY
LEGIT_BANK_SENDER

FAKE_BANK_PHISHING darf nicht auslösen.

Test 5: Supportbegriff ohne Marke

Beispiel:

From: "IT-Support" <support@legitime-firma.example>

Erwartung:

BANK_IT_DISPLAY

Aber kein:

FAKE_BANK_IT_SENDER

16. Dateirechte

Für die Map-Dateien sind in der Regel folgende Rechte ausreichend:

-rw-r--r--

Numerisch:

644

Bedeutung:

rw-   Eigentümer darf lesen und schreiben
r--   Gruppe darf lesen
r--   Andere dürfen lesen

Beispiel:

chmod 644 /etc/rspamd/maps.d/brand_spoof.map
chmod 644 /etc/rspamd/maps.d/bank_phish_words.map
chmod 644 /etc/rspamd/maps.d/bank_it_display.map
chmod 644 /etc/rspamd/maps.d/legit_bank_domains.map
chmod 644 /etc/rspamd/maps.d/sender_domain_blacklist.map

Der Eigentümer sollte üblicherweise root sein:

chown root:root /etc/rspamd/maps.d/*.map

Entscheidend ist, dass der Rspamd-Prozess die Dateien lesen kann und unprivilegierte Benutzer sie nicht verändern dürfen.

17. Pflegeprozess

Eine wirksame lokale Regelbasis benötigt einen kontrollierten Pflegeprozess.

Bei jeder neuen verdächtigen Nachricht sollten folgende Punkte geprüft werden:

  1. Welcher Anzeigename wurde verwendet?
  2. Welche Marke wird imitiert?
  3. Welche tatsächliche From-Domain wurde verwendet?
  4. Stimmen Envelope-From und MIME-From überein?
  5. Welche SPF-, DKIM- und DMARC-Ergebnisse liegen vor?
  6. Wurde SMTP AUTH verwendet?
  7. Welche Received-IPs und Relay-Systeme sind enthalten?
  8. Welche Phishingformulierungen wurden verwendet?
  9. Welche URLs enthält die Nachricht?
  10. Welche Rspamd-Symbole haben ausgelöst?
  11. Hat Bayes fälschlich Ham erkannt?
  12. Fehlt eine Marke oder ein Textmuster in den lokalen Maps?

Danach wird entschieden:

  • Marke ergänzen
  • spezifische Textkombination ergänzen
  • Domain lokal sperren
  • Nachricht als Spam lernen
  • bestehende Regel korrigieren
  • keine Änderung, wenn bereits ausreichend erkannt

Nicht jede neue Mail sollte unmittelbar eine neue Regel erzeugen. Zu viele hochspezifische Regeln erhöhen den Pflegeaufwand und können langfristig zu False Positives führen.

18. Typische Fehler vermeiden

Zu allgemeine Begriffe

Schlecht:

/Login/i
/Portal/i
/TAN/i
/Bestätigung/i

Besser:

/Konto.*gesperrt/i
/SecureGO.*reaktivieren/i
/Adresse.*innerhalb.*Werktage.*aktualisieren/i

Einzelne Regeln zu hoch bewerten

Ein allgemeiner Supportbegriff sollte keine zehn Punkte erhalten. Hohe Werte gehören auf Kombinationen mehrerer unabhängiger Signale.

SPF und DKIM überbewerten

Ein DKIM-Pass bestätigt die verwendete Domain, nicht die im Anzeigenamen genannte Marke.

Globale Allowlist als vollständige Markenprüfung behandeln

Eine globale Liste legitimer Domains verhindert keine markenübergreifende Täuschung. Für höhere Sicherheitsanforderungen ist eine paarweise Marken-Domain-Prüfung erforderlich.

Bayes-Fehlklassifizierungen ignorieren

Eine eindeutige Phishing-Mail mit BAYES_HAM 99,99 % muss als Spam nachtrainiert werden.

Nur den sichtbaren Absender prüfen

Zusätzlich müssen Envelope-From, Return-Path, Received-Kette, DKIM-Domain, SPF-Domain und URLs betrachtet werden.

Ganze Domains vorschnell sperren

Ein kompromittiertes Konto bedeutet nicht automatisch, dass jede Nachricht der vollständigen Domain schädlich ist.

19. Weiterführende Härtung

Der beschriebene Aufbau verbessert die Erkennung deutlich. Für eine weitergehende Härtung bieten sich folgende Ausbaustufen an:

Markenspezifische Domainzuordnung

Statt einer globalen Allowlist wird je Marke definiert, welche Domains zulässig sind.

Weitere Markengruppen

Neben Banken können ergänzt werden:

  • Microsoft und Microsoft 365
  • DHL, UPS, DPD und Hermes
  • Amazon
  • Telekommunikationsanbieter
  • Energieversorger
  • Versicherungen
  • Behörden
  • Zahlungsdienste
  • interne Unternehmensmarken

Automatisiertes Benutzerfeedback

Dovecot IMAPSieve kann das Verschieben in den Spamordner mit rspamc learn_spam verbinden und das Zurückholen legitimer Nachrichten mit rspamc learn_ham.

Force Actions für eindeutige Treffer

Für besonders eindeutige Symbolkombinationen kann Rspamd über force_actions.conf unabhängig vom Gesamtscore eine Aktion erzwingen. Dies sollte nur für sehr präzise Regeln eingesetzt werden, da ein Fehler direkt zu einer erzwungenen Ablehnung oder Spamaktion führen kann.

Neural- und statistische Modelle überwachen

Bayes und neuronale Klassifikatoren sollten nicht blind übernommen werden. Ihre Treffer müssen regelmäßig mit realen Nachrichten verglichen und bei Fehlklassifizierungen korrigiert werden. Rspamd unterstützt neben Bayes auch neuronale Klassifikatoren und weitere statistische Verfahren.

Fazit

Moderne Phishing-Mails sind häufig technisch korrekt authentifiziert. SPF, DKIM und DMARC bleiben unverzichtbar, können aber keinen Missbrauch fremder Marken im Anzeigenamen verhindern.

Die wirksamste lokale Härtung besteht deshalb aus einer kontextbezogenen Bewertung:

Marke im Anzeigenamen
+
nicht passende Absenderdomain
+
phishingtypische Formulierung
=
hohe Phishingwahrscheinlichkeit

Rspamd-Multimaps liefern dafür die Einzelsignale. Composite-Regeln verbinden sie zu einer belastbaren Entscheidung.

Der entscheidende Grundsatz lautet:

Nicht ein einzelnes Wort oder ein einzelnes Authentifizierungsergebnis entscheidet, sondern die Kombination voneinander unabhängiger Merkmale.

Mit gepflegten Markenlisten, spezifischen Textmustern, kontrollierten Domainlisten, sauberem Bayes-Training und reproduzierbaren Tests lässt sich die Erkennungsqualität deutlich erhöhen, ohne legitime Geschäftsmails unnötig zu blockieren.

Tags: , , , , , , , , , , , , ,