Preventing email blasts with Exchange 2010 IP Throttling (or any other technology)

Solution 1:

Ultimately, your developers need to fix their apps. Exchange can handle an obscene number of incoming messages concurrently, so if your developers are creating that much email that you're concerned it's having an impact on the day-to-day stuff then you have serious problems. Is this actually causing you a problem, or are you just imagining you have a problem that really doesn't exist? Check out the Exchange performance counters and get some statistics to back up your claim.

If it were my Exchange server they were thrashing, and I'd verified there was a genuine problem, I'd go to their manager with my concerns (backed with statistics) and tell them to sort their apps out or risk being blocked from sending email completely. If the app is still in development then that's sort of a valid excuse for buggy emails, but it really should be using a separate SMTP server and not the production Exchange server.

Exchange 2010 does have throttling policies which I guess you could (ab)use dependant on your setup, but the scenarios they apply to when you want to throttle non-mailbox objects is pretty narrow (IMO). If the emails are coming from a service running on a machine as NETWORK SERVICE (including a web server) then you can apply a throttling policy to a computer object. What's more likely though is this is a client app run as whatever user happens to be logged on, in which scenario I don't believe you'll be able to throttle using Exchange. I don't believe you can throttle by client IP address either, which is a bit annoying I have to admit.

If you do fall into the category of an app running as NETWORK SERVICE, you can create a new throttling policy and apply it to Active Directory computer objects. The value you'll want to throttle on is probably MessageRateLimit, which is messages per minute. If more messages than the throttling policy are submitted, the app will receive a transient error. The documentation is not very specific on whether it will actually accept the message and delay delivery or temporarily reject it, but your apps really should have some mechanism to handle transient errors anyway so that shouldn't be an issue. The commands to set this up would be New-ThrottlingPolicy -Name "Naughty Apps" -MessageRateLimit 50 and then Set-ThrottlingPolicyAssociation -Identity COMPUTERNAME$ -ThrottlingPolicy "Naughty Apps".

If you don't fall into the app running as NETWORK SERVICE category, then I'm not sure there's anything you can do from within Exchange. You may be able to set up something like Postfix and configure your app to send messages to that server instead, which would then relay them onto your Exchange server at a slower rate. I'm really out of my knowledge area to suggest any actual details though.