Tento článek patří do série, která vychází z mých poznámek při migraci Exchange organizace z verze 2010 na 2016. Nejde o kompletní postup, ale o popis hlavních bodů a oblastí. Příklady se týkají určitého daného designu, ale většinou se dají zobecnit. Stejně tak, i když jde o popis migrace, tak se informace hodí i pro novou instalaci či správu.

Oficiální dokumentace Exchange Server 2016, Mail flow and the transport pipeline, Configure mail flow and client access on Exchange servers.

Základní konfigurace

Aby nám začalo fungovat odesílání a příjem pošty z internetu, tak musíme vytvořit patřičné DNS MX záznamy a na Firewallu směrovat SMTP komunikaci na a z Exchange serveru. Na serveru musíme provést tři konfigurační kroky:

• Accepted Domains (EAC - Mail Flow - Accepted Domains) - určujeme domény, pro které přijímáme a z kterých odesíláme poštu
• Email Address Policies (EAC - Mail Flow - Email Address Policies) - politika pro generování emailových adresy pro uživatele
• Send Connector (EAC - Mail Flow - Send Connectors) - zařizuje odeslání pošty do internetu

Při nové instalaci se nám nastaví defaultní akceptovaná doména i politika, ale může být třeba je upravit. Send Connector neexistuje, takže dokud jej správně nevytvoříme, tak nelze odeslat email mimo organizaci.

Pokud děláme migraci ze starší verze Exchange, tak máme vše již hotové - jedná se o společnou konfiguraci celé Exchange organizace. Pouze musíme do našeho Send Connector přidat nový server jako zdrojový pro odesílání (Source Server).

Transport Pipeline / Service

Každá přijímaná i odesílaná zpráva je zpracována a kategorizována pomocí Transport Service (spadající pod Transport Pipeline) na Mailbox serveru. Následně se vkládá do doručovací fronty (Queue) pro doručení do cílové mailbox DB, DAG, AD Site nebo mimo organizaci. Exchange používá konektory (Connectors), aby umožnil příjem a odesílání pošty na Exchange serverech a také mezi službami na lokálním serveru.

Pozn.: Transport Pipeline funguje značně jinak než na Exchange 2010 a má to zásadní praktický dopad. Rozdíly si postupně popíšeme.

Na Mailbox serveru máme tři transportní služby, kterými prochází příchozí i odchozí zprávy. Služby spolu komunikují nejen v rámci jednoho serveru, ale také se službami na dalších Exchange serverech.

• Front End Transport service - zpracovává (bezstavově) příchozí (a případně odchozí) externí SMTP provoz pro Exchange organizaci, nekontroluje obsah, nevkládá zprávy do fronty
• Transport service - obdoba Hub Transport role na Exchange 2010, zpracovává veškerý SMTP poštovní tok pro organizaci, provádí kategorizaci zpráv, inspekci obsahu, nekomunikuje přímo s mailbox databases (jako na Exchange 2010)
• Mailbox Transport service - skládá se ze dvou služeb, přistupuje přímo do schránky a vybírá nebo vkládá zprávy
  • Transport Submission service - přistupuje (pomocí RPC) do lokální mailbox database, vybírá zprávy a předává je pomocí SMTP na Transport service na stejném nebo jiném Mailbox serveru
  • Transport Delivery service - přijímá  SMTP zprávy od Transport service na stejném nebo jiném Mailbox serveru a ukládá do lokální mailbox database

Podle Microsoft dokumentace (kde si vše můžeme prohlédnout podrobněji Mail flow and the transport pipeline) jsem nakreslil souhrnné schéma, které zobrazuje standardní příjem a odeslání zprávy. Mimo transportních služeb, zobrazuje také přijímací a odesílací konektory. Ty si podrobněji popíšeme dále, ale je důležité si uvědomit, že příchozí zpráva neprochází pouze jedním konektorem, ale dvěma (na různých službách). Pro odchozí zprávy máme dvě varianty, pokud vytvoříme standardní Send Connector, tak zprávy odchází z Transport service. Alternativně můžeme nastavit Proxy skrze Front End Transport service.

Receive Connectors

Dokumentace Receive connectors.

Konfigurace pomocí Exchange Management Shell Get-ReceiveConnector, Set-ReceiveConnector nebo EAC.

• EAC - Exchange Admin Center
• Mail Flow - Receive Connectors

Receive Connectors jsem popisoval pro Exchange 2010 v článku Exchange - příjem a odesílání pošty pomocí Receive Connectors a většina informací je stále platná.

Receive Connectors zpracovávají příchozí SMTP provoz, poslouchají příchozí spojení na definovaném portu se zadanými parametry. Přichází takto zprávy

• z externích serverů mimo naši Exchange organizaci
• ze služeb v Transport Pipeline na našich Exchange serverech
• od poštovních klientů, kteří nepoužívají MAPI, ale SMTP pro odeslání zpráv
• (co Microsoft ve svých popisech neuvádí, ale podle mne je to velmi důležité, je další situace) pokud máme nějaké aplikační servery, které odesílají poštu (ať na interní nebo externí adresy), tak tato komunikace jde také přes SMTP Receive Connectors

Z tohoto pohledu ovlivňuje nastavení Receive Connectors příjem pošty z internetu, ale také odesílání pošty (nejen do internetu) z našich interních serverů.

Po instalaci je automaticky vytvořeno pět defaultních Receive Connectors. Tři konektory jsou na službě Front End Transport service (Client Frontend, Default Frontend, Outbound Proxy Frontend), které slouží pro anonymní a autentizované SMTP spojení. Atribut TransportRole má hodnotu FrontendTransport. A dva na službě Transport service (Client Proxy, Default), které slouží pro autentizované a šifrované SMTP spojení z jiných transportních služeb Mailbox serveru v organizaci (nepřipojují se přímo klienti). Atribut TransportRole má hodnotu HubTransport.

Default Receive Connectors

Seznam automaticky vytvořených konektorů a jejich základních vlastností. Údaje vychází z dokumentace MS a jsou doplněny o několik dalších, které jsou podle mne důležité.

Default Frontend <ServerName> - [FrontendTransport]

• hlavní příjem pošty z internetu a dalších serverů přes SMTP
• akceptuje anonymní i autentizovaná připojení
• poslouchá na TCP 25
• obdoba Default <ServerName> na Exchange 2010
• MessageRateLimit - Unlimited
• Protocol logging - Verbose
• Authentication mechanisms - TLS, BasicAuth, BasicAuthRequireTLS, ExchangeServer, Integrated
• Permission groups - AnonymousUsers, ExchangeLegacyServers, ExchangeServers

User                              ExtendedRights                                   
----                              --------------                                   
NT AUTHORITY\ANONYMOUS LOGON      {ms-Exch-SMTP-Accept-Authoritative-Domain-Sender}
NT AUTHORITY\ANONYMOUS LOGON      {ms-Exch-SMTP-Accept-Any-Sender}                 
NT AUTHORITY\ANONYMOUS LOGON      {ms-Exch-SMTP-Submit}                            
NT AUTHORITY\ANONYMOUS LOGON      {ms-Exch-Accept-Headers-Routing}                 

Client Frontend <ServerName> - [FrontendTransport]

• autentizování SMTP klienti
• poslouchá na TCP 587
• obdoba Client <ServerName> na Exchange 2010
• MessageRateLimit - 5
• Protocol logging - None
• Authentication mechanisms - TLS, BasicAuth, BasicAuthRequireTLS, Integrated
• Permission groups - ExchangeUsers

User                              ExtendedRights                                   
----                              --------------                                   
NT AUTHORITY\Authenticated Users  {ms-Exch-SMTP-Accept-Any-Recipient}
NT AUTHORITY\Authenticated Users  {ms-Exch-Accept-Headers-Routing}   
NT AUTHORITY\Authenticated Users  {ms-Exch-Bypass-Anti-Spam}         
NT AUTHORITY\Authenticated Users  {ms-Exch-SMTP-Submit}               

Default <ServerName> - [HubTransport]

• autentizovaný příjem pošty z Front End Transport service nebo Mailbox Transport Submission service, interně přenáší zprávy pomocí SMTP
• poslouchá na TCP 2525
• MessageRateLimit - Unlimited
• Protocol logging - None
• Authentication mechanisms - TLS, BasicAuth, ExchangeServer, Integrated
• Permission groups - ExchangeLegacyServers, ExchangeServers, ExchangeUsers

User                              ExtendedRights                     
----                              --------------                     
NT AUTHORITY\Authenticated Users  {ms-Exch-SMTP-Submit}              
NT AUTHORITY\Authenticated Users  {ms-Exch-Bypass-Anti-Spam}         
NT AUTHORITY\Authenticated Users  {ms-Exch-Accept-Headers-Routing}   
NT AUTHORITY\Authenticated Users  {ms-Exch-SMTP-Accept-Any-Recipient}

Client Proxy <ServerName> - [HubTransport]

• autentizovaná spojení klientů, která jsou proxována z Front End Transport
• poslouchá na TCP 465
• MessageRateLimit - 5
• Protocol logging - None
• Authentication mechanisms - TLS, BasicAuth, BasicAuthRequireTLS, ExchangeServer, Integrated
• Permission groups - ExchangeServers, ExchangeUsers

User                              ExtendedRights                     
----                              --------------                     
NT AUTHORITY\Authenticated Users  {ms-Exch-SMTP-Submit}              
NT AUTHORITY\Authenticated Users  {ms-Exch-Bypass-Anti-Spam}         
NT AUTHORITY\Authenticated Users  {ms-Exch-Accept-Headers-Routing}   
NT AUTHORITY\Authenticated Users  {ms-Exch-SMTP-Accept-Any-Recipient}

Outbound Proxy Frontend <ServerName> - [FrontendTransport]

• pokud na Send connectoru nastavíme Proxy through CAS, tak se odesílá na tento konektor, autentizované a šifrované spojení
• poslouchá na TCP 717
• MessageRateLimit - Unlimited
• Protocol logging - None
• Authentication mechanisms - TLS, BasicAuth, BasicAuthRequireTLS, ExchangeServer, Integrated
• Permission groups - ExchangeServers

Vytváření a konfigurace konektorů

Pro běžné posílání pošty můžeme vystačit s defaultními konektory ve výchozí konfiguraci. Ale hlavně v situaci, kdy používáme nějaké aplikační servery, které mají odesílat poštovní zprávy, tak potřebujeme vytvořit nové speciální konektory či upravit nějaká nastavení. Praktické situace jsou, když aplikační server podporuje pouze určitou formu autentizace (jako Basic bez TLS) či nepodporuje autentizaci vůbec. Nebo potřebuje odesílat emaily za řadu různých emailových adres.

Na konektorech se nastavuje také logování, velikost přijímaných zpráv a další parametry. Pokud provádíme migraci, tak na původních serverech již můžeme nějaké konektory mít vytvořené. A obecně chceme konfiguraci nastavit podobně. Pro nastavení oprávnění můžeme vystačit s Permission Groups nebo musíme přímo konfigurovat Permissions (oprávnění).

Na nastavení se můžeme podívat v Exchange Admin Center nebo si podrobněji vypíšeme pomocí Exchange Management Shell, kde si můžeme zobrazit všechny konektory, konektory na určitém serveru nebo detaily určitého konektoru.

Get-ReceiveConnector
Get-ReceiveConnector -Server MAILOLD
Get-ReceiveConnector -Identity "MAILOLD\Default MAILOLD" | FL *

Také si můžeme vypsat detailní oprávnění (ta nejzajímavější):

PS C:\>Get-ReceiveConnector -Identity "MAIL1\Default Frontend MAIL1" | Get-ADPermission |
 Where-Object {$_.IsInherited -eq $false -and $_.User -ilike "NT*"} | Sort-Object User |
 FT User, ExtendedRights

User                              ExtendedRights                                   
----                              --------------                                   
NT AUTHORITY\ANONYMOUS LOGON      {ms-Exch-SMTP-Accept-Authoritative-Domain-Sender}
NT AUTHORITY\ANONYMOUS LOGON      {ms-Exch-SMTP-Accept-Any-Sender}                 
NT AUTHORITY\ANONYMOUS LOGON      {ms-Exch-SMTP-Submit}                            
NT AUTHORITY\ANONYMOUS LOGON      {ms-Exch-Accept-Headers-Routing}                 
NT AUTHORITY\Authenticated Users  {ms-Exch-Bypass-Anti-Spam}                       
NT AUTHORITY\Authenticated Users  {ms-Exch-Accept-Headers-Routing}                 
NT AUTHORITY\Authenticated Users  {ms-Exch-SMTP-Submit}                            
NT AUTHORITY\Authenticated Users  {ms-Exch-SMTP-Accept-Any-Recipient}

Nové speciální konektory můžeme vytvořit ručně nebo vyzkoušet nějaký skript pro kopírování, kterých najdeme řadu na internetu. Příklad je Copy a receive connector from one Exchange Server to multiple Exchange Servers, pokud chceme přenášet oprávnění, tak musíme použít parametr CopyPermissions. Stejně tak si můžeme připravit skript, který kopíruje oprávnění z jednoho konektoru na jiný konektor nebo server. Příklad jak kopírovat oprávnění:

$sourcePermissions = Get-ReceiveConnector -Identity "MAIL1\Connector pro AS MAIL1" | Get-ADPermission |
 Where-Object {$_.IsInherited -eq $false -and $_.User -ilike "NT*"}
$sourcePermissions | ForEach-Object {
  Get-ReceiveConnector "MAIL2\Connector pro AS MAIL2" | 
    Add-ADPermission -User $_.User -Deny:$_.Deny -AccessRights $_.AccessRights -ExtendedRights $_.ExtendedRights
}

Pozn.: Pokud máme více serverů, které chceme, aby byly zástupné (a budou třeba dostupné pod stejným DNS jménem), tak nesmíme zapomenout provést stejnou konfiguraci konektorů na všech.

Konektory a maily z aplikačních serverů

Pokud chceme odesílat emaily z nějaké aplikace, tak standardně použijeme adresu poštovního serveru a port 25. Tím se připojíme na konektor Default Frontend <ServerName>, který standardně povolí anonymní připojení (to potřebujeme pro příjem mailů z internetu) a akceptuje emaily s libovolnou adresou odesílatele, které jsou určeny příjemcům v organizaci (Authoritative Domain).

Často potřebujeme posílat emaily také mimo organizaci. Pak můžeme vytvořit nový konektor, který ovšem musí poslouchat na jiném portu nebo přijímat spojení pouze od určitých IP adres. Nebo můžeme upravit defaultní konektor a přidat k němu Permission group Exchange Users se standardními právy, kdy ověřený uživatel může odesílat ze své adresy na libovolné příjemce.

Další situace z praxe je, že máme špatné aplikace, které jako autentizaci podporují pouze Basic, kdy se přihlašovací údaje odesílají v čistém textu. Nebo ještě hůře nepodporují autentizaci vůbec. Pak je řešením vytvořit nový konektor, který omezíme na příjem pošty pouze z IP adresy daného serveru, a u něj nastavíme speciálním způsobem autentizaci a práva.

Takto to jednoduše, přehledně a (podle mne i) bezpečně fungovalo na Exchange Server 2010. Když takto nastavíme Exchange Server 2016, tak se vše tváří OK, ale začneme narážet na různé problémy, které jsou popsány v další kapitole. Důvod je ten, že zprávy přijme Receive Connector na Frontend Transport, který jsme vytvořili a nějak nastavili. Pokud zpráva splňuje parametry, tak projde, ale je předána na další konektor na Hub Transport. A ten již má jinou konfiguraci, která například omezuje počet zpráv za minutu nebo nedovoluje odeslat za jiného odesílatele.

Client Proxy

Pokud posíláme zprávu skrze Default Frontend konektor (nebo i jiný) a klient se přihlašuje (AUTH LOGIN), tak dojde k proxování na konektor Client Proxy. A teprve tento konektor zpracovává údaje o odesílateli (MAIL FROM) a příjemci (RCPT TO). Jeho nastavení povoluje pouze autentizované uživatele a odesílání libovolným příjemcům. Pokud vytvoříme speciální konektor pro nějaký server, kde povolíme pro autentizované uživatele odesílat za libovolnou adresu, tak stejně komunikace dojde na konektor Client Proxy a zde se vrátí chyba, že není povoleno odesílat za jiného odesílatele. Pokud upravíme nastavení konektoru Client Proxy, tak ovlivníme všechna autentizovaná připojení (i když musí komunikace nejprve projít skrze Frontend Transport konektor).

Default

Zajímavé je, že pokud vytvoříme konektor, kde povolíme anonymní uživatele (tedy bez přihlášení) a nastavíme oprávnění odesílat za libovolnou adresu. Tak údaje o odesílateli a příjemci zpracovává přímo tento konektor. Takže ověření odesílatele projde, i když je spojení dále proxováno na konektor Default.

Problémy s odesíláním pošty pomocí Receive Connectors

Pokud nastavíme Receive Connectors jako na Exchange 2010 a budeme odesílat poštu z nějakých aplikačních serverů, tak si brzy všimneme, že se řada zpráv nedoručila. Je jedno, zda se využívá defaultní Default Frontend SERVERNAME nebo nově vytvořený. Problémy se projevují pouze při autentizovaném SMTP připojení, anonymní funguje bez problémů. Ač je tato situace probírána na mnoha fórech, tak jsem nikde nenašel řešení. A když jsem zjistil, co je důvodem (to jsme si zmínili již v minulé kapitole), tak ani u Microsoftu se neuvádí, jak by se správně měla tato situace řešit.

Pokud má aplikační server nějaký log SMTP komunikace, tak v něm nalezneme jednu ze dvou chyb. Ty také nalezneme v protokolovém logu Exchange.

421 4.4.2 Message submission rate for this client has exceeded the configured limit

550 5.7.60 SMTP; Client does not have permissions to send as this sender

První věc je samozřejmě zkontrolovat vstupní konektor, že má nastavený neomezený počet zpráv za minutu a povoleno odesílaní za odesílatele. Další krok je podívat se do logu Front End Transport service (C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpReceive). Zde člověk narazí na rozdíl oproti Exchange 2010, protože u autentizovaných spojení se zde nenachází průběh SMTP komunikace, informace jako MAIL FROM, RCPT TO, a nenachází se zde ani chyba, kterou server vrací. Ale napovědět mohou poslední řádky spojení  

Setting up client proxy session to destination(s):
Proxy session was successfully set up. Session for user will now be proxied

Tak, jak je popsáno v Transport pipeline, tak se zprávy přijaté na Front End Transport service předávají na Transport service (HubTransport), což je konektor Client Proxy SERVERNAME. Takže se musíme podívat do logu Transport service (C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\Hub\ProtocolLog\SmtpReceive). Zde již vidíme zbytek SMTP komunikace a také hledané chyby.

Problém s limitem počtu odesílaných zpráv za minutu - Message rate limit

Dokumentace Message rate limits and throttling, Set-ThrottlingPolicy.

Jedna z chyb, kterou vrací server při pokusu o odeslání, je informace, že byl překročen limit na posílání zpráv za minutu od jednoho zdroje.

421 4.4.2 Message submission rate for this client has exceeded the configured limit

Pro kontrolu si můžeme si vypsat nastavené limity na konektorech.

[PS] C:\>Get-ReceiveConnector -Server MAIL1 | FT Name, MessageRateLimit

Name                               MessageRateLimit
----                               ----------------
Default MAIL1                      Unlimited
Client Proxy MAIL1                 5
Default Frontend MAIL1             Unlimited
Outbound Proxy Frontend MAIL1      Unlimited
Client Frontend MAIL1              5

Vidíme, že většina konektorů je neomezená. Pouze ty, které jsou určeny pro odesílání klientů, mají omezení na 5 zpráv za minutu. To je docela nízká hodnota, ale pro klienty (kteří nepoužívají MAPI) by měla být dostatečná a má chránit prostředky serveru před zahlcením. Jenže pro odesílání z nějakého aplikačního serveru je to velice málo. A jak jsme si popsali, když dojde k autentizaci, tak je zpráva předána na Client Proxy, kde je tento limit.

Toto nastavení můžeme změnit na nějakou větší hodnotu nebo neomezeno. Na zamyšlení je, proč to takto MS defaultně nastavil. Ale jelikož anonymní zprávy z internetu přichází přes konektory, které nemají omezení, tak asi není chyba ani klientský konektor nastavit neomezený.

Set-ReceiveConnector "MAIL1\Client Proxy MAIL1" -Messageratelimit unlimited

Právo odesílat za libovolnou adresu

Druhá chyba, kterou řešíme, a již jsme si také víceméně popsali, informuje, že nemáme právo odesílat za zadanou adresu.

550 5.7.60 SMTP; Client does not have permissions to send as this sender

Autentizovaný uživatel může standardně odesílat maily pouze ze své emailové adresy. Anonymní může odesílat z libovolné adresy, ale pouze na příjemce v organizaci. Občas můžeme potřebovat, aby nějaká aplikace odesílala emaily za různé adresy. Na Exchange 2010 jsme vytvořili speciální konektor, který byl omezen na adresu serveru, a měl povoleno odesílání za libovolné odesílatele na všechny adresy. Mohli bychom to povolit anonymně, ale bezpečněji vypadá využít autentizaci nějakým účtem.

Jenže na Exchange 2016 projde komunikace skrze Front End Transport service, kde jsme právo nastavili, a dojde na konektor Client Proxy SERVERNAME. Tam dané právo pro odesílání není a nastavit jej obecně by zase obešlo omezení na zdrojovou IP adresu serveru.

Vypsání práv (pospali jsme dříve) nebo nastavení provedeme pomocí Exchange Management Shell.

Get-ReceiveConnector "MAIL1\Connector pro AS MAIL1" |
 Add-ADPermission -User "NT AUTHORITY\Authenticated Users" -ExtendedRights ms-Exch-SMTP-Accept-Any-Sender

Ta hlavní práva (ExtendedRights) jsou:

• ms-Exch-SMTP-Accept-Any-Sender - povoluje odesílat maily z adresy, která nepatří do organizace
• ms-Exch-SMTP-Accept-Authoritative-Domain-Sender - povoluje odesílat maily z libovolné adresy s authoritative domain
• ms-Exch-SMTP-Accept-Any-Recipient - povoluje posílat zprávy na adresy mimo Exchange organizaci (relaying)

Situace, kdy potřebujeme, aby nějaká aplikace odesílala emaily z několika adres, by se asi měla správně řešit vytvořením speciálního účtu, kterým se budeme přihlašovat, a tomu nastavíme práva Send As na další účty s jinými adresami (může jít také o Distribution Group nebo Public Folder). Ale ne vždy to takto lze v praxi řešit.

Další možnost je, nastavit na konektor Client Proxy práva odesílat za libovolnou adresu, ne pro Authenticated Users (jak se dělá běžně), ale určitého uživatele či skupinu.

Podle testů je tu i poslední možnost, vytvořit speciální Receive Connector s omezením na IP adresu serveru a neprovádět autentizaci (ANONYMOUS LOGON).

Send Connectors

Dokumentace Send connectors.

Konfigurace pomocí Exchange Management Shell Get-SendConnector, Set-SendConnector nebo EAC.

• EAC - Exchange Admin Center
• Mail Flow - Send Connectors

Send Connectors zpracovávají odchozí SMTP provoz, odesílají zprávy mimo naši Exchange organizaci, vytváří spojení na cílové poštovní servery. Žádné defaultní konektory vytvořeny nejsou, ale existují neviditelné Send Connectors, které směrují zprávy mezi interními Exchange servery. Abychom mohli posílat poštu mimo společnost, tak musíme vytvořit Send Connector (nebo se připojit k Edge Transport serveru).

Send Connectors jsou uloženy v AD DS a jsou společné pro celou Exchange organizaci (nejsou definovány pro server jako Receive Connectors). Pokud provádíme migraci, tak nám Send Connectors již existují a potřebujeme pouze přidat nové servery mezi zdrojové pro odesílání (Source Server), a případně odstranit ty staré, aby odchozí pošta šla přes nové servery.

• EAC - Exchange Admin Center
• Mail Flow - Send Connectors
• Edit - Scoping - Source server

U Send Connectors můžeme konfigurovat několik důležitých parametrů. Často nám vystačí jeden společný konektor, ale můžeme jich vytvořit více. Nově můžeme na konektoru zapnout Proxy through client access server - Configure Send connectors to proxy outbound mail. Nastavujeme zde maximální velikost odesílaných zpráv (kvůli Base64 kódování jsou reálná data asi o 1/3 menší). Určujeme směrování pošty, buď pomocí DNS (a MX záznamů) nebo přeposíláním na Smart Host. Můžeme určit Address Space, tedy pro jaké cílové domény se použije tento konektor.

Protocol Logging - logování SMTP konverzací

Dokumentace Protocol logging.

Asi každý, kdo spravuje nějaký poštovní systém, řeší (méně nebo více často) situace, že nějaká zpráva nebyla správně doručena a je potřeba dohledat proč. Někdy můžeme použít Message Tracking, ale často je potřeba se podívat do SMTP logů (ProtocolLog).

Některé defaultní konektory mají logování zapnuté automaticky, ale většina ne (třeba Receive Connector Client Proxy neloguje, přitom je to důležité). Při vytváření nových konektorů musíme logování zapnout. Myslím, že je vhodné zapnout logování na všechny konektory. Logování můžeme jednoduše zapnout v nastavení konektoru v Exchange Admin Center, kde přepneme Protocol logging level z None na Verbose.

Standardně se provádí rotování logů (circular logging), takže se odmazávají staré. Výchozí hodnoty jsou 30 dní, velikost složky 250 MB (to je v praxi dost málo), velikost souboru 10 MB. Soubory s logy se nachází v cestě podle služby a typu konektoru. Běžně je %ExchangeInstallPath% = C:\Program Files\Microsoft\Exchange Server\V15\.

• Front End Transport service
• Receive connectors: %ExchangeInstallPath%TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpReceive
• Send connectors: %ExchangeInstallPath%TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpSend
• Transport service
• Receive connectors: %ExchangeInstallPath%TransportRoles\Logs\Hub\ProtocolLog\SmtpReceive
• Send connectors: %ExchangeInstallPath%TransportRoles\Logs\Hub\ProtocolLog\SmtpSend
• Mailbox Transport Delivery service
• Receive connectors: %ExchangeInstallPath%TransportRoles\Logs\Mailbox\ProtocolLog\SmtpReceive\Delivery
• Mailbox Transport Submission service
• Send connectors: %ExchangeInstallPath%TransportRoles\Logs\Mailbox\ProtocolLog\SmtpSend\Submission

Na Exchange Server 2010 jsou cesty:

• Send connectors: C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\ProtocolLog\SmtpSend
• Receive connectors: C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\ProtocolLog\SmtpReceive

Get-TransportService | FL Name, *ProtocolLog*
Get-FrontEndTransportService | FL Name, *ProtocolLog*

Get-TransportService | Set-TransportService -ReceiveProtocolLogMaxDirectorySize 600MB -SendProtocolLogMaxDirectorySize 600MB
Get-FrontEndTransportService | Set-FrontEndTransportService -ReceiveProtocolLogMaxDirectorySize 600MB -SendProtocolLogMaxDirectorySize 600MB

Message Tracking

Stejně tak je důležitá funkce Message Tracking, která je standardně zapnutá a ukládá logy do %ExchangeInstallPath%TransportRoles\Logs\MessageTracking. Nově mají i uživatelé možnost využít Delivery reports tab v Outlook on the web. Standardně se ukládá 30 dní, maximální velikost 1 GB.

Get-TransportService | FL Name, MessageTracking*

Get-TransportService | Set-TransportService -MessageTrackingLogMaxDirectorySize 2GB

Testování SMTP

Pro jednoduché otestování SMTP (a konektorů) se může hodit jednoduchá aplikace SMTP Diag Tool, bohužel neumí autentizaci Basic over TLS.