On Fri, 29 Aug 2003, Simon Byrnand wrote:
> 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 wor
Simon Byrnand writes:
>Although I don't have the answer to your question, I suggest you look at
>using the following options to reduce the various timeouts to minimize the
>chance of a "train wreck" due to things outside your control :)
>
>rbl_timeout
>razor_timeout
>dcc_timeout
>pyzor_timeout
>
David Birnbaum <[EMAIL PROTECTED]> writes:
> That sounds good, but will the debug switch show you which test is
> timing out so you CAN disable it quickly? I found it pretty hard to
> figure out which test was failing.
Yep.
--
Daniel Quinlan anti-spam (SpamAssassin), Linux,
Simon Byrnand <[EMAIL PROTECTED]> writes:
> 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 ?
One at a bloody slow time.
SpamAssassin would be m
> 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 abor
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 i
At 22:38 28/08/2003 -0700, Daniel Quinlan wrote:
Simon Byrnand <[EMAIL PROTECTED]> writes:
> Although I don't have the answer to your question, I suggest you look at
> using the following options to reduce the various timeouts to minimize the
> chance of a "train wreck" due to things outside your
Simon Byrnand <[EMAIL PROTECTED]> writes:
> Although I don't have the answer to your question, I suggest you look at
> using the following options to reduce the various timeouts to minimize the
> chance of a "train wreck" due to things outside your control :)
>
> rbl_timeout
> razor_timeout
> d
At 21:23 27/08/2003 -0400, David Birnbaum wrote:
Folks,
With respect to the OSIRU DNS problems recently, we had the situation
where SpamAssassin suddenly went from taking one second to process a
message to 30 seconds or more. Mail suddenly started backing up, and we
ended up with a real train wre
David Birnbaum writes:
>With respect to the OSIRU DNS problems recently, we had the situation
>where SpamAssassin suddenly went from taking one second to process a
>message to 30 seconds or more. Mail suddenly started backing up, and we
>ended up with a real train wreck - mail volume was much hig
Folks,
With respect to the OSIRU DNS problems recently, we had the situation
where SpamAssassin suddenly went from taking one second to process a
message to 30 seconds or more. Mail suddenly started backing up, and we
ended up with a real train wreck - mail volume was much higher than usual
due t
11 matches
Mail list logo
