Aktuelle SpamAssassin-Regeln von Heinlein Support
Auf 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.
Weitere Beiträge zum Thema
Enterprise Mail-Security mit Open-Source?
Enterprise Mail Security with Open Source?
Kommentare
64 Antworten zu Aktuelle SpamAssassin-Regeln von Heinlein Support
Danke. :-)
Ein Hinweis zu Debian Wheezy.
Dort sieht der Aufruf in Zeile 62 von /etc/cron.daily/spamassassin so aus:
<code>su debian-spamd -c "sa-update --gpghomedir /var/lib/spamassassin/sa-update-keys"</code>
Man sollte also auch diese Regeln mit dem User "debian-spamd" aktualisieren, um die Form (und die Rechte) zu wahren:
<code>su debian-spamd -c "sa-update --nogpg --channel spamassassin.heinlein-support.de"</code>
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
Du scheinst nicht verstanden zu haben, dass man `sa-update` nur einmal aufrufen muss, da die Standard-Regeln immer mit geladen werdem. Der Parameter `--channel` kann beliebig oft benutzt werden, um zusätzliche Quellen anzugeben, wobei die Standard-Quelle aber schon implizit mit dabei ist.
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.
<code>
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
</code>
Viele Grüße
Chris
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
[…] ← Aktuelle SpamAssassin-Regeln von Heinlein Support […]
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.
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!
Coole Sache... war meine Idee vor einiger Zeit ja gar nicht sooo dumm :-)
Danke dafür...
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...)
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
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
Ja. So machen tun:
/usr/sbin/amavisd-new reload &> /dev/null
Danke, Dubletten sind gefixt!
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...
Das Update der SpamAssassin-Regeln hat nichts mit einem Reload von Amavis zu tun. Schau ins Logfile, da werden Hinweise stehen.
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 :-)
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).
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.
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
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
Ja, unsere Regeln tauchen bei den SpamAssassin-Treffern dann immer mit "HS_" (=Heinlein Support) als Prefix auf.
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
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
Hallo,
wie kann man denn False Positives melden?
Danke,
Eric
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
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
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...
Einfach direkt an mail@heinlein-support.de.
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. :-)
Ich habe einen aktuellen Debianserver mit Spamassassin und kann bestätigen, dass ein
–sa-update –nogpg –channel spamassassin.heinlein-support.de
in der
etc/cron.daily/spamassassin
NICHT funktoniert, während das normale sa-update per cron sehr gut funktoniert.
Führe ich den Befehl wiederrum im Terminal aus, klappt es. Hat da jemand eine befriedigende Lösung parat?
[…] Von Heinlein Support gibt es hier weitere Infos und eine Anleitung: https://www.heinlein-support.de/blog/news/aktuelle-spamassassin-regeln-… […]
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?
Vielen Dank für das Bereitstellen der Filterregeln.
Kann man euch für diesen tollen Service eine Unterstützung zukommen lassen so kurz vor Weihnachten?
Gruß und eine schöne Zeit
Sebastian
Vielen lieben Dank! War schon fast am Verzweifeln vernünftige Regeln nachzubauen.
[…] Heinlein von Heinlein Support ist der Mann hinter mailbox.org – einem sicherlich nicht ganz unbekannten E-Mail Anbieter. […]
Werden die Regeln noch aktualisiert, bzw. sind die hier beschrieben Infos noch aktuell?
[…] heinlein-support.de […]
Ich als Linuxfrischling habe das sa-update auf einem Ubuntu zum Laufen bekommen.
Die Regeln werden geladen (/var/lib/spamassassin//*) und täglich aktualisiert.
Den Spamassassin habe ich über die Pleskoberfläche neugestartet.
Bisher habe ich im /var/log/maillog keine Einträge mit "HS_" gefunden.
Muss ich noch etwas machen, damit die Regeln auch vom Spamassassin beachtet werden?
Stand 2017/18 Debian 9.2
# 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 -- \
--nogpg --channel spamassassin.heinlein-support.de 2>&1
geht - aber
da die Kiste nur 512 MB hat gibt es
+ env -i LANG=de_DE.UTF-8 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin http_proxy= start-stop-daemon --chuid debian-spamd:debian-spamd --start --exec /usr/bin/sa-update -- --nogpg --channel spamassassin.heinlein-support.de
spawning /usr/bin/curl failed: Cannot allocate memory at /usr/bin/sa-update line 1520.
[…] Heinlein von Heinlein Support ist der Mann hinter mailbox.org – einem sicherlich nicht ganz unbekannten E-Mail Anbieter. […]
@Peer
SHELL und PATH variablen in cron-script gesetzt? Ansonsten absolute Pfade versuchen.
[…] catch ninety percent of all SPAM with there ruleset. Another excellent ruleset is available from Heinlein-Support (german). But. I’ve some special SPAM for health ensurance advertising and so on. So I’ll show a […]
Hallo,
wie kann ich denn eure Regeln in Verbindung mit Plesk verwenden, sodass diese auch automatisch geupdatet werden? Plesk deaktiviert ja den Standard Spamassassian Cron und nutzt dafür etwas eigenes. Ich habe nun schon den ganzen Abend gesucht, aber leider keinerlei richtig bzw. offizielle Dokumentation für Plesk gefunden.
Zudem wird in einem Foren Artikel von Plesk auch geschrieben, dass ich die Liste vorab noch mit sa-compile entsprechend compilen soll, aber ist dies dann immer nötig? Oder was hat das ganze auf sich?
Kannst du mir sagen, wie ich es am besten einrichte, sodass die Liste auch regelmäßig aktualisiert wird?
Gruß Lukas
Auch wenn Roberts Kommentar schon zwei Jahre her ist, stellt sich mir ebenfalls die Frage.
Wird die noch gepflegt?
Hallo Team Heinlein,
habt Ihr vielleicht auch eine entsprechende hs_headers.map-Datei für rspamd? Oder gibt es irgendwo ein Script, welches Maps aus SA-Rules baut? Ich möchte ungern das SA-Modul von rspamd benutzen.
Liebe Grüße und bis spätestens zur nächsten SLAC
Marc
Es funktioniert gut. Allerdings komme ich mit dem Cronjob unter stretch nicht klar. Oben angegebene Zeile gibt es nicht, sondern lediglich diese hier:
# 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
Liege ich damit richtig das dann wie folgt zu ergänzen?
env -i LANG="$LANG" PATH="$PATH" http_proxy="$http_proxy" \
start-stop-daemon --chuid debian-spamd:debian-spamd --start \
--exec /usr/bin/sa-update -- \
--nogpg --channel spamassassin.heinlein-support.de 2>&1
Eventuell dann noch die Abfrage von Florian dazu:
...
# 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
retcode1=$?
env -i LANG="$LANG" PATH="$PATH" http_proxy="$http_proxy" \
start-stop-daemon --chuid debian-spamd:debian-spamd --start \
--exec /usr/bin/sa-update -- \
--nogpg --channel spamassassin.heinlein-support.de 2>&1
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!
...
Wir arbeiten dran die Regelsätze nativ für rspamd bereitzustellen.
Ja, wir pflegen die Dateien noch, es gibt alle paar Tage oder sogar täglich Updates. Mal mehr, mal weniger.
Hallo Team Heinlein,
gibt es eine Möglichkeit, dass Sie Ihren Channel signieren und den KEY zur Verfügung stellen?
Das update-script unter CentOS benötigt eine Signierung.
Viele Grüße
Hans