Official Documentation Message tracking, Transport logs in Exchange Server.
Message Tracking
In Exchange Server 2010, we found the Tracking Log Explorer tool under the Toolbox, which was very useful for tracking message delivery on the server (Mail Flow). This tool was part of the Exchange Troubleshooting Assistant and could be launched manually with the command C:\Program Files\Microsoft\Exchange Server\V14\Bin\ExTRA.exe -AS -PS LaunchMessageTracking.
Microsoft decided to remove this tool in Exchange Server 2013. If we are performing a migration and have servers with version 2010 and 2016 in the organization, this tool on Exchange 2010 will also search for data from the new 2016 servers. I tried to copy the files of this application to the new server, where it can then be launched, but it crashes when displaying the results. Apparently, it could be made to work with some effort, or the Management Tools from Exchange 2010 could be installed.
Tracking Log Explorer is actually a GUI for the cmdlet Get-MessageTrackingLog. Microsoft states that today we should directly use the Exchange Management Shell and this cmdlet. If we use the Out-GridView option, the result is quite similar, but the parameter input is not as comfortable. When we look on the internet, we find prepared PowerShell tools that should also provide more comfortable input, but none of them suited me. Exchange message tracking GUI, Exchange 2013 Message Tracking Log GUI.
Note: A certain limited tool with delivery information is available in EAC - mail flow - delivery reports.
Using Get-MessageTrackingLog
When we want to use the Message Tracking logs, we can directly open the files (standard path C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\MessageTracking), but browsing them is quite complicated (they are in CSV format). Therefore, it is certainly better to use the cmdlet Get-MessageTrackingLog, which searches the message delivery information from the message tracking log. It parses the information in the log and displays the requested data.
By default, the output is displayed in the current window, but for further processing, we can save it to a file using ConvertTo-Csv, but the most practical for browsing looks like Out-GridView. The cmdlet has a number of switches, we only need to use those by which we want to filter the output (search). The result is normally limited to 1000 items, if we want to return everything, we must use the ResultSize switch. The basic filtering is usually the time interval using Start and End, here there is a small problem with the date format. The documentation states that it depends on the regional settings, but in Czech, the format dd.MM.yyyy HH:mm cannot be used, but MM.dd.yyyy HH:mm (i.e., the day and month are swapped) must be used.
Note: In some examples below, the special character ` is used to split the line (command) for better display on the web (and normally can be followed by a line break after | and ,).
A basic example of all messages in a certain time interval (April 10, 2019 from 14:00 to 14:01), the second variant for the last hour.
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
We most often filter by recipient or sender (or by both).
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
Another parameter for filtering is the message subject, where the specified part of the text is searched for (we don't need to use an asterisk or anything similar).
Get-MessageTrackingLog -MessageSubject "PROBLEM" -Start "4.10.2019 10:00" -End "4.10.2019 15:00" -ResultSize unlimited | Out-GridView
We can filter by a number of other parameters, such as EventId, InternalMessageId, MessageId, NetworkMessageId, Reference and Source. Using MessageId, we can display all events for a single message (some events have a Reference to the message from which they originated).
Get-MessageTrackingLog -MessageId "<9c5dc7b8a86cd65dd31c639d29f2505e@www.neco.cz>" -Start "4.10.2019 10:00" ` -End "4.10.2019 15:00" -ResultSize unlimited | Out-GridView
If we want to query a server other than the local one, we add the Server parameter.
Get-MessageTrackingLog -Server mail2 -Recipients bouska@firma.cz -Start "4.10.2019 10:00" -End "4.10.2019 15:00" ` -ResultSize unlimited | Out-GridView
Another thing is choosing the items (properties, columns) to display in the output. Their description is in the 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
Second variant, where there are even more details in the output.
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
Alternatively, we can add sorting (but in GridView we can sort dynamically).
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
Complex command, which is split into multiple lines (for clarity). We'll modify the values to search for and remove the lines with parameters we don't use.
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
Another modification, if we have multiple Exchange servers, we usually want to search for the message flow on all of them. To significantly speed up the execution on multiple servers, we will use the Invoke-Command command (advice from the article 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
}
Event Types (EventID) and Sources
Documentation Source values in the message tracking log, Event types in the message tracking log
Each message generates a number of events in the Message Tracking log. To identify the event, we can use the Source and EventId items.
Source identifies which transport component was responsible for the given event. The most common are:
- SMTP - SMTP sending or receiving (Transport Service)
- STOREDRIVER - MAPI for the mailbox on the local server
- ROUTING - routing (Transport Service)
- AGENT - Transport Agent
- PUBLICFOLDER - mail-enabled Public Folder
- DSN - Delivery Status Notification
EventId determines the type of event in the log. The most common are:
- SEND - sent using SMTP between transport services
- SENDEXTERNAL - a new event, it should be an SMTP send outside the organization, missing in the official description
- RECEIVE - message received using SMTP transport service or from Pickup or Replay folder (Source: SMTP), or sent from mailbox to Mailbox Transport Submission service (Source: STOREDRIVER)
- DELIVER - delivered to local mailbox
- AGENTINFO - uses Transport Agent, e.g. for recording a Transport Rule (How to Tell Which Transport Rule Was Applied to an Email Message)
- HAREDIRECT - a Shadow Message was created (Shadow redundancy in Exchange Server)
- HARECEIVE - a Shadow Message was received by a server in the local DAG or Site
- EXPAND - expand Distribution Group, the group was replaced with member addresses
- DROP - message was dropped without a DSN
- DSN - a Delivery Status Notification (DSN) was generated
- FAIL - delivery failed
- SUBMIT - the Mailbox Transport Submission service successfully handed the message to the transport service
Listing undelivered messages, DSNs, and errors
In addition to searching for specific messages where we want to verify the delivery status, we can sometimes look at some error states.
One option is to list the FAIL events, where delivery failed. This could be a non-existent recipient or entire domain, communication error with the target SMTP server, etc. The RecipientStatus item shows what error occurred. This way, we can find forgotten addresses on application servers that are still trying to send.
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
}
We can list the Delivery Status Notifications (DSN), either by source (Source: DSN) or directly by event (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
}
DSNs show us undelivered messages that our server generated. Based on the message subject, we can find incoming messages from outside. We use the MessageSubject parameter and "Undeliverable" or "Nedoručitelná". If we wanted to use both variants in one command, we would have to use 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
}
Statistics on message sending
Message Tracking logs can also be used to create statistics on email communication in the organization. For Exchange 2010, I wrote an article Exchange server and messaging statistics, where I added an update to Exchange 2016 in the second half.
Retrying message delivery, DSNs and NDRs
If the Exchange Server tries to deliver a message, it connects to the target SMTP server and passes the mail to its recipient. Three situations can occur:
- message is delivered - an SMTP connection is established and the server accepts the message
- message is not delivered - an error occurs, e.g. there is no MX record (mail server) for the domain, the target server rejects the message (non-existent recipient, limit exceeded), a FAIL is recorded in the Message Tracking log and an error (NDR) is sent to the sender
- message is deferred - if an SMTP connection to the target server cannot be established, Exchange tries to deliver it later (based on the configuration), at which point nothing is recorded in the Message Tracking log and the sender is not notified
If the server fails to deliver the message, Retry - a new attempt to connect to the target, or Resubmit - new processing (Submission queue) occurs. The message expires if all delivery attempts within the specified time fail. Then the sender is notified and the message is deleted from the queue.
If the Exchange server fails to connect to the Next Hop (the next mail server), the queue is set to Retry status and the connection attempts continue until the message is delivered or expires. The configuration of the intervals is described in Message retry, resubmit, and expiration intervals.
The sender is sent information about the delayed delivery of the message (that further attempts will be made) - a Delay Delivery Status Notification (Delay DSN), but this is not sent immediately, but only after the Delay notification timeout. This interval is 4 hours by default, and of course the message is only sent if it cannot be delivered within that time. We can change this value, it should normally not be less than 30 minutes (depending on the Retry parameters). We use either the Set-TransportService cmdlet or the Exchange Admin Center and the transport limits settings on the server.
If the message cannot be delivered, a Non-Delivery Report (NDR) is sent to the sender. It contains an error message, including the code, why the delivery failed (Undeliverable).
Messages about delivery failure are returned to the sender (Bounce Message) and belong to the DSN category. These are Delivery Status Notification (DSN) and Non-Delivery Report (NDR). Among the DSN are messages about delivery confirmation to the recipient, read confirmation, delayed delivery (Delivery delayed). More information DSNs and NDRs in Exchange Server, Sent email in Outlook.com comes back "delivery failed".
A few message examples
A message sent to a domain where the SMTP server is unavailable. First, a delay DSN comes in.
Delivery delayed: Subject Delivery is delayed to these recipients or groups: someone@non-responding.domain (someone@non-responding.domain) Subject: Subject 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 non-responding.domain (x.x.x.x) returned '400 4.4.7 Message delayed' 11.02.2019 14:27:11 - Server at non-responding.domain (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'
If the message expires, an NDR about non-delivery is also sent.
Undeliverable: Subject Delivery has failed to these recipients or groups: someone@non-responding.domain(someone@non-responding.domain) 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 non-responding.domain (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'
Sending a message to a non-existent recipient.
Undeliverable: Subject Delivery has failed to these recipients or groups: non-existent-user@firm2.cz (non-existent-user@firm2.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'
Sending a message to a non-existent domain.
Undeliverable: Subject Delivery has failed to these recipients or groups: someone@non-existent.domain (someone@non-existent.domain) 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 message delivery
If we need to find information about an undelivered message, we don't always have enough with the message tracking log (Message Tracking Log), but we also need to use the protocol logs (Protocol Log) or others.
Searching the Message Tracking Log
First, we use the Message Tracking and the Get-MessageTrackingLog cmdlet, as described above. If we find the message we're looking for, it should contain several events - records in the log.
Below are practical examples for configuring multiple Exchange servers and a DAG, showing the events that occur. If we want to list the sequence of events, we need to display the time including milliseconds. When listing events from multiple servers, they may still not be in the correct order (likely due to small time inaccuracies), but even within a single server, two identical events are logged in different orders for different messages.
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
}
Common events (EventId - Source) - sender has a mailbox on an Exchange server, recipient outside the company
- RECEIVE - STOREDRIVER
- HAREDIRECT - SMTP
- RECEIVE - SMTP
- HARECEIVE - SMTP
- SUBMIT - STOREDRIVER
- AGENTINFO - AGENT
- TRANSFER - ROUTING
- SENDEXTERNAL - SMTP
- HADISCARD - SMTP
Common events (EventId - Source) - sender connects via SMTP (from the internet or an application server), recipient on an Exchange server
- RECEIVE - SMTP
- HAREDIRECT - SMTP
- HARECEIVE - SMTP
- AGENTINFO - AGENT
- SEND - SMTP
- DELIVER - STOREDRIVER
- HADISCARD - SMTP
Common events (EventId - Source) - sender and recipient have a mailbox on an Exchange server
- RECEIVE - STOREDRIVER
- HAREDIRECT - SMTP
- RECEIVE - SMTP
- HARECEIVE - SMTP
- SUBMIT - STOREDRIVER
- AGENTINFO - AGENT
- SEND - SMTP
- DELIVER - STOREDRIVER
- HADISCARD - SMTP
If a problem occurs, instead of the SEND event, we may find FAIL, where the RecipientStatus item shows the reason.
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
If we don't see the message at all in the Message Tracking, the problem is likely already with its reception (from an external server or SMTP application) and we need to look in the SmtpReceive service log
- Front End Transport service -
C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpReceive
The structure of the log is described in detail in Protocol logging. Each line starts with the time, connector name, session ID, sequence number in the session, local and remote IP and port, a special character indicating the event type (> Send, < Receive, + Connect, - Disconnect, * Info), followed by information for the given event. Example
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
In the standard sending of a message via SMTP without authentication, we should find the given connection in the FrontEnd log (by time, IP address, name, addresses, etc.). The individual lines contain various events and display the SMTP commands from the client and the server's responses. Typically it's:
- EHLO
- MAIL FROM
- RCPT TO
- DATA
- QUIT
Example of a log excerpt:
+,, >,"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
On some line, there may be an error if a command failed and the message was not accepted for processing.
>,550 5.7.54 SMTP; Unable to relay recipient in non-accepted domain
Or information that the message was queued.
>,"250 2.6.0 ... Queued mail for delivery"
If we send a message via SMTP with authentication, we'll only find a few SMTP commands in the FrontEnd log. One of them may be establishing encryption (STARTTLS).
- EHLO
- (STARTTLS)
- AUTH LOGIN
Example of a log excerpt:
+,, >,"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
Errors here can be found if there is an incorrect authentication or a problem with 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
To continue, we need to look at the Hub log:
- Transport service (Hub) -
C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\Hub\ProtocolLog\SmtpReceive
Here the SMTP communication continues. First, the connection is established between the Exchange server services (FrontEnd and Hub), and then the client continues:
- MAIL FROM
- RCPT TO
- DATA
- QUIT
Example of a log excerpt:
+,, >,"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
We can find the same errors here as in the FrontEnd log.
>,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
One practical situation is that the message is correctly received (SmtpReceive). We find it in the Message Tracking log, but the events are missing SEND, SENDEXTERNAL, or even FAIL. The last logged event is AGENTINFO. Then we need to look at the SmtpSend logs.
- 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
Here, when trying to send the message, we can find an error, for example:
*,,"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."
This suggests that it is the situation described above in Retrying message delivery, DSNs and NDRs, and further delivery attempts will follow.
There are no comments yet.