RTFMAIL und WINMAIL.DAT

In der Zeit bevor Bilder und Farben vom Marketing für Mails entdeckt wurden, hatten E-Mails einen klaren einfachen Aufbau:

• Zustellinformationen
  Bestehend aus Absender, den Empfängern, dem Datum und dem Betreff und noch einigen weiteren Headerinformationen.
• Textbody
  Der Text der Mail ist eigentlich ein ASCII-Text (7-Bit) ganz ohne Formatierung oder Anlagen
• Anlagen
  Optional konnten noch Anlagen beigefügt werden, die aber im SMTP-Standard anfänglich nicht vorhanden waren und über besondere Zeichen im Textkörper mit übertragen wurden.

Technisch wurden aber auch die Anlagen im "Body" der Mail codiert mit übertragen. Wer heute noch ein "ganz altes Mailprogramm" nutzt, der kann auch die Anlagen noch als Text sehen. Früher musste der Anwender tatsächlich binäre Anlagen selbst UUENCODE, BINHEX oder MIME-codieren und dann als Mailtext versenden. Diese Arbeit nehmen heute alle Programme dem Anwender ab. Sie fügen einfach eine Anlage bei und die Codierung und Decodierung erfolgt im Hintergrund.

Aber dabei ist es nicht geblieben. Auch der Text der Mail selbst sollte nicht mehr nur "Text only" sein. Dabei war das Internet gar nicht mal Vorreiter. Schon Microsoft Mail hatte intern formatierte Mails erlaubt. Die Informationen wurden schon damals als binäre Anlage mit dem Namen "WINMAIL.DAT" an jede Mail angehängt. Programme, die mit dieser Anlage nichts anfangen konnten, haben einfach nur die Textversion angezeigt, welche ebenfalls vorhanden ist.

Die Probleme beginnen

Heute, im Zeichen des Internet und dem Siegeszug von HTML als Formatierungssprache für gestaltete Inhalte, ist eine reine Textmail natürlich nicht mehr ausreichend. Die meisten Benutzer verstehen aber nicht, welche Probleme Sie sich letztlich damit einhandelt. Denn um "kompatibel" zu sein, erstellen die meisten Mailprogramme eine Mail mit mehreren Varianten. Eine Mail mit HTML-formatierten Text enthält zusätzlich auch eine "Textversion". So können auch Empfänger ohne HTML-tauglichen Mailclient zumindest eine Basismail lesen

Auf der anderen Seite hat auch HTML ein prinzipielles Problem. In HTML können Sie nicht nur die Schriftarten variieren, sondern auch Bilder einfügen. Nur während ein Webbrowser wie selbstverständlich zuerst die HTML-Datei lädt und dann die darin verknüpften Bilder, Hintergründe, Flash-Animationen etc. nachholt, ist dies bei Mails zwar möglich, aber in fast jedem modernen Client aus zwei Gründen unterbunden:

• WebBugs
  Gerade in der Werbebranche ist es wichtig die Trefferrate zu können, d.h. wer wann welche Mails wie oft liest, weiterleitet etc. Eine kleine unsichtbare Grafik, die bei jedem Lesen von einem externen Webserver nachgeladen wird, ergibt eine schöne Verfolgungskontrolle. Auch ein Grund, warum Firmen Outlook 2003 als Mindestversion erzwingen
• Sicherheit gegen Skripte
  Per http können natürlich auch schlimmere Dinge als nur ein paar WebBugs nachgeladen werden, z.B. Javaskripte, Flashanwendungen etc. Und es ist nicht immer auszuschließen, dass der Schadcode wirklich in einer Sandbox verbleibt.

Ein dritter Aspekt ist die "Unverfälschbarkeit" einer Mail. Was würde mich hindern ihnen eine HTML-Mail zu senden, die den eigentlichen Inhalte als "Frame" oder "IFRAME" von meinem Webserver nachlädt? Ich könnte den gelieferten Inhalt einfach austauschen und sie könnten nie belegen, was sie beim ersten Mal gesehen haben.

Daher versuchen Programme bei HTML-Mails auch die verwendeten Bilder gleich als "Anlagen" mit zu senden, wofür es aber keinen einheitlichen Standard gibt. Es kann also sein, dass die Mail nicht bei jedem Empfänger gleich aussieht.

Wer daher "formattreu" Informationen übertragen will, sollte einfach eine Textmail versenden, die als Anlage die formatierte Information (z.B.: PDF, XPS, TIFF o.ä.) enthält. Nur so ist sichergestellt, dass die Inhalte wirklich identisch aussehen.

RTF, HTML Exchange und Outlook

Das Gespann aus Exchange und Outlook weicht etwas von üblichen Mailsystemen ab. Während bei vielen Mailsystemen schon der Client die Mail in das RFC-822 Format konvertiert und per SMTP an den Server sendet, überträgt Outlook die Mail per MAPI/RPC an Exchange und erst wenn die Mail das Exchange System in Richtung Internet verlässt, konvertiert Exchange die Mail in das "passende" Format.

Outlook „kennt“ drei Formate

• TEXT
  Die erfasste Mails orientiert sich am RFC822 Standard und erlaubt nur Text. Es wird keine Formatierung o.ä. angeboten. Anlagen werden auch als Anlagen gekennzeichnet.
• HTML (HyperText Markup Language)
  Sie können den Text ähnlich einer Webseite formatieren. Outlook bietet Funktionen für Schriftgröße und Farbe an. Auch Tabellen sind z.B. möglich. Anlagen werden aber weiter als "Anlagen" beigefügt
• RTF (Rich Text Format)
  Dies seit MSMAIL verfügbare Format kapselt alle Formatierungen in der besonderen Datei "WINMAIL.DAT". Der Editor entspricht quasi WordPad und speicher die Informationen als "RTF". Anlagen können auch mitten im Fließtext erscheinen. Auch Bilder können sehr einfach in den Text eingefügt werden. Eine Drag&Drop-Aktion bettet die Datei in der Mail mit ein. Allerdings verschwinden die eigentlichen Namen der Dokument und sind nicht mehr direkt sichtbar. Fremdsysteme können diese Mails allerdings meist nicht verstehen und zeigen nur eine Textversion an.

Entsprechend gibt es mehrere Stellen, an denen ein Benutzer und Administrator "steuernd" eingreifen kann.

Windows Registry Editor Version 5.00

[HKEY_CURRENT_User\Software\Microsoft\Office\15.0\Common\Contactcard]
"turnonlegacygaldialog"=dword:00000001

[HKEY_CURRENT_User\Software\Microsoft\Office\16.0\Common\Contactcard]
"turnonlegacygaldialog"=dword:00000001

Gewinner und Verlierer

Welche Einstellung nun effektiv zum Tragen kommt, ist auch recht einfach bestimmt:

Ich habe noch nicht alle Kombinationen in Verbindung mit allen Exchange Servern und Outlook Versionen geprüft. Die Tabelle kann daher fehlerhaft sein. Feedback ist willkommen.

Die Regeln sind überschaubar

• Default
  Exchange konvertiert also per SMTP ausgehende Mails per Default immer nach HTML, es sei denn der User möchte absichtlich ein anderes Format.
• Globale Einstellungen
  gewinnen nur, wenn die Mails auch nach extern gehen.
• Intern nur GPO
  Interne Mails werden allein durch den Client bestimmt. Allerdings kann hier der Administrator über Gruppenrichtlinien eingreifen.

RTF und Programmierer

Wer nun Kontakte bei Benutzern per Outlook oder im Active Directory anlegt, wird natürlich auch das Feld suchen, um die Einstellungen für den Zielempfänger zu konfigurieren. Im Active Directory ist es das Property MapiRecipient. Ein "TRUE" bewirkt, dass die Mails an diesen externen Empfänger per RTF zugestellt werden, sofern der Administrator global keine anderen Vorgaben gemacht hat.

Dieses Feld kann auch per LDAP recht einfach gesetzt werden.

Auch für Kontakte in Outlook kann bestimmt werden, ob der Empfänger die Mail im Standardformat, nur als TEXT oder immer als RTF bekommt. Allerdings ist die passende Einstellung nicht so einfach im Outlook Objektmodell sichtbar:

Bislang hatte ich noch nicht Anforderung, die Felder per Skript (z.B. per CDO) zu ändern, da eine zentrale Einstellung über die SMTP-Domänen auf dem Exchange Server sehr viel einfacher, flexibler und zuverlässiger ist.

Weitere Links

• TargetAddress
• ForeignConnector
• VBS:MakeContact
• RFC 822
  http://www.faqs.org/rfcs/rfc822.html
• http://en.wikipedia.org/wiki/Email