Mailbug in Indy
Hi@all. Ich verwende Delphi XE2 und die mitgelieferte Indy-Version. Ich habe allerdings auch schon neuere Indy Versionen getestet, die meiner Meinung nach den selben Bug haben:
Wenn ich den Header aller E-Mails abrufe, bekommt Indy normalerweise folgende Antwort vom Server:
Code:
Den String zu interpretieren ist für IdImap kein Problem. Es kommt aber auch vor, dass der Betreff nicht in Anführungszeichen steht, sondern eine bestimmte, zuvor mitgeschickte Anzahl an Zeichen enthält:
5509 FETCH (ENVELOPE ("Wed, 11 Oct 2012 14:00:00 +0200" "Betreff" (("..." NIL "..." "...")) (("..." NIL "..." "...")) NIL NIL "<nummer@irgendwas.com>" "<nummer@mailprovider.com>") FLAGS (\Seen) UID 1234)
Code:
Auch dies ist soweit kein Problem. Das Problem oder der Bug taucht dann auf, wenn bestimmte, reservierte Zeichen in dem Betreff-String auftauchen:
5509 FETCH (ENVELOPE ("Wed, 11 Oct 2012 14:00:00 +0200" {7}Betreff (("..." NIL "..." "...")) (("..." NIL "..." "...")) NIL NIL "<nummer@irgendwas.com>" "<nummer@mailprovider.com>") FLAGS (\Seen) UID 1234)
Code:
Also dachte ich mir, dass man einfach die Zahl innerhalb der geschweiften Klammern auswertet und die dann folgenden Zeichen in Anführungszeichen setzt, sodass aus
5509 FETCH (ENVELOPE ("Wed, 11 Oct 2012 14:00:00 +0200" {9}Betr"e"ff (("..." NIL "..." "...")) (("..." NIL "..." "...")) NIL NIL "<nummer@irgendwas.com>" "<nummer@mailprovider.com>") FLAGS (\Seen) UID 1234)
Code:
{9}Betr"e"ff
Code:
Das würde auch prima funktionieren, wenn die Zahl in den geschweiften Klammern auch tatsächlich exakt der Anzahl der nun folgenden String-Zeichen entsprechen würde. Leider stimmt dies aber nur so +/- 3 Zeichen -warum weiß ich nicht?!
"Betr"e"ff" wird.
Hinzu kommt, dass der IMAP Server grundsätzlich ein Fetch-Command, der einen Betreff mit geschweifter Klammer hat, hinter der geschweiften Klammer abbricht und eine neue Zeile sendet:
Code:
Dies habe ich allerdings schon in idReplyIMAP4.pas gebugfixed, indem ich nach nicht fertigen FETCH Zeilen suche:
5509 FETCH (ENVELOPE ("Wed, 11 Oct 2012 14:00:00 +0200" {9}
Betr"e"ff (("..." NIL "..." "...")) (("..." NIL "..." "...")) NIL NIL "<nummer@irgendwas.com>" "<nummer@mailprovider.com>") FLAGS (\Seen) UID 1234)
Delphi-Quellcode:
Hat jemand eine gute Idee, wie wir auch den anderen Fehler bugfixen können?
procedure TIdReplyIMAP4.CheckForMultipleLineStringV3(AValue:TStrings);
var i,j,k:integer; begin for i := 0 to AValue.count-2 do begin if TextEndsWith(AValue[i],'}') then begin j:=i+1; while ((j<AValue.Count) and not(pos('FETCH (ENVELOPE',AValue[j])>0)) do begin if not (j=i+1) then AValue[i]:=AValue[i]+' '; AValue[i]:=aValue[i]+aValue[j]; AValue[j]:=''; inc(j); end; aValue[i]:=FixQuotaInBracketStrings(AValue[i]); outputdebugstring(pchar('repaired: '+avalue[i])); end; end; for k := AValue.count-1 downto 0 do if AValue[k]='' then AValue.Delete(k); end; Das wäre mir echt sehr sehr wichtig. Besten Dank und Grüße, Michael |
AW: Mailbug in Indy
Also wenn ich mir das in der RFC mal so angucke:
Zitat:
1. Die neue Zeile kein Bug sondern gewollt. 2. In den geschweiften Klammern muss stets die Anzahl an Bytes stehen. Hast du da vielleicht irgendwelche Codierungsprobleme, wo mehrere Bytes als ein Buchstabe dargestellt werden? (UTF-8 lässt grüßen) 3. Aus den geschweiften Klammern einen String mit "" zu machen ist wohl eher eine schlechte Idee, weil in den "" nur 7-bit Zeichen stehen dürfen, hinter den Klammern aber volle 8-bit. |
AW: Mailbug in Indy
Okay, danke! Das ist schon mal hilfreich. Aber Indy fliegt einfach mit einer Fehlermeldung raus, wenn sich ein String über zwei Zeilen erstreckt mit der Fehlermeldung: "Unexpected: Non-last response line (i.e. a data line) did not start with a *" (stammt aus der Funktion "SetFormattedReply" in IdReplyIMAP4.pas).
Berücksichtige ich die CRLF, scheint die Länge des Strings, die in den Brackets steht, relativ genau zu stimmen. Trotzdem kommt Indy überhaupt nicht damit klar.... |
Alle Zeitangaben in WEZ +1. Es ist jetzt 22:22 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz