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

[jfheins]

Also wenn ich mir das in der RFC mal so angucke:

Zitat:

4.3. String

A string is in one of two forms: either literal or quoted
string. The literal form is the general form of string. The
quoted string form is an alternative that avoids the overhead of
processing a literal at the cost of limitations of characters
which may be used.

A literal is a sequence of zero or more octets (including CR and
LF), prefix-quoted with an octet count in the form of an open
brace ("{"), the number of octets, close brace ("}"), and CRLF.
In the case of literals transmitted from server to client, the
CRLF is immediately followed by the octet data. In the case of
literals transmitted from client to server, the client MUST wait
to receive a command continuation request (described later in
this document) before sending the octet data (and the remainder
of the command).

A quoted string is a sequence of zero or more 7-bit characters,
excluding CR and LF, with double quote (<">) characters at each
end.

The empty string is represented as either "" (a quoted string
with zero characters between double quotes) or as {0} followed
by CRLF (a literal with an octet count of 0).

Note: Even if the octet count is 0, a client transmitting a
literal MUST wait to receive a command continuation request.

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

[alleinherrscher]

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