SpamAssassin:Konfiguration

Aus KissDoc

---

Top Inhaltsverzeichnis 1 Installation 2 Bewertungskonfiguration 2.1 Statische Tests 2.2 Externe Tests 2.3 Lernende Test (Bayes) 2.4 Eigene Tests 3 Einbindung in Exim

Thema: SpamAssassin

Installation

Syntaxtest: spamassassin --lint

Bewertungskonfiguration

Die Mails werden nach verschiedenen Kriterien bewertet. Wenn ein Kriterium anschlägt, werden Aufgrund einer Bewertungstabelle (/usr/share/spamassasign/50_scrores.cf) Score-Punkte vergeben. Übersteigt die Summe aller Score-Punkte ein bestimmtes Limit (Option required_score), wird die Mail im Header als Spam gekennzeichnet.

Wichtig: Die Bewertungstabelle ist abhängig von den Tests, die man durchführt (eine Kombination von lokalen Tests, externen Tests und Bayes-Test).

Man kann natürlich auch selbst an der Bewertung rumschrauben, allerdings machen die Jungs vom SpamAssasin bestimmt einen guten Job. Aber testen kostet ja nix:

#local.cf

#10 Score-Punkte vergeben, egal ob local, extern oder Bayes
#score DRUGS_ERECTILE 10

# 10 Punkte bei local, 20 Punkte bei local+extern, 30 bei local+Bayes, 40 bei local+extern+Bayes
#score DRUGS_ERECTILE 10 20 30 40

Die Tests (Prüfungsvorschriften) sind nach ihrer Art her Kategorisiert:

Statische Tests

Der Hauptmechanismus von SpamAssassin sind die lokalen statischen Tests. Sie prüfen einen bestimmnten Aspekt, unabhängig von früheren Testläufen oder externen Quellen. Die Dateien für die statischen Tests selbst befinden sich in /usr/share/spamassasin und enden alle mit .cf.

Ein mächtiges Mittel stellen dabei die Spracheinstellungen mit den beiden Einstellungen ok_languages de en (UNWANTED_LANGUAGE_BODY mit 2,8) und ok_locales en (CHARSET_FARAWAY oder CHARSET_FARAWAY_BODY mit 3,2).

Ein zweites starkes Mittel der statischen Tests sind Blacklists. Diese müssen jedoch gewartet werden. Wir versuchen derzeit ohne statische Blacklists auszukommen.

Achtung: Wenn die Mailsuser in Bereichen arbeiten, welche oft Thema von Spam's sind wie Gesundheitswesen, Finanzwesen, Erotik oder einfach nur englische Mails, sind genauere evaluierungen der Konfiguration nötig.

Externe Tests

Darunter versteht man Dienste wie DCC und Pyzor. Auch die DNS Prüfung für RBL's kann sinnvoll sein. Jedoch hat alles zwei Seiten. Wir verwenden derzeit keine externen Tests:

use_dcc 0
use_pyzor 0
use_razor2 0
skip_rbl_checks 1
dns_available no

Dabei verwenden wir jedoch die erhöte Punktzahl der statischen Tests mittels spamassassin -L (siehe Bewertungstabelle).

Lernende Test (Bayes)

Der Bayes-Test ist ein Test, der Aufgrund von bereits bewerteten Mails, also spam (Spam-Mails) oder ham (gute Mails) in seiner Datenbank nachschaut und damit eine Spam-Wahrscheinlichkeit ermittelt - also ein lernendes System. Man kann Spamassassin so einstellen, dass eine gerade eingegangene und bewertete Mail automatisch als pam oder ham in die Bayes-DB wandert. Das ist allerdings mit dem Risiko behaftet, das die Mail auch mal falsch reinrutschen kann und damit das ganze eher nach hinten losgeht. Alternativ dazu vielleicht folgenden Variante:

• Die eingehende Mail landet beim MTA, der sie an SpamAssassin zur Bewertung weitergibt.
• SpamAssassin bewertet die Mail und gibt das Ergebnis an den MTA zurück.
• Daraufhin wird die Mail vom MTA gekickt oder dem User zugestellt (z.B. Posteingang des Cyrus-Users).
• Der User liest jetzt die Mail mit seinem Mail-Client und sagt sich: Das ist eine Spam-Mail - und verschiebt diese in einen Spam-Ordner.
• Per Cron-Job werden alle Mails aus dem Spam-Ordner der Bayes-DB als spam untergeschoben, alle anderen Mails (Posteingang usw.) als ham.
• Damit wird das ganze zu einem selbstlernenden System mit User-Kontrolle. Am Anfang wird es sicher etwas mehr Pflege-Aufwand auf User-Seite sein, die Spam-Erkennung sollte sich aber sehr schnell verbessern.

Folgende Config wäre also denkbar:

bayes_path /var/lib/spamassassin/bayes
use_bayes 1
bayes_auto_learn 1
bayes_auto_learn_threshold_nonspam 0.2
bayes_auto_learn_threshold_spam 12
bayes_ignore_to postmaster@domain.tdl

Hinweis: Standardmässig ist die Bayes-DB bei jedem User einzeln in seinem Home. Damit müssten sich alle User selbst darum kümmern (oder eben der Admin). Günstiger ist da für unser Vorhaben die zentrale Haltung einer einzigen zentralen Bayes-DB.

Eigene Tests

Z.Zt. keine.

Einbindung in Exim

Die Einbindungsmöglichkeiten von SpamAssassin in Exim sind umfangreich. Die einfachste herkömmliche Möglichkeit besteht aus einem Transport und einem Router. Auch eine Einbindung über SA-Exim wäre denkbar. Schließlich ist die Einbindung auch mittels Amavisd-new möglich. Dank der umfangreichen Möglichkeiten von Exim ist jedoch ein so komplexes System wie Amavis nicht zu empfehlen.

Seit Exim 4.5 gibt es die Möglichkeit, SpamAssassin über das Content-Scanning Feature (früher exiscan Patch) einzusetzen. Die ACL verfügt über eine neue Bedingung namens spam, welche spamd/spamc verwendet.

Folgende Einstellungen könnten in die acl_smtp_data Sektion oder nach Debian-Art in die Datei conf.d/acl/40_exim4-config_check_data:

.ifdef CHECK_DATA_SPAM_MARK
.ifdef CHECK_DATA_SPAM_BLOCK
deny
  message = We do not need ad. If you think that is false, get in touch with hostmaster.
  spam = nobody
  condition = ${if >{$spam_score_int}{CHECK_DATA_SPAM_BLOCK}{1}{0}}
  delay = 10s
.endif

warn
  message = X-Spam-Level: $spam_bar
  spam = nobody:true/defer_ok
  
warn
  message = X-Spam-Status: Yes, score=$spam_score
  spam = nobody
  
warn
  message = X-Spam-Status: No, score=$spam_score
  !spam = nobody
  
warn
  message = X-Spam-Report: $spam_report
  spam = nobody
  
warn
  message = Subject: ***SPAM*** $h_Subject
  spam = nobody
  condition = ${if >{$spam_score_int}{CHECK_DATA_SPAM_MARK}{1}{0}}
  delay = 10s
  
.endif

Damit der Spaß auch eingeschalten wird, sind noch die beiden folgenden Zeilen nach Debian-Art in der Datei conf.d/main/01_exim4-config_listmacrosdefs unterzubringen:

#80=8.0 and 65=6.5
CHECK_DATA_SPAM_MARK  = 65
CHECK_DATA_SPAM_BLOCK = 80