I am ahaving a problem with the behaviour of rate limiting (throttling) on the Ironport.
According to the manual, you specify a rate limit of x messages per hour against a HAT Policy, and this is applied per-IP Address for the relevant HAT group(s).
However, it seems to behave slightly differently.
A HAT group can match a connecting IP address either via an SBRS range, or via a HAT Sender definition (or as a default). If a given host matches the HAT group via the SBRS match, then the rate limiting works as expected. Good. If the connecting host matches via one of the Sender definitions, then the rate is applied over the ENTIRE sender definition.
Thus, if you have a Sender that is a single IP address, it works as expected. However, if you specify (eg) 130.216.0.0/16 as the Sender, then the rate limit is applied over this subnet as a single entity! This is not how I believe it is intended to work.
Additional options exist in the HAT Policy to further generalise a rate limit (switch off SBRS and specify how many bits of the address to group by) but these will not make the buckets smaller (I cannot set it to 32bits and get per-IP rate limiting, it still treats the whole Sender definition as one entity).
The reason we are using this is because on our Internal interface, we have HAT groups for: a set of known mail servers (Relay, no rate limit), then the rest of our internal subnet (Relay, rate limit) and finally the Internet as a whole (Relay, Mandate SMTP-Auth and TLS). This allows workstations with IMAP/SMTP mail clients to work but not flood the mail server if they get trojanned. However, we cannot rate limit for the internal subnet due to the previously explained behaviour.
Has anyone else experienced this? I have done a number of tests and can provide more detailed explanations of how to duplicate if you need.
