McMahonWeb

Exchange 2003 Transaction Time and SMTP Tar Pitting

May 20

adminTech Exchange 2003 Tar Pitting SMTP Transaction Time MX Toolbox 1 Comment

I was recently doing some SMTP diagnostics on an Exchange 2003 server.  Everything seemed to be working great, except for the transaction times.  Averaging at 5.2 seconds, it wasn’t horrible, but in the “warning” range for an average mail server.

Why is the transaction time important?  It can mean the difference between receiving or not receiving some email.  If the transaction time gets too high, other mail servers may just timeout trying to communicate.  This is obviously not a good situation for a mail server.

Ideally, the transaction time should be under 1 second, and that’s what I wanted this exchange server to show.  The first point of interest was the Cisco firewall, which has some ESMTP inspection policy in place.  There are known instances of mail servers having trouble sending or receiving with this policy in place, but I couldn’t find any issues related to transaction times.  The second place to look is the server performance itself.  Processor, RAM,  or drive performance issues could theoretically be affecting transaction times.  None of these are of concern for this particular server.

Further digging got me to a feature in exchange known as Tar Pitting. As the Microsoft Support article explains:

• Tar pitting is the practice of deliberately inserting a delay into certain SMTP communications that are associated with spam or with other unwanted traffic. To be effective, these kinds of communications typically rely on generating a high volume of traffic. By slowing an SMTP conversation, you can dramatically reduce the rate at which automated spam can be sent or at which a dictionary attack can be conducted. Legitimate traffic may also be slowed by tar pitting.

That last statement about legitimate traffic being affected is true.  I dug into the registry and found that indeed this mail server was inserting a 5 second delay.  Microsoft points out that this feature is of little value, unless you use recipient filtering.  That technique is not used on this particular server, so the delay isn’t of much use.

I set the delay to zero, and tested.   Transaction times are now averaging .42 seconds.  That’s much better.