Mailbug in Indy

[alleinherrscher]

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:

5509 FETCH (ENVELOPE ("Wed, 11 Oct 2012 14:00:00 +0200" "Betreff" (("..." NIL "..." "...")) (("..." NIL "..." "...")) NIL NIL "<[e-mail]>" "<[e-mail]>") FLAGS (\Seen) UID 1234)

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:

Code:

5509 FETCH (ENVELOPE ("Wed, 11 Oct 2012 14:00:00 +0200" {7}Betreff (("..." NIL "..." "...")) (("..." NIL "..." "...")) NIL NIL "<[e-mail]>" "<[e-mail]>") FLAGS (\Seen) UID 1234)

Auch dies ist soweit kein Problem. Das Problem oder der Bug taucht dann auf, wenn bestimmte, reservierte Zeichen in dem Betreff-String auftauchen:

Code:

5509 FETCH (ENVELOPE ("Wed, 11 Oct 2012 14:00:00 +0200" {9}Betr"e"ff (("..." NIL "..." "...")) (("..." NIL "..." "...")) NIL NIL "<[e-mail]>" "<[e-mail]>") FLAGS (\Seen) UID 1234)

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

Code:

{9}Betr"e"ff

Code:

"Betr"e"ff" wird.

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

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:

5509 FETCH (ENVELOPE ("Wed, 11 Oct 2012 14:00:00 +0200" {9}
Betr"e"ff (("..." NIL "..." "...")) (("..." NIL "..." "...")) NIL NIL "<[e-mail]>" "<[e-mail]>") FLAGS (\Seen) UID 1234)

Dies habe ich allerdings schon in idReplyIMAP4.pas gebugfixed, indem ich nach nicht fertigen FETCH Zeilen suche:

Delphi-Quellcode:

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;

Hat jemand eine gute Idee, wie wir auch den anderen Fehler bugfixen können?

Das wäre mir echt sehr sehr wichtig. Besten Dank und Grüße,
Michael