SPAM-Kampf

LeoLinux

LeoLinux

Well-Known Member
Ich bin gerade damit beschäftigt meinem Mailserversystem Viren- und SPAM-Schutz zu verleihen.

Dabei bin ich aber noch auf das ein oder andere Verständnisproblem gestoßen das sich hier vielleicht aufklären liese ...


Also, es gibt ja X - verschiedene Kombinationen von Lösungen ... am meisten bin ich bei meinen Recherchen über SpamAssasin gestolpert. Dann habe ich da noch von Amavisd gelesen, Razor, Pyzor, Fuzzy-OCR, DCC ... was für Aufgabenbereiche den einzelnen Tools zugewiesen werden kann lies sich auf deren Projektwebsite relativ fix herausfinden ...

... außer bei SpamAssassin - da hänge ich bis heute in der Luft.

Wenn ich Spam Assassin installiere, dann installiert sich z.B. automatisch schon razor-agents mit ... etc. .. demnach war meine erste Schlussfolgerung, dass SpamAssassin eine Art Toolbox ist, welche mit Modulen ausgestattet werden kann ... Modulen wie z.B. Razor, Pyzor ... etc. - ist das richtig?


Grüße
 
Jein.
Spamassassin ist ein Scoringsystem und bietet auch Schnittstellen zu den Prüfsummenchacks an. Es ist aber keine reine Schnittstelle dafür und auch kein reines Scoringsystem. Es arbeitet mit eigenen regulären Ausdrücken, und nem lernbaren Bayesfilter. Diese Sachen sind das Kernstück und auch direkt im Kerhn enthalten. Die von dir genannten Dinge können halt simpel in das Scoring mit einbezogen werden.

Der Clou ist also, dass es sich nicht auf ein Kriterium alleine verlässt. Wenn einer der von dir genannten Prüfsummen-basierten Filter sagt, dass das Spam ist, dann verteilt SpamAssassin erstmal nur nen Score. Dieser kann aber auf Grund anderer Kriterien wieder schwinden, wodurch die Gefahr von false positives stark gesenkt wird
 
Danke für deine Antwort - war fürs Erste sehr hilfreich.

Es arbeitet mit eigenen regulären Ausdrücken
Zum Vergrößern anklicken....
Wie ist das zu verstehen? Hat SpamAssassin Zugriff auf ein ?online? Dictionary?


Grüße
 
Zuletzt bearbeitet:
SpamAssassin ist sehr mächtig. Hast du wir mal das Wiki angesehen? Das ist ziemlich umfangreich und es werden so gut wie alle Fragen beantwortet.
 
Die beste Maßnahme beim Kampf gegen Spam ist, die Mails erst gar nicht anzunehmen, statt sie nachher mühsam zu filtern. Dies funktioniert meiner Erfahrung nach am besten mit RBL-Listen z.B. von spamhaus.org (zen.spamhaus.org).

QMail und Postfix haben die Unterstützung für RBL schon eingebaut, muss man eigentlich nur konfigurieren. Damit werden schon 99% aller Spams vor dem eigentlichen Empfang abgeblockt, weil die ganzen Zombie/Botnetz-Rechner und Spammer auf der schwarzen Liste stehen.

Wenn man nun zusätzlich die bordeigenen Checks der Mailserver etwas schärfer einstellt, wie z.B. Rückwärts-DNS-Abfrage auf den Absender und Prüfung auf MX-Einträge, kommt so gut wie nichts mehr an, was noch gefiltert werden müsste.

Natürlich schadet ein zusätzlicher Spamassassin nicht, aber als alleinige Lösung nicht zu gebrauchen, weil sich die reine Muster-Erkennung zu leicht aushebeln lässt:
- So oft, wie sich die Muster der Spammer ändern, kommt man mit dem Nachlernen nicht mehr nach
- die Spammer werden auch immer schlauer und "vergiften" ihre Mails mit Wörterbuch-Auszügen, Gedichten, zufälligen Google-News usw.; wenn man die dann per Spamassassin anlernt, bekommt man eine hohe False-Positive-Erkennung

Also kurz, auf Spamassassin alleine würde ich mich nicht verlassen, lieber auf RBL-Listen oder Systeme wie Razor zurückgreifen - wesentlich effizienter, sehr zuverlässig und ressourcensparend.

Edit: Habe bei mehreren FreeBSD-Servern Postfix (mit RBL)+amavisd (Port amavisd-new) im Einsatz und kann es weiterempfehlen: amavis kümmert sich dabei um die Integration von Spamassasin und Virenscanner (standard ClamAV, aber beliebige Virenscanner einbindbar).

Funktionsweise: Postfix liefert einfach alle Mails, die er noch annimmt nach RBL-Check, über einen Socket an amavisd weiter, welcher sich dann um Spamassasin und Virenscan kümmert.
Ist insofern bequem, da man alles zentral in der amavisd.conf stehen hat und sich nicht um die Einbindung von jedem einzelnen Scanner, Filter usw. kümmern muss.
 
Zuletzt bearbeitet:
Also ich rate stark davon ab RBLs zum direkten Blocken von Spam zu verwenden. Vor allem Spamhaus. Viele von denen arbeiten mit Willkür. Habe schon so einiges erlebt mit denen. Sowohl als Sender, als auch als Empfänger von Mails. Die scheinen die halbe Welt zum Feind haben. Ich blocke zwar auch Nachrichten, aber nur, wenn ich wirklich sicher sein kann, dass es Spam ist.

Razor verwende ich auch und zwar als Plugin von SA. Ich habe auch dafür gesorgt, dass mein spam-learn-Verzeichnis nicht nur SA, sondern auch Razor füttert. Man kan so ziemlich schnell auf 0.0001 false positives und auf unter 1% false negatives kommen. Ab und an trifft mich noch SPAM, der ganz neu ist und für scheinbar auch sehr ineffizient gesendet wird. Dürfte sich um Leute handeln, die sich auch mal als Spammer versuchen wollen.
 
Ich schliesse mich Athaba an. Bei den RBLs gibts ne Menge false positives.
Eine sehr gute Möglichkeit, um Spam schon vor der Tür draussen zu lassen ist graylisting. Bisher keine Probleme mit false positives, jedes annähernd moderne Mailsystem probierts nach einiger Zeit erneut, das Spamaufkommen und CPU-Last sind um ca 70% zurückgegangen.
 
Ich bin vollkommen zufrieden mit mail/dspam, allerdings brauchts da schon ne ganze Ladung an Mails, um dspam zu trainieren. Wenns dann aber mal läuft, ists total geil:

Korrekt ausgefiltert: 97.666%
False positives: 0.039%
 
Ich bin vollkommen zufrieden mit mail/dspam, allerdings brauchts da schon ne ganze Ladung an Mails, um dspam zu trainieren. Wenns dann aber mal läuft, ists total geil:
Zum Vergrößern anklicken....

Auch sehr interessant!

hier ... hab ich mal auf die Schnelle gefunden:


http://www.freesoftwaremagazine.com/articles/focus_spam_dspam?page=0,3
http://gentoo-wiki.com/HOWTO_Spam_Filtering_with_DSPAM_and_Postfix#Identi ty_Crisis
http://www.kirya.net/articles/setting-up-dspam-as-a-filter-for-postfix-on-debian-sarge/
http://dspamwiki.expass.de/
http://dspamwiki.expass.de/Installation/Postfix/NealesSetup
 
Willst Du oder musst Du die Mailverarbeitung inhouse machen?

Wir sind ne kleine Firma und ich muss gestehen, ich habe auch lange Zeit an der inhouse Verarbeitung unserer Mails festgehalten. Und das lief auch ganz gut. Aber vor ca. 3 Jahren wurde das schlagartig immer schlechter mit der Spamerkennung und -filterung. Die Klagen wurden immer lauter und ich hatte keine Lust mehr darauf und auch nicht auf das ständige Hinterherhinken bei der Anpassung des Systems.

Ich habe mich dann entschieden, das ganze Mailgedöns an unseren lokalen Provider unseres Vertrauens auszulagern. Auch wenn Eigenlob stinkt, aber das war eine meiner besten Entscheidungen, die je getroffen habe.
Ich habe nun mehr zeit für die wirklich wichtigen Dinge und auch die Erkennngsraten sind deutlich besser geworden, sowohl von Spam als auch false positivs.

Denk mal darüber nach, ob Du nicht auch die Mailverarbeitung an einen externen Dienstleister auslagerst.

Gruß c.
 
Ich verstehe und respektiere deine Entscheidung, aber das kommt für mich nicht in Frage - bei mir führt aus dem Projekt heraus kein Weg daran vorbei das SPAM Problem selbst in die Hand zu nehmen. Das ist auch gut so - auch wenn es mit entsprechendem Aufwand verbunden sein wird.
Es gilt nun nur die beste Softwarekombination & Strategie zu wählen - und das Austauschen von Erfahrungen das beste Mittel um mir eine effiziente Grundlage zu schaffen.
 
troll schrieb:
Ich schliesse mich Athaba an. Bei den RBLs gibts ne Menge false positives.
Zum Vergrößern anklicken....

Kann ich so überhaupt nicht bestätigen. Seit über 4 Jahren habe ich RBL für mehrere Mailserver mit Dutzenden von Domains im Einsatz, auch unsere eigener Firmen-Mailserver läuft damit.
In diesen 4 Jahren habe ich *nicht eine* Beschwerde gehabt, dass Mails nicht angekommen wären.

Kommt natürlich darauf an, wie und was man als Spam(mer) definiert und in welchem Umfeld man die RBLs einsetzt.

Bei Home-Servern, dyndns-Geschichten oder Fritz-Boxen wird die RBL-Geschichte nie recht funktionieren, grade bei spamhaus, da dort fast alle Adressbereiche mit dynamischen IPs gelistet sind (was meiner Meinung nach auch Sinn macht). Hat man dagegen dedizierte, sauber konfigurierte Mailserver, dann sind Blacklists eine scharfe Waffe.

Wenn man sich die Header der Spam-Mails genauer anschaut und mal durchleuchtet, über welche Wege die Mail gegangen ist, dann sind dort zu fast 100% IPs drauf, die nun mal zu bekannten Spammernetzen gehören. Oder sie kommen direkt aus so einem Netz.

Wenn ich eine Mail von "newsletter@golem.de" bekomme, der liefernde Mail-Server aber per Reverse-Lookup ein "*.dip.t-dialin.net" oder "xyz.bigdaddy.com" ist, dann ist das für mich Spam, Inhalt egal, Verbindung wird gedroppt.

Und genau das bekommt man über RBLs (und eine gute Mailserver-Config) gut in den Griff.

Ist natürlich Geschmackssache, wie rigoros man da vorgehen möchte, aber ich vertrete da halt die Null-Toleranz-Politik:
Wer bei einem meiner Mail-Server eine Mail abliefern will, dessen Absender-IP nicht der MX der zugehörigen Absender-Email-Domain ist, eine HELO-Meldung mit KATHRIN17 als Rechnername absetzt, eine dynamische IP hat, usw. und so fort, der ist für mich ein Spammer und wird geblockt.

Und wer das dann innerhalb von ein paar Minuten auch noch 100x versucht, bekommt per fail2ban noch einen Tag Pause verordnet, aber das ist nochmal eine andere Geschichte...

edit:

troll schrieb:
Spamaufkommen und CPU-Last sind um ca 70% zurückgegangen
Zum Vergrößern anklicken....
Mit RBL: Ein Server mit 28 Domains und ca. 25.000 (Spam)-Mails/Tag hat eine SpamQuota von ca. 5 Spams/Domain/Tag und unter 1% CPU-Last. Und keiner der 28 Kunden hat irgendein Problem...

Auch auf meinem privaten Server bekomme ich ca. 30.000 Spams/Monat, also ca. 1000 am Tag, davon kommen auch höchstens 2-3 durch. Und die werden dann von Spamassassin gut erkannt, ich habe vermisse bis heute nicht eine Mail...
 
Zuletzt bearbeitet:
Ich habe auch die Spamhaus RBLs auf 3 Servern im Einsatz und absolut keine Probleme mit denen.

Außerdem kann ich auch besonders "nixspam" (http://www.dnsbl.manitu.net/) empfehlen!

z.Zt. blocken die beiden Blacklists ca. 25000 SPAMs pro Tag.
Den Rest erledigen strikte SMTP Regeln und Spamassassin.

postfix/amavisd-new/spamassassin/cyrus-imapd
 
Schon ein einfacher Offline-Spam-Filter gibt gute Ergebnisse. Hier sind Mails pro Monat. Nach Kategorien. Spam-Filter ist bogofilter, nix Online-Checking!

Wobei:
- Mailinglisten enthalten NUR Hams (da filtere ich nichts und es wird nichts gerechnet, außer dass es eine ML-Mail ist)
- Anzahl der Mails, die nicht aus den MLs kommen ist Hams minus ML-Mails

Aber schaut mal wo sich False-Positives/Negatives alle befinden. Ganz weit unten. Bei Spams sieht man wie effektiv die Lernphase ist. Es gibt manchmal einen Spike (neue beworbene Artikel, andere Taktiken...) und kurz darauf dämpft der Spam-Filter das fast auf 0 ab.

Ich filtere nichts vor. Ich sammle alle Spam-Mails, damit ich den Spam-Filter lernen lassen kann.

mailplot.png


Intepretation:
- ca 3% sind also Spams in meiner INBOX
- ungefähr 0,2% Hams landen in der Spam-Box
- Spam zu Ham Verhältnis ist etwa 1 zu 1 im Schnitt

Und ich muss hinzufügen, dass ich eine ziemlich wilde Konfiguration habe, die die Statistik unnötig schlecht macht.
 
Zuletzt bearbeitet:
troll schrieb:
Ich schliesse mich Athaba an. Bei den RBLs gibts ne Menge false positives.
Eine sehr gute Möglichkeit, um Spam schon vor der Tür draussen zu lassen ist graylisting. Bisher keine Probleme mit false positives, jedes annähernd moderne Mailsystem probierts nach einiger Zeit erneut, das Spamaufkommen und CPU-Last sind um ca 70% zurückgegangen.
Zum Vergrößern anklicken....

Kann ich bestätigen. Ich nutze ausschliesslich Greylisting, wobei die Bedingung von den RBLs kommt. Die Mails werden direkt abgelehnt, damit hat der Sender im Fall der Fälle die Möglichkeit, den Fehler zu sehen und zu behandeln. Ist aber noch nie vorgekommen. Der Rest an Spam, der durchkommt ist nicht der Rede wert.
 
Ich muss gestehen, dass ich nun etwas verwirrt bin und nicht wirklich sicher bin was nun letztendlich besser für mich sein soll.

Wenn ich zu Bayeschen Filtern die Begeisterung so lese und zudem noch, dass einige zuvor auch mit SpamAssasin gearbeitet haben, dann tendiere ich wiederum schon eher zu dieser Strategie... ABER Fakt ist, dass ich es meinen Benutzern auf keinen Fall zumuten will und auch nicht kann, dass diese Ihr gewünschtes SPAM Verhalten dem Filter ersteinmal antrainieren müssen bevor diese ihre Mailbox ordentlich nutzen können ... das ist uncool. Es muss bereits gewährleistet sein, dass sogut wie nichts mehr durchkommt .. und der wenige Rest der es schaffen sollte, den sollen die Benutzer dann via Dovecot-SPAM-Modul ausortieren können - dieses DoveCot Module trainiert das dann auch gleich dem SpamAssassin an - was eigentlich ziemlich cool ist - da meine Benutzer sowieso mit IMAP arbeiten werden ist das auch kein Problem - und meiner Meinung nach auch wesentlich "einfacher" zu vermitteln und zu merken, als wenn man die false negative an eine "SPAM-train" eMail Adresse forwarden müsste ...
 
Zuletzt bearbeitet:
RBLs kann man schon nutzen, aber nicht, um direkt zu blocken. Mir gefällt das Konzept hinter policyd-weight ziemlich gut - hier werden Scores für die Präsenz auf RBLs vergeben. Für windige RBLs wie Spamhaus halt ein paar weniger Punkte, für seriöse ein paar mehr. Ab einer gewissen Schwelle wird dann geblockt - jemand, der auf 10 RBLs gelistet ist, ist wahrscheinlich kein false positive ;)
 
LeoLinux schrieb:
Wenn ich zu Bayeschen Filtern die Begeisterung so lese und zudem noch, dass einige zuvor auch mit SpamAssasin gearbeitet haben, dann tendiere ich wiederum schon eher zu dieser Strategie... ABER Fakt ist, dass ich es meinen Benutzern auf keinen Fall zumuten will und auch nicht kann, dass diese Ihr gewünschtes SPAM Verhalten dem Filter ersteinmal antrainieren müssen bevor diese ihre Mailbox ordentlich nutzen können ... das ist uncool.
Zum Vergrößern anklicken....

Das musst du auch nicht. Du kannst global für alle filtern. Sprich du fütterst sa einmal mit nem Satz Spammails, der Rest passiert von selbst.

Noch etwas zu den RBLs: Sie können zu einem juristischen Problem werden, wenn du jemandem die Mails einfach wegblockst. Anders als bei Graylisting werden die stumpf abgelehnt - auch bei Wiederholung.
 
Moin LeoLinux,

LeoLinux schrieb:
ABER Fakt ist, dass ich es meinen Benutzern auf keinen Fall zumuten will und auch nicht kann, dass diese Ihr gewünschtes SPAM Verhalten dem Filter ersteinmal antrainieren müssen bevor diese ihre Mailbox ordentlich nutzen können ... das ist uncool.
Zum Vergrößern anklicken....

persönlich und auch in unserer Firma habe ich die Erfahrung gemacht, dass die SpamAssassin-Geschichte auch ohne Training schon sehr gut funktioniert. Damit die User die Filter trainieren können, würde ich einen Spam-Account einrichten, an den jeder User sein Spam schicken kann.
Das habe wir in der Firma und auch bei einigen Kunden so eingerichtet. Das kommt bei den Usern sehr gut an, weil jeder SELBER entscheiden kann, was Spam ist und was nicht.

Viele Grüße

JueDan
 
Mit dem Training ist das aber so eine Sache. Vor allem, wenn es User gibt, die da Newsletter reintun, die sie nicht mehr wollen. Dann landen sie auch bei den Anderen im Spam. Eine größere Gruppe von Usern führt da zu jeder Menge false positives. Es kommt eben darauf an, was man den Usern zumuten kann oder will.
 
troll schrieb:
Noch etwas zu den RBLs: Sie können zu einem juristischen Problem werden, wenn du jemandem die Mails einfach wegblockst. Anders als bei Graylisting werden die stumpf abgelehnt - auch bei Wiederholung.
Zum Vergrößern anklicken....

Blocken ist in Ordnung, solange das im SMTP-Dialog geschieht (Abbruch mit einer 500er Meldung). Dann ist der Sender darüber informiert, dass seine Mail nicht zugestellt werden konnte. IANAL, aber soweit ich das in den letzten Jahren mitbekommen habe, wird so etwas von deutschen Gerichten nicht als unzulässiger Eingriff in das Postgeheimnis gewertet und auch nicht als unrechtmäßige Sendungsunterschlagung.

Anders sieht es freilich aus, wenn ein Mailserver nach erfolgreich abgeschlossenem SMTP-Dialog mit der einliefernden Stelle entscheidet, die Mail nicht zuzustellen (z. B. aufgrund der Bewertung eines Bayes-Filters o. ä.). Hat man dazu nicht die schriftliche Einwilligung des Postfach-Inhabers, macht man sich als Postmaster strafbar.
 
Ogion, ich meine etwas anders: Der Kunde hat den Service gekauft und ein Recht darauf seine Mails zu erhalten. Egal, ob Spam, oder nicht. Er kann auf Vertragserfüllung pochen.
 
... Ich muss gestehen, dass ich noch gar nicht an all die möglichen rechtlichen Proleme gedacht habe.
Das ist sehr interessant!
 
Natürlich kann der Kunde auf Vertragserfüllung pochen - da ist aber einfach die Frage, was im Vertrag bzw. den AGB drinsteht. Da durch Rejecten im Annahmedialog keine anderen gesetzlichen Vorschriften berührt sind, greift hier die Vertragsfreiheit. Im übrigen halte ich es für wichtig, eine entsprechende Klausel in den AGB zu haben - es kann ja auch andere (technische) Gründe geben, aus denen eine Mail nicht angenommen wird bzw. der Annahmedialog abbricht (Wartungsarbeiten, Netzwerkstörung, Fehler bei der Gegenseite, ...)
 
... Bei meiner weiteren Konfiguration meines MailSystems ist mir eine weitere Frage aufgekommen:

... wenn ich das soweit richtig verstanden habe (speaking under correction), dann kann ich SpamAssassin über zwei generelle Wege involvieren:



1) smtp leitet die Mail an AmaVis weiter (was generell über Port 10024 läuft). Amavis scannt dann nach Viren und ruft anschließend SpamAssassin zur weiteren Filterzwecken auf. Danach wird die Mail zum weiteren Verfahren von AmaVis wieder über reinject, Port 10025, eingespeist.

2) smtp leitet die Mail an AmaVis Daeomon für den AntiVirusScan. Danach wird die Mail wieder über 10025 zum weiteren Verfahren eingespeist. Danach wird die Mail von smtp an spamd (SpamAssassin) eingespeist und von dort aus wieder zurück an den smtp




Nun zum eigentlich Kern meiner Frage:
In Fall 1) läuft AmaVis als Daemon - und SpamAssassin nicht - sondern wird nur bei Bedarf aufgerufen.
In Fall 2) läuft AmaVis als auch SpamAssassin als Daemon.

1: habe ich das System richtig verstanden?
2: Wann macht welche Lösung Sinn?
Meine Vermutung tendiert dazu, dass nur Sinn macht beides als Daemon laufen zu lassen, wenn _viele_ Mails durch das System saußen ... - richtig?

3: Wenn ich an spätere Optimierung meines MailSystems denke wäre es mir ein Dorn im Auge, wenn ich mit einer der beiden Varianten weniger Konfigurations / Filtermöglichkeiten hätte als mit der Anderen - was ich aber bezweifle - richtig?



Vielen Dank im Vorraus & Grüße
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben