8
Update- Der -vermeintliche- Grund für Spam-Assassins derzeitige Ohnmacht gegenüber Rechnungs-Spam
-Update ->Es sieht so aus, als wäre hier ein Konfigurationsfehler die Ursache, und nicht Spamassassin. Tipp somit wertlos 
Moin.
Zur Zeit kommt täglich pro Mann eine teilweise zweistellige Anzahl an Mails mit Rechnungen, die Viren enthalten oder solche downloaden wollen. Dies geht schon seit einiger Zeit, aber unser Spam-Assassin kommt irgendwie nicht wirklich nach, trotz Trainings der Filter.
Heute fiel dem zuständigen Kollegen dann auf, woran das liegt: sämtliche Mails dieser Art haben einen Base64-codierten Body, welchen Spam-Assassin schlicht nicht auswerten kann - zumindest derzeit noch. Man darf hoffen, dass er es bald lernt, denn die Mailprogramme können es ja auch lesen.
Moin.
Zur Zeit kommt täglich pro Mann eine teilweise zweistellige Anzahl an Mails mit Rechnungen, die Viren enthalten oder solche downloaden wollen. Dies geht schon seit einiger Zeit, aber unser Spam-Assassin kommt irgendwie nicht wirklich nach, trotz Trainings der Filter.
Heute fiel dem zuständigen Kollegen dann auf, woran das liegt: sämtliche Mails dieser Art haben einen Base64-codierten Body, welchen Spam-Assassin schlicht nicht auswerten kann - zumindest derzeit noch. Man darf hoffen, dass er es bald lernt, denn die Mailprogramme können es ja auch lesen.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 291096
Url: https://administrator.de/contentid/291096
Ausgedruckt am: 25.11.2024 um 15:11 Uhr
8 Kommentare
Neuester Kommentar
Kann ich so nicht bestätigen:
Das ist nur aussortiert worden, weil der GTUBE-Teststring im Mailbody enthalten ist. Und das kann Spamassassin nur herausgefunden haben, indem es in den Base64-Body hineingeschaut hat
Ich habe das zur Sicherheit auch mal mit einem älteren Spamassassin getestet - aber selbst mit dem, der unter Debian Squeeze dabei ist wurde das erkannt.
Delivered-To: spam-quarantine
X-Quarantine-ID: <k9gcAZOoykFT>
X-Spam-Flag: YES
X-Spam-Score: 999.58
X-Spam-Level: ****************************************************************
X-Spam-Status: Yes, score=999.58 tag=-99 tag2=5.3 kill=6.5
tests=[BAYES_00=-1.9, GTUBE=1000, MISSING_MID=0.497,
RDNS_DYNAMIC=0.982, TVD_SPACE_RATIO=0.001]
autolearn=no autolearn_force=no
X-policyd-weight: using cached result; rate: 7.15
Received: from t-ipconnect.de (p20030080x.dip0.t-ipconnect.de [IPv6:2003:80:x])
by mx0.301-moved.de (GrobiSuperMail) with ESMTP
for <x>; Thu, 17 Dec 2015 13:12:21 +0100 (CET)
To: <x>
From: Test <x>
Subject: TEST
Date: Thu, 17 Dec 2015 12:17:44 +0100
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
WEpTKkM0SkRCUUFETjEuTlNCTjMqMklETkVOKkdUVUJFLVNUQU5EQVJELUFOVEktVUJFLVRFU1Qt
RU1BSUwqQy4zNFg=Das ist nur aussortiert worden, weil der GTUBE-Teststring im Mailbody enthalten ist. Und das kann Spamassassin nur herausgefunden haben, indem es in den Base64-Body hineingeschaut hat
Ich habe das zur Sicherheit auch mal mit einem älteren Spamassassin getestet - aber selbst mit dem, der unter Debian Squeeze dabei ist wurde das erkannt.
Hallo,
wollte gerade diesbezüglich eine Frage stellen, da ich bisher weder hier noch im Internet etwas gefunden habe (oder falsch gesucht). Vor unserem Exchange 2013 ist ein Debian mit Postfix, Spamassins und Clamav vorgeschaltet. Bisher hat die Kiste immer alle "Rechnungen" und "Zahlungsaufforderungen" usw. wunderbar rausgefiltert. Seit ca. 2 Wochen bekomme ich aber von Exchange einen Haufen "Unzustellbar Nachrichten" das angeblich die Nachricht nicht weitergeleitet wird, da in der zip ein JS/Swabfex.E Virus/Trojaner gefunden wurde. Nur leider landen diese Mails trotzdem in die entsprechenden Postfächer.
Hat jemand ne Lösung, wie ich die Einsortierung in die Postfächer verhindern kann?
Gruß Opalka
wollte gerade diesbezüglich eine Frage stellen, da ich bisher weder hier noch im Internet etwas gefunden habe (oder falsch gesucht
). Vor unserem Exchange 2013 ist ein Debian mit Postfix, Spamassins und Clamav vorgeschaltet. Bisher hat die Kiste immer alle "Rechnungen" und "Zahlungsaufforderungen" usw. wunderbar rausgefiltert. Seit ca. 2 Wochen bekomme ich aber von Exchange einen Haufen "Unzustellbar Nachrichten" das angeblich die Nachricht nicht weitergeleitet wird, da in der zip ein JS/Swabfex.E Virus/Trojaner gefunden wurde. Nur leider landen diese Mails trotzdem in die entsprechenden Postfächer.Hat jemand ne Lösung, wie ich die Einsortierung in die Postfächer verhindern kann?
Gruß Opalka
Interessant. Ich gehe schwer davon aus, dass wir den neuesten haben, den es für unsere Linuxvariante gibt. Ich geb' das mal weiter, danke.
Das ist übrigens ein Header so einer Nachricht:
Received: from ExchangeSrv.XXXX.local (192.168.X.X) by
ExchangeSrv.XXXX.local (192.168.X.X) with Microsoft SMTP Server (TLS) id
15.0.1130.7 via Mailbox Transport; Wed, 16 Dec 2015 19:20:13 +0100
Received: from ExchangeSrv.XXXX.local (192.168.X.X) by
ExchangeSrv.XXXX.local (192.168.X.X) with Microsoft SMTP Server (TLS) id
15.0.1130.7; Wed, 16 Dec 2015 19:20:13 +0100
Received: from remote.XXXXX.de (192.168.X.X) by
ExchangeSrv.XXXX.local (192.168.X.X) with Microsoft SMTP Server id
15.0.1130.7 via Frontend Transport; Wed, 16 Dec 2015 19:20:13 +0100
Received: from localhost (localhost [127.0.0.1])
by remote.XXXX.de (Postfix) with ESMTP id AF51620C56
for <XXXX@XXXXXX.XX>; Wed, 16 Dec 2015 19:18:22 +0100 (CET)
X-Quarantine-ID: <nNPpC882-PoG>
X-Virus-Scanned: Debian amavisd-new at XXXX.XX
X-Spam-Flag: YES
X-Spam-Score: 22.489
X-Spam-Level: **********************
X-Spam-Status: Yes, score=22.489 tagged_above=-999 required=3
tests=[BAYES_99=3.5, BAYES_999=0.2, CK_HELO_DYNAMIC_SPLIT_IP=1.5,
FROM_EXCESS_BASE64=0.979, HELO_DYNAMIC_IPADDR2=3.607,
HTML_MESSAGE=0.001, PYZOR_CHECK=1.392, RCVD_IN_BL_SPAMCOP_NET=1.347,
RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_PBL=3.335, RCVD_IN_PSBL=2.7,
RCVD_IN_RP_RNBL=1.31, RCVD_IN_XBL=0.375, RDNS_NONE=0.793,
TVD_RCVD_IP=0.001] autolearn=spam
Received: from remote.XXXX.de ([127.0.0.1])
by localhost (websrv.XXXX.local [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id nNPpC882-PoG for <XXXX@XXXX.XX>;
Wed, 16 Dec 2015 19:18:18 +0100 (CET)
Received: from 190-49-216-75.speedy.com.ar (unknown [190.49.216.75])
by remote.XXXX.de (Postfix) with ESMTP id 9963920A10
for <XXXX@XXXX.XX>; Wed, 16 Dec 2015 19:18:17 +0100 (CET)
Message-ID: <3694070716.SIM_7482871EE335@XXXX.XX>
From: =?UTF-8?B?QWRlbGUgSGVhdGg=?= <HeathAdele6923@speedy.com.ar>
To: =?UTF-8?B?bG4uYmVzdGVsbHVuZw==?= <XXXXX@XXXX.XX>
Subject: ***SPAM***
=?UTF-8?B?WW91ciBhY2NvdW50IGhhcyBhIGRlYnQgYW5kIGlzIHBhc3QgZHVl?=
Date: Wed, 16 Dec 2015 15:20:07 -0300
Reply-To: =?UTF-8?B?bG4uYmVzdGVsbHVuZw==?= <XXXXX@XXXX.XX>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NexPart_002"
Return-Path: HeathAdele6923@speedy.com.ar
X-MS-Exchange-Organization-Network-Message-Id: fb2a70b9-56a1-4caa-d1b4-08d306458a39
X-MS-Exchange-Organization-AVStamp-Enterprise: 1.0
X-Auto-Response-Suppress: DR, OOF, AutoReply
X-MS-Exchange-Organization-AuthSource: ExchangeSrv.XXXX.local
X-MS-Exchange-Organization-AuthAs: Anonymous
Noja, Spamassassin hat sie als SPAM eingestuft und sogar sehr ordentlich Punkte dafür gegeben - da ist wohl die beste Strategie, entweder die Mail ab einem gewissen "Kill-Score" bereits am Eingang abzulehnen oder dann wenigstens getaggete Mails in die entsprechenden SPAM-Ordner zu verschieben.
Spamassassin kann bei mir auch nichts bewirken. Das meiste wird über verbotene Anhänge (exe, js und eventuelle Doppelendungen) und den Virenschutz entsorgt. Das meiste filtert der kostenlose Sophos für Linux aus. Teilweise sind aber auch sehr komische Anhangskombinationen dabei. Heute war es eine .pdf.js
doc-Dateien weg zu filtern wäre zwar möglich, würde aber sehr schnell zu einem Aufstand führen. Daher muss ich mich hier leider auf meine drei Virenscanner verlassen (ClamAV erkennt aber grundsätzlich nichts).
doc-Dateien weg zu filtern wäre zwar möglich, würde aber sehr schnell zu einem Aufstand führen. Daher muss ich mich hier leider auf meine drei Virenscanner verlassen (ClamAV erkennt aber grundsätzlich nichts).
Was hier bisher sehr gut gewirkt hat war die Kombination aus:
Insbesondere die SPF- und DMARC-Checks haben die beiden Wellen von @dertour.de und @bergmann-soehne.de sehr zuverlässig zurückgehalten.
Und DMARC sollte man sowieso prüfen um die ganzen schlecht gemachten eBay- und Paypal-Phishing-Mails direkt zu verweigern.
- SPF- und DMARC-Check mit SpamAssassin / Amavis
- Server mit inkonsistenten PTRs direkt verjagen
Insbesondere die SPF- und DMARC-Checks haben die beiden Wellen von @dertour.de und @bergmann-soehne.de sehr zuverlässig zurückgehalten.
Und DMARC sollte man sowieso prüfen um die ganzen schlecht gemachten eBay- und Paypal-Phishing-Mails direkt zu verweigern.
Ich kann mittlerweile weitergeben, dass LordGurke Recht hat und somit mein Tipp recht wertlos ist.
Mein Kollege hat einen Konfigurationsfehler eingeräumt (den er nun finden und beheben will), denn geblacklistete, base-64-codierte Teststrings werden nicht wie bei LordGurke erkannt.
Vielen Dank für den Hinweis.
Mein Kollege hat einen Konfigurationsfehler eingeräumt (den er nun finden und beheben will), denn geblacklistete, base-64-codierte Teststrings werden nicht wie bei LordGurke erkannt.
Vielen Dank für den Hinweis.
