Disclaimer Probleme

Es scheint so einfach zu sein, eine Mail vor dem Versand noch mal schnell zu ändern. Aber der Teufel steckt wie so oft im Detail. 

Disclaimer und Bilder

Immer mehr Firmen möchten nicht nur einfache TEXT-Mails senden, sondern senden formatierte HTML-Nachrichten. Da bietet es sich natürlich an, gleich auch Bilder in den Trailer mit anzuhängen, zumindest wenn es sich um HTML-Nachrichten handelt. Was aber auf den ersten Blick so einfach aussieht, hat durchaus eine Fallen. Hier die drei möglichen Varianten

Variante 1: Bild per Hyperlink

Die einfachste Variante ist die Einbindung als Hyperlink. Ein einfacher "IMG-Link" im Trailer verweist auf das Bild, welches Sie z.B. auf dem öffentlichen Webserver verfügbar gemacht haben. Das könnte im HTML-Disclaimer dann wie folgt aussehen:

<img border="0" src="http://www.example.com/images/mailtraier.gif">

Die Einschränkungen dabei sind

  • Mitarbeiter kann nicht selbst bestimmen
    Die wenigsten Firmen erlauben ihren Mitarbeitern, Dateien auf einem Webserver bereit zu stellen. Damit kann ein Mitarbeiter natürlich nicht eigene Bilder hinterlegen. Die Verwaltung ist entsprechend aufwändiger.
  • Empfänger braucht Internetzugriff
    Damit der Empfänger die Mail "komplett" lesen kann, muss sein Programm die Bilder von der externen Quelle per HTTP herunterladen können. Das funktioniert nicht, wenn die Anwender keine Verbindung zum Internet haben (Offline, PDA etc.) oder es funktioniert unbequem, wenn der Anwender sich erst an einem Proxy anmelden muss. Man kann nicht davon ausgehen, dass ein Programm ohne Rückfrage aus dem Internet Dateien herunter laden kann.
  • Empfängersoftware muss Bild anzeigen
    Das Einbinden von externen Bildern in Mails wurde früher auch oft genutzt, um über "Webbugs" ein Feedback über die Werbung zu erhalten. Immer wen Sie so eine Mail lesen, fordert ihr PC ja die Daten vom Webserver des Absenders an und dies ich "nachvollziehbar". Als Versender bekomme ich so sogar viel bessere Daten als von einer Quittung. Daher zeigt Outlook 2003 z.B.: diese Bilder gar nicht mehr automatisch an.

Also ist diese Variante eine universelle und kompatible aber keine sichere Variante.

Variante 2: Einbettung in HTML

Wie auf http://en.wikipedia.org/wiki/Data_URL beschrieben ist, kann man auch direkt in die HTML-Datei binäre Daten einbinden. Auch auf diesem Weg kann man z.B.: Bilder in einen Disclaimer einfügen. Hier ein Beispiel:

<img src="data:image/png;base64,
iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKCAYAAACNMs+9AAAABGdBTUEAALGP
C/xhBQAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB9YGARc5KB0XV+IA
AAAddEVYdENvbW1lbnQAQ3JlYXRlZCB3aXRoIFRoZSBHSU1Q72QlbgAAAF1J
REFUGNO9zL0NglAAxPEfdLTSkybe4BZM4DIO4C7OwQg2JoQ9LE1exdlYvBBeZ7jq
ch9//q1uH4TLzw4d6+ErXMMcXuHWxId3KOETnnXXV6MJpcq2MLaI97CER3N0
vr4MkhoXe0rZigAAAABJRU5ErkJggg==" alt="Red dot" />

Allerdings ignoriert der Internet Explorer 7 diese Daten und stellt nur ein leeres Kästchen mit einem roten X dar. Da auch Outlook und andere Programme bei der Anzeige von HTML-Mails einfach nur diese Controls verwenden, kann ich als Versender daher nicht sicher sein, dass das Bild auch dargestellt wird. Also ist auch dies keine zufriedenstellende Lösung.

Variante 3: Anlage mit Link

Aber Outlook zeigt ja, dass Bilder in einer Mail funktionieren können und so habe ich einfach eine Mail mit Bild aus Outlook versenden und mir im Quelltext angeschaut, wie dies erreicht wird. Im wesentlichen sieht es so aus, dass in der HTML-Mail ein Tag drin steht und das Bild über eine "ClassID" eingebunden wird. Das Bild selbst ist dann eine Anlage an die Mail, in der auch die ClassID hinterlegt wird. Hier ein Auszug der Mail:

...
<IMG src= "cid:001090815@01022007-34BF">
...

------=_NextPart_001_011E_01C7461B.2A5C6CB0
Content-Type: image/jpeg;
name="adtree.jpg"
Content-Transfer-Encoding: base64
Content-ID: <001090815@01022007-34BF>

/9j/4AAQSkZJRgABAQEBLAEsAAD/2wBDAAUDBAQEAwUEBAQFBQUGBwwIBwcHBw8LCwkMEQ8SEhEP
ERETFhwXExQaFRERGCEYGh0dHx8fExciJC....
.....

Dieses Verfahren scheint also zumindest in einer Microsoft Umgebung sauber zu funktionieren. Erfahrungen über andere Mailempfänger und deren Anzeige solcher Mails liegen mir leider nicht vor.

In Verbindung mit einer Software, die automatisch Disclaimer anhängt, muss man nun nur sicherstellen, dass diese Software auch Anlagen anfügen kann und dabei auch eine feste Content-ID einfügt, auf die man dann im HTML-Disclaimer verweisen kann.

Disclaimer Kaskade

Wenn ich mir nun vorstelle, wie viele Disclaimer meine Mailbox zukünftig  füllen und wie viele Antworten auf Antworten am ende überwiegend aus Disclaimern bestehen,  dann werde ich wohl noch einen anderen Sink nachschieben müssen; einen "Disclaimerkiller". Über die gleiche Methode kann ich ja jede eingehende Mail "untersuchen" und wenn z.B.: in den letzen Zeilen eine "Trennlinie" zu finden ist, könnte man den gleich abschneiden. Die Blackberry und ActiveSync Anwender werden es sicher danken. Und die Kaskadierung von Disclaimern in Antworten auf Antworten könnten so auch reduziert werden. Früher haben die Anwender bei Disclaimern diese durch ein Zeile mit "--"  eingeleitet. Einige Mailprogramme haben diese dann sogar automatisch beim Antworten entfernt.

Disclaimer und Formate (TNEF)

Wer heute eine Mail in das Internet sendet, hat in der Regel die Wahl, ob er diese als TEXT und/oder HTML-versendet. Exchange kennt aber noch die Option, die Mails als "RTF" zu versenden. Das kann der Benutzer selbst beim Versand an der Mailadresse festmachen:

User RTF

Allerdings kann dies auch der Administrator auf dem Exchange Server je Zielsdomäne konfigurieren:

TNEF  TNEF

In allen Fällen ist es für einen SMTP-Sink allerdings schwer, diese Mail mit einem Disclaimer zu versehen, da TNEF bei einer TEXT als auch einer HTML-Mail als "WINMAIL.DAT"-Anlage daher kommt, in der die RTF-formatierte Mail zu finden ist. Wenn Sie daher den Bedarf haben, auch nach extern TNEF zu senden, dann sollten Sie die Produkte entsprechend auf die Tauglichkeit prüfen. Ich befürchte aber, dass keines der Produkte damit wirklich sauber umgehen kann.

Disclaimer mit Exchange 5.5 und anderen Mailsystemen

Exchange 5.5 ist zwar schon lange nicht mehr "supported", aber ich weiß natürlich, dass noch sehr viele Firmen weiterhin Exchange 5.5 im Betrieb haben. Auch für diese Umgebungen gibt es natürlich Lösungen. Die meisten Disclaimer Tools können nämlich auch mit Exchange 5.5 oder sogar ohne Exchange eingesetzt werden. Allerdings müssen Sie wissen, dass diese Produkte sich alle als "SMTP-Sink" auf dem Windows 2000/2003 SMTP-Server einbinden. Diese Funktion ist aber nicht an Exchange 2000/2003 gebunden, so dass man jede ausgehende Mail einfach durch einen Windows 2000/2003 SMTP-Server leiten muss, um einen Disclaimer anzubinden.

Allerdings bieten viele Produkte Zusatzfunktionen, die auf ein vorhandenes und gepflegtes Active Directory aufbauen, um z.B. den Absender als intern zu identifizieren und anhand von Regeln den passenden Disclaimer anzuwenden. Einige Produkte funktionieren aber auch komplett ohne Active Directory.

Wenn Sie daher einen Exchange 5.5 Server im Einsatz haben, dann können Sie die Konfiguration so abändern, dass der Exchange Server die Daten über einen Internet Mail Connector an einen Windows 2000/2003 SMTP-Server leitet, der dann den Disclaimer anfügt und in das Internet versendet. Beim Betrieb eines einzelnen Servers könnten Sie sogar überlegen, den Windows SMTP-Server "auf" dem Exchange 5.5 Server mit zu betreiben (nur wenn Exchange 5.5 auf Windows 2000 installiert ist) und durch geschickte Konfiguration der TCPIP-Ports und Weiterleitungen diese Funktion erreichen. Eine Installation auf einem Exchange 2000/2003 Server ist meist nicht zwingend erforderlich. Sogar die Funktionen des Active Directory können Sie nutzen, wenn Sie z.B. die Exchange 5.5 mit dem Active Directory Connector replizieren.

Die Funktion des Disclaimers mit einem Windows SMTP Server lässt sich sogar nutzen, um andere Mailsysteme um eine leistungsfähige Disclaimerfunktion zu bereichern.