Codierung

Als die meisten der Leser noch Kinder waren, hat das Internet seine ersten Schritte getan. Damals haben wir alle von den heute verfügbaren Bandbreiten nur geträumt. Meine eigenen Anfänge waren 300baud Akustikkoppler und 2400er Modem. Viele Professoren haben uns versucht zu erklären, dass 9600 Baud über eine Telefonleitung das höchste der Gefühle sei, da Bandfilter das hörbare Spektrum beim Telefon auf 4,8KHz beschränken. Sehr bald gab es dann aber die 14400er Modem und heute ist DSL mit Megabit schon fast überall verfügbar.

Aber damals waren Bits und Bytes eben kostbar und eine Tatsache lässt sich bis heute nicht verbergen:; uS-ASCII war der Zeichensatz, den damals die ersten Computer verwendet haben. Natürlich gab es noch andere Zeichensätze, z.B. EBCDIC (IBM Mainframe) und weiter nationale Besonderheiten. Wer damals umlaute benutzten wollte, musste beim Apple][ z.B. auf die eckigen Klammern verzichten. Die Umschaltung erfolgte durch einen Schaltet, der in der Grafikkarte ein anderes Zeichensatz ROM aktiviert hat.

Damals wurde auch noch zwischen 7-bit und 8-bit unterschieden. US-ASCII basiert auf 7 Bits und konnte daher nur bis zu 127 Zeichen darstellen. Diese Grenzen verfolgen und auch noch heute, wenn wir eine Mail mit umlauten versenden wollen. Der kleinste gemeinsame Nenner aller Mailsystems ist 7-bit US-ASCII

Umlaute in Mails und Header

Die RC822 beschreibt, welche Zeichen in einer Mail enthalten sein dürfen. Kurze Antwort: uS-ASCII !.

Damit stellt sich natürlich die Frage, wie wir in Deutschland und viele andere Länder mit Sonderzeichen trotzdem alle Funktionen eine Mailprogramms nutzen können. Das funktioniert nur über eine Umsetzung dieser Sonderzeichen mit Hilfe von US-ASCII-Zeichen. Dazu wird eine besondere Zeichenkombination bestimmt, die eine Codierung einleitet. Heute werden die meisten Mails mittels der ISO8859-1-Codierung umgesetzt. Das sieht dann so aus.

Aus : "Düsentrieb, Daniel"   wird  "=?iso-8859-1?Q?D=FCsentrieb=2C_Daniel?="

Die Sonderzeichen "=?"  und "?=" schließen den String ein. Nach dem ersten "=?" folgt die Angabe der Codierung gefolgt von einem "?" und dann einer weiteren Angabe (Q= Quoted Printable) und einem weiteren ?. Dann folgt der eigentliche Text mit den besonders codierten Zeichen. Aus einem ü wird dann ein "=FC".

Wenn Sie hierzu mehr wissen wollen, dann ist die RFC1342 für sie interessant:

  • RFC1342 http://www.ietf.org/rfc/rfc1342.txt
    Codierung von Nicht ASCII-Zeichen in einer Mail
  • 956275 An Exchange 2007 sender's address is split into two separate addresses when an external recipient replies to the message
    QuoteDisplayNameBeforeRfc2047Encoding

ISO8859-1 ist natürlich nur eine mögliche Codierung. Es gibt weitere Codierungen, die für bestimmte Zeichensätze bessere Umsetzungen erlauben. So sind speziell im ostasiatischen Raum andere Codierungen im Einsatz. Allerdings hat diese Umcodierung auch das Problem, dass die Nachricht entsprechend größer wird.

Unter dem Begriff "Dingbat" versteht man Bilder, die per Unicode auch im Betreff verwendet werden können, z.B. Sterne, Flugzeuge etc.

 oder

Das Flugzeug ist z.B. wie folgt codiert

Subject: =?UTF-8?B?4pyIIEZyYW5rLCBnZXdpbm5lbiBTaWUgMiBUaWNrZXRzIGbDvHIg?=
=?UTF-8?B?ZWluZSBCdWRhcGVzdC1SZWlzZSE=?=

Schade dass man nicht gleich eigene "Zeichen" verwenden kann, dann würde ich Mails mit MSXFAQ-Logo senden.

Anlagen an eine Mail oder was steckt hinter UUENCODE, MIME, BINHEX

Nun ist es aber nicht nur der Kopf und die Nachricht selbst, die über die Leitung übertragen werden müssen, sondern schon sehr bald war auch der Versand von Anlagen erforderlich. Auch hier hat Sie das Team im John Postel seine Gedanken gemacht. Anlagen werden einfach mit in den Body der Mail eingebaut. Hierbei mussten dann gleich zwei Dinge berücksichtigt werden:

  • Trennung von Anlagen und Mitteilung
    Es musste ein Standard definiert werden, damit alle Systeme einfach zwischen der Mitteilung und den Anlagen unterscheiden konnten
  • Anlagen sind binär
    Auch hier ist wieder die 7-bit/8-bit Problematik zu beachten, wobei es diesmal nicht nur um einige zusätzliche Sonderzeichen geht.

Anfang wurde diese Codierung sehr einfach gemacht: Der Anwender musste die Anlage mit dem Verfahren "UUENCODE" umcodieren. Dabei ist dann einfach eine Text-Datei heraus gekommen, die der Anwender in die Nachricht eingefügt hat. Der Empfänger (Anfangs der Mensch!) hat diese "komischen Zeichen" erkannt, als Datei gespeichert und mit UUDECODE wieder zu einer Datei umgesetzt. Heute machen dies die Mailprogramme vollautomatisch.

Wenn Sie also in einer Mail folgenden Inhalt oder ähnlich finden, dann ist das UUENCODE drüber gelaufen:

begin 644 turnoff.com
M#A^X`!;-+SP`=!4SV[B#%LTO@_L`=`FZ0@+HK@#IG@"X$$HSV[FKZ\TO/;ZZ
M=1BX$$J[`0#-+[J'`NB.`+2&N1X`N@``S16X`%,SV\T5<P/I<`"!^TU0=`/I
M9P`]`0%S`^E?`%&X`%0SV\TO,\"!^TU0=0U0N`%4NP`!S2]8<@%`65!34;@!
M4S/;S16X#E,SV[D!`<T5N`]3NP$`B\O-%;@(4[L!`(O+S16X!U.[`0"Y`P#-
M%;KM`>@0`.D``+@`3,TANM`!Z`(`Z_.T"<TAPU-O<G)Y+"!K96EN($%032!I
M;G-T86QL:65R="$D4VEE(&V!<W-E;B!D96X@4$,@<V-H96EN8F%R('9O;B!(
M86YD(&%U<W-C:&%L=&5N(0T*05!-('=I<FMT(&YI8VAT(&]B=V]H;"!V;W)H
M86YD96XA)$1I97-E<R!0<F]G<F%M;2!D87)F('5N9"!K86YN('5N=&5R(%=I
M;F1O=W,@;FEC:'0@875S9V5F@6AR="!W97)D96XA)%=A<G1E(#(@4V5K=6YD
@96X@875F(&1A<R!&;'5S:&5N(&1E<R!#86-H92XN+B0N
`
end
sum -r/size 51913/632 section (from "begin" to "end")
sum -r/size 53013/437 entire input file

Das ganze ist übrigens eine kleine COM-Datei, die einen PC mit ATX-Netzteil unter DOS abschaltet. Wenn Sie diese Zeichen einfach in Notepad kopieren und mit der Endung ".UU" abspeichern dann können einige Packer wie WinZip dies sogar auspacken.

Der Nachteil von UUENCODE ist, dass sich die Mail aufbläht und damit nur eine 8-Bit Information in 7-bit eingepackt wird. Aber selbst in 256 Zeichen eines 8-bit Codes haben nicht alle Sonderzeichen aller Sprachen Platz. Das ist der Moment, an dem MIME das Feld betritt. Einige Zeit nach UUENCODE und uS-ASCII wurde mit MIME ein Weg beschrieben, alle Zeichensätze der Welt elektronisch übertragbar zu machen. Verschiedene Übersetzungstabellen helfen hierbei. Sie erkennen diese Abschnitte in einer Mail.

From: "TestUser" <test@example.com>
To: <frank.carius@example.com>

------_=_NextPart_001_01C575B6.4299BAD8
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

------_=_NextPart_001_01C575B6.4299BAD8
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


------_=_NextPart_001_01C575B6.4299BAD8--

Die eigentlichen Inhalte haben ich heraus gekürzt. Die einzelnen Informationen sind in Blöcke aufgeteilt, von denen jeder Block eigenständig codiert sein kann. Neben der Codierung (hier "us-ascii") wird auch "Content-type" angegeben. So kann ihr Outlook auch gleich ein passendes Icon  anzeigen und das dazu gehörige Programm starten.

Mittlerweile erhalten wir immer mehr Nachrichten, in denen auch die Mitteilungen in mehreren Formaten enthalten ist. So senden viele Personen, die eine HTML-Mail versenden auch eine Text-Variante mit, damit auch die Empfänger die Mail lesen können, die z.B. die Anzeige von HTML-Nachrichten verweigern oder nicht unterstützen. Das vergrößert natürlich auch die Datenmenge.

Eine kleine Besonderheit ist dabei der SMTP-Erweiterung "8bitmime". Über diese Erweiterung kann ein Mailserver der Gegenseite mitteilen, dass er auch 8-bit Informationen annehmen und verarbeiten kann. Der absendende Mailserver könnte dann die Nachricht neu codieren und dabei die komplette 8-Bit verwenden. So kann die zu übertragende Datenmenge reduziert werden. Leider gibt es immer noch Mailserver (Exchange 2000/2003 zähl auch dazu), die für einen Absender diese Funktion "8bitmime" anbieten aber bei einer Weiterleitung als Relay die Mail nicht umcodieren können.

Absender mit Umlauten

Bei der Fehlersuche nach Probleme ist mir eine kleine Besonderheit von Exchange 2000 SP3 aufgefallen. Ursache war eigentlich, dass die Mails eines Exchange Servers auf der Gegenseite angeblich nicht angekommen sind. Die Mails wurden aber sehr wohl in das Postfach zugestellt, aber sind dann beim Abholen mit dem SBS POP3-Connector nicht korrekt zugestellt worden. Dabei ist mir folgendes aufgefallen:

Gegeben ist ein Exchange Postfach mit dem Namen "Düsentrieb, Daniel". Wichtig ist hier nur der Umlaut im Display Namen. Dieser Benutzer sendet eine Mail ein eine andere Adresse. Beim Empfänger kommt dabei folgendes im Header an.

From: =?iso-8859-1?Q?D=FCsentrieb=2C_Daniel?= <Daniel.Duesentrieb@firma1.de>
To: <User@example.com>

Dieses Format ist absolut korrekt. Exchange codiert den Absender anhand der RFC2047 bzw. RFC1342 und da damit auch das Komma als Sonderzeichen nicht mehr existiert, ist nicht einmal die Einkapselung in Anführungszeichen erforderlich.

Angezeigt wird dann "Düsentrieb, Daniel". Das ist OK so aber bei dem Empfänger ist die Mail nicht zugestellt worden. Ich vermute, dass der POP3-Connector diese Formatierung nicht korrekt umgesetzt hat. Outlook Express hat ein ähnliches Problem derart, dass die Mailadresse in zwei Adressen aufgeteilt wird. Einmal "Düsentrieb"  und dann "Daniel daniel.duesentrieb@firma.de". Ganz als wäre das Komma ein Trenner statt Teil des Namens.

In dem Zuge habe ich aber mir das Feld "Einfache Anzeige" (AD-Feld displayNamePrintable) genauer angeschaut: In den Dokumentationen steht, dass diese Feld für "Downlevel Mailsystem" (Vielleicht Microsoft Mail ?) verwendet werden kann, die nicht mit umlauten zurecht kommen. Diese Feld ist normalerweise leer. Ich habe es zum Test mit "Duesentrieb, Daniel" gefüllt und erneut eine Testmail gesendet.

Was nun kam, hatte ich aber nicht erwartet, Ich erhielt eine Mail von "Dusentrieb, Daniel", d.h. es war weder diese einfache Anzeige noch der originale Displayname. Im Header stand aber diesmal drin.

From: =?us-ascii?Q?Dusentrieb=2C_Daniel?= <Daniel.Duesentrieb@firma1.de>
To: <User@example.com>

Anscheinend bewirkt das Füllen der "Einfachen Anzeige" nebenbei, dass Exchange 2000 SP3 auch die ausgehende Codierung von SMTP FROM-Adressen verändert. Ich konnte sogar einfach "TEST" in das Feld der einfachen Anzeige schreiben, und bekam dann immer noch eine Mail von "Dusentrieb, Daniel".

Fix für Exchange 2003

Von Microsoft gibt es dazu einen Artikel in der TechNet, der Exchange nicht mehr zur RFC2047 kompatibel macht und damit das Problem beseitigt

  • 886757 A sender's e-mail address appears to a recipient as two distinct addresses if the sender's display name contains a comma and extended characters in Exchange 2000 or in Exchange 2003
  • 956275 An Exchange 2007 sender's address is split into two separate addresses when an external recipient replies to the message

Ein Hotfix und ein Wert in der Registrierung (RFC2047Compliant) verändern das Verhalten von Exchange so, dass die Aufteilung in zwei Nachrichten nicht mehr auftreten sollte.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\InternetContent\
RFC2047Compliant:DWORD = 0

Dieser Key funktioniert nur, wenn Exchange 2000 SP2 oder neuer installiert ist. Wenn Sie Exchange 2000 Hotfixes installiert haben kann es sein, dass Sie auch hier dann einen weiteren Hotfix brauchen.

Fix für Exchange 2007

Auch Exchange 2007 hat diesen Fehler und erst durch Exchange 2007 SP1 Rollup7 gibt es eine Option, die diese verhalten anpasst.

  • 956275 An Exchange 2007 sender's address is split into two separate addresses when an external recipient replies to the message
  • 886757 A sender's e-mail address appears to a recipient as two distinct addresses if the sender's display name contains a comma and extended characters in Exchange 2000 or in Exchange 2003

Nach Installation des Exchange 2007 SP1 Rollup7 muss dann noch die Datei "Edgetransport.exe.config" erweitert werden:

<appSettings>
   <add key="QuoteDisplayNameBeforeRfc2047Encoding" value="true"/>
....
</appSettings>

Achtung: XML-Dateien sind "Case-Sensitive", d.h. Groß/Kleinschreibung muss beachtet werden.

Weitere Links