Das kann man gar nicht so abschließend beantworten. Aber vielleicht helfen ein paar Informationen weiter, mit denen Du Deine eigenen Rückschlüsse ziehen kannst:
Mails bestehen grob gesagt aus Header, Body und Anhängen.
Der Mailtext wird dabei oft als "text/plain" verschickt, dann ist er im Body zu finden. Oder (nur) als "text/
html", dann ist er bei den Indys in den Messageparts zu finden. Oft gibt es auch beides, also den reinen Text und eine alternative Fassung des Textes, die ist dann auch den "Messageparts" zu finden. Das sind dann i.d.R.
HTML-Fassungen, könnte aber auch (ganz, ganz selten) RTF sein. Im Mailheader ist darüber eine Info zu finden, dort steht dann z.B. "multipart/alternative". Ich habe aber auch schon erlebt, dass im Body-Text eine Art Mini-
HTML verwendet wurde, der Text aber als "text/plain" deklariert wurde.
Und Letzteres ist ein Beispiel für die ganzen Probleme beim Mails entschlüsseln und auch für die Limits, die in den
Indy-Komponenten stecken.
Indy's arbeiten voll
RFC-Konform, also nach internationalen Standards. Aber that's it. Wenn eine Mail einen Standard nicht einhält, dann wird eben ein Fehler ausgeworfen, eine weitere Abarbeitung der Mail findet dann ab der fehlerhaften Stelle nicht mehr statt.
Und es sind massenweise fehlerhafte Mails unterwegs, von irgendwelchen Web-Mailversendern, Eigenkonstruktionen von Firmen, was auch immer. Aus diesem Grunde rufe ich für mein Mail-Programm (Safer Mail) die Mails in der RAW-Fassung ab, also so, wie der Server mir die Daten anliefert, die Interpretation der Mails mache ich dann selber (was auch nicht einfach ist und selbst nach 10 Jahren Arbeit daran immer wieder nachtjustiert werden muss).
Will damit sagen, dass Du für Dein Projekt möglicherweise nicht alles 100%-tig dekodieren kannst, es sei denn, Du willst einen irren Aufwand dafür betreiben.
Du solltest also für Dein Projekt prüfen, ob der Body einen Text hat. Wenn ja, OK. Wenn nicht, dann must Du die Messageparts durchlaufen und anhand der Content-Type-Informationen prüfen, welche Textart vorliegt. Dann kannst Du z.B. aus einer
HTML-Mail eine reine Textmail machen (hier gibt es diverse Units im Netz zu finden, nach "
HTML to Text" suchen), es sei denn Du willst lieber die
HTML-Fassung verwenden, die könntest Du dann in einer TWebbrowser-Komponente anzeigen lassen. Wenn der
HTML-Text aber Schadcode enthalten sollte, könnte das ein Risiko sein, weil die TWebBrowser-Komponente für sich alleine keine Schutzfunktionen bietet.
Da gibt es aber auch noch ein paar andere Fallstricke, z.B. bei Textteilen, die als "inline" deklariert sind (prüft man im "Content-Disposition"-Eintrag). Die landen in den Messageparts und Du musst dann unter Umständen aus mehreren Messageparts einen einheitlichen Text gestalten. So gibt es Konstruktionen (z.B. bei Apple-Mails hatte ich schon diverse Fälle), wo der eigentliche Mailtext aus einer Komposition von einfachen
ANSI-Texten und
HTML-Texten bestand. Um das irgendwie anzeigen zu können, muss man daraus entweder einen neuen
HTML-Text basteln oder eben alles in reinen Text umwandeln.
Soweit die TidMessage-Komponente die Decodierung des in der Mail verwendeten Charsets nicht anbietet oder aufgrund einer fehlerhaften Komposition der Mail nicht schafft, musst Du den Mailtext selbst decodieren. Da kann z.B. in der einfachsten Form die Funktion "Utf8ToAnsi" verwendet werden, wenn ein UTF-8 codierter Text vorliegt. Die charset-Information findest Du im Header als Zusatz für den Content-Type bzw. jeweils bei den Messageparts.
Leider kann ich keinen Beispiel-Source-Code posten, da ich es ja wie gesagt, für meine Zwecke anders gelöst habe (neben den erläuterten technischen Gründen vor allem aber, um das Bedrohungspotential der Mail besser beurteilen zu können, bzw. in den Griff zu bekommen). Aber ich hoffe, die Ausführungen bringen Dich ein wenig weiter.