Emails verarbeiten - Indy ist nicht gut genug :(

[Assertor]

Hallo,

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



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