MIME-Struktur — multipart, Plaintext-Teil und Content-Type

Wie eine E-Mail zusammengesetzt ist

Eine moderne Nachricht besteht fast nie aus einem einzigen Textblock. Sie ist ein Baum aus Teilen, und der Content-Type-Header sagt, nach welcher Regel er zu lesen ist. Drei Typen decken den Alltag ab:

• multipart/alternative — dieselbe Nachricht in mehreren Formaten. Der Client sucht sich eines aus.
• multipart/related — HTML plus die Bilder, die es per cid: einbindet. Die Teile gehören zusammen.
• multipart/mixed — die Nachricht plus echte Anhänge. Die Teile sind unabhängig.

Eine gut gebaute Mail mit Anhang und Inline-Bild verschachtelt alle drei: außen mixed, darin related, darin alternative. Die Reihenfolge innerhalb von alternative ist dabei nicht beliebig — nach RFC 2046 §5.1.4 steht die am wenigsten bevorzugte Fassung zuerst. Der Plaintext gehört also nach oben, HTML nach unten. Wer die Reihenfolge dreht, sorgt dafür, dass ein Teil der Empfänger den reinen Text angezeigt bekommt.

Was AnalyzeMy.Email prüft

• Content-Type der Nachricht und die Struktur der enthaltenen Teile
• Vorhandensein eines Plaintext-Teils — separat vom HTML-Teil ausgewiesen
• Größe beider Teile sowie ihr Verhältnis zueinander
• Anzahl der Bilder und das Verhältnis von Bild zu Text
• Anhänge mit ihren Dateitypen

Warum Filter das bewerten

Der fehlende Plaintext-Teil ist der häufigste Befund. Reines HTML ohne Textalternative gilt seit Jahren als Spam-Indikator, weil legitime Massenversender die Alternative praktisch immer mitliefern und automatisierte Spam-Werkzeuge sie oft weglassen. SpamAssassin und ähnliche Systeme vergeben dafür Punkte.

Der Plaintext darf keine Attrappe sein. Ein Textteil mit dem Inhalt „Diese Nachricht benötigt einen HTML-fähigen Client" ist schlechter als gar keiner: Er erfüllt die Form, liefert aber keinen Inhalt, und genau dieses Muster ist gut erkennbar. Der Textteil sollte dieselbe Aussage tragen wie das HTML.

Ein sehr hoher Bildanteil bei wenig Text ist das klassische Bild-Spam-Muster: Text als Grafik, damit inhaltliche Filter nichts zu lesen finden. Dass viele Clients Bilder erst auf Nachfrage laden, macht solche Nachrichten für Empfänger zusätzlich leer.

Empfehlungen

• Immer multipart/alternative mit einem echten, inhaltsgleichen Textteil senden.
• Reihenfolge einhalten: Plaintext zuerst, HTML zuletzt.
• Zeichensatz je Teil deklarieren — charset=utf-8 und eine passende Kodierung (quoted-printable oder base64). Fehlende Angaben führen zu zerschossenen Umlauten.
• Bilder nicht als Textersatz verwenden. Was inhaltlich wichtig ist, gehört als Text in die Nachricht.
• Struktur nicht überschachteln: Mehr Ebenen als nötig verwirren ältere Clients, ohne etwas zu gewinnen.