![]() |
Emails verarbeiten - Indy ist nicht gut genug :(
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 ;) |
Re: Emails verarbeiten - Indy ist nicht gut genug :(
Vielleicht erhältst du hier ein paar Anregungen
|
Re: Emails verarbeiten - Indy ist nicht gut genug :(
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. |
Re: Emails verarbeiten - Indy ist nicht gut genug :(
Ich habe mit der extended MAPI vom Imibo gute Erfahrung gemacht.
Die Sample- und Request- Beispiel-Projekte waren dabei hilfreich. ![]() |
Re: Emails verarbeiten - Indy ist nicht gut genug :(
extenden MAPI hilft dir aber nur beim Zugriff auf einen Exchange o.ä.
|
Re: Emails verarbeiten - Indy ist nicht gut genug :(
Zitat:
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. |
Re: Emails verarbeiten - Indy ist nicht gut genug :(
Hi,
Zitat:
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 |
Re: Emails verarbeiten - Indy ist nicht gut genug :(
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:
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. |
Re: Emails verarbeiten - Indy ist nicht gut genug :(
Da in D2005 auch nur der Compiler von D7 Update 2 steckt, würde ich D7 vorziehen. Sonst halt TD(E) oder neuer
|
Re: Emails verarbeiten - Indy ist nicht gut genug :(
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 ;)
|
Re: Emails verarbeiten - Indy ist nicht gut genug :(
Liste der Anhänge anzeigen (Anzahl: 1)
Hallo,
Zitat:
Zitat:
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:
Screenshot anbei. Am besten mal eine "anonymisierte" Mail als .eml (also Text) hier im Forum anhängen. Edit: Zitat:
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 |
Re: Emails verarbeiten - Indy ist nicht gut genug :(
Liste der Anhänge anzeigen (Anzahl: 1)
Zitat:
![]() Zitat:
Man erzeuge eine neue Mail, packe einen schönen Abdenser rein wie "Günther, Horst" <horst.guenther@online.de>, 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:
Zitat:
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: |
Re: Emails verarbeiten - Indy ist nicht gut genug :(
Hi Adrian,
ein später Nachtrag: Zitat:
Zitat:
Zitat:
Zitat:
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:
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 |
Re: Emails verarbeiten - Indy ist nicht gut genug :(
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! |
Re: Emails verarbeiten - Indy ist nicht gut genug :(
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: <Andreas.Hausladen@wilken.de>
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 <andreas.hausladen@wilken.de>; 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 <andreas.hausladen@wilken.de>; Fri, 21 Aug 2009 13:26:29 +0200 (CEST) Message-ID: <4A8E84A1.1030104@wilken.de> Date: Fri, 21 Aug 2009 13:27:29 +0200 From: Andreas Hausladen <Andreas.Hausladen@wilken.de> Organization: Wilken User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Hausladen Andreas <andreas.hausladen@wilken.de> 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 |
Re: Emails verarbeiten - Indy ist nicht gut genug :(
Hi Andreas,
Zitat:
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 |
Re: Emails verarbeiten - Indy ist nicht gut genug :(
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:
Ich muss dazu allerdings sagen, dass ich nicht auf einer ganz aktuellen Indy Version sitze, sondern auf einer älteren Indy10er. Gruß, Steffen |
Re: Emails verarbeiten - Indy ist nicht gut genug :(
Zitat:
Ein Punkt am Zeilenanfang (genauer gesagt die Sequenz "\r\n.\r\n") bedeutet bei SMTP das Ende der E-Mail: Zitat:
![]() |
Re: Emails verarbeiten - Indy ist nicht gut genug :(
Zitat:
|
Re: Emails verarbeiten - Indy ist nicht gut genug :(
Hi,
Zitat:
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 |
Re: Emails verarbeiten - Indy ist nicht gut genug :(
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 ( ![]() Zitat:
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 |
Re: Emails verarbeiten - Indy ist nicht gut genug :(
Zitat:
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! |
Re: Emails verarbeiten - Indy ist nicht gut genug :(
Hi Adrian,
Zitat:
Zitat:
Zitat:
Gruß Assertor |
Re: Emails verarbeiten - Indy ist nicht gut genug :(
:dp:
Nachtrag: Funktioniert wirklich :) |
Re: Emails verarbeiten - Indy ist nicht gut genug :(
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: ![]() Wäre es Möglich, dass Indy das auch etwas weniger restriktiv dekodiert? Grüße, paresy |
Re: Emails verarbeiten - Indy ist nicht gut genug :(
Hallo Paresy,
Zitat:
Zitat:
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: |
Re: Emails verarbeiten - Indy ist nicht gut genug :(
Hi,
Zitat:
Gruß Assertor |
AW: Emails verarbeiten - Indy ist nicht gut genug :(
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 |
Alle Zeitangaben in WEZ +1. Es ist jetzt 22:51 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz