Mailing-List: contact users-help@spamassassin.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of robert@schetterer.org
 designates 212.52.224.206 as permitted sender)
Message-ID: <4F0E8D8C.2080108@schetterer.org>
Date: Thu, 12 Jan 2012 08:36:44 +0100
From: Robert Schetterer <robert@schetterer.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: users@spamassassin.apache.org
Subject: Re: [OT] RBLs
References: <013ed5d1-6b05-4fb6-8f37-f696823cdba9@office.splatnix.net>
 <alpine.OSX.1.10.1201111144100.34990@dave-silver-mini.local>
 <4F0DF9C4.4080901@pacific.net>
 <Pine.LNX.4.64.1201111559110.8286@a-lnx000.engr.uiowa.edu>
 <4F0E0F0D.3020208@invaluement.com>
In-Reply-To: <4F0E0F0D.3020208@invaluement.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Am 11.01.2012 23:37, schrieb Rob McEwen:
> On 1/11/2012 5:10 PM, David B Funk wrote:
>> Problem with all those methods is that they're reactive, will not hit
>> until -after- somebody has seen the bad crap and created filers,
>> RBL-lists, taught Bayes, etc.
>>
>> The OP explicitly said that the first spam run was at 06:39 and by
>> 06:42 it was hitting RBLs (pretty darned quick by my book;).
>> However he has some fussy customers who weren't understanding and
>> so was asking for a method of dealing with this. 
> 
> This is actually a good argument for having a variety of good IP and URI
> DNSBLs. Even the fastest reacting ones are going to update, at most,
> once per minute. (and even that is rather rare... I think most
> fast-reacting ones update every ~5 minutes.) Even then, public DNSBLs
> have to rsync from the master to mirrors before the data is usable.
> 
> For this reason, you're going to hit some DNSBLs just seconds after they
> updated... others are going to be a little less fresh. This is exactly
> why having multiple quality DNSBLs is helpful. If you check 8 different
> good ones instead of 2 different good ones (for example), then there is
> a greater chance that you'll query one of those mere seconds after it
> updated, and where it already had data on a new spam campaign.
> 
> Along those lines, with the invaluement blacklists that I manage...
> we're soon going to offer a special version whereby we send an alert to
> "trigger" subscribers' rsyncs within a couple of seconds after each
> invaluement list's last update--thus making that reaction time even
> faster--and causing more spam that are at the "tip of the spear" to get
> caught.
> 
> ALSO: There are OFTEN times when an IP doesn't have a chance to get
> caught, but it contains a domain already found on surbl, uribl, ivmURI,
> or DBL. Or, times when a domain hadn't had a chance to get caught yet,
> but the IP is caught from a previous spam campaign. But if you're not
> using all the best DNSBLs, you miss out on some of this!
> 
> MORE: And, btw, really good /24 blacklists do _preemptively_ block much
> snowshoe spam, from the very 1st spam sent!
> 

Hi Rob, read postfix archives
about rbls, there are tons of info
this all was discussed before, there is simply nothing "very" new
about this theme, there might be "news" with comming up more use of ipv6
spam


-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria