MIME-Struktur einer E-Mail: multipart/alternative, der Klartextteil und Kodierungen

Worum es geht

Eine E-Mail besteht aus einem Header-Block gefolgt von einem Body; MIME lässt den Body zu einem Baum von Teilen werden, jeder mit eigenem Content-Type. Eine Nachricht mit Text- und HTML-Version verwendet multipart/alternative. RFC 2046 verlangt, dass die Teile in aufsteigender Präferenzreihenfolge angeordnet werden, wobei das bevorzugte Format zuletzt steht, sodass text/plain zuerst und text/html zuletzt kommt; Clients zeigen den letzten Teil an, den sie darstellen können. Inline-Bilder stecken in einem multipart/related-Wrapper um den HTML-Teil; Anhänge kommen in ein äusseres multipart/mixed. Bodys mit Nicht-ASCII-Bytes deklarieren eine Content-Transfer-Encoding: quoted-printable für überwiegend ASCII-Text (kodierte Zeilen sind mit weichen Umbrüchen auf 76 Zeichen begrenzt) oder base64 für Binärdaten. Header-Felder wie Subject und Anzeigenamen können in klassischer Mail kein rohes UTF-8 tragen; RFC-2047-Encoded-Words (=?utf-8?q?...?=, jeweils höchstens 75 Zeichen) umschliessen sie.

Warum es wichtig ist

Mail ohne Textteil, mit einem Textteil, der nur «diese Nachricht in einem HTML-Client ansehen» sagt, oder mit einem Betreff, dessen Umlaute als Fragezeichen ankommen, liest sich für Filter wie für Menschen wie Spam. Die meisten Fehler in Vorlagen stecken auf dieser Ebene: Escaping, Kodierung und Zeilenlänge, nicht der Text selbst.

So wird es angewendet

• Den Klartextteil aus denselben Daten wie das HTML erzeugen, statt Tags zu entfernen: Überschriften als Zeilen, Links als label: URL, Tabellen als Listen. Beide Vorlagen an einem Ort halten, sodass eine Änderung an der einen auch eine Änderung an der anderen ist.
• Nachrichten mit der MIME-Bibliothek der Plattform aufbauen (zum Beispiel Pythons email-Paket); Boundaries nie von Hand zusammensetzen.
• Jede in den HTML-Teil eingefügte Variable nach denselben Regeln wie bei Webseiten escapen und den Textteil frei von HTML-Entities halten.
• Die Bibliothek quoted-printable für Text und base64 für Anhänge wählen lassen; Quellzeilen kurz halten, da das Nachrichtenformat (RFC 5322) Zeilen auf 998 Zeichen begrenzt und 78 empfiehlt.
• Nicht-ASCII-Betreffzeilen und Anzeigenamen über Encoded-Words leiten; mit einem Namen testen, der Umlaute und ein Emoji enthält.
• Absolute HTTPS-URLs und Inline-CSS verwenden; externe Stylesheets und Skripte werden von Mail-Clients ignoriert oder blockiert.

Stolpersteine

Ein Textteil, der einmal geschrieben und bei einer Änderung des HTML vergessen wird. Alternative Teile in der falschen Reihenfolge, sodass Text bevorzugende Clients den falschen anzeigen. Ein als UTF-8 deklarierter Zeichensatz, während die Bytes tatsächlich Latin-1 sind. multipart/related-Bilder ohne Content-ID-Referenzen, die als Anhänge ankommen. Tracking-Weiterleitungen im Textteil, wo die lesende Person die rohe URL sieht.