Office 365 Mail Routing

Microsoft macht es den Firmen sehr einfach, eine Domäne und die Postfächer in Office 365 zu hosten. Mit der Einrichtung des Tenant kann der Kunde auch eine Domäne addieren, für die sofort Postfächer angelegt werden können. Um Mails empfangen zu können, muss der Administrator dann "nur" den MX-Record auf die Office 365-Umgebung lenken. Zum Versand sind überhaupt keine Anpassungen erforderlich, da die Postfächer alle direkt versenden können.

Die Standartkonfiguration der Connectoren muss ein Administrator immer nur dann angehen, wenn er Mails abweichend zustellen will oder bestimmte Absender gewisse Vorteile verschaffen will.

Connector Grundlagen

Daher gibt es auch bei Office 365 die Möglichkeit, entsprechende Connectoren einzurichten. Microsoft hat um den Mai 2015 herum die Konfiguration von Connectoren in Exchange grundlegend geändert. In einem Blogeintrag, vom folgendes Bild stammt, wurde dies kurz erklärt:


Announcing a new way to create connectors in Office 365
http://blogs.office.com/2015/05/22/announcing-a-new-way-to-create-connectors-in-office-365/

Microsoft unterscheidet pro Tenant nun mit wem die Firma wie kommunizieren möchte. Im gleichen Schritt hat Microsoft aber auch die Konfiguration in der Exchange Management Center geändert. Wer z.B. den Hybrid-Mode nutzt oder auch sonst auf einen Exchange 2013 "OnPremise" Server schaut, wird noch das bekannte Bild sehen. Unter Nachrichtenfluss finden sich die Reiter für Sendeconnectoren und Empfangskonnectoren:

In der Cloud hingegen gibt es diese Bild mittlerweile nicht mehr. Stattdessen gibt es nur noch Connectoren:

Wenn Sie hier einen Connector anlegen wollen, dann werden Sie nach dem Szenario gefragt, also nach der Quell und dem Ziel dieser Verbindungen. Entsprechend legt Office 365 im Hintergrund dann einen Send-Connector oder einen Receive-Connector an.

Abhängig davon, was Sie beim "Von" auswählen, gibt es unterschiedliche Möglichkeiten beim "Ziel". Folgende Konstellationen für "Von" und "An" waren am 28. Mai 2015 möglich.

Ausgehende Connectoren

Wenn sie als Quelle "Office 365" nutzen, dann können Sie in der zweiten Box nur drei Optionen auswählen. Entsprechend der Wahl kommen weitere Fenster zur Spezifikation der Parameter. 

Von An Filter Zustellung Sicherheit Interne Header Bemerkung

Office 365

Eigene Organisation

  • Transportregel
    oder
  • AcceptedDomains
    oder
  • Domainliste
    Aber kein "*"

FQDN-Ziel

  • TLS mit öffentlichen
    oder
  • selfsigned Zertifikaten
    am Ziel


Empfohlen

Über diese Connector erreichen Sie eine enge Verbindung zwischen Office 365 und einer Exchange oder anderem Mailplattforn "OnPremise".

Office 365

Partner

  • Zieldomäne (auch mit *"
    oder
  • Transportregel

  • MX-Record
    oder
  • Smarthosts

  • TLS mit öffentlichen
    oder
  • selfsigned Zertifikaten
    am Ziel


nicht möglich

Hier mit können Sie ihren Tenant mit anderen Partnerfirmen verbinden und z.B. TLS vorschreiben. So können Sie eine Verschlüsselung erzwingen, die ansonsten nur optional ist.

Smarthost kann im ECP-Assistenten nicht ausgewählt aber später in der Konfiguration aktiviert werden.

Office 365

Internet


entfällt


entfällt


entfällt


nicht möglich

Dieser Weg ist per Default eingerichtet und kann nicht konfiguriert werden. (Hinweis Centralized Routing)

Eingehende Connectoren

Wenn Sie eine der drei Quellen im ersten Schritt auswählen, dann ist das Ziel immer Office 365. Sie können also keine direkte Brücke zwischen einem Partner und dem Internet oder einem Server OnPremise konfigurieren. Die Mails gehen also immer durch Office 365.

Von An Filter Sicherheit Interne Header Bemerkung

Eigene Organisation

Office 365

  • Zertifikatsname
    oder
  • Source-IP

  • TLS bei Filter nach Zertifikatsnamen erzwungen.


Empfohlen

Absender muss aus "Accepted Domains" sein. Also nicht aus dem Internet (Stichwort Centralized Routing)

Achtung:
Mails über diesen Connector werden als "Trusted" angesehen und bekommen einen "SCL -1" und werden damit nicht mehr auf Spam/Viren geprüft.

Partner

Office 365

  • AbsenderDomäne
    oder
  • Source-IP

  • TLS erzwingen
  • Zertifikatvalidierung
  • IP-Filterung


nicht möglich

Über diesen Connector können Sie einen Partner bevorzugt behandeln.

Internet

Office 365


entfällt


entfällt


nicht möglich

Dieser Connector ist nicht addierbar, da er per Default schon vorhanden ist. Stellen Sie einfach den MX-Record zu Office 365 um.

Centralized Routing

In der Regel senden Postfächer in der Cloud ihre Mails direkt in das Internet und nur Empfänger OnPremise bekommen die Mails über einen passenden Connector. Allerdings gibt es auch die Option, dass alle Mails über die OnPremise-Server geroutet werden. Das ist z.B. erforderlich, wenn Sie durch ein Gateway digital signieren wollen. Hierzu können Sie im Hybrid Konfigurationsassistent die Funktion "Route all Internet-bound messages through your OnPremises Exchange Servers " (Exchange 2010) bzw. "Enable Centralized Mail Transport” (Exchange 2013) aktivieren.

Wird hierüber die Konfiguration durchgeführt, dann legt der Assistent einige Connectoren im Hintergrund an. Maßgeblich ist hier vor allem der Connector in Office 365, über den alle Mails zum Server "OnPremise" geroutet werden. Dazu legt der Assistent einen Send-Connector zur Organisation an, wie man in der GUI und noch besser in der Exchange remote PowerShell sehen kann:

$Cred = Get-Credential
$Session = New-PSSession `
   -ConfigurationName Microsoft.Exchange  `
   -ConnectionUri https://outlook.office365.com/PowerShell-liveid/  `
   -Credential $Cred `
   -Authentication Basic  `
   -AllowRedirection
Import-PSSession $Session

Get-OutboundConnector

Name                RecipientDomains    SmartHosts          Enabled
----                ----------------    ----------          -------
Outbound to 1191... {*}                 {hybrid.msxfaq.de... True

PS C:\> Get-OutboundConnector | fl


Enabled : True useMXRecord : False
Comment :
ConnectorType : OnPremises
ConnectorSource : Default
RecipientDomains : {*}
SmartHosts : {hybrid.msxfaq.de}
TlsDomain : mail.msxfaq.de
TlsSettings : DomainValidation
IsTransportRuleScoped : False
RouteAllMessagesViaOnPremises : True
CloudServicesMailEnabled : True
AllAcceptedDomains : False
TestMode : False
ValidationRecipients :
IsValidated : False
LastValidationTimestamp :
AdminDisplayName :
ExchangeVersion : 0.1 (8.0.535.0)
Name : Outbound to <GUID>
Identity : Outbound to <GUID>
IsValid : True

Alle Mails an "*" werden damit zu dem angegebenen Host geroutet. Auf der OnPremise-Seite wird bei Exchange 2010 noch ein Receive Connector angelegt. Bei Exchange 2013 entfällt dies und der Standard Receive-Connector wird entsprechen angepasst, sie hier zu sehen ist:

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

AuthMechanism                           : Tls, Integrated, BasicAuth, BasicAuthRequireTLS, ExchangeServer
BinaryMimeEnabled                       : True
Bindings                                : {[::]:25, 0.0.0.0:25}
ChunkingEnabled                         : True
DefaultDomain                           :
DeliveryStatusNotificationEnabled       : True
EightBitMimeEnabled                     : True
SmtpUtf8Enabled                         : False
BareLinefeedRejectionEnabled            : False
DomainSecureEnabled                     : True
EnhancedStatusCodesEnabled              : True
LongAddressesEnabled                    : False
OrarEnabled                             : False
SuppressXAnonymousTls                   : False
ProxyEnabled                            : False
AdvertiseClientSettings                 : False
Fqdn                                    : EX2013.msxfaq.de
ServiceDiscoveryFqdn                    :
TlsCertificateName                      : <I>CN=AlphaSSL CA - SHA256 - G2, O=GlobalSign nv-sa, C=BE<S>CN=*.msxfaq.de, OU=
Enabled                                 : True
ConnectionTimeout                       : 00:10:00
ConnectionInactivityTimeout             : 00:05:00
MessageRateLimit                        : unlimited
MessageRateSource                       : IPAddress
MaxInboundConnection                    : 5000
MaxInboundConnectionPerSource           : 20
MaxInboundConnectionPercentagePerSource : 2
MaxHeaderSize                           : 128 KB (131,072 bytes)
MaxHopCount                             : 60
MaxLocalHopCount                        : 5
MaxLogonFailures                        : 3
MaxMessageSize                          : 100 MB (104,857,600 bytes)
MaxProtocolErrors                       : 5
MaxRecipientsPerMessage                 : 200
PermissionGroups                        : ExchangeUsers, 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                   : {<I>CN=MSIT Machine Auth CA 2, DC=redmond, DC=corp, DC=microsoft, DC=com<S>CN=mail
                                          OU=Forefront Online Protection für Exchange, O=Microsoft, L=Redmond, S=WA, C=US:Ac
Server                                  : EX2013
TransportRole                           : FrontendTransport
SizeEnabled                             : Enabled
TarpitInterval                          : 00:00:05
MaxAcknowledgementDelay                 : 00:00:30
AdminDisplayName                        :
ExchangeVersion                         : 0.1 (8.0.535.0)
Name                                    : Default Frontend EX2013
OrganizationId                          :
Id                                      : EX2013\Default Frontend EX2013
IsValid                                 : True

Wichtig sind hier zwei Einträge

  • AuthMechanism
    Hier muss TLS mit aktiv sein, da sich Office 365 per Client Zertifikat meldet
  • TlsDomainCapabilities
    Hier taucht das Zertifikat auf, mit dem sich Office 365 meldet.
  • PermissionGroups
    Hier sollte normal nicht "anonym" erscheinen, es sei denn dieser Server ist zugleich das Ziel des MX-Records.

Bei Exchange 2010 wurde hier noch ein eigener Connector angelegt.

Office 365 mit anderem Mailrelay

Es sollte ihnen sicher nicht entgangen sein, dass ich mit Net at Work und dem Produkt NoSpamProxy an einem Produkt beteiligt bin, welche Mails nicht nur auf Viren und Spam prüfen sondern auch digital signieren und verschlüsseln kann. Wenn nun ein Interessent oder Kunde seine Infrastruktur komplett in die Cloud verlegt aber weiterhin den Mehrwert eines Drittproduktes für die Verbindung mit dem Internet nutzen will, dann muss in Office 365 dies entsprechend konfiguriert werden.

Mit dem Wissen dieser Seite sollten Sie nun recht einfach verstehen, wie Sie ihren Office 365 Tenant dazu bringen, alle Mails an einen anderen ausgehenden Server zu senden:

  • Connector "Office 365 -> Partner"
    Adressraum "*"
    Smarthost: "ausgehendes Relay"
    TLS mit Name absichern

Alternativ könnten Sie auch einen Connector ohne Adressraum konfigurieren, der über Transportregeln angesprochen wird und eine entsprechende Transportregel anlegen.

Beachten Sie aber, dass der "Smarthost" einige Besonderheiten beachten muss, um sinnvoll die Berechtigungen prüfen zu können

Weitere Links