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