Outlook 11 vs. application/pdf

[Ignatios Souvatzis]

Hi, folgendes Phänomen:

ein Empfänger einer E-mail antwortet mir mit etwas, was folgende
Header produziert:

X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18463
X-Mailer: Microsoft Office Outlook 11

und beklagt sich, dass etwas mit folgender Struktur:

MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="/04w6evG8XlLl3ft"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

--/04w6evG8XlLl3ft
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

text text

--/04w6evG8XlLl3ft
Content-Type: application/pdf
Content-Disposition: attachment; filename="filiname.pdf"
Content-Transfer-Encoding: base64

JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIv

schwer zu lesen sei, ... wie sich nach Rueckfrage herausstellt, weil
das base64-kodierte PDF roh dargestellt wird, also tatsaechlich als
Text "JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgM..."

Warum macht Outlook 11 sowas - und wie kann es ein Windows- und überhaupt
Computerlaie dazu bringen, das sein zu lassen?

-is
--
seal your e-mail: http://www.gnupg.org/

[Andreas Kohlbach]

Müssten die Delimeter (hier "--/04w6evG8XlLl3ft") sich nicht
unterscheiden in den beiden Parts? Sieht mir aus, als seien die identisch.
--
Andreas
30. When the odds are 200 to 1 against you, it's no problem.
- Arcade Wisdom

[Michael Landenberger]

"Andreas Kohlbach" schrieb am 22.11.2012 um 01:53:39:

> Müssten die Delimeter (hier "--/04w6evG8XlLl3ft") sich nicht
> unterscheiden in den beiden Parts? Sieht mir aus, als seien die identisch.

Nein, die müssen sogar gleich sein. Schließlich müssen sie mit dem im Header
deklarierten "Boundary"-String übereinstimmen, und ein "Boundary"-String kann
nur einmal pro MIME-Part deklariert werden.

Ich gehe davon aus, dass der OP die Einrückung des Text- und PDF-Parts nur zur
besseren Übersicht vorgenommen hat und diese Parts in der Original-Mail nicht
eingerückt sind. Ansonsten könnte das die Ursache für die Fehlinterpretation
durch Outlook sein: Boundary-Strings und die folgenden Part-Header dürfen
nicht eingerückt sein.

Gruß

Michael

[Ignatios Souvatzis]

Michael Landenberger wrote:
> "Andreas Kohlbach" schrieb am 22.11.2012 um 01:53:39:

> Ich gehe davon aus, dass der OP die Einrückung des Text- und PDF-Parts nur zur
> besseren Übersicht vorgenommen hat und diese Parts in der Original-Mail nicht
> eingerückt sind.

Genau. Was halt mutt-1.5.nuschel produziert.

> Ansonsten könnte das die Ursache für die Fehlinterpretation
> durch Outlook sein: Boundary-Strings und die folgenden Part-Header dürfen
> nicht eingerückt sein.

Nein, sind sie nicht. Hat bisher jedes Windows-System verstanden,
das am anderen Ende war. Der letzte, der mir mit fragendem Blick
rohes base64 gezeigt hat, war ein Benutzer, der partout neumodischer
Software nicht traute und deshalb bei /usr/ucb/mail blieb. Aber
das ist ca. 15 Jahre her.

-is

[Andreas Kohlbach]

Michael Landenberger wrote on 22. November 2012:
>
> "Andreas Kohlbach" schrieb am 22.11.2012 um 01:53:39:
>
>> Müssten die Delimeter (hier "--/04w6evG8XlLl3ft") sich nicht
>> unterscheiden in den beiden Parts? Sieht mir aus, als seien die identisch.
>
> Nein, die müssen sogar gleich sein. Schließlich müssen sie mit dem im Header
> deklarierten "Boundary"-String übereinstimmen, und ein "Boundary"-String kann
> nur einmal pro MIME-Part deklariert werden.

Umm... Muss die ID im Header nicht über dem ersten Part des Body
auftauchen? Der dann am Ende wiederum die ID des folgenden Parts hat,
und ggf. der folgende Part am Ende die des darauf folgenden Parts, etc?

Bei OP sieht es so aus, als ob das für den ersten Part richtig war. Der
zweite Part aber wieder die ID des ersten Parts hat.
--
Andreas
15. Repulsive, ugly, cannabalistic, evil beings have just as much right to be
loved as heroic fighters.
- Arcade Wisdom

[Michael Landenberger]

"Andreas Kohlbach" schrieb am 23.11.2012 um 00:47:13:

> Bei OP sieht es so aus, als ob das für den ersten Part richtig war. Der
> zweite Part aber wieder die ID des ersten Parts hat.

Was verstehst du unter "ID"?

Der im Header der Mail deklarierte Boundary-String ist jedenfalls
"/04w6evG8XlLl3ft". Ein Part beginnt dort, wo dieser String mit
vorangestelltem '--' (2 Minuszeichen) im Mail-Body steht. Taucht der String
mit den beiden Minuszeichen mehrfach auf, unterteilt er die Mail in mehrere
Parts, d. h. immer dort, wo der String steht, endet der vorangegangene Part
und es beginnt ein neuer Part. Genau das ist bei der vom OP beschriebenen Mail
der Fall. Am Ende des letzten Parts steht wieder der Boundary-String, diesmal
aber mit vorangestelltem *und* hinten drangehängtem '--'. Diese Zeile hat der
OP nicht mitzitiert, aber ich gehe davon aus, dass sie vorhanden ist. Sie
steht vermutlich am Ende des Base64-codierten PDF-Anhangs.

Man kann also eine Mail mit mehreren Parts (bzw. einen Part mit mehreren
Unter-Parts) problemlos mit lauter gleichen Strings in Parts bzw. Unter-Parts
unterteilen. Es geht auch gar nicht anders, denn im Mail-Header (bzw. im
Header des Parts) lässt sich jeweils nur ein einziger Boundary-String
definieren.

Im vorliegenden Fall entsprechen die Header exakt den Vorgaben. Dass Outlook
den codierten PDF-Anhang als Text darstellt, ist ein Fehler von Outlook.
Leider habe ich keine Ahnung, wie man Outlook diesen Fehler austreiben kann.

Gruß

Michael