Hallo,

ich habe mir ein Programm gebastelt, das mittels TIDMessage und LoadFromFile aus einem Verzeichnis, in dem ich meine Mails sichere, die Mails mit Datum und Betreff einlesen kann. Wenn jedoch eine Mail nicht geladen werden kann, hängt sich der Thread an der Stelle LoadFromFile auf. Gibt es eine Möglichkeit, dass ich vorher prüfen kann, ob <TiDMessage-Object>.LoadFromFile(...) erfolgreich ausgeführt werden kann?

Hallo,

du könntest mit FileExists vorher prüfen ob die Datei vorhanden ist.

Grüße
Klaus

Die Datei ist vorhanden und ich kann sie auch via Doppelklick öffnen. Nur LoadFromFile hat Probleme und hängt sich auf. Bis jetzt konnte ich nur eine Mail ausmachen, wo es Probleme gibt, allerdings habe ich das Programm bis jetzt auch nur auf einen Bruchteil meiner gesicherten Mails angesetzt. Deswegen möchte ich diesen Fehler gern codetechnisch lösen.

Hallo,

Mails müssen am Ende immer eine oder zwei Leerzeilen und 'ne Zeile, in der nur ein Punkt ist, haben (schau mal in die Spezifikation RFC ichweissleidernichwas - siehe unten). Wenn die Leerzeile(n) und/oder Punkt am Ende fehlen, kommt idMessage (nach meiner Erfahrung) mit den Dateien nicht zurecht (da ja noch nicht die vollständige Mail empfangen wurde).
Schau mal nach, ob das Problem bei allen Mails passiert oder nur bei einigen und ob Du durch anhängen von Leerzeilen an dem Problem vorbeikommst.

In meinem Programm mache ich das so:

zusammenfalten · markieren

Delphi-Quellcode:

...
    sl := TStringList.Create;
    st := TMemoryStream.Create;
    Try
      Try
        sFileName := sr.FindData.cFileName;
        sl.LoadFromFile(sDirectory + '\' + sFileName);
        sl.Add('');
        sl.Add('.');
        sl.Add(' ');
        sl.SaveToStream(st);
        st.Position := 0;
        Try
          IdMessage.LoadFromStream(st);
        except
          on e : Exception do Begin
            stb2.SimpleText := sDirectory + '\' + sFileName + ' - ' + e.Message;
          end;
        end;
...

Zitat von Delphi-Hilfe:

TIdMessage encapsulates a complete Internet Message as described in the Internet Standards documents:

RFC 822 - Standard for the Format of ARPA Internet Text Messages (http://www.rfc-editor.org/rfc/rfc822.txt)
RFC 1036 - Standard for Interchange of USENET Messages (http://www.rfc-editor.org/rfc/rfc1036.txt)

TIdMessage is used with message-based protocols, such as POP3, SMTP, and NNTP. TIdMessage supports Multipurpose Internet Mail Extensions (MIME) as described in the Internet Standards documents:

RFC 2045 - Multipurpose Internet Mail Extensions (MIME), Part One: Format of Internet Message Bodies (http://www.rfc-editor.org/rfc/rfc2045.txt)
RFC 2046 - Multipurpose Internet Mail Extensions (MIME), Part Two: Media Types (http://www.rfc-editor.org/rfc/rfc2046.txt)
RFC 2047 - Multipurpose Internet Mail Extensions (MIME), Part Three: Message Header Extensions for Non-ASCII Text (http://www.rfc-editor.org/rfc/rfc2047.txt)
RFC 2048 - Multipurpose Internet Mail Extensions (MIME), Part Four: Registration Procedures (http://www.rfc-editor.org/rfc/rfc2048.txt)

RFC 2049 - Multipurpose Internet Mail Extensions (MIME), Part Five: Conformance Criteria and Examples (http://www.rfc-editor.org/rfc/rfc2049.txt)

Danke für die Antwort . Das werde ich mal prüfen.

zusatz:
Und siehe da, besagter Mail fehlt die Lehrzeile am Ende der Mail.

In der Borland-Hilfe zum Developer Studio 2006 ist das direkt falsch erklärt. Da steht:

Zitat:

When AHeadersOnly is False, only header values up to and including the blank line delimiter in RFC message headers will be read from the input file. When AHeadersOnly is True, both message Headers and MessageParts will be read into the message instance.

Ich hatte den Wert jedoch schon vorher auf True, und so wurde ja nur der Header geladen. Trotzdem hängt sich der Thread noch immer an dieser Stelle auf bei bestimmten Mails, mit einer fehlenden Leerzeile am Ende der Mail hat das leider nichts zu tun .

Hallo,

kannst Du mal so eine Mail, die hakt, hier anhängen? Würde mir das dann mal anschauen und ggfls. mit meinem (pseudo)-Spamfilter testen. Kannst aber auch mal so'ne Mail per PN schicken.

Eine PN mit der Mail als Anhang ist unterwegs.

Hallo,

habe mir die Mail mal angeschaut und mit meinem Programm auch ein Problem gehabt.
Die Mail enthält einen Anhang, der von IDMessage decodiert wird, hierbei tritt der Fehler "Ungleichmäßige Größe in DecodeToStream" auf und anschließend gibt es dann noch 'ne Zugriffsverletzung.

Das Problem konnte ich dadurch lösen, dass ich am Ende der Datei zwei Leerzeilen eingefügt habe.
Der Mailanhang hat in etwa diese Form:

markieren

Code:

------ =_DIRMAIL_1_N8NN3L9GM4636JHO
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: BASE64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs
...
ICA8L3RyPgo8L3RhYmxlPgoJPC9ib2R5Pgo8L2h0bWw+Cg0K

------ =_DIRMAIL_1_N8NN3L9GM4636JHO--

Befindet sich am Ende kein Zeilenumbruch, so wird das Ende von IDMessage nicht erkannt, was zu dem von Dir beobachteten Problem führt. Prinzipiell ist es kein Fehler, wenn Du die Mails in der von mir in Post #4 beschriebenen Form lädst. Du kannst dort getrost grundsätzlich zwei Leerzeilen anhängen, zuviel ist kein Problem, nur zuwenig.

Hallo,

was mir gerade noch auffällt:

Wenn der Virenscanner den Anhang beim Dekodieren durch IDMessage als verseucht erkennt, tritt der Fehler "Ungleichmäßige Größe in DecodeToStream" auch auf, da er dem Programm die beim Dekodieren erstellte Datei "unterm Hintern" wegzieht. Beim Dekodieren werden die Anhänge im Tempverzeichnis abgelegt, mit Namen in der Form "ind*.tmp". Da diese Dateien nicht immer ordentlich aufgeräumt werden, sollte man hier ab und an mal "nacharbeiten".