Regelmässig erhalten wir Mails, die mit Apple-Mail erstellt wurden und Anhänge wie z.B. PDFs beinhalten.

Problem: Mails werden hier generell mit thunderbird im Textmodus, also nicht im HTML-Modus gelesen. Und dabei wird bei Mails, die mit Apple-Mail erstellt wurden, nicht angezeigt, dass die Mail einen Anhang hat.

Erst bei Umschalten in die HTML-Ansicht mittels des thunderbird add-ons "Allow HTML Temp" wird angezeigt, dass die Mail eine Anlage hat. Das ist ärgerlich und führte hier schon zu verschiedenen Irritationen bis hin zu verspäteter Zahlung von Rechnungen, da nicht erkennbar war, dass eine PDF-Datei Bestandteil der Mail war.

Woran liegt das? Was ist das Problem?

Apple-Mail generiert bei einer neuen Mail zunächst zwei Teile gemäss RFC 2046, diese werden dann im Header der Mail als

Content-Type: multipart/alternative;
    boundary="boundary42"

gekennzeichnet. Der erste Teil der neuen Mail (eingeleitet durch den boundary-String) ist dann

--boundary42
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;

So weit, so gut.

Als zweiter Teil der Mail wird von Apple-Mail ein neues multipart-Element erzeugt, diesmal allerdings "multipart/mixed":

--boundary42
Content-Type: multipart/mixed;
     boundary="newboundary43"

Ein "multipart/mixed"-Element als Kind der "mutlipart/alternative"-Mail? Macht keinen sinnvollen Eindruck...

Der erste Teil des neuen multipart/mixed-Elements ist nun

--newboundary43
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;

und der zweite Teil der ggf vorhandene Anhang

--newboundary43
Content-Disposition: inline;
	filename="Rechnung.pdf"
Content-Type: application/pdf;
	name="Rechnung.pdf"

D.h. der Anhang ist nur im zweiten Teilelement der Mail enthalten, nicht im Hauptelement, der eigentlichen Mail.

Dann folgt der End-Boundary für den mixed-part

--newboundary43--

und dann noch der End-Boundary für die Gesamtnachricht

--boundary42--

Und jetzt ist die Frage, wer hier seine Hausaufgaben nicht gemacht hat:

1. thunderbird, weil es die bevorzugte Reihenfolge der Mail-Teile ignoriert? Der letzte Teil (hier also der multipart/mixed-Teil) ist gem. o.g. RFC der wichtigste und zu bevorzugen?
2. Apple, weil es ein multipart/mixed-Element in ein multipart/alternative-Element einbettet?

Ich tendiere ganz klar zu Antwort 2. Sinnvoller wäre es, wenn nur multipart/mixed verwendet würde und die Dateianhänge dann als eigenes Element generell sichtbar wären.