Hybrid Mail Routing

Exchange On-Prem und der Einstieg in die Cloud bedeutet für die meisten Firmen die Einrichtung einer Koexistenz beider Exchange Organisationen. Nur kleine Firmen können einen "Sprung" in die Cloud wagen und alle Postfächer zu einem Stichtag umstellen. Damit ist es erforderlich, die beiden Welten zu koppeln, damit interne Mails auch geschützt zwischen den beiden Welten ausgetauscht werden. Office 365 sieht dazu den "Hybrid Mode" vor.

Beachten Sie dazu auch Hybrid Centralized Mail Transport, HCW im Detail und Office 365: Mail Connector

Establishing Exchange Hybrid Mailflow
https://www.youtube.com/watch?v=1i_SO6nKe0o&t=605s
Sehr gute Beschreibung zum Mailrouting in einer Hybrid Umgebung

Grundverständnis

Technisch ist auch die Verbindung eine Office 365 Tenant mit einer Exchange On-Prem-Installation nichts anderes als eine Verbindung von zwei Exchange Organisationen, wie ich auf Interorg und Verzeichnisabgleich schon beschrieben habe.

  • Connectoren und Domaineinstellungen stellen das Mailrouting sicher
    Dabei wird bevorzugt der direkte Weg zum Zielsystem gesucht, um Relay-Systeme, Spamfilter u.a. zu umgehen und vielleicht abweichende Grenzwerte (größere Mails), andere OOF-Einstellungen, Weiterleitungen o.ä. zu erlauben.
  • Mailkontakte stellen das Adressbuch und die Weiterleitung sicher
    Damit das Adressbuch auf dem Client auf beiden Seiten eine vollständige Liste anzeigt, werden die On-Prem Postfächer in der Cloud als MailUser angelegt und Exchange Online Postfächer sind lokal dann eine "Remote Mailbox". Das hat auch den Vorteil, dass man "unbekannte" Empfänger schon beim Eintreffen erkennen und ablehnen kann.

Für die Kontakte sorgt der Office 365 ADSync-Prozess und das Mailrouting übernehmen normale Exchange Send-Connectoren und Receive Connectoren, die vom Hybrid Configuration Wizard entsprechende angelegt werden. Allerdings wird hier natürlich der Einsatz von TLS erfordert. Über diesen Weg authentifizieren sich die beiden Connectoren gegenseitig, d.h. der Send-Connector On-Prem spricht mit einem eigens eingerichteten Connector in Office 365 und umgekehrt. Offiziell kann die Exchange Online Umgebung nur mit einem Exchange Hubtransport oder einen Exchange Edge in ihrem Firmennetzwerk sich verbinden.

„Es dürfen keine weiteren SMTP-Hosts oder Dienste zwischen dem lokalen Exchange 2013-Clientzugriffsserver oder einem Exchange 2013/2010 SP3-Edge-Transport-Server und EOP vorhanden sein. Nachrichten hinzugefügte Informationen, die Hybridtransportfunktionen aktivieren, werden entfernt, wenn die Nachrichten einen Nicht-Exchange 2013-Server, einen Server vor Exchange 2010 SP3 oder einen SMTP-Host durchlaufen.“
Quelle: https://technet.Microsoft.com/de-de/library/jj659055(v=exchg.150).aspx

Ignite 2017: BRK2090 Insights into your Office 365 Mail Flow
https://channel9.msdn.com/Events/Ignite/Microsoft-Ignite-Orlando-2017/BRK2090
https://www.youtube.com/watch?v=PGJ9poMrYhc

Domains in Office 365

Wenn Sie einen Tenant in Office 365 einrichten, dann werden SMTP-Domänen angelegt. Eine dritte Domäne kommt aber bei den meisten Firmen sowieso hinzu, wenn Sie ihre Firmendomäne einrichten.

Die Domänen haben folgende Bewandtnis:

  • msxfaq.onmicrosoft.com
    Dies ist die Default Domäne, aus der z.B. der UPN und die Mailadresse für all die Benutzer abgeleitet wird, die ein Konto in der Cloud haben. Dieses Domäne ist auch in Exchange per Default vorhanden und ist zugleich die "OriginatorOrg".
  • msxfaq.mail.onmicrosoft.com
    Dies ist die SMTP-Routing-Domäne für Postfächer in der Cloud, zu denen es einen Kontakt in der On-Prem-Umgebung gibt. Sie wird in Exchange Online als auch On-Prem angelegt, wenn Exchange mit Hybrid konfiguriert wird. Sie wird zusätzlich auch unter "RemoteDomains" hinterlegt um die Formatierung der übertragenen Mails zu optimieren. Die andere Organisation ist ja nicht irgendjemand. Weiterhin wird diese Domäne auch in den Empfängerrichtlinien addiert.
  • msxfaq.net
    Dies ist eine zusätzliche Domäne, die durch das Hinzufügen in Office 365 auch in Exchange addiert wird. Das ist z.B. eine "richtige" SMTP-Domäne mit der die Postfächer erreichbar sind und auch Mails versenden.

Diese Liste ist nicht zwingend mit den Domänen in ihrer On-Premises-Exchange Organisation identisch. Sie können lokal durchaus On-Prem weitere SMTP-Domänen haben, die für Exchange Online aber nicht relevant sein müssen. Wichtig ist, dass alle Empfänger in beiden Welten vorhanden sind, so dass die Adressbücher "gleich" sind.

Mailrouting

Wie Sie von Exchange sicher schon kennen, wird das Mailrouting über Connectoren konfiguriert. On-Prem ist das ein Send-Connector, der Mails an die Cloud sendet. Damit die Cloud ihren On-Prem Server "erkennt" , wird dort ein "Inbound Connector" angelegt, der der Cloud dabei hilft ihren On-Prem Server zu erkennen. Das kann über die IP-Adresse oder einen Namen im Zertifikat sein.

In die Gegenrichtung legt der HCW einen "Outbound Connector" in der Cloud an, der Mails an ihre On-Prem-Benutzer sendet. Diese Mails landen dann auf einem Receive Connector ihrer On-Prem-Umgebung. Bis Exchange 2010 hat der HCW einen eigens dafür definierten Connector angelegt. Seit Exchange 2013 wird der Standard Connector genutzt. Das bringt durchaus Risiken, wie ich auf Hybrid Hintereingang beschrieben habe.

Ausgangssituation

Werfen wir einen Blick auf die Connectoren. Wenn Sie das erste Mal das Exchange Control Panel der Exchange Online Instanz starten, dann sehen Sie, dass es per Default erst mal keine Connectoren gibt.

Eine Exchange Online Instanz kann aber dennoch Mails in das Internet versenden oder empfangen, wenn sie den MX-Record entsprechend gesetzt haben. Bei einer On-Prem Installation ist das schon etwas anders. Hier gibt es bei Exchange 2016 schon fünf Receive-Connectoren

Der Hybrid Configuration Wizard erweitert diese Konfiguration nun um folgende weitere Connectoren.

On-Prem: Send-Connector "Outbound to Office 365"

Der Hybrid Assistent legt einen Send Connector mit dem Namen "Outbound to Office 365" an, über den ihre Exchange On-Prem Organisation alle Mails an die Domäne "<tenant>.mail.onmicrosoft.com" per MX-Record zur Cloud sendet. Der MX-Record dazu wird von Microsoft verwaltet.

nslookup -q=MX msxfaq.mail.onmicrosoft.com
Server:  fritz.box
Address:  192.168.178.1

Nicht autorisierende Antwort:
msxfaq.mail.onmicrosoft.com  MX preference = 10, mail exchanger = msxfaq-mail-onmicrosoft-com.mail.protection.outlook.com
[PS] C:\>Get-SendConnector "Outbound to Office 365"| fl

AddressSpaces                : {smtp:msxfaq.mail.onmicrosoft.com;1}
AuthenticationCredential     :
CloudServicesMailEnabled     : True
Comment                      :
ConnectedDomains             : {}
ConnectionInactivityTimeOut  : 00:10:00
ConnectorType                : Default
DNSRoutingEnabled            : True
DomainSecureEnabled          : False
Enabled                      : True
ErrorPolicies                : Default
ForceHELO                    : False
Fqdn                         : mail.msxfaq.de
FrontendProxyEnabled         : False
HomeMTA                      : Microsoft MTA
HomeMtaServerId              : EX2016
Identity                     : Outbound to Office 365
IgnoreSTARTTLS               : False
IsScopedConnector            : False
IsSmtpConnector              : True
MaxMessageSize               : 35 MB (36,700,160 bytes)
Name                         : Outbound to Office 365
Port                         : 25
ProtocolLoggingLevel         : None
Region                       : NotSpecified
RequireOorg                  : False
RequireTLS                   : True
SmartHostAuthMechanism       : None
SmartHosts                   : {}
SmartHostsString             :
SmtpMaxMessagesPerConnection : 20
SourceIPAddress              : 0.0.0.0
SourceRoutingGroup           : Exchange Routing Group (DWBGZMFD01QNBJR)
SourceTransportServers       : {EX2016}
TlsAuthLevel                 : DomainValidation
TlsCertificateName           : <I>CN=AlphaSSL CA - SHA256 - G2, O=GlobalSign nv-sa, C=BE<S>CN=*.msxfaq.de,
                               OU=Domain Control Validated
TlsDomain                    : mail.protection.outlook.com
UseExternalDNSServersEnabled : False

Eine Authentifizierung per Benutzername o.ä. findet nicht statt. Aber die Cloud "erkennt natürlich ihren Server, wie sie gleich sehen werden.

Hinweis:
Der Hybrid Connector ist wirklich per Default nur für die MOERA - Microsoft Online Email Routing Address "<tenantname>.mail.onmicrosoft.com" zuständig. Wenn sie in der Cloud auch Empfänger in der Domain "<tenantname>.onmicrosoft.com" nutzen, z.B. Microsoft Teams/Office Groups, dann können Sie diese Domain später mit addieren und damit auch diesen Verkehr durch den Tunnel senden.

Office 365: Inbound Connector von OnPrem

Der HCW legt in Office 365 zwei Connectoren an, einen für eingehende Mails von ihrem On-Prem-System und einen für Mails an ihr On-Prem-System.

Der "Inbound Connector" sorgt dafür, dass die Mails von der lokalen Umgebung entsprechend "vertrauenswürdig" sind.

In dem Beispiel identifiziert sich der On-Premises Server mit einem Zertifikat. Alternativ kann dies auch eine IP-Adresse sein.

Get-InboundConnector "Hybrid Eingehend"

Enabled                        : True
ConnectorType                  : OnPremises
ConnectorSource                : AdminUI
Comment                        :
SenderIPAddresses              : {}
SenderDomains                  : {smtp:*;1}
TrustedOrganizations           : {}
ClientHostNames                : {}
AssociatedAcceptedDomains      : {}
RequireTls                     : True
RestrictDomainsToIPAddresses   : False
RestrictDomainsToCertificate   : True
CloudServicesMailEnabled       : True
TreatMessagesAsInternal        : False
TlsSenderCertificateName       : hybrid.msxfaqdev.com
EFTestMode                     : False
ScanAndDropRecipients          : {}
EFSkipLastIP                   : False
EFSkipIPs                      : {}
EFSkipMailGateway              : {}
EFUsers                        : {}
OrganizationalUnitRootInternal : msxfaqdev.onmicrosoft.com
AdminDisplayName               :
ExchangeVersion                : 0.1 (8.0.535.0)
Name                           : Inbound from <guid>
Identity                       : Inbound from <guid>
IsValid                        : True
ObjectState                    : Unchanged

Dazu passend gibt es natürlich On-Prem dann auch den bereits beschriebenen Send-Connector. Ob der Connector bei einer Mail vom lokalen Exchange Server gegriffen hat, können Sie im SMTP-Header der Mail im Exchange Online Postfach sehen:

x-ms-exchange-crosstenant-id: de21c301-a4ae-4292-aa09-6db710a590a6
x-ms-exchange-crosstenant-originalattributedtenantconnectingip: TenantId=<Tenant-GUID>;Ip=[80.66.20.24];Helo=[hybrid.msxfaq.de]
x-ms-exchange-crosstenant-authsource: EX19.msxfaq.de
x-ms-exchange-crosstenant-authas: Anonymous
x-ms-exchange-crosstenant-fromentityheader: HybridOnPrem

Diese Header zeigen an, dass die Mail über einen Hybrid-Connector angenommen wurde.

Office 365: Outbound Connector zu OnPrem

In die Gegenrichtung wird ein "Outbound Connector" zur On-Prem-Umgebung angelegt. Maßgeblich hier das "Mail Flow Szenario" und hier die Angabe des "Smarthost". Auch hier wird das Zertifikat zusätzlich als Sicherheit verwendet, nicht dass ein DNS-Spoofing die Mails zu einem anderen Server umleiten könnte.

Der Connector ist hier für den Adressraum "*" gültig, da wir auch alle Mails von Office 365 über die On-Prem-Umgebung und NoSpamProxy versenden. Wenn Sie Mails aus der Cloud direkt in das Internet senden wollen, dann stehen hier nur die lokale Domänen. Hier ein Beispiel einer Konfiguration:

PS C:\> Get-OutboundConnector "Outbound to " | fl

Enabled                       : True
UseMXRecord                   : False
Comment                       :
ConnectorType                 : OnPremises
ConnectorSource               : AdminUI
RecipientDomains              : {}
SmartHosts                    : {hybrid.msxfaqdev.com}
TlsDomain                     :
TlsSettings                   : EncryptionOnly
IsTransportRuleScoped         : False
RouteAllMessagesViaOnPremises : False
CloudServicesMailEnabled      : True
AllAcceptedDomains            : True
SenderRewritingEnabled        : False
MtaStsMode                    : Opportunistic
SmtpDaneMode                  : Opportunistic
TestMode                      : False
LinkForModifiedConnector      : 00000000-0000-0000-0000-000000000000
ValidationRecipients          : {user@msxfaqdev.com}
IsValidated                   : True
LastValidationTimestamp       : 15.11.2023 13:06:44
AdminDisplayName              :
ExchangeVersion               : 0.1 (8.0.535.0)
Name                          : Outbound to 
Identity                      : Outbound to 
IsValid                       : True
ObjectState                   : Unchanged

Wichtig sind hier u.a. die Eigenschaften "CloudServicesMailEnabled:$true" und "TlsSettings: EncryptionOnly", damit der OnPremises Server auch die Hybrid-Felder akzeptiert.

On-Prem: Receive Connector zum Empfang von EXO

Auch der lokale Exchange Server muss unterscheiden können, ob die Mail nun " aus dem Internet" oder von Exchange Online im allgemeinen oder von ihrem Exchange Online Tenant kommt. Exchange On-Premises geht erst einmal davon aus, dass ihr Receive Connector "Default Frontend <servername>" für jegliche RemoteIP-Adresse auch aus dem Internet erreichbar ist und daher die Konfiguration dort angepasst werden muss. Der HCW prüft dies aber und wenn es keinen Receive Connector gibt, der "any" annimmt, dann legt HCW einfach einen neuen Connector an:

Das kann unerwartete Ergebnisse haben, wenn Sie vorher absichtlich eine "offene Annahme" unterbunden haben.

Die Standard Connectoren von Exchange 2016 sind z.B.:

[PS] C:\>Get-ReceiveConnector

Identity                                Bindings                                Enabled
--------                                --------                                -------
EX2016\Default EX2016                   {0.0.0.0:2525, [::]:2525}               True
EX2016\Client Proxy EX2016              {[::]:465, 0.0.0.0:465}                 True
EX2016\Default Frontend EX2016          {[::]:25, 0.0.0.0:25}                   True
EX2016\Outbound Proxy Frontend EX2016   {[::]:717, 0.0.0.0:717}                 True
EX2016\Client Frontend EX2016           {[::]:587, 0.0.0.0:587}                 True
EX2016\RelayAnonymous                   {[::]:25, 0.0.0.0:25}                   True

Sie finden hier aber noch einen zusätzlichen Receive Connectoren "RelayAnonymous", der für ausgewählte Source-IP-Adressen ein Relay erlaubt. Interessant ist hier als oder Default Frontend, mit dem sich Exchange 2016 verbinden könnte. Hier eine Auswahl der Felder:

[PS] C:\>Get-ReceiveConnector "EX2016\Default Frontend EX2016" |fl

AuthMechanism                             : Tls, Integrated, BasicAuth, BasicAuthRequireTLS, ExchangeServer
Banner                                    :
BinaryMimeEnabled                         : True
Bindings                                  : {[::]:25, 0.0.0.0:25}
ChunkingEnabled                           : True
DefaultDomain                             :
DeliveryStatusNotificationEnabled         : True
EightBitMimeEnabled                       : True
SmtpUtf8Enabled                           : True
BareLinefeedRejectionEnabled              : False
DomainSecureEnabled                       : True
EnhancedStatusCodesEnabled                : True
LongAddressesEnabled                      : False
OrarEnabled                               : False
SuppressXAnonymousTls                     : False
ProxyEnabled                              : False
AdvertiseClientSettings                   : False
Fqdn                                      : EX2016.msxfaq.de
ServiceDiscoveryFqdn                      :
TlsCertificateName                        : <I>CN=GlobalSign RSA OV SSL.....<S>CN=hybrid.msxfaqdev.de, O=....
Comment                                   :
Enabled                                   : True
ConnectionTimeout                         : 00:10:00
ConnectionInactivityTimeout               : 00:05:00
MessageRateLimit                          : Unlimited
MessageRateSource                         : IPAddress
MaxInboundConnection                      : 5000
MaxInboundConnectionPerSource             : 20
MaxInboundConnectionPercentagePerSource   : 2
MaxHeaderSize                             : 256 KB (262,144 bytes)
MaxHopCount                               : 60
MaxLocalHopCount                          : 5
MaxLogonFailures                          : 3
MaxMessageSize                            : 36 MB (37,748,736 bytes)
MaxProtocolErrors                         : 5
MaxRecipientsPerMessage                   : 200
PermissionGroups                          : AnonymousUsers, ExchangeServers, ExchangeLegacyServers
PipeliningEnabled                         : True
ProtocolLoggingLevel                      : Verbose
RemoteIPRanges                            : {::-ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff, 0.0.0.0-255.255.255.255}
RequireEHLODomain                         : False
RequireTLS                                : False
EnableAuthGSSAPI                          : False
ExtendedProtectionPolicy                  : None
LiveCredentialEnabled                     : False
TlsDomainCapabilities                     : {mail.protection.outlook.com:AcceptCloudServicesMail}
Server                                    : EX2016
TransportRole                             : FrontendTransport
RejectReservedTopLevelRecipientDomains    : False
RejectReservedSecondLevelRecipientDomains : False
RejectSingleLabelRecipientDomains         : False
AcceptConsumerMail                        : False
SizeEnabled                               : Enabled
TarpitInterval                            : 00:00:05
AuthTarpitInterval                        : 00:00:05
MaxAcknowledgementDelay                   : 00:00:30
AdminDisplayName                          :
ExchangeVersion                           : 0.1 (8.0.535.0)
Name                                      : Default Frontend EX2016
Identity                                  : EX2016\Default Frontend EX2016
IsValid                                   : True
ObjectState                               : Unchanged

Und hier noch mal die "tlsdomaincapabilities" genauer aufgeschlüsselt.

[PS] C:\>(Get-ReceiveConnector "EX2016\Default Frontend EX2016").tlsdomaincapabilities | fl

Domain             : mail.protection.outlook.com
Capabilities       : AcceptCloudServicesMail
SmtpX509Identifier :

Beachten Sie dabei auch den Wert von "TlsCertificateName". Hier sollte das Zertifikat vorgegeben werden, welches sie Exchange Online vorzeigen.

Zum einen sind die RemoteIP-Ranges nicht eingeschränkt und dann findet sich nur im Feld "TlsDomainCapabilities" der Wert "{mail.protection.outlook.com:AcceptCloudServicesMail}". Das ist auch der einzige Eintrag, den der HCW hier macht. Bei allen anderen Connectoren ist der Wert nicht gesetzt:

[PS] C:\>Get-ReceiveConnector | select identity,TlsDomainCapabilities

Identity                                                  TlsDomainCapabilities
--------                                                  ---------------------
EX2016\Default EX2016                                     {}
EX2016\Client Proxy EX2016                                {}
EX2016\Default Frontend EX2016                            {mail.protection.outlook.com:AcceptCloudServicesMail}
EX2016\Outbound Proxy Frontend EX2016                     {}
EX2016\Client Frontend EX2016                             {}
EX2016\RelayAnonymous                                     {}

So versteht der On-Prem-Server, dass eine Verbindung eines entfernten Systems, welches sich per Zertifikat als "mail.protection.outlook.com" ausweist, der passende Tenant ist.

Da kann man nun nur noch hoffen, dass keine PKI irrtümlich ein Zertifikat für diesen Namen ausstellt und damit jemand anderes sich als legitimer Partner ausweisen kann.

Wie unangenehmer dürfte es ihnen aber sein, dass der Receive Connector erst einmal von "überall" erreichbar ist und auch wenn sich die Absenderseite nicht mit einem Zertifikat ausweist, so kann sie dann eben "normale" Mails ohne Empfängerprüfung, SPF-Check, RBL-Check etc. einliefern. Keine verlockende Aussicht.

Achtung:
Sie müssen sich Gedanken zur weiteren Absicherung des On-Prem Receive Connectors machen, da sie ansonsten eventuell ein "offenes System" haben.

Beachte dazu auch die Seite Hybrid Hintereingang

Prüfung und Fehlersuche

Nach der automatischen oder manuellen Einrichtung eines Hybrid Connectors sollten Sie jeweils eine Mail zwischen einem OnPremises-Postfach und einem Exchange Online Postfach senden, die auch beide in beiden Welten bekannt sein müssen, d.h. ADSync muss die Objekte synchronisieren. Ein "CloudOnly"-Postfach ist kein legitimer Test. Schauen Sie sich dann genau den Absender bei der empfangenen Mail an. Er sollte den "Displaynamen" anzeigen und kein "<mailadresse>" sichtbar dahinter haben. Wenn die SMTP-Adresse sichtbar ist, dann ist das ein Zeichen für den "anonymen" und nicht authentifizierten Empfang.

Beim Exchange OnPremises Server können Sie im Receive Connector einfach das SMTP-Logging aktivieren und finden einen Hinweis wie z.B.  

 

Der Fehler "Ignored X-OriginatorOrg header value ..." zeigt an, dass die Mail zwar Exchange Online den Header in der Mail liefert. Hier sehe ich eine eingehende Verbindung von Exchange Online zu einem lokalen Server und nach dem EHLO bietet der lokale Exchange auch STARTTLS an. Allerdings startet Exchange Online dann direkt die Mail ohne auf TLS zu wechseln und damit kann der Receive Connector das Client-Zertifikat nicht prüfen. Dann ist klar, dass er den "X-OriginatorOrg"-Header und alle anderen Einstellungen blockiert, die für einen Hybrid-Mailflow erforderlich sind. Ursache war hier ein vorgelagerte Firewall, die neben Layer4-Umsetzung auch "SMTP missverstanden" hat.

Das folgende Beispiel zeigt eine TLS-Verbindung, bei der aber das Client-Zertifikat von Exchange Online nicht angekommen ist

Sie sehen das am "Status=NoRemoteCertificate"  oder dem "EmptyCertificate" darüber. Auch hier eine eine Firewall von extern zwar den STARTTLS noch durchgelassen aber das Paket derart verändert, dass Exchange Online kein Client Zertifikat gesendet hat. Eine korrekte eingehende Verbindung sieht dann wie folgt aus:

Mein Exchange OnPremises Server bietet STARTTLS an, welches der Absender dann nutzt. Danach sehe ich mein ausgeliefertes Zertifikat aber auch das Client-Zertifikat von Exchange Online (cn=mail.protection.outlook.com) und Exchange wendet die "TlsDomainCapabilities" an, was z.B. ein "BypassAntiSpam" und andere Vorteile mit sich bringt.

Remote Domains

Mit den Connectoren in Office 365 und On-Prem ist sichergestellt, dass die Mails zwischen den beiden Welten direkt und per TLS verschlüsselt und abgesichert übertragen werden. Ganz fertig sind wird aber noch nicht, da im nächsten Schritt nun den beiden Welten beigebracht wird, dass die andere Seite vertrauenswürdiger ist als das restliche Internet. Das gilt z.B. hinsichtlich von OOF-Meldungen (Intern statt extern), die Erlaubnis zur automatischen Weiterleitung von Mails über Regeln u.a.

Auch das macht der HCW für sich, indem er in Office 365 ihre On-Prem-Domain entsprechend einträgt und konfiguriert.

On-Prem werden die vergleichbaren Einstellungen für die "tenantname.mail.onmicrosoft.com" gemacht, die als TargetAddress bei den Benutzern hinterlegt ist, deren Postfach schon in der Cloud liegt.

Routing mit CBR -Connector based Routing

Während bei Exchange On-Prem normalerweise anhand der Ziel-SMTP-Domäne der passende Send-Connector ausgewählt wird, ist die bei Exchange Online anders geregelt. Über Transport-Regeln kann man nicht nur die Mails verändern, sondern auch den "Next Hop" vorgeben.

Das können Administratoren einer On-Prem-Umgebung so nicht aber eröffnet in Office 365 vielfältige Möglichkeiten einer Anbindung von anderen Dienstleistern.

Von anderem Tenant

Interessant ist der Versand einer Mail von einem anderen Office 365 Tenant an eine On-Prem Service. Auch hier wird die Mail per TLS verschlüsselt und es werden die gleichen Mailserver für den Versand ins Internet wie auch zum Versand im Hybridmode genutzt. Ein Relay muss also einen anderen Indikator heranziehen, um die Mail aus dem "eigenen Partner-Tenant" auch als solchen zu verwenden.

Hier habe ich mal eine Mail aus meinem NoSpamProxy extrahiert und mir die Header angeschaut.

X-OriginatorOrg: msxfaq.onmicrosoft.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Jan 2015 16:11:58.9849 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: eef62a09-7718-4063-82db-d7582dc8916f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR01MB267

Wenn eine Firewall oder Schutzlösung etwas genauer auf die Verbindung schaut, dann könnte Sie anhand des Zertifikats ermitteln, dass die Gegenstelle Office 365 ist und dann über den Header den Tenant ermitteln.

Weitere Links