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:
Managing Active Directory does not always have to be complicated. If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why
Exchange organizations may use the Journaling Agent of the Transport Service to archive messages going through Exchange. However, if the Transport Service is integrated with some email content management application (such as an antispam), the admini…
This video tutorial shows you the steps to go through to set up what I believe to be the best email app on the android platform to read Exchange mail.
Get the app on your phone: The first step is to make sure you have the Samsung Email app on your …