Re: [dspam-users] RABL Now LIVE!

This sounds stupid unless I explain that I let dspam train in
realtime, not corpus later, on messages that I can detect are
u.s.e. by honeypot addresses. In other words, we are talking
about dspam tokenized messages in a way that cannot taint
rabl, although it puts the cart before the horse as far as
statistically derived, instead training the statistical filter.

And I will upgrade the listserver grep outgoing to collect list
server ip's. Perhaps for more people to implement writing,
rabl ought to look at the same listserver ip file to escape list
server ip's. Then it would be up to us to write that file somehow.

What about big spammers like aol and yahoo, do we bl them?
I hope not because that's why I stopped referencing bl's and
started relying exclusively on dspam, clam, and protocol and
header checking by the mta.

It shouldn't dumb down my dspam to trust central rabl as
long as I set dspam.conf to train dspam on rabl messages,
which you have provided an option for in dspam.conf.

Bob Dodds wrote:
> Jonathan Zdziarski wrote:
>> rabl is not online at the moment. i need to update the page. nobody's
>> really shown much interest in becoming a writer.
>>
>> Jonathan
> I was scared off by your desire to have high traffic
> systems reporting. I can report verified honeypot
> u.s.e.(no mailing list server ip's) spread over 75
> virtual domains.
>
> I have rabl_server and rabl_client installed but
> to separate out only honeypot, no addresses
> subscribed to mailing lists, I have to write
> something to touch those ip files rather than
> dspam doing it. Hopefully one line added to
> my mta and config dspam.conf not to report,
> then let rabl_server and rabl_client do their
> thing.
>
> TODO:
>
> I grep outgoing for ezmlm list servers and write
> them all to a file so as not to verp to ezmlm and
> not to require verp on bounces from ezmlm. ezmlm
> can't handle verp, and if they upgrade it, there
> will be old ezmlm versions out there for years.
> One could grep outgoing for ALL list server "magic"
> in headers, and on that basis, not report list server
> ip's to rabl, but the central rabl server could not do
> that for itself. How a writer deals with this issue
> would be part of assessing trust. At first I would
> simply only report honeypot u.s.e. sources to
> circumvent the list server problem. We would
> pass around our "magic" for detecting list servers
> in headers of outgoing.
>
> # skip if a mailing list alias appended to that address
> my ( $local , $domain ) = ( $skip =~ /^(.*)\@(.*?)$/ ) ;
> if ( $stripped =~ /^\Q$local\E\b/i and $stripped =~
> /\@\Q$domain\E$/i ) {
> $self->log( LOGDEBUG , "skip hyphenated looking like list alias:
> $skip" ) ;
> return undef ;
> }
> ...................
>
> if ( $transaction->header->get( 'Mailing-List' )
> and my ( $ezmlm_list , $ezmlm_domain )
> = ( $transaction->header->get( 'Mailing-List' )
> =~/ ([^ ]*)-help(\@.*); (run by ezmlm$)/ ) ) {
>
> $self->log( LOGDEBUG ,
> "ezmlm server at $ezmlm_list$ezmlm_domain belongs on skip list" ) ;
>
> my @skips
> = uniq ( $ezmlm_list . $ezmlm_domain , $self->qp->config(
> 'bounce_verp.skip' ) ) ;
>
> open ( SKIP , '>' , "./config/bounce_verp.skip" )
> or die "Can't write to ./config/bounce_verp.skip $!" ;
>
> printf SKIP "%s\n"x@skips , @skips ;
>
> close SKIP ;
>
> }
>
>>
>>
>>
>> On Dec 13, 2005, at 9:23 AM, Aaron Wolfe wrote:
>>
>>> Can anyone confirm that this actually works? I setup my config file
>>> as per below and although I'm not sure what I'm looking for in the
>>> logs, a tcpdump for any traffic from or to rabl.nuclearelephant.com
>>> <http://rabl.nuclearelephant.com> shows zero traffic. Is there a
>>> way to manually test the blacklist?
>>> Does a blacklist hit generate a unique log entry in the system or
>>> user logs?
>>> Thanks
>>> -Aaron
>>>
>>> On 12/11/05, *Bob Dodds* <cto@xqme.com <mailto:cto@xqme.com>> wrote:
>>>
>>> David Wolfgang-Kimball wrote:
>>> > Is this up..? I get no response.
>>> >
>>> > On Aug 1, 2005, at 5:46 PM, Jonathan Zdziarski wrote:
>>> >
>>> >> The world's first fully machine-automated statistical
>>> blackhole list
>>> >> (yes, we existed before the WPBL) is now live. The Reactive
>>> >> Autonomous Blackhole List (RABL, or "rabble") is a statistically
>>> >> automated list designed to measure spam and virii based on
>>> network
>>> >> penetration (how widespread a particular sender ip has affected
>>> >> networks across the world). At the moment, there are only a few
>>> >> writer accounts on the system, so the catch rate is minimal,
>>> but I
>>> >> hope to have many more getting on board in the coming weeks.
>>> Please
>>> >> check it out at http://rabl.nuclearelephant.com. DSPAM integrates
>>> >> into the RABL both reading and writing, so it will be very
>>> simple to
>>> >> get on board. Just contact me if you're interested in a write
>>> >> account. My only requirement at the moment is that I have to know
>>> >> you (or someone who knows you) and can verify you're not a
>>> spammer.
>>> >> larger systems would be ideal.
>>> >>
>>> >> Jonathan
>>> Use rabl.nuclearelephant.com <http://rabl.nuclearelephant.com>
>>> like this:
>>>
>>> # /etc/dspam/dspam.conf
>>> Lookup " rabl.nuclearelephant.com <http://rabl.nuclearelephant.com>"
>>>
>>> Web Browser: http://www.nuclearelephant.com/projects/rabl/
>>>
>>> rabl items in /etc/dspam/dspam.conf
>>>
>>> # Lookup: Perform lookups on streamlined blackhole list servers
>>> (see
>>> # http://www.nuclearelephant.com/projects/sbl/)
>>> <http://www.nuclearelephant.com/projects/sbl/%29>. The
>>> streamlined blacklist
>>> # server is machine-automated, unsupervised blacklisting system
>>> designed to
>>> # provide real-time and highly accurate blacklisting based on
>>> network
>>> spread.
>>> # When performing a lookup, DSPAM will automatically learn the
>>> inbound
>>> message
>>> # as spam if the source IP is listed. Until an official public RABL
>>> server is
>>> # available, this feature is only useful if you are running your own
>>> # streamlined blackhole list server for internal reporting among
>>> multiple mail
>>> # servers. Provide the name of the lookup zone below to use.
>>> #
>>> # This function performs standard reverse-octet.domain lookups,
>>> and while it
>>> # will function with many RBLs, it's strongly discouraged to use
>>> those
>>> # maintained by humans as they're often inaccurate and could
>>> hurt filter
>>> # learning and accuracy.
>>> #
>>> Lookup "rabl.nuclearelephant.com <http://rabl.nuclearelephant.com>"
>>>
>>> #
>>> # RBLInoculate: If you want to inoculate the user from RBL'd
>>> messages it
>>> would
>>> # have otherwise missed, set this to on.
>>> #
>>> RBLInoculate on
>>>
>>> # TrackSources: specify which (if any) source addresses to track
>>> and report
>>> # them to syslog (mail.info <http://mail.info>). This is useful
>>> if you're running a firewall or
>>> # blacklist and would like to use this information. Spam
>>> reporting also
>>> drops
>>> # RABL blacklist files (see
>>> http://www.nuclearelephant.com/projects/rabl/ ).
>>> #
>>> TrackSources spam
>>>
>>> # RABLQueue: Touch files in the RABL queue
>>> # If you are a reporting streamlined blackhole list participant,
>>> you can
>>> # touch ip addresses within the directory the rabl_client
>>> process is
>>> watching.
>>> #
>>> # cvs -d :pserver:cvs@cvs.nuclearelephant.com
>>> <mailto:cvs@cvs.nuclearelephant.com>:/usr/local/cvsroot login
>>> # cvs -d :pserver:cvs@cvs.nuclearelephant.com
>>> <mailto:cvs@cvs.nuclearelephant.com>:/usr/local/cvsroot co
>>> rabl_server
>>> #
>>> #RABLQueue /var/spool/rabl
>>>
>>>
>>>
>>>
>>
>
Received on Tue Dec 13 15:34:00 2005