Aktuelle SpamAssassin-Regeln von Heinlein Support

spamassassinAuf den Webseiten zu unserem Postfixbuch veröffentlichen wir seit jeher tagesaktuelle Header-/Bodychecks für aktuell kursierende Spam-Mails. Viele Leser und Kunden von uns haben diese Checks in ihre jeweilige Postfix-Konfiguration eingebunden und aktualisieren die Scripte per Cron-Job. Jetzt haben wir unsere Checks umgebaut und veröffentlichen sie ab sofort als SpamAssassin-Ruleset — bequem aktualisierbar über sa-update.

Das Problem an Header-Body-Checks in Postfix: Sie wirken final. Treffen sie zu, wird die jeweilige Mail sofort abgelehnt und hat keine weitere Chance. Fast immer ist das kein Problem, sind unsere Pattern doch absichtlich sehr konkret gehalten und können oft kaum auf eine andere Mail unberechtigterweise passen. Aber „oft“ und „kaum“ ist eben nicht „nie“ und so kam es immer wieder mal dazu, daß diese Checks auch zu einem False Positive führen konnten.

Aktuelle SpamAssassin-Regeln direkt aus unserem Live-Betrieb

Seit einem Jahr nutzen wir unsere Checks für unsere hauseigenen Spamfilter bei Heinlein Hosting, dem Hosted Anti-Spam-Service oder unserem Provider JPBerlin.de darum bereits als SpamAssassin-Ruleset. Die meisten Regeln haben dabei eine Gewichtung von 5, so daß sie extrem stark in die Gewichtung eingehen, aber trotzdem immer noch weitere verdächtige Faktoren hinzukommen müssen. Oder andersherum formuliert: Ist eine E-Mail ansonsten sehr sauber, wird sie auch bei einem normalen Treffer unserer Body-/Header-Checks nicht gleich herausgefiltert werden.

Gute SpamAssassin-Regeln, keine False Positives

Die neuen SpamAssassin-Regeln haben sich bewährt: Sehr gute Filterergebnisse, keine False Positives-Querschläger.

Mit dem heutigen Tag werden wir die bisherigen Body-/Header-Checks von http://www.postfixbuch.de darum nicht mehr weiter pflegen, sondern zeigen lieber hier die Anleitung, wie automatisiert über sa-update unsere Regelsätze in Amavis/SpamAssassin eingebunden werden.

Jede SpamAssassin-Installation sollte so oder so täglich per Cron-Job einen Aufruf des Tools „sa-update“ durchführen. Fehlt das Tool, so muß bei einigen Distributionen noch das Paket „spamassassin“ ausdrücklich installiert werden.

SpamAssassin Regeln von Heinlein Support über sa-update

sa-update prüft über eine DNS-Abfrage sehr performant, ob neue Regelsätze vorliegen und lädt ggf. die jeweiligen Regelsätze per http-Download herunter. Wird sa-update ohne Parameter aufgerufen, lädt es automatisch die Regeln von updates.spamassassin.org.

Über den Aufruf

sa-update --nogpg --channel spamassassin.heinlein-support.de

werden parallel zu den normalen SpamAssassin-Regeln auch unsere Heinlein-eigenen Regeln installiert. Sie finden sich dann in /var/lib/spamassassin/<version>/spamassassin.heinlein-support.de wieder.

Profis, die compilierte SA-Regeln einsetzen, müssen nun re2c ausführen. In allen Fällen aber muß der spamd, bzw. der Amavis neu gestartet werden, je nachdem, was eingesetzt wird.

Die üblichen Distributionen bringen jedoch bereits fertige Cron-Scripte in /etc/cron.daily mit, in denen sich mit wenigen Handgriffen auch der Aufruf unserer Regeln ergänzen läßt. Achten Sie natürlich darauf, daß ein http-Connect zu http://www.spamassassin.heinlein-support.de/ möglich ist!

Die Einrichtung von sa-update unter Debian

Das Cron-Script liegt in /etc/cron.daily/spamassassin, dort findet sich ungefähr in Zeile 64 der Aufruf von sa-update:

# Update
umask 022
sa-update

Hier wird nun der zweite Aufruf unserer Regelsätze wie folgt ergänzt:

# Update
umask 022
sa-update
sa-update --nogpg --channel spamassassin.heinlein-support.de

ansonsten kann alles so bleiben, wie es ist. Bitte achten Sie darauf, daß der Cron-Job in /etc/default/spamassassin aktiviert ist:

# Cronjob
# Set to anything but 0 to enable the cron job to automatically update
# spamassassin's rules on a nightly basis
CRON=1

Die Einrichtung von sa-update unter OpenSUSE/SLES

Das Script liegt hier als /etc/cron.daily/suse.cron-sa-update vor, der Aufruf von sa-update sieht per Default so aus:

if [ "$SPAM_SA_UPDATE" = "yes" ]
then
        /usr/bin/sa-update &> /dev/null
        result=$?

Und kann wie folgt ergänzt werden:

if [ "$SPAM_SA_UPDATE" = "yes" ]
then
        /usr/bin/sa-update --nogpg --channel spamassassin.heinlein-support.de &> /dev/null    
        /usr/bin/sa-update &> /dev/null
        result=$?

Auch hier ist darauf zu achten, daß der Cron-Job in /etc/sysconfig/spamd wie folgt aktiviert ist:

# Set this varible to yes if you want the daily cron job
# to call sa-update. 
SPAM_SA_UPDATE="yes"

sowie ggf. auch die anderen Parameter in dieser Datei den Neustart von Amavis etc. regeln.

Häufigere Updates

SpamAssassin veröffentlicht nur sehr selten, wenige Male im Jahr, neue Regelupdates, so daß ein täglicher Cron-Job hier ausreichend ist. Wir veröffentlichen jedoch fortlaufend neue Updates, wann immer unser Support-Team unerkannte Spamwellen entdeckt und eingepflegt hat. Aus diesem Grunde können bei unseren Regelsätzen auch stündliche Cron-Jobs sehr sinnvoll sein. In diesem Fall sollte man die Script-Datei von /etc/cron.daily einfach nach /etc/cron.hourly verschieben.

sa-update prüft eh anhand eines sehr schnellen DNS-Lookups die Seriennummer und wird so bei unveränderten Regelsätzen gar keine TCP-Verbindung zum jeweiligen Update-Server aufbauen. Der stündliche Cron-Job hat also keine tiefergehenden Beeinträchtigungen zur Folge.

  •  Die von uns veröffentlichten SpamAssassin-Regeln sind absolut identisch zu den von uns im Livebetrieb genutzten Regeln. Ggf. sind kurzzeitig eingebaute Fehler oder Irrtümer nicht ausgeschlossen. Verwendung daher auf absolut eigene Gefahr.

 

 

Dieser Beitrag wurde unter Blog, Mailserver, News, Spam abgelegt und mit , , , , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

32 Antworten auf Aktuelle SpamAssassin-Regeln von Heinlein Support

  1. 42 sagt:

    Danke. :-)

    Ein Hinweis zu Debian Wheezy.
    Dort sieht der Aufruf in Zeile 62 von /etc/cron.daily/spamassassin so aus:
    su debian-spamd -c "sa-update --gpghomedir /var/lib/spamassassin/sa-update-keys"

    Man sollte also auch diese Regeln mit dem User „debian-spamd“ aktualisieren, um die Form (und die Rechte) zu wahren:
    su debian-spamd -c "sa-update --nogpg --channel spamassassin.heinlein-support.de"

  2. Florian sagt:

    Klasse, vielen Dank.

    Ein Hinweis allerdings für Debian: Wenn man das nun nach der Anleitung
    aus dem Blog macht, kann es unter Umständen (sogar häufig) dazu kommen,
    dass zwar Regeln geladen werden, aber weder ein Reload noch ein
    Recompile der Regeln stattfindet. Grund ist, dass das Debian-Script nur
    den Exit-Codes des vorherigen Befehls prüft. Und das wäre dann eben das
    sa-update von heinlein. Ergibt das einen Exit-Code von 1, beendet sich
    das Script und macht nichts weiter. Es könnte aber gut sein, dass das
    „normale“ sa-update kurz vorher einen Exit-Code von 0 produziert hat
    und damit ein recompile&reload notwendig gewesen wäre. Das ist also
    nicht gerade optimal. Ganz trivial ist der Fix natürlich in dem Fall
    auch nicht.

    Wir behelfen uns jetzt mit dieser alles andere als eleganten Lösung:

    Ungefähr Zeile 62:

    # Update
    umask 022
    sa-update
    retcode1=$?

    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!
    spamassassin –lint || die_with_lint
    do_compile
    reload
    ;;
    1)
    # no updates
    exit 0
    ;;
    2)
    # lint failed!
    die_with_lint
    ;;
    *)
    echo „sa-update failed (with exit code $?) for unknown reasons“ 1>&2
    ;;
    esac

    Vielleicht kann man zumindest den Hinweis noch in den Blog einbauen.
    Wie man das dann für sich löst, ist ja jedem selbst überlassen. Uns
    reicht es so, andere müssen möglicherweise das case-statement noch
    umstellen, damit es 100% korrekte Fehlermeldungen für jeden
    Update-aufruf gibt. Du kannst das aber gerne so 1:1 übernehmen.

    Grüße
    Florian

  3. Chris sagt:

    Vorab auch von mir vielen Dank. :-)

    Sind die Regeln bereits online und verfügbar? Ich bekomme beim Abrufen immer den Hinweis, dass keine Updates verfügbar sind.


    Jan 17 15:22:53.086 [24668] dbg: channel: attempting channel spamassassin.heinlein-support.de
    Jan 17 15:22:53.086 [24668] dbg: channel: update directory /var/lib/spamassassin/3.003001/spamassassin_heinlein-support_de
    Jan 17 15:22:53.086 [24668] dbg: channel: channel cf file /var/lib/spamassassin/3.003001/spamassassin_heinlein-support_de.cf
    Jan 17 15:22:53.086 [24668] dbg: channel: channel pre file /var/lib/spamassassin/3.003001/spamassassin_heinlein-support_de.pre
    Jan 17 15:22:53.182 [24668] dbg: channel: no updates available, skipping channel

    Viele Grüße
    Chris

  4. Alex sagt:

    Leider nicht SA 3.4.* tauglich:

    Jan 18 00:29:03.291 [51406] dbg: channel: attempting channel spamassassin.heinlein-support.de
    Jan 18 00:29:03.291 [51406] dbg: channel: using existing directory /var/lib/spamassassin/3.004000/spamassassin_heinlein-support_de
    Jan 18 00:29:03.291 [51406] dbg: channel: channel cf file /var/lib/spamassassin/3.004000/spamassassin_heinlein-support_de.cf
    Jan 18 00:29:03.291 [51406] dbg: channel: channel pre file /var/lib/spamassassin/3.004000/spamassassin_heinlein-support_de.pre
    Jan 18 00:29:03.345 [51406] dbg: dns: query failed: 0.4.3.spamassassin.heinlein-support.de => NXDOMAIN
    Jan 18 00:29:03.389 [51406] dbg: channel: no updates available, skipping channel
    Jan 18 00:29:03.389 [51406] dbg: diag: updates complete, exiting with code 1

  5. Pingback: Aktuelle Welle von Banktrojaner mit SpamAssassin filterbar | Heinlein Support - Unser Linux-Blog für Admins

  6. Das für SpamAssassin 3.2 und 3.4 keine Seriennummern veröffentlicht wurden, war ein kleiner Bug, der eben gefixt wurde. Auch andere 3er-Versionen von SpamAssassin kriegen jetzt die Regel-Updates. Bitte nochmal prüfen.

  7. Alex sagt:

    achtung:

    Jan 18 12:34:18.909 [27503] dbg: rules: HS_HEADER_128 merged duplicates: HS_HEADER_129
    Jan 18 12:34:18.909 [27503] dbg: rules: HS_BODY_214 merged duplicates: HS_BODY_215
    Jan 18 12:34:18.909 [27503] dbg: rules: HS_BODY_465 merged duplicates: HS_BODY_473
    Jan 18 12:34:18.910 [27503] dbg: rules: HS_HEADER_162 merged duplicates: HS_HEADER_220

    sonst ok:

    Jan 18 12:34:19.021 [27503] dbg: channel: adding 70_HS_body.cf
    Jan 18 12:34:19.021 [27503] dbg: channel: adding 70_HS_header.cf
    Jan 18 12:34:19.021 [27503] dbg: generic: unlinking /var/lib/spamassassin/3.004000/spamassassin_heinlein-support_de/325.tar.gz.sha1
    Jan 18 12:34:19.021 [27503] dbg: generic: unlinking /var/lib/spamassassin/3.004000/spamassassin_heinlein-support_de/325.tar.gz
    Jan 18 12:34:19.022 [27503] dbg: channel: update complete
    Jan 18 12:34:19.022 [27503] dbg: generic: cleaning up temporary directory/files
    Jan 18 12:34:19.022 [27503] dbg: generic: cleaning directory /tmp/.spamassassin27503WmoLSWtmp
    Jan 18 12:34:19.022 [27503] dbg: generic: unlinking 70_HS_header.cf
    Jan 18 12:34:19.022 [27503] dbg: generic: unlinking 70_HS_body.cf
    Jan 18 12:34:19.022 [27503] dbg: diag: updates complete, exiting with code 0

    Danke!

  8. Sascha Peters sagt:

    Coole Sache… war meine Idee vor einiger Zeit ja gar nicht sooo dumm :-)
    Danke dafür…

  9. Kann es sein, daß da jetzt eine GPG Signature dran ist?
    # sa-update –allowplugins –channelfile /etc/spamassassin/sare-sa-update-channels.txt –gpgkeyfile /etc/spamassassin/sa-update-keys.txt
    gpg: process ‚/usr/bin/gpg‘ finished: exit 2
    error: GPG validation failed!
    The update downloaded successfully, but it was not signed with a trusted GPG
    key. Instead, it was signed with the following keys:

    343F74FE

    Perhaps you need to import the channel’s GPG key? For example:

    wget http://spamassassin.apache.org/updates/GPG.KEY
    sa-update –import GPG.KEY

    channel: GPG validation failed, channel failed

    (ich kann GPG und NOGPG schlecht mischen…)

  10. Sascha Peters sagt:

    Ich habe nun einen eigenen Cronjob angelegt der mit dem Rückgabewert von sa-update arbeitet… (1 Wenn eine neue Regel installiert wurde). Mein Startskript vom amavis kennt das „reload“ nicht, weiß jemand ob man dem Amavis auch „reloaden“ kann, damit die Regeln vom Spamassassin neu eingelesen werden. (Spamassassin nicht als Daemon)

    30 * * * * root /usr/bin/sa-update –nogpg –channel spamassassin.heinlein-support.de && /etc/init.d/amavis restart

  11. Daniel sagt:

    Ich verwendet für /etc/cron.daily/spamassassin unter Debian Wheezy:

    sa-update –gpghomedir /var/lib/spamassassin/sa-update-keys –channel updates.spamassassin.org –channel spamassassin.heinlein-support.de

  12. Ja. So machen tun:

    /usr/sbin/amavisd-new reload &> /dev/null

  13. Danke, Dubletten sind gefixt!

  14. Sascha Peters sagt:

    Also wenn ich bei meinem Ubuntu, wo ich das neuerer Amavis installiert habe (von Hand) „/usr/sbin/amavisd-new reload“ mache, dann ist amavis beendet :-) Da scheint irgendwas faul zu sein…

  15. Das Update der SpamAssassin-Regeln hat nichts mit einem Reload von Amavis zu tun. Schau ins Logfile, da werden Hinweise stehen.

  16. Sascha Peters sagt:

    Ich wollte auch nicht sagen das die Regeln damit zu tun haben, außer das Sie dann nicht verwendet werden 😉 Ich habe mir die Logfiles angesehen, steht nichts was im augenblick relevant wäre. Ich habe es nun auf einem Ubuntu eigenen Amavis getestet, „reload“ ist im Init Skript zwar aus, aber wie Du es sagst, geht es. Nur das dies ebenfalls einen „restart“ bewirkt, wenn man im Logfile schaut…. also scheint es keine „Verbesserung“ zu sein, nicht im Moment… Soweit nur kurz die Rückmeldung… Die Regeln sind trotzdem super und Gold Wert :-)

  17. Toni Schornböck sagt:

    Ich habe diese Regeln ein paar Tage bei uns laufen lassen, aber leider sind sie mir viel zu aggressiv. Viele Regeln scoren mit 5 oder teilweise sogar mehr punkten, was zB gerade bei den Body Checks die auf Newsletter gehen einfach zu hoch ist. Ein DCC_CHECK + ein HS_BODY_* Zusammen killt mir jeden Newsletter egal wie gut Bayes anschlägt.

    Wäre es möglich eine Metaregel einzuführen wenn ein HS_BODY_* matcht, so dass man hier rescoren kann? Denn aktuell ist ein rescoring der Regeln nicht wirklich möglich – da ich davon ausgehen muss dass sich die Anzahl der Regeln ändert.

    Die HS_HEADER Regeln gefallen mir sehr gut, lediglich HS_BODY ist einfach zu hoch gescored. Ich persönlich mag ja sowieso keine Regeln die von sich selbst behaupten 100% genau Spam zu erkennen… (was ein Score von 5 oder höhre ja bedeutet).

  18. In der Tat sind einige Body-Scores derzeit noch zu hoch. Normalerweise sollten alle Regeln dort nur einen geringen Score haben. Da die letzten Wochen sehr aggressiver und auch gefährlicher Spam unterwegs war, haben wir in einigen Fällen den Score ausnahmsweise höher angesetzt. Von Problemen mit Newslettern ist uns hier nichts bekannt. Bugreports nehme ich gerne entgegen. Ansonsten werden wir den Score auch alsbald wieder senken.

  19. Marcel Jähne sagt:

    Da ich unter Debian Wheezy meinen Spamassassin über /service/spamd automatisch starten lasse, sieht mein Cronjob folgendermaßen aus:
    /usr/local/bin/sa-update –gpgkey 40F74481 –channel sa.zmi.at –gpgkey 6C6191E3 –channel sought.rules.yerp.org –channel updates.spamassassin.org –nogpg –channel spamassassin.heinlein-support.de && killall -9 spamd

    Gruß
    Marcel

  20. Andreas Wass sagt:

    Hallo Heinlein Support!
    Vielen Dank für den zusätzlichen Spamschutz über sa-update. Eine Frage hätte ich dazu: Werden die Logeinträge im maillog bei Anwendung einer eurer Spamregeln mit einem Zusatz versehen oder wie kann man das dann sehen?

    mfg Andreas Wass

  21. Ja, unsere Regeln tauchen bei den SpamAssassin-Treffern dann immer mit „HS_“ (=Heinlein Support) als Prefix auf.

  22. Gabriel Hege sagt:

    Achtung: unter Ubuntu (14.04 und evtl. auch andere Debian-basierte Systeme) enthält das ‚daily‘ Cron-Skript für Spamassassin ein zufälliges Sleep für 0-3600 Sekunden. Wenn man das Skript einfach nach cron.hourly verschiebt, kann es passieren, dass es zweimal parallel ausgeführt wird und außerdem andere stündliche Cronjobs ebenfalls bis zu einer Stunde verzögert werden.

    Ich würde noch RANGE (Zeile 57 im Skript) auf maximal 600 (10 min) setzen.

    ciao,
    Gabriel

  23. Benjamin Mark sagt:

    Hallo,

    erst mal vielen Dank für die Bereitstellung eurere Regeln im Kampf gegen den Spam-Mist. Ich würde auch gern nochmal auf GPG zurückkommen. Da ich Spamassassin nicht „pur“ benutze sondern in Kombi mit dem Zimbra Server muss ich die ganzen Channel-Updates in ein Statement packen da das sa-update von einem Zimbra Script gemacht wird. Das sieht momentan so aus:

    ./sa-update -D -v –gpgkey 24F434CE –channel sought.rules.yerp.org –gpgkey 6C6191E3 –channel updates.spamassassin.org –nogpg –channel spamassassin.heinlein-support.de –updatedir /opt/zimbra/conf/spamassassin –allowplugins –refreshmirrors

    Wenn ich das so ausführe bekomme ich allerdings den Fehler:

    error: GPG validation failed!
    The update downloaded successfully, but it was not signed with a trusted GPG
    key. Instead, it was signed with the following keys:

    343F74FE

    Perhaps you need to import the channel’s GPG key? For example:

    wget http://spamassassin.apache.org/updates/GPG.KEY
    sa-update –import GPG.KEY

    Kann man einen GPG Key bei euch runterladen?

    Danke

    Benjamin

  24. Eric sagt:

    Hallo,

    wie kann man denn False Positives melden?

    Danke,
    Eric

  25. Christoph Lehmann sagt:

    Hallo,
    ich habe ein paar Fragen zu den Regeln,

    1. Werden die Regeln noch gepflegt?

    Es gab vor geraumer Zeit die Spam-Welle mit Banken und Telefonanbietern, in den Regeln finde ich hierzu nix…

    2. Wie häufig kommen neue hinzu?
    3. Werden „alte“ auch entfernt?
    3. Können Sie etwas zur Effektivität der Regeln erzählen?

    Gruß,
    Christoph Lehmann

  26. Hans sagt:

    hallo, ich verwende debian jessie auf Raspberry 2 und meine /etc/cron.daily/spamassassin sieht zur Zeit so aus :
    # Update
    umask 022
    env -i LANG=“$LANG“ PATH=“$PATH“ start-stop-daemon \
    –chuid debian-spamd:debian-spamd –start \
    –exec /usr/bin/sa-update — \
    –sa-update –nogpg –channel spamassassin.heinlein-support.de

    case $? in
    0)
    # got updates!
    env -i LANG=“$LANG“ PATH=“$PATH“ start-stop-daemon \
    –chuid debian-spamd:debian-spamd –start \
    –exec /usr/bin/spamassassin — –lint 2>&1 || 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

    da ich vollkommen neu bin in dieser Richtung, bin ich auch total überfragt, ob das nun so stimmen kann oder nicht.
    Würde mich sehr freuen, wenn ihr mir da weiter helfen könntet.
    Gruß Hans

  27. Ja, die Regeln werden noch gepflegt. Wir betreiben ja selber verschiedene Mail-Provider wie mailbox.org und pflegen für den Eigengebrauch unsere Regeln, mehr oder weniger täglich. Mal mehr, mal weniger, je nachdem, was sich so tut. In den den Regelsätzen sind einige Regeln bezügl. der Rechnungs-Viren drin, die das sehr gut und zielgerichtet erledigt haben. Wir haben am Ende von dieser Spam/Viren-Welle nichts mehr mitbekommen…

  28. Ich habe es jetzt nicht ausprobiert, sieht aber gut aus. Der Test dazu ist aber recht einfach: Wenn die Regeln unterhalb von /var/lib/spamassassin/… auftauchen, dann scheint es zu klappen. Zur Not einmal ablöschen, den Cron-Job abwarten und wieder nachschauen. :-)

  29. Pingback: Spamassassin Erkennungsrate verbessern mit mailbox.org Filtern

  30. Hans sagt:

    Super Sache. Vielen Dank.
    In welchem Logflie kann ich denn unter Ubuntu nachsehen, ob
    „sa-update –nogpg –channel spamassassin.heinlein-support.de“ per Cron erfolgreich gelaufen ist?

  31. Pingback: SpamAssassin Erkennungsrate (deutlich) verbessern | SYN-FLUT.de

Hinterlasse eine Antwort

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

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>