Emails verarbeiten - Indy ist nicht gut genug :(

[Assertor]

Hallo,

Zitat von adrian4321:

die Indys habe ich aber selbstverständlich aktualisiert.

Quelle SVN oder Fulgan Mirror, Tiburon Branch, korrekt?

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 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 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 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
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..."

[Assertor]

Hi Adrian,

ein später Nachtrag:

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
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 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 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 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..."

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 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 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 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 von jbg:

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