다음을 통해 공유

Stange things are afoot

  • 아티클

I wanted to get this down as I've seen similar symptoms twice now for a feature that can sometimes shoot you in the foot. Exchange Server 2007 has a component built into transport that attempts to determine whether or not a connecting IP should be discredited or not. 

We determine a connecting client IP to be discredited if it has previously connected and disconnected under a tarpitted session. If it's discredited we pro-actively enable tarpitting, a process where we wait for a specific interval between ALL responses sent back to the client. The default for this interval is 5 seconds. Except under this condition, tarpitting usually occurs after the first command that results in an error response.

I've seen this bite in two ways:

  1. Abitrary tweaking of the tarpitinterval and specifying a much longer interval than normal.
  2. Servers that perform chunking, sending small chunks of BDAT data and monitoring CHUNK acknowledgements.

When tweaking the interval, I personally don't suggest anthing much higher than 5 seconds which happens to be the default. To set the value you use the following cmd:

set-ReceiveConnector "Connector Name" -tarpitinterval 00:00:5

Tarpitting is generally used to slow down directory harvesting and impeded mass mailing. The thought is if it takes too long to perform the operation mailers will give up. Again, I recommend the default but if you feel the need to tweak it, don't set it to 00:05:00 (5 minutes) like I've seen it.

Another way this impacted us is through chunking. Chunking provides a method to submit multiple SMTP commands in succession without waiting for a response. This impacted one mailer submitting to us because the mailer was submitting larger messages in small chunks. The 5 second intervals caused a queue up of 2.6.0 CHUNK received OK, ### octets responses from Exchange. Every response took 5 seconds, and after 1 minute the mailer gave up waiting for the additional responses and disconnected. The reason for this is that we tarpit every BDAT response that isn't the last chunk (BDAT ### LAST).

The only way to resolve under this situation is to set the tarpitInterval to 00:00:00 or disable Chunking and BinaryMime on your receive connector.