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.

Stelle Wer Beispiel

Outlook Mailformat

Hiermit kann der Benutzer beim Erstellen der Mail das Format auswählen. Damit wird in Outlook gesteuert, welche Funktionalität der Benutzer beim Erstellen der Mail hat.

Benutzer

Beispiel: Outlook 2007 Formatoptionen:
Outlook Formatoptionen

GPO Outlook Mailformat

Ein Administrator kann über Gruppenrichtlinien steuern, welche Formate der Benutzer überhaupt zur Auswahl hat bzw. nutzen muss.

Administrator

Beispiel: Office 2003 ADM-Vorlage:

Outlook Empfängerformat:

Der Benutzer kann pro Empfänger eine Information an Exchange mitgeben, wie Exchange die Mail versenden soll, sofern der Administrator dies nicht übersteuert. Per Default nutzt Exchange "HTML", es sei den der Benutzer fordert TEXT oder RTF an.

Benutzer

Beispiel: Outlook 2007 Empfängereigenschaften

Exchange Kontakt

Die Firma kann als "Dienstleistung" auch im Active Directory entsprechende Kontakte anlegen. Hier kann der Administrator steuern, ob RTF immer oder nie genutzt wird.

Administrator

Beispiel Exchange 207 Kontakteinstellungen:

Exchange Zieldomäne

An zentraler Stelle kann der Administrator pro Domäne steuern, wie Mails dorthin zu formatieren sind.

Administrator

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.

Zielempfänger Globale Einstellung Empfängereinstellung Mailformat Ergebnis

Internet

Immer RTF

Egal

Egal

Mail wird als RTF versendet. Nur sinnvoll, wenn Partnerorganisation RTF versteht

Internet

Never use

Egal

Egal

Mail wird nie als RTF versendet. Abhängig von den Einstellungen des users geht die Mail als TXT oder HTML (natürlich auch mit einer Textversion) raus

Internet

User Setting

Text

Egal

Mail wird als TXT versendet. Der Benutzer hat dies absichtlich eingestellt, da der Empfänger vermutlich weder RTF noch HTML versteht. So kann der Anwender selbst ohne Mitwirkung des Administrators Einfluss nehmen

Internet

User Setting

RTF

Egal

Mail wird als RTF versendet. Der Benutzer hat dies absichtlich eingestellt, da der Empfänger mit RTF umgehen kann und er so die erweiterten Formatfunktionen, Termineinladungen, Abstimmungsschaltflächen etc. nutzen kann, ohne dass zentral die komplette Domain definiert werden muss.

Internet

User Setting

Outlook Default

HTML

Mail wird als HTML versendet

Internet

User Setting

Outlook Default

Text

Mail wird als TEXT versendet

Internet

User Setting

Outlook Default

RTF

Mail wird vom Exchange Server nach HTML konvertiert

Intern

nicht relevant

Text

Egal

Mail wird als TXT zugestellt.

Intern

nicht relevant

RTF

Egal

Mail wird als RTF zugestellt

Intern

nicht relevant

Outlook Default

HTML

Mail wird als HTML zugestellt

Intern

nicht relevant

Outlook Default

Text

Mail wird als TEXT zugestellt

Intern

nicht relevant

Outlook Default

RTF

Mail wird als RTF zugestellt

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