> Simon Byrnand <[EMAIL PROTECTED]> writes: > >> So umm, how does the rbl_timeout setting work in 2.60 then ? I didn't >> quite >> follow the logic of what you said :) I would have previously assumed >> that >> it was just a cutoff where if an individual test took longer than that >> it >> was aborted.... but it doesn't sound like it works like that at all... > > It is still a cut-off, but it will cut-off earlier if most of the > queries have already been made successfully. It works well in practice > because the timeout is relative to the overall responsiveness of the > network and blacklists. > > The benefits: > > - if one or a few blacklists are down, they timeout quickly enough that > you probably don't need to disable them for short outages > - it's done without all the overhead and complication of tracking the > status of each blacklist > - when a blacklist comes back up, it is used immediately > >> I have rbl_timeout set to 10 in 2.55 so if I should be setting it higher >> when I upgrade to 2.60 I'd like to have some vaugue understanding of why >> :) > > The documentation is hopefully clearer than my email: > > rbl_timeout n (default 15) > All RBL queries are made at the beginning of a check and we try to > read the results at the end. This value specifies the maximum > period > of time to wait for an RBL query. If most of the RBL queries have > succeeded for a particular message, then SpamAssassin will not > wait > for the full period to avoid wasting time on unresponsive > server(s). > For the default 15 second timeout, here is a chart of queries > remaining versus the effective timeout in seconds: > > queries left 100% 90% 80% 70% 60% 50% 40% 30% 20% > 10% 0% > timeout 15 15 14 14 13 11 10 8 5 3 > 0 > > In addition, whenever the effective timeout is lowered due to > additional query results returning, the remaining queries are > always > given at least one more second before timing out, but the wait > time > will never exceed the timeout. > > For example, if 20 queries are made at the beginning of a message > check and 16 queries have returned (leaving 20%), the remaining 4 > queries must finish within 5 seconds of the beginning of the check > or they will be timed out. > > (yeah, I just reworded it a tiny bit from 2.60-rc3)
Sounds very clever... I guess we'll see how well it works in practice :) Generally the situation for us anyway is that we have fast DNS available but individual blacklists may stop replying as osirusoft did... its not common for the response time of all lists to be slow at once, so it looks like the above scheme may work out well.... I'll take my rbl_timeout line out when I upgrade and let it be the default value. I presume though that I'd still be wise to keep the timeouts for razor, dcc, and pyzor ? And speaking of that, do they run in parallel with each other and/or other network tests, or one at a time ? Regards, Simon ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
