As of Exchange Server 2007 Microsoft implements tarpitting by default even when receiving chunked emails. (The default timeout value set is 5 seconds.) Now one would think Exchange Server would automagically turn off tarpitting for a sender's IP address in the middle of receiving a chunked email and then turn it back on once they receive a BDAT LAST command. Unless, perhaps, they're afraid someone will attempt a MIM attack by hijacking the email chunking.
So the problems come in when some third-party firewall proxies start thinking there's an issue with communication to the Exchange Server within the firewall/boundary. This is because the firewall is getting backlogged with email chunks since the Exchange Server is waiting 5 seconds between receiving chunks before it will accept any more. Now the firewall vendor will likely tell you to turn of ESMTP or at the very least BDAT/CHUNKING on the firewall's proxy to resolve this problem. I'm sure this is because they don't want to start messing around with Exchange Server configurations. The problem is that this disables firewall proxy features for ESMTP emails. And, as we all know, sometimes the firewall is the better place to stop malicious attacks, like directory harvesting, by miscreants. However, since we mess around with everything…here's what I believe is a better solution.
So, assuming you're confident that the third-party firewall proxy will properly vet chunked SMTP, it is safe and easy enough to turn off tarpitting on only the Exchange Server's Internet inbound receive connector. This is accomplished by disabling tarpitting on the appropriate receive connector. This will still keep tarpitting enabled for all other receive connectors on the given Exchange Server.
Open the problematic Exchange Server's PowerShell command interface and enter [set-ReceiveConnector "<Connector Name>" -tarpitinterval 00:00:00]. (Just what's between the brackets, not the brackets themselves.) One will need to know which receive connector to perform this action against. To find all receive connectors simply run [get-ReceiveConnector] within PowerShell. This will return a list of all receive connectors along with their listening IP:PORT bindings and whether they are enabled or not. Based on this information one should easily be able to determine the Internet inbound connector. [Hint: It's usually the only one enabled listening on Port 25.] In my case the connector had the cryptic name of "Internet Inbound". ;-) So my set-ReceiveConnector command looked like this: