Exchange Gloves: Tarpit for '0.00:00:09.675' due to 'DelayedAck',Delivered

So whether you are in co-existence between Lotus notes and Exchange or Exchange 2003 and 2010. There will be a time where there will be a delay experienced at some time. It happens to almost every environment.

The SMTP tarpit feature is one of the most useful tools to protect organizations from directory harvesting attacks (DHAs). By default, the tarpit interval, or time before a response, is five seconds, and the error limit is five.

On the first day we were experiencing 20 minute email delays, nothing too noticeable as this wasn’t consistent either. The second day the delays had reached up to an hour and then 2 hours. Only a few emails were passing through and Lotus notes was showing a considerable queue build up (2000+ emails) in a retry state. Exchange did not have any queues. After much troubleshooting on the network side and Quest co-existence server the next step was to start looking at the problem from the Exchange end as a possible receiving issue. So then the troubleshooting began and we started at the receive connector end.

1) First place to start looking with troubleshooting is turning the SMTP logging on the receive connector. Change this from None to Verbose.

2) To do this in EMC, Expand the Server Configuration > Hub Transport node

3) Select the Hub Transport server you want to configure, and then select the Receive Connector > Properties

4) On the General tab, change the Protocol logging level from None to Verbose, click Apply and OK.

5) Locate the logs by opening the following location C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\ProtocolLog\SmtpReceive . There will be a file called RECVYYYYMMDD-1

Started observing this error throughout the logs, which indicated that messages were not coming through to exchange normally:

354 Start mail input; end with <CRLF>.<CRLF>,

Then observed a multiple error messages which triggered our interest:

Tarpit for '0.00:00:09.675' due to 'DelayedAck',Delivered

Investigated the “DelayedAck” (Delayed Acknowledgement) indicates slow email acceptance and generates the error message above, all throughout the Receive connectors SMTP logs.

This means that Exchange has not acknowledged the pending message yet.

So further researching brought me to a few pages. Where the problem was the “MaxAcknowledgementDelay” parameter was not equal to 0.

To first see what my receive connectors were set to the default appeared to be 30.

Get-receiveconnector “connector name” | fl sort-by *max*

MaxInboundConnection : 5000

MaxInboundConnectionPerSource : 20

MaxInboundConnectionPercentagePerSource : 2

MaxHeaderSize : 64 KB (65,536 bytes)

MaxHopCount : 60

MaxLocalHopCount : 12

MaxLogonFailures : 3

MaxMessageSize : 22 MB (23,068,672 bytes)

MaxProtocolErrors : 5

MaxRecipientsPerMessage : 200

MaxAcknowledgementDelay : 00:00:30

Then ran:

Set-ReceiveConnector "Default connector (Servername)" -MaxAcknowledgementDelay 0

And for verification:

Get-receiveconnector “connector name” | fl sort-by *max*

MaxInboundConnection : 5000

MaxInboundConnectionPerSource : 20

MaxInboundConnectionPercentagePerSource : 2

MaxHeaderSize : 64 KB (65,536 bytes)

MaxHopCount : 60

MaxLocalHopCount : 12

MaxLogonFailures : 3

MaxMessageSize : 22 MB (23,068,672 bytes)

MaxProtocolErrors : 5

MaxRecipientsPerMessage : 200

MaxAcknowledgementDelay : 00:00:00

This turns this feature off and bingo the queue on the Domino co-existence server quickly disappeared. Email flow is back to normal and no longer has any email build ups.

The cmdlet does have to be run on every single one of your HUB servers, no restart of services or servers required.

Although, do remember to turn off your verbose logging on the HUB server as the logs do fill up very quickly and can cause some issues if you don’t have enough space available.

1) To do this in EMC, Expand the Server Configuration > Hub Transport node

2) Select the Hub Transport server you want to configure, and then select the Receive Connector > Properties

3) On the General tab, change the Protocol logging level from Verbose back to None, click Apply and OK.