MICROLINC - Probleme suchen Lösung
Zurück   Home

Exchange Server - BCC Empfänger nicht Teil des Headers

  -  06.04.2022 - 15:13
Menü

Home
Microsoft Small Business Server 2011 Standard
Hardware
Windows
MS Office
Projekte
Support
Download
Peripherie
Sonstiges (Off-Topic)
Telefonie
Windows 8
Windows Mobile
Security-Software
DATEV
Virtualisierung Oracle virtualbox
nginx
Kryptographie
hMailServer
Android
Novell
Exchange

Allocatus - Fehler Interner Serverfehler

Allocatus - "Die Eigenschaft "calendar:End" ist für diesen Objekttyp nicht gültig

Outlook 2013 Login Prompt nach Update

MAPI over HTTP - Diagnose

Exchange - Ermittlung aller Schemaversionen von allen Domaincontrollern

Exchange 2013 - Healthmailboxen neu erstellen

Exchange 2013 - Retentionpolicy auf Healthmailboxen anwenden

CodeTwo Exchange Rules Sent Items Update HTTP 501 Fehler

501 5.1.7 Invalid Address

Exchange SMTP Logbücher auswerten

OWA for iPad Hinweis für Outlook Web App entfernen

Informationen an Dritte reduzieren

ActiveSync Lesebestätigungen unterbinden

Getrennte Postfächer - Wie funktioniert das?

Anmeldeschleife OWA

Ersetzen von Zeichen über E-Mail-Adressrichtlinie

Troubleshooting Exchange Health Manager Sensoren

Public Folder Hierarchie Postfach entfernen

EOP als vorgelagertes Gateway für OnPremise

Office Message Encryption

Menge der Unterordner zählen (PowerShell)

Exchange Online - TLS Report für SMTP-Verbindungen

Inline Attachments in reguläre Anhänge umwandeln

Lync 2013 / Skype for Business - Exchange Online EWS Modern Auth

Freigegebene Kalender lassen sich nicht öffnen

Securepoint urlpath_regex Exchange 2019

Exchange Online / Outlook

Exchange Online - eDiscovery - Export von Mailboxordnern

RestrictedAdmin Mode Remote Destop Exchange Management Shell

Exchange Server - BCC Empfänger nicht Teil des Headers

Ermittlung inkorrekt angelegter Mailobjekte

Outlook - Nicht mehr vorhandenen Termin absagen

Server 2012 R2
AD Certificate Service (PKI) / Zertifizierungsstelle
System Center
Blackberry
Microsoft Flow
Virtualisierung Microsoft Hyper-V
Ubiquiti
3CX
OneDrive
PowerShell
Azure
HAProxy
Defender
Teams


 
Autor:Thomas Windscheif last edit:09.04.2022 22:25

Link zu diesem Beitrag:


[Druckansicht]

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


Über den Autor
Thomas Windscheif arbeitet bei excITe Consulting und ist langjähriger Berater im Bereich IT-Infrastruktur und Groupware. Sowohl Kleinunternehmen z. B. im Handwerk als auch der größere fertigende Mittelstand gehören zu seinem Projektumfeld. Im Wesentlichen gehören die Planung von Infrastruktur-Migrationen (Novell/Micro Focus, Microsoft), Cloud-Lösungen (Office365), Groupware-Umgebungen (z. B. Exchange) und deren Umsetzung zu seinen Aufgaben. Neues begeistert ihn aber ebenso und so unterstützt Thomas Windscheif auch bei themenfremden IT-Systemen, überall da wo er helfen kann.

Sein Ziel: Die Mehrwerte der heutigen IT-Lösungen für einfacheres und modernes Arbeiten beim Kunden einbringen.


Login


QuickTag:  

 
Sie haben ein ungelöstes Problem in Ihrer Exchange Server oder Microsoft-Infrastruktur?
Treten Sie gerne mit mir in Kontakt. Sowohl bei einfachen Exchange Installationen, als auch bei hochverfügbaren, lastverteilten Mehrstandort-DAG-Topologien mit Loadbalancern unterstütze ich Sie -auch kurzfristig- sehr gerne.

Nutzen Sie den Live Chat, xing, LinkedIn, das Kontaktformular oder den Mailkontakt

[News als RSS-Feed abonnieren]
News

vom 03.08.2022 - 15:19


- Das Ende der Standardauthentifizierung - Wie bereite ich mein Unternehmen vor? -

Am 01.Oktober.2022 wird Microsoft Standardauthentifizierung zur Anmeldung nicht mehr unterstützen. Immer noch (!) sehe ich viele Kunden die keinen Überblick über die Authentifizierungen an Ihrem Tenant haben. Oftmals sind es Smartphones, welche via ActiveSync und Standardauthentifizierung angebunden sind oder E-Mail-Clients via IMAP/POP3.

Wie man ermittelt welche Benutzer über welche App derzeit via Standardauthentifizierung (Legacy Authentication) zugreift und welche Maßnahmen zur Deaktivierung von Standardauthentifizierung vornehmen kann. Habe ich in dem folgenden Artikel zusammengefasst:

http://www.microlinc.de/index.php?lev1=36&lev2=2&lev3=&id=452


Weitere News:

Sharepoint-Kalender unter Team freigeben


vom 17.07.2022 17:41


Exchange Update HAFNIUM-Exploit


vom 09.03.2021 09:27


Windows Server 2019 - LDAP out of memory exception


vom 16.09.2019 17:48


3CX V16 Call Control API mit PowerShell Core


vom 25.04.2019 11:41


Exchange Online SMTP TLS Report


vom 15.02.2019 18:04


TLS-Test für SMTP mit PowerShell


vom 10.12.2018 11:47


3CX Secure SIP via DIRECT-STUN mit yealink T46S


vom 08.09.2018 15:35


Exchange 2016 CU10


vom 25.06.2018 15:21


Apple iCloud Addin stört Outlook Kalenderfunktionen


vom 18.10.2017 13:24


.NET 4.7 released - Bitte nicht auf Exchange Servern installieren


vom 13.06.2017 21:52


Troubleshooting Exchange Health Manager Sensoren


vom 16.05.2017 21:06


Exchange 2016 - ActiveSync-Lesebestätigungen können nun unterdrückt werden


vom 09.03.2017 18:28


Exchange - Informationen an Dritte einschränken


vom 20.02.2017 01:53


Einen guten Start in das neue Jahr


vom 31.12.2016 19:21


Smart App Banner für OWA entfernen


vom 09.09.2016 20:15


Neue Version des Berechtigungsvererbungsskript für Exchange released


vom 17.05.2016 19:34


LogParser für Exchange SMTP-Logs


vom 16.05.2016 00:48


Exchange Healthmailboxen neu anlegen


vom 25.03.2016 16:28


Retention Policy auf Healthmailboxen anwenden


vom 24.03.2016 20:52



[alle News auflisten]
Sitemap - Kontakt - Datenschutz & Disclaimer - Impressum