Office 365 Mail Connector

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.

Wichtig: Beim Einsatz der Option "Centralized Mail Transport" sind Besonderheiten zu beachten: Siehe dazu Hybrid Centralized Mail Transport.

Die Standardkonfiguration 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 On-Premises 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.

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

Establishing Exchange Hybrid Mailflow
https://www.youtube.com/watch?v=1i_SO6nKe0o&ab_channel=Microsoft365
20 Minuten sehr detaillierte Informationen zu Connectoren und insbesondere Centralized Mail Flow

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 On-Premises.

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 On-Prem 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.

Receive Connector On-Prem

Um die Mails aus der Cloud zu empfangen, wird On-Prem natürlich auch ein Empfangsconnector benötigt. bei Exchange 2010 wurde sogar noch ein eigener Connector angelegt. Bei Exchange 2013/2016 wird der bestehende Connector ggfls. aktualisiert.

[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 die folgenden 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