Mailing-List: contact users-help@spamassassin.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of dfs@roaringpenguin.com
 designates 70.38.112.54 as permitted sender)
Date: Wed, 6 Jul 2011 08:00:05 -0400
From: "David F. Skoll" <dfs@roaringpenguin.com>
To: users@spamassassin.apache.org
Subject: Re: DUL/DUL+ redesign to improve DNS cache hit ratio [SA v. MTA]
Message-ID: <20110706080005.103f978e@charlie.roaringpenguin.com>
In-Reply-To: <8h7hdk18fn+B76@austin.huge.strangled.net>
References: <4E1199F7.9010908@gmail.com>
	<4E11A960.6010305@gmail.com>
	<20110704092419.36e1936d@hydrogen.roaringpenguin.com>
	<4E138178.7000604@gmail.com>
	<20110705185532.07478914@shishi.roaringpenguin.com>
	<8h7hdk18fn+B76@austin.huge.strangled.net>
Organization: Roaring Penguin Software Inc.
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Wed, 06 Jul 2011 08:15:47 +0200
Andrzej Adam Filip <andrzej.filip@gmail.com> wrote:

> It may improve performance e.g. in case of hundredths mail servers in
> a data/co-location center using shared forwarder and rejecting on
> first DNSBL hit. Somehow I doubt buying data for such "reseller"
> configuration is legally encouraged  by paid DNSBL operators.

This is true.  But it's also not in paid DNSBL operators interest to
improve the hit ratio.  If the cache hit ratio is improved too much,
the DNSBL operators would be unable to detect heavy users and ask
(threaten) them for money. :)  In the limiting case, if the cache
becomes *too* effective, the organization hosting the cache *is*
effectively providing the whole data set to its users.

Regards,

David.