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