Understand Exchange message rate limit - 4.4.2 Message submission rate for this client has exceeded the configured limit

I have this problem on my application to relay email through port 587 of our Exchange 2010: error prompt was 4.4.2 Message submission rate for this client has exceeded the configured limit.

I understand this is due to the MessageRateLimit of my receiver connector. I checked the limit is 5 and limit by user (MessageRateSource), and I think the problem probably will be fixed by increasing the limit to 50 or 100. However I would like to understand this configuration more (how if I set it to 50 now and it hit the same error tomorrow?)

Based on MS site, this is throttling setting to limit "The maximum number of messages per minute that can be sent by a single source". So I tested using powershell script (not sure whether it does matter, so I include the partial code below):

$SMTPClient = New-Object System.Net.Mail.SmtpClient( $emailSmtpServer , $emailSmtpServerPort )
$SMTPClient.EnableSsl = $true
$SMTPClient.Credentials = New-Object System.Net.NetworkCredential($emailSmtpUser , $emailSmtpPass );
#[System.Net.ServicePointManager]::ServerCertificateValidationCallback = { return $true }
$SMTPClient.Send( $emailMessage )

In this script I'm first submit the email with another user ID, and the result: I'm able to submit email to the same receiver more than 5 times within a minutes. So why does the limit not applied to this case?

After that, I tried the script with my application ID, the same error (4.4.2) prompted. I then checked the tracking log explorer and I found there is no other email submitted with that application ID. So is it Exchange store the user count some where which I need to reset it? And how can I trace the email submission? It doesn't seem appears in tracking log explorer, so as my concern earlier, it might hit the same error even I change it to 50, I'm unable to troubleshoot further without able to trace them.

Sorry as the question is a bit long.

Appreciate if anyone can provide me some clues.

I am going to flip this question on its head. When a client comes to me with this issue, the first thing I ask is why are the messages being relayed through Exchange? Exchange makes a very poor bulk emailer, and there are better options. Why isn't the application sending the email itself, or via its own server rather than Exchange?

If you have an application sending so much email to external recipients that it is tripping over the throttling limits then I wouldn't want that anywhere near Exchange. It is only a matter of time before it gets blacklisted. Own IP address, own PTR and DNS and send email itself.

Not the answer you are looking for I admit, but often thinking of the issue another way gives you a better way of dealing with the issue.

Throttling within exchange is quite powerful but - afaik hard to track.

In my experience setting limits on connectors is quite problematic as you may have only a very small subset of users that are sending high volume. Pushing the limits on the connectors for few users exposes an increased risk of abuse by a compromised account.

Throttling policies

When working with higher volumes you should determine your highest message rates and set these to your receive connector. This is your global limit.

Next you should establish first a Throttling-Policy that reduces the limit back to a moderate value (like 5 msg/min) as organizational policy.

Finally you can add additional policies that raise the sending limit for specific users.

This doesn't expose 'mass-mailing' limits to all users that can access the given connector and allows more granular control.

You can get more information about policies in the documentation.

Detecting limits

While it's a good point for diagnostics, I wouldn't start trying to handle reaching the limits on the server side.

There are propably more outcomes that indicate failure that success when sending mail. Reaching the rate limit is just one of them. And your application needs to handle these, as well as scenarios where the whole mailserver may not be reachable due some downtime.

Therefore I would strongly recommend to focus on proper error handling and a queuing mechanism in your application. Check out ways to get the SMTP dialog messages and log them in case of failure. This will enable quick and easy diag in production - not only for this specific case.

As @seembee said, sending high volumes increases the risk of getting blacklisted. This risk is still given when bypassing exchange and using dedicated mass-mailing hosts. Sending stuff like newsletters i would agree completely. But when you're sending important mails like invoices that may even have legal restrictions on the mail-flow i wouldn't recommend to bypass the exchange-infrasructure.