mb_send_mail() und seine Nutzungsvarianten

[Der Martin]

Hallo,

• Als Transfer-Encoding base64 zu benutzen, halte ich unter den gegebenen Umständen am bequemsten, hatte das auch gehofft, dass es so ist. Dass Du das ermittelt hattest, war mir bisher leider nicht aufgefallen.

naja, base64 ist als Transfer-Encoding wohl robust, weil dann plain ASCII auf dem Übertragungsweg genügt. Das erkauft man sich aber mit dem Nachteil, dass die Nachricht im Quellcode nicht mehr lesbar ist und das Transfervolumen um 1/3 zunimmt.

Eben mal an ein paar gesendeten Mails verifiziert: Mein Thunderbird (Linux) versendet Content-Type: text/plain; charset=utf-8 mit Content-Transfer-Encoding: 8bit, als quasi Klartext. MS Outlook (wahlweise Outlook 2016 oder Outlook 365) produziert dagegen hartnäckig base64.

Also mb_send_mail() produziert, da es ja UTF-8 verschickt, ein Mail, dessen Body wie folgt transportiert wird:

Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: BASE64

Für base64-codierten Content noch UTF-8 zu deklarieren, ist eigentlich Unfug. Da kommen sowieso nur ASCII-Zeichen vor; charset=ASCII würde also genügen.

Man könnte also damit jetzt jede Datei versenden, auch Bilder... Da wäre dann nur der Content-Type-Header falsch. Wird der Default-Header überschrieben, wenn man den explizit setzt?

Zumindest bei mail() ist das so (hab ich schon gemacht).

Und da in BASE64 die originalen Zeilenumbrüche ebenfalls kodiert werden, nimmt mb_send_mail() die Gelegenheit beim Schopf und bricht das BASE64-Zeug nach 76 Zeichen um, der Zeilnumbruch ist "\n". (Auch beim Shell-Programm base64 passiert genau das per Voreinstellung!)

Mich persönlich würde noch interessieren, woher die 76 kommt (also 78 incl. CRLF)? Die RFCs sprechen imho immer von 80 Bytes incl. CRLF!?

Es sind höchstens 80, gern auch weniger. Aber 78 wäre kein Vielfaches von 4, man würde also eine base64-Gruppe zerreißen. Deshalb 76.

Live long and pros healthy,
 Martin