Exchange 2013 SMTP service delayed / slow acknowledgement

Question

Hey Guys,
since we upgraded from Exchange 2010 to Exchange 2013 (SP1) any SMTP Receive Connector we create (including the default one) show the same strange behavior. When you send an email (no matter if internal or external) it sometimes takes
up to 30 seconds for the exchange server to acknowledge the message. Using the SMTP log I see the following entries:
2014-08-08T08:58:29.053Z,                       MAIL FROM:<[email protected]>,
2014-08-08T08:58:29.053Z,                       SMTPSubmit SMTPAcceptAnySender SMTPAcceptAuthoritativeDomainSender AcceptRoutingHeaders,Set
Session Permissions
2014-08-08T08:58:29.053Z,                       receiving message
2014-08-08T08:58:29.053Z,                       250 2.1.0 Sender OK,
2014-08-08T08:58:29.053Z,                       RCPT TO:<[email protected]>,
2014-08-08T08:58:29.053Z,                       250 2.1.5 Recipient OK,
2014-08-08T08:58:29.053Z,                       DATA,
2014-08-08T08:58:29.053Z,                       354 Start mail input; end with <CRLF>.<CRLF>,
2014-08-08T08:58:29.068Z,                       Proxy destination(s) obtained from OnProxyInboundMessage event
2014-08-08T08:58:40.960Z,                       "250 2.6.0 <5160cd2a-9160-4a35-9007-1f9c17761bc0@--------> [InternalId=17776869639170,
Hostname=-----------] Queued mail for delivery",
As you can see there’s a delay between 08:58:29 and 08:58:40 where nothing happens. The sending smtp service waits for the server to acknowledge the message – at least that’s what I guess. Since we use this kind of connector a lot for
internal mail traffic with non-Outlook clients it is essential to get rid of this issue. For example using Trac Ticket system or Subversion also leads to slow or delayed responses. Creating a ticket in Trac sometimes takes up to a Minute since several emails
are created and sent in background processes. We didn’t have this issue with Exchange 2010 and I actually couldn’t find much using google. 
Since there's no error showing it's quite difficult to track down the issue. After I did some researching I tried configuring the receive connector to change this behavior but nothing helped. I tested the following options:
MaxAcknowledgementDelay 00:00:00
TarpitInterval 00:00:00
MessageRateSource None
MessageRateLimit unlimited
MaxInboundConnectionPercentagePerSource: 20
MaxInboundConnectionPerSource 100
 I Also took a look at the Throttling Policies with no luck either. 
Calling the Microsoft support simply led to the typical “we do not support 3^rd party issues”. In fact this is NOT a third party issue but arguing didn't help. I tested every possible solution I found and after weeks
I simply dont' have the slightest idea any more, how to solve the problem.
Some information about our Exchange environment:
Exchange DAG with 2 servers
Windows Server 2012 (latest updates)
Exchange 2013 SP1 installed
Disabling DAG members also didn’t help and all the members show the same behavior no matter which connector I choose to use.  
Any hint or idea would be very much appreciated.
Thanks,
Christoph

Answer 1

Hi Christoph,
From the SMTP session, the delay happened when processing data. This can be caused by several factors, such as the length of message content.
In Exchange 2013, we have the function called shadow redundancy, the transport server makes a redundant copy of any messages it receives before it acknowledges successfully receiving the message back to the sending server. This helps to ensure that all messages
in the Exchange 2013 transport pipeline are made redundant while they're in transit. If Exchange 2013 determines the original message was lost in transit, the redundant copy of the message is redelivered.
For more information about shadow redundancy, we can refer to the article:
Shadow redundancy
http://technet.microsoft.com/en-us/library/dd351027(v=exchg.150).aspx
By default, it is enabled, and if we want to disable it, we can use the command:
Set-TransportConfig –ShadowRedundancyEnabled $false
Best Regards,
Tracy Liang