www.SAMURAJ-cz.com 

19.04.2024 Rostislav Translate to English by Google     VÍTEJTE V MÉM SVĚTĚ

Články

Exchange Server 2016 DSN, Message Tracking a analýza posílání zpráv

Pondělí, 15.04.2019 16:59 | Samuraj - Petr Bouška |
V praxi často potřebujeme potvrdit, že byla nějaká zpráva doručena, případně hledat problémy, proč doručena nebyla. Minule jsme nastavili logování Protocol Logging a Message Tracking. Nyní se podíváme, jak tyto logy využít pro sledování doručení zpráv a Troubleshooting. Bohužel již nemáme k dispozici nástroj Tracking Log Explorer, takže musíme využít Exchange Management Shell.

Oficiální dokumentace Message tracking, Transport logs in Exchange Server.

Message Tracking - sledování zpráv

Na Exchange Server 2010 jsme pod Toolbox našli nástroj Tracking Log Explorer, který byl velmi užitečný ke sledování doručování zpráv na serveru (Mail Flow). Tento nástroj byl součástí Exchange Troubleshooting Assistant a dal se spustit ručně C:\Program Files\Microsoft\Exchange Server\V14\Bin\ExTRA.exe -AS -PS LaunchMessageTracking.

Microsoft se rozhodl s verzí Exchange Server 2013 tento nástroj zrušit. Pokud provádíme migraci, a máme v organizaci servery s verzí 2010 i 2016, tak nám tento nástroj na Exchange 2010 vyhledává údaje i z nových serverů 2016. Vyzkoušel jsem zkopírovat soubory této aplikace na nový server, kde se následně dá spustit, ale při zobrazení výsledků spadne. Patrně by s nějakým úsilím šel rozchodit nebo by se daly nainstalovat Management Tools z Exchange 2010.

Tracking Log Explorer je vlastně GUI pro cmdlet Get-MessageTrackingLog. Microsoft uvádí, že dnes máme přímo využít Exchange Management Shell a tento příkaz. Pokud využijeme možnost zobrazení Out-GridView, tak je výsledek dost podobný, pouze zadání parametrů není tak komfortní. Když se podíváme po internetu, tak nalezneme připravené PowerShell nástroje, které by i pohodlnější zadání měly řešit, ale žádný mi nevyhovoval. Exchange message tracking GUI, Exchange 2013 Message Tracking Log GUI.

Pozn.: Určitý omezený nástroj s informacemi o doručení se nachází v EAC - mail flow - delivery reports.

Použití Get-MessageTrackingLog

Když chceme využít Message Tracking logy, tak si můžeme přímo otevřít soubory (standardní cesta C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\MessageTracking), ale jejich procházení je dost komplikované (jde o CSV formát). Proto je určitě lepší využít cmdlet Get-MessageTrackingLog, který prohledává informace o doručení zpráv z protokolu sledování zpráv (Message Tracking Log). Parsuje informace v logu a zobrazuje požadované.

Standardně se výstup zobrazí v aktuálním okně, pro další zpracování můžeme uložit do souboru ConvertTo-Csv, ale nejpraktičtější pro prohlížení vypadá Out-GridView. Cmdlet má řadu přepínačů, použít musíme pouze ty, podle kterých chceme výstup filtrovat (vyhledat). Výsledek je standardně omezen na 1000 položek, pokud chceme vracet vše, tak musíme použít přepínač ResultSize. Základní filtrování bývá časový interval pomocí Start a End, zde je malý problém se zápisem data. V dokumentaci se uvádí, že záleží na regionálním nastavení, ale při Czech se nedá použít český formát dd.MM.yyyy HH:mm, ale musí se používat MM.dd.yyyy HH:mm (tedy přehozený den a měsíc).

Pozn.: V některých příkladech níže se používá speciální znak ` pro rozdělení řádku (příkazu), aby se lépe zobrazilo na webu (a běžně může následovat odřádkování po | a ,).

Základní příklad všech zpráv v určitém časovém intervalu (10. 4. 2019 14:00 až 14:01), druhá varianta za poslední hodinu.

Get-MessageTrackingLog -Start "4.10.2019 14:00" -End "4.10.2019 14:01" -ResultSize unlimited | Out-GridView
Get-MessageTrackingLog -Start (Get-Date).AddHours(-1) -End (Get-Date) -ResultSize unlimited | Out-GridView

Nejčastěji filtrujeme podle příjemce nebo odesílatele (nebo podle obou).

Get-MessageTrackingLog -Sender bouska@firma.cz -Start "4.10.2019 10:00" -End "4.10.2019 15:00" -ResultSize unlimited |
 Out-GridView
Get-MessageTrackingLog -Recipients bouska@firma.cz -Start "4.10.2019 10:00" -End "4.10.2019 15:00" -ResultSize unlimited |
 Out-GridView

Další parametr pro filtrování je předmět zprávy, kde se hledá zadaná část textu (nepotřebujeme používat hvězdičku nebo podobně).

Get-MessageTrackingLog -MessageSubject "PROBLEM" -Start "4.10.2019 10:00" -End "4.10.2019 15:00" -ResultSize unlimited |
 Out-GridView

Filtrovat můžeme podle řady dalších parametrů, jako je EventId, InternalMessageId, MessageId, NetworkMessageId, Reference a Source. Pomocí MessageId si můžeme vypsat všechny události k jedné zprávě (některé události mají v položce Reference odkaz na zprávu z které vznikli).

Get-MessageTrackingLog -MessageId "<9c5dc7b8a86cd65dd31c639d29f2505e@www.neco.cz>" -Start "4.10.2019 10:00" `
 -End "4.10.2019 15:00" -ResultSize unlimited | Out-GridView

Pokud se chceme ptát jiného než lokálního serveru, tak přidáme parametr Server.

Get-MessageTrackingLog -Server mail2 -Recipients bouska@firma.cz -Start "4.10.2019 10:00" -End "4.10.2019 15:00" `
 -ResultSize unlimited | Out-GridView

Další věc je volba položek (vlastností, sloupců), které se mají zobrazit ve výstupu. Jejich popis je ve Fields in the message tracking log files.

Get-MessageTrackingLog -Recipients bouska@firma.cz -Start "4.10.2019 10:00" -End "4.10.2019 15:00" -ResultSize unlimited |
 Select-Object Timestamp, EventId, Source, Sender, Recipients, MessageSubject, ClientIp, OriginalClientIp, ClientHostname,
 ServerIp, ServerHostname, RecipientStatus | Out-GridView

Druhá varianta, kde je ještě více údajů ve výstupu.

Get-MessageTrackingLog -Recipients bouska@firma.cz -Start "4.10.2019 10:00" -End "4.10.2019 15:00" -ResultSize unlimited |
 Select-Object Timestamp, EventId, Source, Sender, Recipients, MessageSubject, ClientIp, OriginalClientIp, ClientHostname,
 ServerIp, ServerHostname, RecipientStatus, TotalBytes, RecipientCount, RelatedRecipientAddress, MessageId, ConnectorId,
 Directionality | Out-GridView

Případně můžeme přidat řazení (ale v GridView můžeme řadit dynamicky).

Get-MessageTrackingLog -Recipients bouska@firma.cz -Start "4.10.2019 10:00" -End "4.10.2019 15:00" -ResultSize unlimited |
 Select-Object Timestamp, EventId, Source, Sender, Recipients, MessageSubject, ClientIp, OriginalClientIp, ClientHostname,
 ServerIp, ServerHostname, RecipientStatus | Sort-Object Timestamp | Out-GridView

Komplexní příkaz, který je rozdělený na více řádků (pro přehlednost). Upravíme hodnoty, podle kterých chceme vyhledávat, a odmažeme řádky s parametry, které nepoužijeme. 

Get-MessageTrackingLog `
 -Server mail2 `
 -Start "4.10.2019 10:00" -End "4.10.2019 15:00" `
 -Sender bouska@firma.cz `
 -Recipients bouska@firma.cz `
 -MessageSubject "PROBLEM" `
 -ResultSize unlimited `
 | Select-Object Timestamp, EventId, Source, Sender, Recipients, MessageSubject, ClientIp, OriginalClientIp, ClientHostname,
    ServerIp, ServerHostname, RecipientStatus `
 | Sort-Object Timestamp `
 | Out-GridView

Další úprava, pokud máme více Exchange serverů, tak většinou chceme hledat průchod zprávy na všech. Pro výrazné zrychlení vykonání na více serverech použijeme příkaz Invoke-Command (rada z článku Speed Up Multi-Server Message Tracking Log Searches with PowerShell Remoting).

Get-TransportService | Invoke-Command {
 Get-MessageTrackingLog `
  -Start "4.10.2019 10:00" -End "4.10.2019 15:00" `
  -Sender bouska@firma.cz `
  -Recipients bouska@firma.cz `
  -MessageSubject "PROBLEM" `
  -MessageId "<9c5dc7b8a86cd65dd31c639d29f2505e@www.neco.cz>" `
  -ResultSize unlimited `
  | Select-Object Timestamp, EventId, Source, Sender, Recipients, MessageSubject, ClientIp, OriginalClientIp, ClientHostname,
     ServerIp, ServerHostname, RecipientStatus, TotalBytes, RecipientCount, RelatedRecipientAddress, MessageId, ConnectorId,
     Directionality `
  | Sort-Object Timestamp `
  | Out-GridView
}

Typy událostí (EventID) a zdroje (Source)

Dokumentace Source values in the message tracking log, Event types in the message tracking log

Každá zpráva vygeneruje v Message Tracking logu celou řadu událostí. Pro identifikaci události můžeme využít položky Source a EventId.

Source identifikuje, jaká transportní komponenta byla zodpovědná za danou událost. Nejčastější jsou

  • SMTP - SMTP odesílání nebo příjem (Transport Service)
  • STOREDRIVER - MAPI pro schránku na lokálním serveru
  • ROUTING - směrování (Transport Service)
  • AGENT - Transport Agent
  • PUBLICFOLDER - mail-enabled Public Folder
  • DSN - Delivery Status Notification

EventId určuje typ události v logu. Nejčastější jsou

  • SEND - odesláno pomocí SMTP mezi transportními službami
  • SENDEXTERNAL - nová událost, mělo by jít o SMTP odeslání mimo organizaci, chybí v oficiálním popisu
  • RECEIVE - zpráva přijata pomocí SMTP transportní služby nebo ze složky Pickup či Replay (Source: SMTP), nebo byla odeslána ze schránky do Mailbox Transport Submission service (Source: STOREDRIVER)
  • DELIVER - doručeno do lokální schránky
  • AGENTINFO - používá Transport Agent, třeba pro záznam Transport Rule (How to Tell Which Transport Rule Was Applied to an Email Message)
  • HAREDIRECT - vytvořena Shadow Message (Shadow redundancy in Exchange Server)
  • HARECEIVE - Shadow Message byla přijata serverem v lokáním DAGu nebo Site
  • EXPAND - expand Distribution Group, skupina byla nahrazena adresami členů
  • DROP - zpráva byla zahozena (drop) bez DSN
  • DSN - byla generována Delivery Status Notification (DSN)
  • FAIL - doručení selhalo
  • SUBMIT - služba Mailbox Transport Submission předala úspěšně zprávu transportní službě

Výpis zpráv o nedoručení, DSN a chyb

Mimo hledání určitých zpráv, kde chceme ověřit stav doručení, se můžeme občas podívat na nějaké chybové stavy.

Jedna možnost je vypsat si za nějaké období události FAIL, že selhalo doručení. To může být neexistující příjemce nebo celá doména, chyba komunikace s cílovým SMTP serverem, apod. Položka RecipientStatus ukazuje, k jaké chybě došlo. Můžeme tak nalézt zapomenuté adresy na aplikačních serverech, na které se stále snaží odesílat.

Get-TransportService | Invoke-Command {
 Get-MessageTrackingLog -EventId FAIL -Start "4.10.2019 0:00" -End "4.10.2019 23:59" -ResultSize unlimited |
 Select-Object Timestamp, EventId, Source, Sender, Recipients, RecipientStatus, MessageSubject, ClientIp, OriginalClientIp,
 ClientHostname, ServerIp, ServerHostname, MessageId, ConnectorId, Directionality | Out-GridView
}

Můžeme si vypsat zprávy Delivery Status Notifications (DSN), buď podle zdroje (Source: DSN) nebo přímo událost (EventId: DSN).

Get-TransportService | Invoke-Command {
 Get-MessageTrackingLog -Source DSN -Start "4.10.2019 0:00" -End "4.10.2019 23:59" -ResultSize unlimited |
 Select-Object Timestamp, EventId, Source, Sender, Recipients, RecipientStatus, MessageSubject, ClientIp, OriginalClientIp,
 ClientHostname, ServerIp, ServerHostname, MessageId, ConnectorId, Directionality | Out-GridView
}

DSN nám zobrazí zprávy o nedoručení, které generoval náš server. Podle předmětu zprávy můžeme najít příchozí zprávy zvenku. Použijeme parametr MessageSubject a "Undeliverable" nebo "Nedoručitelná". Kdybychom chtěli obě varianty jedním příkazem, tak bychom museli použít Where-Object (Searching Message Tracking Logs by Email Subject).

Get-TransportService | Invoke-Command {
 Get-MessageTrackingLog -MessageSubject "Undeliverable" -Start "4.10.2019 0:00" -End "4.10.2019 23:59" `
 -ResultSize unlimited | Select-Object Timestamp, EventId, Source, Sender, Recipients, RecipientStatus,
 MessageSubject, ClientIp, OriginalClientIp, ClientHostname, ServerIp, ServerHostname, MessageId, ConnectorId,
 Directionality | Out-GridView
}

Statistiky o posílání zpráv

Message Tracking logy můžeme také využít k vytváření statistik o mailové komunikaci v organizaci. Pro Exchange 2010 jsem napsal článek Exchange server a statistiky posílání zpráv, kde jsem do druhé poloviny doplnil aktualizaci na Exchange 2016.

Opakované doručování zpráv, DSN a NDR

Pokud se Exchange Server snaží doručit zprávu, tak se spojuje s cílovým SMTP serverem a předává mu mail pro jeho příjemce. Mohou nastat tři situace

  • zpráva se doručí - naváže se SMTP spojení a server zprávu přijme
  • zpráva se nedoručí - dojde k chybě, třeba neexistuje MX záznam (poštovní server) pro doménu, cílový server zprávu odmítne (neexistující příjemce, překročení limitu), do Message Tracking logu se vloží FAIL a odesílateli se pošle chyba (NDR)
  • zpráva se odloží - pokud se nepovede navázat SMTP spojení na cílový server, tak se Exchange snaží o pozdější doručení (dle nastavení), v tu chvíli se nic nevloží do Message Tracking logu ani se neinformuje odesílatel

Pokud se serveru nedaří doručit zprávu, tak probíhá Retry - nový pokus o spojení s cílem nebo Resubmit - nové zpracování (Submission queue). Zpráva expiruje (Expires) pokud všechny pokusy o doručení, v zadaném čase, selžou. Pak se odesílá informace odesílateli a zpráva se smaže z fronty.

Pokud se Exchange serveru nedaří spojit s Next Hop (dalším poštovním serverem), tak se fronta nastaví do stavu Retry a pokusy o spojení pokračují, dokud se zpráva nedoručí nebo neexpiruje. Konfigurace intervalů je popsána v Message retry, resubmit, and expiration intervals.

Odesílateli se pošle informace o zpoždění odeslání zprávy (že se dále bude snažit odeslat) - Delay Delivery Status Notification (Delay DSN), ale to se neposílá hned, ale až po Delay notification timeout. Tento interval je defaultně 4 hodiny a samozřejmě se zpráva posílá, pouze pokud se v té době nepodaří doručit. Tuto hodnotu můžeme změnit, standardně by neměla být menší než 30 minut (záleží na Retry parametrech). Využijeme buď cmdlet Set-TransportService nebo Exchange Admin Center a nastavení transportních limitů na serveru.

Exchange nastavení Delay notification timeout

Pokud se nepodaří zprávu doručit, tak se odesílateli pošle zpráva Non-Delivery Report (NDR). Ta obsahuje chybovou zprávu, včetně kódu, proč se doručení nezdařilo (Undeliverable - Nedoručitelná).

Zprávy o chybě doručení se vrací zpět odesílateli (Bounce Message) a patří do kategorie DSN. Jde o Delivery Status Notification (DSN) a Non-Delivery Report (NDR). Mezi DSN jsou zprávy o potvrzení doručení příjemci, potvrzení přečtení, zpoždění doručení (Delivery delayed - Doručení se zpozdilo). Více informací DSNs and NDRs in Exchange Server, Sent email in Outlook.com comes back "delivery failed".

Několik příkladů zpráv

Odeslaná zpráva na doménu, kde je nedostupný SMTP server. Nejprve přijde DSN o zpoždění.

Delivery delayed: Předmět

Delivery is delayed to these recipients or groups:
někdo@neodpovídající.doména (někdo@neodpovídající.doména)
Subject: Předmět

This message hasn't been delivered yet. Delivery will continue to be attempted.
The server will keep trying to deliver this message for the next 1 days, 22 hours and 56 minutes. You'll be notified if the
 message can't be delivered by that time.

Server at neodpovídající.doména (x.x.x.x) returned '400 4.4.7 Message delayed'
11.02.2019 14:27:11 - Server at neodpovídající.doména (x.x.x.x) returned '451 4.4.397 Error communicating with target host.
 -> 421 4.2.1 Unable to connect -> SocketTimedout: Socket error code 10060'

Pokud dojde k expiraci, tak se odešle i NDR o nedoručení.

Undeliverable: Předmět

Delivery has failed to these recipients or groups:
někdo@neodpovídající.doména(někdo@neodpovídající.doména)

Several attempts to deliver your message were unsuccessful and we stopped trying. It could be a temporary situation. Try to
 send your message again later.

13.02.2019 13:44:15 - Server at mail1.firma.local returned '550 5.4.300 Message expired -> 451 4.4.397 Error communicating
 with target host. -> 421 4.2.1 Unable to connect -> SocketTimedout: Socket error code 10060'
13.02.2019 13:40:25 - Server at neodpovídající.doména (x.x.x.x) returned '451 4.4.397 Error communicating with target host.
 -> 421 4.2.1 Unable to connect -> SocketTimedout: Socket error code 10060'

Odeslání zprávy pro neexistujícího příjemce.

Undeliverable: Předmět

Delivery has failed to these recipients or groups:
neexistující-uživatel@firma2.cz (neexistující-uživatel@firma2.cz)

The email address you entered couldn't be found. Please check the recipient's email address and try to resend the message.
 If the problem continues, please contact your email admin.

Remote Server returned '550 5.1.10 RESOLVER.ADR.RecipientNotFound; Recipient not found by SMTP address lookup'

Odeslání zprávy na neexistující doménu.

Undeliverable: Předmět

Delivery has failed to these recipients or groups:
někdo@neexistující.doména (někdo@neexistující.doména)

A problem occurred and this message couldn't be delivered. Check to be sure the email address is correct. If the problem
 continues, please contact your email admin

Remote Server returned '554 5.4.4 SMTPSEND.DNS.NonExistentDomain; nonexistent domain test.local -> DnsDomainDoesNotExist:
 InfoDomainNonexistent'

Troubleshooting doručení zprávy

Pokud potřebujeme nalézt informace o nedoručené zprávě, tak ne vždy vystačíme s logem sledování zpráv (Message Tracking Log), ale musíme využít i protokolové logy (Protocol Log) či další.

Prohledání logu sledování zpráv - Message Tracking

Jako první využijeme Message Tracking a cmdlet Get-MessageTrackingLog, jak jsme si popsali výše. Pokud hledanou zprávu nalezneme, tak by měla obsahovat několik událostí - záznamů v logu.

Níže jsou příklady z praxe, pro konfiguraci, kde je více Exchange serverů a DAG, které ukazují jaké události nastávají. Pokud si chceme vypsat pořadí událostí, tak musíme čas zobrazit včetně milisekund. Když vypisujeme události z více serverů, tak přesto nemusí být ve správném pořadí (patrně kvůli malým nepřesnostem času), ale i v rámci jednoho serveru jsou dvě stejné události zalogovány v různém pořadí u různých zpráv.

Get-TransportService | Invoke-Command { 
 Get-MessageTrackingLog -MessageId "<9c5dc7b8a86cd65dd31c639d29f2505e@www.neco.cz>" -Start "4.10.2019 0:00" -End "4.10.2019 20:01" `
  -ResultSize unlimited | Sort-Object Timestamp | FT @{label=’Timestamp [ms]’;Expression={"{0:dd.MM.yyyy HH:mm:ss.fff}" -f $_.Timestamp}},
  EventId, Source, Sender, Recipients, OriginalClientIp, ClientHostname, ServerHostname 
}

Běžné události (EventId - Source) - odesílatel má schránku na Exchange serveru, příjemce mimo firmu

  • RECEIVE - STOREDRIVER
  • HAREDIRECT - SMTP
  • RECEIVE - SMTP
  • HARECEIVE - SMTP
  • SUBMIT - STOREDRIVER
  • AGENTINFO - AGENT
  • TRANSFER - ROUTING
  • SENDEXTERNAL - SMTP
  • HADISCARD - SMTP

Běžné události (EventId - Source) - odesílatel se připojuje přes SMTP (z internetu nebo aplikačního serveru), příjemce na Exchange serveru

  • RECEIVE - SMTP
  • HAREDIRECT - SMTP
  • HARECEIVE - SMTP
  • AGENTINFO - AGENT
  • SEND - SMTP
  • DELIVER - STOREDRIVER
  • HADISCARD - SMTP

Běžné události (EventId - Source) - odesílatel i příjemce mají schránku na Exchange serveru

  • RECEIVE - STOREDRIVER
  • HAREDIRECT - SMTP
  • RECEIVE - SMTP
  • HARECEIVE - SMTP
  • SUBMIT - STOREDRIVER
  • AGENTINFO - AGENT
  • SEND - SMTP
  • DELIVER - STOREDRIVER
  • HADISCARD - SMTP

Pokud nastane problém, tak místo události SEND můžeme nalézt FAIL, kde je v položce RecipientStatus důvod.

Timestamp               EventId    Source      RecipientStatus
---------               -------    ------      ---------------
15.04.2019 08:59:58.084 RECEIVE    STOREDRIVER {To}
15.04.2019 08:59:58.244 HAREDIRECT SMTP        {}
15.04.2019 08:59:58.245 RECEIVE    SMTP        {}
15.04.2019 08:59:58.261 HARECEIVE  SMTP        {}
15.04.2019 08:59:58.274 SUBMIT     STOREDRIVER {}
15.04.2019 08:59:58.366 AGENTINFO  AGENT       {}
15.04.2019 08:59:58.379 TRANSFER   ROUTING     {}
15.04.2019 08:59:58.415 FAIL       DNS         {[{LED=554 5.4.4 SMTPSEND.DNS.NonExistentDomain; nonexistent domain...
15.04.2019 09:01:11.185 HADISCARD  SMTP        {}

Protocol Log Receive Connector - SmtpReceive

Pokud zprávu vůbec nevidíme v Message Tracking, tak je pravděpodobně problém již s jejím přijetím (od externího serveru či SMTP aplikace) a musíme se podívat do SmtpReceive logu služby

  • Front End Transport service - C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpReceive

Struktura logu je podrobně popsána v Protocol logging. Každý řádek začíná časem, názvem konektoru, ID session, číslem sekvence v dané session, lokální a vzdálená IP a port, speciální znak určující typ události (> Send, < Receive, + Connect, - Disconnect, * Info), pak následují informace pro danou událost. Příklad

2019-04-14T09:02:00.263Z,MAIL1\Default Frontend MAIL1,08D6B79E841C352B,2,10.0.0.100:25,10.0.0.10:57110,<,EHLO app.firma.local

Při standardním odesílání zprávy přes SMTP bez autentizace bychom ve FrontEnd logu měli nalézt dané připojení (dle času, IP adresy, jména, adres, apod.). Jednotlivé řádky obsahují různé události a zobrazují SMTP příkazy od klienta i odpovědi serveru. Běžně jde o:

  • EHLO
  • MAIL FROM
  • RCPT TO
  • DATA
  • QUIT

Ukázka části logu:

+,,
>,"220 mail1.firma.local Microsoft ESMTP MAIL Service ready at Wed, 9 Jan 2019 13:59:59 +0100",
<,EHLO app.firma.local,
>,250  MAIL1.firma.local Hello [10.0.0.10] SIZE 51380224 PIPELINING DSN ENHANCEDSTATUSCODES STARTTLS X-ANONYMOUSTLS AUTH NTLM
 X-EXPS GSSAPI NTLM 8BITMIME BINARYMIME CHUNKING XRDST,
<,MAIL FROM:<noreply@firma.cz>,
*,08D665F9FACC16F2;2019-01-09T13:00:00.103Z;1,receiving message
>,250 2.1.0 Sender OK,
<,RCPT TO:<bouska@firma.cz>,
>,250 2.1.5 Recipient OK,
<,DATA,
>,354 Start mail input; end with <CRLF>.<CRLF>,
*,,Proxy destination(s) obtained from OnProxyInboundMessage event. Correlation Id:bbfc4680-4b9d-4c6e-aded-a6e1eba1b55b
>,"250 2.6.0 <1333627227.163.1555072241326@app.firma.local> [InternalId=46789373723132, Hostname=mail.firma.local] 1988
 bytes in 0.134, 14,475 KB/sec Queued mail for delivery",
<,QUIT
>,221 2.0.0 Service closing transmission channel,
-,,Local

Na některém řádku se může nacházet chyba, pokud nějaký příkaz selhal a zpráva nebyla přijata ke zpracování.

>,550 5.7.54 SMTP; Unable to relay recipient in non-accepted domain

Nebo informace, že byla zpráva zařazena do fronty.

>,"250 2.6.0  ...  Queued mail for delivery"

Pokud odesíláme zprávu přes SMTP s autentizací, tak ve FrontEnd logu nalezneme pouze pár SMTP příkazů. Jedním z nich může být navázání šifrování (STARTTLS).

  • EHLO
  • (STARTTLS)
  • AUTH LOGIN

Ukázka části logu:

+,,
>,"220 mail1.firma.local,
<,EHLO app.firma.local,
>,250  mail1.firma.local Hello [10.0.0.10] SIZE 51380224 PIPELINING DSN ENHANCEDSTATUSCODES AUTH LOGIN 8BITMIME BINARYMIME,
<,AUTH LOGIN,
>,334 <authentication response>,
>,334 <authentication response>,
*,SMTPSubmit SMTPAcceptAnyRecipient BypassAntiSpam AcceptRoutingHeaders,Set Session Permissions
*,username,authenticated
*,,ASyncBackendLocator.BeginGetDatabaseToServerMappingInfo.
*,,AsyncBackendLocator.EndGetDatabaseToServerMappingInfo
*,,Setting up client proxy session to destination(s): mail1.firma.local;mail2.firma.local
*,,Proxy session was successfully set up. Session forusername will now be proxied
>,235 2.7.0 Authentication successful,
-,,Local

Chybu zde nalezneme, pokud dojde ke špatné autentizaci nebo problému s TLS. 

*,,Inbound authentication failed as we reject well-known account authentication for NT AUTHORITY\ANONYMOUS LOGON
*,Tarpit for '0.00:00:05' due to '535 5.7.3 Authentication unsuccessful'

*,,TLS negotiation failed with error CertUnknown

Pro pokračování se musíme podívat do Hub logu:

  • Transport service (Hub) - C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\Hub\ProtocolLog\SmtpReceive

Zde je pokračování SMTP komunikace. Nejprve se naváže spojení mezi službami Exchange serveru (FrontEnd a Hub) a pak pokračuje klient:

  • MAIL FROM
  • RCPT TO
  • DATA
  • QUIT

Ukázka části logu:

+,,
>,"220 mail1.firma.local,
<,EHLO mail1.firma.local,
>,250  mail1.firma.local Hello [10.0.0.100] SIZE 51380224 PIPELINING DSN ENHANCEDSTATUSCODES STARTTLS X-ANONYMOUSTLS AUTH
 GSSAPI NTLM X-EXPS GSSAPI NTLM 8BITMIME BINARYMIME CHUNKING XEXCH50 XRDST XSHADOWREQUEST,
<,X-ANONYMOUSTLS,
>,220 2.0.0 SMTP server ready,
*,"CN=mail1.firma.local ... ",Sending certificate Subject Issuer name Serial number Thumbprint Not before ...
*,,"TLS protocol SP_PROT_TLS1_2_SERVER negotiation succeeded using bulk encryption algorithm CALG_AES_256 with strength ..."
<,EHLO mail1.firma.local,
>,250  mail1.firma.local Hello [10.0.0.100] SIZE 51380224 PIPELINING DSN ENHANCEDSTATUSCODES AUTH GSSAPI NTLM LOGIN X-EXPS
 EXCHANGEAUTH GSSAPI NTLM X-EXCHANGEAUTH SHA256 8BITMIME BINARYMIME CHUNKING XEXCH50 XRDST XSHADOWREQUEST XPROXY XPROXYFROM
 X-MESSAGECONTEXT ADRC-2.1.0.0 EPROP-1.2.0.0 XSYSPROBE XORIGFROM XMESSAGEVALUE,
<,X-EXPS EXCHANGEAUTH,
*,SMTPSubmit SMTPSubmitForMLS SMTPAcceptAnyRecipient SMTPAcceptAuthenticationFlag SMTPAcceptAnySender ...
*,NT AUTHORITY\SYSTEM,authenticated
>,235 <authentication response>,
<,XPROXY SID=08D665F9FACC1715 IP=10.0.0.10 PORT=54454 DOMAIN=app.firma.local CAPABILITIES=0 SECID=...
*,None,Set Session Permissions
*,SMTPSubmit SMTPAcceptAnyRecipient BypassAntiSpam AcceptRoutingHeaders,Set Session Permissions
>,250 XProxy accepted and authenticated,
<,MAIL FROM:<noreply@firma.cz>,
*,08D665FA1D55847F;2019-01-09T13:00:12.980Z;1,receiving message
>,250 2.1.0 Sender OK,
<,RCPT TO:<bouska@firma.cz>,
>,250 2.1.5 Recipient OK,
<,DATA,
>,354 Start mail input; end with <CRLF>.<CRLF>,
*,,receiving message with InternetMessageId <1063563420.01547038812805.JavaMail.kom@app.firma.local>
>,"250 2.6.0 <1063563420.01547038812805.JavaMail.kom@app.firma.local > [InternalId=372073016852, Hostname=mail1.firma.local]
 101890 bytes in 0.193, 513,334 KB/sec Queued mail for delivery",
<,QUIT,
>,221 2.0.0 Service closing transmission channel,
-,,Local

Zde můžeme nalézt stejné chyby, jako ve FrontEnd logu.

>,550 5.7.60 SMTP; Client does not have permissions to send as this sender
>,421 4.4.2 Message submission rate for this client has exceeded the configured limit

Protocol Log Send Connector - SmtpSend

Jedna z praktických situací je, že je zpráva korektně přijata (SmtpReceive). V Message Tracking logu ji nalezneme, ale v událostech chybí SEND, SENDEXTERNAL nebo i FAIL. Poslední zalogovaná událost je AGENTINFO. Pak se musíme podívat do SmtpSend logů.

  • Front End Transport service - C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpSend
  • Transport service (Hub) - C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\Hub\ProtocolLog\SmtpSend

Zde můžeme, při pokusu odeslat danou zprávu, nalézt například chybu:

*,,"Failed to connect. Winsock error code: 10060, Win32 error code: 10060, Destination domain: firma2.cz, Error Message: A
 connection attempt failed because the connected party did not properly respond after a period of time, or established
 connection failed because connected host has failed to respond 1.2.3.4:25."

To nám napoví, že jde o situaci popsanou výše v Opakované doručování zpráv, DSN a NDR a budou následovat další pokusy o doručení zprávy.

zobrazeno: 14599krát | Komentáře [0]

Autor:

Související články:

Microsoft Exchange

Jednou částí mé práce je administrace poštovního serveru od firmy Microsoft, tedy Exchange Serveru. Články začínají u verze 2003 a jak jde čas, tak pokračují dále.

Migrace Exchange organizace 2010 na 2016

Prováděl jsem migraci organizace z Exchange Server 2010 na Exchange Server 2016. Celý proces byl dost náročný a dlouhý (i se studiem mi trval 4 měsíce). V průběhu jsem narazil na množství problémů, chyb a nedostatků (i v oficiální dokumentaci). Ze svých poznámek vytvářím tuto sérii. Nejde o kompletní návod na přechod, ale o hlavní body a zmínky problémů, na které jsem narazil. Jednotlivé články popisují různé oblasti Exchange Server 2016, takže nejde pouze o přechod ze starší verze, ale hodí se i pro novou instalaci či správu.

Pokud se chcete vyjádřit k tomuto článku, využijte komentáře níže.

Komentáře

Zatím tento záznam nikdo nekomentoval.

Přidat komentář

Vložit tag: strong em link

Vložit smajlík: :-) ;-) :-( :-O

Nápověda:
  • maximální délka komentáře je 2000 znaků
  • HTML tagy nejsou povoleny (budou odstraněny), použít se mohou pouze speciální tagy (jsou uvedeny nad vstupním polem)
  • nový řádek (ENTER) ukončí odstavec a začne nový
  • pokud odpovídáte na jiný komentář, vložte na začátek odstavce (řádku) číslo komentáře v hranatých závorkách