Autor: Björn Tantau

Ein Kunde rief an, weil eine Kundin von ihm sich beschwert hätte, dass die von unserem Shopsystem generierte Bestellbestätigung ziemlich seltsam aussieht. Nun, für Laienaugen muss sie das getan haben, weil der HTML-Teil mit inkorrekt umgesetzten UTF-8 Zeichen zu sehen war. Und die angehängte PDF-Datei mit den AGB wurde auch komplett im Mailtext angezeigt, was den Datenmüll schön abrundete.

Wieso sollte das auf einmal falsch laufen, wenn es die ganze Zeit über keine Beschwerden gab? Ich ging der Sache auf den Grund und habe getestet, wie das ganze in verschiedenen Clients angezeigt wird. Zuerst in KMail, der Mailclient, den ich standardmäßig verwende. Alles in Ordnung. Mozilla Thunderbird: Alles in Ordnung. Microsoft Outlook: Alles in Ordnung. Microsoft Outlook Express: Kann kein UTF-8, das ist aber auch schon alles. Squirrelmail: Alles in Ordnung.

Bei genauerem Hinsehen fiel mir auf, dass in der beanstandeten Mail die Boundary, also die Zeichenfolge, die besagt, dass ein neuer Teil der E-Mail beginnt, mit im Text erschien. Das sollte eigentlich nicht sein. Die Kundin benutzt web.de, vielleicht hat es mit deren Webclient zu tun. Zum Glück habe ich bei web.de noch eine Wegwerfadresse. Ich lasse mir an die eine Bestellbestätigung schicken und tatsächlich kommt die Mail zerschossen an.

Zum Vergleich will ich mir das ganze nochmal in einem Client einrichten. Da ich auf Jeannie noch Thunderbird offen hab‘ wird der halt genommen und dort auch schnell der web.de-Zugang eingerichtet. Zur Sicherheit schicke ich nochmal die Bestellbestätigung an meine Arbeitsadresse. Und auf einmal hat der Thunderbird auch Probleme mit der Darstellung. Dabei klappte doch vorher alles!

Ein Vergleich der Quelltexte der funktionierenden Mail mit der nicht-funktionierenden zeigte mir ein paar Gänsefüßchen hinter der Boundary im Kopf der nicht-funktionierenden Mail. Ich untersuchte das Skript, das die E-Mail erzeugte und fand dort auch das Anführungszeichen. Nach dem Entfernen funktionierte alles wieder. (Also, nicht ganz, zuerst hatte ich die ganze Zeit die falsche Datei auf dem Testserver bearbeitet und bis ich das herausgefunden hatte sind mir schon eine Menge Flüche über die Lippen gegangen.)

Aber wieso hat es vorher funktioniert und dann auf einmal nicht mehr? Nun, die Sache war so. KMail hat den Header automatisch korrigiert und die korrigierte Mail wieder auf den IMAP-Server geladen. Deshalb sah die Mail in allen anderen Clients auch richtig aus. Auf so etwas muss man erst einmal kommen!

Ich sagte also dem Kunden Bescheid, dass ich den Fehler gefunden hätte und fragte ihn, ob er es trotzdem zur Sicherheit nochmal testen könnte. Wenig später kam dann der Anruf, dass es immer noch nicht klappte. 🙁

Nach weiterer erfolgloser Suche fragte ich ihn, ob er mir einen Ausdruck schicken könnte. Beim Weiterleiten werden gerne mal Mailfehler noch eine ganze Ecke schwerer zu diagnostizieren. Einem Kunden zu erklären, wie er die komplette Mail samt Header weiterleitet ist meistens mehr oder weniger unmöglich.

Auf dem Ausdruck bot sich mir dann ein schrecklicher Anblick. Bei GMX wurde mehr oder weniger der ganze Header im Mailtext angezeigt. Und hinter jeder Header-Zeile war eine Leerzeile. Ein bisschen googlen eröffnete mir dann, dass GMX nicht mit CRLF (das Zeilenende; in PHP setzt man das mit „\r\n“ um) zurecht kommt und das ganze zerpflückt. Ich musste also nicht-RFC-konform handeln und aus den CRLF ein LF machen. Ich glaube, die Anzahl der Mailserver, die damit nicht zurecht kommen ist geringer als die Anzahl der GMX-User, also wird das wohl mehr oder weniger keine negativen Konsequenzen haben.

Aber trotzdem… Weiß einer wen ich bei GMX zur Sau machen muss, damit die das korrigieren? 😡