GabrielG: IMAP: Zu Mails mit Content-Type "related"

Hallo zusammen,

ich rufe Mails mit PHP-IMAP ab, analysiere sie und schicke sie ggf. weiter (per PEAR Mime_mail). Das ganze funktioniert auch solange ganz gut wie ich "einfache" Mails mit Plaintext oder formatiertem HTML-Text ggf. auch mit Anhängen habe.
Aber ich beiße mir gerade die Zähne an den Mails aus, die in den Textfluss ingetrierte Bilder haben - bei denen also Bilder nicht normal angehängt werden sondern integriert und per content-id angesteuert werden. Dateiname und -Typ sowie die Content-ids lassen sich ja mit imap_fetchstructure wunderbar auslesen.
Aber beim Mailbody hänge ich: Ich hätte für den Text den Subtype HTML erwartet, finde aber PLAIN vor. Außerdem hätte ich erwartet, dass ich im HTML-Code die content-ids der Bilder finde, aber stattdessen kommt nur Text, der nach einem Alternativ-Tag aussieht.

Kann es sein, dass PHP-IMAP diese Mails falsch parst (und nur den Alternativ-Textinhalt anzeigt) oder habe ich da irgendwo einen Denkfehler?
Bei einer Testmail sagt mir "imap_fetchstructure" es gäbe nur Part 0 und Part 1. Part 0 (bzw. in der Zählweise mit Header Part 1) ist laut "imap_fetchbody" der Text als Plaintext ohne Hinweis auf die Stelle des Bildes und ohne HTML-Formatierungen und Part 1 (bzw. 2) ist das Bild. Versuche Part 3, 1.1 oder ähnliches anzusteuern geben nichts zurück.

Ich würde mich sehr freuen, wenn mir da jemand weiterhelfen könnte.

Gruß,
GMG

  1. Hallo,

    ich rufe Mails mit PHP-IMAP ab, analysiere sie und schicke sie ggf. weiter (per PEAR Mime_mail).

    wenn du sie weiterleitest - warum dann nicht in ihrer ursprünglichen Form? Mir scheint, du machst dir erst die Mühe, die Mailstruktur aufzudröseln (für die Analyse okay) und danach neu aufzubauen.

    Aber beim Mailbody hänge ich: Ich hätte für den Text den Subtype HTML erwartet

    Ich nicht. Ich hätte multipart/alternative erwartet, und darin text/plain als erste Alternative, und multipart/related als zweite Alternative; darin wiederum text/html als ersten Block, und image/* als weitere Blöcke.
    Schließlich soll eine HTML-Mailnachricht ihren Inhalt ja immer alternativ als Plaintext mitbringen.

    Kann es sein, dass PHP-IMAP diese Mails falsch parst (und nur den Alternativ-Textinhalt anzeigt) oder habe ich da irgendwo einen Denkfehler?

    Kann ich anhand deiner Angaben nicht sagen. Du zeigst uns weder den Quelltext der Mailnachricht, noch Auszüge aus deinem PHP-Code.

    Bei einer Testmail sagt mir "imap_fetchstructure" es gäbe nur Part 0 und Part 1.

    So würde ich es erwarten - nämlich text/plain und multipart/related.

    Part 0 (bzw. in der Zählweise mit Header Part 1) ist laut "imap_fetchbody" der Text als Plaintext ohne Hinweis auf die Stelle des Bildes und ohne HTML-Formatierungen

    Richtig.

    und Part 1 (bzw. 2) ist das Bild.

    Das sollte nicht sein. Part 1 (bzw. Part 2 nach IMAP-Numerierung, siehe Beispiel in der Spec) sollte der multipart/related-Container sein, Part 2.1 dann text/html, und erst 2.2 bis 2.n sollten die eingebundenen Bilder sein.

    Versuche Part 3, 1.1 oder ähnliches anzusteuern geben nichts zurück.

    Wenn die Message so aufgebaut ist, wie ich erwarten würde, gibt es auch weder Part 3, noch Part 1.1.

    Ich würde mich sehr freuen, wenn mir da jemand weiterhelfen könnte.

    Dazu solltest du zunächst mal die tatsächliche (nicht interpretierte) Struktur der untersuchten Message zeigen.

    So long,
     Martin

    --
    Paradox ist, wenn der Innenminister sich äußert und der Außenminister sich erinnert.
    Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
    1. Hello,

      Dazu solltest du zunächst mal die tatsächliche (nicht interpretierte) Struktur der untersuchten Message zeigen.

      Ja, das dachte ich auch.

      Dazu sollte GabrielG aber bitte eine gaaanz kleine Testmail erzeugen mit zwei klitzekleinen eingebettenen Bildern, damit man Lust hat, das auch zu lesen. Die Daten sollten dann auch ruhig vollständig und benutzbar hier gepostet werden, damit man es nicht alles selber tippen muss zum Testen.

      Liebe Grüße aus dem schönen Oberharz

      Tom vom Berg

      --
       ☻_
      /▌
      / \ Nur selber lernen macht schlau
      http://bergpost.annerschbarrich.de
      1. Danke euch schonmal. Ich dachte es wäre vielleicht schon offensichtlich wo evtl. ein Denkfehler meinerseits vorliegt. Hier ist die Mail und die Struktur. Die Mail wurde per Outlook 2010 versendet.

        Hier ist die Mail (mit kleinem Bild ;)) wie sie von IMAP-Body ausgegeben wird:

        Beginn Mail

        This is a multipart message in MIME format.

        ------=_NextPart_000_0020_01CBF398.66B249D0
        Content-Type: text/plain;
        charset="iso-8859-1"
        Content-Transfer-Encoding: 7bit

        Das ist ein Text, hier kommt ein Bild:

        Und hier formatierter Text. Ende.

        ------=_NextPart_000_0020_01CBF398.66B249D0
        Content-Type: image/png;
        name="image001.png"
        Content-Transfer-Encoding: base64
        Content-ID: image001.png@01CBF398.663D40E0

        iVBORw0KGgoAAAANSUhEUgAAACAAAAAPCAIAAAAK4lpAAAAB6ElEQVR4nLVUsW4TQRB9I/kLzJfg
        VAlFCqCwG4cCyT+BaPgBKj6AjpKGNHQIRSIUUToK01FBHUtpHCcO2ZndeRS7e+vEOaVidTrtzWne
        zHv7ZuXP4hr/cw263fHJ3CwFs4Px3o/5r/4UkhCQJEAn4U6Q7gBJB50k6XCula3As/3RJsxsvHMX
        lfC6d4IESRIkPFdrkRL/+PnLAA8tAiBYP1gjAAFB/YOMC5FXzwX4m+Lg/fHZ4vy2RDGGYAeTJz1V
        MlgmAzJjtneJAtcxrlSHkIury16JbssjrQw3mi5CCUBQCFJ4k+LKbKk6JDXooGPfL1CDbU9VGdJp
        LwRAWQVdqi41EJLcG4PvJz/NYrA4He/elaZQr+rU3kEScAKQTICQRx9Oh6ATAFPaKPB0//GWNBlN
        kvunr3PVpGaq8cZiUA0hBotmUS2+e/MSHRMQhBAOELzfRR6VxRclMpuMwAbhnhunE+hs6s2vnbzb
        Etl0vOd0OpHnCQBw2M/g7esXGY6gQLIlvNbpkYgugDf3YzYeeR5c1iHuRozVTpBOW6k07peIpY3q
        7Gbxct7ejF+OiiWtGqK6c0sijdPJLt3ZQEtuzsmXBFCO0TfGvNaX1gwgvxfrbQZH305V12eL84ur
        Sw2a3FPyByamZ/0D2FgPrqgIniUAAAAASUVORK5CYII=

        ------=_NextPart_000_0020_01CBF398.66B249D0--

        Ende der Mail

        Die Interpretierte Struktur ist die folgende:

        Beginn Struktur

        stdClass Object
        (
            [type] => 1
            [encoding] => 0
            [ifsubtype] => 1
            [subtype] => RELATED
            [ifdescription] => 0
            [ifid] => 0
            [ifdisposition] => 0
            [ifdparameters] => 0
            [ifparameters] => 1
            [parameters] => Array
                (
                    [0] => stdClass Object
                        (
                            [attribute] => boundary
                            [value] => ----=_NextPart_000_0020_01CBF398.66B249D0
                        )

        )

        [parts] => Array
                (
                    [0] => stdClass Object
                        (
                            [type] => 0
                            [encoding] => 0
                            [ifsubtype] => 1
                            [subtype] => PLAIN
                            [ifdescription] => 0
                            [ifid] => 0
                            [lines] => 6
                            [bytes] => 83
                            [ifdisposition] => 0
                            [ifdparameters] => 0
                            [ifparameters] => 1
                            [parameters] => Array
                                (
                                    [0] => stdClass Object
                                        (
                                            [attribute] => charset
                                            [value] => iso-8859-1
                                        )

        )

        )

        [1] => stdClass Object
                        (
                            [type] => 5
                            [encoding] => 3
                            [ifsubtype] => 1
                            [subtype] => PNG
                            [ifdescription] => 0
                            [ifid] => 1
                            [id] => image001.png@01CBF398.663D40E0
                            [bytes] => 748
                            [ifdisposition] => 0
                            [ifdparameters] => 0
                            [ifparameters] => 1
                            [parameters] => Array
                                (
                                    [0] => stdClass Object
                                        (
                                            [attribute] => name
                                            [value] => image001.png
                                        )

        )

        )

        )

        )

        Ende Struktur
        1. Hallo,

          Hier ist die Mail und die Struktur.

          leider fehlt der globale Mail-Header. Wichtig ist vor allem dessen Content-Type-Feld, denn was du im folgenden wiedergibst, passt tatsächlich nicht so recht zum "common practise". Allerdings stimmen deine Ergebnisse, die mich erst so verwundert haben, mit dieser merkwürdigen Struktur überein.

          Die Mail wurde per Outlook 2010 versendet.

          Outlook war schon immer dafür bekannt, gern Bockmist zu produzieren. :-(

          This is a multipart message in MIME format.

          ------=_NextPart_000_0020_01CBF398.66B249D0
          Content-Type: text/plain;
          charset="iso-8859-1"
          Content-Transfer-Encoding: 7bit

          Das ist ein Text, hier kommt ein Bild:

          Und hier formatierter Text. Ende.

          ------=_NextPart_000_0020_01CBF398.66B249D0
          Content-Type: image/png;
          name="image001.png"
          Content-Transfer-Encoding: base64
          Content-ID: image001.png@01CBF398.663D40E0

          iVBORw0KGgoAAAANSUhEUgAAACAAAAAPCAIAAAAK4lpAAAAB6ElEQVR4nLVUsW4TQRB9I/kLzJfg
          VAlFCqCwG4cCyT+BaPgBKj6AjpKGNHQIRSIUUToK01FBHUtpHCcO2ZndeRS7e+vEOaVidTrtzWne
          zHv7ZuXP4hr/cw263fHJ3CwFs4Px3o/5r/4UkhCQJEAn4U6Q7gBJB50k6XCula3As/3RJsxsvHMX
          lfC6d4IESRIkPFdrkRL/+PnLAA8tAiBYP1gjAAFB/YOMC5FXzwX4m+Lg/fHZ4vy2RDGGYAeTJz1V
          MlgmAzJjtneJAtcxrlSHkIury16JbssjrQw3mi5CCUBQCFJ4k+LKbKk6JDXooGPfL1CDbU9VGdJp
          LwRAWQVdqi41EJLcG4PvJz/NYrA4He/elaZQr+rU3kEScAKQTICQRx9Oh6ATAFPaKPB0//GWNBlN
          kvunr3PVpGaq8cZiUA0hBotmUS2+e/MSHRMQhBAOELzfRR6VxRclMpuMwAbhnhunE+hs6s2vnbzb
          Etl0vOd0OpHnCQBw2M/g7esXGY6gQLIlvNbpkYgugDf3YzYeeR5c1iHuRozVTpBOW6k07peIpY3q
          7Gbxct7ejF+OiiWtGqK6c0sijdPJLt3ZQEtuzsmXBFCO0TfGvNaX1gwgvxfrbQZH305V12eL84ur
          Sw2a3FPyByamZ/0D2FgPrqgIniUAAAAASUVORK5CYII=

          ------=_NextPart_000_0020_01CBF398.66B249D0--

          Eindeutig eine Plaintext-Mail mit einem Bild als Anhang. Der globale Content-Type ist dann vermutlich multipart/mixed. - Oder der Mail-Quelltext ist nicht vollständig.

          Ciao,
           Martin

          --
          Theorie ist, wenn jeder weiß, wie's geht, und es geht trotzdem nicht.
          Praxis ist, wenn's geht, und keiner weiß warum.
          Bei uns sind Theorie und Praxis vereint: Nichts geht, und keiner weiß warum.
          Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
          1. Hallo,

            Hier ist die Mail und die Struktur.

            leider fehlt der globale Mail-Header. Wichtig ist vor allem dessen Content-Type-Feld, denn was du im folgenden wiedergibst, passt tatsächlich nicht so recht zum "common practise". Allerdings stimmen deine Ergebnisse, die mich erst so verwundert haben, mit dieser merkwürdigen Struktur überein.

            Die Mail wurde per Outlook 2010 versendet.

            Outlook war schon immer dafür bekannt, gern Bockmist zu produzieren. :-(

            Hallo,

            ja, das sieht mir auch sehr seltsam aus, vor allem der NextPart-Trenner am Schluss, nach dem definitiv nichts mehr kommt, so seltsam es auch aussieht. Hier ist der Header (leicht geschwärzt):

            Beginn Header

            Return-Path: <xx>
            X-Spam-DCC: wuwien: xx 1290; Body=1 Fuz1=1
            X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on
            xx
            X-Spam-Level:
            X-Spam-Status: No, score=-1.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,
            TVD_RCVD_SINGLE autolearn=no version=3.2.5
            X-Original-To: xx
            Delivered-To: xx
            Received: from GMG (xx [xx])
            by xx (Postfix) with ESMTPSA id 818A92F04C2D
            for <xx>; Tue,  5 Apr 2011 13:50:15 +0200 (CEST)
            From: =?iso-8859-1?Q?xx?= <xx>
            To: <xx>
            Subject: Der Betreff
            Date: Tue, 5 Apr 2011 13:50:18 +0200
            Message-ID: 001f01cbf387$a32952c0$e97bf840$@xx
            MIME-Version: 1.0
            Content-Type: multipart/related;
            boundary="----=_NextPart_000_0020_01CBF398.66B249D0"
            X-Mailer: Microsoft Outlook 14.0
            Thread-Index: Acvzh33/E/N0ipMfSK6U9TEn1ChVWg==
            Content-Language: de

            Ende Header
            1. Hi,

              leider fehlt der globale Mail-Header.

              Return-Path: <xx>
              X-Spam-DCC: wuwien: xx 1290; Body=1 Fuz1=1
              X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on
              xx
              X-Spam-Level:
              X-Spam-Status: No, score=-1.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,
              TVD_RCVD_SINGLE autolearn=no version=3.2.5
              X-Original-To: xx
              Delivered-To: xx
              Received: from GMG (xx [xx])
              by xx (Postfix) with ESMTPSA id 818A92F04C2D
              for <xx>; Tue,  5 Apr 2011 13:50:15 +0200 (CEST)
              From: =?iso-8859-1?Q?xx?= <xx>
              To: <xx>
              Subject: Der Betreff
              Date: Tue, 5 Apr 2011 13:50:18 +0200
              Message-ID: 001f01cbf387$a32952c0$e97bf840$@xx
              MIME-Version: 1.0
              Content-Type: multipart/related;
              boundary="----=_NextPart_000_0020_01CBF398.66B249D0"
              X-Mailer: Microsoft Outlook 14.0
              Thread-Index: Acvzh33/E/N0ipMfSK6U9TEn1ChVWg==
              Content-Language: de

              Ah, da isser ja. Nun ja, schon sehr merkwürdig. multipart/related wäre der richtige Containertyp für HTML+eingebettete Grafiken. Dann aber text/plain reinzupacken, ist Murks, das ergibt keinen Sinn.

              Outlook war schon immer dafür bekannt, gern Bockmist zu produzieren. :-(
              ja, das sieht mir auch sehr seltsam aus, vor allem der NextPart-Trenner am Schluss, nach dem definitiv nichts mehr kommt, so seltsam es auch aussieht.

              Der ist okay. Das Ende eines multipart-Containers wird markiert, indem der um zwei Minuszeichen "--" ergänzte boundary-String als Abschluss gesetzt wird.

              Also fehlt dir offensichtlich erstmal eine korrekt (sprich: sinnvoll) aufgebaute Mailnachricht, um deine Analyse zu testen. Mit dieser Testmail, die du hier gezeigt hast, kannst du nur ausprobieren, was dein Script tut, wenn es Unsinn analysieren soll.

              So long,
               Martin

              --
              Chef:         Zum vierten Mal in dieser Woche erwische ich Sie nun schon beim Zuspätkommen. Was haben Sie dazu zu sagen?
              Angestellter: Dann muss heute Donnerstag sein.
              Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
              1. Hi Martin

                Also fehlt dir offensichtlich erstmal eine korrekt (sprich: sinnvoll) aufgebaute Mailnachricht, um deine Analyse zu testen. Mit dieser Testmail, die du hier gezeigt hast, kannst du nur ausprobieren, was dein Script tut, wenn es Unsinn analysieren soll.

                Ich habe gerade feststellen müssen, dass wir ein Phantom gejagt haben, dass sich in Outlook versteckt hat :(. Und dass es sich hier um einen weiteren der zahlreichen Bugs in Office 2010 handelt.
                Outlook ist bei mir gerade so eingestellt, dass es standardmäßig Mails per S-Mime signiert. Ich habe jedoch die Testmail explizit nicht signieren lassen, damit ich es mir für den Anfang nicht noch schwerer mache wie nötig.
                Hätte ich jedoch entweder eine signierte Mail verschickt oder die standardmäßige Signierung dekativiert hätte mir Outlook eine Mail in der Form abgeliefert wie ich sie auch erwartet hätte :(. Kaum ist die standardmäßige Signierung dekativiert läuft das ganze auch schon fast komplett so wie es soll.

                Vielen Dank dir für deine Hilfe! Ich hatte nicht an Outlook gezweifelt sondern so langsam an meinem eigenen Verstand - da du es aber genauso gesehen hast habe ich angefangen Outlook zu hinterfragen, was dann auch zum Ziel geführt hat.

                Noch eine kleine OT-Frage, da du ja der Fachmann in dem Gebiet bist: Ich habe einen HTML-Part mit Encoding 3 (Quoted Printable) und Charset UTF-8.
                Ist es korrekt wenn ich ihn wie folgt decode?
                $html = utf8_decode(quoted_printable_decode(imap_fetchbody($this->connection, $message_id, $section)));
                Dann wird aber der Dash "=E2=80=93" zu "?" und genauso auch "=C2=B7", "=E2=80=9E" und "=E2=80=9C". Natürlich kann man sich die 4 Zeichen mit str_replace und Konsorten wieder zurechtmurksen, aber es muss doch auch eine saubere Lösung geben, oder?

                Gruß
                GabrielG

                1. Hi,

                  Ich habe einen HTML-Part mit Encoding 3 (Quoted Printable) und Charset UTF-8.
                  Ist es korrekt wenn ich ihn wie folgt decode?
                  $html = utf8_decode(quoted_printable_decode(imap_fetchbody($this->connection, $message_id, $section)));

                  Dabei werden dir ggf. enthaltene Sonderzeichen, die in ISO-8859-1 nicht abbildbar sind, verloren gehen.

                  Dann wird aber der Dash "=E2=80=93" zu "?" und genauso auch "=C2=B7", "=E2=80=9E" und "=E2=80=9C". Natürlich kann man sich die 4 Zeichen mit str_replace und Konsorten wieder zurechtmurksen, aber es muss doch auch eine saubere Lösung geben, oder?

                  Klar - UTF-8 in der Webanwendung verwenden.

                  MfG ChrisB

                  --
                  RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?
                  1. Hi ChrisB,

                    Ich habe einen HTML-Part mit Encoding 3 (Quoted Printable) und Charset UTF-8.
                    Ist es korrekt wenn ich ihn wie folgt decode?
                    $html = utf8_decode(quoted_printable_decode(imap_fetchbody($this->connection, $message_id, $section)));

                    Dabei werden dir ggf. enthaltene Sonderzeichen, die in ISO-8859-1 nicht abbildbar sind, verloren gehen.

                    Wie kann man das vermeiden? Gibt es keine Standardfunktionen zum Umwandeln in die entsprechenden HTML-Entities, die man ja durchaus in ISO-8859-1 abbilden kann?

                    Dann wird aber der Dash "=E2=80=93" zu "?" und genauso auch "=C2=B7", "=E2=80=9E" und "=E2=80=9C". Natürlich kann man sich die 4 Zeichen mit str_replace und Konsorten wieder zurechtmurksen, aber es muss doch auch eine saubere Lösung geben, oder?

                    Klar - UTF-8 in der Webanwendung verwenden.

                    Das wäre der direkte Weg, ist im konkreten Fall aber leider nicht umsetzbar. Wenn diese Mail nach einer Prüfung (und automatisierten Bearbeitung) wieder versendet werden soll wird sie automatisch als ISO-8859-1 versendet und nicht als UTF-8. Da ich PEAR-Mail_mime für die Generierung der Mail verwende habe ich da leider keinerlei Einfluss drauf. Zumindest habe ich noch nicht herausgefunden wie man Mail_mime sagen kann, dass es UTF-8 nehmen soll. Siehe:
                    http://pear.php.net/reference/Mail_Mime-latest/Mail_Mime/Mail_mime.html#methodsetHTMLBody

                    Gruß
                    GabrielG

                    1. Hi,

                      Dabei werden dir ggf. enthaltene Sonderzeichen, die in ISO-8859-1 nicht abbildbar sind, verloren gehen.

                      Wie kann man das vermeiden? Gibt es keine Standardfunktionen zum Umwandeln in die entsprechenden HTML-Entities, die man ja durchaus in ISO-8859-1 abbilden kann?

                      Doch, die gibt es. Wie die heißt, findest du selber raus ...?

                      Klar - UTF-8 in der Webanwendung verwenden.

                      Das wäre der direkte Weg, ist im konkreten Fall aber leider nicht umsetzbar. Wenn diese Mail nach einer Prüfung (und automatisierten Bearbeitung) wieder versendet werden soll wird sie automatisch als ISO-8859-1 versendet und nicht als UTF-8. Da ich PEAR-Mail_mime für die Generierung der Mail verwende habe ich da leider keinerlei Einfluss drauf. Zumindest habe ich noch nicht herausgefunden wie man Mail_mime sagen kann, dass es UTF-8 nehmen soll. Siehe:
                      http://pear.php.net/reference/Mail_Mime-latest/Mail_Mime/Mail_mime.html#methodsetHTMLBody

                      Siehe *Google*
                      http://www.pear-forum.de/fpost9450.html#9450

                      MfG ChrisB

                      --
                      RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?
                      1. Hi ChrisB,

                        Wie kann man das vermeiden? Gibt es keine Standardfunktionen zum Umwandeln in die entsprechenden HTML-Entities, die man ja durchaus in ISO-8859-1 abbilden kann?

                        Doch, die gibt es. Wie die heißt, findest du selber raus ...?

                        Ich hatte mal
                        $html = mb_convert_encoding($html, 'HTML-ENTITIES', 'UTF-8');
                        probiert, aber das hat mir in Outlook die Aufzählungspunkte zerbröselt (durch "&#61623" ersetzt - im Webmailer dagegen hat es gepasst). Etwas besseres konnte ich aber nicht finden.

                        Klar - UTF-8 in der Webanwendung verwenden.

                        Das wäre der direkte Weg, ist im konkreten Fall aber leider nicht umsetzbar. Wenn diese Mail nach einer Prüfung (und automatisierten Bearbeitung) wieder versendet werden soll wird sie automatisch als ISO-8859-1 versendet und nicht als UTF-8. Da ich PEAR-Mail_mime für die Generierung der Mail verwende habe ich da leider keinerlei Einfluss drauf. Zumindest habe ich noch nicht herausgefunden wie man Mail_mime sagen kann, dass es UTF-8 nehmen soll. Siehe:
                        http://pear.php.net/reference/Mail_Mime-latest/Mail_Mime/Mail_mime.html#methodsetHTMLBody

                        Siehe *Google*
                        http://www.pear-forum.de/fpost9450.html#9450

                        Danke für den Link! Da habe ich Google wohl die falschen Suchbefehle gegeben. Damit hat sich der obere Murks erledigt.

                        Gruß
                        Gabriel