MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

Closed Mail System

Über das Internet kann jede Firma mit jeder anderen Firma Mails per SMTP austauschen. Der MX-Record weist den Weg und mittlerweile wird zumindest per OpportunisticTLS das Meiste auf dem Transport verschlüsselt und per SPF geprüft und DKIM signiert. Aber es gibt auch "private" Mailsysteme, die besondere Anforderungen hinsichtlich Verschlüsselung, Verifizierung und Routing stellen. Darum geht es hier

Wussten sie schon, ...

...dass es Deutschland ein "Behördennetzwerk" gibt und z.B. Städte und Gemeinden ihre Kommunikation gar nicht über das Internet austauschen, sondern ein eigenes "Intranet" (DOI, EKOM21) zwischen den Standorten aufgespannt haben? Ein ähnliches System nutzt das Gesundheitswegen in Deutschland (KIM Fachdienst), damit Kliniken, Krankenkassen und Praxen eine sichere Kommunikation untereinander aufbauen können. Juristen kennen das "Besondere Anwaltspostfach (beA) zur verbindlichen Kommunikation und auch das Schweizer Gesundheitssystem hat mit HIN Mail ein eigenes System. In Deutschland gab es z.B. mit De-Mail auch schon Versuche solche geschlossenen Systeme zu etablieren. Die deutsche Post hatte ePost während die Schweizer Verwaltungen wohl mit IncaMail der Schweizer Post unterwegs sind.

 

Viele Firmen sehen ihr eigenes internes System als "Grün" an. Aber es gibt etwas zwischen "intern" und "Internet". Ein Verbund sind z.B. befreundete Firmen, mit denen man explizite Absprachen hinsichtlich Sicherheit, Verschlüsselung aber auch Vertrauen und Mailrouting getroffen haben. Bis zu einer gewissen Menge könnten Sie das in Exchange Online über einen Partner Connector und Partner Inbound Connector konfigurieren. In Exchange On-Premises hilft hier sein SendConnector aber für den Empfang ist die Konfiguration nicht so einfach.

Die Einschränkungen

Die Nutzung solcher Lösung bedeutet für einen Anwender und Administrator mindestens eines der beiden Anforderungen:

  • Mehrere Postfächer
    Wenn die System überhaupt nicht verbunden sind, dann muss der Anwender mehrere Postfächer, teils mit separaten Programmen lesen und nutzen. Das kann ich als Sicherheitsfeature verkaufen, wenn ich so eine Mail aus der einen Welt nicht einfach in die Andere weiterleiten kann. Allerdings müssen alle Anwender sich dann mehrfach anmelden.
  • Eingriff ins Mailrouting
    Wird ein Postfach genutzt, dann haben Sie zwischen Internet und Postfach immer eine Logik, die diese besonderen Mails und Domains aus/umleitet oder separat verarbeitet. Damit wird das Gateway zur kritischen Komponenten, denn auch alle anderen Mails müssen dennoch diese Logik durchlaufen.

Die Problematik war On-Premises vielleicht noch einfacher zu lösen, da die Mailserver mit dem Postfach nahe am Anwender standen. Sobald nun aber Postfächer z.B. in Exchange Online oder einem anderen Provider gehostet werden und im "Multi-Tenant"-Betrieb laufen, bei dem viele Kunden die gleichen IP-Adressen und Zertifikate nutzen, dann wird die Lösung schon aufwändiger.

Aus/Einleitung

Normalerweise haben sie ihren Mailserver, welcher ausgehend seine Mails entweder selbst direkt oder über einen Smartphone, z.B. einen vorgeschalteten Relay-Server senden. Eingehend verweist der MX-Record meist auch auf einen Spamfilter in der Cloud oder On-Premises, ehe so eine Mail dann an den eigentlichen Mailserver weitergegeben wird.

Nun haben wir die Herausforderung, dass Mails an bestimmte SMTP-Domains nicht über das Internet, sondern einen eigenen Kanal übertragen und empfangen werden. Das gibt natürlich für alle Teilnehmer dieser "geschlossenen" Kommunikation.

 

Was auf den ersten Blick so einfach aussieht, müssen wir uns aber erst einmal genauer betrachten:

Wo und wie "ausleiten"

Der Absender kann die Mails an die befreundeten Gegenstellen z.B. direkt auf dem Mailserver, z.B.: per Exchange Send-Connector/Outbound Connector und SMTP-Adressraum direkte an die Gegenstellen senden.

Das geht schnell ist uns schnell ohne Zusatzprodukte konfiguriert. Allerdings muss der Administrator hier dann die Konfiguration ggfls. häufiger anpassen. Es kommen ja immer mal neue Partner-Domains hinzu oder fallen weg. Weiterhin kann er die Mehrwerte des vorgeschalteten Systems, z.B. Umschreiben von Absendern, ausgehender Spam/Virenschutz, Disclaimer, Archiv etc. dann nicht nutzen. Wer ein vorgeschaltetes System hat, wird daher eher dort in das Mailrouting eingreifen. Zumal einige Systeme hier flexible APIs bereitstellen.

Es gibt aber auch Lösungen wie z.B.  HIN Mail im Schweizer Gesundheitswesen, die direkt ein entsprechende Relay mitbringen, welches Sie dann zwischen Internet und ihren Mailserver stellen können.

Wo und wie "einleiten"

Natürlich müssen wir uns auch die Gegenrichtung anschauen. Sie müssen ja auch von ihren Partnern eingehende entsprechende Mails annehmen. Der erste Punkt ist auch hier Festlegung, wo in ihrem Mailsystem diese eigentlich externen Mails ankommen sollen. Sie können direkt auf ihrem Mailserver landen. Allerdings haben sie dann keinen AntiSpam/Antivirus-Schutz durch ein vorgelagertes System. Daher werden die meisten Teilnehmer des Verbundnetzwerks eingehende Mails beim vorgelagerten System annehmen.

Dort müssen sie dann z.B. abhängig von der Domain und der einliefernden IP-Adresse entscheiden, wie sie damit umgehen. Vielleicht wollen Sie anhand der IP-Adressen den Absendern einen Bonus verleihen, aber bitte nur für die zugelassenen Domains. Phishing und Angriffe kommen auch bei den besten Freunden vor.

Es geht bei all den Überlegungen daher nicht nur drum, wie sie eine Mail gesichert zum besonderen Zielsystem bekommen sondern auch von diesen Systemen die Mails annehmen und nicht z.B. über das gegen Abhören nicht gescherte Internet ungeschützt übertragen.

On-Premises: Exchange Connector Grenzen

Zuerst hat mich interessiert, wie sich Exchange On-Premises damit schlägt. Das bedeutet nicht, dass ich diesen Weg bevorzugen würde. Es geht erst einmal um die technische Machbarkeit.

Ausgehend 

Hier können wir über den "Send-Connector" und entsprechende Adressräume die Mails an bestimmte Domain über andere Wege senden. Damit stellt sich natürlich die Frage, ob man nun pro Domain einen eigenen Connector anlegt oder vielleicht ein Connector mit vielen Domains per MX-Record alle Partner gleichartig bedienen kann. Wenn Sie mit Smarthosts und statischen IP-Adressen oder gar MTLS-Authentifizierung arbeiten müssen, dann müssen Sie pro Gegenstelle einen eigenen Connector anlegen. Beim Routing per MX-Record können Sie bis zu 2243 Domaineinträge pro Connector hinterlegen. Diese Information können Sie z.B. auf der Schema-Erweiterung auslesen:

Auszug aus 
D:\Setup\ServerRoles\Common\Setup\Data\schema13.ldf 
D:\Setup\ServerRoles\Common\Setup\Data\PostWindows2003_schema16.ldf  

dn: CN=ms-Exch-Routing-List,<SchemaContainerDN>
changetype: ntdsSchemaAdd
adminDescription: ms-Exch-Routing-List
adminDisplayName: ms-Exch-Routing-List
attributeID: 1.2.840.113556.1.2.354
attributeSyntax: 2.5.5.4
isMemberOfPartialAttributeSet: FALSE
isSingleValued: FALSE
lDAPDisplayName: routingList
mapiId: 33062
name: ms-Exch-Routing-List
oMSyntax: 20
objectCategory: CN=Attribute-Schema,<SchemaContainerDN>
objectClass: attributeSchema
rangeLower: 1
rangeUpper: 2243
schemaIdGuid:: Z3TfqOrF0RG7ywCAx2ZwwA==
searchFlags: 0

Für die Anzahl der Connectoren kennen ich kein Limit, da jeder Connector ein eigener LDAP-Eintrag ist. Es dürfte aber schon Grenzen geben, da die Exchange Transport-Dienste bei ihrer Entscheidung die komplette Liste bewerten müssen. Aber es sind sicher mehrere hundert Einträge.

 

Wenn Sie keine eigenen Connectoren nutzen wollen und es eh einen "*"-Connector zum Internet gibt dann könnten Sie auch über DNS-Server ein Rerouting erreichen. Exchange fragt beim Versand über MX-Records normalerweise die im Betriebssystem hinterlegten DNS-Server. Sie können aber jederzeit auch über das "Set-TransportService"-Commandlet vom Betriebssystem unabhängige DNS-Server hinterlegen, die sie dann je Send-Connector über den Wert "UseExternalDNSServersEnabled" individuell aktivieren können. Sie können aber nicht pro Connector eigene DNS-Server vorgeben. Dieses Verfahren ist aber eher wenigen Exchange Administratoren, Supportern oder Dienstleistern bekannt.

Auf jeden Fall könnten Sie im DNS-Server für die besonderen Domains einfach eigene selektive Forwarder oder sogar DNS-Zonen für die Zustellung der Mails pflegen. Das funktioniert natürlich nur, wenn Sie Chef über den Server sind. In Exchange Online funktioniert der DNS-Server-Weg nicht. Eine Steuerung des ausgehenden Routings über Transportregel ist in Exchange Server nicht mit Bordmitteln vorgesehen. Es gibt allerdings auch hier 3rd-Party-Produkte, die solche Funktionen als Transport Agent nachrüsten.

Eingehend: Exchange "Receive Connectoren"

Eingehend kennt Exchange nur die "Receive Connectoren", die maximal anhand der Source-IP-Adresse oder Zieladresse:Port und vielleicht noch mit TLS-Zertifikaten abgesichert werden können. Das war es dann aber auch und damit eignen sich diese Connectoren nur sehr schwach für eine direkte Annahme von Mails von verbundenen anderen Unternehmen. Ich kann z:B. auch nicht wirklich nach der SMTP-Domain des Absenders prüfen oder mit Regeln arbeiten. Theoretisch wäre eine  SMTP-Transport-Erweiterung möglich, die z.B. Mails von besonders zu behandelnden SMTP-Domains nur über bestimmte Wege ins System rein lassen.

Exchange Online

In Exchange Online haben Sie keinen Zugriff auf die Server oder DNS-Einstellungen. Sie können dort aber neben den bekannten Send-Connectoren, die dort allerdings ausgehend dann "Outbound-Connector" vom Typ "Partner" heißen oder direkt als "Partner-Connector" beschrieben werden. Allerdings gibt es in Exchange Online auch die  Möglichkeit, einen Connector über eine Transportregel anzusteuern. Damit habe ich nun drei Optionen

  • Ein Partner-Connector pro Domain
  • Partner-Connector für mehrere Domains
  • Partner-Connector mit Transportregel

Auch hier stellen sich wieder einige Fragen, die ich experimentell (Feb 2025) ausprobiert habe.

Einstellung

 Wert

Wie viele Transportregeln kann ich anlegen?

Antwort: Laut Exchange Online Service Descriptions sind bis zu 300 Transportregel pro Tenant möglich. Das ist eine leider erreichbare Grenze, wenn sie sehr viele Domains alle individuell per Regel behandeln wollen.

300 Transportregeln/Tenant

Wie viele Bedingungen kann ich in Transportregeln hinterlegen?

Sie Summe aller RegEx-Ausdrücke aller Regeln zusammen ist auf 20kByte beschränkt. Wenn wir einmal von ca. 20 Zeichen pro Domain ausgehen, dann wäre hier bei 1000 Domain Schluss. Eine einzelne Regel darf aber maximal 8 Kilobyte enthalten

 20kB gesamt
8KB/Regel

Wie viele Partner-Connector kann ich anlegen?

Auch dies habe ich experimentell geprüft aber nach über 10.000 erfolgreich angelegten Send-Connectoren vom Typ Partner habe ich aufgehört weiter zu zählen.

Über 10.000 Connectoren

Wie viele Domains kann ich pro Partner Connector anlegen?

Ich konnte einen Partner Connector mit maximal "1268" RecipientDomains anlegen. Danach kam der Fehler, dass ein administratives Limit überschritten würde.

1268 Domain/Connector

Die Anzahl der Domain pro Partner Connector ist relativ hoch und dürfte für viele Fälle ausreichen. Leider sind die Möglichkeiten über eine Transportregel aufgrund der vorgegebenen Grenzen nur eingeschränkt nutzbar.

Eingehend können Sie über Partner-Connectoren vorgeben, für welche Domain der Connector zutrifft. Er überstimmt in dem Zuge auch andere Connectoren, z.B. über welche die normalen Mails ankommen. So können Sie recht einfach für jede Domain einen "InboundConnector" vom Typ Partner und einem Zertifikat oder IP-Adresse als weiteres Kriterium nutzen.

3rd-Party-Lösungen

Zumindest für die Exchange On-Premises-Umgebungen bin ich sehr sicher, dass Sie die meisten Server hintern einem AntiSpam-System stehen, der zugleich als Informationsdrehscheibe funktionieren dürfte. Hier würde ich dann vorschlagen, dass sie dieses 3rd-Party-System dazu verwenden, die Mails an bestimmte Domains gesondert zu behandeln, z.B. indem Sie an andere Hosts gesendet werden oder beim Versand über das Internet die strengeren Vorgaben wie TLKS-Zwang oder Schutz durch SMIME erzwungen werden. Die gleichen Regeln sollten dann natürlich auch für eingehende Mails gelten, d.h. Mails von den Domains der geschlossenen Umgebung sollten nie aus dem Internet angenommen werden, wenn die Absender sich an die gleiche Logik halten.

Es gibt diverse SMTP-Gateways und Spamfilter, die nicht nur zwischen einem internen System und dem Internet vermitteln, sondern auch die Routings zu internen Netzwerken quasi eingebaut habem

Beispiel DOI/NdB

Ein Beispiel ist das "Netz des Bundes", vormals DOI. Dies ist ein Zusammenschluss vieler Mailserver von Städten und Gemeinden, die über ein internes privates Netzwerk kommunizieren können. Wenn Sie einen eigenen Mailserver betreiben, dann können Sie für die entsprechenden SMTP-Domains ihre Mails direkt über die sichere Verbindung zur Gegenstelle übertragen und müssen diese nicht über den MX-Record und das unsichere Internet routen.

Die Aufgabe besteht dabei aus der Automatisierung dieses Routings. Es gibt im Grund zwei Möglichkeiten:

  • DNS-Service mit abweichendem MX-Record 
    Der Betreiber könnte einen eigenen DNS-Service bereitstellen, der nur von den Mitgliedern des geschlossenen Systems gefragt werden kann. Der DNS-Service würde dann für Partnerdomains die optimal interne IP-Adresse zurückliefern. Wenn eine Domain nicht intern sondern nur über das Internet erreichbar ist, könnte der gleiche DNS-Service als Forwarder dann den öffentlichen MX-Record der Domain ermitteln und zurückgeben.
    Für die Mitglieder wäre die Konfiguration sehr einfach. Sie können mit Set-TransportService eine Liste der DNS-Server über den Parameter "ExternalDNSServers" hinterlegen und mit Set-SendConnector und dem Parameter "-UseExternalDNSServersEnabled:$true" diese anstelle der DNS-Server im Betriebssystem nutzen.
  • Connectoren mit Adressräumen.
    Alternativ kann jeder Teilnehmer natürlich einen Send-Connector pro Domain mit dem Smarthost konfigurieren.

Beim Netz des Bundes wird eine Liste der Domains und dazugehörigen Smarthosts per HTTPS im Internet bereitgestellt. Die Adresse ist nur für NdB-Teilnehmer erreichbar und nicht aus dem Internet auflösbar

https://www.intranet.doi-de.net/Mailertables/mailertable.txt.asc?__blob=publicationFile.

Das Format entspricht der Datei "Mailertable", wie diese bei Sendmail in der Regel genutzt wird. Wer einen LINUX-basierten SMTP-Server hat, kann daher diese Datei intern z.B. per CURL und einem CRONJob regelmäßig herunterladen und in den verwendeten Mailserver einspielen.

Ich habe noch kein PowerShell-Script gebaut, welches diese Datei einliest und mittels For-Schleife einfach in Exchange OnPremises für jede Domain einen Connector anlegt. Meine DOI/NDB-Kunden nutzen ein Mailrelay wie NoSpamProxy und prüfen natürlich auch DOI/NDB-Mails auf Spam und Malware. NoSpamProxy kann nativ die Mailertable verarbeiten.

In Exchange Online macht so ein Skript keinen Sinn, denn Exchange Online hat gar kein Bein im DOI/NDB-Netzwerk und kann daher die in der mailertable hinterlegten IP-Adressen und Server gar nicht direkt erreichen. Auch hier könnten Sie aber alle Mails an DOI/NDB-Domain von ihrem Tenant z.B. zu einem lokalen Relay senden, welches dann die Mails weiter verteilt.

Einschätzung

Es ist kompliziert, würde der ein oder andere sagen. Die Leistungen von Exchange On-Premises mit Connectoren erlauben von Hause aus den Versand zu bestimmten Domains über eigene Send-Connectoren zu regeln. Beim Empfang ist Exchange Server allerdings sehr schwach, da er über die Receive Connectoren eigentlich alles annimmt und sie nur anhand der Source-IP eine Verbindung erlauben können aber nicht abhängig von der Absenderdomain. So sollten Sie einen Server nie ins Internet stellen und eine Filterung nach Quell-IP-Adresse ist zwar möglich aber kann nicht einfach mit der Absender-Domain verbunden werden.

Vielleicht hat der Artikel ein paar Zusammenhänge erklärt aber ich habe sicher nicht alle Sonderfälle abhandeln können. Wir können aber gerne über ihren Problemfall individuell sprechen.

Weitere Links