Multipart Mime

Wenn Sie sich auf der Seite Envelope und Header und Codierung anschauen, wie eine SMTP-Mail über die Leitung geht, dann sehen Sie neben dem Envelope, dem Header und dem Body keine weiteren Bestandteile. Wo sind dann die Anlagen einer Mail zu finden ?

Mehrere Inhalte im Body

In der Anfangszeit der Mails wurden wirklich nur "TextOnly- Emails" versendet und viele wünschen sich vieleicht diesen Zustand zurück. Die Mails waren klein, die Verfasser haben sich nicht mit Formatierungen aufgehalten und jeder Client konnte die Mails lesen. Aber auch damals wurden natürlich schon Anlagen übertragen. Dazu hat man ganz am Anfang die binären Anlagen einfach ein einen ASCII-Text übersetzt. Das Programm UUENCODE/UUDECODE war so ein Verfahren, um aus einer 8bit-Datei einen ASCII-Text zu machen, den der Anwender dann einfach in den Body der Mail eingefügt hat.

Dies ist ein Test mit UUENCODE
begin 644 test.txt
>1&EE<R!I<W0@96EN(%1E<W0@;6ET(%5514Y#3T1%
`
end

Das "Begin" und End" wurde sehr bald schon direkt von Mailprogrammen erkannt, so dass der Anwender einfach auf die Dateien zugreifen konnte. Aber die Codierung nach ASCII war natürlich nicht gerade optimal und auch wenn UUENCODE funktioniert, so war es den neuen Funktionen nicht mehr gewachsen. Anwender wollten ja nicht nur mehrere Anlagen anfügen, sondern auch formatiert Mails (HTML-Mails) senden und digital Verschlüsseln und Signieren. Letztlich hat MIME (http://de.wikipedia.org/wiki/Multipurpose_Internet_Mail_Extensions) diese Plattform geschaffen. Damit ist es möglich, mehrere Inhalte in einer Mail zu hinterlegen und der Client kann sogar auswählen, welche Version er dem Anwender anzeigt.

Das ist z.B. auch der Weg eine Mail sowohl als "TextOnly" als auch als HTML-Mail zu senden. Ein leistungsfähiger Client wird ihnen die farbenfrohe formatierte Version anzeigen, während ein rudimentärer Client auf die Text-Version zurückgreifen kann

Bislang hat mir noch niemand die Folgen beschreiben können, wenn Text und HTML-Version sich unterscheiden sollten. Welche "Version" ist dann zutreffend, wenn per Mail Verträge, Betellungen o.ä. ausgeführt werden ?. Der Empfänger sieht ja nur "eine" Version.

MIME

Eines der Ziele von MIME ist eine saubere Deklaration des Inhalts um Interpretierungen zu verhindern. Eine reine Text-Mail ist zwar weiterhin möglich, aber neu ist hier der Content-Type und die Angabe des Encoding.

MIME-Version: 1.0
From: 1&1 Internet AG <support@service.1und1.de>
Subject: Ihr Vertrag
To: frank.carius@netatwork.de
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Date: Thu, 13 Sep 2012 17:39:16 +0200

Hier ist dann die Message

Nur weil jemand "nur Text" schreibt, bedeutet das ja nicht, dass er auf umlaute oder andere Sonderzeichen verzichten möchte. Diese sind aber im reinen 7-Bit-ASCII natürlich nicht vorhanden. Über die Angabe eines "Encoding" ist es aber möglich, ein optimiertes Verfahren zu wählen, welches die Mail nicht so stark aufbläht. Die Mails selbst enthält am Ende übrigens nicht den "." als Abschluss Das ist wieder Teil des Envelope.

Interessanter wird es nun, wenn eine Mail mehrere Elemente enthält. Dann kann der Versender ein "MultiPart-MIME" darauf machen, wie an folgendem Beispiel einer Mail deutlich wird, die eine HTML-Mail ist, die aber auch einen Textanteil hat. Sie besteht aus drei Blöcken. Zudem gibt es im Header den Content-Type "multipart".

  • Einem Basistext
    Den bekommt jeder zu sehen, der keinen MIME-tauglichen Mailclient verwendet. Der "versteht" die neuen Abschnitte ja nicht
  • text/plain
    Die ist die "Text"-Version der Mail
  • text/html
    Die ist die "HTML"-Version der Mail
From: "Frank Carius" <frank.carius@netatwork.de>
To: <fra---nk@carius.de>
Subject: Test
MIME-Version: 1.0
Message-ID: <04d87e94-2836-46e5-8caa-7f11e56a8353@xtinmta101.xt.local>
Content-Type: multipart/alternative;
	boundary="ABCDEFG1234=_?:"

This is a multi-part message in MIME format.

--ABCDEFG1234=_?:
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 8bit

Ist ist der Textteil der Mail

--ABCDEFG1234=_?:
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
    <head>
        <title>Test</title>
    </head>
    <body>
        <h1>Ueberschrift</h1>
        <p>Dies ist der HTML-Teil der Mail</p>
    </body>
</html>

--ABCDEFG1234=_?:--

Sie sehen aber auch, dass die Abschnitte mit einem "Trenner"  (Hier "--ABCDEFG1234=_?:--") voneinander separiert sind, der oben im Header auch aufgeführt wird.

Dies ist nur eine einfache Mail. Wenn Sie Anlagen mit senden, gibt es weitere Teile und ein Teil selbst kann auch wieder ein "Multipart"-Teil sein, der dass Verschachtelungen möglich sind. Gerade HTML-Mails lagern auch Bilder in eigene Parts aus. Hier eine Textmail mit einem PDF-Attachment:

MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0036_01CD9129.277A8540"

This is a multipart message in MIME format.

------=_NextPart_000_0036_01CD9129.277A8540
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Siehe PDF-Anlage

------=_NextPart_000_0036_01CD9129.277A8540
Content-Type: application/pdf;
	name="sample.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="sample.pdf"

JVBERi0xLjYNJeLjz9MNCjYgMCBvYmogPDwvTGluZWFyaXplZCAxL0wgNDcwODA4L08gOC9FIDQ2
NjIzOC9OIDEvVCA0NzA2NDIvSCBbIDEyMTYgMjU4XT4+DWVuZG9iag0gICAgICAgICAgICAgICAg

------=_NextPart_000_0036_01CD9129.277A8540--

Wenn sie einmal den Aufbau von MIME verstanden haben, dann sollte es recht einfach sein, die Inhalte korrekt auszulesen.

Probleme mit Multipart Mime

Dennoch gibt es immer wieder "Probleme" mit Mails, bei denen anscheinend die Anlagen nicht vorhanden sind, die "besonders Groß" sind aber man nichts davon sieht etc. Dann hilft ein Blick in die Quelle um zu prüfen, ob es "Parts" gibt, die vielleicht einfach nicht angezeigt werden.

Es gibt natürlich auch "böse Sender", die absichtlich eine Mail falsch formatieren um entsprechende Schwächen beim Client des Empfängers auszunutzen, d.h. Buffer Overflows o.ä. oder es zumindest zu versuchen.

Exchange wurde von Version zu Version hier immer strenger und wenn eine Mail von einem IMAP4-Client vielleicht noch angezeigt wird, so kann es bei Exchange sein, dass er bei der Konvertierung der Mail in sein eigenes Format nicht so tolerant ist. Es ist schließlich ein unterschied, ob ein Server einen Speicherüberlauf hat oder "nur" ein Client. Das fällt z.B. auch auf, wenn Mail an ein Exchange Postfach per Regel an ein anderes System weitergeleitet werden sollen. Wenn Exchange die Mail nicht "versteht", dann packt es diese lieber als Ganzes in eine Anlage und sendet eine neue Mail mit der defekten Mail als Anlage. Das kann beim eigentlichen Empfänger natürlich zu einem Stirnrunzeln führen oder schlimmstenfalls automatische Verarbeitungen (EDIFACT, PDF-Rechnungen etc.) stören.

Wenn der Absender einer solchen Mail bekannt ist und der Fehler reproduzierbar ist, dann ist ein Pipelinetracing eine Möglichkeit die Mail beim Empfang als RAW-Format zu erhalten und auch die weitere Verarbeitung zu analysieren. Sollte dies nicht möglich sein, dann können Sie versuchen die defekte Mail per IMAP4/POP3 oder MFCMAPI/Exfolders zu lesen und so noch mal an die "RAW-Information" zu kommen oder mit NETMON oder Wireshark die Mail mitzuschneiden. Das ist besonders dann gefragt, wenn Pipelinestracing keinen "Sender" finden kann, weil das FROM-Feld schon nicht korrekt ist, wie in diesem Beispiel eines SAP-System:

Rot eingekreist ist das FROM-Feld, welches anscheinend viele Leerzeichen und auch Zeilenumbrüche enthält. Hinzu kommt, dass auch der Body ein Multipart ist, dessen erster Teil ein "text/plain" ist aber keinen Inhalt enthält. Nicht jedes Mailprogamm kommt mit so einer Mail zurecht und warum solte jemand einen "Null-part" addieren, dann könnte er diesen gleich weg lassen.

Alternativ kann der Sender die gleiche Mail aber auch einfach an einen Freemailer wie GMX/WEB.DE senden, die auch einen Zugriff auf das RAW-Forma zulassen. Diese Systeme verändern die Mail in der Regel nicht.

Mit ein bisschen Glück können Sie den Fehler in der Formatierung oder Codierung erkennen und dem Sender die richtigen Hinweise geben.

Weitere Links