You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Mike French <mi...@acclaimnetworks.com> on 2006/12/13 22:35:30 UTC
DNSRBL
Postfix/Amavis-new
Spamassassin 3.1.4
I ran Amavis debug-sa and I'm curious if the is normal?
[5846] dbg: dns: success for 9 of 26 queries
[5846] dbg: dns: timeout for habeas-firsttrusted after 13 seconds
[5846] dbg: dns: timeout for njabl after 13 seconds
[5846] dbg: dns: timeout for whois after 13 seconds
[5846] dbg: dns: timeout for sorbs after 13 seconds
[5846] dbg: dns: timeout for whois,whois-lastexternal after 13 seconds
[5846] dbg: dns: timeout for sorbs-lastexternal,sorbs after 13 seconds
[5846] dbg: dns: timeout for sblxbl,sblxbl-lastexternal after 13 seconds
[5846] dbg: dns: timeout for sblxbl after 13 seconds
[5846] dbg: dns: timeout for njabl after 13 seconds
[5846] dbg: dns: timeout for sorbs after 13 seconds
[5846] dbg: dns: timeout for whois after 13 seconds
[5846] dbg: dns: timeout for njabl-lastexternal,njabl after 13 seconds
[5846] dbg: dns: timeout for securitysage after 13 seconds
[5846] dbg: dns: timeout for sblxbl after 13 seconds
[5846] dbg: dns: timeout for spamcop after 13 seconds
[5846] dbg: dns: timeout for spamcop after 13 seconds
[5846] dbg: dns: timeout for spamcop after 13 seconds
Do these normally timeout or do they need to be removed from a rule? I'm
thinking they are timed out because nothing was found?
Re: DNSRBL
Posted by Jason Haar <Ja...@trimble.co.nz>.
Richard Frovarp wrote:
>
> Make sure you are running a local caching name server. Even with a
> real name server on the same subnet, I have heard of massive delays in
> DNS lookups as a result. This in turn causes a massive slowdown in the
> processing of mail.
You are absolutely correct. However - we are running caches, and they
really only help if you receive 'N>1' spam from the same source within
5-60 minutes (TTL of most RBLs). Unfortunately these BOT armies tend to
mean we get the same SPAM *content* from 100-1000 *different* IPs per
hour. In that case caching doesn't help (much).
Caching FuzzyOCR hashes helps :-)
--
Cheers
Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +64 3 9635 377 Fax: +64 3 9635 417
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
Re: DNSRBL
Posted by Richard Frovarp <Ri...@sendit.nodak.edu>.
Jason Haar wrote:
> Theo Van Dinter wrote:
>
>> On Wed, Dec 13, 2006 at 03:35:30PM -0600, Mike French wrote:
>>
>>
>>> Do these normally timeout or do they need to be removed from a rule? I'm
>>> thinking they are timed out because nothing was found?
>>>
>>>
>> The problem is likely related to your name servers. There should always
>> be a response, even if it's "not found".
>>
>>
>>
> Well - unless it's a timeout :-) I certainly see (i.e. tcpdump) DNS
> responses routinely taking those sorts of amounts of time. Don't forget
> - UDP is lossy, so there's opportunity for retransmit delays, etc.
>
> Here in NZ we are about as far away from other countries DNS as you can
> get - I had to ramp up all DNS-related SA timeouts to get an acceptable
> level of SA hitrates. Of course it does mean SA takes >10sec to process
> a good fraction of our email :-(
>
> I've just checked: 9% of our NZ-based SA calls take > 10 sec - and it
> will be all DNS related. Conversely 0.3% of our US-based SA calls take
>
>> 10secs...
>>
>
> It's just the way it is. New Zealand is working on a tectonic-plate
> strategy to drag the country closer to California to improve home
> broadband performance :-)
>
>
Make sure you are running a local caching name server. Even with a real
name server on the same subnet, I have heard of massive delays in DNS
lookups as a result. This in turn causes a massive slowdown in the
processing of mail.
Re: DNSRBL
Posted by Jason Haar <Ja...@trimble.co.nz>.
Theo Van Dinter wrote:
> On Wed, Dec 13, 2006 at 03:35:30PM -0600, Mike French wrote:
>
>> Do these normally timeout or do they need to be removed from a rule? I'm
>> thinking they are timed out because nothing was found?
>>
>
> The problem is likely related to your name servers. There should always
> be a response, even if it's "not found".
>
>
Well - unless it's a timeout :-) I certainly see (i.e. tcpdump) DNS
responses routinely taking those sorts of amounts of time. Don't forget
- UDP is lossy, so there's opportunity for retransmit delays, etc.
Here in NZ we are about as far away from other countries DNS as you can
get - I had to ramp up all DNS-related SA timeouts to get an acceptable
level of SA hitrates. Of course it does mean SA takes >10sec to process
a good fraction of our email :-(
I've just checked: 9% of our NZ-based SA calls take > 10 sec - and it
will be all DNS related. Conversely 0.3% of our US-based SA calls take
>10secs...
It's just the way it is. New Zealand is working on a tectonic-plate
strategy to drag the country closer to California to improve home
broadband performance :-)
--
Cheers
Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +64 3 9635 377 Fax: +64 3 9635 417
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
Re: DNSRBL
Posted by Theo Van Dinter <fe...@apache.org>.
On Wed, Dec 13, 2006 at 03:35:30PM -0600, Mike French wrote:
> Do these normally timeout or do they need to be removed from a rule? I'm
> thinking they are timed out because nothing was found?
The problem is likely related to your name servers. There should always
be a response, even if it's "not found".
--
Randomly Selected Tagline:
"... and a chunk of carbon is a mighty simple thing." - Prof. Vaz