------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1298
Summary: Doesn't 42.39, Ratelimit options for handling fast
clients, contradict itself?
Product: Exim
Version: 4.80
Platform: Other
URL: http://www.exim.org/exim-html-
current/doc/html/spec_html/ch42.html#ratoptfast
OS/Version: All
Status: NEW
Severity: bug
Priority: low
Component: Documentation
AssignedTo: nigel@???
ReportedBy: regid23@???
CC: exim-dev@???
For example, how can the client's recorded rate not being updated if
it is above the limit, and, at the same time, measures the client's
average rate of successfully sent email? Unless the client slows down,
not updating the recorded rate can only show the long time desired
average rate, not the actual rate.
1. The following patch is based upon my thoughts of the author
intention. I have not read the code, or made any experiments.
2. The patch is against spec.txt. Not spec.xfpt. This is to ease the
discussion. I can try to make a patch against spec.xfpt once the
wording is determined.
--- a/spec.txt 2012-09-20 01:14:28.434496547 +0300
+++ b/spec.txt 2012-09-20 01:14:22.000000000 +0300
@@ -26417,11 +26417,16 @@ or leaky update modes. This is independe
as rejecting the message) that may be specified by the rest of the ACL.
The leaky (default) option means that the client's recorded rate is not
updated
-if it is above the limit. The effect of this is that Exim measures the
client's
-average rate of successfully sent email, which cannot be greater than the
-maximum allowed. If the client is over the limit it may suffer some
-counter-measures (as specified in the ACL), but it will still be able to send
-email at the configured maximum rate, whatever the rate of its attempts. This
+if it is above the limit. The effect of this is that Exim does not measure the
client's
+average rate of successfully sent email. Instead, the rate is temporarily
fixed at the
+maximum allowed. In other words,
+
+ $sender_rate is kept approximately equal to
$sender_rate_limit/$sender_rate_period.
+This fixation is, approximately, as long as the actual rate is above the
limit.
+
+If the client is over the limit it may suffer some counter-measures (as
specified in the ACL),
+but, depending on these counter-measures, it will still be able to send
+email at the actual rate, whatever the rate of its attempts. This
is generally the better choice if you have clients that retry automatically.
For example, it does not prevent a sender with an over-aggressive retry rate
from getting any email through.
@@ -26430,7 +26435,7 @@ The strict option means that the client'
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
+ACL. These counter-measures can force it to slow down and allow sufficient
time to pass so 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:
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
