Plugin-Idee: Bad-Recipient-Filter

[anbuva]

Hallo Quellcore,

Durch Zufall bin ich erst heute auf dieses Posting gestossen (man kann ja nicht alles mitbekommen ). Da will ich dann also auch noch mal meinen Senf dazugeben

Halo Allerseits,
vornehmlich natürlich an Chactory und Anbuva, die in ihrer Schreibwut in den letzten Monaten ja kaum zu bremsen waren.

Ja, das stimmt. Das ich so oft hier reinschaute, hatte bei mir aber auch andere (nicht unbedingt zufriedenstellende ) Gründe, welche aber nicht mit Spami zusammenhingen, wie ich betonen möchte ...

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.

Ja, leider. Noch immer hoffe ich auch täglich auf eine Antwort von denen. Würde mir schon reichen, überhaupt ein Lebenszeichen zu vernehmen. Vielleicht muss man ja bald mal ein Kopfgeld für deren Ergreifung aussetzen

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......Eine Idee für den Namen des Filters hätte ich auch schon: Bad-Recipient-Filter

Das klingt wirklich Klasse Allein schon der Gedanke an ein neues PlugIn (egal welcher Art) erzeugt bei mir schon Freudentaumel.

Da aber Anbuva und Chactory schon mal angedeutet haben, daß sie nicht programmieren können, hoffe ich natürlich auch noch auf weitere Wortmeldungen

Ähmm; mhhh Nun ja, so ganz trifft das nicht zu. Programmieren ist eigentlich kein Fremdwort oder Neu für mich. Ich bin (verzeihung) war in 2 Sprachen aktiv. Allerdings habe ich durch meine z. Tl. jahrelange Faulheit und andere Gründe einiges wieder verlernt. Ich müsste erst selber wieder "lernen", bevor ich da wieder beigehen könnte. Gut, sicherlich würde es rascher gehen; aber Dirty-Programming ist und sollte eigentlich nicht mein Ding werden...
Ich habe aber vor, demnächst wieder anzufangen. Falls ich Glück habe, werde ich es (beruflich gesehen) auch wieder müssen. In der Tat habe ich auch schon mit den Gedanken gespielt, mal selber was zu entwickeln ...

Gruß
anbuva

[Chactory]

Hei, Anbuva,

Ich habe aber vor, demnächst wieder anzufangen. Falls ich Glück habe, werde ich es (beruflich gesehen) auch wieder müssen. In der Tat habe ich auch schon mit den Gedanken gespielt, mal selber was zu entwickeln ...

das wäre ja was!

Gruß, Chactory

[anbuva]

Hallo Chactory!

Da fehlt mir jetzt nur noch "der liebe Gott" und ein Quentchen oder mehr Glück (nachdem ich soviel Pech hatte ) ...

Gruß
anbuva

[Andreas_Z]

Hallo anbuva!

Ich bin zwar nicht der liebe Gott , aber Glück wünschen kann ich Dir trotzdem. Bei mir siehts, was die Programmierkenntnisse angeht, leider sehr ähnlich aus. Dummer weise habe ich keine Zeit, mich neu einzuarbeiten. Ideen habe ich zwar, aber die Zeit....

Gruß
Andreas_Z

[anbuva]

Hallo Andreas_Z!

Jo! War erschreckend zu merken, wie schnell man doch was verlernen kann. Selbst die einfachsten Dinge fallen einem anfangs erst wieder etwas schwer...

Gruß
anbuva

[Burkart]

Servus!

Ich bin wieder hier und habe mich die letzten paar Stunden ins Plugin-Programmieren gestürzt. Nach der ersten Freude, anhand des im SDK mitgelieferten Image-Filters unter Dev-C++ eine DLL erzeugen zu können, kam der Dämpfer mit bisher langer, erfolgloser Fehlersuche: Spami moniert meine DLL mittels "Ein Plugin konnte nicht geladen werden: Project1.dll". Mist. Unter http://www.spamihilator.com/forum/viewtopic.php?p=2858#2858 habe ich evtl. die Andeutung eines Workarounds gefunden, heute wird das aber nix mehr. In jedem Fall werde ich mich auch die nächsten Tage wieder um den Filter kümmern und - vorausgesetzt, Spami ist dann gnädiger gestimmt - hoffentlich bald ein erstes Plugin vorzeigen können.

Bye, Burkart

[anbuva]

Hallo Burkart!

Mensch Burkart, das klingt ja schon fast wie Weihnachten . Ich freue mich schon darauf, ein erstes Ergebnis bzw. PlugIn Deiner Bemühungen zu begutachten.
Und: Keine falsche Scham , falls noch nicht alles funktionieren sollte oder viele Fehler noch vorkommen sollten. Wer sich hier beschwert oder rummäkelt, soll es erst mal selber (besser) machen und bekommt es mit anbuva zu tun (den fresse ich dann auch auf ) !!! Ich "liebe" diese Leute, die immer gleich alles aus Missgunst zerreißen mögen und wollen!

Gruß
anbuva

[Chactory]

Wunderbar! Bin ebenfalls sehr gespannt auf weiteres!

[Quellcore]

Hallo Burkart!

Na, das sind ja sehr gute Nachrichten.
Viel Erfolg weiterhin, am Fleiß scheint es ja schon mal nicht zu scheitern.
Ich hatte da noch eine Idee, die ich natürlich hier vorstellen wollte, bevor das Programmieren beginnt. Dafür bin iich wohl jetzt ein bischen spät dran.

Und zwar hatte ich die Idee, daß zur Klassifizierung der Mail der gesamte Header nach Mailadressen untersucht wird.
Mir ist nämlich aufgefallen, daß die bösen Adressen sich auch mehr oder weniger häufig in anderen Zeilen als der "To"-Zeile wiederfinden lassen.
Beim Lernprozeß (würde ich dann wieder strikt nur auf die "To"-Zeile zurückgreifen, um die Liste nicht mit zu vielen fiktiven Absender-Adressen zuzumüllen.

Gruß
Quellcore

P.S. Wenn Du schon mit diesem Teil des Plugins fertig sein solltest darfst Du diesen Post gerne ignorieren.

[Burkart]

Hallo!

Mensch Burkart, das klingt ja schon fast wie Weihnachten . Ich freue mich schon darauf, ein erstes Ergebnis bzw. PlugIn Deiner Bemühungen zu begutachten.

Alles klar. Aber nicht vor dem 24. aufmachen

Ich hatte da noch eine Idee, die ich natürlich hier vorstellen wollte, bevor das Programmieren beginnt. Dafür bin iich wohl jetzt ein bischen spät dran.

Kein Problem, die eigentliche Programmierarbeit hat noch nicht begonnen. Bisher hat es ja daran gehapert, daß Spami das Plugin überhaupt nicht erkannt hat. Das hat sich grad vorhin als C++-Problem herausgestellt - eigentlich leicht zu umgehen, wenn man nur erstmal weiß, wie. Dazu schreibe ich dann für zukünftige Plugin-Entwickler nochmal an anderer Stelle was. Inzwischen hab ich also ein Plugin, das von Spami akzeptiert wird und das schonmal alle Mails mit unbekannter Einstufung durchläßt

Und zwar hatte ich die Idee, daß zur Klassifizierung der Mail der gesamte Header nach Mailadressen untersucht wird.
Mir ist nämlich aufgefallen, daß die bösen Adressen sich auch mehr oder weniger häufig in anderen Zeilen als der "To"-Zeile wiederfinden lassen.
Beim Lernprozeß (würde ich dann wieder strikt nur auf die "To"-Zeile zurückgreifen, um die Liste nicht mit zu vielen fiktiven Absender-Adressen zuzumüllen.

Welche anderen Felder meinst Du denn? Die "Received by mail-xy.de from mail-z.com for dings@wuppel.net"? Die würden sich sicher noch lohnen, auszuwerten. Noch weitere?

Was dann das Lernen angeht, warum da nicht auch alle Adressen miteinbeziehen? Ich würde es dann bloß so handhaben, daß mehrfache Nennungen einer Adresse pro Mail nur einmal gezählt werden. Und am Besten gibt's dafür dann auch wieder ne Option.

Außerdem ließe sich bestimmt auch einfach ein Logfile einbauen. Da würden dann erstmal sämtliche Fundorte vermerkt und wir können dann nach ein paar Monaten Probelauf gucken, auf welche Felder die Suche am Besten ausgeweitet werden sollte.

Hinsichtlich der Zumüll-Problematik hilft denke ich der mitgespeicherte Timestamp. Sollte die Datenbank wirklich mal zu groß werden, kann man sie dann ja ähnlich wie den lernenden Filter per Hand oder vielleicht auch automatisch aufräumen.

Bye, Burkart

[Quellcore]

Welche anderen Felder meinst Du denn? Die "Received by mail-xy.de from mail-z.com for dings@wuppel.net"? Die würden sich sicher noch lohnen, auszuwerten. Noch weitere?

Das Problem ist ja, daß ein Header abhängig vom MailClienten/Provider ist und immer anders aussehen kann.
Mir sind außer dem von Dir bereits erwähnten 'Received:'-Feld noch folgende interessante Felder aufgefallen:

• Delivered-To:
• X-Originating-Email:
• X-Sender:
• CC:
• BCC:

Was dann das Lernen angeht, warum da nicht auch alle Adressen miteinbeziehen?

Wie bereits erwähnt geht es mir hauptsächlich um das Zumüllen der Liste mit falschen Absender-Adressen. Es gibt hier im Forum Mitglieder, die mehrere hundert Spammails pro Tag bekommen. Wenn man davon ausgeht, daß ungefähr die hälfte der Absender-Adressen gefälscht ist, dann kommt man immer noch auf mehrere hunder neuer Adressen, die pro Tag auf die Blacklist Deines Filters kommen und sowieso nur einmal und nie wieder auftreten. Die Bereinigung der Liste müßte dann ja schon jeden Tag erfolgen, dafür fehlen dann aber aussagekräftige Daten.

Ich würde es dann bloß so handhaben, daß mehrfache Nennungen einer Adresse pro Mail nur einmal gezählt werden. Und am Besten gibt's dafür dann auch wieder ne Option.

Gute Idee, ich würde sie auch nur 1x pro Mail zählen wollen.

Außerdem ließe sich bestimmt auch einfach ein Logfile einbauen. Da würden dann erstmal sämtliche Fundorte vermerkt und wir können dann nach ein paar Monaten Probelauf gucken, auf welche Felder die Suche am Besten ausgeweitet werden sollte.

Wenn sich das mit Deinen Programmierkenntnisssen bewerkstelligen läßt, umso besser

Hinsichtlich der Zumüll-Problematik hilft denke ich der mitgespeicherte Timestamp. Sollte die Datenbank wirklich mal zu groß werden, kann man sie dann ja ähnlich wie den lernenden Filter per Hand oder vielleicht auch automatisch aufräumen.

s.o.
Ich denke, daß zwischen den Bereinungen der Listen mindestens 4 Wochen vergehen sollten. Dann kann die Liste aber im Einzelfall schon mehrere tausend Einträge habe, evtl. sogar 10.000.
Ich habe mich bis jetzt wenig mit Datenbanken solchen Ausmaßes beschäftigt. Falls dies kein Problem sein sollte, ziehe ich meine Einwände diesbzgl. gerne zurück!

Herzlichen Glückwunsch noch mal, daß das Plugin-Skelett schon mal läuft.
Mit froher Erwartung hoffe ich schon auf Deine Tipps zur C++ Plugin Programmierung!

[Burkart]

Hallo, Quellcore!

Mir sind außer dem von Dir bereits erwähnten 'Received:'-Feld noch folgende interessante Felder aufgefallen:

• Delivered-To:
• X-Originating-Email:
• X-Sender:
• CC:
• BCC:

X-Originating-Email und X-Sender geben ja Senderadressen an, sind also uninteressant. Selbiges gilt auch für das noch nicht genannte Return-Path. CC sollte natürlich genau wie To von Anfang an gefiltert werden. Aber gibt es wirklich Mails mit einem BCC-Feld? Denn eigentlich ist der Trick ja gerade, per SMTP einen Empfänger anzugeben (mittels RCPT-Kommando), der in der Mail selbst nicht auftaucht. So gesehen wäre allein die Existenz eines BCC-Feldes ja schon ein Indiz für Spam. Und was Delivered-To angeht, steht da nicht immer meine tatsächliche Adresse? Müßte ich in Zukunft drauf achten.

Wenn man davon ausgeht, daß ungefähr die hälfte der Absender-Adressen gefälscht ist, dann kommt man immer noch auf mehrere hunder neuer Adressen, die pro Tag auf die Blacklist Deines Filters kommen

Moment, es werden ja nicht die Absender- sondern die Empfänger-Adressen überprüft. Ich sammle seit mehr als einem Jahr falsche Empfängeradressen und habe inzwischen ca. 250 Stück in meiner Liste. Jetzt kriege ich natürlich nicht hunderte Spam-Mails am Tag. Was ich sagen will ist, daß (bei mir) nicht soooo furchtbar viele unterschiedliche falsche Empfangsadressen auftauchen

Wenn sich das (Logfile, Anm.) mit Deinen Programmierkenntnisssen bewerkstelligen läßt, umso besser

Ich stelle mir das so vor, daß einfach im gesamten Header nach dem @-Zeichen gesucht wird. Das Message-ID-Feld wird dann ignoriert, alle anderen werden einfach in eine fortlaufende Textdatei geschrieben. Programmiertechnisch ist das kein Ding.

Ich denke, daß zwischen den Bereinungen der Listen mindestens 4 Wochen vergehen sollten. Dann kann die Liste aber im Einzelfall schon mehrere tausend Einträge habe, evtl. sogar 10.000.

Warten wir's mal ab.

Ich habe mich bis jetzt wenig mit Datenbanken solchen Ausmaßes beschäftigt. Falls dies kein Problem sein sollte, ziehe ich meine Einwände diesbzgl. gerne zurück!

Auch ich bin kein Datenbankprogrammierer. Deshalb gilt auch hier: Abwarten.

Bye, Burkart

[Quellcore]

Hallo Burkart,
da haben wir uns bei eingen Punkten mißverstanden.

X-Originating-Email und X-Sender geben ja Senderadressen an, sind also uninteressant. Selbiges gilt auch für das noch nicht genannte Return-Path. CC sollte natürlich genau wie To von Anfang an gefiltert werden. Aber gibt es wirklich Mails mit einem BCC-Feld? Denn eigentlich ist der Trick ja gerade, per SMTP einen Empfänger anzugeben (mittels RCPT-Kommando), der in der Mail selbst nicht auftaucht. So gesehen wäre allein die Existenz eines BCC-Feldes ja schon ein Indiz für Spam. Und was Delivered-To angeht, steht da nicht immer meine tatsächliche Adresse? Müßte ich in Zukunft drauf achten.

Anscheinend sind wir ja auf gleichem Wege zur Idee eines lernenden Bad-Recipient-Filters gekommen.
Ich habe über einen langen Zeitraum falsche Empfänger (To/CC/BCC) in den Substringfilter eingetragen.
Beim Nachprüfen einiger Mails, die dann später aufgrund meiner Einträge durch den Substring-Filter ausgesondert worden sind, waren dann diese 'schlechten' Adressen aber nicht in einem der Empfängerfelder (To/CC/BCC), sondern in den oben von mir aufgezählten. (Delivered-To:/X-Originating-Email:/X-Sender:/)
Daher auch meine Idee, den Filter auf den gesamten Header loszulassen.

Leider gibt es auch Mails mit dem BCC-Feld, ich glaube, daß sogar eine Version der Outlook-Reihe solche Mails erzeugt. Ich gebe Dir natürlich Recht, daß das den Sinn so eines BlindCopyCarbon arg in Frage stellt.

Diese schlechten Adressen sind bei mir uch schon mal im "Delivered-To"-Feld aufgetaucht.

Moment, es werden ja nicht die Absender- sondern die Empfänger-Adressen überprüft. Ich sammle seit mehr als einem Jahr falsche Empfängeradressen und habe inzwischen ca. 250 Stück in meiner Liste. Jetzt kriege ich natürlich nicht hunderte Spam-Mails am Tag. Was ich sagen will ist, daß (bei mir) nicht soooo furchtbar viele unterschiedliche falsche Empfangsadressen auftauchen

Du hattest ja im vorigen Post folgendes geschrieben:

Was dann das Lernen angeht, warum da nicht auch alle Adressen miteinbeziehen?

Ich wollte deswegen nicht alle Adressen des Headers für das Lernen mit einbeziehen, da man dann ja auch die (so oft fiktiven) Absenderadressen mit drin hätte und dann die Liste doch extrem schnell und unnötig wachsen würde. Falls Du die doch ausschließen wolltest, ist ja alles in Butter.
Dein Erfahrungswert von ca. 250 Einträgen (ohne Beachtung der Absender) nach ca. 1 Jahr deckt sich mit meinen Beobachtungen.

Ich hoffe, daß Du jetzt meine Idee, bei der Klassifizierung den gesamten Header zu untersuchen, beim Lernen aber nur die Empfänger zu berücksichtigen, besser verstehst.

[Burkart]

Hallo, Quellcore!

Ich hoffe, daß Du jetzt meine Idee, bei der Klassifizierung den gesamten Header zu untersuchen, beim Lernen aber nur die Empfänger zu berücksichtigen, besser verstehst.

Ja, habe ich jetzt besser verstanden und halte es so, wie Du es beschrieben hast, für gut. Je nachdem wie die Erfahrungen sind, auch die von Leuten mit hundertmal mehr Spam als ich, ließe sich das Lernen ja immernoch mal auf andere Felder ausdehnen.

Die Plugin-Entwicklung ging noch nicht ganz so rasch voran wie angepeilt, inzwischen ist es aber so weit, daß bei allen ankommenden Mails die Zeilen mit @-Zeichen in eine Log-Datei geschrieben werden. Bei mir sind seitdem jedoch noch nicht genug Mails angekommen, um aus den gesammelten Daten sinnvoll auf die von Spammern verwendeten Header-Fields zu schließen.

Leider gibt es auch Mails mit dem BCC-Feld, ich glaube, daß sogar eine Version der Outlook-Reihe solche Mails erzeugt. Ich gebe Dir natürlich Recht, daß das den Sinn so eines BlindCopyCarbon arg in Frage stellt.

Ich habe aus anderen Gründen mal die zuständige RFC2822 konsultiert und bin dabei auf den Seiten 21 und 36 über eine Beschreibung des BCC-Feldes gestoßen. Kurz: Obwohl sicherheitstechnisch bedenklich, wird es trotzdem vom Standard zugelassen und macht mitunter Sinn.

Bye, Burkart

[Burkart]

Hallo, Quellcore et al!

Wie gesagt schreibt mein Plugin eine Logdatei mit allen Header-Fields, die ein @-Zeichen enthalten, in der Annahme, daß das dann in der Regel E-Mail-Adressen sind. Inzwischen habe ich festgestellt, daß auch oft das Subject eine Mail-Adresse enthält. Zum Einen ist das legitimerweise meine eigene, z.B. "Newsletter xy an foo@bar" oder "web.de Spam-Report für dingsbums@web.de". Außerdem ist das manchmal bei Spam-Mails der Fall, z.B. enthält das Subject dann ausschließlich meine korrekte Adresse.

Die Frage ist jetzt, ob das Subject genau wie alle anderen Header-Felder in die Suche nach bekannten Adressen einbezogen werden sollte oder nicht. Ich selbst bin mir da sehr unschlüssig.

Bye, Burkart