+For example, it does not prevent a sender with an over-aggressive retry rate
+from getting any email through.
+
+The &%strict%& option means that the client's recorded rate is always
+updated. The effect of this is that Exim measures the client's average rate
+of attempts to send email, which can be much higher than the maximum it is
+actually allowed. If the client is over the limit it may be subjected to
+counter-measures by the ACL. It must slow down and allow sufficient time to
+pass that its computed rate falls below the maximum before it can send email
+again. The time (the number of smoothing periods) it must wait and not
+attempt to send mail can be calculated with this formula:
+.code
+ ln(peakrate/maxrate)
+.endd
+
+
+.section "Limiting the rate of different events" "ratoptuniq"
+.cindex "rate limiting" "counting unique events"
+The &%ratelimit%& &%unique=%& option controls a mechanism for counting the
+rate of different events. For example, the &%per_addr%& option uses this
+mechanism to count the number of different recipients that the client has
+sent messages to in the last time period; it is equivalent to
+&`per_rcpt/unique=$local_part@$domain`&. You could use this feature to
+measure the rate that a client uses different sender addresses with the
+options &`per_mail/unique=$sender_address`&.
+
+For each &%ratelimit%& key Exim stores the set of &%unique=%& values that it
+has seen for that key. The whole set is thrown away when it is older than the
+rate smoothing period &'p'&, so each different event is counted at most once
+per period. In the &%leaky%& update mode, an event that causes the client to
+go over the limit is not added to the set, in the same way that the client's
+recorded rate is not updated in the same situation.
+
+When you combine the &%unique=%& and &%readonly%& options, the specific
+&%unique=%& value is ignored, and Exim just retrieves the client's stored
+rate.
+
+The &%unique=%& mechanism needs more space in the ratelimit database than the
+other &%ratelimit%& options in order to store the event set. The number of
+unique values is potentially as large as the rate limit, so the extra space
+required increases with larger limits.
+
+The uniqueification is not perfect: there is a small probability that Exim
+will think a new event has happened before. If the sender's rate is less than
+the limit, Exim should be more than 99.9% correct. However in &%strict%& mode
+the measured rate can go above the limit, in which case Exim may under-count
+events by a significant margin. Fortunately, if the rate is high enough (2.7
+times the limit) that the false positive rate goes above 9%, then Exim will
+throw away the over-full event set before the measured rate falls below the
+limit. Therefore the only harm should be that exceptionally high sending rates
+are logged incorrectly; any countermeasures you configure will be as effective
+as intended.
+
git://git.exim.org / users / jgh / exim.git / blobdiff