Seite 1 von 2

Zugriff auf Nachrichtentext in mehrteiliger MIME-Nachricht

BeitragVerfasst: 17. Apr 2010, 21:34
von Quellcore
Hallo allerseits,

Ich hatte es in einem anderen Thread schon einmal angedeutet:
Quellcore hat geschrieben:Ich habe noch einen triftigeren Grund, der aber eine ziemlich ausladende Erklärung erfordert und letztendlich auf ein Feature Request bzw. eine Bug Report für den Spami hinausläuft.
Kurz gesagt: Ein Großteil meines Mailaufkommens lässt sich nur über Daten aus dem Header korrekt klassifizieren, da der Mailtext für den Spami nicht sichtbar ist.
Filter wie der lernende Filter, der Spamwortfilter, DCC können also nicht zur Klassifizierung beitragen.

Ich weiß immer noch nicht, ob es sich um ein Bug Report oder ein Feature Request handelt, im Zweifelsfall aber immer für den Angeklagten, also ein Feature Request. :mrgreen:

Bei einem meiner Konten bekommen ich nun alle eingehenden Mails als MIME-Anhang an eine andere Adresse "weitergeleitet".

Spami hat keinen Zugang zu dem MIME-Teil, was das Filtern natürlich extrem erschwert und nahezu unmöglich macht, wenn ich da nicht täglich am Regelfilter schrauben würde. :wink:
So sieht eine Original-Nachricht auf dem Hansenet-Server aus:
Code: Alles auswählen
Return-Path: <username@domain1.de>
Received: from [173.2.219.165] by email.hansenet.de with HTTP; Sat, 17 Apr 2010 20:44:35 +0200
Date: Sat, 17 Apr 2010 14:44:35 -0400
Message-ID: <4BA843890000015F@mfsv011.hansenet.de>
From: "Vorname Nachname" <username@domain1.de>
Subject: Testmail, Spam Text im MIME-Teil wird nicht erkannt
Reply-To: username@domain2.de
To: username@domain1.de
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

* POLICY VIOLATION ! *
* POLICY VIOLATION ! *

Diese Mail wird dann als Kopie an meinen GMX-Account verschickt, so dass ich dann letztendlich die Mail als MIME-Anhang erhalte:
Code: Alles auswählen
Return-Path: <>
X-Flags: 0000
Delivered-To: GMX delivery to username@domain2.de
Received: (qmail invoked by alias); 17 Apr 2010 18:44:38 -0000
Received: from mail01.hansenet.de (EHLO email.hansenet.de) [213.191.73.61]
  by mx0.gmx.net (mx068) with SMTP; 17 Apr 2010 20:44:38 +0200
Received: by email.hansenet.de (8.0.026) id 4BA8438000DEF47B for username@domain2.de; Sat, 17 Apr 2010 20:44:37 +0200
Sender: postmaster@post.hansenet.de
From: "Vorname Nachname" <username@domain1.de>
Subject: Testmail, Spam Text im MIME-Teil wird nicht erkannt
To: username@domain2.de
Date: Sat, 17 Apr 2010 20:44:37 +0200
Message-ID: <4BA8438000DEF47A@mfsv011.hansenet.de>
Delivered-To: username@domain1.de
Precedence: junk
MIME-Version: 1.0
Content-Type: Multipart/Mixed; boundary="========/4BA8438000DEF47A/email.hansenet.de"
X-GMX-Antivirus: 0 (no virus found)
X-GMX-Antispam: -2 (not scanned, spam filter disabled);
 Detail=5D7Q89H36p4L00VTXC6D4q0N+AH0PUCnKGJbGgJLbSXk30NezpdxUg==V1;
X-GMX-UID: pDf/esVubUkovTUrSWkn+5xkZ2hlNwot

Dies ist eine mehrteilige MIME-Nachricht.
Wenn Sie diesen Text sehen, kann Ihr Mail-Client MIME-formatierte
Nachrichten eventuell nicht richtig verarbeiten.
Weitere Informationen hierzu finden Sie unter RFC 2045 bis 2049.

--========/4BA8438000DEF47A/email.hansenet.de
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

  -----  The attached message is an automatically
  -----  generated copy of mail delivered to username@domain1.de


--========/4BA8438000DEF47A/email.hansenet.de
Content-Type: Message/RFC822

Return-Path: <username@domain1.de>
Received: from [173.2.219.165] by email.hansenet.de with HTTP; Sat, 17 Apr 2010 20:44:35 +0200
Date: Sat, 17 Apr 2010 14:44:35 -0400
Message-ID: <4BA843890000015F@mfsv011.hansenet.de>
From: "Vorname Nachname" <username@domain1.de>
Subject: Testmail, Spam Text im MIME-Teil wird nicht erkannt
Reply-To: username@domain2.de
To: username@domain1.de
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

* POLICY VIOLATION ! *
* POLICY VIOLATION ! *



--========/4BA8438000DEF47A/email.hansenet.de--

  • Der lernende Filter vertut sich bei der Klassifizierung ständig, da er nur die Zeilen im Header (Betreff, Absender und Empfänger) zur Klassifizierung heranzieht
  • Der Link-Filter sieht natuerlich keine Links, da diese im MIME-Teil stehen
  • Der DCC-Filter ist machtlos, da die Prüfsummen natürlich komplett anders sind.
  • Der Spamwort-Filter hat das gleiche Problem wie der lernende Filter, nur der Betreff wird gescannt.
  • Filter zur Erkennung von Spam, die in meinem Fall weiterhin funktionieren, da sie mit den Headerdaten arbeiten, sind z.B. Regelfilter, Bad-Recipient-Filter, Misnamed-Filter

Hintergrund:
Ich habe eine Uralt-Mailadresse von Hansenet, beim sogannten Speed-Komplett Paket war damals vieles mit dabei, so z.B. Webspace, eigene Domain, usw...
Nichts davon dürfte mehr funktionieren, da wir den Vertrag vor Jahren aufgelöst (grobe Schätzung: 2004 :lol: ) haben.
Dem ist aber nicht so, bis vor kurzem lief alles noch ohne Einschränkungen.
Dann wurde bei Alice wohl etwas umgestellt, die Mailserver für den Pop3-Zugriff lassen mich nicht mehr per POP3 zugreifen, das ist bestimmt aber nur ein Nebeneffekt und nicht geplant gewesen.
Nach wie vor kann ich mich noch über das alte Webportal über die persönliche Domain einloggen.
In den Einstellungen auf dem Webportal habe ich versucht eine Weiterleitung einzurichten, die Funktion scheint aber ebenso nicht mehr zu funktionieren.
Ich konnte aber die Option "Kopie aller Nachrichten senden an:" wählen und habe dort eine Zweitadresse von GMX eingetragen, so dass ich sie wieder per POP3 von dem GMX-Konto ziehen kann.
Hansenet.png
Hansenet.png (6.85 KiB) 9799-mal betrachtet

Leider sind alle Nachrichten nun als MIME-Anhang "angeheftet".
Da es sich um mein Haupt-Mailkonto handelt, möchte ich nur sehr ungern auf diesen Account verzichten. Ich glaube wirklich, dass Alice aka Hansenet es niemals spitz bekommen wird, dass diese Domain inkl. Webspace und Mailserver offiziell gelöscht werden dürfte.
Ich habe auch nicht wirklich ein schlechtes Gewissen, da mein damaliger WG-Kollege der eigentliche Vertragsinhaber war und Hansenet sich extrem zickig angestellt hat, als er beim Auszug diesen Vertrag auf seine neue Adresse abändern wollte. Letztendlich haben wir dann den Umständlichen Weg der Kündigung und eines kompletten Neuvertrages für ihn gewählt.
Er ist übrigens heute noch Alice-Kunde und bezahlt somit irgendwie auch für unseren alten Webspace und Mailserver.
Wir werden uns also still verhalten und hoffen, dass unsere Domain auf ewig weiterlebt.

Gruß,
Quellcore

Re: Zugriff auf Nachrichtentext in mehrteiliger MIME-Nachricht

BeitragVerfasst: 18. Apr 2010, 10:16
von anbuva
Hallo Quellcore!

eine interessante Info. Leider bin ich da jetzt auch kein Spezialist, als dass ich jetzt was sinnvolles dazu beitragen könnte.

Gruß
anbuva

Re: Zugriff auf Nachrichtentext in mehrteiliger MIME-Nachricht

BeitragVerfasst: 19. Apr 2010, 07:05
von Andreas_Z
Hallo Quellcore!

Du möchtest also. dass Spami auch die Mime-Parts auseinandernimmt und untersucht. Soweit reicht mein Hintergrundwissen dann leider auch nicht. Das ist dann wohl eher ein Fall für Michel. Nicht dass Spami diese Dinger wirklich schon untersucht und nicht klar kommt.

Gruß
Andreas_Z

Re: Zugriff auf Nachrichtentext in mehrteiliger MIME-Nachricht

BeitragVerfasst: 19. Apr 2010, 22:11
von Quellcore
Andreas_Z hat geschrieben:Nicht dass Spami diese Dinger wirklich schon untersucht und nicht klar kommt.

Mein Reden, deswegen bin ich mir halt nicht sicher, ob es Bug Report oder ein Feature Request ist.
Ich bin ja leider auch Vollblutlaie wenn es um die Spezifikationen von E-Mails geht, ich möchte mich aber nicht länger damit abfinden, dass Spami bereits seit weit über einem Jahr partout mit diesen Mails nicht zurecht kommen will.

Ich habe soeben noch mal eine Mail im Papierkorb genauer angeschaut und dabei festgestellt, dass Spami sehr wohl den ersten MIME-Teil scannt, der lernende Filter benutzt die dort auftauchenden Wörter für die Klassifizierung.
Code: Alles auswählen
--========/4BA8438000DEF47A/email.hansenet.de
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

-----  The attached message is an automatically
-----  generated copy of mail delivered to username@domain1.de


Die Frage ist jetzt nur warum der zweite, in meinem Fall wichtigere MIME-Part nicht gescannt wird.
Entweder es wird immer nur der erste MIME-Part gescannt oder es hängt mit dem "Content-Type" zusammen.

Der ursprüngliche Nachrichtentext wird im Quelltext durch folgendes eingeleitet:
Code: Alles auswählen
--========/4BA8438000DEF47A/email.hansenet.de
Content-Type: Message/RFC822

Hier ist der Content-Type "Message/RFC822" anstatt wie im ersten MIME-Teil "text/plain; charset=ISO-8859-1"

Vielleicht liegt da der Hase im Pfeffer :!:

Gruß,
Quellcore

Re: Zugriff auf Nachrichtentext in mehrteiliger MIME-Nachricht

BeitragVerfasst: 20. Apr 2010, 06:33
von Andreas_Z
Hallo Quellcore!

das halte ich auch für sehr warscheinlich. Hier ist Michel gefragt. Mal sehen, was er dazu sagt....

Gruß
Andreas_Z

Re: Zugriff auf Nachrichtentext in mehrteiliger MIME-Nachricht

BeitragVerfasst: 21. Apr 2010, 20:13
von michel
Quellcore hat geschrieben:Hier ist der Content-Type "Message/RFC822" anstatt wie im ersten MIME-Teil "text/plain; charset=ISO-8859-1"

Das ist exakt der Grund. Spamihilator durchsucht lediglich die Teile einer E-Mail, deren Content-Type mit "text/" beginnen. Andere Content-Types weisen auf einen Anhang im klassischen Sinne hin (also z.B. eine PDF-Datei oder ein Bild). Soetwas wird nicht durchsucht, da binäre Daten das Programm durcheinander bringen können.

Allerdings hört sich der Content-Type "Message/RFC822" nach einem an, den man zusätzlich noch unterstützen könnte. Ich muss das recherchieren und setze es auf die TODO-Liste.

Gruß
Michel

Re: Zugriff auf Nachrichtentext in mehrteiliger MIME-Nachricht

BeitragVerfasst: 21. Apr 2010, 21:48
von Quellcore
michel hat geschrieben:Allerdings hört sich der Content-Type "Message/RFC822" nach einem an, den man zusätzlich noch unterstützen könnte. Ich muss das recherchieren und setze es auf die TODO-Liste.

Das klingt doch mal super, ich bin begeistert.
Dieser Content-Type scheint ja auch regelkonform zu sein, im Quelltext ist der Nachrichtentext vollständig lesbar und Thunderbird zeigt diese Nachrichten problemlos an.
Sollte Deine Recherche zum Schluss kommen, dass das Scannen dieses MIME-Teils nicht in Spami umgesetzt wird, muss man ja schon fast davor Angst haben, dass dies als neue Spam-Masche benutzt wird.

Gruß,
Quellcore

Re: Zugriff auf Nachrichtentext in mehrteiliger MIME-Nachricht

BeitragVerfasst: 22. Apr 2010, 16:29
von anbuva
Quellcore hat geschrieben:Sollte Deine Recherche zum Schluss kommen, dass das Scannen dieses MIME-Teils nicht in Spami umgesetzt wird, muss man ja schon fast davor Angst haben, dass dies als neue Spam-Masche benutzt wird.

:shock:

Re: Zugriff auf Nachrichtentext in mehrteiliger MIME-Nachricht

BeitragVerfasst: 23. Apr 2010, 06:47
von Andreas_Z
Hallo Quellcore!

Ich glaube, davor brauchen wir keine Angst haben. Die anderen Content-Types lassen sich ja zum Großteil mittels anderer Filter aussieben (Anhänge).

Gruß
Andreas_Z

Re: Zugriff auf Nachrichtentext in mehrteiliger MIME-Nachricht

BeitragVerfasst: 23. Apr 2010, 12:50
von anbuva
Hallo Andreas_Z!

Ich glaube, davor brauchen wir keine Angst haben...

puhh... :D

Gruß
anbuva

Re: Zugriff auf Nachrichtentext in mehrteiliger MIME-Nachricht

BeitragVerfasst: 6. Jun 2010, 13:30
von michel
Hi!

Ich brauche hierzu noch einmal eure Hilfe. Der Content-Type "Message/Rfc822" besagt, dass an diese E-Mail eine weitere angehängt ist. Wie man in dem Beispiel von Quellcore sehen kann, ist das eine vollständige Nachricht mit Header und Body. Es gibt nun mehrere Möglichkeiten wie Spamihilator das ganze interpretieren könnte:

1) Die Mails werden gemeinsam betrachtet, wobei der Header der angehängten Nachricht übersprungen wird. Das führt dazu, dass die meisten Filter den Inhalt der angehängten Nachricht sehen, aber den Header nicht mehr. Das heißt, nach letzterem kann nicht gefiltert werden.

2) Die Mails werden gemeinsam betrachtet, der Header der angehängten Nachricht wird in den Text hinein kopiert. Die Filter könnten nun zumindest auch den Header der angehängten Nachricht nach Schlüsselwörtern durchsuchen, diesen aber nicht mehr als solchen erkennen.

3) Die Mails werden gemeinsam betrachtet, wobei der Header der angehängten Nachricht an den Header der ersten angehängt wird. Header bleibt hierbei Header und Body bleibt Body. Alle Filter sehen alles. Das Problem ist lediglich, dass man die Headers zweier Nachrichten vermischt und dadurch auch doppelte Einträge für Betreff, Absender, Datum, usw. hat. Die meisten Filter werden nur einen von diesen Einträgen (den ersten?) betrachten. Der andere wird wahrscheinlich ignoriert.

4) Die Mails werden getrennt betrachtet, d.h. es gibt zwei Filterdurchläufe. Einen für die gesamte Nachricht und dann noch einen für die innere Nachricht. Dadurch ist die beste Kompatibilität mit allen Filtern sichergestellt. Außerdem werden wirklich alle Teile der Mail betrachtet. Die einzige Frage: Was macht man mit den beiden Ergebnissen? Wenn z.B. das Ergebnis der ersten Filterung besagt, dass die Mail "Non-Spam" ist und das der zweiten liefert "Spam". Welches Ergebnis ist dann das richtige?

Ich hoffe, ihr könnt gute Anregungen für dieses Problem liefern.

Vielen Dank im Voraus!
Michel

Re: Zugriff auf Nachrichtentext in mehrteiliger MIME-Nachricht

BeitragVerfasst: 6. Jun 2010, 13:54
von Chactory
Hallo zusammen!

Quellcores Fall dürfte so sehr selten vorkommen, deshalb habe ich den Thread zuerst nicht sehr aufmerksam gelesen. In letzter Zeit erhalte ich jedoch immer mehr Mails mit hineinkopierter Mail, also keine Weiterleitung, sondern vermutlich mit Drag&Drop hineinkopiert.

Ich finde Lösung 4 am zutreffendsten. Michel offenbar auch, sonst hätte er es nicht zur Diskussion gestellt, denn nur aus 4 entstehen weitere Fragen.

Beide Mails gehören jeweils getrennt in den Trainingsbereich, die "innere" Mail als solche gekennzeichnet.

Vermutlich sollte die Übergabe einer Mail mit zusätzlicher Huckepack-Spammail durch den User einstellbar sein. Grundeinstellung: Wenn die Trägermail kein Spam ist, dann zusammen Non-Spam.

Allerdings tritt dann wirklich das Problem auf, wie Quellcore schrieb, daß es zu einer Masche werden könnte. Hier wäre dann übrigens Bob Loefflers exzellenter Emptymailfilter machtlos. Vermutlich erhält man solche Mails in Mails aber sowieso nur von Freunden und kann diese entsprechend in die Freundliste einstellen.

Gruß, Chactory

Re: Zugriff auf Nachrichtentext in mehrteiliger MIME-Nachricht

BeitragVerfasst: 6. Jun 2010, 16:07
von anbuva
Hallo,

ich tendiere zu :
michel hat geschrieben:4) Die Mails werden getrennt betrachtet, d.h. es gibt zwei Filterdurchläufe. Einen für die gesamte Nachricht und dann noch einen für die innere Nachricht. Dadurch ist die beste Kompatibilität mit allen Filtern sichergestellt. Außerdem werden wirklich alle Teile der Mail betrachtet.

gerade wegen der Kompatibilität und der Gesamtbetrachtung die wohl beste Lösung.

Die einzige Frage: Was macht man mit den beiden Ergebnissen? Wenn z.B. das Ergebnis der ersten Filterung besagt, dass die Mail "Non-Spam" ist und das der zweiten liefert "Spam". Welches Ergebnis ist dann das richtige?

Bei unklaren Ergebnissen sollte dann der User wählen können, ob er es lieber als Spam oder Non-Spam sehen möchte. Im Zweifelsfall würde ich hier z. B. Spam wählen wollen.

Gruß
anbuva

Re: Zugriff auf Nachrichtentext in mehrteiliger MIME-Nachricht

BeitragVerfasst: 6. Jun 2010, 16:35
von Patti
Hallo michel!

Die einzige Frage: Was macht man mit den beiden Ergebnissen? Wenn z.B. das Ergebnis der ersten Filterung besagt, dass die Mail "Non-Spam" ist und das der zweiten liefert "Spam". Welches Ergebnis ist dann das richtige?


Waere es da nicht moeglich, dann an die anderen Filter zur "nachkontrolle" zu uebergeben ?

Gruß
Patti

Re: Zugriff auf Nachrichtentext in mehrteiliger MIME-Nachricht

BeitragVerfasst: 6. Jun 2010, 16:40
von anbuva
Hallo Patti!

daran habe ich im ersten Durchlauf noch gar nicht gedacht :idea: Klar, das wäre natürlich auch eine Idee!

Gruß
anbuva