Plugin-Idee: Bad-Recipient-Filter

Haben Sie eine tolle Idee für eine neue Plugin-Funktion oder ein neues Plugin?

Moderator: Forum-Team

Plugin-Idee: Bad-Recipient-Filter

Beitragvon Quellcore » 6. Jul 2006, 15:50

Halo Allerseits,
vornehmlich natürlich an Chactory und Anbuva, die in ihrer Schreibwut in den letzten Monaten ja kaum zu bremsen waren.
Leider ist es in der jüngsten Vergangenheit ja recht ruhig in der Plugin-Szene geworden. Unsere Dauerbrenner Edy Hinzen, Bob, Sebastian etc... sind in den Weiten des WorldWideWeb untergetaucht.

Nichtsdestotrotz habe ich da noch mal eine Plugin-Idee:
Es geht um die Empfänger E-mail Adresse(n).
Folgende Plugins beschäftigen sich schon damit: Adresse-Filter, Air-Filter, Mandatory-String-Filter, im weitesten Sinne auch der X-Header-Filter.

Ich habe in den letzten Monaten alle(!) erhaltenen Spammails bzgl. der Empfängeradresse untersucht.

Dabei habe ich beobachten können, daß nachwievor sehr viele Mails nicht an mich adressiert sind und sich die Empfängeradressen der Spammails oft wiederholen.

Ich habe damals an der Diskussion zu Sebastians Mandatory-String-Filter teilgenommen, bin aber aufgrund der falsch-positiv Filterungen, die sich aus der Blindkopie-Problematik ergiben, nicht zufrieden. Gleiches dürfte dann auch für den Adressee-Filter gelten.

So habe ich mir wochenlang mal die Mühe gemacht, diese 'schlechten' Empfänger manuell in den Substringfilter einzutragen.
Vorher habe ich das gleiche mit dem X-Header-Filter gemacht, der stürzt nur leider so häufig täglich ab, daß er sich komplett disqualifiziert.
Mit dem Ergebnis bin ich sehr zufrieden, nur mit dem Aufwand natürlich nicht! ;-)

Ein lernender Filter im Stile des URL-Filters, der sich nur um den Header einer Mail kümmert und dort nur die Empfängeradressen betrachtet, wäre da wohl das perfekte Plugin für meinen Fall. Dabei müßte durch das Lernen eine Blacklist und eine Greylist gepflegt werden.

Hier noch mal einen Überblick zum möglichen Arbeitsablauf so eines Filters.

Code: Alles auswählen
Scan-Process
************
scan Header data for recipient
check if one of the recipients is in the greylist  >>> proceed with next filter process >>> unsure
check if one of the recipients is in the blacklist >>> filter process gets cancelled    >>> classifiy mail as spam

Learning-Process
****************
learned as Non-Spam >>> check if recipient is in blackilist >>> if TRUE, move entry from blacklist to greylist
                    >>> check if recipient is in greylist   >>> if FALSE, add recipient to greylist
learned as Spam     >>> check if recipient is in greylist   >>> if TRUE, cancel learning process
                    >>> check if recipient is blackilist    >>> if FALSE, add recipient to blacklist


Eine Idee für den Namen des Filters hätte ich auch schon: Bad-Recipient-Filter

Anregungen, Aufregungen, Feedback, Programmierwut, etc. sind erwünscht. Da aber Anbuva und Chactory schon mal angedeutet haben, daß sie nicht programmieren können, hoffe ich natürlich auch noch auf weitere Wortmeldungen.
Intel Core i7-2700K Processor (@ 45*100 = 4500 MHz) on ASRock P67 Extreme4 Gen3 with 16GB G.SKILL Ripjaws X Series (4 x 4GB) 240-Pin DDR3 SDRAM DDR3 2133 (PC3 17000) Model F3-17000CL11Q-16GBXL (Timings 10-10-10-28 2T @ 1866 MHz)
SSD Samsung 128GB 2.5-inch SSD 830 Series (Desktop)
HDD WD Caviar® SE16 640 GB, SATA2, 16 MB Cache, 7200 RPM
ATI Radeon HD 5850 ASUS EAH5850/G/2DIS/1GD5

Win 7 Ultimate 64-Bit / ESET NOD32 Antivirus 5.0 / Firefox 12.0 / Thunderbird 12.0
Spamihilator 1.0.0
Benutzeravatar
Quellcore
Assistent
Assistent
 
Beta-Tester
 
Beiträge: 1683
Registriert: 8. Mai 2004, 14:03
Wohnort: Long Island / USA

Re: Plugin-Idee: Bad-Recipient-Filter

Beitragvon Andreas_Z » 7. Jul 2006, 07:47

Hallo Quellcore!

Die Idee halte ich für gut. Und vor allem die sehr detailierten Vorarbeiten gefallen mir. Hoffentlich findet sich ein Programmierer.

Gruß
Andreas_Z
Core i7 3,4 GHz, 8 GB RAM, Win7 64bit SP1, GDATA Bussiness 11.0
Exchange-Server 2003, VM mit WinXP Pro SP3.
Spami-Online-Hilfe, Spami-FAQ, Anbuva's FAQ
Benutzeravatar
Andreas_Z
Administrator
Administrator
 
Administration
Beta-Tester
Forum-Team
 
Beiträge: 4364
Registriert: 6. Nov 2003, 09:10
Wohnort: Schwielowsee, Germany

Re: Plugin-Idee: Bad-Recipient-Filter

Beitragvon Chactory » 7. Jul 2006, 21:25

Hallo Quellcore und Andreas_Z,

Quellcore hat geschrieben:die in ihrer Schreibwut in den letzten Monaten ja kaum zu bremsen waren
ach, wenn ich doch nur eine ebensolche Programmierwut hätte ...

Quellcore hat geschrieben:Bad-Recipient-Filter
Tolle Idee!

Bist Du wieder zurück aus NYC? Welcome back!

Gruß, Chactory
HilfeTippsAnbuva's FAQBob's FAQ «en»SpamwortlisteRegelfilterScreenshotsSSL/TLSSpami 1.6.0
Vostro 3450, Intel Core i5 2410M 2,3 GHz, 4 GB DDR3 SDRAM 1333 MHz, Windows 7 Pro 64 Bit SP1

Bild
Benutzeravatar
Chactory
Administrator
Administrator
 
Administration
Beta-Tester
Forum-Team
 
Beiträge: 9310
Registriert: 10. Jan 2004, 00:19
Wohnort: Kiel (D)

Re: Plugin-Idee: Bad-Recipient-Filter

Beitragvon Quellcore » 10. Jul 2006, 14:16

Chactory hat geschrieben:Bist Du wieder zurück aus NYC? Welcome back!

Yes, i'm back! Die Welt zu Gast bei Freunden, Danke!
Ich habe mir es natürlich trotzdem nicht nehmen lassen, jeden Tag hier im forum vorbeizuschauen, habe mir aber aus Sicherheitsgründen nur den reinen Lesezugriff auf dieses Forum gegönnt. :wink:

Noch mal zurück zum Thema: ich hoffe wirklich, daß hier die üblichen Plugin-Programmierer noch einmal Blut lecken, mal sehen was da (nicht) kommt.
Letzte Woche habe ich mir auch schon mal das Spami Plugin SDK (Software Development Kit) angeschaut, bin aber noch nicht weiter als bis zum berüchtigten Bahnhof gekommen.
Intel Core i7-2700K Processor (@ 45*100 = 4500 MHz) on ASRock P67 Extreme4 Gen3 with 16GB G.SKILL Ripjaws X Series (4 x 4GB) 240-Pin DDR3 SDRAM DDR3 2133 (PC3 17000) Model F3-17000CL11Q-16GBXL (Timings 10-10-10-28 2T @ 1866 MHz)
SSD Samsung 128GB 2.5-inch SSD 830 Series (Desktop)
HDD WD Caviar® SE16 640 GB, SATA2, 16 MB Cache, 7200 RPM
ATI Radeon HD 5850 ASUS EAH5850/G/2DIS/1GD5

Win 7 Ultimate 64-Bit / ESET NOD32 Antivirus 5.0 / Firefox 12.0 / Thunderbird 12.0
Spamihilator 1.0.0
Benutzeravatar
Quellcore
Assistent
Assistent
 
Beta-Tester
 
Beiträge: 1683
Registriert: 8. Mai 2004, 14:03
Wohnort: Long Island / USA

Re: Plugin-Idee: Bad-Recipient-Filter

Beitragvon Chactory » 10. Jul 2006, 23:32

Hi Quellcore,

Quellcore hat geschrieben:[...] bin aber noch nicht weiter als bis zum berüchtigten Bahnhof gekommen.
wollen mal sehen, wohin der Zug geht. :wink:

Irgendwie bin ich immer noch nicht darüber hinweg, daß der BCC-Fehler des Addressee-Filters nicht zu überwinden ist :x, denn dessen Filteridee ist prinzipiell schon hervorragend. Alle E-Mails, die nicht an mich adressiert sind, sind nicht für mich. Bingo! :wink:

In einer an mich selber gesendeten E-Mail per BCC finde ich die Empfängeradresse im Header. Im folgenden Zitatblock habe ich jeweils Absender und Empfänger blau markiert. Ob es möglich ist, daß der Addressee-Filter auch den Header ausliest? Habe ich etwas falsch verstanden? (Z.B.: wird der Empfänger nicht von allen Headern dargestellt?)

Return-Path: <ABSENDER@SERVER.DE>
Received: from murder (frontend1.mail.uni-kiel.de [134.245.12.48])
by backend2.mail.uni-kiel.de (Cyrus v2.2.12) with LMTPA;
Mon, 10 Jul 2006 22:50:09 +0200
X-Sieve: CMU Sieve 2.2
Received: from frontend1.mail.uni-kiel.de ([unix socket])
by frontend1.mail.uni-kiel.de (Cyrus v2.2.12) with LMTPA;
Mon, 10 Jul 2006 22:50:09 +0200
Received: from l1ms.rz.uni-kiel.de ([134.245.11.86])
by frontend1.mail.uni-kiel.de with esmtp (Exim 4.42)
id 1G02hl-0007GH-44
for MEINKONTO@ srv1.mail.uni-kiel.de; Mon, 10 Jul 2006 22:50:09 +0200
Received: from amavis by l1ms.rz.uni-kiel.de with scanned-ok (Exim 4.42)
id 1G02hl-0003s7-33
for EMPFÄNGER@SERVER.DE; Mon, 10 Jul 2006 22:50:09 +0200
Received: from imo-m17.mx.bpm.com ([64.12.138.207])
by l1ms.rz.uni-kiel.de with esmtp (Exim 4.42)
id 1G02hk-0003rh-Fg
for EMPFÄNGER@SERVER.DE; Mon, 10 Jul 2006 22:50:08 +0200
Received: from ABSENDER@SERVER.DE
by imo-m17.mx.bpm.com (mail_out_v38_r7.5.) id u.481.53e9f99 (60465);
Mon, 10 Jul 2006 16:49:58 -0400 (EDT)
Received: from apoc (acce657a.ipt.aol.com [172.206.101.122])
by ciaaol-m01.mx.bpm.com (v110.15) with ESMTP
id MAILCIAAOLM012-ec3144b2bd72c7;
Mon, 10 Jul 2006 16:49:57 -0400
From: "Chactory" <ABSENDER@SERVER.DE>
To: <ABSENDER@SERVER.DE>
Subject: BETREFF DER MAIL
Date: Mon, 10 Jul 2006 22:49:59 +0200
Message-ID: <LGEIKGOBFJMDHMAJOHGECEOGCBAA.ABSENDER@SERVER.DE>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0002_01C6A473.2C29F7A0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
X-AOL-IP: 172.206.101.122
X-Spam-Checker-Version: SpamAssassin 3.0.3-uni_kiel_nospam (2005-04-27) on
nospam.rz.uni-kiel.de
X-Spam-Level: ***
X-Spam-Status: No, score=3.8 required=9.0 tests=BAYES_80,HTML_90_100,
HTML_MESSAGE,MIME_QP_LONG_LINE autolearn=no
version=3.0.3-uni_kiel_nospam
X-Spam-Report: * 0.0 HTML_MESSAGE BODY: HTML included in message * 3.6
BAYES_80 BODY: Bayesian spam probability is 80 to
95% * [score: 0.8589] * 0.0 HTML_90_100 BODY: Message
is 90% to 100% HTML *
0.1 MIME_QP_LONG_LINE RAW: Quoted-printable line
longer than 76 chars
X-Virus-Scanned: by AMaViS 0.3.12 (Uni-Kiel/l1ms-cs)

------=_NextPart_000_0002_01C6A473.2C29F7A0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

TEXT DER MAIL.

------=_NextPart_000_0002_01C6A473.2C29F7A0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.2912" name=3DGENERATOR>
</HEAD>
<BODY>
<DIV><SPAN class=3D843594820-10072006>
<FONT face=3DTahoma size=3D2>TEXT DER MAIL.</FONT>
</SPAN></DIV>
</BODY>
</HTML>

------=_NextPart_000_0002_01C6A473.2C29F7A0--

Gruß, Chactory
HilfeTippsAnbuva's FAQBob's FAQ «en»SpamwortlisteRegelfilterScreenshotsSSL/TLSSpami 1.6.0
Vostro 3450, Intel Core i5 2410M 2,3 GHz, 4 GB DDR3 SDRAM 1333 MHz, Windows 7 Pro 64 Bit SP1

Bild
Benutzeravatar
Chactory
Administrator
Administrator
 
Administration
Beta-Tester
Forum-Team
 
Beiträge: 9310
Registriert: 10. Jan 2004, 00:19
Wohnort: Kiel (D)

Re: Plugin-Idee: Bad-Recipient-Filter

Beitragvon Quellcore » 10. Jul 2006, 23:58

Chactory hat geschrieben:In einer an mich selber gesendeten E-Mail per BCC finde ich die Empfängeradresse im Header. Im folgenden Zitatblock habe ich jeweils Absender und Empfänger blau markiert. Ob es möglich ist, daß der Addressee-Filter auch den Header ausliest? Habe ich etwas falsch verstanden? (Z.B.: wird der Empfänger nicht von allen Headern dargestellt?)

Das ist blanker Zufall und hängt vom Mailprogramm ab.
Ich hab es mit Thunderbird versucht, die Empfängeradresse erscheint dann nicht in der Mail.
Testweise habe ich mir dann auch noch mal eine Mail per BCC über das GMX-Portal gesendet, auch hier taucht die Empfängeradresse nicht auf.
Dann habe ich noch ein weiteres WebMail-Portal ausprobiert, auch nix.

So soll es ja eigentlich auch sein. Welches Mailprogramm hast Du denn bemüht? Outlook oder Outlook Express? :wink:
Intel Core i7-2700K Processor (@ 45*100 = 4500 MHz) on ASRock P67 Extreme4 Gen3 with 16GB G.SKILL Ripjaws X Series (4 x 4GB) 240-Pin DDR3 SDRAM DDR3 2133 (PC3 17000) Model F3-17000CL11Q-16GBXL (Timings 10-10-10-28 2T @ 1866 MHz)
SSD Samsung 128GB 2.5-inch SSD 830 Series (Desktop)
HDD WD Caviar® SE16 640 GB, SATA2, 16 MB Cache, 7200 RPM
ATI Radeon HD 5850 ASUS EAH5850/G/2DIS/1GD5

Win 7 Ultimate 64-Bit / ESET NOD32 Antivirus 5.0 / Firefox 12.0 / Thunderbird 12.0
Spamihilator 1.0.0
Benutzeravatar
Quellcore
Assistent
Assistent
 
Beta-Tester
 
Beiträge: 1683
Registriert: 8. Mai 2004, 14:03
Wohnort: Long Island / USA

Re: Plugin-Idee: Bad-Recipient-Filter

Beitragvon Chactory » 11. Jul 2006, 00:59

So wird es wohl sein. Jetzt fällt mir dazu gerade nichts mehr ein, obwohl ich es nicht einsehen kann, daß man dieses wertvolle Instrument wegen des BCC-Fehlers nicht verwenden kann ... Ich verwende Outlook 2000.
HilfeTippsAnbuva's FAQBob's FAQ «en»SpamwortlisteRegelfilterScreenshotsSSL/TLSSpami 1.6.0
Vostro 3450, Intel Core i5 2410M 2,3 GHz, 4 GB DDR3 SDRAM 1333 MHz, Windows 7 Pro 64 Bit SP1

Bild
Benutzeravatar
Chactory
Administrator
Administrator
 
Administration
Beta-Tester
Forum-Team
 
Beiträge: 9310
Registriert: 10. Jan 2004, 00:19
Wohnort: Kiel (D)

Re: Plugin-Idee: Bad-Recipient-Filter

Beitragvon KanuUli » 11. Jul 2006, 08:13

Quellcore hat geschrieben:Letzte Woche habe ich mir auch schon mal das Spami Plugin SDK (Software Development Kit) angeschaut, bin aber noch nicht weiter als bis zum berüchtigten Bahnhof gekommen.


Wenn mir wer ne Schnittstelle in c# gibt, dann würde wahrscheinlich auch das eine oder andere Plugin von mir kommen.

Vielleicht sollte ich mir die SDK doch mal wieder anschaun.

Gruß Kanu
Benutzeravatar
KanuUli
Kanu-Kapitän
Kanu-Kapitän
 
Forum-Team
 
Beiträge: 1449
Registriert: 25. Jul 2003, 13:59
Wohnort: Bamberg, Germany

Re: Plugin-Idee: Bad-Recipient-Filter

Beitragvon Chactory » 11. Jul 2006, 10:26

Hallo KanuUli!

Das wäre einfach toll! :D

Gruß, Chactory
HilfeTippsAnbuva's FAQBob's FAQ «en»SpamwortlisteRegelfilterScreenshotsSSL/TLSSpami 1.6.0
Vostro 3450, Intel Core i5 2410M 2,3 GHz, 4 GB DDR3 SDRAM 1333 MHz, Windows 7 Pro 64 Bit SP1

Bild
Benutzeravatar
Chactory
Administrator
Administrator
 
Administration
Beta-Tester
Forum-Team
 
Beiträge: 9310
Registriert: 10. Jan 2004, 00:19
Wohnort: Kiel (D)

Re: Plugin-Idee: Bad-Recipient-Filter

Beitragvon Burkart » 20. Aug 2006, 16:50

Hallo, Quellcore und Co!

Auch ich benutze seit längerer Zeit den Substring-Filter zum Aussortieren von Mails an mir fremde Adressen. Der Erfolg insbesondere bei Mails, die sonst kein anderer Filter erkennt, ermutigt, die ständige Arbeit hingegen ist lästig. Deshalb war auch mir schon die Idee nach einem selbständig lernenden Filter gekommen, allerdings mit einem etwas anderen Ansatz.

Folgende Mail-Grundtypen habe ich festgestellt:
a) Mails an eine meiner Adressen, die ich auch haben will. Diese Adressen beinhalten auch Mailinglists.
b) Spam an eine meiner Adressen, den ich nicht haben will.
c) Spam an fremde Adressen, den ich nicht haben will.
d) Mails an eine meiner alten Adressen, die weitergeleitet werden, über die in letzter Zeit jedoch gefühlt 100% Spam kommt, den ich nicht will.
e) Bei einer Catch-all-Mailbox Mails an eine fixe Domain mit variablem Benutzer. Ob Spam oder Gutmensch läßt sich schlecht sagen.
f) Massen-Mails von Freunden, die außer an mich noch an andere mir meist bekannte Adressen gehen und die ich haben will.
g) Massen-Mails von Freunden, die ich als BCC erhalten will. Meist steht unter "To:" der Absender selbst.
h) Kombinationen, insbesondere solche aus b), c) und d). In der Regel bedeutet das, daß ich die Mail nicht haben will.

Die (Massen-) Mails von Freunden lassen sich natürlich auch erkennen, indem ich deren Adressen in die globale Freundesliste eintrage. Wie in einem anderen Thread beschrieben, gefällt mir die aktuelle Implementation der Spami-Freundesliste jedoch nicht hundertprozentig, weshalb sich ein Ausbau des Plugins auf Senderadressen in meinen Augen anbietet.

Bleiben wir der Einfachheit halber jetzt aber erstmal bei den zu filternden Empfängeradressen. Entgegen Quellcores Vorschlag würde ich eine Whitelist einführen, die somit automatisch meine Adressen lernt; in jedem Fall spart man sich so die manuelle Eingabe à la Adressee. Andere "gute" Adressen (Fälle e, f, g) würden so natürlich ebenfalls gelernt. Ebenso einfach würden unerwünschte Adressen in der Blacklist landen. Schwierig wird es erst, wenn Kobinationen auftreten oder wenn eine Blacklist-Adresse plötzlich für gut bzw. eine Whitelist-Adresse für schlecht befunden wird.

Mails an meine Whitelist- sowie eine fremde Blacklist-Adresse (Kombination aus a/b und c) sind schwer zu sortieren, wir sind in einer Grauzone. Die Frage ist jetzt, ob man auf Sicherheit gehen will, d.h. die Mail mit unbekannter Einstufung durchläßt, oder ob man davon ausgeht, daß es sich um Spam handelt. Ich sage dazu aus über einem Jahr Erfahrung mit dem Substring-Filter, daß es bei einer fremden Adresse bisher immer Spam war. Von daher würde ich in diesem Fall der Blacklist Priorität über die Whitelist geben. Dies übrigens im Unterschied zu Quellcore, wo die Greylist Priorität hat.

Es kommt also vor, daß Spam sowohl an eine fremde als auch an eine eigene Adresse geschickt wird. Beim Lernprozeß ergibt sich also die Situation, daß eine (meine) Whitelist-Adresse plötzlich als Spam-Adresse gelernt wird. Meine Idee diesbezüglich war es, neben der reinen Adresse auch den Zeitpunkt des letzten Vorfindens sowie die Anzahl der Fünde sowohl in der Black- als auch in der Whitelist zu vermerken. Über eine noch nicht näher bestimmte Rechnung hätte ich dann eine Einschätzung als gute, böse oder nicht zuzuordnende Adresse ermittelt. Hierzu muß ich sagen, daß Quellcores Greylist für all jene Adressen, die mindestens einmal in jeweils einer Spam- und einer Non-Spam-Mail aufgetaucht sind, durch ihre Einfachheit brilliert.

Nun haben ja "gute" Adressen erst einmal nichts in der Greylist zu suchen. Wenn dann kommt eine Whitelist infrage. Für die Implementierung macht Quellcores Vorschlag hingegen wieder Sinn - denn wenn die Adresse mangels Whitelist gar nicht gespeichert würde, würde sie ja beim ersten Fund in einer Spam-Mail fälschlicherweise in die Blacklist eingetragen werden.

Nun aber nochmal zurück zu dem Fall, daß eine Blacklist-Adresse in einer Non-Spam-Mail auftaucht. Erst einmal ist mir das wie gesagt in über einem Jahr noch nicht untergekommen. Sollte das aber tatsächlich mal vorkommen, wird es kompliziert. Die Adresse - wie von Quellcore vorgeschlagen - von der Black- in die Greylist zu übernehmen, würde dem Filter ein stückweit seine Effizienz rauben. Andererseits wäre es natürlich sehr ärgerlich, wenn eine früher in die Blacklist geratene Adresse plötzlich Verwendung findet, sie enthaltende Mails vom Filter jedoch weiterhin als Spam zurückgehalten würden. Über meine Idee der errechneten Einstufung aufgrund von Spam- und Non-Spam-Funden ließe sich dieses Problem ohne Mehraufwand umgehen, bei dem Greylist-Modell will mir hierzu keine einfache Lösung einfallen. Daher würde ich hier dafür plädieren, die Adressen im (bestimmt sehr seltenen) Fall des Falles in die Greylist zu übernehmen.

Alles in Allem würde ich somit Quellcores Vorschlag mit leichten Abänderungen zustimmen.

Scan-Process
************
scan Header data for recipient

check if one of the recipients is in the greylist >>> proceed with next filter process >>> unsure

...fällt weg.
check if one of the recipients is in the blacklist >>> filter process gets cancelled >>> classifiy mail as spam

Learning-Process
****************
learned as Non-Spam >>> check if recipient is in blacklist >>> if TRUE, move entry from blacklist to greylist

...dürfte in der Praxis fast nie auftreten.
learned as Non-Spam (cont'd) >>> check if recipient is in greylist >>> if FALSE, add recipient to greylist
learned as Spam >>> check if recipient is in greylist >>> if FALSE >>> check if recipient is in blacklist >>> if FALSE, add recipient to blacklist


Gehe ich recht in der Annahme, daß "cancel learning process" nur meinte, nicht auf Blacklist hin zu prüfen? In dem Fall finde ich die leicht modifizierte Beschreibung eindeutiger. War etwas anderes gemeint, bitte ich um Korrektur.

Diese leicht überarbeitete Fassung, im Grunde ein automatischer Substringfilter, ließe sich sicher vergleichsweise leicht implementieren und dabei trotzdem viel Spam ausfiltern. Mag sein, daß die von mir angedachte Variante mit Black- und Whitelist inclusive Timestamp und Zähler für Sender und Empfänger mehr Möglichkeiten bietet, dafür kriegt Quellcores Lösung eindeutig den Effizienz-Preis und ist damit einfach mal näher an einer Realisierung dran. Ich müßte mich nochmal mit der Spami-API und meinen eingerosteten C-Kenntnissen beschäftigen. Gerade weil mir eben diese Problematik auch schon länger unter den Nägeln brennt, könnte ich mir dann vorstellen, mich an einem Plugin zu versuchen - nehmt das aber bitte nicht gleich als Versprechen für eine schnelle Lösung.

Gibt es denn soweit erstmal weitere Ideen zu dem Filter?

Bye, Burkart
Benutzeravatar
Burkart
Spam-Killer
Spam-Killer
 
Beiträge: 39
Registriert: 20. Aug 2006, 13:50
Wohnort: Aalen

Re: Plugin-Idee: Bad-Recipient-Filter

Beitragvon Quellcore » 21. Aug 2006, 02:52

Hallo Burkart,
Vielen Dank für Deine Anmerkungen und Konkretisierungen.

Burkart hat geschrieben:Bleiben wir der Einfachheit halber jetzt aber erstmal bei den zu filternden Empfängeradressen. Entgegen Quellcores Vorschlag würde ich eine Whitelist einführen, die somit automatisch meine Adressen lernt; in jedem Fall spart man sich so die manuelle Eingabe à la Adressee. Andere "gute" Adressen (Fälle e, f, g) würden so natürlich ebenfalls gelernt. Ebenso einfach würden unerwünschte Adressen in der Blacklist landen. Schwierig wird es erst, wenn Kobinationen auftreten oder wenn eine Blacklist-Adresse plötzlich für gut bzw. eine Whitelist-Adresse für schlecht befunden wird.

Eine Whitelist ist natürlich eine sehr gute Idee, erweitert es doch die Funktion des Filters.
Ich denke aber dann eher an Black-, Grey-,White- und Excludelist.
Das genauere Procedere muß ich mir dann aber auch noch mal genauer überlegen, werde es dann weiter unten nachreichen.

Bzgl. Excludelist: Es wird immer Adressen geben, die der Filter NICHT als Entscheidungskriterium benutzen darf, das sind vornehmlich die eigenen Mailadressen.
Diese Adressen kommen auf die Excludelist.
Sie müssen dort manuell eingetragen werden (in den Einstellungen des Filters), werden beim Lernen nicht berücksichtigt und bleiben so lange in der Excludelist, bis man Sie manuell dort wieder herauslöscht.

Burkart hat geschrieben:Mails an meine Whitelist- sowie eine fremde Blacklist-Adresse (Kombination aus a/b und c) sind schwer zu sortieren, wir sind in einer Grauzone. Die Frage ist jetzt, ob man auf Sicherheit gehen will, d.h. die Mail mit unbekannter Einstufung durchläßt, oder ob man davon ausgeht, daß es sich um Spam handelt. Ich sage dazu aus über einem Jahr Erfahrung mit dem Substring-Filter, daß es bei einer fremden Adresse bisher immer Spam war. Von daher würde ich in diesem Fall der Blacklist Priorität über die Whitelist geben. Dies übrigens im Unterschied zu Quellcore, wo die Greylist Priorität hat.

Es wäre doch perfekt, wenn man dieses Verhalten in den Optionen des Filters seinem Geschmack anpassen könnte.
Der Filter würde bei mir aus mehreren Gründen ziemlich weit vorne in der Filterreihenfolge sein, es darf deshalb auf KEINEN Fall zu False-Positive Erkennungen kommen. Deshalb würde ich die konservative Methode bovorzugen, also die unbekannte Einstufung zu wählen.

Burkart hat geschrieben:Es kommt also vor, daß Spam sowohl an eine fremde als auch an eine eigene Adresse geschickt wird. Beim Lernprozeß ergibt sich also die Situation, daß eine (meine) Whitelist-Adresse plötzlich als Spam-Adresse gelernt wird. Meine Idee diesbezüglich war es, neben der reinen Adresse auch den Zeitpunkt des letzten Vorfindens sowie die Anzahl der Fünde sowohl in der Black- als auch in der Whitelist zu vermerken. Über eine noch nicht näher bestimmte Rechnung hätte ich dann eine Einschätzung als gute, böse oder nicht zuzuordnende Adresse ermittelt. Hierzu muß ich sagen, daß Quellcores Greylist für all jene Adressen, die mindestens einmal in jeweils einer Spam- und einer Non-Spam-Mail aufgetaucht sind, durch ihre Einfachheit brilliert.

Das Logging bezgl. Trefferanzahl / Datum des letzten Vorfindens wäre traumhaft. Weiter unten gehe ich noch einmal genauer auf die Greylist ein, dafür hätte ich auch gerne die Info mit abgespeichert, ob die jeweiligen Adressen in der Greylist das letzte mal als Spam oder Non-Spam gelernt worden sind.
Ob man diese Informationen dann wie von Dir vorgeschlagen in einer Formel zur Spamwahrscheinlichkeit verwendet, sei erst einmal dahin gestellt.

Die Blacklist könnte sich nach einer gewissen Zeit ganz schön aufblähen, also sollte man obsolete Einträge (zu alt bei Trefferanzahl = 1) einfach aus der Blacklist entfernen.
Das Entschlacken der Blacklist könnte autmatisch bei jedem Start oder auch manuell in den Einstellungen des Filters erfolgen.

Burkart hat geschrieben:Nun aber nochmal zurück zu dem Fall, daß eine Blacklist-Adresse in einer Non-Spam-Mail auftaucht. Erst einmal ist mir das wie gesagt in über einem Jahr noch nicht untergekommen. Sollte das aber tatsächlich mal vorkommen, wird es kompliziert. Die Adresse - wie von Quellcore vorgeschlagen - von der Black- in die Greylist zu übernehmen, würde dem Filter ein stückweit seine Effizienz rauben. Andererseits wäre es natürlich sehr ärgerlich, wenn eine früher in die Blacklist geratene Adresse plötzlich Verwendung findet, sie enthaltende Mails vom Filter jedoch weiterhin als Spam zurückgehalten würden. Über meine Idee der errechneten Einstufung aufgrund von Spam- und Non-Spam-Funden ließe sich dieses Problem ohne Mehraufwand umgehen, bei dem Greylist-Modell will mir hierzu keine einfache Lösung einfallen. Daher würde ich hier dafür plädieren, die Adressen im (bestimmt sehr seltenen) Fall des Falles in die Greylist zu übernehmen.

Mit der Greylist stelle ich mir das folgendermaßen vor.
Adressen kommen untern den folgenden Bedingungen auf die Greylist:
Code: Alles auswählen
Adresse war in Blacklist und es wird als Non-Spam gelernt >>> Adresse verschieben nach Greylist
Adresse war in Whitelist und es wird als Spam gelernt     >>> Adresse verschieben nach Greylist

Bei der nächsten Filterung werden die Adressen auf der Greylist nicht berücksichtigt.
Kommt jetzt eine Mail an, dessen Empfänger auf der Greylist steht passiert beim Lernen folgendes:
Es wird anhand der Logging-Daten überprüft, ob die auf der Greylist stehende Adresse beim letzten Mal genauso gelernt wurde wie beim aktuellen Lernvorgang. Ist das der Fall, sollte die Adresse wieder verschoben werden.
Wenn 2x als Spam gelernt wurde, dann zur Blacklist, bei 2x Non-Spam dann zur Whitelist.

Das war es erst einmal von meiner Seite
Intel Core i7-2700K Processor (@ 45*100 = 4500 MHz) on ASRock P67 Extreme4 Gen3 with 16GB G.SKILL Ripjaws X Series (4 x 4GB) 240-Pin DDR3 SDRAM DDR3 2133 (PC3 17000) Model F3-17000CL11Q-16GBXL (Timings 10-10-10-28 2T @ 1866 MHz)
SSD Samsung 128GB 2.5-inch SSD 830 Series (Desktop)
HDD WD Caviar® SE16 640 GB, SATA2, 16 MB Cache, 7200 RPM
ATI Radeon HD 5850 ASUS EAH5850/G/2DIS/1GD5

Win 7 Ultimate 64-Bit / ESET NOD32 Antivirus 5.0 / Firefox 12.0 / Thunderbird 12.0
Spamihilator 1.0.0
Benutzeravatar
Quellcore
Assistent
Assistent
 
Beta-Tester
 
Beiträge: 1683
Registriert: 8. Mai 2004, 14:03
Wohnort: Long Island / USA

Re: Plugin-Idee: Bad-Recipient-Filter

Beitragvon Burkart » 21. Aug 2006, 19:38

Hallo, Quellcore!

Quellcore hat geschrieben:Eine Whitelist ist natürlich eine sehr gute Idee, erweitert es doch die Funktion des Filters.
Ich denke aber dann eher an Black-, Grey-,White- und Excludelist.


Oje, und dabei hatte ich mich doch gerade von Deiner schlicht eleganten Lösung überzeugen lassen...

Quellcore hat geschrieben:Bzgl. Excludelist: Es wird immer Adressen geben, die der Filter NICHT als Entscheidungskriterium benutzen darf, das sind vornehmlich die eigenen Mailadressen.
Diese Adressen kommen auf die Excludelist.
Sie müssen dort manuell eingetragen werden (in den Einstellungen des Filters), werden beim Lernen nicht berücksichtigt und bleiben so lange in der Excludelist, bis man Sie manuell dort wieder herauslöscht.


Ich glaube, darauf können wir verzichten. Während ich in meinen ursprünglichen Überlegungen noch davon ausgegangen war, sowohl Spam- als auch Non-Spam-Mails zu finden, denke ich jetzt, daß dieser Filter ausschließlich zum Aussortieren von Spam taugt, nicht jedoch zur Identifikation von guten Mails. Meine Erfahrungen bisher sind sogar so, daß eigentlich eine Blacklist reicht. Gut, da ich diese bisher händisch per Substring-Liste gepflegt habe, hatte ich noch eine gewisse Kontrolle. Hmmm. Nichtsdestoweniger meine ich, daß die Funktion der Excludelist auch über die Whitelist/Greylist abgedeckt wird. Klar, wenn man die eigene(n) Adresse(n) von Anfang an per Hand eingibt, ist die Whitelist definiert und muß nicht erst erlernt werden. Nach ein, zwei Lernvorgängen dürfte der Filter aber doch auch selbst die "guten" Adressen gelernt haben. Aus diesem Grund sträube ich mich dagegen, die eigenen Adressen in eine zusätzliche Excludelist einzugeben. Und auch wenn man jetzt argumentieren kann, daß das ja niemand tun muß, bleibt die Frage, ob es denn wirklich Sinn macht in der Form, daß es den Filter verbessert. In jedem Fall aber wird die Programmierung durch eine zusätzliche Liste nicht leichter ;-)

Quellcore hat geschrieben:
Burkart hat geschrieben:Mails an meine Whitelist- sowie eine fremde Blacklist-Adresse (Kombination aus a/b und c) sind schwer zu sortieren, wir sind in einer Grauzone. Die Frage ist jetzt, ob man auf Sicherheit gehen will, d.h. die Mail mit unbekannter Einstufung durchläßt, oder ob man davon ausgeht, daß es sich um Spam handelt. Ich sage dazu aus über einem Jahr Erfahrung mit dem Substring-Filter, daß es bei einer fremden Adresse bisher immer Spam war. Von daher würde ich in diesem Fall der Blacklist Priorität über die Whitelist geben. Dies übrigens im Unterschied zu Quellcore, wo die Greylist Priorität hat.

Es wäre doch perfekt, wenn man dieses Verhalten in den Optionen des Filters seinem Geschmack anpassen könnte.
Der Filter würde bei mir aus mehreren Gründen ziemlich weit vorne in der Filterreihenfolge sein, es darf deshalb auf KEINEN Fall zu False-Positive Erkennungen kommen. Deshalb würde ich die konservative Methode bovorzugen, also die unbekannte Einstufung zu wählen.


Alles klar, eine Option wäre sicher kein Problem.
Übrigens, auch ich habe den bisherigen Ersatz in Form des Substring-Filters an Position 2 (hinter dem Newsletter-Plugin) stehen. Dieser führt ja auch ausschließlich eine Blacklist und hat trotzdem noch nie falsch angeschlagen.

Quellcored hat geschrieben:Das Logging bezgl. Trefferanzahl / Datum des letzten Vorfindens wäre traumhaft.
[...]
Die Blacklist könnte sich nach einer gewissen Zeit ganz schön aufblähen, also sollte man obsolete Einträge (zu alt bei Trefferanzahl = 1) einfach aus der Blacklist entfernen.
Das Entschlacken der Blacklist könnte autmatisch bei jedem Start oder auch manuell in den Einstellungen des Filters erfolgen.


Ja, gute Idee. Ein guter Zeitpunkt zum Entschlacken wäre wahrscheinlich der Lernprozeß. Hier muß eh auf die Datenbank zugegriffen werden.

Quellcore hat geschrieben:
Burkart hat geschrieben:Nun aber nochmal zurück zu dem Fall, daß eine Blacklist-Adresse in einer Non-Spam-Mail auftaucht. Erst einmal ist mir das wie gesagt in über einem Jahr noch nicht untergekommen. Sollte das aber tatsächlich mal vorkommen, wird es kompliziert. Die Adresse - wie von Quellcore vorgeschlagen - von der Black- in die Greylist zu übernehmen, würde dem Filter ein stückweit seine Effizienz rauben. Andererseits wäre es natürlich sehr ärgerlich, wenn eine früher in die Blacklist geratene Adresse plötzlich Verwendung findet, sie enthaltende Mails vom Filter jedoch weiterhin als Spam zurückgehalten würden. Über meine Idee der errechneten Einstufung aufgrund von Spam- und Non-Spam-Funden ließe sich dieses Problem ohne Mehraufwand umgehen, bei dem Greylist-Modell will mir hierzu keine einfache Lösung einfallen. Daher würde ich hier dafür plädieren, die Adressen im (bestimmt sehr seltenen) Fall des Falles in die Greylist zu übernehmen.


Mit der Greylist stelle ich mir das folgendermaßen vor.
Adressen kommen untern den folgenden Bedingungen auf die Greylist:
Code: Alles auswählen
Adresse war in Blacklist und es wird als Non-Spam gelernt >>> Adresse verschieben nach Greylist
Adresse war in Whitelist und es wird als Spam gelernt     >>> Adresse verschieben nach Greylist

Bei der nächsten Filterung werden die Adressen auf der Greylist nicht berücksichtigt.
Kommt jetzt eine Mail an, dessen Empfänger auf der Greylist steht passiert beim Lernen folgendes:
Es wird anhand der Logging-Daten überprüft, ob die auf der Greylist stehende Adresse beim letzten Mal genauso gelernt wurde wie beim aktuellen Lernvorgang. Ist das der Fall, sollte die Adresse wieder verschoben werden.
Wenn 2x als Spam gelernt wurde, dann zur Blacklist, bei 2x Non-Spam dann zur Whitelist.


Dem mag ich so nicht zustimmen. Angenommen eine Adresse taucht einmal in einer Spam-Mail auf (-> Blacklist), dann in einer Non-Spam (-> Greylist), dann Spam (-> Blacklist). Soweit OK, man würde also einzelne Ausreißer ignorieren. Wenn es mit dieser Adresse jedoch so weitergeht, wechselt sie stets zwischen Black- und Greylist hin und her. Passiert das gleiche mit dem feinen Unterschied, daß die Adresse zuerst in einer Non-Spam- (-> Whitelist) und dann in einer Spam-Mail (-> Greylist) war, gibt es Ping-Pong zwischen White- und Greylist. Und passiert es nun einmal, daß die Adresse einmal in einer Spam-Mail (-> Blacklist) und dann zweimal hintereinander in einer Non-Spam-Mail war (-> Greylist -> permanente Greylist), haben wir schon ein drittes Verhalten. Klar ist das alles sehr unwahrscheinlich, trotzdem ist mir die Reaktion des Filters zu chaotisch. Davon abgesehen wird die Implementierung mit permanenter Greylist, temporärer Spam- und temporärer Non-Spam-Greylist auch wieder komplizierter als notwendig.

Ich hätte da einen anderen Vorschlag, der mit nur einer einzigen Liste auskommt, genauer mit einer einzigen Tabelle. Jede Zeile steht für eine Adresse, in den Spalten steht neben der Adresse selbst die Häufigkeit und das letzte Auftreten in einer Spam-Mail sowie die Häufigkeit und das letzte Auftreten in einer Non-Spam-Mail. Darüber, welche Häufigkeiten (und vielleicht auch welches letzte Auftreten) eine Adresse vorzuweisen hat, wird sie als "schwarze, weiße oder graue" Adresse eingestuft. Die Einstufung ließe sich beliebig komplex machen. Die Einfachste Variante entspricht Quellcores ursprünglichem Vorschlag: Kein einziges Auftreten in einer Non-Spam-Mail bedeutet Blacklist, alles andere bedeutet Greylist. Theoretisch bedeutet ausschließliches Auftreten in Non-Spam-Mails Whitelist, das Ergebnis ist jedoch bei White- und bei Greylist dasselbe: Der Filter kann sich nicht entscheiden und reicht die Mail an seine Kollegen weiter.

Wenn man möchte, kann man sich jetzt die Einteilung in Black- und Grey-/Whitelist beliebig schwierig machen. Einfacher Vorschlag: Wenn eine Adresse mit mehrfachen Funden in der Blacklist steht und nur 1 mal in einer Non-Spam-Mail auftauchte, gilt die Adresse immernoch als Spam-Adresse. Ausbauen ließe sich das z.B. in der Form, daß die Adresse auch dann noch "böse" ist, wenn sie zweimal in einer Non-Spam-Mail auftauchte, dieser Fund jedoch mindestens 3 Monate länger her ist als der letzte Fund in einer Spam-Mail. Und so weiter und so fort. Wie gesagt, für den Anfang würde ich die simple Blacklist mit sofortigem (gedachten) Verschieben in die Greylist bei einmaligem Auftauchen in einer Non-Spam-Mail vorschlagen. Kompliziertere Einschätzungen blieben dann einer etwaigen Verbesserung vorbehalten - sofern das überhaupt notwendig werden sollte.

Bye, Burkart
Benutzeravatar
Burkart
Spam-Killer
Spam-Killer
 
Beiträge: 39
Registriert: 20. Aug 2006, 13:50
Wohnort: Aalen

Re: Plugin-Idee: Bad-Recipient-Filter

Beitragvon Quellcore » 21. Aug 2006, 21:12

Burkart hat geschrieben:Ich hätte da einen anderen Vorschlag, der mit nur einer einzigen Liste auskommt, genauer mit einer einzigen Tabelle. Jede Zeile steht für eine Adresse, in den Spalten steht neben der Adresse selbst die Häufigkeit und das letzte Auftreten in einer Spam-Mail sowie die Häufigkeit und das letzte Auftreten in einer Non-Spam-Mail. Darüber, welche Häufigkeiten (und vielleicht auch welches letzte Auftreten) eine Adresse vorzuweisen hat, wird sie als "schwarze, weiße oder graue" Adresse eingestuft. ...

Die Idee 'nur' mit einer Liste zu arbeiten finde ich sehr gut, heute Nachmittag kam mir der gleiche Gedanke.

Burkart hat geschrieben:Die Einstufung ließe sich beliebig komplex machen. Die Einfachste Variante entspricht Quellcores ursprünglichem Vorschlag: Kein einziges Auftreten in einer Non-Spam-Mail bedeutet Blacklist, alles andere bedeutet Greylist. Theoretisch bedeutet ausschließliches Auftreten in Non-Spam-Mails Whitelist, das Ergebnis ist jedoch bei White- und bei Greylist dasselbe: Der Filter kann sich nicht entscheiden und reicht die Mail an seine Kollegen weiter... Während ich in meinen ursprünglichen Überlegungen noch davon ausgegangen war, sowohl Spam- als auch Non-Spam-Mails zu finden, denke ich jetzt, daß dieser Filter ausschließlich zum Aussortieren von Spam taugt, nicht jedoch zur Identifikation von guten Mails. Meine Erfahrungen bisher sind sogar so, daß eigentlich eine Blacklist reicht.

Ich denke auch, daß man sich auf die Spamfilterung konzentrieren sollte, das Erkennen von Non-Spam bleibt anderen Filtern und der Freundesliste vorbehalten. Es sollte den Programmieraufwand auch deutlich minimieren.

Burkart hat geschrieben:
Quellcore hat geschrieben:Bzgl. Excludelist: Es wird immer Adressen geben, die der Filter NICHT als Entscheidungskriterium benutzen darf, das sind vornehmlich die eigenen Mailadressen.
Diese Adressen kommen auf die Excludelist.
Sie müssen dort manuell eingetragen werden (in den Einstellungen des Filters), werden beim Lernen nicht berücksichtigt und bleiben so lange in der Excludelist, bis man Sie manuell dort wieder herauslöscht.

Gut, da ich diese bisher händisch per Substring-Liste gepflegt habe, hatte ich noch eine gewisse Kontrolle. Hmmm. Nichtsdestoweniger meine ich, daß die Funktion der Excludelist auch über die Whitelist/Greylist abgedeckt wird. Klar, wenn man die eigene(n) Adresse(n) von Anfang an per Hand eingibt, ist die Whitelist definiert und muß nicht erst erlernt werden. Nach ein, zwei Lernvorgängen dürfte der Filter aber doch auch selbst die "guten" Adressen gelernt haben. Aus diesem Grund sträube ich mich dagegen, die eigenen Adressen in eine zusätzliche Excludelist einzugeben. Und auch wenn man jetzt argumentieren kann, daß das ja niemand tun muß, bleibt die Frage, ob es denn wirklich Sinn macht in der Form, daß es den Filter verbessert. In jedem Fall aber wird die Programmierung durch eine zusätzliche Liste nicht leichter ;-)


Burkart hat geschrieben:Alles klar, eine Option (Anm.: Blacklist hat Priorität über die Whitelist) wäre sicher kein Problem.

Wenn es dann konzeptbedingt keine Excludelist gibt, stimme ich auf jeden Fall auch mit Deiner Meinung überein, daß die Blacklist dominant über die imaginäre Greylist/Whitelist herrscht. Ansonsten würden ja jede Spammail, die mehrere Adressaten hat aber auch an meine eigene Adresse gerichtet ist, nicht erkannt werden.

Burkart hat geschrieben:... Wie gesagt, für den Anfang würde ich die simple Blacklist mit sofortigem (gedachten) Verschieben in die Greylist bei einmaligem Auftauchen in einer Non-Spam-Mail vorschlagen. Kompliziertere Einschätzungen blieben dann einer etwaigen Verbesserung vorbehalten - sofern das überhaupt notwendig werden sollte.

Dem gibt es eigentlich nichts mehr hinzuzufügen. Sehr guter Vorschlag!
Intel Core i7-2700K Processor (@ 45*100 = 4500 MHz) on ASRock P67 Extreme4 Gen3 with 16GB G.SKILL Ripjaws X Series (4 x 4GB) 240-Pin DDR3 SDRAM DDR3 2133 (PC3 17000) Model F3-17000CL11Q-16GBXL (Timings 10-10-10-28 2T @ 1866 MHz)
SSD Samsung 128GB 2.5-inch SSD 830 Series (Desktop)
HDD WD Caviar® SE16 640 GB, SATA2, 16 MB Cache, 7200 RPM
ATI Radeon HD 5850 ASUS EAH5850/G/2DIS/1GD5

Win 7 Ultimate 64-Bit / ESET NOD32 Antivirus 5.0 / Firefox 12.0 / Thunderbird 12.0
Spamihilator 1.0.0
Benutzeravatar
Quellcore
Assistent
Assistent
 
Beta-Tester
 
Beiträge: 1683
Registriert: 8. Mai 2004, 14:03
Wohnort: Long Island / USA

Re: Plugin-Idee: Bad-Recipient-Filter

Beitragvon Burkart » 22. Aug 2006, 17:04

Hallo, Quellcore!

Quellcore hat geschrieben:Wenn es dann konzeptbedingt keine Excludelist gibt, stimme ich auf jeden Fall auch mit Deiner Meinung überein, daß die Blacklist dominant über die imaginäre Greylist/Whitelist herrscht. Ansonsten würden ja jede Spammail, die mehrere Adressaten hat aber auch an meine eigene Adresse gerichtet ist, nicht erkannt werden.


Wieso wäre es denn Deiner Meinung nach eine andere Situation, wenn es eine Excludelist gäbe? Diese ist doch nichts anderes als eine fest einprogrammierte (im Sinne von: Vom Menschen vorgegebene) White/Greylist.

Trotzdem ließe sich sicher eine Option einbauen, wo mit der Greylist die Sicherheit oberste Priorität hat.

Ich bin ab morgen erstmal ein paar Tage unterwegs. Danach, also in ein, zwei Wochen würde ich mich dann mal an einem Filter versuchen. Wäre doch gelacht, wenn nach den ganzen Überlegungen alles im Sand verliefe.

Bye, Burkart
Benutzeravatar
Burkart
Spam-Killer
Spam-Killer
 
Beiträge: 39
Registriert: 20. Aug 2006, 13:50
Wohnort: Aalen

Re: Plugin-Idee: Bad-Recipient-Filter

Beitragvon Quellcore » 23. Aug 2006, 00:28

Burkart hat geschrieben:Wieso wäre es denn Deiner Meinung nach eine andere Situation, wenn es eine Excludelist gäbe? Diese ist doch nichts anderes als eine fest einprogrammierte (im Sinne von: Vom Menschen vorgegebene) White/Greylist.

Autsch, da hast Du mich jetzt erwischt.
Ich kann jetzt gerade meinen Gedankengang dazu auch nicht mehr nachvollziehen, deswegen würde ich ihn bis auf weiteres ignorieren, was hälst Du davon? ;-)

Burkart hat geschrieben:Trotzdem ließe sich sicher eine Option einbauen, wo mit der Greylist die Sicherheit oberste Priorität hat.

Falls es dann wirklich so kommt, daß Du Dich an die Verwirklichung dieses Projektes machst, dann kannst Du selbt entscheiden. Ich korrespondiere da mittlerweile mit Deiner Meinung, den Blacklisteinträgen Vorrang vor den Greylisteinträgen zu geben. Wenn sich die Option in den Einstellungen für Dich einfach und ohne viel Mehraufwand realisieren ließe, dann wäre es umso besser.
Burkart hat geschrieben:Ich bin ab morgen erstmal ein paar Tage unterwegs. Danach, also in ein, zwei Wochen würde ich mich dann mal an einem Filter versuchen. Wäre doch gelacht, wenn nach den ganzen Überlegungen alles im Sand verliefe.

Das klingt ja recht vielversprechend! :D
Ich lese mich gerade in C++ ein, aber bis jetzt nur zum Spaß und wegen dieses Threads, mal sehen was daraus noch wird.
Ich habe gestern mal ein wenig mit den Beispielfiltern aus dem Spami SDK rumgespielt, mehr aber auch nicht. Ich weiß noch nicht mal, wie man dann am Ende eine DLL draus macht.

Also, bis bald dann.

Grüße aus Hamburg
Intel Core i7-2700K Processor (@ 45*100 = 4500 MHz) on ASRock P67 Extreme4 Gen3 with 16GB G.SKILL Ripjaws X Series (4 x 4GB) 240-Pin DDR3 SDRAM DDR3 2133 (PC3 17000) Model F3-17000CL11Q-16GBXL (Timings 10-10-10-28 2T @ 1866 MHz)
SSD Samsung 128GB 2.5-inch SSD 830 Series (Desktop)
HDD WD Caviar® SE16 640 GB, SATA2, 16 MB Cache, 7200 RPM
ATI Radeon HD 5850 ASUS EAH5850/G/2DIS/1GD5

Win 7 Ultimate 64-Bit / ESET NOD32 Antivirus 5.0 / Firefox 12.0 / Thunderbird 12.0
Spamihilator 1.0.0
Benutzeravatar
Quellcore
Assistent
Assistent
 
Beta-Tester
 
Beiträge: 1683
Registriert: 8. Mai 2004, 14:03
Wohnort: Long Island / USA

Nächste

Zurück zu Plugins: Feature Requests

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 0 Gäste

 industrious-southeast