rspamd ...aus der Perspektive eines Hobbyadmins (2019 Edition)

Traditionell besteht ein gängiges Setup eines Standalone-Mailservers aus einem Mail Transfer Agent wie Postfix, einem Mailfilter wie amavisd-new samt Spamfilter SpamAssassin und einen Virenscanner wie clamav sowie einem IMAP-Server wie Dovecot.

Rspamd ist eine moderne Alternative zu amavisd-new und SpamAssassin, die insbesondere für Admins, die eher nebenher einem kleinen Mailserver für die Familie oder kleine Büros betreiben, interessant ist. Es wurde ja schon mehrfach auf den Chemnitzer Linux-Tagen erwähnt. Dieser Talk stellt Rspamd speziell aus der Perspektive des Hobbyadmins vor und beschreibt basierend auf aktuellen Versionen die Integration in ein Postfix-Setup, wie es der Vortragende für seine eigenen Domains verwendet.

Transcript

1. rspamd ...aus der Perspektive eines Hobbyadmins Chemnitzer Linuxtage 16. März 2019 Pieter Hollants 2019 Edition
2. I. Einführung
3. Pieter wer? Entwickler (vorallem Python) im Rhein-Main-Gebiet, aber auch... ➔ 3J Support-Front (zu Netware/Win95-Zeiten) ➔ 9J (Senior) Werkstudent im SUSE Consulting ➔ 4J Linux Systems Engineer bei der Deutschen Flugsicherung (u.a. Automatisierte Installationen hoch-verfügbarer Systeme, Hardware Standardisierung) ...und Freelancer seit über 16J (Dev & Admin)
4. “E-Mail? Nimmt man doch fertig von der Stange”
5. E-Mail = Gmail? https://money.cnn.com/2014/04/01/technology/gmail/index.html
6. Eigener Server = doofe Idee? https://www.geekwire.com/2015/ why-you-shouldnt-try-to-host-your-own-email/ https://www.digitalocean.com/community/tutorials/why-you-may-not-want-to-run-your-own-mail-server https://nilead.com/article/5-reasons-you-should-not-host-your-own-email
7. Gründe für eigenen Server Private Daten bleiben privat ➔ keine automatisierten Auswertungen (Werbung...) ➔ aber: nutzt wenig, wenn andere Seite bei GMail & co. Volle Kontrolle übers Mailsystem ➔ unendlich Speicherplatz, E-Mail-Adressen, Aliase... ➔ Spamfilterung, Virenscans, E-Mail-Sicherheit Unabhängigkeit von anderen Anbietern ➔ Tarifänderungen, komplette Diensteinstellung ➔ Kostenfaktoren nach https://thomas-leister.de/warum-eigener-mailserver/
8. Gründe gegen eigenen Server Es ist Arbeit! ➔ Komplexes System mit vielen Komponenten ➔ Einmal manuell eingerichtet = in zwei Jahren vergessen ➔ Laufender administrativer Aufwand (vermisste Mails, Konfigurationstuning, Zertifikate...) Rechtlicher Rahmen ➔ eigentlich nur für Soloselbständige empfehlenswert, maximal Familien ➔ eigene kleine Firma besser bei unabhängigen Mailprovidern aufgehoben
9. Gründe gegen eigenen Server Es ist Arbeit! ➔ Komplexes System mit vielen Komponenten ➔ Einmal manuell eingerichtet = in zwei Jahren vergessen ➔ Laufender administrativer Aufwand (vermisste Mails, Konfigurationstuning, Zertifikate...) Rechtlicher Rahmen ➔ eigentlich nur für Soloselbständige empfehlenswert, maximal Familien ➔ eigene kleine Firma besser bei unabhängigen Mailprovidern aufgehoben WikiMedia Commons / Qwertyxp2000 / CC-BY-SA
10. Mailserveranatomie (1/2)
11. Mailserveranatomie (2/2) ➔ Erhöhte Komplexität durch Spam, Viren & co., hier am Beispiel von Postfix ➔ Traditionell amavisd-new als Interface zwischen MTA und Content scanner ➔ SpamAssassin: Mail filter, in Perl geschrieben, automatisiertes Update der Regeln per Cronjob ➔ Virenscanner wie clamav, kommerzielle Vertreter ➔ Zwei smtpd-Instanzen benötigt: eine mit amavisd-new als Content Filter, eine ohne
12. II. Meet rspamd 9
13. Hintergrund ➔ Geschrieben durch Vsevolod Stakhov ➔ Neuentwicklung aus Betroffenheit heraus: ➔ Administrierte E-Mail Systeme bei rambler.ru ➔ Vorhandene Lösungen erzeugten zuviel CPU-Last ➔ Releases: 0.2.7 (2009) → 1.0 (2015) → 1.9.0 (12.03.2019) ➔ Ziel: Performance für “Mass mail processing” ➔ Apache 2.0-Lizenz https://de.slideshare.net/VsevolodStakhov/rspamdfosdem-57772063
14. Grundprinzip ➔ MTA reicht empfangene Mails an rspamd weiter ➔ z.B. Milter-Schnittstelle ➔ Module werten Mails anhand von Regeln/Tests aus ➔ Jeder Test wird durch Symbol (Name) identifiziert ➔ Konfiguration weist Symbolen Scores zu ➔ Gesamtscore = ∑ Scores zutreffender Tests ➔ Abhängig von Gesamtscore Empfehlung an MTA ➔ Pass ➔ Reject ➔ Add header
15. Features ➔ Content scanning ➔ Reguläre Ausdrücke ➔ Fuzzy hashes ➔ Policy checks ➔ SPF, DKIM, DMARC, ARC ➔ Realtime blacklists (RBLs): DNS-based IP checks, URLs ➔ Phishing checks ➔ IP reputation, Rate limits ➔ Greylisting ➔ Statistical tools ➔ Bayes classifier ➔ Neural networks ➔ Integriertes Webinterface inkl. Statistiken
23. Architektur ➔ Kern in C geschrieben, Erweiterungsmodule in C/Lua ➔ Eventgetriebenes Prozessmodell ➔ Paralleles Abarbeiten von Regeln ➔ Asynchrone Netzwerkrequests ➔ Unterschiedliche Typen von Regeln ➔ Pre rules (z.B. Greylisting) ➔ Normal rules (Scoring positiv/negativ) ➔ Post rules (z.B. Composite rules) ➔ Verschiedene Prozesse ➔ Hauptprozess (Config, Logs, Prozessmanagement) ➔ Scannerprozesse (Scannen Mails) ➔ Workerprozesse (Controller (API), Service (z.B. Lua host)) ➔ Viele Module nutzen Redis als Cache
24. III. Konfigurationstheorie 18
25. Konfigurierbares ➔ Zu aktivierende Module ➔ Eingebaute Module (C) vs. externe Lua-Module ➔ Modul-spezifische Konfigurationsoptionen ➔ z.B. antivirus: welche Virenscanner sollen verwendet werden ➔ Scores (Kommazahlen) ➔ z.B. Default config: FORGED_SENDER (Absender in Envelope und From: unterschiedlich) Gewicht 0,30 ➔ Aktionen bei Gesamtscore X ➔ z.B. Default config: Greylisting ab Gesamtscore 4,0 ➔ Worker-Konfiguration ➔ z.B. Listen-Sockets, Skalierung ➔ Allgemeine Optionen ➔ z.B. Timeouts
26. Konfigurierbares ➔ Zu aktivierende Module ➔ Eingebaute Module (C) vs. externe Lua-Module ➔ Modul-spezifische Konfigurationsoptionen ➔ z.B. antivirus: welche Virenscanner sollen verwendet werden ➔ Scores (Kommazahlen) ➔ z.B. Default config: FORGED_SENDER (Absender in Envelope und From: unterschiedlich) Gewicht 0,30 ➔ Aktionen bei Gesamtscore X ➔ z.B. Default config: Greylisting ab Gesamtscore 4,0 ➔ Worker-Konfiguration ➔ z.B. Listen-Sockets, Skalierung ➔ Allgemeine Optionen ➔ z.B. Timeouts Austarieren dieser Stellschrauben entscheidet über Erfolg oder Misserfolg des gesamten Spamfilters!
27. https://rspamd.com/doc/modules/ (Aug 2018)
28. Modulkategorisierung 1. Module, die aufgrund Absender/Empfänger Domain/IP agieren 2. Module, die Nachrichtensignaturen überprüfen (gegen DNS- Einträge) oder selbst hinzufügen 3. Module, die Nachrichteninhalte gegen (DNS) Blacklisten prüfen 4. Module, die Nachrichten ohne DNS-Interaktion analysieren 5. Module, die Metadaten wie z.B. Absenderdomains an externe Datenbanken weiterleiten 6. Module, die statt Tests Aktionen implementieren 7. Sonstige Module Im Folgenden: Unterstrichen = eingebaute C Module; Rest = Lua
29. Module (1/7) Module, die aufgrund Absender/Empfänger Domain/IP agieren: ➔ asn: Findet Autonomous System Number (ASN), Ländercode und Subnet von Absender IPs heraus ➔ ip_score: Trackt die Anzahl empfangener Nachrichten von einer IP, einem Subnet, einem ASN oder einem Land ➔ mx_check: Prüft, ob die Senderdomain im Envelope wenigstens einen erreichbaren MX hat (Standardconfig: aus) ➔ ratelimit: Begrenzt Mails von/für bestimmte Absender/Empfänger mittels Leaky Bucket-Methode ➔ rbl: Prüft Absender-IP gegen RBLs, Reverse DNS-Einträge, “Received:” Adressen und HELO/EHLO Parameter ➔ spf: Prüft die Sender Policy Framework (SPF) Policy der Absenderdomain
30. Module (1/7) Module, die aufgrund Absender/Empfänger Domain/IP agieren: ➔ asn: Findet Autonomous System Number (ASN), Ländercode und Subnet von Absender IPs heraus ➔ ip_score: Trackt die Anzahl empfangener Nachrichten von einer IP, einem Subnet, einem ASN oder einem Land ➔ mx_check: Prüft, ob die Senderdomain im Envelope wenigstens einen erreichbaren MX hat (Standardconfig: aus) ➔ ratelimit: Begrenzt Mails von/für bestimmte Absender/Empfänger mittels Leaky Bucket-Methode ➔ rbl: Prüft Absender-IP gegen RBLs, Reverse DNS-Einträge, “Received:” Adressen und HELO/EHLO Parameter ➔ spf: Prüft die Sender Policy Framework (SPF) Policy der Absenderdomain .ru/.cn = Punktabzug? Komplex Einsatzszenario? Aber Vorsicht...
31. https://digitalcourage.de/blog/2018/copyright-kampagnenseite-blocked
32. Module (2/7) Module, die Nachrichtensignaturen überprüfen (gegen DNS- Einträge) oder selbst hinzufügen: ➔ arc: Prüft Authenticated Received Chain (ARC) Signaturen, die durch Mailrelays hinzugefügt wurden (ergänzt DKIM) ➔ dkim: Prüft/Ergänzt Domain Keys Identified Mail (DKIM) Signaturen (= ob Mail wirklich von der behaupteten Domain kommt) ➔ dmarc: Konsultiert DMARC TXT DNS-Einträge zum Verhalten bei fehlgeschlagenen DKIM/SPF-Checks ➔ mid: Unterdrückt negative Folgen fehlender “Message-Id” header für DKIM-signierter Mails bestimmter Domains (als Workaround für falsch konfigurierte Domains) ➔ whitelist: Erhöht/Reduziert Scores für Mails vertrauenswürdiger Quellen
33. Module (2/7) Module, die Nachrichtensignaturen überprüfen (gegen DNS- Einträge) oder selbst hinzufügen: ➔ arc: Prüft Authenticated Received Chain (ARC) Signaturen, die durch Mailrelays hinzugefügt wurden (ergänzt DKIM) ➔ dkim: Prüft/Ergänzt Domain Keys Identified Mail (DKIM) Signaturen (= ob Mail wirklich von der behaupteten Domain kommt) ➔ dmarc: Konsultiert DMARC TXT DNS-Einträge zum Verhalten bei fehlgeschlagenen DKIM/SPF-Checks ➔ mid: Unterdrückt negative Folgen fehlender “Message-Id” header für DKIM-signierter Mails bestimmter Domains (als Workaround für falsch konfigurierte Domains) ➔ whitelist: Erhöht/Reduziert Scores für Mails vertrauenswürdiger Quellen Kenn bislang keine... Brauche ich bislang nicht... Kontrolle abgeben?
34. Module (3/7) Module, die Nachrichteninhalte gegen (DNS) Blacklisten prüfen: ➔ dcc: Konsultiert Distributed Checksum Clearinghouses (DCC), um festzustellen, ob Mail Spam ist ➔ emails: Extrahiert E-Mail Adressen und vergleicht sie gegen konfigurierte Listen oder DNS Blacklists ➔ fuzzy_check: Versucht Fuzzy Matching von Zeichenketten, um verschiedene Schreibweisen von typischen Formulierungen zu erwischen ➔ phishing: Versucht mittels OpenPhish-Dienst Phishing URLs in HTML-Mails zu finden ➔ surbl: Extrahiert URLs und Domains dieser URLs und prüft diese gegen Blacklists wie surbl.org, uribl.com, Spamhaus etc. (teils kommerziell) ➔ url_reputation: Experimentelles Modul, um URLs zu extrahieren und ihren Domains Reputationen zuzuweisen
35. Module (3/7) Module, die Nachrichteninhalte gegen (DNS) Blacklisten prüfen: ➔ dcc: Konsultiert Distributed Checksum Clearinghouses (DCC), um festzustellen, ob Mail Spam ist ➔ emails: Extrahiert E-Mail Adressen und vergleicht sie gegen konfigurierte Listen oder DNS Blacklists ➔ fuzzy_check: Versucht Fuzzy Matching von Zeichenketten, um verschiedene Schreibweisen von typischen Formulierungen zu erwischen ➔ phishing: Versucht mittels OpenPhish-Dienst Phishing URLs in HTML-Mails zu finden ➔ surbl: Extrahiert URLs und Domains dieser URLs und prüft diese gegen Blacklists wie surbl.org, uribl.com, Spamhaus etc. (teils kommerziell) ➔ url_reputation: Experimentelles Modul, um URLs zu extrahieren und ihren Domains Reputationen zuzuweisen Lizenzrestriktion & externer Daemon Gibt nützlichere Attribute in Mails Machtvoll, komplex, extra Worker, extra Learning, versuche es weiterhin ohne... Aus gutem Grund experimentell?
36. Module (4/7) Module, die Nachrichten ohne DNS-Interaktion analysieren: ➔ antivirus: Prüft Mails mittels externer Virenscanner wie clamav ➔ chartable: Bestraft auffällig viele Zeichencodierungswechsel (z.B. zwischen Latin und Chinese) ➔ maillist: Neutralisiert Regeln bei Nachrichten von Mailinglisten ➔ mime_types: Prüft MIME types und Inhalte von Archiven ➔ neural_networks: Experimentelles Modul, um neuronale Netze zur Mailklassifikation einzusetzen ➔ once_received: Tests für Mails mit nur einem Received Header ➔ regexp: Tests mit regulären Ausdrücken ➔ replies: Trackt Antworten auf eigenes Mails mittels Message-Id Header ➔ reputation: Experimentell, bislang undokumentiert ➔ trie: “Blitzschnelles” Durchsuchen nach Strings mit Aho-Corasick- Algorithmus
37. Module (4/7) Module, die Nachrichten ohne DNS-Interaktion analysieren: ➔ antivirus: Prüft Mails mittels externer Virenscanner wie clamav ➔ chartable: Bestraft auffällig viele Zeichencodierungswechsel (z.B. zwischen Latin und Chinese) ➔ maillist: Neutralisiert Regeln bei Nachrichten von Mailinglisten ➔ mime_types: Prüft MIME types und Inhalte von Archiven ➔ neural_networks: Experimentelles Modul, um neuronale Netze zur Mailklassifikation einzusetzen ➔ once_received: Tests für Mails mit nur einem Received Header ➔ regexp: Tests mit regulären Ausdrücken ➔ replies: Trackt Antworten auf eigenes Mails mittels Message-Id Header ➔ reputation: Experimentell, bislang undokumentiert ➔ trie: “Blitzschnelles” Durchsuchen nach Strings mit Aho-Corasick- Algorithmus Lange verwendet, Nutzen vs. Aufwand bei kleinem MX “Heißer Scheiß” aber komplex Default expiry 24 hours zu kurz Experimentell, undokumentiert Was ist nicht versteh, brauch ich wohl nicht...
38. Module (5/7) Module, die Metadaten wie z.B. Absenderdomains an externe Datenbanken weiterleiten: ➔ clickhouse: Leitet Daten an eine clickhouse.yandex Instanz weiter ➔ elastic: Leitet Daten an eine Elasticsearch-Instanz weiter ➔ external_services: z.B. ICAP (Internet Content Adaption Protocol) → ClamAV/Sophos/Kaspersky ➔ history_redis: Speichert Historie in einer Redis-Instanz ➔ metadata_exporter: Exportiert Metadaten via Redis Publish/Subscribe-Channels, HTTP POST URLs und Mails ➔ metric_exporter: Exportiert Metriken an ein externes Monitoring-System (derzeit nur Graphite)
39. Module (5/7) Module, die Metadaten wie z.B. Absenderdomains an externe Datenbanken weiterleiten: ➔ clickhouse: Leitet Daten an eine clickhouse.yandex Instanz weiter ➔ elastic: Leitet Daten an eine Elasticsearch-Instanz weiter ➔ external_services: z.B. ICAP (Internet Content Adaption Protocol) → ClamAV/Sophos/Kaspersky ➔ history_redis: Speichert Historie in einer Redis-Instanz ➔ metadata_exporter: Exportiert Metadaten via Redis Publish/Subscribe-Channels, HTTP POST URLs und Mails ➔ metric_exporter: Exportiert Metriken an ein externes Monitoring-System (derzeit nur Graphite) Brauche ich alle nicht :)
40. Module (6/7) Module, die statt Tests Aktionen implementieren: ➔ dkim_signing: Alternative zu dkims sign_condition (nicht wirklich eine Aktion da unabhängig von Score) ➔ force_actions: Erzwingt unabhängig von Message-Score eine Aktion, wenn bestimmte Symbole gefunden werden ➔ greylisting: Implementiert Greylisting (Temporäres Abweisen mit dem Ziel eines erneuten Zustellversuchs) ➔ milter_headers: Fügt Message Header wie x-spamd-bar und authentication-results hinzu
41. Module (6/7) Module, die statt Tests Aktionen implementieren: ➔ dkim_signing: Alternative zu dkims sign_condition (nicht wirklich eine Aktion da unabhängig von Score) ➔ force_actions: Erzwingt unabhängig von Message-Score eine Aktion, wenn bestimmte Symbole gefunden werden ➔ greylisting: Implementiert Greylisting (Temporäres Abweisen mit dem Ziel eines erneuten Zustellversuchs) ➔ milter_headers: Fügt Message Header wie x-spamd-bar und authentication-results hinzu Einsatzszenario?
42. Module (7/7) Sonstige Module: ➔ bayes_expiry: Entfernt veraltete Bayes Token ➔ multimap: Erlaubt es, Maps (z.B. Blacklists) dynamisch von URLs oder Dateien zu laden ➔ rspamd_update: Aktualisiert rspamd Regeln, Scores und Aktionen ohne rspamd-Neustart bzw. Upgrade ➔ spamassassin: Importiert SpamAssassin-Regeln ➔ url_redirector: Hilfsmodul für surbl, um Redirects in URL zu verfolgen ➔ url_tags: Experimentes Modul, dass “URL tags” in Redis cachet
43. Module (7/7) Sonstige Module: ➔ bayes_expiry: Entfernt veraltete Bayes Token ➔ multimap: Erlaubt es, Maps (z.B. Blacklists) dynamisch von URLs oder Dateien zu laden ➔ rspamd_update: Aktualisiert rspamd Regeln, Scores und Aktionen ohne rspamd-Neustart bzw. Upgrade ➔ spamassassin: Importiert SpamAssassin-Regeln ➔ url_redirector: Hilfsmodul für surbl, um Redirects in URL zu verfolgen ➔ url_tags: Experimentelles Modul, dass “URL tags” in Redis cachet Brauchen wir das? Fange bei Null an… Experimentell, kaum dokumentiert
44. Scores Nur ein kleiner Ausschnitt… *=One-shot symbol https://www.0xf8.org/2018/05/an-alternative-introduction-to-rspamd-configuration-scores/
45. IV. rspamd in der Praxis 39
46. Installation ➔ CentOS 6/7, Fedora 21-25: ➔ yum Repos unter https://rspamd.com/rpm-stable/ ➔ CentOS-Pakete erfordern EPEL ➔ Debian/Ubuntu: ➔ apt Repos unter http://rspamd.com/apt-stable ➔ Debian-eigene Pakete “terribly outdated” ➔ openSUSE/SLES: ➔ zypper Repo unter https://download.opensuse.org/repositories/server:mail/ ➔ FreeBSD, OpenBSD: ➔ Ports collection ➔ Redis gleich mitinstallieren!
47. Postfix/MTA-Integration Self-scan mode (small setups) Proxy mode (large setups)
48. Postfix/MTA-Integration Self-scan mode (small setups) Proxy mode (large setups)
49. “Zeig endlich Config!!?” Christine Owens; CC0; https://www.publicdomainpictures.net/en/view-image.php?image=115842 “rspamadm configwizard”? Nee...
50. https://www.0xf8.org/2019/03/an-updated-configuration-file-structure-diagram-for-rspamd-1-9-0/ Toddler: Flickr Henry Borrows; CC-BY-SA 2.0; https://www.flickr.com/photos/foilman/5906443080
51. /etc/rspamd ➔ common.conf, groups.conf und modules.conf: (fast) nur Includes ➔ actions.conf: welche Aktionen bei welchen Gesamtscores ➔ composites.conf: Kombinationen von Symbolen → neue Symbole ➔ statistic.conf: Derzeit nur Bayes classifier (eingebaut, kein Modul) ➔ settings.conf: Individualisierungen z.B. für Nachrichten bestimmter Absender ➔ options.inc: Verschiedenes wie z.B. DNS timeouts, aber auch eingebaute Module via filters= Direktive ➔ cgp.inc: CommuniGate Pro Groupware-Spezifika ➔ logging.inc: Logging setup ➔ worker-*.inc: Worker setup, z.B. IP-Adressen
52. /etc/rspamd/modules.d ➔ Modul-spezifische Konfigurationsdateien ➔ Inkludiert aus top-level modules.conf ➔ Leider nur für Lua-Module Ein- und Ausschalten jeweils via enabled = true Zeile ➔ Teilweise Einbindung weiterer *.inc Dateien, die leider wieder unter /etc/rspamd liegen... ➔ Die meisten Module sind defaultmäßig aktiv ➔ Änderungen hieran schreien nach einem sed -i Job oder besser: Config management ➔ redis.conf: Allgemeine Redis-Konfiguration
53. /etc/rspamd/scores.d ➔ Mehr oder weniger thematisch sortierte Gruppen von Scores ➔ Inkludiert aus top-level groups.conf ➔ Leider nicht direkt erkennbar, welches Modul welche Gruppe bzw. welche Symbole verwendet ➔ Recht kryptische Symbolnamen wie z.B. HFILTER_HELO_4 ➔ Description hilft nicht immer weiter: “Helo host checks (hard)”
54. https://www.0xf8.org/2019/03/an-updated-configuration-file-structure-diagram-for-rspamd-1-9-0/ Beispiel /etc/rspamd/local.d/worker-controller.inc: password = $2$t4y… enable_password = $2$4y... “Differentielle Anpassung” heißt: Ausgelieferte Konfigurationsdateien NICHT direkt ändern, sonst werden Updates unheimlich kompliziert! Stattdessen entweder rspamd.conf.local verwenden oder besser: gleichnamige Kopie der jeweiligen Konfigurationsdatei anlegen in - /etc/rspamd/local.d (einzelne Direktiven; verschmolzen mit Original) - /etc/rspamd/overrides.d (ganze Blöcke; ersetzt Original).
55. Thunderbird-Addon rspamd-spamness von Alexander Moisseev https://rspamd.com/img/thunderbird_rspamd.png
56. Fazit ➔ Webinterface out-of-the-box, das nicht aussieht wie von 2000 ➔ Out-of-the-box Konfiguration braucht kaum Anpassungen ➔ Zumindest für meine Minizwecke reduzierte Load nicht ausschlaggebend ➔ Dokumentation schon relativ gut ➔ Paar Merkwürdigkeiten bei Struktur der Konfigurationsdateien… geschenkt ➔ Aktives Projekt (GitHub-Tickets öffnen macht Sinn) ➔ rspamd ist schon toll!
57. Fragen? Feedback? Pieter Hollants pieter@hollants.com pfhllnts pfhllnts@mstdn.io Blog-Artikel-Serie: https://www.0xf8.org/2018/05/an-alternative-introduction-to-rspamd- configuration-introduction/
58. Nachtrag: Publikumsfeedback ➔ ip_score: Empfehlung einzuschalten, lernt von alleine ➔ mx_check: Default aus weil es ausgehende Verbindung aufbaut, was oft nicht gewollt ist ➔ whitelist und ähnliche Module: by Default so konfiguriert, dass Maps von rspamd.com verwendet werden, manuelle Pflege also nicht zwingend nötig ➔ fuzzy_check: Empfehlung, dies an zu lassen wegen Checks von rspamd.com, Worker kann aus bleiben ➔ bayes_expiry: Funktioniert andersherum, erhält “gute” Tokens ➔ Configdateien nicht kopieren nach local.d, sondern neu anlegen, nur Deltas zur Defaultconfig hinterlegen