Pozn.: Často používám termín lokální či interní místo On-Premises. Obecně pro cloudové služby Microsoftu (Azure AD, Office 365, Microsoft 365, Exchange Online) buď označení cloud nebo online. On-Premises Exchange pouze Exchange, cloudový Exchange Online případně zkratku EXO. Pro Hybrid Configuration Wizard je zkratka HCW. Sám Microsoft různě používá označení Microsoft 365, Office 365, Exchange Online (často v souvislosti s organizace / tenant). Další termín k EXO je Exchange Online Protection (EOP), což je většinou myšlena služba přijímající poštu do EXO a provádějící ochranu. V různých adresách používám termín tenant, který se v praxi nahrazuje názvem daného Tenantu.

Příjem a odesílání zpráv

Transport options in Exchange hybrid deployments, Transport routing in Exchange hybrid deployments

Pozn.: Pokud se rozhodneme nastavit jako hlavní Microsoft 365 nebo Office 365, a MX záznamy směrujeme do Exchange Online, tak musíme provést několik změn, které HCW neprovede.

Při odesílání zpráv je standardně zpráva odeslána organizací, kde se schránka nachází. V Hybrid Configuration Wizard máme možnost zapnout Centralized Mail Transport. Pak jsou zprávy odesílané do internetu, ze schránek v Exchange Online, předány na On-Premises servery k odeslání (vše odesílají interní servery). Pokud bychom chtěli vše odesílat přes cloudové servery, tak můžeme upravit (či vytvořit) konektor na On-Premises (AddressSpaces * a odesílání pomocí Smart Host tenant.mail.protection.outlook.com). Set up your email server to relay mail to the Internet via Microsoft 365 or Office 365.

Microsoft zdůrazňuje, že mezi On-Premises a Online Exchange servery nesmí být žádná komponenta, která zpracovává/upravuje SMTP provoz. Tedy patrně ani AntiSpam brána (udělal jsem malý test a zprávy korektně procházely i přes bránu). Microsoft do těchto zpráv přidává určité vlastní hlavičky, které zprávu určují jako interní. Pokud by se tento údaj odstranil, tak je zpráva externí/anonymní a pracuje se s ní jinak.

Řešit to můžeme tak, že budeme mít dvě veřejné adresy pro příjem pošty. Standardní příjem pošty (SMTP) využívá adresu zadanou v MX záznamu domény. Ta je směrovaná na poštovní bránu. Do Outbound konektoru v naší Exchange Online organizaci zadáme jako Smart Host jinou adresu. Ta směruje přímo (přes firewall) na Exchange server (je potřeba, aby používal důvěryhodný certifikát). Příjem přes tuto adresu můžeme chtít omezit na IP adresy z EXO. Jejich seznam nalezneme v Exchange Online IP addresses and URLs.

Accepted Domains - Authoritative vs. InternalRelay

Manage accepted domains in Exchange Online

Další důležitá věc se týká informace o příjemcích. Ve výchozím stavu, aby fungovalo doručování zpráv mezi On-Premises a Exchange Online organizacemi (což v řadě případů znamená i doručování zpráv z internetu). Tak musí mít obě organizace informaci o všech příjemcích a vědět, zda se schránka nachází lokálně nebo externě (typ Mail User a User Mailbox, externí schránky jsou jako Contact nebo RemoteMailbox). Pokud dorazí zpráva pro příjemce v rámci autoritativní akceptované domény, a přijímající Exchange organizace nemá uživatele vedeného jako s emailem (Recipient), tak zprávu odmítne.

Můžeme nastavit i jiné chování, kdy je zpráva pro neznámého příjemce předána druhé organizaci. To určujeme nastavením typu akceptované domény na InternalRelay. Například pro situaci, kdy chceme stále primárně využívat On-Premises Exchange a v cloudu používat pouze určité služby. Pak nemusíme chtít synchronizovat do cloudu veškeré mailové skupiny a účty. Aby z cloudu dorazila pošta i na adresy, které zde nejsou synchronizované, tak musíme změnit typ domény.

Přidání domén se provádí v Microsoft 365 admin center. Doména se pro Exchange Online automaticky nastaví jako Authoritative Accepted Domain (takže může odesílat a přijímat poštu). Typ můžeme změnit v Exchange admin center (EAC) - Mail flow - Accepted domains. Nastavit můžeme dva typy:

• Authoritative - přijímá zprávy pouze pro validní příjemce v této organizaci, ostatní příjemci jsou odmítnuti, všichni příjemci tedy musí existovat v online organizaci (i když jejich schránka může být v On-Premises), provádí se Directory Based Edge Blocking (DBEB), kdy jsou neexistující příjemci odmítnuti již na perimetru
• InternalRelay - pro známé příjemce je zpráva doručena, pro neznámé je předána na On-Premises server, příjemce tedy může existovat pouze na interních serverech a nemusí být v cloudu, musíme mít definovány konektory (ty vytvoří Hybrid Configuration Wizard), MS nedoporučuje tuto volbu, pokud máme všechny příjemce v cloudu

Problém s doručováním zpráv do jiných organizací v EXO

Hned po konfiguraci Exchange Hybrid jsem narazil na problémy s doručováním pošty do určitých domén. Patrně na tento problém řada firem nenarazí a jak jsou poštovní zprávy směrovány je jim jedno. Ale špatné mi přijde, že Microsoft o tomto v oficiální dokumentaci vůbec nepíše. Až později jsem nalezl pár článků, které toto chování popisují.

Já jsem plánoval, že zatím zůstanou všechny schránky na On-Premises Exchange serverech. Takže jsem podle informací předpokládal, že všechna pošta bude odcházet z interního prostředí (stejně jako přicházet podle MX záznamu). Konektory, které vytvořil průvodce, jsem očekával, že slouží pouze pro přenos zpráv v rámci naší domény. Pokud jsou některé schránky interně a některé v cloudu. Zjistil jsem, že to tak není. To si popíšeme dále.

Krátce po dokončení konfigurace Exchange Hybrid se ozvalo několik našich partnerských firem, s kterými vyměňujeme hodně zpráv, že jim najednou přestaly přicházet emaily od nás. Docela rychle jsem zjistil, že všechny tyto firmy mají MX záznam směrovaný na Exchange Online. Tedy poštu hostovanou u Microsoftu. V logu odchozích zpráv byla poslední událost, že zprávy korektně přijal Microsoft server.

Více jsem zjistil teprve poté, co jedna firma provedla analýzu na své straně (v EXO) a poslala mi řadu informací. První informace by přitom byly ještě zavádějící. Všechny naše zprávy (od konfigurace HCW) končili v karanténě, měly Spam Confidence Level 9. Což by se zdálo, že nás Microsoft najednou začalo blokovat kvůli SPAMu. Naštěstí mi také poslali hlavičku jedné takové zprávy. Zde byl vidět pravý důvod, selhalo SPF. Bylo zde uvedeno, že zpráva nebyla přijata od našeho serveru (IP adresy), ale z adresy 40.107.21.80. To je adresa Microsoftu patří k outbound.protection.outlook.com, tedy odesílací adrese Exchange Online.

Sender Policy Framework (SPF) a Exchange Hybrid

Řešení je jednoduché, přidat do SPF záznamu (DNS záznam typu TXT)

include:spf.protection.outlook.com

Celý záznam může vypadat následně.

"v=spf1 ip4:10.20.30.40 include:spf.protection.outlook.com -all" 

Plyne z toho poučení, pokud používáme SPF (popis Ověřování emailů pomocí SPF - Sender Policy Framework nebo u MS How Microsoft 365 uses Sender Policy Framework (SPF) to prevent spoofing), tak pro Exchange Hybrid musíme vždy povolit odesílání z Microsoft serverů. I když zatím neplánujeme žádné schránky v cloudu.

Tok pošty skrze firemní Tenant v Exchange Online

Když jsem se v Exchange Online podíval pomocí Message trace (New Exchange admin center), tak jsem zde nalezl všechny ty nedoručené zprávy (a spoustu dalších, o kterých jsem nevěděl). Ve zjednodušeném reportu bylo vidět, že byla zpráva přijata od naší IP adresy a poslána na nějakou adresu Microsoftu inbound.protection.outlook.com (třeba 104.47.9.36).

Na první pohled to vypadá, že všechny zprávy pro jiné organizace v Exchange Online, zachytí náš Inbound Connector. Zprávu tedy přijme náš Tenant, ten ví, že patří jinému příjemci, takže ji odešle pomocí MX záznamu. Odchází standardně jako by byla odeslána z Exchange Online. Při druhém přijetí již nepadne do našeho konektoru (neodpovídá certifikát nebo IP), ale je doručena do cílového Tenantu.

Provedl jsem řadu pokusů. Protože asi nejvíce informací, jak zpráva putovala, je vidět v hlavičce doručené zprávy, tak jsem napsal do různých hostovaných domén a získal zpět doručené emaily. Pro analýzu hlaviček může pomoci nástroj Message Header Analyzer. Je vidět, že zpráva prochází přes mail.protection.outlook.com na nějaký prod.outlook.com a je opět odesílána z outbound.protection.outlook.com. Znovu ji přijme mail.protection.outlook.com až dojde na cílový prod.outlook.com.

Dost mne zmátlo, když jsem zjistil, že některé zprávy neprošly naším Exchange Online, ale byly doručeny rovnou do cílového Tenantu. Ale dává to smysl, náš konektor se nachází na určitých MS serverech, pokud je cílový tenant na stejných serverech (IP adresách), tak se použije konektor. Nezjistil jsem, zda jde o geolokaci (MS v admin center uvádí pouze European Union) nebo datacentrum nebo forest nebo co přesně, aby organizace měly stejné adresy.

Identifikovat, zda jsou dva Tenanty (domény) na stejných serverech, můžeme jednoduše. Podíváme se na MX záznam a jaké IP adresy vrací dané DNS jméno. Naše organizace, a většina ostatních, má (v praxi je slovo Tenant nahrazeno jménem dané organizace)

tenant1.mail.protection.outlook.com - IP adresy 104.47.8.36, 104.47.9.36, 104.47.10.36

V pár případech šlo o jiné adresy a zprávy byly doručeny napřímo.

tenant2.mail.protection.outlook.com - IP adresy 104.47.0.36, 104.47.1.36, 104.47.2.36

Konektory mezi On-Premises a Online

Vše způsobuje Inbound Connector na Exchange Online. Hybrid Configuration Wizard standardně vytvoří a nastaví několik konektorů. Můžeme se podívat na jejich detaily (zde s vypnutým Centralized Mail Transport, což je default).

Na On-Premises Exchange serverech

• Default Frontend Receive Connector - upraví konektor Default Frontend SERVER, hlavně se nastaví certifikát (TLSCertificateName) a odebere skupina ExchangeUsers
• Send Connector - vytvoří konektor Outbound to Office 365 - TenantOrganizationGUID, nastaví se pro adresy z domény (tenant = náš tenant) tenant.mail.onmicrosoft.com (AddressSpaces), doručování podle MX záznamu, zapne TLS (RequireTLS, TLSCertificateName) a ověření domény mail.protection.outlook.com (TLSAuthLevel, TLSDomain), zapne CloudServicesMailEnabled (určuje využití interních hlaviček pro hybrid mail flow)

Na Exchange Online

• Standard Inbound Connector - vytvoří konektor Inbound from OrganizationGUID, přijímá všechny domény (SenderDomains smtp:*;1), typ konektoru (ConnectorType) OnPremises (obsluhuje domény používané v interní organizaci), vyžaduje TLS (RequireTLS) a náš certifikát (TLSSenderCertificateName, RestrictDomainsToCertificate slouží k identifikaci odesílajícího serveru, druhá možnost je IP adresa), zapne CloudServicesMailEnabled
• Standard Outbound Connector - vytvoří konektor Outbound to OrganizationGUID, pro adresy z naší domény firma.cz (RecipientDomains), směruje na zadanou adresu interního serveru (SmartHosts), typ konektoru OnPremises, TLS ověření našeho certifikátu (TLSSettings, TLSDomain), zapne CloudServicesMailEnabled, nezapne (podle nastavení v průvodci) Centralized Mail Transport (RouteAllMessagesViaOnPremises)

Uplatnění konektorů

Z toho plyne, že by vše mohlo fungovat i bez konektorů na interních Exchange serverech. Hlavně se řeší TLS a identifikace pomocí certifikátu, aby se spojily správné dvě strany. Pro odesílání se doplňuji interní položky do hlavičky zprávy. Microsoft uvádí, že kdybychom nepoužili konektory, a vyměňovali velké množství zpráv mezi našimi poštovními servery a Microsoft 365 či Office 365 organizací, tak by se uplatnil Graylisting (omezování provozu jako ochrana proti SPAMu).

Odesílání z našeho cloud Tenantu se nastaví pro adresy příjemců z naší domény a posílá se přes zadaný server (nemusí být stejný jako v MX záznamu, protože by mělo směrovat přímo na Exchange server, a ne třeba přes AntiSpam bránu).

Příjem do našeho cloud Tenantu se identifikuje pomocí TLS spojení s certifikátem s naším jménem, přijímá zprávy z libovolné odesílací domény. Neřeší se adresa příjemce. Můžeme upravit různé nastavení, ale nelze určit, aby konektor fungoval pouze pro příjemce v naší doméně. Zkusil jsem i nastavit do SenderDomains pouze určitou doménu a stejně skrze konektor procházely emaily z jiných domén.

Dokumentace k Mail Flow a co zde nalezneme

Popis Exchange Server hybrid deployments k této oblasti uvádí pouze základní a velice omezené informace (Transport options and routing). Trochu více informací nalezneme v dokumentaci Exchange Online (Mail flow best practices). Jde například o články

• Mail flow best practices for Exchange Online, Microsoft 365, and Office 365 (overview)
• Set up connectors to route mail between Microsoft 365 or Office 365 and your own email servers
• Configure mail flow using connectors
• Manage mail flow with mailboxes in multiple locations (Exchange Online and On-Premises)

Různé scénáře toku pošty

Jsou zde popsány různé scénáře a potřebné konfigurace (konektorů). Ale mluví se pouze o našich schránkách v cloudu a na interních serverech a posílání a přijímání pošty z internetu či partnerských organizací. Popisují se varianty, zda všechna pošta přichází do cloudu (jaké změny musíme udělat) nebo na On-Premises servery, kde se provádí kontrola a odkud odchází. Nikde se nezmiňuje situace, kdy je příjemce další organizace na stejných EXO serverech, a že pak je chování jiné, než by člověk očekával. Také mi přijde škoda, že pro různé scénáře jsou popsány jednotlivé kroky konfigurace, ale chybí detailní popis konfigurace konektorů (vždy je uvedeno projděte průvodce).

Konektor do cloudu a doručování

Microsoft uvádí (How do connectors route mail between Microsoft 365 or Office 365 and my own email server?), že konektor z našich firemních serverů do EXO přijímá všechny zprávy z našich poštovních serverů a odesílá je za nás (naším jménem) příjemcům. Příjemce může být schránka v naší EXO organizaci nebo příjemce v internetu. Potřebujeme vytvořit konektor na interních serverech, který odesílá zprávy přímo na EXO. Pokud bude odesílat všechny zprávy do EXO, tak veškerý pošta bude odcházet z cloudu (a můžeme využít jeho bezpečnostní funkce).

Možnosti odesílání z cloudu přes konektor

Pokud vytváříme odchozí konektor, tak máme více možností nastavení. Můžeme vytvořit pro všechny naše akceptované domény, pro vyjmenované domény nebo využít Transport Rule (Scenario: Conditional mail routing in Exchange Online). Můžeme také nastavit, aby se všechny odchozí zprávy odeslaly na speciální službu (server), kde se provedou nějaké úpravy/kontroly a pak se pošlou zpět na EXO odkud standardně odejdou příjemci (Scenario: Integrate Microsoft 365 or Office 365 with an email add-on service). Další speciální věc, pouze pro specifické scénáře, je Enahnced Filtering for Connectors.

Kde jsou schránky

V mnoha scénářích Microsoft vychází z toho, že jsou všechny schránky v cloudu (to se snaží doporučovat, protože je to pro něj výhodné). Situace, kdy je část schránek lokálně a část v cloudu je popsána Manage mail flow with mailboxes in multiple locations (Exchange Online and On-Premises). Jak posílat emaily ze zařízení nebo aplikací, obecně jak využít SMTP Relay, je popsáno v How to set up a multifunction device or application to send email using Microsoft 365 or Office 365.

Kdy odchozí zprávu zpracuje náš Tenant

Po zkoumání, které mi ukázalo chování popsané v předchozích kapitolách, a studování oficiální dokumentace, se mi podařilo formulovat dotaz do Google. Ten mi vrátil následující články, které popisují právě to chování. Kdy zpráva pro jiný Tenant Microsoft 365 projde naším Tenantem.

• Office 365 Message Attribution
• Demystifying and troubleshooting hybrid mail flow: when is a message internal?
• Important notice for Office 365 email customers who have configured connectors
• Configure a certificate-based connector to relay email messages through Office 365

Přiřazení zprávy k Tenantu a typ Incoming vs. Originating

Popisují, že Microsoft 365 je velmi složité multi-Tenant prostředí, kde celá infrastruktura (IP adresy, certifikáty, transportní servery) může být sdílena s dalšími Tenanty. Proto je velmi důležité přiřazování zpráv k organizaci (Tenantu). Můžeme chtít odesílat všechny zprávy skrze EXO, aby došlo k požadovaným filtracím, kontrolám, apod. Proto když posíláme zprávu z našeho On-Premises serveru (a domény) jiné organizaci (doméně) v cloudu, tak se musí rozlišit, zda přichází (Incoming) do cílové domény nebo pochází (Originating) z naší domény.

Pokud příchozí zpráva odpovídá příchozímu konektoru (Inbound Connector) nějakého Tenantu a je typu OnPremises (tedy pochází z On-Premises serveru daného Tenantu) nebo pochází ze schránky v Exchange Online, tak se bere jako Originating. V ostatních případech, a pokud je doména příjemce akceptovanou doménou nějaké Office 365 organizace, tak se bere jako Incoming.

Zprávy Internal vs. Anonymous

Další článek popisuje, jak je důležité rozlišování zpráv na interní - Internal (nějakým způsobem autentizovaná, třeba odesláno přihlášeným uživatelem) a anonymní - Anonymous (přijato od anonymního zdroje).

V hlavičce emailu se nachází jedna z variant:

X-MS-Exchange-Organization-AuthAs: Internal
X-MS-Exchange-Organization-AuthAs: Anonymous

Interní zprávy se jinak zpracovávají, obchází anti-spam kontroly, mohou být doručeny do distribučních skupin, které vyžadují autentizované odesílatele, zpracovává je Resource Booking Attendant. Přesné rozhodování, jestli bude zpráva brána jako interní, je dost složité, záleží na určitých hlavičkách a konektorech. Proto je třeba mít vše dobře nastaveno a nemodifikovat hlavičky při přenosu mezi interními servery a cloudem.

Využívání více domén v On-Premises

Hodně zde řeším to, že zprávy z interních serverů projdou naším Tenantem, než jsou doručeny příjemci v jiné organizaci na stejných EXO serverech. Pro mne není důležitá primární doména, ale pokud máme na On-Premises Exchange serverech další domény pro které odesíláme a přijímáme poštu.

Pokud používáme více veřejných domén pro poštovní služby a chceme je používat také v cloudu na Exchange Online. Tak by to mělo být jednoduché a zmiňuje to většina scénářů oficiální dokumentace. Všechny domény musíme přidat jako Accepted Domain, ať již Authoritative nebo InternalRelay. A Hybrid Configuration Wizard by měl správně nastavit konektory i vše ostatní.

Jiná situace je, pokud další domény chceme používat pouze na interních serverech a do cloudu je nezahrnovat. Pokud zprávy odesíláme ze stejných interních serverů (přesněji se stejným/podobným certifikátem) a zpráva dorazí na Exchange Online servery, kde je i náš Tenant, tak ji zachytí náš Inbound Connector. Je jedno, jaká je doména odesílatele. Testy ukazují, že zafunguje Relay a zprávy jsou přeposlány z našeho Tenantu příjemci. A to i bez toho, aby byla daná doména nastavena jako Accepted Domain.

Detaily o On-Premises Inbound Connector

Zásadní tedy je, jak přesně se chová Inbound Connector, který přijímá zprávy z interních serverů, a jak lze případně nastavit. Z různé dokumentace (uvedené výše) jsem dal dohromady následující. Popis mi často přijde matoucí.

Jak se identifikují naše servery (konektor)

Podle čeho Microsoft 365 identifikuje náš poštovní server a přiřadí zprávy k příchozímu konektoru. Tedy jak můžeme nastavit Inbound Connector. Je to popsáno na různých místech Identifying email from your email server, Configure a certificate-based connector to relay email messages through Office 365, Configure your Microsoft 365 or Office 365 environment, ale nepřijde mi to úplně srozumitelné (zdá se mi, že informace vzájemně úplně neodpovídají).

• certifikát použitý pro TLS na poštovním serveru - (doporučeno) jde o důvěryhodný certifikát, který použije odesílající poštovní server k autentizaci s Exchange Online, doporučuje se, aby Subject Common Name nebo Subject Alternative Name certifikátu odpovídal primární SMTP doméně organizace
• odchozí IP adresa poštovního serveru - z jaké adresy, adres nebo rozsahu adres odchází naše pošta do cloudu, podle adres identifikuje EXO jako poštovní servery naší organizace, musí jít o naše vlastní IP adresy, nelze využít sdílené služby

Aby fungoval Relay

Dále se uvádí, že pokud chceme, aby Exchange Online nebo Exchange Online Protection (EOP) předával (relay) emaily z naší organizace do internetu, tak musí být splněno jedno z následujících

• používá se certifikát, kde Subject Name odpovídá akceptované doméně v našem Tenantu
• všechny odesílací domény a subdomény jsou konfigurovány jako akceptované domény v našem Tenantu

Parametr TlsSenderCertificateName a předmět certifikátu

Na několika místech se uvádí, že při konfiguraci Subject Name certifikátu pro Inbound Connector se může použít * (wildcard), př. *.firma.cz. Díky tomu můžeme používat certifikát serveru, kde je jeho doménové jméno, př. mail.firma.cz a toto jméno nemusíme registrovat jako akceptovanou doménu (kde máme registrováno firma.cz). Zápis s hvězdičkou pak odpovídá i jménu v certifikátu i registrované doméně.

Přeposílání zpráv za jiné domény

Z toho mi plyne, že pokud použiji pro odesílání pošty do EXO certifikát, kde jméno odpovídá akceptované doméně, a jeho jméno (doménu) nastavím na příchozím konektoru. Tak pak přes tento konektor mohu odesílat poštu za různé domény, které nemusím mít v cloudu nastaveny. Tyto zprávy se mohou i předávat (relay) externím příjemcům.

V jednom článku je zmínka, že fungující Spoofing (možnost odesílat za cizí adresy/domény) je pro SMTP normální. Ale Exchange Online není Open Relay, povoluje odesílání zpráv pouze svým identifikovaným zákazníkům. Jsou také uváděny legitimní důvody, kdy potřebuje server odeslat zprávu za jinou doménu (třeba přeposílání). Doporučuje se proto využívat certificate-based connector.

Pokud vytvářím konektor v EAC, tak se zde jako nápověda zobrazí dost z těchto informací. Například

Office 365 will only accept messages through this connector if the sender's domain or TLS certificate domain is configured
 as an accepted domain for your Office 365 organization.

Musím všechny domény nastavit jako akceptované v cloudu?

Podle některých článků bych chápal, že všechny domény odesílatele musí být nastaveny jako akceptované (Configuring the sender domain as an accepted domain). Ale možná jde o staré články a změnilo se to 5. 6. 2017, jak popisuje Configure a certificate-based connector to relay email messages through Office 365.

Ale také existuje report Non-accepted domain v Office 365 Security & Compliance - Mail flow Dashboard, který ukazuje informace o zprávách z On-Premises organizace, kde doména odesílatele není nastavena jako akceptovaná doména v Microsoft 365 Non-accepted domain report in the Security & Compliance Center. V článku se uvádí, že takové zprávy mohou být omezovány.

Jako závěr mi přijde, že další domény, které používám v interní organizaci, nemusím nastavovat v cloudu. A v těch speciálních případech, kdy projdou naším Tenantem, se korektně přepošlou. Ale pokud by takové pošty bylo velké množství, tak bych je nastavit měl.

Jak se určuje, ke kterému Tenantu zpráva patří

Zajímavý je popis How Office 365 determines to which tenant a specific message belongs. Když zkusím tento proces přepsat (a ještě trochu zjednodušit).

• vezme se certifikát použitý odesílacím serverem
• jméno v certifikátu (nebo SAN) se použije pro hledání Inbound Connector typu OnPremises, podle TlsSenderCertificateName, mezi všemi Tenanty v daném EOP lese
• z nalezených konektorů se hledá, který Tenant má TlsSenderCertificateName z konektoru nastaveno jako akceptovanou doménu (nejvíce specifický výsledek vyhrává) - pokud je nalezeno, tak je zpráva přiřazena jako Originating z tohoto Tenantu
• pokud se nenalezne, tak se podle Connecting IP (adresa odesílajícího serveru) hledá mezi všemi Tenanty v daném EOP lese Inbound OnPremises konektor, který odpovídá IP adrese
• z nalezených konektorů se hledá, který Tenant má MailFrom doménu nastavenu jako akceptovanou doménu - pokud je nalezeno, tak je zpráva přiřazena jako Originating z tohoto Tenantu
• pokud se nenalezne, tak se hledá podle domény v RcptTo, který Tenant ji má jako akceptovanou doménu - pokud je nalezeno, tak je zpráva přiřazena jako Incoming do tohoto Tenantu a dále se hledá, zda zpráva odpovídá nějakému Inbound Partner konektoru v tomto Tenantu, pokud ano, tak je k němu přiřazena, jinak přichází skrze Default Inbound Connector
• pokud se nenalezne, tak je zpráva odmítnuta

Z tohoto procesu plyne několik zajímavých závěrů, které byly více či méně zmíněny v dokumentaci.

• Abychom skrze náš EXO Tenant předali zprávu z domény odesílatele, kterou nemáme nastavenu jako akceptovanou, tak musíme využívat certifikát. Pokud máme příchozí konektor podle IP adresy, tak musí být doména odesílatele nastavena jako akceptovaná.
• Pokud používáme certifikát, tak se příchozí konektor hledá pouze podle jména v certifikátu, nekontroluje se odesílací doména (pokud tento krok pouze nevynechali v popisu procesu).

Jak zařídit, aby naše odchozí zprávy z On-Premises neprocházely skrze náš EXO Tenant

Nalezl jsem jediný popis FAQ #6(b) - I don’t want outbound email originating from my on-premises gateway going through my Office 365 tenant. How do I fix this? Řekl bych, že jde o jednu ze dvou možností.

• různé certifikáty - na Send Connector, který máme pro posílání zpráv do Exchange Online, použijeme jiný certifikát, než jaký máme na standardním odesílacím konektoru (do internetu), na Inbound Connector pak nastavíme jméno tohoto certifikátu (patrně bez hvězdičky, pokud by oba certifikáty byly na stejné doméně, a musíme jméno nastavit jako akceptovanou doménu)
• různé IP adresy - zařídit, aby pošta odcházející z našeho Send Connector do Exchange Online, odcházela z jiné veřejné IP adresy, než odchází ostatní pošta do internetu, Inbound Connector nastavit podle této IP adresy (i když se všude doporučuje využití certifikátu)

Omezení Inbound Connector

Oboje není úplně jednoduché realizovat. Já bych chtěl vyřešit, aby do našeho Tenantu v cloudu nepadaly žádné emaily z jiných odesílacích domén. Jako nejlepší by mi přišlo omezit Sender Domains na Inbound Connector. Když se podívám na cmdlet Set-InboundConnector, tak je zde parametr SenderDomains a AssociatedAcceptedDomains. Ale dělal jsem pokusy s oběma parametry, a zdá se, že nemají žádný vliv.

Typ konektoru OnPremises vs. Partner

Když vytvářím v cloud EAC konektor, který přijímá zprávy z naší organizace do našeho Office 365. Tak volím, jak se identifikují zprávy, buď podle jména v certifikátu nebo podle IP adresy odesílacího serveru. Nic dále nemohu nastavit.

Když vytvářím konektor z partnerské organizace do našeho Office 365. Tak volím, zda se zprávy identifikují podle domény odesílatele nebo IP adresy odesílacího serveru. Dále mohu na konektor nastavit omezení. Vyžadování TLS a také určitého jména v certifikátu. Příjem pouze z vybraných IP adres odesílacího serveru. Set up connectors for secure mail flow with a partner organization

Když vytvořím oba typy konektorů s podobným nastavením, a následně si je zobrazím pomocí PowerShellu, tak jsou jejich parametry téměř identické. Samozřejmě se liší hodnota ConnectorType OnPremises vs. Partner, první má povolené CloudServicesMailEnabled a defaultně je SenderDomains u prvního *, u druhého zadané *.firma.cz.

Parametry konektoru

Nepodařilo se mi najít žádnou dokumentaci konfigurace parametrů konektorů. V New-InboundConnector se neuvádí nic o tom, že některé parametry se dají použít pouze pro určitý typ konektoru, ale vypadá to, že je to tak. Docela se ztrácím i v popisu parametrů RestrictDomainsToCertificate, RestrictDomainsToIPAddresses, SenderDomains, SenderIPAddresses, TlsSenderCertificateName, tedy hlavně v jejich vzájemné vazbě. Možná to trochu vysvětluje jediná zmínka, kterou jsem nalezl v poznámce Manage mail flow using a third-party cloud service with Exchange Online.

If you already have an OnPremises inbound connector for the same certificate or sender IP addresses, you still need to
 create the Partner inbound connector (the RestrictDomainsToCertificate and RestrictDomainsToIPAddresses parameters are
 only applied to Partner connectors). The two connectors can coexist without problems.

Zde je jasně uvedeno, že parametry RestrictDomainsToCertificate a RestrictDomainsToIPAddresses se použijí pouze pro partnerský konektor. Takže to samé může být pro SenderDomains a AssociatedAcceptedDomains.