Jeff Chan jeffc@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
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.
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.
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