Emails verarbeiten - Indy ist nicht gut genug :(

[adrian4321]

Hallo!

Ich arbeite seit längerer Zeit mit Indy, um eingehende Emails systematisch in Textteil, Attachment-Dateien, Absender, Betreff usw. aufzugliedern und in einer Art Bürosystem zu verwalten.

Leider gibt es permanent irgendwelche Emails, bei denen Indy versagt. Da werden z.B. komplette MultiParts unterschlagen, Textkörper falsch decodiert (z.B. bei Umlauten), Content-Types bleiben leer, weil der Header nicht richtig ausgelesen wird und und und.
Dabei aktualisiere ich regelmäßig auf das neueste Indy-Paket.

Indy ist leider einfach nicht gut genug - was z.B. Outlook oder Thunderbird klaglos anzeigt, bringt Indy ins Straucheln.

Daher meine Frage: Wie kann ich Emails ähnlich zuverlässig wie die gängigen Clients es tun "decodieren"? Kann ich Outlook automatisieren und dafür einsetzen, oder gibt es andere, gute Komponenten für Delphi?

Auch dachte ich an die Möglichkeit, über einen exterenen Aufruf irgendein geeignetes Modul aufzurufen, das mir die Mails dann decodiert oder Dateien für Text, Attachments usw. anlegt, die ich dann mit meinem Delphi-Programm aufgreifen kann? Leider wüsste ich aber nichts, was ich dafür nutzen könnte!

Ich danke Euch für jegliche Lösungsansätze ;)

[mkinzler]

Vielleicht erhältst du hier ein paar Anregungen

[Bernhard Geyer]

Wir setzen auf IP*Works.

Kostest zwar ein paar €, aber haben eigentlich wenig Problem damit.
Alternativ wäre auch ICS wenn man auf SSL verzichten kann ganz gut.

[HPW]

Ich habe mit der extended MAPI vom Imibo gute Erfahrung gemacht.
Die Sample- und Request- Beispiel-Projekte waren dabei hilfreich.

http://www.imibo.com/imidev/delphi/les/index.html

[mkinzler]

extenden MAPI hilft dir aber nur beim Zugriff auf einen Exchange o.ä.

[adrian4321]

Zitat:

Zitat von Bernhard Geyer

Wir setzen auf IP*Works.

Kostest zwar ein paar €, aber haben eigentlich wenig Problem damit.
Alternativ wäre auch ICS wenn man auf SSL verzichten kann ganz gut.

Danke für den Tipp, ich habe mir gerade die Demo von IP* Works heruntergeladen und etwas damit gespielt. Sieht soweit nicht schlecht aus, konnte auch einen "Problemfall", mit dem Indy nicht zurecht kommt, decodieren.

Wie sieht es da mit UTF-8-codierten Texten/Dateinamen aus, und wisst Ihr, ob lange Dateinamen mit Zeilenumbrüchen im Header Ärger machen?

Setzt Du die Komponente wirklich im "harten Alltag" ein, wo von einfachen Textmails über komplexe Mime-Strukturen mit großen Anhängen bis hin zu Spam alles vertreten ist?

Wenn das wirklich was taugt, würde ich das Geld auch gerne investieren.

[Assertor]

Hi,

Zitat:

Zitat von adrian4321

einen "Problemfall", mit dem Indy nicht zurecht kommt, decodieren.

Hast Du denn eigentlich mal Deine entdeckten Problemfälle irgendwo irgendwem gemeldet oder mitgeteilt? Die Delphi Community hat ja sowieso das Problem, das viele kostenlose Komponenten verwenden wollen, aber keinerlei Bereitschaft besteht, zu helfen. Auch Bugreports können helfen! Die Delphi Community soll doch keine Informationeinbahnstraße sein.

Also, her mit Beispieldateien, mit denen Indy nicht zurechtkommt! Die werde ich mir dann mal ansehen und auch an unser Team weiterleiten.

Als Hintergrund sei übrigens erwähnt: Mal eben E-Mail verarbeiten gibt es nicht, hier sind Standards definiert - die sind auch nicht das Problem. Das Problem sind irgendwelche Server oder Anwendungen, die vom Standard aus teilweise unnachvollziehbaren Gründen abweichen. Wird ja auch gerne von Spam oder Trojanern verwendet, um Prüfungen auszuhebeln.

Gleich Komplexität gibt es z.B. bei FTP Servern, wo Indy über 30 Listparser-Klassen hat, nur um die Rückgaben von Abweichlern zu verarbeiten.

Gerade im Bereich der E-Mail Verarbeitung hat sich aber in den Indy Versionen seit D2009 einiges getan, hier sind Probleme wegen verschiedener Zeichensätze adressiert wurden - was für Nicht-Unicode Delphi Versionen sowieso immer etwas problematisch war.

Bitte gib mit dem Bugreport auch an, ob Du tatsächlich D2005 verwendest (ist das nicht eins der verbuggten Delphis, die es gibt?).

Und zu guter letzt: Mir ist auf Anhieb ein im professionellen E-Mail/Exchange Bereich tätiger Software-Hersteller bekannt, welcher die E-Mail Verarbeitung seit Jahren auch mit und über Delphi & Indy abwickelt. Also es geht schon, aber Indy kann Dir nicht alles abnehmen, insbesondere wenn die Eingabedaten teilweise einfach falsch sind.

Gruß Assertor

[adrian4321]

Ja, ich habe auch schon mehrere Problemfälle direkt an die Entwickler weitergeleitet. Da hat sich mal mehr und mal weniger getan, aber so oder so bleibt es ein Katz- und Maus-Spiel und es treten einfach zu viele Probleme auf, als dass man hier von zuverlässiger Verarbeitung sprechen könnte.
Ich bin also durchaus bereit, den kostenlosen Projekten unter die Arme zu greifen - aber hier brauche ich etwas zuverlässiges, und dann ist es auch kein Problem, wenn das Geld kostet.

Sicher liegt es oft daran, dass Standards nicht ganz eingehalten werden, aber ich habe leider nicht die Macht über all die Anwendungen, die das unsaubere Zeugs verschicken. Und letztlich war es in allen Fällen doch so, dass Thunderbird oder Outlook auch mit diesen Mails zurecht kamen, Indy jedoch nicht.

Ich poste einfach mal den letzten Problemfall in gekürzter Fassung:

Zitat:

Return-Path: a@b.c
X-Original-To: a@b.c
Delivered-To: a@b.c
Received: from localhost (localhost [127.0.0.1])
by mail.xxxx.eu (Postfix) with ESMTP id 475A34DFA0
for <a@b.c>; Fri, 17 Jul 2009 20:26:40 +0200 (CEST)
From: <a@b.c>
To: "a@b.c" <a@b.c>
Content-Base: http://127.0.0.1/AIMS/Notification/
Date: Fri, 17 Jul 2009 13:25:59 -0500
Subject: =?utf-8?Q?blabla?=
=?utf-8?Q?blablubb?=
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="_=aspNetEmail=_a7d6bc7105194e67aceb78eb2 7f64571"
Content-Transfer-Encoding: quoted-printable
X-Mailer: aspNetEmail ver 2.5.0.0
X-RCPT-TO: <a@b.c>
Message-ID: <DLEV2557053b7c611c14fb783c4ed958e5ab673@dlev255 >
X-Virus-Scanned: amavisd-new at xxxx.eu
X-Spam-Status: No, score=-0.824 tagged_above=-999 required=5 tests=[AWL=0.316,
BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457,
NORMAL_HTTP_TO_IP=0.001]
X-Spam-Score: -0.824
X-Spam-Level:

--_=aspNetEmail=_a7d6bc7105194e67aceb78eb27f64571
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

=0D=0A<=21DOCTYPE HTML PUBLIC =22-//W3C//DTD HTML 4=2E0 Transitional//EN=22=
[blabla]
=0A</HTML>=0D=0A

--_=aspNetEmail=_a7d6bc7105194e67aceb78eb27f64571
Content-Type: image/gif; name="Aims.gif"
Content-Transfer-Encoding: base64
Content-ID: <image_0000>

R0lGODlhSAAlANUA[bla]
AAOw==

--_=aspNetEmail=_a7d6bc7105194e67aceb78eb27f64571--

Das Problem: Ich krieg den Content-Type "text/html" nicht. Die Content-Type-Eigenschaft bleibt leer.
Lösche ich aus dem Haupt-Header "Content-Transfer-Encoding: quoted-printable" heraus, dann funktioniert es.... Das ist nur einer von vielen Fällen, wo einfach bisschen was schief geht, und deswegen die ganze Mail letztendlich unlesbar ist.

Und ja, ich nutze wirklich noch D2005 (mehr brauche ich irgendwie nicht, ich arbeite meist auch noch mit Win2k ;)) - die Indys habe ich aber selbstverständlich aktualisiert.

[mkinzler]

Da in D2005 auch nur der Compiler von D7 Update 2 steckt, würde ich D7 vorziehen. Sonst halt TD(E) oder neuer

[adrian4321]

Glaub ich Euch ja alles gerne, aber ich glaube nicht, dass meine aktuellen Probleme damit zusammenhängen... Und ansonsten hatte ich mit D2005 nie Probleme, ich stelle aber auch wirklich keine ausgefallenen Sachen damit an ;)

[Assertor]

Hallo,

Zitat:

Zitat von adrian4321

die Indys habe ich aber selbstverständlich aktualisiert.

Quelle SVN oder Fulgan Mirror, Tiburon Branch, korrekt?

Zitat:

Zitat von adrian4321

so bleibt es ein Katz- und Maus-Spiel und es treten einfach zu viele Probleme auf, als dass man hier von zuverlässiger Verarbeitung sprechen könnte.

Doch bei korrekten Daten arbeitet es zuverlässig. Bei fehlerhaften Eingabedaten ist dies immer so, egal mit welcher Komponente. Ich verstehe Dein Problem natürlich, aber befürchte so einfach ist es nicht zu lösen. Teste IP*Works oder was auch immer mit diesen Daten, aber sei dann bitte auch so ehrlich und poste hier das Ergebnis. Eine Demo von anderen Komponenten sollte zum Testen ja reichen. Bin sehr gespannt auf das Ergebnis.

Niemand würde z.B. eine Kompressions-Komponente daran messen, wie diese aus defekten oder fehlenden Daten versucht zu erraten, was ursprünglich vorhanden war oder wie dies im Sinne des jeweiligen Benutzers gerne abgewandelt werden sollte.

Zitat:

Zitat von adrian4321

Ich poste einfach mal den letzten Problemfall in gekürzter Fassung:

Diese Daten 1:1 gespeichert, zeigt mir Outlook bzw. Vista Mail nicht korrekt an. Thunderbird bleibt ebenso leer. Was soll Indy da denn nun anders machen?

Screenshot anbei.

Am besten mal eine "anonymisierte" Mail als .eml (also Text) hier im Forum anhängen.

Edit:

Zitat:

Zitat von adrian4321

Glaub ich Euch ja alles gerne, aber ich glaube nicht, dass meine aktuellen Probleme damit zusammenhängen... Und ansonsten hatte ich mit D2005 nie Probleme, ich stelle aber auch wirklich keine ausgefallenen Sachen damit an ;)

Außer das Indy natürlich viele Delphi Funktionen der RTL/VCL nutzt und die Bugs Deines Delphis (im QC gibt es da doch viele) natürlich auch hier zuschlagen.

Der Maßstab "hatte ich mit D2005 nie Probleme" steht im krassen Gegensatz zu einer Software-Qualitätssicherung.

Edit2:
Der Trick bei Outlook und Co besteht wohl eher darin, auch den quoted-printable Teil durch den HTML Render zu jagen. Wenn mal wieder ein Hobbyprogrammierer den HTML Teil im Mailversand in den Textteil packt, wird dieser dann trotzdem angezeigt. Gleiches steht dir auch frei. Du könntest auch prüfen, ob der HTML leer ist und dann ggf. ein Fallback auf den Textteil machen.

Gruß Assertor

[adrian4321]

Zitat:

Zitat von Assertor

Quelle SVN oder Fulgan Mirror, Tiburon Branch, korrekt?

Hier: ftp://indy.fulgan.com/

Zitat:

Doch bei korrekten Daten arbeitet es zuverlässig. Bei fehlerhaften Eingabedaten ist dies immer so, egal mit welcher Komponente. Ich verstehe Dein Problem natürlich, aber befürchte so einfach ist es nicht zu lösen. Teste IP*Works oder was auch immer mit diesen Daten, aber sei dann bitte auch so ehrlich und poste hier das Ergebnis. Eine Demo von anderen Komponenten sollte zum Testen ja reichen. Bin sehr gespannt auf das Ergebnis.

Es arbeitet i.d.R. zuverlässig mit den Daten, die es selber erzeugt hat. Nein, stimmt auch nicht, auch hier hab ich was auf Lager :D
Man erzeuge eine neue Mail, packe einen schönen Abdenser rein wie "Günther, Horst" <[e-mail]>, speichere die Mail, öffne sie wieder und versuche, sie per SMTP zu verschicken. Das kracht, weil beim Öffnen der Mail Name und Mailadresse irgendwie vermischt werden, so dass keine Mailadresse mehr dabei herauskommt. Es macht dabei einige Unterschiede, ob der Name in " " gefasst wird, ob ein Komma enthalten ist und ob Umlaute enthalten sind. Alles mit Indy-Bausteinen erstellt und bearbeitet wohlgemerkt!

Unabhängig davon sind wir uns zu 100% einig, dass viel Mist an Mails erzeugt wird, der nicht regelkonform ist, und dass solche Mails eine Frechheit sind. Aber was will man machen - auch solche Mails sind oft wichtig und werden dennoch von Thunderbird/Outlook anstandslos angezeigt, von Indy leider oft nicht. Klar liegt dabei die Schuld nicht bei Indy!

Was die Testmail von vorhin anbelangt - sorry, die habe ich wohl zu weit gekürzt, anbei nochmal eine Version, die bei mir, ebenso wie das ungekürzte Original mit TB/Outlook problemlos angezeigt wird, mit Indy aber nicht, weil da der Content-Type fehlt. Dabei sieht der Inhalt des Multiparts, den Indy ausgibt, so aus:

Zitat:

Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

=0D=0A<=21DOCTYPE HTML PUBLIC =22-//W3C//DTD HTML 4=2E0 Transitional//EN=22=
>=0D=0A<HTML>Test</HTML>=0D=0A

- der Header wurde wohl garnicht als solcher erkannt, kein Wunder, dass "Content-Type" leer bleibt.

Zitat:

Bei fehlerhaften Eingabedaten ist dies immer so, egal mit welcher Komponente. Ich verstehe Dein Problem natürlich, aber befürchte so einfach ist es nicht zu lösen. Teste IP*Works oder was auch immer mit diesen Daten, aber sei dann bitte auch so ehrlich und poste hier das Ergebnis. Eine Demo von anderen Komponenten sollte zum Testen ja reichen. Bin sehr gespannt auf das Ergebnis.

Das werde ich ausführlich machen (Problemfall anbei funktioniert damit schonmal), und gerne berichte ich dann auch wieder ausführlich!
Es ist halt immer das Theater, dass bei ab und an wiederkehrenden Fehlern gleich die User dem Admin im Nacken sitzen und der Admin mir im Nacken sitzt, immer mit dem Kommentar "Outlook kann es doch auch..." :lol:

[Assertor]

Hi Adrian,

ein später Nachtrag:

Zitat:

Zitat von adrian4321

Es arbeitet i.d.R. zuverlässig mit den Daten, die es selber erzeugt hat. Nein, stimmt auch nicht, auch hier hab ich was auf Lager :D
Man erzeuge eine neue Mail, packe einen schönen Abdenser rein wie "Günther, Horst" <[e-mail]>, speichere die Mail, öffne sie wieder und versuche, sie per SMTP zu verschicken. Das kracht, weil beim Öffnen der Mail Name und Mailadresse irgendwie vermischt werden, so dass keine Mailadresse mehr dabei herauskommt. Es macht dabei einige Unterschiede, ob der Name in " " gefasst wird, ob ein Komma enthalten ist und ob Umlaute enthalten sind. Alles mit Indy-Bausteinen erstellt und bearbeitet wohlgemerkt!

Könntest Du hierfür Code-Beispiele posten oder mir mailen?

Zitat:

Zitat von adrian4321

Unabhängig davon sind wir uns zu 100% einig, dass viel Mist an Mails erzeugt wird, der nicht regelkonform ist, und dass solche Mails eine Frechheit sind. Aber was will man machen - auch solche Mails sind oft wichtig und werden dennoch von Thunderbird/Outlook anstandslos angezeigt, von Indy leider oft nicht. Klar liegt dabei die Schuld nicht bei Indy!

Absolut richtig!

Zitat:

Zitat von adrian4321

Was die Testmail von vorhin anbelangt - sorry, die habe ich wohl zu weit gekürzt, anbei nochmal eine Version, die bei mir, ebenso wie das ungekürzte Original mit TB/Outlook problemlos angezeigt wird, mit Indy aber nicht, weil da der Content-Type fehlt. Dabei sieht der Inhalt des Multiparts, den Indy ausgibt, so aus:

Gut, das konkrete Problem ist nicht die Ausgabe von Indy, sondern die Verarbeitung der Eingabe-Mail: Schon der Top-Level "Content-Transfer-Encoding" Header hat einen ungültigen Wert nach RFC 2045 Abschnitt 6.4:

Zitat:

If an entity is of type "multipart" the Content-Transfer-Encoding is not permitted to have any value other than "7bit", "8bit" or "binary".

Deine Mail hat dort "Quoted Printable" stehen. Dieser falsche Wert führt dann dazu, daß der Indy Parser die MIME Boundaries nicht erkennen kann, da diese ein "=" Zeichen enthalten. Das ist technisch leider 100% korrekt.

Derzeit werden die Daten, die der Parser nicht - weil sie falsch sind - zuordnen kann, in ein eigenes TIdText Objekt gepackt und dann bei TIdMessage.SaveToFile() mit weggeschrieben. Dadurch kommt es dann zu zwei Content-Headern innerhalb der Boundary (der alte wird als einfacher Text betrachtet).

Das ganze geht weiter bei den Attachments. Weil das Haupt-Encoding falsch ist, werden auch diese Daten verformt. Deswegen wird auch zwischen TIdMessage.LoadFromFile() and .SaveToFile() die Message scheinbar zerstört.

Zitat:

Zitat von adrian4321

Es ist halt immer das Theater, dass bei ab und an wiederkehrenden Fehlern gleich die User dem Admin im Nacken sitzen und der Admin mir im Nacken sitzt, immer mit dem Kommentar "Outlook kann es doch auch..." :lol:

Wahrscheinlich ignorieren Outlook/Thunderbird einfach das Content-Transfer-Encoding, da der Parser schon vorab prüft, ob MultiPart Data enthalten ist - also weiß, daß die Boundaries Ihre eignenen Content-Typ haben.

Aber: Ich verstehe Dich und sehe es genauso - was bringt ein Parser, der zwar 100% korrekt arbeitet, aber im täglichen Einsatz nunmal auch defekte Daten verarbeitet werden müssen.

Ich habe das ganze daher mal im Indy Core Team gepostet und wir werden das dort weiter diskutieren. Meiner Meinung nach wäre eine Option sinnvoll, die ein "relaxed Parsing" ermöglicht, also auch fehlerhafte Eingabedaten ähnlich Outlook/Thunderbird akzeptiert und möglichst korrekt parst.

Wann und ob das etwas wird, kann ich aber leider nicht versprechen.

Wenn Du noch mehr Beispiel-Mails hast, möglichst mit den unterschiedlichsten Defekten, kannst Du die mir gerne senden (hier posten oder als PN).

Gruß Assertor

[adrian4321]

Hallo,

danke für Deine informative Antwort!
Ich kann gerne noch einige Problemfälle nachsenden. An sich würde ich ja auch gerne mit Indy weiterarbeiten...

Allerdings bin ich gerade noch im Urlaub :), von daher bitte ich noch um ein paar Tage Geduld...

Viele Grüße und bis dann!

[jbg]

Weil ihr gerade dabei seit. Kann es sein dass IdMessage.LoadFromFile nicht zum Einlesen von *.eml Dateien geeignet ist? Oder muss ich LoadFromFile so verstehen, dass es POP3/IMAP Server-Dateien nur lesen kann.
Es macht nämlich keinen Spaß, wenn die Email beim Auftreten eines Punkts in einer eigenen Zeile für beendet erklärt wird und sämtliche Anhänge und text/html Parts dadurch verloren gehen. Den Bug kann ich bei Indy 9 als auch bei Indy 10 (Delphi 2007) und Indy 10 Tiburon (direkt aus dem SVN) nachvollziehen.

Hier mal eine Beispiel *.eml Datei.

Code:

Return-Path: <[e-mail]>
Received: from andromeda ([unix socket])
   by andromeda (Cyrus v2.1.15) with LMTP; Fri, 21 Aug 2009 13:26:29 +0200
X-Sieve: CMU Sieve 2.2
Received: from localhost (localhost [127.0.0.1])
   by wilken.de (Postfix) with ESMTP id A0B4F24923F
   for <[e-mail]>; Fri, 21 Aug 2009 13:26:29 +0200 (CEST)
Received: from wilken.de (localhost [127.0.0.1])
   by localhost (AvMailGate-2.0.2-10) id 20238-752D3A3D;
   Fri, 21 Aug 2009 13:26:29 +0200
Received: from [10.1.2.25] (wksp4081.qs.wilken.de [10.1.2.25])
   by wilken.de (Postfix) with ESMTP id 96325248CC9
   for <[e-mail]>; Fri, 21 Aug 2009 13:26:29 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Fri, 21 Aug 2009 13:27:29 +0200
From: Andreas Hausladen <[e-mail]>
Organization: Wilken
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Hausladen Andreas <[e-mail]>
Subject: asd
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable
X-AntiVirus: checked by AntiVir MailGate (version: 2.0.2-10; AVE: 7.9.1.3; VDF: 7.1.5.143; host: 10.1.1.31)

Hallo

..
Diese doppelten Punkte werden auf einen reduziert, was nach dem
Speichern und erneutem Laden dazu führt, dass auch dieser Text
hier weg ist.

.
Das hier ist schon gar nicht mehr vorhanden nach dem Laden

[Assertor]

Hi Andreas,

Zitat:

Zitat von jbg

Weil ihr gerade dabei seit. Kann es sein dass IdMessage.LoadFromFile nicht zum Einlesen von *.eml Dateien geeignet ist?

Nein, das sollte auch für Plaintext Messagefiles nutzbar sein.

Bevor ich jetzt zu jeder einzelnen Mail was sage, schlage ich vor: Wir machen hier den Schrott-Mail Sammelplatz. Das erhöht die Qualität, da es uns das Testen erlaubt. Das bisherige "Bug nicht melden, aber drüber ärgern" hilft ja bei OpenSource nicht viel ;)

Gruß Assertor

[MasterEvil]

Hallo,

ich habe gerade das selbe Problem.

Ich sammel E-Mails von Microsofts Windows Fax Server zusammen, um sie einzelnen Adressen zuzuordnen.
Diese E-Mails haben im Header "Content-Transfer-Encoding: base64" stehen, sind aber MIME Multipart. Indy fängt dann an und versucht alles von base64 zu dekodieren, obwohl es nicht base64-codiert ist.

"This is a multi-part message in MIME format." ist danach unlesbar und bei den anderen message-parts dekodiert er auch die MIME-Kopfzeilen wie z.B. "Content-Type: text/plain;" ins unleserliche, was ihn dann nicht erkennen lässt, das es ein attachment ist.

Nehme ich "Content-Transfer-Encoding: base64" aus dem Kopf raus, ist alles in Ordnung.

Hier die gekürzte Mail:

Zitat:

Received: from b.intranet.t.de[192.168.0.83] (helo=TAIFUNSupport) by mail.intranet.t.de[192.168.0.12] with smtp (Indy SMTP Server)
thread-index: AcoiU5teQd8eQddFTpao8PCP0XN0Gg==
Thread-Topic: Der Faxserver TAIFUN-SUPPORT hat ein neues Fax von X empfangen.
From: <[e-mail]>
To: <[e-mail]>
Subject: Der Faxserver TAIFUN-SUPPORT hat ein neues Fax von X empfangen.
Date: Fri, 21 Aug 2009 13:36:21 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; charset=utf-8;
boundary="----=_NextPart_000_0001_01CA2264.5EF4B590"
Content-Transfer-Encoding: base64
X-Mailer: Microsoft CDO for Windows 2000
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01CA2264.5EF4B590
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: base64

[base64 Text entfernt]

------=_NextPart_000_0001_01CA2264.5EF4B590
Content-Type: image/tif;
name="FAX.TIF"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="FAX.TIF"

[base64 Tif Image entfernt]

------=_NextPart_000_0001_01CA2264.5EF4B590--

Nachtrag:
Ich muss dazu allerdings sagen, dass ich nicht auf einer ganz aktuellen Indy Version sitze, sondern auf einer älteren Indy10er.

Gruß,
Steffen

[mjustin]

Zitat:

Zitat von jbg

Weil ihr gerade dabei seit. Kann es sein dass IdMessage.LoadFromFile nicht zum Einlesen von *.eml Dateien geeignet ist? Oder muss ich LoadFromFile so verstehen, dass es POP3/IMAP Server-Dateien nur lesen kann.
Es macht nämlich keinen Spaß, wenn die Email beim Auftreten eines Punkts in einer eigenen Zeile für beendet erklärt wird und sämtliche Anhänge und text/html Parts dadurch verloren gehen.

Ist das denn wirklich ein Bug?

Ein Punkt am Zeilenanfang (genauer gesagt die Sequenz "\r\n.\r\n") bedeutet bei SMTP das Ende der E-Mail:

Zitat:

Alles was nun kommt, wird vom SMTP-Server als Nachricht gespeichert. Wie kann man diesen Eingabe-Modus beenden?
Indem man einen einzelnen Punkt alleine auf einer Zeile sendet (genauer gesagt die Sequenz "\r\n.\r\n").
Und was wenn die Mail einen einzelnen Punkt alleine auf einer Zeile enthält?
Dann haben wir ein Problem! Damit die Bearbeitung nicht abbricht, muss man dafür sorgen, dass der Punkt nicht mehr alleine auf der Zeile steht. Das tut man indem man einfach einen weiteren Punkt vorne anhängt. Der SMTP-Server weiss das auch, und deshalb wird der erste von zwei Punkten am Zeilenanfang vom SMTP-Server ignoriert (zumindest was den Nachrichten-Inhalt angeht).

http://www.ratnet.stw.uni-erlangen.d...wtos/smtp.html

[jbg]

Zitat:

Zitat von mjustin

Ein Punkt am Zeilenanfang (genauer gesagt die Sequenz "\r\n.\r\n") bedeutet bei SMTP das Ende der E-Mail:

Das Problem ist das ich eine *.eml Datei habe und nicht mit einem SMTP oder einem POP3/IMAP Server kommuniziere. Dummerweise wird bei Indy haar genau dieselbe Lese/Schreibe Routine für beides benutzt.

[Assertor]

Hi,

Zitat:

Zitat von jbg

Zitat:

Zitat von mjustin

Ein Punkt am Zeilenanfang (genauer gesagt die Sequenz "\r\n.\r\n") bedeutet bei SMTP das Ende der E-Mail:

Das Problem ist das ich eine *.eml Datei habe und nicht mit einem SMTP oder einem POP3/IMAP Server kommuniziere. Dummerweise wird bei Indy haar genau dieselbe Lese/Schreibe Routine für beides benutzt.

Ja, das ist beides richtig. Der Punkt hat halt diese Funktion bei SMTP und der Parser ist für Dateien und Online gleich.

Danke erstmal an alle, die bisher hier Mails hinterlegt haben. Wir haben schon etwas geändert und ich werde das damit mal testen. Sobald es etwas neues gibt, gebe ich hier Feedback!

Gruß Assertor

[Assertor]

Hallo,

ein Nachtrag: Die hier vorgestellten Probleme wurden bereinigt und stehen im aktuellen Indy SVN zur Verfügung.

:dp:

Ein Test mit einem Punkt, mit zwei Punkten etc. läuft nun bei GMail ohne Probleme, auch nach Speichern und Neuladen aus einer .eml Textdatei mit TIdMessage. Je nach Quellmail wird es entweder QP codiert oder z.B. 7bit.

Falls jemand noch andere Problemmails hat, immer her damit.

@jbg: Der Punkt in der Mail muß vom Server entweder als Quoted Printable mit =2E codifert werden (http://tools.ietf.org/html/rfc1756) oder wenigstens innerhalb eines z.B.

Zitat:

Content-Transfer-Encoding: 7bit
Content-Disposition: inline

stehen - wenn der Server den Punkt anders in einer .eml Datei speichert, ist das leider ein grober Schnitzer Eures Mailservers.

Woher kommt denn die .eml Datei? Aus Outlook exportiert oder vom Server exportiert? Kannst Du zur Fehlersuche eine Mail ohne AntiVir Gateway empfangen?

Ich würde Tippen, wenn der Postfix die direkt zustellt, ist die Mail korrekt und läuft auch in Indy. Das AntiVir Gateway ändert jede (!) Mail, wie man am X-AntiVirus: checked by AntiVir MailGate sieht. Also kann hier auch der Encoding-Fehler zuschlagen.

Manche Fehler lassen sich nicht beheben, z.B. fehlerhaftes Charset - da kann nur der Benutzer eingreifen, da er weiß, welche Sprache es sein soll. Gleiches gilt für grobe Encoding Fehler - der Fix im SVN behebt nur, doppelte und fehlerhafte Content-Encodings, aber kann fehlerhaft codierte Daten nicht gültig machen.

Die Funktion je nach Aufruf anders arbeiten zu lassen, ist meiner Meinung nach nicht sinnvoll. Beispiel: Indy wird auch als Post/Pre-Parser für Exchange Server eingesetzt (Connector) - wenn hier aus und in Dateien gespeichert wird, soll es sich eben genau wie ein Mailserver-Parsing verhalten.

Gruß Assertor

[adrian4321]

Zitat:

ein Nachtrag: Die hier vorgestellten Probleme wurden bereinigt und stehen im aktuellen Indy SVN zur Verfügung.

Meins auch...? Dickes Lob für Dein Engagement auf jeden Fall ;) Endlich hab ich einen guten Ansprechpartner :)

Dann werde ich die Tage die neueste Version einbauen und schauen, welche Fehler übrig bleiben. Bin leider nur grad fürchterlich im Uni-Lernstress, daher muss das Softwareentwickeln im Moment etwas kürzer treten, wird wohl noch so bis Mitte Oktober dauern, bis ich mich wieder mehr reinhängen kann...

Viele Grüße!

[Assertor]

Hi Adrian,

Zitat:

Zitat von adrian4321

Zitat:

ein Nachtrag: Die hier vorgestellten Probleme wurden bereinigt und stehen im aktuellen Indy SVN zur Verfügung.

Meins auch...?

Gerade Deine Test-Mail läuft nun fehlerfrei durch :)

Zitat:

Zitat von adrian4321

Dickes Lob für Dein Engagement auf jeden Fall ;) Endlich hab ich einen guten Ansprechpartner :)

Danke für das Lob, das hört man gerne!

Zitat:

Zitat von adrian4321

Dann werde ich die Tage die neueste Version einbauen und schauen, welche Fehler übrig bleiben. Bin leider nur grad fürchterlich im Uni-Lernstress, daher muss das Softwareentwickeln im Moment etwas kürzer treten, wird wohl noch so bis Mitte Oktober dauern, bis ich mich wieder mehr reinhängen kann...

Kein Problem, sobald Du noch andere Sachen entdeckst, gerne her damit :)

Gruß Assertor

[adrian4321]

:dp:
Nachtrag: Funktioniert wirklich :)

[paresy]

Habe die aktuellste Indy Version aus dem SVN (3867).

Diese funktioniert jetzt auch recht gut beim Dekodieren von Betreffzeilen.
Jedoch gibt es mal wieder besondere Server, die sich nicht an die RFC Spezifikation halten. (z.B. StudiVZ)

z.B. =?UTF-8?Q?Du wurdest zum Moderator bef=C3=B6rdert?=

Leerzeichen sind laut RFC2047 aber nicht erlaubt und deswegen dekodiert Indy diese Zeile nicht. Andere Funktionen (z.b. von PHP: http://php.net/manual/de/function.iconv-mime-decode.php) sehen das nicht so eng und dekodieren dies trotzdem.

Wäre es Möglich, dass Indy das auch etwas weniger restriktiv dekodiert?

Grüße,
paresy

[Assertor]

Hallo Paresy,

Zitat:

Zitat von paresy

Habe die aktuellste Indy Version aus dem SVN (3867).

Diese funktioniert jetzt auch recht gut beim Dekodieren von Betreffzeilen.

Danke für das positive Feedback!

Zitat:

Zitat von paresy

Jedoch gibt es mal wieder besondere Server, die sich nicht an die RFC Spezifikation halten. (z.B. StudiVZ)

z.B. =?UTF-8?Q?Du wurdest zum Moderator bef=C3=B6rdert?=

Leerzeichen sind laut RFC2047 aber nicht erlaubt und deswegen dekodiert Indy diese Zeile nicht. Andere Funktionen (z.b. von PHP: http://php.net/manual/de/function.iconv-mime-decode.php) sehen das nicht so eng und dekodieren dies trotzdem.

Wäre es Möglich, dass Indy das auch etwas weniger restriktiv dekodiert?

Da muß ich Dir zustimmen, auch wenn der Header wie Du schon geschrieben hast, so nicht korrekt formuliert ist. Trotzdem wird ja von faktisch allen E-Mail Clients (Thunderbird, MSO) das Parsing relaxt sobald diese ungültige Daten auflaufen.

Ich habe das im Team mal vorgeschlagen, kann aber derzeit keine Aussage oder Versprechen machen ob und wann da etwas geändert wird.

Auf jeden Fall Danke fürs Melden (auch wenn es kein Bug ist, ist es ja hilfreich)!

Gruß Assertor

:dp:

[Assertor]

Hi,

Zitat:

Zitat von paresy

Andere Funktionen (z.b. von PHP: http://php.net/manual/de/function.iconv-mime-decode.php) sehen das nicht so eng und dekodieren dies trotzdem.

Wäre es Möglich, dass Indy das auch etwas weniger restriktiv dekodiert?

Wir sind noch am Diskutieren, derzeit ist das Ergebnis offen. Aber zu Iconv: Der oben gezeigte Link zeigt auch, daß dort ein Strict Mode implementiert ist (aber dort per default off). Sobald es etwas neues gibt, poste ich es hier.

Gruß Assertor

[fisipjm]

Hi,

der Post ist zwar schon Uralt, aber ich bin gerade an genau diesem Problem aus dem letzten Kommentar dran.
Habt ihr hier schon entschieden bzw. gibt es einen Workaround? Wäre echt sehr nice.

Gruß
PJM