(Deutsch) SpamAssassin Erkennungsrate (deutlich) verbessern

Sorry, this entry is only available in German.

17 Comments on “(Deutsch) 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!

Leave a Reply

Your email address will not be published. Required fields are marked *