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

[adrian4321]

Zitat:

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

Meins auch...? Dickes Lob für Dein Engagement auf jeden Fall Endlich hab ich einen guten Ansprechpartner

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!

[Assertor]

Hi Adrian,

Zitat von adrian4321:

Zitat:

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

Meins auch...?

Gerade Deine Test-Mail läuft nun fehlerfrei durch

Zitat von adrian4321:

Dickes Lob für Dein Engagement auf jeden Fall Endlich hab ich einen guten Ansprechpartner

Danke für das Lob, das hört man gerne!

Zitat von adrian4321:

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

Kein Problem, sobald Du noch andere Sachen entdeckst, gerne her damit

Gruß Assertor

[adrian4321]

Nachtrag: Funktioniert wirklich

[paresy]

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: http://php.net/manual/de/function.iconv-mime-decode.php) sehen das nicht so eng und dekodieren dies trotzdem.

Wäre es Möglich, dass Indy das auch etwas weniger restriktiv dekodiert?

Grüße,
paresy

[Assertor]

Hallo Paresy,

Zitat von paresy:

Habe die aktuellste Indy Version aus dem SVN (3867).

Diese funktioniert jetzt auch recht gut beim Dekodieren von Betreffzeilen.

Danke für das positive Feedback!

Zitat von paresy:

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: http://php.net/manual/de/function.iconv-mime-decode.php) sehen das nicht so eng und dekodieren dies trotzdem.

Wäre es Möglich, dass Indy das auch etwas weniger restriktiv dekodiert?

Da muß ich Dir zustimmen, auch wenn der Header wie Du schon geschrieben hast, so nicht korrekt formuliert ist. Trotzdem wird ja von faktisch allen E-Mail Clients (Thunderbird, MSO) das Parsing relaxt sobald diese ungültige Daten auflaufen.

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

[Assertor]

Hi,

Zitat von paresy:

Andere Funktionen (z.b. von PHP: http://php.net/manual/de/function.iconv-mime-decode.php) sehen das nicht so eng und dekodieren dies trotzdem.

Wäre es Möglich, dass Indy das auch etwas weniger restriktiv dekodiert?

Wir sind noch am Diskutieren, derzeit ist das Ergebnis offen. Aber zu Iconv: Der oben gezeigte Link zeigt auch, daß dort ein Strict Mode implementiert ist (aber dort per default off). Sobald es etwas neues gibt, poste ich es hier.

Gruß Assertor

[fisipjm]

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