------- 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: [email protected] ReportedBy: [email protected] CC: [email protected] 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 -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
