Kommentare zu: Kampf dem Spam https://archiv.rackblogger.de/2006/11/20/kampf-dem-spam/ We love to HOST you. :-) Mon, 15 Jun 2026 13:20:03 +0000 http://wordpress.org/?v=2.0.9 Von: Klaus Keppler https://archiv.rackblogger.de/2006/11/20/kampf-dem-spam/#comment-415 Fri, 24 Nov 2006 10:21:35 +0000 https://archiv.rackblogger.de/2006/11/20/kampf-dem-spam/#comment-415 Cool das man FuzzyOCR auch abhängig von der bisher erreichten Punktzahl starten kann... werde ich mir mittelfristig wohl auch mal anschauen. Auf Greylisting-Postfächern schlägt diese Art des Spam praktisch (noch) gar nicht auf, und die (Ressourcen-)Kosten für Greylisting sind sicherlich geringer als OCR. Aber für eine weitere Verschärfung sicher eine tolle Sache... Cool das man FuzzyOCR auch abhängig von der bisher erreichten Punktzahl starten kann… werde ich mir mittelfristig wohl auch mal anschauen.
Auf Greylisting-Postfächern schlägt diese Art des Spam praktisch (noch) gar nicht auf, und die (Ressourcen-)Kosten für Greylisting sind sicherlich geringer als OCR. Aber für eine weitere Verschärfung sicher eine tolle Sache…

]]> Von: nighthawk https://archiv.rackblogger.de/2006/11/20/kampf-dem-spam/#comment-401 Thu, 23 Nov 2006 00:42:55 +0000 https://archiv.rackblogger.de/2006/11/20/kampf-dem-spam/#comment-401 ich habe bei mir festgestellt, dass die bayes filter sehr gut auf diese gif spams anschlagen. die landen mittlerweile zuverlaessig in der "bayes >99%" kategorie. irgendwas gleichartiges das man mit blossem auge anscheinend nicht einfach so erkennen kann, muss also wohl dran sein. das fuzzyocr plugin fuer spamassassin (ich denke darum ging es hier) kann man so konfigurieren, dass es ueber einer gewissen bereits erreichten punktzahl gar nicht mehr anspringt - man koennte fuer >99% spam 6 (konservativ) oder 9 (etwas agressiver) punkte definieren und dem ocr ding sagen, es soll halt nur laufen wenn bislang unter 4 punkte angefallen sind. oder irgendwie sowas. ich weiss ja nicht wo sich die auslastung bislang so bewegt. aber eins kann ich sagen - das ocr plugin ist genial. wenn man die serverkapazitaeten frei hat, dann ist es derzeit zweifelsfrei das mittel der wahl gegen den bilderspam. die trefferquote ist mit nichts anderem zu erreichen. ich habe bei mir festgestellt, dass die bayes filter sehr gut auf diese gif spams anschlagen. die landen mittlerweile zuverlaessig in der “bayes >99%” kategorie. irgendwas gleichartiges das man mit blossem auge anscheinend nicht einfach so erkennen kann, muss also wohl dran sein.
das fuzzyocr plugin fuer spamassassin (ich denke darum ging es hier) kann man so konfigurieren, dass es ueber einer gewissen bereits erreichten punktzahl gar nicht mehr anspringt - man koennte fuer >99% spam 6 (konservativ) oder 9 (etwas agressiver) punkte definieren und dem ocr ding sagen, es soll halt nur laufen wenn bislang unter 4 punkte angefallen sind. oder irgendwie sowas. ich weiss ja nicht wo sich die auslastung bislang so bewegt.
aber eins kann ich sagen - das ocr plugin ist genial. wenn man die serverkapazitaeten frei hat, dann ist es derzeit zweifelsfrei das mittel der wahl gegen den bilderspam. die trefferquote ist mit nichts anderem zu erreichen.

]]> Von: Klaus Keppler https://archiv.rackblogger.de/2006/11/20/kampf-dem-spam/#comment-358 Mon, 20 Nov 2006 23:18:09 +0000 https://archiv.rackblogger.de/2006/11/20/kampf-dem-spam/#comment-358 Was die Ressourcen betrifft sitzt man als ISP leider wirklich am kürzeren Hebel. Ziel dieses manuellen Filters ist es aber ganz klar auch nicht, wirklich alle Spam-Mails zu filtern. Eine bescheidene Quote von sagen wir mal 20% wäre schonmal ein netter Anfang. Die Erfahrung ist wirklich so, dass bei großen Spamfluten seeehr viele quasi identische Mails aufschlagen. So wirklich zu schaffen machen in letzter Zeit aber wirklich die Mails mit völlig zufälligem Text-Inhalt und einem jeweils einmaligen (mit Zufallsmustern versehenem) GIF-Attachment, das den eigentlichen Werbetext enthält. Es gibt zwar selbst für so etwas schon Spam-Filter mit unscharfem OCR, aber das sprengt auf Dauer alle Kapazitäten... Zu den anderen Methoden: Geylisting: wird in Kürze aktiviert, ist eine feine Sache, zieht aber einen *erheblichen* Datenbank-Impact nach sich RBLs: nutzen wir schon lange, hält bereits ~80% aller SMTP-Verbindungen von uns ab... Logikprüfungen: schwierig, da wir einfach zu viele Kunden haben :-P (soll heißen, die Anforderungen wären zu unterschiedlich). Individualisierbare Bayes-Filter werden getestet, für weniger versierte Mail-User sind die aber leider recht "gefährlich" (bei Business-Kunden sind false positives seeehr unschön). MX-Priority: führt bei schlampingen Mailservern (Mikrosaft Austausch) gerne zu Problemen :-( Greylisting führt deutlich zuverlässiger zu einem ähnlichen Ergebnis. Das Problem ist und bleibt letztendlich die langsame aber sichere Professionalisierung der Spam-Absender, was meiner persönlichen Meinung nach früher oder später zu nicht mehr automatisch durchzuführender Spam-Erkennung führt. :-( Was die Ressourcen betrifft sitzt man als ISP leider wirklich am kürzeren Hebel. Ziel dieses manuellen Filters ist es aber ganz klar auch nicht, wirklich alle Spam-Mails zu filtern. Eine bescheidene Quote von sagen wir mal 20% wäre schonmal ein netter Anfang. Die Erfahrung ist wirklich so, dass bei großen Spamfluten seeehr viele quasi identische Mails aufschlagen.
So wirklich zu schaffen machen in letzter Zeit aber wirklich die Mails mit völlig zufälligem Text-Inhalt und einem jeweils einmaligen (mit Zufallsmustern versehenem) GIF-Attachment, das den eigentlichen Werbetext enthält. Es gibt zwar selbst für so etwas schon Spam-Filter mit unscharfem OCR, aber das sprengt auf Dauer alle Kapazitäten…

Zu den anderen Methoden:
Geylisting: wird in Kürze aktiviert, ist eine feine Sache, zieht aber einen *erheblichen* Datenbank-Impact nach sich
RBLs: nutzen wir schon lange, hält bereits ~80% aller SMTP-Verbindungen von uns ab…
Logikprüfungen: schwierig, da wir einfach zu viele Kunden haben :-P (soll heißen, die Anforderungen wären zu unterschiedlich). Individualisierbare Bayes-Filter werden getestet, für weniger versierte Mail-User sind die aber leider recht “gefährlich” (bei Business-Kunden sind false positives seeehr unschön).
MX-Priority: führt bei schlampingen Mailservern (Mikrosaft Austausch) gerne zu Problemen :-( Greylisting führt deutlich zuverlässiger zu einem ähnlichen Ergebnis.

Das Problem ist und bleibt letztendlich die langsame aber sichere Professionalisierung der Spam-Absender, was meiner persönlichen Meinung nach früher oder später zu nicht mehr automatisch durchzuführender Spam-Erkennung führt. :-(

]]> Von: nighthawk https://archiv.rackblogger.de/2006/11/20/kampf-dem-spam/#comment-357 Mon, 20 Nov 2006 23:07:27 +0000 https://archiv.rackblogger.de/2006/11/20/kampf-dem-spam/#comment-357 von diesen haendisch zu pflegenden listen sind wir mittlerweile schon wieder ab.. das geht so einfach nicht. die spammer haben endlos ressourcen und sie sind einem auch personenmaessig ueberlegen.. die koennen einen mit diesen listen am langen arm verhungern lassen. man kann sich die mails noch so genau angucken und beschliessen, dass man jetzt die tollsten schluesselwoerter zum filtern gefunden hat.. das dauert maximal bis zum naechsten morgen, da haben die sich irgendwelche anderen tollen pillen rausgesucht und man kommt in die firma und alle postfaecher sind wieder voll. greift denn sonst nichts? greylisting? rbls? irgendwelche logikpruefungen der headerzeilen? mal im dns als hoechsten und niedrigsten mx einen server angeben, der nur "connection refused" sendet? von diesen haendisch zu pflegenden listen sind wir mittlerweile schon wieder ab.. das geht so einfach nicht. die spammer haben endlos ressourcen und sie sind einem auch personenmaessig ueberlegen.. die koennen einen mit diesen listen am langen arm verhungern lassen.
man kann sich die mails noch so genau angucken und beschliessen, dass man jetzt die tollsten schluesselwoerter zum filtern gefunden hat.. das dauert maximal bis zum naechsten morgen, da haben die sich irgendwelche anderen tollen pillen rausgesucht und man kommt in die firma und alle postfaecher sind wieder voll.
greift denn sonst nichts? greylisting? rbls? irgendwelche logikpruefungen der headerzeilen? mal im dns als hoechsten und niedrigsten mx einen server angeben, der nur “connection refused” sendet?

]]>