Für die Mailrelay-Anbindung an Exchange Online und für die Attributpflege wird bereits ein Exchange Server auf Basis von Exchange 2016 betrieben, so dass das Betriebsteam bereits Erfahrung mit dem Umgang von Exchange gesammelt hat

Es soll zuerst eine Ist-Analyse der postfix-Konfiguration erfolgen. Hierfür werden die Konfigurationsdateien analysiert und die Maillogs über ein PowerShell-Skript über Wochen ausgewertet. Als Ergebnis wird eine Excel-Tabelle mit den IP-Adressen des versendenden Systems, Absende-E-Mail-Adresse, Empfänger-E-Mail-Adresse etc. generiert. Diese wird dann entsprechend aufbereitet um die Geschäftsfälle zu identifizieren.

Durch die sehr M365-lastige Lizenzierung des Kunden, sind bereits höherwertige E5-Pläne über den Reseller mit Nutzungsrechten für Exchange Server vorhanden. Die Entscheidung statt des postfix-Servers eine Exchange-basierte Infrastruktur zu verwenden, fiel wegen der bereits vorhandenen Lizenzen, bestehendem Know-How im Betrieb sowie der Flexibilität von Microsoft Exchange.

Da kritische Kundenkommunikation von einer unbekannten Menge von Systemen über den postfix-Server läuft, soll die Umgebung hochverfügbar ausgelegt werden. Daher wird eine Exchange 2019 Datenbankverfügbarkeitsgruppe vorgesehen und ein Loadbalancer um den aktiven Traffic auf die aktiven Knoten last zu verteilen.

Nach der ersten Analyse der postfix-Logs konnten die Nachrichtenmengen und die vorzuhaltenden Speichergrößen ermittelt werden und das Sizing der Exchange Server 2019-Umgebung vorgenommen werden.

Eine rein Exchange Online basierter Mailflow war nach der Sichtung der ersten angebundenen Systemen ausgeschlossen, da teilweise nur unverschlüsselte und unauthentifizierte SMTP-, IMAP und POP3-Kommunikation auf Senderseite möglich war. Eine kurzfristige Anpassung der Schnittstellen auf Seiten der Anwendung war erkennbar nicht möglich.

Um dennoch einen hohen Sicherheitsstandard bieten zu können wurden Empfangskonnektoren mit Abstufungen vorgesehen (transportverschlüsselt, StartTLS, unverschlüsselt in Kombination mit Authentifizierung oder ohne) und generell einem IP-Whitelisting um die Betreiber der sendenden Systemen zur Interaktion mit dem Mail-Betrieb steam zu „zwingen“. Zur Ermittlung des passenden Konnektors wurde ein Entscheidungsflussdiagramm erstellt.

Die sendenden Systeme werden Schritt-für-Schritt auf die neue Umgebung umgezogen. Jedes System muss über einen Steckbrief verfügen, in dem die Kerninformationen (Sende-IP-Adresse, Bezeichnung des genutzten Empfangskonnektors, Geschäftsfall, etc.) dokumentiert sind. Mangels Dokumentation und teilweise Kenntnis über die sendenden Systeme wurden über den Herstellersupport und/oder intensive Tests die möglichst sichersten Anbindungsmöglichkeiten an die Exchange-Umgebung ermittelt. Der Kunde verfügt über ein Change Advisory Board, daher musste jede Änderung entsprechend aufbereitet werden und entsprechend durchgeführte Testszenarien dokumentiert werden.

Für die Exchange-Infrastruktur wird eine vollständige Dokumentation erstellt, inklusive der Installationsparameter und alle Betriebsfälle werden in einzelnen Schritt-für-Schritt-Handbüchern mit entsprechenden Screenshots dokumentiert. Die Betriebshandbücher ermöglichen es, dass auch fachfremde Administratoren Arbeiten durchführen können.

Für die Exchange-Server-Umgebung wurden CheckMK-Sensoren entwickelt, welche die internen Healthcheck-Ergebnisse der Exchange-Umgebung auswerten sowie proaktive Redundanz- und Replikations-Testergebnisse zurückgeben. Auch die in der Exchange-Konfiguration genutzten Zertifikate werden über CheckMK-Sensoren auf Ablaufdatum hin geprüft und entsprechende Warnungen je nach Laufzeit zurückgegeben.

Eine besondere Herausforderung war ein spezieller Geschäftsfall bei dem Kunden. E-Mails werden via BCC-Feld als eine Art Archivierung von bestimmten Systemen an eine zusammengesetzte nicht real existierende E-Mail-Adresse gesendet. Das Abfangen der E-Mails an sich war mittels Pattern über Exchange Transportregeln kein Problem, das Setzen des bei postfix konfigurierbaren „X-Original-To“-Feld unter Exchange allerdings schon. Hierfür wurden diverse Lösungen auf dem Markt, welche als Transportagent agieren evaluiert und eine entsprechende Lösung wurde mit Janusnet Janusgate gefunden.

Der Betrieb der Umgebung wurde durch das Betriebsteam immer mehr übernommen, ebenso das eigenständige Schreiben von Betriebsfällen. Sodass die Unterstützungleistungen unsererseits nur noch bei speziellen Fällen notwendig wird.

Herausforderungen:

• Hoher Aufwand durch Dokumentationspflichten
• Detaillierte Aufbereitung der Changes für das Change Advisory Board
• Marktsichtung und Implementierung des speziellen BCC-Geschäftsfalls mit Transportagenten von Janusnet Janusgate
• Analyseaufwand bei der Anbindung der sendenden System um hier direkt „sicher“ zu starten, statt weiterhin unverschlüsselt und ohne Authentifizierung zu arbeiten