Exchange Server - BCC Empfänger nicht Teil des Headers - 06.04.2022
von Thomas Windscheif / Microlinc
Exchange 2019
Exchange 2016
Exchange 2013
Exchange 2010
BCC
Empfängerauflösung
Recipient Type P1 (Delivery Envelope)
Recipient Type P2 (Display Envelope)
Transport Agent
Janusnet Janusgate Exchange
Unter Exchange 2019 und den Vorgängerversionen wird der BCC-Empfänger nur im Recipient Type P1-Header sichtbar. Es handelt sich hierbei um die SMTP-Routing-Informationen welche nur vom Server ausgewertet werden. Der Recipient Type P2-Header (also der Teil welchen der Anwender sieht) dagegen enthält den BCC-Empfänger nicht. Dies hat zur Folge, dass der BCC-Empfänger an der E-Mail selber nicht erkennt, warum er diese erhalten hat. Für verarbeitende Systeme die die E-Mail erhalten auf Basis von Mitgliedschaften von Verteilergruppen oder durch eine Exchange Transportregel mit Regex-Pattern, ist folglich die BCC-Empfängeradresse nicht mehr auswertbar.
Im vorliegenden Fall hatte ein Kunde eine Art Archivierung über BCC für die E-Mail-basierte Kundenkommunikation etabliert.
Jede E-Mail an Kunden werden von den Quellsystemen mit einer E-Mail-Adresse auf Basis der Kundennummer als BCC-Empfänger versendet. Über eine Exchange Transportregel wurde ein Regex-Pattern für die Empfängeradresse als Bedingung für eine Weiterleitung an ein bestimmtes Zielpostfach definiert. Die dort empfangene E-Mail wird sodann von dem "Archivsystem" via IMAP bzw. POP3 abgerufen und dann über die BCC-Empfängeradresse, welche die Kundennummer enthält im Backend verarbeitet. ABER: Leider liefert Exchange im Nachrichtenheader die BCC-Empfangsadresse nicht mit. Dieser wird dagegen unter Postfix mittels des "X-Original-To"-Headers (Setting: enable_original_recipient in der Main.cf) standardmäßig gesetzt.
Da die Änderung des Verhaltens bei den versendenden Systemen keine Option war, musste eine Lösung gefunden werden.
Auf Transportregel-Basis kann man leider nicht mit Platzhaltern arbeiten. Daher muss die Lösung auf Transport-Agenten-Ebene gefunden werden:
- Entwicklung eines eigenen Transportagenten
- Signaturmanagement-Tool mit Header-Management
- Mailrouting-Policy-Tool auf Basis von Transportagenten
Entwicklung eines eigenen Transportagenten
Ich entwickle ja gerne neue Anwendungen und Skripte, daher war dieser Ansatz schon sehr reizvoll.
Allerdings habe ich mich dagegen entschieden, weil:
- Aufwendige Entwicklungsumgebung (Exchange Server mit entsprechendem CU, Visual Studio Installation)
- Durch CUs ändern sich im Laufe des Lebenszyklus von Exchange gerne die .NET-Runtime unter derer die Transport-Dienste von Exchange kompiliert werden. D. h. spätestens dann muss man den Agenten neu kompilieren. D. h. wieder Bereitstellung einer Entwicklungsumgebung und des Visual Studios und dann hoffen das der Weg dann noch so funktioniert wie seinerzeit.
- Fehlertoleranz ist nicht hoch im Transportagenten. Wenn der Transportagent nicht sauber entwickelt wurde und jede Art von Fehler abgefangen wird, besteht die Gefahr, dass der gesamte Transportstack unter Exchange abstürzt. Mit anderen Worten: Es werden weder Mails empfangen noch versendet.
- Wenig Dokumentation im Internet zur Entwicklung von Transportagenten inbesondere für diese spezielle Anforderung
Fazit: Lieber nicht. Es geht hier um einen kritischen Geschäftsprozesse welcher ein einwandfreies Zustellen und Verarbeiten von E-Mails garantiert sicherstellen muss.
Signaturmanagement-Tool mit Header-Management
Meine Hoffnung war, dass die zwei großen Anbieter im Signaturmanagement [CodeTwo und Exclaimer] (welche bekanntlich mit einem Transportagenten arbeiten) ggf. eine Lösung aus dem Standardregelwerk anbieten können. Leider habe ich von beiden eine technische Absage bekommen.
Mailrouting-Policy-Tool auf Basis von Transportagenten
Auf dem Markt gibt es nur sehr wenige Anbieter die unter dem Kontext der Compliance Filtersysteme auf Basis von Transportagenten unter Exchange anbieten. Ich habe drei Anbieter ausfindig gemacht (CI Solution, Egress und Janusnet).
Von zweien habe ich für mein gewünschtes Szenario keine Zusage für die Umsetzbarkeit bekommen.
Das Tool von CI Solution sah erst sehr viel versprechend aus, da man auch direkt eine Testversion herunterladen konnte (CI-Mail-Policy). Der Hersteller war auch sehr schnell in der Kommunikation. Leider konnte das Produkt die gewünschte Funktion nicht liefern.
Bei Egress steht auf der Homepage kein Support für Exchange 2019 explizit. Darüberhinaus hat der Support mir mitgeteilt, dass die Funktion so nicht vorgesehen ist. In der Zwischenzeit hatte ich aber schon sehr regen Austausch mit der Firma Janusnet.
Mein Usecase wurde direkt intern im Labor aufbereitet und in einem innerhalb von 3 Tagen organisierten Call (am Wochenende haben wir den Termin hierfür koordiniert bekommen; wohlgemerkt Zeitzone UK und Australien !!!) in einem Handson binnen 30 Minuten evaluiert. Ich war einfach nur verblüfft. Kein "Vetriebsgeschwafel", kein Zerreden wie sinnlos der Geschäftsfall von meinem Kunden ist sondern absolut pragmatischer Call. Habe ich - und ich mache das ja schon ein paar Jahre - selten erlebt.
Nach dem Call wurde mir eine 1 monatige Testlizenz sowie die bereits erarbeitete Regeldatei zur Verfügung gestellt.
Über den "Janusgate Rules Editor" kann man selber die Regeln in einem verständlichen Userinterface erweitern.
Die eigentliche Engine ist das "Janusgate Exchange". Laut Hersteller bereits seit Exchange 2007 bei verschiedenen Kunden weltweit im Einsatz und bisher auch CU-kompatibel. Meint, dass auch nach dem CU-Update der Agent weiter funktioniert ohne das man mit dem Hersteller troubleshooten muss. Für die Installation erhält man eine kundenspezfische Anleitung mit Screenshots. Antworten auf Fragen kamen innerhalb eines Werktages in der Presales-Phase. Bevor der Vertrag geschlossen wird, kann man und soll man den Agent auf Herz und Nieren prüfen. Kurzum: Selten eine Herausforderung qualitativ so zufriedenstellend gelöst bekommen wie durch die Lösung Janusnet Janusgate Exchange.
Die Produktseite bei Janusnet für Janusgate Exchange ist hier zu finden: https://www.janusnet.com/janusGATE/Exchange