IMAP Attachment, ein Byte wird verschluckt

[mcinternet]

Moin,

RAD Studio XE2 - 32 Bit. Ich hole mittels IMAP (POP3 geht da aus technischen Gründen nicht) Mail mit GPG-verschlüsselten Attachments ab. Bei ca. 30% wird ein Byte unterschlagen; ist nat. bei Verschlüsselung tödlich.
Das ist auch unabhängig von der Größe der Datei. Hier mal mein Code:

Delphi-Quellcode:

procedure TFrmMain.btn_connectClick(Sender: TObject);
  var     iCollection : TIdMessageCollection ;
          AUID : String;
          iloop : integer;
          idx: Integer;
          FN : string;
          MSG : TIdMessage;
          mailcount : integer;
          msgpartcount : integer;

begin
  imap.Connect(true);
  iCollection := TIdMessageCollection.Create(TIdMessageItem);
  MSG := TIdMessage.Create();
  imap.SelectMailBox('inbox');
  mailcount := imap.MailBox.TotalMsgs;
  lbl_mailcount.Caption := inttostr(mailcount);
  for iLoop := 1 to mailcount  do begin
     imap.GetUID(iLoop,AUID);
     imap.Retrieve(iLoop,msg);

     lbl_uid.Caption := auid;
     msgpartcount := pred(msg.MessageParts.Count);
     lbl_msgcount.Caption := inttostr(msgpartcount);
     for idx := 0 to msgpartcount do
     begin
       if msg.MessageParts.Items[idx] is TIdAttachmentFile then
        begin
          FN := strPath + 'Export\'+ rightstr(TIdAttachmentFile(msg.MessageParts.Items[idx]).Filename,23);
          if (not fileexists(FN)) and (RightStr(FN,3) = 'gpg') then
          begin
            lbl_fn.Caption := FN;
            TIdAttachmentFile(msg.MessageParts.Items[idx]).SaveToFile(FN);
     end;
  end;
end;

IMAP Einstellungen:
Auth Type: iatUserPass
Host: xxxxx
Mailbox Separator: /
MillisecsToWaitToClearBuffer: 10
Name: IMAP
Passswort: xxxxxx
Port: 143
RetrieveOnSelect: rsDisabled
SASLMechanisms:
Tag: 0
Username: xxxxx
UseTLS: utNoTLSSupport


Wer hat da eine Idee?

Gruß
McInternet

[Namenloser]

Passiert es denn reproduzierbar immer bei den gleichen Mails?

[mcinternet]

Zitat von NamenLozer:

Passiert es denn reproduzierbar immer bei den gleichen Mails?

Ja - wenn ich die Dateien dann vergleiche, schmeißt mir Notepad+ 2-3 Fehler raus - (man sieht bloß keine!!!) und Ultraedit nur einen. (auch nix zu sehen)
Nur das die Datei immer genau 1 Byte Unterschied in der Länge hat. - Ein ziemlich obskurer Fehler.

Gruss

Mc

[himitsu]

Zitat:

schmeißt mir Notepad+ 2-3 Fehler raus

Was für Fehler?

Du könntest uns natürlich auch mal ein paar Dateien geben, so zum Nachsehn, wa Anders ist.

[mcinternet]

Zitat von himitsu:

Zitat:

schmeißt mir Notepad+ 2-3 Fehler raus

Was für Fehler?

Du könntest uns natürlich auch mal ein paar Dateien geben, so zum Nachsehn, wa Anders ist.

Die Dateien kann/darf ich Euch nicht geben. => BSI ....

Also: Die Dateien sind gpg verschlüsselt (AES 256).
Ich speichere sie ab zum automatischen Weiterverarbeiten. Dabei fallen ca. 30% raus, können nicht entschlüsselt werden. Hole ich diese mit einem eMail-Client ab, so sind diese 30% dann genau ein Byte länger. Die anderen 70% sind gleich. d.h. bei 30% der Dateien, welche ich mit o.g. Code ziehe fehlt im Endeffekt genau ein Byte.
Mache ich nun mit Notepad+ oder Ultraedit einen Vergleich, so sagt Notepad, das dort ein Unterschied wäre -> kann mir zwar die Zeile zeigen, aber nicht das Zeichen ( und das mittendrin! ).
Auch bei sehr genauem Hinschauen findet man keinen Unterschied (Wir haben da das 8-Augen-Prinzip angewandt). Seltsamerweise zeigt mir Ultraedit 3 Unterschiede an, kann mir aber ebenfalls nur ne Zeile zeigen und der Hex-Code ist gleich. - Also ist da irgendwo ein leak ...? Nur wo?

Ich kann da aus vorgegebenen Sicherheitsstrukturen, welche ich auch nicht umgehen oder aufweichen kann kein POP3 anwenden, nur IMAP. Von daher meine Frage, ob jemand da eine Idee für nen Workaround hat....? Oder haut mir da die API, das Windowsdateisystem (WIN7 Enterprise 32 Bit) oder sonstwer rein?

Ich finde da auch keine Regelmäßigkeit bzgl. Dateigröße, Name oder so. Das tritt bei 1-2k und auch bei 10k und größer auf.

Gruss
Mc

[himitsu]

http://www.delphipraxis.net/113368-b...vergleich.html (ist zwar nicht so cool wie Ultraedit ... aber funktioniert )
Es gibt (bestimmt) noch bessere Programme, aber für den Anfang reicht's.

[add] HxD / HxD hat auch einen Dateivergleich drin

[mcinternet]

Zitat von himitsu:

http://www.delphipraxis.net/113368-b...vergleich.html (ist zwar nicht so cool wie Ultraedit ... aber funktioniert )
Es gibt (bestimmt) noch bessere Programme, aber für den Anfang reicht's.

[add] HxD / HxD hat auch einen Dateivergleich drin

danke, werde es Morgen mal damit versuchen und poste das Ergebnis dann

Gruss

Mc

[mcinternet]

Problem solved

Es lag an der Indy Komponente.
Hab mir die aktuellste Version gesaugt (und mit ein wenig Aufstand) installiert. Und siehe da: Alles klappt


Gruss

Mc

[Namenloser]

Ich vermute einfach mal, dass es mit der Base64-Kodierung zu tun hatte... das ist ja das gängige Verfahren bei binären E-Mails. Es gibt es nämlich genau drei Möglichkeiten, wie Base64-enkodierte Daten enden können: entweder gar kein Padding-Zeichen, einmal = , oder == ; weil immer 3 Bytes auf 4 Zeichen abgebildet werden. Und je nach Datenlänge geht das nicht ganz auf, sodass am Ende aufgefüllt werden muss.

Wäre denkbar, dass einer dieser Fälle von Indy falsch gehandelt wurde, was die ca. 30% erklären würde.

[mcinternet]

Zitat von NamenLozer:

Ich vermute einfach mal, dass es mit der Base64-Kodierung zu tun hatte... das ist ja das gängige Verfahren bei binären E-Mails. Es gibt es nämlich genau drei Möglichkeiten, wie Base64-enkodierte Daten enden können: entweder gar kein Padding-Zeichen, einmal = , oder == ; weil immer 3 Bytes auf 4 Zeichen abgebildet werden. Und je nach Datenlänge geht das nicht ganz auf, sodass am Ende aufgefüllt werden muss.

Wäre denkbar, dass einer dieser Fälle von Indy falsch gehandelt wurde, was die ca. 30% erklären würde.

Es muß ja zwangsläufig an Indy gelegen haben. Nach dem Austausch mit gegen das Build: Indy10_4778 ging es einwandfrei.
Es betraf übrigens nur UUE codierte Mails!

Gruss

Mc