Dieser Artikel stammt im englischen Original von Jörg Knobloch und ist hier zu finden.
Alles, was Sie jemals über 8-Bit-Bytes und beschädigte E-Mails wissen müssen, die die Server von Verizon, Yahoo, AOL, AT&T, Bellsouth, SBCglobal etc. durchlaufen haben.
Ein kurzer Ausflug in die Geschichte der Kodierungen
Laut diesem Wikipedia-Artikel wurde das 8-Bit-Byte bereits in den 1960er-Jahren als Grundeinheit für adressierbare digitale Informationen eingeführt. Damals wurden sowohl ASCII- als auch EBCDIC-Codierungen erfunden. ASCII ist eine 7-Bit-Codierung, bei der nur die unteren sieben Bits des 8-Bit-Bytes verwendet werden, während EBCDIC eine 8-Bit-Codierung ist, bei der alle acht Bits verwendet werden. Als Computer populärer wurden und international verwendet wurden, wurden andere "lokale" 8-Bit-Codierungen erfunden, beispielsweise die ISO-8859-Zeichensätze ISO-8859-1 für "westliche" lateinische Sprachen mit deutschen, französischen und spanischen Zeichen (äöü) , áéíóú usw.), ISO-8859-7 für Griechisch und viele mehr. Microsoft hat diese Codierungen später durch Hinzufügen des Euro-Zeichens (€) erweitert, sodass ISO-8859-1 durch Windows-1252 und ISO-8859-7 beispielsweise durch Windows-1253 ersetzt wurden. Alle diese Ein-Byte-8-Bit-Codierungen waren immer noch nicht für Sprachen geeignet, die einen größeren Zeichensatz verwenden, z. B. Chinesisch, Japanisch und Koreanisch (normalerweise als CJK zusammengefasst). Für diese wurden also andere Codierungen erstellt. Am Ende setzte sich Unicode und die UTF-8-Codierung durch. UTF-8 ist eine 8-Bit-Codierung, bei der jedes Zeichen mit einem oder mehreren Bytes codiert wird. Wenn nur ein Byte verwendet wird, stellt das Byte ein 7-Bit-ASCII-Zeichen dar. Wenn mehrere Bytes verwendet werden, haben alle das höchste gesetzte Bit. Mit anderen Worten, ein einzelnes Byte mit dem höchsten gesetzten Bit ist in UTF-8 nicht gültig.
Dies ist theoretisch alles, was Sie wissen müssen, um Folgendes zu verstehen. Beachten Sie, dass im folgenden Text ein Highbit-Byte ein 8-Bit-Byte mit dem höchsten gesetzten Bit ist, also > 80 in hexadezimaler Schreibweise. Ein 8-Bit-Zeichen kann nicht in einfachem 7-Bit-ASCII codiert werden, sondern muss mit High-Bit-Bytes codiert werden.
E-Mail-Übertragung
Es ist wichtig zu wissen, dass in den frühen Tagen einige E-Mail-Server nur die unteren sieben Bits (Content Transfer Encoding 7bit) übertragen konnten, aber heutzutage können die meisten E-Mail-Server Highbit-Bytes (CTE 8bit) verarbeiten. Beim Versenden einer E-Mail wird der SMTP-Server abgefragt, ob er die sogenannte 8BITMIME-Fähigkeit besitzt. Thunderbird ignoriert das Ergebnis jedoch, da fast alle modernen Server 8BITMIME unterstützen, einige davon, ohne dies explizit anzugeben.
Wie wir im nächsten Abschnitt sehen können, meldet Yahoo sogar explizit 8BITMIME-Fähigkeit zurück.
8BITMIME und Yahoo
Yahoo-Server unterstützen 8BITMIME (Stand: 30. Juli 2019). Um dies zu beweisen, führen Sie telnet smtp.mail.yahoo.com 25 aus, gefolgt von EHLO Yahoo. Das Ergebnis ist:
250-smtp408.mail.ir2.yahoo.com Hello Yahoo [95.23.45.31])
250-PIPELINING
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-SIZE 41697280
250 STARTTLSWarum enthält meine E-Mail auch 8-Bit-Zeichen, wenn ich scheinbar nur englischen Text schreibe?
Viele Benutzer sind der Meinung, dass sie nicht von 8-Bit-Problemen betroffen sein dürften, da sie nur englischen Text schreiben, der vermeintlich nur 7-Bit-ASCII benötigt. Das ist aber nicht der Fall. Sobald sie zwei aufeinanderfolgende Leerzeichen in eine E-Mail eingeben, erstellen sie 8-Bit-Zeichen, da das erste Leerzeichen in Windows-1252 als ein Byte A0 oder in UTF-8 als zwei Bytes C2 A0 codiert ist. Außerdem verwenden englische Schriftsteller manchmal intelligente Anführungszeichen oder "lange" (also typographische) Bindestriche, die nicht mit einem 7-Bit-ASCII-Zeichen codiert werden können. Daher wird ein 8-Bit-Zeichen verwendet.
Was ist das Problem beim Senden von E-Mails über einen Yahoo SMTP-Server
Die von Verizon, Yahoo, Bellsouth, AT&T, Sbcglobal und anderen betriebenen E-Mail-Server sind seit Februar 2018 als fehlerhaft bekannt. Der Wechsel zwischen zwei fehlerhaften Zuständen zerstört zeitweise alle 8-Bit-Zeichen, andernfalls nur 8-Bit-Zeichen von Nicht-UTF -8-Kodierungen (mehr unten).
Der ursprüngliche Autor dieses Artikels (Jörg Knobloch) hat seit Februar 2018 unzählige Test-Mails verschickt. 8-Bit-Unterstützung bei Yahoo & Co. hat nie funktioniert, eine der folgenden Verfälschungen wurde immer beobachtet.
Zustand 1: Alle 8-Bit-Zeichen werden zerstört
In diesem Fall werden alle Highbit-Bytes in allen Codierungen durch ein Fragezeichen "?" ersetzt. Beispiel: Ein Benutzer sendet "Hi Bob, raining today". Bob empfängt: "Hi Bob,? raining today" oder "Hi Bob,?? raining today", abhängig davon, ob die E-Mail in Windows-1252 kodiert gesendet wurde, wurde das erste Leerzeichen als A0 übertragen, oder sie in UTF-8 kodiert gesendet wurde, wo das erste Leerzeichen C2 A0 übertragen wurde. Es ist unnötig zu erwähnen, dass alle anderen 8-Bit-Zeichen, wie äöü, áéíóú, jeder griechische oder CJK-Text vollständig unleserlich werden, da High-Bit-Bytes unabhängig von der Kodierung verwendet werden. Zum Beispiel wird "Hägar" wieder zu "H?gar" oder "H??gar", abhängig von der verwendeten Kodierung, entweder ein Byte in Windows-1252 oder zwei in UTF-8.
Zustand 2: Alle Highbit-Bytes werden als UTF-8 interpretiert, andere Kodierungen zerstört
Dies ist die kompliziertere Beschädigung. Wenn sich Yahoo-Server so verhalten, werden alle in UTF-8 codierten Nachrichten unversehrt durch die Server geleitet. Nachrichten, die andere Codierungen wie Windows-1252 verwenden, sind jedoch auf unschöne Weise beschädigt. Im Allgemeinen sollten Mailserver den Nachrichteninhalt nicht interpretieren und unverändert weitergeben. Yahoo verstößt jedoch dagegen und ändert den E-Mail-Inhalt. In diesem Zustand interpretiert Yahoo alle Highbit-Bytes in einer Nachricht als UTF-8. Enthält eine Nachricht ein Highbit-Byte, das in der UTF-8-Codierung nicht gültig ist, wird es durch das sogenannte UTF-8-Ersetzungszeichen � ersetzt, das als drei Bytes EF BF BD codiert ist. Wir müssen uns daran erinnern, dass einzelne Highbit-Bytes, die in den ISO-8859- oder Windows-12xx-Kodierungen verwendet werden, alle ungültig sind, wenn sie als UTF-8 interpretiert werden, da in UTF-8 auf das erste Highbit-Byte mindestens ein weiteres Highbit-Byte folgen müsste. Das in Windows-1252 nicht umbrechende Leerzeichen A0 oder der Windows-1252-codierte Buchstabe "ä", E4 als Byte, wird durch EF BF BD (also � ) ersetzt. Es wird aber noch schlimmer. Der empfangende E-Mail-Client, der beispielsweise die (im Header angegebene) Codierung der Nachricht berücksichtigt, zeigt sie als Windows-1252 an. Und in Windows-1252 wird die Byte-Sequenz EF BF BD als Zeichenfolge � angezeigt. Genau, der Buchstabe "i" mit Diaeresis, eine spanische Öffnung "¿" und der Bruch "½". Beispiel: Ein Benutzer sendet "Hi Bob, raining today...". Bob empfängt: "Hi Bob,� raining today". Es erübrigt sich zu erwähnen, dass Nachrichten, die 8-Bit-ISO-8859- oder Windows-12xx-Codierungen wie Griechisch verwenden, vollständig unlesbar werden.
Was bei Verizon, Yahoo, AOL etc. eigentlich passieren müsste
Eigentlich hätte dieser technisch schreckliche und nervige Fehler bei Verizon, Yahoo, AOL und Co. einen Sturm von Beschwerden auslösen müssen. Der Autor dieses Artikels hat sich zweimal in Yahoo-Foren beschwert, bevor diese Hilfe-Foren geschlossen wurden. Der Community-Manager von Thunderbird hat sich mehrmals an den verantwortlichen Manager von Verizon gewandt. Keine Änderung des Yahoo-Verhaltens außer dem Wechsel von Status 1 zu Status 2 oder umgekehrt. Die E-Mail, die im Juni 2019 an Yahoo gesendet wurde, finden Sie hier. Diese beschreibt nur Zustand 2, da dies das Verhalten zum Zeitpunkt des Schreibens war.
Was Sie in Thunderbird (als Workaround) machen können
Thunderbird kann angewiesen werden, alle Nachrichten in reinem 7-Bit-ASCII-Format zu senden. Dabei wird die QP-Codierung (Quoted Printable) verwendet, bei der alle Highbit-Bytes als Hexadezimalwert mit vorangestelltem "=" übertragen werden. So wird der Buchstabe "ä" oder E4 in Windows-1252 als String =E4 übertragen. Dies ist aber sehr ineffizient, da dadurch die Datenmenge, die übertragen und auf Mailservern gespeichert werden muss, bis zum Dreifachen anwachsen wird. Das ist auch der Grund, warum die QP-Codierung in Thunderbird nicht die Standardeinstellung ist. Um die QP-Codierung einzuschalten, legen Sie die Voreinstellung mail.strictly_mime im Konfigurationseditor auf "true" fest.
Als betroffener Anwender richten Sie bitte auf jeden Fall eine Beschwerde an den Support bei Ihrem Postfach-Anbieter, wenn Sie ein Postfach bei einem der genannten Anbieter (die übrigens zumindest teilweise zusammengehören!) besitzen! Sie können in Ihrer Beschwerde sicherlich gerne auf das englische Original dieses Artikels verweisen: 8-bit bytes and e-mail corruption at Verizon, Yahoo, etc.
Nur dann wird man dort vielleicht in Zukunft für Abhilfe sorgen und sich korrekt an Standards halten, anstatt seine Anwender im Regen stehen zu lassen und zu Workarounds zu nötigen.