Ok, bei dir also genauso wie bei mir. Dann weiss ich wenigstens schon einmal, daß mein Mailfilter da nicht irgendwas dazwischengepfuscht hat.
Ich habe ein wenig in den Mail / MIME RFC gelesen. Das Subject muss so komisch encodiert werden da der Mail Standard vorschreibt, daß im Mailheader nur ASCII-Zeichen vorkommen dürfen. Bei Headereinträgen bei denen das nicht der Fall ist, also z.B. Subject mit Umlauten darin, muss das Subject mit sogenannten Encoded Words umschrieben werden. Zudem dürfen Headereinträge nicht länger sein als 76 Zeichen. Daher werden mehrere Encoded Words aneinandergekettet.
In dem Beispiel hier haben wir also zwei Encoded Words:
=?utf-8?B?TmV1ZSBBbnR3b3J0IHp1IE1pdGdsaWVkZXIgbmFjaCBlaW5lciBaZWl0IGzD?=
=?utf-8?B?tnNjaGVuIGxhc3Nlbg==?=
Ein Encoded Word beginnt mit der Definition des Zeichensatzes (=?utf-8) gefolgt von der Definition des Encodings (?B für Base64, alternative wäre ?Q für quoted-printable. Normalerweise wird ?Q eingesetzt da das im Gegensatz zu ?B leserlich ist wenn das Subject zum Teil aus ASCII besteht). Darauf hin folgt dann der eigentliche encodete String gefolgt von dem Schlussmarker ==?=.
Das Problem hier ist nun, daß streng genommen, diese Encoded Words in sich abgeschlossene Einheiten sein sollen. Ein Encoded Word mit =?utf-8 behauptet von sich, einen UTF-8 String encodiert zu haben. Das ist in dem von MyBB produzierten Encoded Wort jedoch nicht der Fall, da der Buchstabe ö, der in UTF-8 aus zwei Bytes besteht, auseinandergerissen wurde. Daher endet das erste UTF-8 Encoded Word mit einem Zeichen das nicht UTF-8 ist, und das zweite UTF-8 Encoded Word beginnt dementsprechend mit einem Zeichen das nicht UTF-8 ist.
Ob das nun in Mailprogrammen korrekt dargestellt wird, hängt davon ab, wie diese Programme arbeiten... entweder sie dekodieren einfach nur den encodierten String als Bytefolge, und setzen das dann später ohne nähere Prüfung wieder zusammen... dann ist die Darstellung korrekt weil das auseinandergerissene ö wieder zusammengesetzt wurde
...oder das Mailprogramm versucht jedes Encoded Word einzeln als UTF-8 String zu verstehen und als UTF-8 Zeichen darzustellen, das scheitert dann an den beiden unvollständigen Zeichen, die nicht in den angegebenen Zeichensatz hineinpassen und daher dann als ?? auftauchen.
Streng genommen ist es ein Bug in MyBB, die Angabe dass es sich bei dem Encoded Word um UTF-8 handelt stimmt einfach nicht, wenn darin UTF-8 Zeichen zerstückelt werden. Es wird halt netterweise trotzdem in vielen Mailprogrammen deswegen keine Darstellungsschwierigkeiten geben.
Ich markiere das hier einfach mal als erledigt da Problem nun bekannt, ich kann bei mir bei Gelegenheit die Funktion utf8_encode in der class_mailhandler.php durch etwas anderes ersetzen.
(Wobei ich mich bei der Gelegenheit frage, wieso man sowas in PHP eigentlich überhaupt selber machen muss. Mail ist so ein stinkaltes Protokoll da hätte ich eine Standardkonforme Implementierung in der Sprache selbst erwartet).
Auch nicht Standardkonform ist, daß MyBB das Subject dann in einer Zeile beläßt statt jedem Wort seine eigene Zeile zu geben. Das könnte auch mit einem Bug zusammenhängen
http://bugs.php.net/bug.php?id=45955 der jedoch nie bestätigt bzw. dementiert wurde.
Wenn ich selbst so ein Subject anlege sieht es in der RAW Mail so aus:
Code:
Subject: =?utf-8?B?44Gy44KJ44GM44Gq44Kr44K/44Kr44OK?=
=?utf-8?B?5ryi5a2XIERhcyBpc3QgamEgc293YXMgdm9uIGxhbmd3ZWlsaWcsIMOkw6Q=?=
=?utf-8?B?w6RoIGphIHNvIHdlcmRlbiB3aXIgbmllIHBhbGF2w6Rybi4gw4TDlsOcw6Q=?=
=?utf-8?B?w7bDvMOfLg==?=
Also schön auf mehrere Zeilen verteilt.
Ich werde mir mal anschauen wie andere CMS das Mailproblem in PHP angehen, eventuell kann man sich da bei einem anderen GPL Projekt eine passende Funktion organisieren gehen
