Discuss

discuss@lists.surbl.org

1867 discussions

Re: [SURBL-Discuss] Re: Bill Stearns' sa-blacklist available as SURBL: ws.surbl.org
by Daniel Quinlan 21 Apr '04

21 Apr '04

Jeff Chan <jeffc(a)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

3 2

RE: [SURBL-Discuss] Combined SURBL A record format (Was: Re: Bill Stearns' sa-blacklistavailable as SURBL: ws.surbl.org)
by Scott Truman 21 Apr '04

21 Apr '04

> 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. > This is all quite interesting. I'm happy with either method obviously. Excuse my ignorance with regards to DNS lookups, but do all the A records come down with the first DNS lookup, or are they fetched each time from the remote server? What are the traffic overheads with incorporating either type of method - I would have thought that the bit mask method would cause less traffic - also with smaller zone transfers? Cheers Scott

2 1

RFC: SURBL software implemetation guidelines
by Jeff Chan 21 Apr '04

21 Apr '04

I'm adding a very brief section to the Quick Start of the SURBL site: > Implementation guidelines > Here are some very brief instructions for folks writing > software to use SURBL lists: You code should: > > 1. Extract URIs from message bodies > 2. (Extraction of URIs from message bodies should ideally > include full resolution of redirections into the final target > domain name. This can be a non-trivial problem.) > > 3. Extract base (registrar) domains from those URIs > 4. Not do name resolution on the domains > 5. Look up the domain name in the SURBL by prepending it to > the name of the SURBL, e.g., domainundertest.com.sc.surbl.org > then doing Address record DNS resolution. A non-result > indicates lack of inclusion in the list. A result of 127.0.0.2 > represents inclusion. > 6. Handle numeric IPs in URIs similarly, but reverse the > octet ordering before comparison against the RBL. This is > standard practice for RBLs. For example, http://1.2.3.4/ is > checked as 4.3.2.1.sc.surbl.org > > SURBL lists unusually have both names and numbers in the same > list. For example, 2.0.0.127 and example.com and similar actual > spam domains and addresses are both in all SURBL lists. > Numbered addresses in SURBLs are to have occurred as numbers in spams. Can anyone think of any additions, corrections, or suggestions before I announce it more broadly? Jeff C. -- Jeff Chan mailto:jeffc@surbl.org http://www.jeffchan.com/

5 19

[SURBL-Discuss] Administrivia: announce replies go to discuss, discuss replies go to list
by Jeff Chan 21 Apr '04

21 Apr '04

I probably should have cross posted this originally, but replies on the discussion list now go back to the list via a Reply-To: address. This was influenced by Kelsey's suggestion. It may be more convenient for most replies, but note that if you want to reply to only the poster, you'll need to edit your recipients. Jeff C. __ From: Jeff Chan <jeffc(a)surbl.org> To: SURBL Announce <announce(a)lists.surbl.org> Date: Tuesday, April 20, 2004, 5:15:45 PM Subject: [SURBL-Announce] Administrivia: announce replies go to discuss, discuss replies go to list We've changed the list settings slightly to direct replies to this announcement list to go to the discussion list, and for replies on the discussion list to go to the list by default rather than to the poster. discuss(a)lists.surbl.org Hope that's ok with everyone. Please reply off list if it's not. :-) Jeff C.

1 0

[SURBL-Discuss] RE: Bill Stearns' sa-blacklist available as SURBL: ws.surbl.org
by Chris Santerre 21 Apr '04

21 Apr '04

[forwarded response from announce list] The ONLY complaint anyone ever had with Stearn's list was the overhead. With it setup this way, there is no stopping him!! :) Great job by Bill and Jeff! --Chris (Yeah I know,....the list.) :-) > -----Original Message----- > From: Don Newcomer [mailto:newcomer@dickinson.edu] > Sent: Tuesday, April 20, 2004 8:41 AM > To: Jeff Chan > Cc: SURBL Announce; SpamAssassin Users > Subject: Re: Bill Stearns' sa-blacklist available as SURBL: > ws.surbl.org > > > Wow, I implemented this yesterday and, after about 18 hours, > this rule was > #4 in my list of most-used rules! Good job, guys!

1 0

[SURBL-Discuss] Re: Bill Stearns' sa-blacklist available as SURBL: ws.surbl.org
by William Stearns 21 Apr '04

21 Apr '04

[forwarded response from announce list] Good morning, Don, On Tue, 20 Apr 2004, Don Newcomer wrote: > Wow, I implemented this yesterday and, after about 18 hours, this rule was > #4 in my list of most-used rules! Good job, guys! Fantastic! How are the system cpu load and memory usage at the moment? I assume your enthusiasm means they're both in acceptable ranges? Cheers, - Bill --------------------------------------------------------------------------- "... It ... could ... work!" -- Gene Wilder in Young Frankenstein -------------------------------------------------------------------------- William Stearns (wstearns(a)pobox.com). Mason, Buildkernel, freedups, p0f, rsync-backup, ssh-keyinstall, dns-check, more at: http://www.stearns.org --------------------------------------------------------------------------

1 0

[SURBL-Discuss] Re: Bill Stearns' sa-blacklist available as SURBL: ws.surbl.org
by Don Newcomer 21 Apr '04

21 Apr '04

[forwarded response from announce list] Wow, I implemented this yesterday and, after about 18 hours, this rule was #4 in my list of most-used rules! Good job, guys! ================================================================================ Don Newcomer Dickinson College Senior Manager, Systems P.O. Box 1773 newcomer(a)dickinson.edu Carlisle, PA 17013 Phone: (717) 245-1256 FAX: (717) 245-1690

1 0

ANNOUNCE: Mail::SpamAsssassin::SpamCopURI 0.11
by Eric Kolve 21 Apr '04

21 Apr '04

I have just released SpamCopURI version 0.11. This fixes a few bugs that had been reported and adds open redirect resolution. This basically takes a URL from say rd.yahoo.com and attempts to resolve the Location header without ever fetching from the potential spammy site. Only the URLs that have hosts that match an address list get redirect resolution. As well, redirect resolution is off by default, but can be enabled in the conf file. I have placed several open redirect sites in the conf file. The basic requirement is that the redirect return a 300 level HTTP response when fetching. I placed google.com in there even though they don't have their own redirect domain, but this should be fairly safe since most if not all google URLs are either redirects or searches. Give it a try and tell me what you think. This is all dependent upon LWP, but if you don't have LWP everything else will function as it did before. I have removed all the deprecated tests that depended on local Storable data. See the INSTALL file for information about upgrading from a previous version. There is all a bit more information about installation that should help those that had trouble in the past. --eric

2 1

[SURBL-Discuss] Fwd: Re: Bill Stearns' sa-blacklist available as SURBL: ws.surbl.org
by Jeff Chan 21 Apr '04

21 Apr '04

Here are some good comments from Dave Funk about the handling/creation of the SURBLs. Please comment on his suggestions, several of which we may want to implement as time permits. Jeff C. __ On Tue, 20 Apr 2004, Jeff Chan wrote: > On Tuesday, April 20, 2004, 1:20:05 PM, Charles Gregory wrote: > > Would it be possible to have 'surbl.org' run a *combined* blacklist, so > > that people who want to check both 'ws.surbl.org' *and* 'sc.surbl.org' can > > do it with ONE dns lookup request, instead of two? > > Good question, which Matt asks also. Here's my response :-) > [snip..] > > Because ws is larger and more stable, the zone files for it > > gets a six hour TTL compared to 10 minutes for sc. Due to the > > differences between the time scales, sizes, and data sources of > > ws and sc, we probably won't be offering a combined ws plus sc > > list. For example it would be difficult to say what TTL a > > merged list should get, and you probably would not want a > > megabyte plus BIND zone file refreshing every 10 minutes. For > > those using rsynced zone files that would probably not be an > > issue, but for those using BIND, the DNS traffic quite well > > could be. > > So the quick answer is they'll probably not be combined. > > However we probably will offer a combined version of Bill's > list and Chris' BigEvil list since they are more similar in > character. A few comments. 1) It is possible to set a TTL in a DNS zone on a per-record basis. (at least with BIND). So you could combine the two zones and have the 'sc' records flagged with a short TTL, and 'ws' with longer. 2) Newer versions of BIND support incremental zone-transfer, and so will just push changes. 3) We also secondary MAPS RBL+ zone, that's a 54Mbyte zone that updates every 3 hours. (IE 18Mbyte/hour). A 1Mbyte x 10 minutes would be only 6Mbytes/hour, chicken feed. ;) 4) Over half the size of those zones is in the TXT records. Just changing 'Message body contains domain in sa-blacklist. See: http://www.stearns.org/sa-blacklist/' to 'Blocked, See: http://www.stearns.org/sa-blacklist/' reduced the 'ws' zone size by 33% 5) It's possible to combine the zones but keep the data logically seperate so people can differentiate and adjust scores/policys accordingly. Check out how MAPS does RBL+, the A record returns an "IP address" that is effectivly a bit-mask flag to indicate which MAPS zone the original hit was from (DUL, RSS, RBL, OPS, etc). Look at how the 'check_rbl' and 'check_rbl_sub' routines are used inside SA to pull apart a single DNS query against RBL+ (at least in SA 2.6*, havn't looked at 3.0 yet ;) This is not to imply criticism if your response, just some tech info to show alternatives. Regardless, I would recommend using 5) when you combine Bill's list and Chris' BigEvil so that people can differentiate in case they have score/policy concerns regarding the two. People who just look for the existence of the A record won't notice the difference but people who know and care can utilize the additional info. Dave -- 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{ -- Jeff Chan mailto:jeffc@surbl.org-nospam http://www.surbl.org/

5 6

[SURBL-Discuss] RE: RFC: Removing example.com as a testpoint (Was: Re: [SURBL-Dis cuss] Re: No install Problems with 0.10)
by Chris Santerre 20 Apr '04

20 Apr '04

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss