You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by Jeff Chan <je...@surbl.org> on 2004/04/21 05:50:36 UTC
Re: [SURBL-Discuss] Re: Bill Stearns' sa-blacklist available as SURBL: ws.surbl.org
On Tuesday, April 20, 2004, 7:12:25 PM, Scott Truman wrote:
> On Tuesday, April 20, 2004, 6:10:30 PM, Bill Landry wrote:
> > 127.0.0.2 = Spamcop
> > 127.0.0.3 = WS List
> > 127.0.0.4 = BigEvil List
> > 127.0.0.5 = etc...
> > Same thing multi-test RBLs like AHBL, Sorbs, Blars,
> FiveTen, NJABL and
> > others do.
> One could even extend that as such (if they don't already):
> 127.0.0.2 = SC List
> 127.0.0.4 = WS List
> 127.0.0.8 = BigEvil List
> 127.0.0.16 = Someother List
> etc....
> Multiple hits for the same lookup could be returned by combining the last octet i.e. a result of 127.0.0.10 would indicate the URI was found in both the SC and BigEvil lists. If one was only
> interested in what SC found, then one would AND the result with 127.0.0.2
Nice. We probably will do an "all" list, so this is good to
think about.
Does anyone have any comments about either approach? Bill seems
to indicate there was a precedent in other "combining" RBLs, but
Scott's suggestion is also clever.
(BTW Pardon the large cross posting, but this is the sort of thing
that would be good to work out up front. Maybe if someone could
gateway the question to other RBL folks for comment....)
Jeff C.
Re: Combined SURBL A record format (Was: Re: Bill Stearns' sa-blacklist
available as SURBL: ws.surbl.org)
Posted by Sidney Markowitz <si...@sidney.com>.
Jeff Chan wrote:
> The bitmask approach is more compact, but the multiple A record
> approach is more human-readable and transparent IMO
I don't think human-readability is necessary for an RBL. And the bitmask
format is transparent to a program and is more efficient for a program
to use. Making it readable to a human could be the task of a query
program that is designed to be used by a human. For example, if you have
a web page form to query the SURBL it could accept a host or domain name
or a URI and display in a list form instead of as a bitmask.
-- sidney
Combined SURBL A record format (Was: Re: Bill Stearns' sa-blacklist available as SURBL: ws.surbl.org)
Posted by Jeff Chan <je...@surbl.org>.
On Tuesday, April 20, 2004, 11:45:16 PM, Daniel Quinlan wrote:
> Anyhow, using a bitmask is done. OPM is probably the cleanest example.
> We (used to, OPM is now included in another blacklist so we dropped the
> rules) do OPM like this:
> # header __RCVD_IN_OPM eval:check_rbl('opm', 'opm.blitzed.org.')
> # describe __RCVD_IN_OPM Received via a relay in opm.blitzed.org
> # tflags __RCVD_IN_OPM net
> #
> # header RCVD_IN_OPM_WINGATE eval:check_rbl_sub('opm', '1')
> # describe RCVD_IN_OPM_WINGATE OPM: sender is open WinGate proxy
> # tflags RCVD_IN_OPM_WINGATE net
> #
> # header RCVD_IN_OPM_SOCKS eval:check_rbl_sub('opm', '2')
> # describe RCVD_IN_OPM_SOCKS OPM: sender is open SOCKS proxy
> # tflags RCVD_IN_OPM_SOCKS net
> #
> # header RCVD_IN_OPM_HTTP eval:check_rbl_sub('opm', '4')
> # describe RCVD_IN_OPM_HTTP OPM: sender is open HTTP CONNECT proxy
> # tflags RCVD_IN_OPM_HTTP net
> The second argument in check_rbl_sub is the bitmask (in decimal, not
> hex). We'd need to make some modifications to our URIBL module to do
> the same for a bitmasked SURBL, but I'm sure we would.
> We'd be just as happy with multiple A record returns. NJABL is a good
> example of this:
> ------- start of cut text --------------
> header __RCVD_IN_NJABL eval:check_rbl('njabl', 'dnsbl.njabl.org.')
> describe __RCVD_IN_NJABL Received via a relay in dnsbl.njabl.org
> tflags __RCVD_IN_NJABL net
> header RCVD_IN_NJABL_RELAY eval:check_rbl_sub('njabl', '127.0.0.2')
> describe RCVD_IN_NJABL_RELAY NJABL: sender is confirmed open relay
> tflags RCVD_IN_NJABL_RELAY net
> header RCVD_IN_NJABL_DIALUP eval:check_rbl('njabl-notfirsthop', 'dnsbl.njabl
> .org.', '127.0.0.3')
> describe RCVD_IN_NJABL_DIALUP NJABL: dialup sender did non-local SMTP
> tflags RCVD_IN_NJABL_DIALUP net
> header RCVD_IN_NJABL_SPAM eval:check_rbl_sub('njabl', '127.0.0.4')
> describe RCVD_IN_NJABL_SPAM NJABL: sender is confirmed spam source
> tflags RCVD_IN_NJABL_SPAM net
> header RCVD_IN_NJABL_MULTI eval:check_rbl_sub('njabl', '127.0.0.5')
> describe RCVD_IN_NJABL_MULTI NJABL: sent through multi-stage open relay
> tflags RCVD_IN_NJABL_MULTI net
Good to know. Sounds like it's mostly a question of style
then, though multiple A records would require no new coding
whereas bitmasks would.
http://opm.blitzed.org/info
> Using the DNSBL
>
> Anyone can query our DNSBL through normal DNS means. Just
> reverse the octets and do a name lookup. For example, to check
> if 127.0.0.2 is present in opm.blitzed.org, do a DNS lookup on
> 2.0.0.127.opm.blitzed.org. Each entry in the DNSBL has an A
> record and a TXT record associated with it, the TXT record
> contains a URL to the proxy information page specific to that
> IP address telling the user a little information about how to
> sort out the proxy.
>
> In opm.blitzed.org, the A record has an IP address of 127.1.0.x
> where x is a bitmask of the types of proxy that have been
> reported to be running on the host. The values of the bitmask
> are as follows:
>
> WinGate 1
> SOCKS 2
> HTTP CONNECT 4
> Router 8
> HTTP POST 16
The bitmask approach is more compact, but the multiple A record
approach is more human-readable and transparent IMO. I'm leaning
towards the latter, but am interested in any other comments.
Jeff C.
Combined SURBL A record format (Was: Re: Bill Stearns' sa-blacklist available as SURBL: ws.surbl.org)
Posted by Jeff Chan <je...@surbl.org>.
On Tuesday, April 20, 2004, 11:45:16 PM, Daniel Quinlan wrote:
> Anyhow, using a bitmask is done. OPM is probably the cleanest example.
> We (used to, OPM is now included in another blacklist so we dropped the
> rules) do OPM like this:
> # header __RCVD_IN_OPM eval:check_rbl('opm', 'opm.blitzed.org.')
> # describe __RCVD_IN_OPM Received via a relay in opm.blitzed.org
> # tflags __RCVD_IN_OPM net
> #
> # header RCVD_IN_OPM_WINGATE eval:check_rbl_sub('opm', '1')
> # describe RCVD_IN_OPM_WINGATE OPM: sender is open WinGate proxy
> # tflags RCVD_IN_OPM_WINGATE net
> #
> # header RCVD_IN_OPM_SOCKS eval:check_rbl_sub('opm', '2')
> # describe RCVD_IN_OPM_SOCKS OPM: sender is open SOCKS proxy
> # tflags RCVD_IN_OPM_SOCKS net
> #
> # header RCVD_IN_OPM_HTTP eval:check_rbl_sub('opm', '4')
> # describe RCVD_IN_OPM_HTTP OPM: sender is open HTTP CONNECT proxy
> # tflags RCVD_IN_OPM_HTTP net
> The second argument in check_rbl_sub is the bitmask (in decimal, not
> hex). We'd need to make some modifications to our URIBL module to do
> the same for a bitmasked SURBL, but I'm sure we would.
> We'd be just as happy with multiple A record returns. NJABL is a good
> example of this:
> ------- start of cut text --------------
> header __RCVD_IN_NJABL eval:check_rbl('njabl', 'dnsbl.njabl.org.')
> describe __RCVD_IN_NJABL Received via a relay in dnsbl.njabl.org
> tflags __RCVD_IN_NJABL net
> header RCVD_IN_NJABL_RELAY eval:check_rbl_sub('njabl', '127.0.0.2')
> describe RCVD_IN_NJABL_RELAY NJABL: sender is confirmed open relay
> tflags RCVD_IN_NJABL_RELAY net
> header RCVD_IN_NJABL_DIALUP eval:check_rbl('njabl-notfirsthop', 'dnsbl.njabl
> .org.', '127.0.0.3')
> describe RCVD_IN_NJABL_DIALUP NJABL: dialup sender did non-local SMTP
> tflags RCVD_IN_NJABL_DIALUP net
> header RCVD_IN_NJABL_SPAM eval:check_rbl_sub('njabl', '127.0.0.4')
> describe RCVD_IN_NJABL_SPAM NJABL: sender is confirmed spam source
> tflags RCVD_IN_NJABL_SPAM net
> header RCVD_IN_NJABL_MULTI eval:check_rbl_sub('njabl', '127.0.0.5')
> describe RCVD_IN_NJABL_MULTI NJABL: sent through multi-stage open relay
> tflags RCVD_IN_NJABL_MULTI net
Good to know. Sounds like it's mostly a question of style
then, though multiple A records would require no new coding
whereas bitmasks would.
http://opm.blitzed.org/info
> Using the DNSBL
>
> Anyone can query our DNSBL through normal DNS means. Just
> reverse the octets and do a name lookup. For example, to check
> if 127.0.0.2 is present in opm.blitzed.org, do a DNS lookup on
> 2.0.0.127.opm.blitzed.org. Each entry in the DNSBL has an A
> record and a TXT record associated with it, the TXT record
> contains a URL to the proxy information page specific to that
> IP address telling the user a little information about how to
> sort out the proxy.
>
> In opm.blitzed.org, the A record has an IP address of 127.1.0.x
> where x is a bitmask of the types of proxy that have been
> reported to be running on the host. The values of the bitmask
> are as follows:
>
> WinGate 1
> SOCKS 2
> HTTP CONNECT 4
> Router 8
> HTTP POST 16
The bitmask approach is more compact, but the multiple A record
approach is more human-readable and transparent IMO. I'm leaning
towards the latter, but am interested in any other comments.
Jeff C.
Re: [SURBL-Discuss] Re: Bill Stearns' sa-blacklist available as SURBL: ws.surbl.org
Posted by Daniel Quinlan <qu...@pathname.com>.
Jeff Chan <je...@surbl.org> writes:
> Does anyone have any comments about either approach? Bill seems
> to indicate there was a precedent in other "combining" RBLs, but
> Scott's suggestion is also clever.
You know, I did mention this (and I requested it at least once) to you
several weeks ago...
Anyhow, using a bitmask is done. OPM is probably the cleanest example.
We (used to, OPM is now included in another blacklist so we dropped the
rules) do OPM like this:
# header __RCVD_IN_OPM eval:check_rbl('opm', 'opm.blitzed.org.')
# describe __RCVD_IN_OPM Received via a relay in opm.blitzed.org
# tflags __RCVD_IN_OPM net
#
# header RCVD_IN_OPM_WINGATE eval:check_rbl_sub('opm', '1')
# describe RCVD_IN_OPM_WINGATE OPM: sender is open WinGate proxy
# tflags RCVD_IN_OPM_WINGATE net
#
# header RCVD_IN_OPM_SOCKS eval:check_rbl_sub('opm', '2')
# describe RCVD_IN_OPM_SOCKS OPM: sender is open SOCKS proxy
# tflags RCVD_IN_OPM_SOCKS net
#
# header RCVD_IN_OPM_HTTP eval:check_rbl_sub('opm', '4')
# describe RCVD_IN_OPM_HTTP OPM: sender is open HTTP CONNECT proxy
# tflags RCVD_IN_OPM_HTTP net
#
# header RCVD_IN_OPM_ROUTER eval:check_rbl_sub('opm', '8')
# describe RCVD_IN_OPM_ROUTER OPM: sender is open router proxy
# tflags RCVD_IN_OPM_ROUTER net
#
# header RCVD_IN_OPM_HTTP_POST eval:check_rbl_sub('opm', '16')
# describe RCVD_IN_OPM_HTTP_POST OPM: sender is open HTTP POST proxy
# tflags RCVD_IN_OPM_HTTP_POST net
The second argument in check_rbl_sub is the bitmask (in decimal, not
hex). We'd need to make some modifications to our URIBL module to do
the same for a bitmasked SURBL, but I'm sure we would.
We'd be just as happy with multiple A record returns. NJABL is a good
example of this:
------- start of cut text --------------
header __RCVD_IN_NJABL eval:check_rbl('njabl', 'dnsbl.njabl.org.')
describe __RCVD_IN_NJABL Received via a relay in dnsbl.njabl.org
tflags __RCVD_IN_NJABL net
header RCVD_IN_NJABL_RELAY eval:check_rbl_sub('njabl', '127.0.0.2')
describe RCVD_IN_NJABL_RELAY NJABL: sender is confirmed open relay
tflags RCVD_IN_NJABL_RELAY net
header RCVD_IN_NJABL_DIALUP eval:check_rbl('njabl-notfirsthop', 'dnsbl.njabl
.org.', '127.0.0.3')
describe RCVD_IN_NJABL_DIALUP NJABL: dialup sender did non-local SMTP
tflags RCVD_IN_NJABL_DIALUP net
header RCVD_IN_NJABL_SPAM eval:check_rbl_sub('njabl', '127.0.0.4')
describe RCVD_IN_NJABL_SPAM NJABL: sender is confirmed spam source
tflags RCVD_IN_NJABL_SPAM net
header RCVD_IN_NJABL_MULTI eval:check_rbl_sub('njabl', '127.0.0.5')
describe RCVD_IN_NJABL_MULTI NJABL: sent through multi-stage open relay
tflags RCVD_IN_NJABL_MULTI net
header RCVD_IN_NJABL_CGI eval:check_rbl_sub('njabl', '127.0.0.8')
describe RCVD_IN_NJABL_CGI NJABL: sender is an open formmail
tflags RCVD_IN_NJABL_CGI net
header RCVD_IN_NJABL_PROXY eval:check_rbl_sub('njabl', '127.0.0.9')
describe RCVD_IN_NJABL_PROXY NJABL: sender is an open proxy
tflags RCVD_IN_NJABL_PROXY net
------- end ----------------------------
Daniel
--
Daniel Quinlan anti-spam (SpamAssassin), Linux,
http://www.pathname.com/~quinlan/ and open source consulting
Re: [SURBL-Discuss] Re: Bill Stearns' sa-blacklist available as
SURBL: ws.surbl.org
Posted by Raymond Dijkxhoorn <ra...@prolocation.net>.
Hi!
> ;; ANSWER SECTION:
> 91.119.193.81.dnsbl.sorbs.net. 172657 IN A 127.0.0.3
> 91.119.193.81.dnsbl.sorbs.net. 172657 IN A 127.0.0.6
> 91.119.193.81.dnsbl.sorbs.net. 172657 IN A 127.0.0.2
>
> SA has several multi-response RBLs setup to post a single query and receive
> multiple responses. Here is a the above response handled by SA:
>
> *SNIP*
> Apr 22 09:24:19 gw1 amavis[28426]: (28426-10) SPAM-TAG, <xg...@aol.com> ->
> <jt...@pointshare.net>, Yes, hits=140.9 tagged_above=1.0 required=1.0
> tests=RCVD_IN_SORBS, RCVD_IN_SORBS-HTTP, RCVD_IN_SORBS-SOCKS,
> RCVD_IN_SORBS-SPAM
>
> Note that SA reported that the message failed three Sorbs test, all from a
> single DNS query.
thats also what i wanted to do with the seperate 'results', thanks for
explaining in detail. I guess most people have a clear vieuw now. So, when
can we start using the combined lists :)
Bye,
Raymond.
Re: [SURBL-Discuss] Re: Bill Stearns' sa-blacklist available as SURBL: ws.surbl.org
Posted by Bill Landry <Bi...@Pointshare.com>.
----- Original Message -----
From: "David B Funk" <db...@engineering.uiowa.edu>
> Both two encodings are used by other DSBLs. The first one is an
> enumeration (used by Sorbs, NJABL, etc), the second one a bit-field
> ("set") (used by MAPS RBL+).
>
> The enumeration has the advantage of being simpler and covering
> more posibilities but is only single valued. (IE the match is for
> only one possible list).
That's not correct. For example, one query as follows to Sorbs return
several result codes:
dig 91.119.193.81.dnsbl.sorbs.net
;; ANSWER SECTION:
91.119.193.81.dnsbl.sorbs.net. 172657 IN A 127.0.0.3
91.119.193.81.dnsbl.sorbs.net. 172657 IN A 127.0.0.6
91.119.193.81.dnsbl.sorbs.net. 172657 IN A 127.0.0.2
SA has several multi-response RBLs setup to post a single query and receive
multiple responses. Here is a the above response handled by SA:
*SNIP*
Apr 22 09:24:19 gw1 amavis[28426]: (28426-10) SPAM-TAG, <xg...@aol.com> ->
<jt...@pointshare.net>, Yes, hits=140.9 tagged_above=1.0 required=1.0
tests=RCVD_IN_SORBS, RCVD_IN_SORBS-HTTP, RCVD_IN_SORBS-SOCKS,
RCVD_IN_SORBS-SPAM
Note that SA reported that the message failed three Sorbs test, all from a
single DNS query.
Bill
Re: [SURBL-Discuss] Re: Bill Stearns' sa-blacklist available as SURBL: ws.surbl.org
Posted by Bill Landry <Bi...@Pointshare.com>.
----- Original Message -----
From: "David B Funk" <db...@engineering.uiowa.edu>
> Both two encodings are used by other DSBLs. The first one is an
> enumeration (used by Sorbs, NJABL, etc), the second one a bit-field
> ("set") (used by MAPS RBL+).
>
> The enumeration has the advantage of being simpler and covering
> more posibilities but is only single valued. (IE the match is for
> only one possible list).
That's not correct. For example, one query as follows to Sorbs return
several result codes:
dig 91.119.193.81.dnsbl.sorbs.net
;; ANSWER SECTION:
91.119.193.81.dnsbl.sorbs.net. 172657 IN A 127.0.0.3
91.119.193.81.dnsbl.sorbs.net. 172657 IN A 127.0.0.6
91.119.193.81.dnsbl.sorbs.net. 172657 IN A 127.0.0.2
SA has several multi-response RBLs setup to post a single query and receive
multiple responses. Here is a the above response handled by SA:
*SNIP*
Apr 22 09:24:19 gw1 amavis[28426]: (28426-10) SPAM-TAG, <xg...@aol.com> ->
<jt...@pointshare.net>, Yes, hits=140.9 tagged_above=1.0 required=1.0
tests=RCVD_IN_SORBS, RCVD_IN_SORBS-HTTP, RCVD_IN_SORBS-SOCKS,
RCVD_IN_SORBS-SPAM
Note that SA reported that the message failed three Sorbs test, all from a
single DNS query.
Bill
Re: [SURBL-Discuss] Re: Bill Stearns' sa-blacklist available as
SURBL: ws.surbl.org
Posted by David B Funk <db...@engineering.uiowa.edu>.
On Tue, 20 Apr 2004, Jeff Chan wrote:
> On Tuesday, April 20, 2004, 7:12:25 PM, Scott Truman wrote:
> > On Tuesday, April 20, 2004, 6:10:30 PM, Bill Landry wrote:
>
> > > 127.0.0.2 = Spamcop
> > > 127.0.0.3 = WS List
> > > 127.0.0.4 = BigEvil List
> > > 127.0.0.5 = etc...
>
> > > Same thing multi-test RBLs like AHBL, Sorbs, Blars,
> > FiveTen, NJABL and
> > > others do.
>
> > One could even extend that as such (if they don't already):
>
> > 127.0.0.2 = SC List
> > 127.0.0.4 = WS List
> > 127.0.0.8 = BigEvil List
> > 127.0.0.16 = Someother List
> > etc....
>
> > Multiple hits for the same lookup could be returned by combining the last octet i.e. a result of 127.0.0.10 would indicate the URI was found in both the SC and BigEvil lists. If one was only
> > interested in what SC found, then one would AND the result with 127.0.0.2
>
> Nice. We probably will do an "all" list, so this is good to
> think about.
>
> Does anyone have any comments about either approach? Bill seems
> to indicate there was a precedent in other "combining" RBLs, but
> Scott's suggestion is also clever.
Both two encodings are used by other DSBLs. The first one is an
enumeration (used by Sorbs, NJABL, etc), the second one a bit-field
("set") (used by MAPS RBL+).
The enumeration has the advantage of being simpler and covering
more posibilities but is only single valued. (IE the match is for
only one possible list).
The bit-field has the advantage of being able to represent membership
in multiple lists at the cost of represinting fewer lists (7 as opposed
to 254 possible groups). IE you can say that a particular entry
is in both SC list & WS list.
SA already has functions for picking apart either kind of representation.
Given the nature of the proposed blackist (IE a compilation of different
sources of information), I'd suggest the bit-field format to best handle
the case of a given host being in more than one list.
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: [SURBL-Discuss] Re: Bill Stearns' sa-blacklist available as SURBL: ws.surbl.org
Posted by Daniel Quinlan <qu...@pathname.com>.
Jeff Chan <je...@surbl.org> writes:
> Does anyone have any comments about either approach? Bill seems
> to indicate there was a precedent in other "combining" RBLs, but
> Scott's suggestion is also clever.
You know, I did mention this (and I requested it at least once) to you
several weeks ago...
Anyhow, using a bitmask is done. OPM is probably the cleanest example.
We (used to, OPM is now included in another blacklist so we dropped the
rules) do OPM like this:
# header __RCVD_IN_OPM eval:check_rbl('opm', 'opm.blitzed.org.')
# describe __RCVD_IN_OPM Received via a relay in opm.blitzed.org
# tflags __RCVD_IN_OPM net
#
# header RCVD_IN_OPM_WINGATE eval:check_rbl_sub('opm', '1')
# describe RCVD_IN_OPM_WINGATE OPM: sender is open WinGate proxy
# tflags RCVD_IN_OPM_WINGATE net
#
# header RCVD_IN_OPM_SOCKS eval:check_rbl_sub('opm', '2')
# describe RCVD_IN_OPM_SOCKS OPM: sender is open SOCKS proxy
# tflags RCVD_IN_OPM_SOCKS net
#
# header RCVD_IN_OPM_HTTP eval:check_rbl_sub('opm', '4')
# describe RCVD_IN_OPM_HTTP OPM: sender is open HTTP CONNECT proxy
# tflags RCVD_IN_OPM_HTTP net
#
# header RCVD_IN_OPM_ROUTER eval:check_rbl_sub('opm', '8')
# describe RCVD_IN_OPM_ROUTER OPM: sender is open router proxy
# tflags RCVD_IN_OPM_ROUTER net
#
# header RCVD_IN_OPM_HTTP_POST eval:check_rbl_sub('opm', '16')
# describe RCVD_IN_OPM_HTTP_POST OPM: sender is open HTTP POST proxy
# tflags RCVD_IN_OPM_HTTP_POST net
The second argument in check_rbl_sub is the bitmask (in decimal, not
hex). We'd need to make some modifications to our URIBL module to do
the same for a bitmasked SURBL, but I'm sure we would.
We'd be just as happy with multiple A record returns. NJABL is a good
example of this:
------- start of cut text --------------
header __RCVD_IN_NJABL eval:check_rbl('njabl', 'dnsbl.njabl.org.')
describe __RCVD_IN_NJABL Received via a relay in dnsbl.njabl.org
tflags __RCVD_IN_NJABL net
header RCVD_IN_NJABL_RELAY eval:check_rbl_sub('njabl', '127.0.0.2')
describe RCVD_IN_NJABL_RELAY NJABL: sender is confirmed open relay
tflags RCVD_IN_NJABL_RELAY net
header RCVD_IN_NJABL_DIALUP eval:check_rbl('njabl-notfirsthop', 'dnsbl.njabl
.org.', '127.0.0.3')
describe RCVD_IN_NJABL_DIALUP NJABL: dialup sender did non-local SMTP
tflags RCVD_IN_NJABL_DIALUP net
header RCVD_IN_NJABL_SPAM eval:check_rbl_sub('njabl', '127.0.0.4')
describe RCVD_IN_NJABL_SPAM NJABL: sender is confirmed spam source
tflags RCVD_IN_NJABL_SPAM net
header RCVD_IN_NJABL_MULTI eval:check_rbl_sub('njabl', '127.0.0.5')
describe RCVD_IN_NJABL_MULTI NJABL: sent through multi-stage open relay
tflags RCVD_IN_NJABL_MULTI net
header RCVD_IN_NJABL_CGI eval:check_rbl_sub('njabl', '127.0.0.8')
describe RCVD_IN_NJABL_CGI NJABL: sender is an open formmail
tflags RCVD_IN_NJABL_CGI net
header RCVD_IN_NJABL_PROXY eval:check_rbl_sub('njabl', '127.0.0.9')
describe RCVD_IN_NJABL_PROXY NJABL: sender is an open proxy
tflags RCVD_IN_NJABL_PROXY net
------- end ----------------------------
Daniel
--
Daniel Quinlan anti-spam (SpamAssassin), Linux,
http://www.pathname.com/~quinlan/ and open source consulting
Re: [SURBL-Discuss] Re: Bill Stearns' sa-blacklist available as
SURBL: ws.surbl.org
Posted by David B Funk <db...@engineering.uiowa.edu>.
On Tue, 20 Apr 2004, Jeff Chan wrote:
> On Tuesday, April 20, 2004, 7:12:25 PM, Scott Truman wrote:
> > On Tuesday, April 20, 2004, 6:10:30 PM, Bill Landry wrote:
>
> > > 127.0.0.2 = Spamcop
> > > 127.0.0.3 = WS List
> > > 127.0.0.4 = BigEvil List
> > > 127.0.0.5 = etc...
>
> > > Same thing multi-test RBLs like AHBL, Sorbs, Blars,
> > FiveTen, NJABL and
> > > others do.
>
> > One could even extend that as such (if they don't already):
>
> > 127.0.0.2 = SC List
> > 127.0.0.4 = WS List
> > 127.0.0.8 = BigEvil List
> > 127.0.0.16 = Someother List
> > etc....
>
> > Multiple hits for the same lookup could be returned by combining the last octet i.e. a result of 127.0.0.10 would indicate the URI was found in both the SC and BigEvil lists. If one was only
> > interested in what SC found, then one would AND the result with 127.0.0.2
>
> Nice. We probably will do an "all" list, so this is good to
> think about.
>
> Does anyone have any comments about either approach? Bill seems
> to indicate there was a precedent in other "combining" RBLs, but
> Scott's suggestion is also clever.
Both two encodings are used by other DSBLs. The first one is an
enumeration (used by Sorbs, NJABL, etc), the second one a bit-field
("set") (used by MAPS RBL+).
The enumeration has the advantage of being simpler and covering
more posibilities but is only single valued. (IE the match is for
only one possible list).
The bit-field has the advantage of being able to represent membership
in multiple lists at the cost of represinting fewer lists (7 as opposed
to 254 possible groups). IE you can say that a particular entry
is in both SC list & WS list.
SA already has functions for picking apart either kind of representation.
Given the nature of the proposed blackist (IE a compilation of different
sources of information), I'd suggest the bit-field format to best handle
the case of a given host being in more than one list.
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{