SpamAssassin Erkennungsrate (deutlich) verbessern

Jeder, der einen eigenen Mailserver betreibt, kennt es: das leidige Thema SPAM. So betreibe auch ich einen Mailserver und habe mich mit dem Thema einige Tage intensiv auseinandergesetzt. Im Folgenden gebe ich einige Tipps, wie die SpamAssassin Erkennungsrate deutlich verbessert werden kann. Zusammen mit einigen Postfix Konfigurationen kommt bei mir so gut wie überhaupt kein SPAM mehr durch.

Einleitung

SpamAssassin ist ein sehr bekanntes und ausgezeichnetes Programm, das anhand von verschiedensten Tests jeder E-Mail einen “Score” zuweist. Je höher diese Punktzahl ist, desto wahrscheinlicher handelt es sich bei der Mail um SPAM.

Ich habe meine Mailserver alle auf Basis der sehr guten Anleitung von Christoph Haas (workaround.org) konfiguriert. Christoph schreibt diese Tutorials schon sehr lange, ich glaube ich habe um 2006 herum meinen ersten Server danach aufgesetzt.

Im Rahmen des Tutorials wird auch SpamAssassin installiert und aktuell direkt, früher mittels Amavis an Postfix angebunden. Ich bevorzuge nach wie vor die Anbindung über Amavis, da ich gerne auch ClamAV als Virenscanner einsetze. Die Erkennungsrate von ClamAV ist erstmal recht gering, auch hier können wir noch einiges rausholen. Dazu werde ich demnächst noch einen Beitrag schreiben.

 

Verwendet einen eigenen DNS Resolver

Zu Beginn gleich der vielleicht wichtigste Tipp, wie die SpamAssassin Erkennungsrate deutlich verbessert werden kann. SpamAssassin benutzt für viele dieser Tests sogenannte DNS Blacklists (DNSBL). Diese werden verwendet, um z.B. die IP-Adressen der SMTP Relays abzugleichen, oder auch um in der Mail enthaltene Links zu prüfen. Falls eine Domain in einem solchen Link in einer DNSBL bekannt ist, erhöht SpamAssassin folglich den Score und die Mail kann besser klassifiziert werden. Im umgedrehten Fall wird bei vertrauenswürdigen Links der Score verringert, somit sinkt auch die Chance auf eine fälschlicherweise als Spam markierte Mail.

Viele dieser DNSBLs arbeiten nach dem Freemium Prinzip, d.h. für kleinere Mailserver ist deren Benutzung kostenfrei, bei größeren Mailserver-Installationen verkaufen die Provider dieser Listen entsprechende Zugänge. Da die Listen DNS-Basiert arbeiten, wird also die Quell-IP des anfragenden DNS-Servers getrackt und limitiert.

Wenn euer Mailserver einen bekannten öffentlichen DNS-Server verwendet (z.B. Google DNS), frägt ja letztlich dieser DNS-Server bei der Liste nach. Da diese DNS-Server von vielen tausenden Benutzern verwendet werden, laufen sie schnell in das Rate-Limit der DNSBL-Provider.

Ersichtlich wird es im E-Mail Header, wenn SpamAssassin dort den Check URIBL_BLOCKED listet. Dieser wird mit 0.001 Punkten gewertet und soll nur ein Hinweis auf genau dieses Problem sein.

URIBL_BLOCKED - SpamAssassin Erkennungsrate verbessern
Hier sieht man die Meldung URIBL_BLOCKED.

Abhilfe schafft die Verwendung eines eigenen (Caching) DNS-Resolvers. Dadurch frägt euer eigener DNS-Server bei den DNSBLs an und die Anfrage geht durch. Ich habe hier beschrieben, wie unter Ubuntu 14.04 bind als Caching DNS-Resolver installiert wird: Caching DNS-Resolver mit bind9

Allein diese Maßnahme hat die SpamAssassin Erkennungsrate bei mir deutlich verbessert.

SpamAssassin Erkennungsrate verbessern, Test DNSBL
hier wurden zahlreiche DNSBLs abgefragt. (Die Checks beginnen mit RCVD_IN)

 

Trainiert die Bayes-Datenbank

Auch mit folgendem Tipp kann die SpamAssassin Erkennungsrate verbessert werden. Das Programm verwendet eine integrierte Bayes-Datenbank, um Textphrasen zu klassifizieren und zu bewerten. Damit das Ganze funktioniert, muss diese Datenbank zunächst trainiert werden. Wichtig ist, dass der richtige Pfad zur Datenbank angegeben wird, sonst landet das ganze im .spamassassin Ordner des jeweiligen Benutzers. Dort schaut SpamAssassin (meines Wissens) allerdings nicht nach, wenn es über Amavis oder den spamd aufgerufen wird.

Spam Mail Quelle

Für das “Training” sind eine Menge Mails notwendig. Um genug Spam Mails zu bekommen, habe ich das aktuellste Monatsarchiv von http://untroubled.org/spam/ verwendet. Dieses habe ich mittels wget heruntergeladen, entpackt und anschließend das Tool sa-learn auf die Mails losgelassen. Falls SpamAssassin nicht über Amavis eingebunden ist, muss der Datenbank-Pfad angepasst werden.

Anschließend verfüttere ich auch noch alle Mails im “Junk” Ordner aller Postfächer an sa-learn

cd /tmp
wget http://untroubled.org/spam/2016-03.7z
7z x 2016-03.7z
sudo sa-learn --dbpath /var/lib/amavis/.spamassassin --progress --spam /tmp/2016/03
sudo sa-learn --dbpath /var/lib/amavis/.spamassassin --progress --spam /var/vmail/*/*/Maildir/.Junk

 

“Gute” Mails

Die Bayes-Datenbank sollte natürlich auch erwünschte Mails zu Gesicht bekommen. Hierzu verwende ich einfach alle gelesene Mails, die in allen vorhandenen Postfächern vorhanden sind.

sa-learn --dbpath /var/lib/amavis/.spamassassin --progress --ham /var/vmail/*/*/Maildir/cur

Dies kann (und sollte) man selbstverständlich via Cron-Job automatisieren.

 

Verwendet zusätzliche Signaturen

Peer Heinlein von Heinlein Support ist der Mann hinter mailbox.org – einem sicherlich nicht ganz unbekannten E-Mail Anbieter. Freundlicherweise stellt er kostenlos die von seinem Team entwickelten und beinahe täglich aktualisierten SpamAssassin Rulesets zur Verfügung. Eine Anleitung zum Einbinden in ein Debian/Ubuntu System findet ihr auf seinem Blog.

Im Wesentlichen werden diese Signaturen mittels dem bereits vorhandenen Cron-Job, der die SpamAssassin-eigenen Rulesets aktualisiert, zusätzlich geladen. Der Vollständigkeit halber anbei die modifizierte Version des Cron Bash-Scripts, unter Ubuntu 14.04 muss sie nach /etc/cron.daily/spamassassin. Die modifizierten Zeilen habe ich markiert. Neben dem eigentlichen Download prüft mein Script noch die Returncodes von beiden sa-update aufrufen. Wenn nur einer von beiden Aufrufen neue Signaturen gebracht hat, wird spamd bzw. Amavis neu gestartet. Ich habe diesen Code-Schnipsel (Zeile 70-76) aus den Kommentaren von o.g. Blog. Ist ziemlich quick’n’dirty, aber funktioniert für meine Ansprüche.

#!/bin/sh

# Duncan Findlay
# duncf@debian.org

# Daily cronjob for SpamAssassin updates. This isn't pretty but it
# should do the job.

CRON=0

test -f /etc/default/spamassassin && . /etc/default/spamassassin

test -x /usr/bin/sa-update || exit 0
test -x /etc/init.d/spamassassin || exit 0

if [ "$CRON" = "0" ] ; then
exit 0
fi

# If there's a problem with the ruleset or configs, print the output
# of spamassassin --lint (which will typically get emailed to root)
# and abort.
die_with_lint() {
su - debian-spamd -c "spamassassin --lint -D 2>&1"
exit 1
}

do_compile() {
# Compile rules if the required tools are available. Prior to version
# 3.3.2-8, there was an additional check to verify that an sa-compile
# run had previously been executed by hand. With sa-learn now
# distributed in a separate, optional, package, this check is no
# longer necessary.
if [ -x /usr/bin/re2c -a -x /usr/bin/sa-compile ]; then
su - debian-spamd -c "sa-compile --quiet"
# Fixup perms -- group and other should be able to
# read and execute, but never write. Works around
# sa-compile's failure to obey umask.
chmod -R go-w,go+rX /var/lib/spamassassin/compiled
fi
}

# Tell a running spamd to reload its configs and rules.
reload() {
# Reload
if which invoke-rc.d >/dev/null 2>&1; then
invoke-rc.d spamassassin reload > /dev/null
else
/etc/init.d/spamassassin reload > /dev/null
fi
if [ -d /etc/spamassassin/sa-update-hooks.d ]; then
run-parts --lsbsysinit /etc/spamassassin/sa-update-hooks.d
fi
}

# Sleep for up to 3600 seconds
RANGE=3600
number=`od -vAn -N2 -tu4 < /dev/urandom`
number=`expr $number "%" $RANGE`
sleep $number

# Update
umask 022
su - debian-spamd -c "sa-update --gpghomedir /var/lib/spamassassin/sa-update-keys"
retcode1=$?
su - debian-spamd -c "sa-update --nogpg --channel spamassassin.heinlein-support.de"
retcode2=$?

if [ $retcode1 -eq 0 ] || [ $retcode2 -eq 0 ]; then
retcode=0
elif [ $retcode1 -eq 2 ] || [ $retcode2 -eq 2 ]; then
retcode=2
else
retcode=$retcode2
fi

case $retcode in
0)
# got updates!
su - debian-spamd -c "spamassassin --lint" || die_with_lint
do_compile
reload
;;
1)
# no updates
exit 0
;;
2)
# lint failed!
die_with_lint
;;
*)
echo "sa-update failed for unknown reasons" 1>&2
;;
esac

Wenn alles funktioniert hat, müssten unter /var/lib/spamassassin/<version>/ einige Dateien mit “heinlein” im Namen liegen. Das sind die eigentlichen Rulesets. Anhand des Zeitstempels kann auch überprüft werden, wann das letzte Update kam.

 

Verwendet Pyzor und Razor

Pyzor und Razor sind Prüfsummenbasierte Netzwerke, um SPAM zu erkennen. Dabei wird eine Prüfsumme vom Body der erhaltenen Mail gebildet und an die Pyzor oder Razor Server gesendet. Falls die Prüfsummen von vielen Benutzern identisch sind (d.h. der Mailtext ist gleich), ist die Wahrscheinlichkeit, dass es sich bei der Mail um SPAM handelt höher.

Pyzor

Achtung: Pyzor verwendet den Port TCP 24441 für ausgehende Verbindungen zum Pyzor Server. Falls eine Firewall ausgehende Verbindungen blockiert, muss dieser Port entsprechend freigeschaltet werden. Folgende Schritte sind notwendig, um Pyzor unter Ubuntu 14.04 einzubinden:

sudo apt-get install pyzor
pyzor --homedir /etc/mail/spamassassin discover

Nun muss das noch SpamAssassin mitgeteilt werden. Dazu muss die Datei /etc/spamassassin/local.cf wie folgt editiert werden:

# die nächste Zeile dürfte schon auf 1 stehen. Falls nicht, dann anpassen.
use_pyzor &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 1
# die nächste Zeile kommt ans Ende der Datei
pyzor_options --homedir /etc/mail/spamassassin

Danach noch SpamAssassin oder Amavis neu starten, dann war’s das schon. Getestet werden kann es wie folgt:

cat /pfad/zu/ner/mail | spamassassin -D pyzor 2&amp;amp;gt;&amp;amp;amp;1 | less

Der Output sollte wie folgt aussehen:

Apr 1 14:40:43.038 [17306] dbg: pyzor: network tests on, attempting Pyzor
Apr 1 14:40:46.625 [17306] dbg: pyzor: pyzor is available: /usr/bin/pyzor
Apr 1 14:40:46.626 [17306] dbg: pyzor: opening pipe: /usr/bin/pyzor check &amp;amp;lt; /tmp/.spamassassin17306kiOe9Ytmp
Apr 1 14:40:47.528 [17306] dbg: pyzor: [17308] finished: exit 1
Apr 1 14:40:47.528 [17306] dbg: pyzor: got response: public.pyzor.org:24441 (200, 'OK') 0 0

Razor

So wird Razor unter Ubuntu 14.04 installiert und konfiguriert:

sudo apt-get install razor
sudo razor-admin -home=/etc/spamassassin/.razor -register
sudo razor-admin -home=/etc/spamassassin/.razor -create
sudo razor-admin -home=/etc/spamassassin/.razor -discover

entsprechend muss analog zu Pyzor wieder die Datei /etc/spamassassin/local.cf angepasst werden:

# die nächste Zeile dürfte schon auf 1 stehen. Falls nicht, dann anpassen.
use_razor &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; 1
# die nächste Zeile kommt ans Ende der Datei
razor_config /etc/mail/spamassassin/.razor/razor-agent.conf

Hier wüsste ich leider keinen Weg, wie man die Funktion von Razor direkt testen kann. Jedenfalls müsste ab jetzt der SpamAssassin Test RAZOR2_CHECK in Mails auftauchen. Überprüft werden kann das (nach ein paar Tagen) wie folgt:

grep -R RAZOR /pfad/zu/den/mails

 

Filtert nach Ländern

SpamAssassin bringt ein Plugin namens RelayCountry mit, mit welchem es möglich wird, die Länder der einzelnen SMTP Relays anhand der GeoIP Information zu bestimmen. Dies dient zum einen der Bayes-Datenbank. Sie bekommt also zusätzliche Informationen und wird künftig selbständig lernen, aus welchen Ländern viel Spam kommt. Ich habe bei mir noch “händische” Regeln hinzugefügt: Wenn eine Mail z.B. durch einen SMTP-Server in Vietnam relayed wurde, bekommt sie in meinem Fall zwei Punkte. Dieser Schritt hat auch nochmal gut geholfen, die SpamAssassin Erkennungsrate zu verbessern.

Folgende Schritte sind unter Ubuntu 14.04 als Vorbereitung notwendig:

apt-get install libgeo-ip-perl
mkdir /usr/share/GeoIP
wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCountry/GeoIP.dat.gz
wget http://geolite.maxmind.com/download/geoip/database/GeoIPv6.dat.gz
gunzip GeoIP.dat.gz
gunzip GeoIPv6.dat.gz
mv GeoIP.dat /usr/share/GeoIP/
mv GeoIPv6.dat /usr/share/GeoIP/

Damit wurde das notwendige Perl-Modul installiert, sowie mit der aktuellen GeoIP-Lite Datenbank von MaxMind ausgestattet. Das Plugin wird in der Datei /etc/spamassassin/init.pre aktiviert, dazu wird das Kommentarzeichen vor folgender Zeile entfernt:

loadplugin Mail::SpamAssassin::Plugin::RelayCountry

Jetzt können noch eigene Regeln geschrieben werden, um Mails aus bestimmten Ländern abzuwerten. Dazu muss ans Ende von /etc/spamassassin/local.cf folgendes:

ifplugin Mail::SpamAssassin::Plugin::RelayCountry
add_header all Relay-Country _RELAYCOUNTRY_
header RELAYCOUNTRY_BAD X-Relay-Countries =~ /(CN|RU|UA|RO|VN)/
describe RELAYCOUNTRY_BAD Relayed through spammy country at some point
score RELAYCOUNTRY_BAD 2.0

header RELAYCOUNTRY_GOOD X-Relay-Countries =~ /^(DE|AT|CH)/
describe RELAYCOUNTRY_GOOD First untrusted GW is&nbsp;DE, AT or CH
score RELAYCOUNTRY_GOOD -0.5
endif # Mail::SpamAssassin::Plugin::RelayCountry

Damit bekommt jede Mail, die durch ein SMTP-Relay in China, Russland, Ukraine, Rumänien oder Vietnam geroutet wurde, automatisch zwei Punkte. Im Gegenzug ziehe ich 0,5 Punkte ab, wenn das letzte Relay in Deutschland, Österreich oder der Schweiz stand.

Damit lässt sich das Ganze auch gut testen. Nach einem Neustart von SpamAssassin oder Amavis sollte bei jeder Mail, die aus Deutschland eintrudelt, folgender Check im Header stehen:

SpamAssassin Erkennungsrate Verbessern: Relaycountry_Good
RELAYCOUNTRY_GOOD

Im Gegenzug bei Mails aus den o.g. Ländern:

SpamAssassin Erkennungsrate verbessern: Relaycountry_Bad
RELAYCOUNTRY_BAD

 

Verwendet zusätzliche Plugins

Ich habe kürzlich ein gutes SpamAssassin Plugin von eXtremeSHOK gefunden, welches die “From” und “Reply-To” Header vergleicht. Gibt es dort Unterschiede, bekommt die Mail direkt ein paar Punkte. Je nachdem, ob sich auch die Domain unterscheidet, sind es zwei bzw. direkt fünf Punkte. Bei meinem Test ist mir oft aufgefallen, dass bei Spam-Mails hier unterschiedliche Domains verwendet werden. Diesen Tipp habe ich persönlich erst zum Schluss entdeckt und eingebaut. Seitdem kam überhaupt kein SPAM mehr durch.

Die Installation ist unter Ubuntu 14.04 sehr einfach:

cd /tmp
wget&nbsp;https://github.com/extremeshok/spamassassin-extremeshok_fromreplyto/archive/1.3.1.tar.gz
tar -zxvf 1.3.1.tar.gz
mkdir /etc/mail/spamassassin/plugins/
cp plugins/* /etc/mail/spamassassin/plugins/
cp 01_extremeshok_fromreplyto.cf /etc/mail/spamassassin

Das war’s schon, anschließend muss noch Amavis oder der spamd neu gestartet werden. Getestet werden kann das Plugin, indem man sich selbst eine Mail schickt. Anschließend sollte der Check FROM_IS_TO im Mailheader auftauchen.

 

Modifiziert die Punktevergabe

Noch ein Kurztipp am Ende. Dieser Tipp ist relativ “advanced”, da man genau wissen sollte, was man verändert.

Mittels der Datei /etc/spamassassin/local.cf können die Standardwerte der Punktevergabe für Checks verändert werden. Ich habe bei mir die vergebenen Punkte erhöht, wenn eine Domain oder ein Link in einer DNSBL auftaucht:

score RCVD_IN_BL_SPAMCOP_NET 0 5.246 0 5.347
score RCVD_IN_BRBL_LASTEXT 0 5.246 0 5.347
score URIBL_BLACK 0 5.7 0 5.7
score URIBL_WS_SURBL 0 2.659 0 2.608
score URIBL_MW_SURBL 0 2.263 0 2.263
score URIBL_CR_SURBL 0 2.263 0 2.263
score URIBL_GREY 0 2.084 0 1.424
score URIBL_DBL_SPAM    0 4.5 0 4.5
score URIBL_DBL_PHISH   0 4.5 0 4.5
score URIBL_DBL_MALWARE 0 4.5 0 4.5
score URIBL_DBL_BOTNETCC 0 4.5 0 4.5
score URIBL_DBL_ABUSE_SPAM 0 4.0 0 4.0
score URIBL_DBL_ABUSE_PHISH 0 4.5 0 4.5
score URIBL_DBL_ABUSE_MALW  0 4.5 0 4.5
score URIBL_DBL_ABUSE_BOTCC 0 4.5 0 4.5

24 Comments on “SpamAssassin Erkennungsrate (deutlich) verbessern

  1. Pingback: Caching DNS-Resolver mit bind9 | SYN-FLUT.de

  2. Gibt doch immer wieder interessante Artikel zu finden 🙂 Besonders gefallen hat mir das SpamAssassin Plugin von eXtremeSHOK; war mir bisher nicht bekannt. Ein schöner Blog. Vielen Dank

    • Hi Lars,

      danke für das Lob! Bin ja aktuell noch arg am Aufbau und habe aktuell auch leider wenig Zeit. Aber mit der Zeit wird das schon werden. Motivation habe ich jedenfalls genug. 🙂

      Viele Grüße
      Alex

  3. Interessanter Beitrag. Mal sehen, was das Pimpen von Spamassassin bring. Leider hat es bei den Scripten die Sonderzeichen verhagelt, kannst Du das ändern? Ich hätte nämlich gerne das Updatescript 😉

    • Hi Thomas,

      danke für den Hinweis! Habe es eben repariert. Jetzt kann das Script verwendet werden. 🙂

      Viele Grüße
      Alex

  4. Hallo,

    danke für deinen Blog. Gefällt mir gut.
    Leider bekomme ich den URIBL_BLOCKED nicht angezeigt. Muß der Header irgendwo noch aktiviert werden?

    lg

    wynni

  5. Wenn ich mir meine Mailserver mit “catchall” konfiguriere, also ALLE Mails zustelle, fällt schnell auf, dass mancher Spam tatsächlich an 100te @meinserver.net gehen.

    Gibt es ein Filtermodul, dass Mails als Spam markiert, welche vom selben Absender/Betreff/Inhalt an mehr als k Postfächer gehen?

    Also als hartes Kriterium, nicht durch nachträgliches Anlernen…

  6. Müssen die GeoIP Datenbanken regelmäßig aktualisiert werden, z.B. per Cronjob? Die einmal heruntergeladenen .dat Dateien unter /usr/share/GeoIP ändern sich nicht von alleine. Hingegen neu heruntergeladene GeoIP(v6).dat ein anderes Datum und Größe haben. Besteht die Notwendigkeit die Datenbanken von Zeit zu Zeit zu aktualisieren?

    Gruß,
    Lars

    • Je nach Linux-Distribution wird die GeoIP.dat im Optimatfall nicht einfach runtergeladen, sondern über den Package-Manager deiner Distribution installiert. Somit wird sie auch automatisch über die Auto-Update-Funktion aktualisiert (die du hoffentlich konfiguriert hast)…..

  7. Hallo Alex,

    schöner Artikel, danke, daß Du es mal so gut zusammengefaßt hast! Auch für Debian Server eine schöne Zusammenfassung! Die GeoIP Datenbanken sind im aktuellen Debian Stretch und Testing schon dabei, müssen in dem Fall nicht unbedingt per Cronjob aktualisiert werden.

    Eine Besonderheit:

    pyzor –homedir /etc/mail/spamassassin discover

    funktioniert beim aktuellen Debian und auch anderen aktuelleren Distributionen nicht. Das “discover” gibt es nicht mehr. Bei neuen Pyzor Versionen muß man gar keine homedir mehr angeben, es funktioniert bereits so… die Einbindung in die

    /etc/spamassassin/local.cf

    wie Du beschrieben hast, pyzor_options braucht man nicht mehr.

    Mir gefielen Deine Änderungen an der Punktevergabe, das mit den Ländern ist interessant, Pyzor und Razor bringt einiges… http://untroubled.org/spam/ zum Training ist natürlich hervorragend und gleichsam erschreckend. Abgründe der Menschheit… 🙂

    Das „From“ und „Reply-To“ Vergleichsplugin bringt auch viel!

    Etwas möchte ich noch hinzufügen:

    Den absolut größten Effekt hat auf unseren Servern insbesondere Greylisting

    (https://de.wikipedia.org/wiki/Greylisting)

    Damit wird im Grunde fast alles weg gefiltert. Spamassassin kümmert sich um den mickrigen Rest – das ist vor allem spannend, wenn man nur wenig Rechenleistung zur Verfügung hat (kleiner privater Mailserver auf einem Raspberry Pi 3 oder so – Nachteil: auch gewollte Mails, Anmeldebestätigungen usw. kommen verzögert an, aber es ist zur Spambekämpfung wie gesagt hoch effektiv und spart CPU Zeit.)

  8. Weißt du zufällig welcher ersatz befehl es für “discover” jetzt gibt, bei pyzor?
    Den befehl gibt es nicht mehr unter Ubuntu Artful/Debian Stretch.
    “(9653) CRITICAL Unknown command: discover”

  9. > spamd[32175]: config: failed to parse line, skipping, in “/etc/spamassassin/local.cf”: use_razor 1

    Diese Direktive scheint es nicht zu geben.

    • in neueren Installationen muß die Zeile

      use_razor 1

      durch

      use_razor2 1

      ersetzt werden, dann mault spamassissin auch nicht mehr über die Zeile.

    • bei neuen Installation von razor muss die Zeile in local.cf

      use_razor 1

      ersetzt werden durch

      use_razor2 1

      dann mault auch spamassassin nicht mehr.

  10. Weißt du, wie man das ganze für Debian Stretch adaptiert? Der cronjob sieht da etwas anders aus:

    # Update
    umask 022
    env -i LANG=”$LANG” PATH=”$PATH” http_proxy=”$http_proxy” \
    start-stop-daemon –chuid debian-spamd:debian-spamd –start \
    –exec /usr/bin/sa-update — \
    –gpghomedir /var/lib/spamassassin/sa-update-keys 2>&1

    case $? in

  11. Bei den “Guten Mails” sollte man sehr vorsichtig sein. Bei einem Shared Server gibt es durchaus Nutzer, die SPAM Mails nicht in den Spam Ordner schieben oder löschen. Daher würde Bayes auch von schlechten E-Mails lernen. Ich empfehle hier lieber den Weg über RBL’s. Mittlerweile bekommt man damit 90% des SPAM abgelehnt.

  12. Auch wenn der Artikel schon etwas älter ist, waren noch ein paar schöne Ideen dabei, die nach kleineren Anpassungen auch bei Ubuntu 18.04 ihren Dienst tun.
    Vielen Dank dafür!

  13. Nach dem Aufruf von spamassassin im Ordner /etc/cron.daily erhalte ich immer den folgenden Fehler

    error: error setting creation time of /var/lib/spamassassin/3.004002/spamassassin_heinlein-support_de/MIRRORED.BY: Operation not permitted
    Cannot open file /var/lib/spamassassin/3.004002/spamassassin_heinlein-support_de/1718.tar.gz: No such file or directory at /usr/bin/sa-update line 1600.

    Die Berechtigungen sehen exakt so aus wie beim originalen ruleset von SA.

    Habe ich was vergessen/übersehen/überlesen?

  14. Hallo,
    vielleicht kann mir hier jemand helfen, im Netz habe ich dazu nichts passendes gefunden.
    Gibt es eine Möglichkeit in Spamassassin Mails mit bestimmten Endungen zu blocken?
    Mein Hostanbieter bietet mir für meine Mailkonten einen Spamfilter (Spamassassin) an. Dort werden aber im einfachen Modus nur ganze Adressen bzw. Wildcards nur vor dem @ akzeptiert. Z.B.
    Blacklist_from Kontact@55410-deutschinc.club
    oder
    Blacklist_from *@55410-deutschinc.club

    Im Modus für Fortgeschrittene kann man auf Commandoebene editieren.
    Gibt es eine Regel die mir alle Mailadressen mit der Endung .club sperrt?
    Versucht habe ich:
    Blacklist_from *@*.club
    Blacklist_from *.club
    Beides hat nicht funktioniert.
    Vielleicht bin ich ja auf einem völlig falschen Weg.
    Hat jemand eine Idee?
    Bin für jeden Rat dankbar.
    Vielen Dank
    Gruß Wolfgang

  15. Moin, ♥ Dank für die Anleitung, ist diese nach all den Jahren eig immer noch Aktuell?

    Würde mich freuen wenn dieser Thread ggf. Aktualisiert wird, so dass es auch mit neueren SPAMASSASSIN, Debian/Ubuntu und Postfix/Dovecot Versionen sauber läuft.

    Freue mich auf Infos hierzu

    • Hi Christoph! Bei mir steht bald selbst ein Mailserver Upgrade an, somit werde ich diesen Artikel demnächst überarbeiten. Nötig und verdient hätte er’s 🙂

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert