Exchange Online Disclaimer

In Deutschland und vielen anderen Ländern gibt es die Rechtslage, dass eine Mail bestimmte Pflichtangaben wie z.B. HRA/HRB-Nummer, Name des Geschäftsführer etc. enthalten sein müssen. Damit muss sich jeder Administrator mit dem Thema "Legal Disclaimer" beschäftigen, d.h. wie addiere ich die Pflichtangaben.

Übersicht

Als Administrator können Sie allerdings keine eigene Software auf dem Postfachserver von Exchange Online installieren. Bisher bekannte Disclaimer-Addons als 3rd-Party Produkt müssen sich andere Wege suchen oder ersetzt werden. Oft sind diese 3rd Party-Tools aber viel leistungsfähiger. In Exchange Online gibt es aber einen anderen Weg, den es OnPremises nicht gibt:

Die Optionen 1,2 und 4 dürften sie schon von meinen anderen Seiten (Siehe auch Disclaimer/Signatur) kennen, so dass ich sie hier nur kurz aufzählen. Neu ist aber die Option 3, welche es derart OnPremises nicht mit Bordmitteln gibt.

Position Beschreibung Zwang Intern SMIME
1 a/b/c

Client

Outlook unterstützt die Konfiguration von Signaturen auf dem Client. Diese Einstellungen sin natürlich komplett dezentral zu verwalten. Es gibt aber 3rd Party Tools, die solche Einstellungen beim Benutzer vornehmen und sich auch per Software-Verteilung.

 

Nein

Ja

Ja

Transport Regel

Die zweite Option ist eine klassische Exchange Transport-Regel. Hinsichtlich Disclaimer entspricht die Funktion im wesentlichen der OnPremises-Version.

Ja

Ja

Bedingt

Umleitung

Weniger bekannt ist die Option, in Exchange Online Mails an einen bestimmten Connector umrouten und durch ein externes System verarbeiten lassen kann. So funktionieren viele "Cloud Disclaimer", die sich nicht mehr als Transport Agent installieren können.

Ja

Ja

Gateway

Upstream

Auf dem Weg sind Internet können Sie Exchange Online anweisen, alle Mails nicht selbst per DNS-Auflösung (MX-Record) zu versenden sondern über einen Smarthost an ein vorgeschaltetes System zu übermitteln. Dieses kann dann auch noch einmal die Mail vor dem Versand verändern.

Ja

Nein

Gateway

Hybrid Centralized Mailtransport

Wenn Sie noch Exchange Hybrid nutzen, können Sie natürlich alle Mails aus der Cloud über die OnPremises Umgebung routen und dort wie bisher ihre 3rd-Party-Disclaimer Software einsetzen. Eventuell kann die Software sogar die gesendete Mail im Exchange Online Postfach nachträglich mit dem Disclaimer versehen.

 

 

 

Je nach dem, an welcher Stelle die Veränderung erfolgt, kann eine SMIME-Signatur berücksichtigt werden oder das System auf Daten aus dem AzureAD/Active Directory zugreifen.

Option3: Rerouting

Die Option 3, die es so nicht OnPremises gibt, gehe ich noch einmal genauer ein. Wenn Sie über das Exchange Control Panel eine Transportregel anlegen und die erweiterten Optionen auswählen, dann können Sie ein Rerouting zu einem Connector einstellen.

Das bedeutet, dass Sie so bestimmte oder auch alle Mails über diesen vorab anzulegenden Connector an ein eigenes System senden können.

 Es bietet sich natürlich an, dieses System z.B. in Azure zu hosten anstatt zuhause selbst zu betreiben. Das System kann die Mails dann nach der Verarbeitung entweder selbst ins Internet senden oder einfach wieder an Exchange Online zurückgeben. Damit dabei aber keine Schleife entsteht, sollte diese System die bereits verarbeitete Mail irgendwie kennzeichnen, so dass sie diese Mails dann von der Umleitung ausnehmen können.

Das könnte z.B. ein besonderes Feld im Header sein, welche bei einer Weiterleitung oder Antwort des Empfängers natürlich nicht übernommen werden sollte.

Natürlich brauchen Sie neben dem System, welches die Mails verarbeitet auch noch einen "Inbound Connector (vom Mailserver der Org zu Office365", über welchen das System die Mail wieder zum Tenant sicher einliefern kann, auch wenn die Absenderadresse zu den eigenen Domänen gehört

Einschätzung

Auf den ersten Blick erscheint die Option 3 bestechend einfach und flexibel. Sie können damit Exchange Online als Spamfilter und Versender weiter verwenden und dennoch in die Mail auf dem Transport eingreifen. Aber nicht alles ist aus den ersten Blick erkennbar und daher würde ich auch die Option 4 nicht ganz außer acht lassen. Es gibt nämlich signifikante Einschränkungen:

  • Verschlüsselter Spam
    Wenn sie SMIME/PGP aktiv nutzen, dann könnten gezielte Angriffe von extern per Phishing etc. erfolgen. Da die Mails aber verschlüsselt sind, kann Exchange Online Protection dort nicht reinschauen. EOP kann also maximal über die IP-Adresse und vielleicht den vorgeblichen Absender Spam/Phishing-Mails erkennen. Das reicht heute nicht mehr aus. Daher ist es in Verbindung mit der Funktion "SMIME/PGP" bei so einer Anbindung ratsam, Spamschutz und Verschlüsselung aus einer Hand zu kaufen und vor EOP zu stellen.
    Daher bieten meine Kollegen von NoSpamProxy die Funktionen "Encryption" und "Disclaimer" gar nicht ohne das Modul "Protection" an, um solche Lücken aus Unkenntnis bei Kunden gar nicht erst entstehen zu lassen
  • Hosted Disclaimer
    Wenn sie heute schon Exchange Online aus der Cloud nutzen, dann dürfte ein eigener Server für Disclaimer sogar stören. Vielleicht nutzen Sie dann besser die Disclaimer-Funktion ebenfalls als Hosted Service eines Anbieters. Dann sind sie aber schon wieder ganz nah an der Option 4, denn dann kann der "Disclaimer-Service" die Mails auch gleich selbst versenden.
  • DKIM-Signaturen
    Exchange Online kann ausgehende Mails per DKIM signieren. Wenn die Mail schon per DKIM signiert beim Disclaimer-Service ankommt und dieser die Mail verändert, dann wird die DKIM Signatur ungültig. Sie sollte daher entfernt und neu generiert werden

Damit relativiert sich die Begeisterung für Option 3 schon wieder und sie sollten möglichst unterschiedliche Testfälle mit dem ausgewählten Produkt durchspielen, ehe Sie damit produktiv gehen.

Weitere Links