IMAP: Zu Mails mit Content-Type "related"

[GabrielG]

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

[Der Martin]

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

[Tom]

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

[GabrielG]

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

[Der Martin]

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

[GabrielG]

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

[Der Martin]

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

[GabrielG]

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

[ChrisB]

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

[GabrielG]

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

[ChrisB]

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

[GabrielG]

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